GeoSpatial vocabularies

Having been involved with a number of conversations recently, and being 
aware of many more, I am proposing a new Community Group around 
vocabularies for describing locations.

See http://www.w3.org/community/groups/proposed/#locadd

Background
==========
This is hardly a new idea and the last thing I want to do is to fall 
into the XKCD trap [1]. Nevertheless, we have different organisations 
having similar but separate conversations at the moment, mostly born of 
different use cases and perspectives. This is normal but I think some 
sort of coordination could be beneficial.

GeoSPARQL
=========
The OGC has completed work on GeoSPARQL [2]. This is favoured by the 
likes of (UK mapping agency) Ordnance Survey and has been produced 
primarily by geospatial experts with an interest in linked data.

NeoGeo
======
A community effort has produced NeoGeo [3]. This is favoured by the 
likes of (French mapping agency) IGN and has been produced primarily by 
linked data experts with an interest in geospatial data.

The primary difference between GeoSPARQL and NeoGeo is in the way they 
handle point, line and polygon literals. Both enjoy significant support 
and implementation experience.


INSPIRE
=======
Is a European Commission Directive that legally obliges the Member 
States of the European Union to publish environmental and geospatial 
data using a common set of standards which are under various stages of 
development [4].


ISA Programme Location Core Vocabulary
======================================
Produced by a working group chaired by the team responsible for the 
development of INSPIRE under the auspices of a different part of the 
European Commission, this very lightweight vocabulary includes 
properties and classes for describing locations and for recording 
addresses in a manner conformant with INSPIRE - a feature not shared by 
vCARD for example. Now a work item of the W3C Government Linked Data WG 
[5], the vocabulary needs further community review and refinement [6].


schema.org
==========
Includes basic classes and properties for locations including:
- addresses (a clone of vCard) http://schema.org/PostalAddress
- lat/long (a clone of WGS84) http://schema.org/GeoCoordinates
- geoShape (including boc, circle, line & polygon) 
http://schema.org/GeoShape

It inherits things like name, URL and description from schema.org/Thing 
which are at least analogous to things like Geographic Names and 
Geographic Identifiers.

schema.org includes containedIn but not, AFAICT, borders etc. The 
schema.org location properties seem closely linked with event 
vocabulary. Classes include Mountain, Body of Water, Continent etc.

The current list of proposed extensions to schema.org [7] does not 
include anything in this space and there is no (visibly active) 
discussion associated with schema.org and location.


W3C Point of Interest
=====================
I'm sorry to say that the Points of Interest WG [8] seems to have hit 
the buffers so that the March 2012 draft [9] looks like being as far as 
it gets. This just at a time when more and more data is being published, 
a lot of it related to locations and, well, points of interest. The 
ideas behind the POI WG remain as important as ever but it seems that a 
new focus is necessary if that work is to be leveraged effectively.


Standards bodies
================
OGC and W3C are both willing to help if required but what actually *is* 
required? That's what the proposed community group is to find out. When 
we know that, we can look at where any work should be done. Like any 
membership organisation, both W3C and OGC put the wishes of their 
members first. Both bodies are very willing to work together.


Possible outcomes
=================
One possible outcome is a standard that is backwards compatible with 
GeoSPARQL and NeoGeo and that combines aspects of both. The danger there 
is that this would lead to an over-complex standard that could never be 
fully implemented - which is about as big a pointless waste of time as 
can be imagined. However, the two are close and common ground shouldn't 
be hard to find.

At the other extreme is that everyone carries on in in their own way 
and, well, people can pick and choose. This seems less than ideal to me. 
If interoperability between data sets is important then we need to make 
some effort to coordinate.

The gaps seem to be around linked-data friendly INSPIRE standards, 
particularly wrt addresses, and in handling geometry literals that can 
be huge (no one is talking about yet another way to define points lines 
and polygons btw!).

What I hope the proposed group could achieve is:

- consensus on the use cases/gaps that need be filled;
- at least a rough solution that takes full account of the existing work 
highlighted here.

If that can be done, the GLD WG's charter would allow it to take this 
through the W3C Recommendations Track, assuming the continued support 
and interest of the community. The WG itself does not have the resources 
and geospatial expertise to see this through on its own.

If this interests you, do please join the Community Group at 
http://www.w3.org/community/groups/proposed/#locadd and post your ideas.

Thank you

Phil.



[1] http://xkcd.com/927/
[2] http://www.opengeospatial.org/standards/geosparql
[3] http://geovocab.org/doc/neogeo/
[4] http://inspire.ec.europa.eu/index.cfm/pageid/2
[5] http://www.w3.org/2011/gld/
[6] http://philarcher.org/isa/locn-v1.00.html although officially I 
should point you to http://joinup.ec.europa.eu/asset/core_location/home
[7] http://www.w3.org/wiki/WebSchemas/SchemaDotOrgProposals
[8] http://www.w3.org/2010/POI/
[9] http://www.w3.org/2010/POI/documents/Core/core-20111216.html


-- 


Phil Archer
W3C eGovernment
http://www.w3.org/egov/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Monday, 6 August 2012 12:46:53 UTC