This is my response to The London Assembly Health and Public Services Committee‘s consultation on an open data standard for information about public toilets [Googe Docs link]. Try not to giggle at the back — this is good stuff, and of great usefulness: imagine a mobile app which can tell you where the nearest open public toilet is, in the evening; or the nearest with ease of access, if you’re a wheelchair user; or the nearest which is free, if you have no change. And no, I don’t live in London, but this standard should be usable everywhere, in the UK or overseas.
- Name of building / park / location
- Use vCard properties (“street-address”, “locality”, “region”, “country-name”) .
- Use vCard “postal-code” property. Do not restirct to the 8-character UK standard, without checking that this will work for overseas postcodes.
- Unique identifier
- Should be a URI; or at least be capable of being resolved to one.
- Latitude/ Longitude
- Specify that these are in WGS84, as used by vCard and common mapping services (other, incompatible, coordinate schema exists).
- Easting/ Northing
- Redundant (or computable) if coordinates used. Not available in vCard. If both are allowed, need to specify which has precedence in case of inconsistency.
- Use vCard “agent” property, including postal address properties. Alternatively, have a singe URI to a separate vCard record for the owner.
- Gender, children, RADAR, other multi-choice properties
- Use the vCard “category” property, which is plural, with an agreed vocabulary, where absence means no; alternatively have the vocabulary include negative values, and assume absence to mean “not known”.
- Is it inside a shop / café / pub?
- Use the vCard “category” property, with an agreed vocabulary, applied to the owner.
- Opening hours
- Use the proposed model, inside the vCard “note” property. Watch for emerging “opening hours” schema elsewhere.
And move all free-text options to the vCard “note” property, which is plural, using a prefix to distinguish them.
If the use of vCard is not possible, I would still mirror vCard properties and property-names as closely as possible, especially for addresses, in order to ensure ease of interoperability.
I am happy to elaborate on these points if that would be helpful.
Disclosure: I’m a contributor to the v4 vCard revisions.
Update: At the request of staff from The London Assembly, I’ve updated their Google Doc (linked above), mapping fields to the vCard standard.