Roll Call

  • Kevin Porter and Petar Lalovic from Toronto
  • Michael Lawrence Evans from Code for America
  • Mark Head from Voxeo Labs
  • Cliff Ingham and Rick Dietz from Bloomington
  • Matt Bonness from Motorola
  • Eric Carson from Connected Bits
  • Dmitry Kachaev Labs
  • Philip Ashlock with OpenPlans & Civic Commons

Review state of deployments

Discuss adoption by providers and clients, this will help us understand the need we may address with spec changes.

  • Matt: Baltimore Service discovery URL is still blank.
  • Eric: ConnectedBits will add these URLs. A couple more deployments coming in the near future.

GeoReport 2.x

Review process of continued development of GeoReport v2 spec. Went over the proposal outlined at

GeoReport features for future spec

  • User management - authentication. Need to filter for users own requests
    • Cliff: may also have a mobile version without a “my reports” feature. No clear path on approach (openid, oauth, have complexities).
    • Mark: Authentication is the tricky part, once we have it, we can let servers decide what to spit out. The server can decide what information to return or accept based on the authentication.
    • Possibly add list of permissions to discovery somehow.
    • Would be good to use a standardized approach to authentication.
  • Media handling, just add that as part of POST, eg as multipart.
  • Cross domain handling with JS, eg JSONP.
  • Adding internal management features to the spec (update status, assign ticket, etc)
    • complex issue, different workflow models, and permissions. We should be cautious about going into this.
  • Commenting. How to add additional information about an existing request. Good to have a two way dialogue. In Bloomington, we anticipate multiple requests for the same problem and those can be easily grouped.
  • Petar on mandatory fields: Fields that we require, vs optional. How do we convey that something defined as optional in the spec is actually mandatory for us. Additional node in service definition response, list the arguments for required fields that are part of the core spec. Example is graffiti on private building, we require names and emails. Override using service_definitions with their own requirements. This needs additional discussion, continue the original thread:
    • Change the spec to be explicit about required fields, eg email, locations.
  • non-geospatial uses of GeoReport, eg federal level interest. This is already being done in Bloomington

Service Discovery

  • LoST as possible long term approach
  • start with list, name of city and jurisdiction_ids

Inquiry API development

More to come. New wiki page for drafting:

Inventory of Products/Services

Please add yours:

Additional Discussion

  • Dmitry: Question to CfA folks - new Dashboard, can it be easily connected to other cities.?
  • Michael: It works with Boston’s data, but we might not be getting all their data. It’s not easily plugged in and there are inconsistent implementations of the spec in different cities. Will be posting documentation of issues that came up.
  • Michael: Apigee, console for Twitter API.
  • Phil: Mashery open sourced their interactive API docs. We can see about implementing this for our docs:
  • Dmitry: WMATA folks said Mashery offers some of their service to government for free.
  • Mark: Need to think about API platform services using open standards
  • Phil: Validator should help on ensuring interoperability and consistent implementations.
  • Michael: a founder of github created a thing called - easy way to test APIs online so you don’t have to know too much about it. Has inspired twitter API interfaces, eg twurl.
  • Kevin: concern over privacy. If people come in to use these apps … If they come in through our website, we can put up a blurb, but if they come up through via itunes, how do we tell them our privacy policy. Having a blurb about privacy/policy for each jursidcition - maybe as part of service discovery, the spec does get into SLAs and things per request, but maybe a need for some higher level language. Also a need to set expectations about whether you’re interacting with an official jurisdiction and who they are.
  • Cliff: Also, possibly something at the service discovery level, a way to indicate a logo or other graphics and content/design that might be specific to the jurisdiction.


Notes originally taken at: