There have been several recent efforts to standardize vocabularies for describing locations, using existing geometry specifications. GeoSPARQL, NeoGeo and the EU ISA Programme's Location Core Vocabulary join schema.org's vocabulary and more. Is there a set of use cases that an usefully be served by greater collaboration in this space? What problems remain? Where are the awkward edges that need to be knocked into shape?
The mission of the Location and Addresses Community Group is to review the existing efforts in this space (notably GeoSPARQL, NeoGeo, the EU's INSPIRE Directive and schema.org) and assess whether any use cases would be served by harmonization and/or new standardization work.
This group may produce specifications or use cases and requirements documents, which may be proposed for adoption by the Government Linked Data (GLD) Working Group consistent with its charter (http://www.w3.org/2011/gld/charter).
I have just joined this group (it took some time to get through the subscription process). I hope the group will come to life soon, I think its subject is both interesting and important.
Here is one thing that I think would be good to share our thoughts on: the method of specification of the Coordinate Reference System (CRS), also known as the Spatial Reference System (SRS), in spatial Linked Data. I have been following and commenting on the GeoSPARQL specification, and this is one thing that I think I wish would have been different: In GeoSPARQL The CRS can be indicated by a URI (which is good), but that URI is concatenated with the coordinates in the literal that describes the geometry. I think it would have been much nicer if the CRS could be published as a separate triple. For one thing, it would allow consumers of data to use the CRS as a filter in SPARQL queries.
I wonder what the other group members think of this issue.
In addition to GeoSPARQL, NeoGeo, INSPIRE, ISA Programme Location Core Vocabulary, schema.org and W3C Point of Interest, there is ADMS. This can describe a Community data Repository and its contents (Assets). Those Repositories have Assets@Location, and, for example, if Federal, State, Local, and Municipal Governments run the Repositories then they can be specified by the existing coding system.
For example, US Federal Information Processing Standards (FIPS) are a cascade system, but you can make Domains from the same codes. If you embed ADMS at the proper level, you create a Repository for that level with fixed metadata for the location.
I made an example of the “Tarrant County Texas Data Repository”.
Data : http://www.rustprivacy.org/2012/roadmap/locadd/em-adms1.txt
In XML with client-side XSLT (view the source to see the XML):
XML : http://www.rustprivacy.org/2012/roadmap/locadd/em-adms1.xml
It validates (http://www.rustprivacy.org/2012/roadmap/locadd/em-adms-trace.txt), although ADMS 0.8 was too big to put on my server.
Using the “Local Repository” as a proxy location, you can get Weather Forecasts and Reports, Water Quality Data, and all sorts of handy stuff. The main problem is the sheer number of Domain Identifiers – FIPS has about 40,000. The EU has 27 members, but that’s easy – just put an EU wrapper over the cascade (or FIFA, or G-20, or …)