- 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 ex-Dc.gov/OCTO 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.
Review process of continued development of GeoReport v2 spec. Went over the proposal outlined at http://lists.open311.org/groups/discuss/messages/topic/6QwZRga9MPbkYOCqCYh9sU
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: http://lists.open311.org/groups/discuss/messages/topic/1Yj3jSrYVYjZYuAgpvpGxx
- 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
- 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: http://wiki.open311.org/Inquiry_v2_Draft
Inventory of Products/Services
Please add yours: http://wiki.open311.org/GeoReport_v2/Support
- 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: https://github.com/mashery/iodocs
- 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 http://hurl.it - easy way to test APIs online so you don’t have to know too much about it. Has inspired twitter API interfaces, eg twurl.
- 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: http://etherplans.org/open311-2011-09