Further development of GeoSPARQL

This page is for collecting ideas on how GeoSPARQL can be further developed to arrive at the 'agreed spatial ontology' mentioned in the charter.

Why update GeoSPARQL 1.0 ?

1. It's too complicated -- there are good use cases for simple geometry properties as in GeoRSS2007
2. It's too simple -- could be extended with more expressive properties and geometry types
3. It's too diverse -- would be nice to write queries just involving features and not "mess" with geometries if desired, rather than needing both semantic and geospatial expertise for every use.

Future work described in GeoSPARQL 1.0

Chapter 12 of the GeoSPARQL standard document lists foreseen future work:

"Many future extensions of this standard are possible. Obvious extensions are to define new conformance classes for other standard serializations of geometry data (e.g. KML, GeoJSON). In addition, significant work remains in developing vocabularies for spatial data, and expanding the GeoSPARQL vocabularies with OWL axioms to aid in logical spatial reasoning would be a valuable contribution. There are also large amounts of existing feature data represented either in a GML file (or similar serialization) or in a datastore supporting the general feature model. It would be beneficial to develop standard processes for converting (or virtually converting and exposing) this data to RDF"

Note that it is straightforward to convert most GML into RDF (GML v1 even had a RDF implementation!). See this paper Linked Data in SDI or How GML is not about Trees.

Ontology in development

A further development of the GeoSPARQL ontology is shared on here on WebProtégé. Comments are welcome.

Options for improvement

An unordered list of options for further development of GeoSPARQL:

Add more geometry serializations/data types

For example:

1. GeoJSON
2. NeoGeo
3. SVG
4. KML
5. GeoShape (schema.org)
6. Geohash
7. the Geo URI scheme
8. GeoRSS

This will be helpful for data consumers, allowing them to request their preferred data type.

Negotiate geometry serializations

One can use GeoSPARQL to request a particular serialization (e.g. asGML). These could conceivably be virtual serializations that are generated on demand. Each of the literals is a custom RDF datatype (WKTLiteral, etc.), however there does not seem to be a mechanism for defining, requesting, or negotiating alternative RDF datatypes, either in SPARQL or in HTTP.

HTTP content negotiation is successfully carried out for different overall RDF serializations (e.g. application/rdf+ttl , application/rdf+xml, etc.). One fairly clean option would be to define a custom content-type parameter, e.g. application/rdf+ttl; geomliteral="wkt" to use in content negotiation.

Add semantic foundations

For example:

1. Definition of geometry

SDWGEO: SpatialThing equivalent to ISO 19109 GF_Feature

1. Definition of a spatial thing/feature

SDWGEO: Geometry equivalent to ISO 19107 GM_Object

1. Definition of CRS

This will be helpful for reasoning, for extending the GeoSPARQL ontology, and for matching GeoSPARQL with other vocabularies.

Add geometry descriptors

For example:

1. CRS (e.g. the distinction between flat plane and spherical coordinates is important) --already in GeoSPARQL
2. Number of dimensions (1, 2, 3) -- already in GeoSPARQL
3. Level of detail - "resolution" property in GeoSPARQL
4. Model type (minimal bounding box, centroid, convex hull, concave hull, etc.) -- not inherent to a geometry, but can go in the geometry property
5. Geometry type (point, line, polygon, multipolygon, etc.) - subclasses of geometry
6. Axis order (actually a part of the CRS specification, but deviations from the CRS specification in this respect exist in practice) -- prefer better CRS choices

This will be helpful for data consumers, allowing them to efficiently filter geometric data based on usage requirements, or to understand the nature of a geometry when a geometry is encountered.

Descriptors like these could be useful at the dataset level too.

Add more spatial functions

GeoSPARQL already includes:

1. relate
2. distance,
3. buffer
4. convex hull
5. intersection
6. union
7. difference
8. symmetric difference
9. envelope
10. boundary

Other possibilities:

1. Area
2. Nearest neighbour
3. Generalization
4. Centroid
5. Bounding box

This allows consumers to do more with spatial data, although the functions are not strictly part of an ontology but rather extensions to SPARQL. Functions may also allow geometric relations to imply feature relations and the inverse, although this may also be possible with property chains. Perhaps it is also helpful to define general classes of functions that can be extended?

Add semantic geometric properties

1. SDWGEO:

• hasGeometry
  • defaultGeometry
  • hasArea
  • hasBoundary
  • hasCenterline
  • hasCentroid
  • hasEnvelope
  • hasGrid
  • hasPosition
  • hasSurface
  • hasVolume

Add simple dimensional extents

Just enough of a spatial model to enable qualitative feature relationships such as "within" or "along" SDWGEO:

• hasExtent (Position, Path, Area, Volume)

Add simple geometric properties

Equivalent to more complex properties with defaults (e.g. CRS = CRS84). For example (after GeoRSS Simple): point(-172.34,41.23)

1. SDWGEO:

• simpleGeometry
  • box
  • line
  • point
  • polygon

Priority

Of the options described above, adding semantic foundations seems to have the highest priority. Especially having a definition of geometry could pave the way for other improvements. For example, a geometry is a core element in a CRS specification. And the concept of geometry must be defined in order to try to provide geometry descriptors.

Definition of Geometry, Feature and SpatialObject

This is how geometry is currently defined in GeoSPARQL:

 <owl:Class rdf:ID="Geometry">
   <dc:date rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2011-06-16</dc:date>
   <skos:definition xml:lang="en">
     The class represents the top-level geometry type. This class is 
     equivalent to the UML class GM_Object defined in ISO 19107, and 
     it is superclass of all geometry types.
   </skos:definition>
   <rdfs:label xml:lang="en">Geometry</rdfs:label>
   <owl:disjointWith>
     <owl:Class rdf:ID="Feature"/>
   </owl:disjointWith>
   <skos:prefLabel xml:lang="en">Geometry</skos:prefLabel>
   <dc:creator>OGC GeoSPARQL 1.0 Standard Working Group</dc:creator>
   <rdfs:subClassOf rdf:resource="#SpatialObject"/>
   <rdfs:isDefinedBy rdf:resource="http://www.opengis.net/spec/geosparql/1.0"/>
   <rdfs:isDefinedBy rdf:resource=""/>
   <dc:contributor>Matthew Perry</dc:contributor>
   <rdfs:comment xml:lang="en">
     The class represents the top-level geometry type. This class is 
     equivalent to the UML class GM_Object defined in ISO 19107, and 
     it is superclass of all geometry types.
   </rdfs:comment>
   <dc:description xml:lang="en">
     The class represents the top-level geometry type. This class is 
     equivalent to the UML class GM_Object defined in ISO 19107, and 
     it is superclass of all geometry types.
   </dc:description>
 </owl:Class>

Following, the GeoSPARQL definition of feature (defined as disjoint from geometry), and of spatial object (superclass of both feature and geometry):

 <owl:Class rdf:about="#Feature">
   <skos:prefLabel xml:lang="en">Feature</skos:prefLabel>
   <dc:description xml:lang="en">
     This class represents the top-level feature type. This class is 
     equivalent to GFI_Feature defined in ISO 19156:2011, and it is 
     superclass of all feature types.
   </dc:description>
   <rdfs:isDefinedBy rdf:resource=""/>
   <dc:contributor>Matthew Perry</dc:contributor>
   <rdfs:isDefinedBy rdf:resource="http://www.opengis.net/spec/geosparql/1.0"/>
   <rdfs:label xml:lang="en">Feature</rdfs:label>
   <rdfs:comment xml:lang="en">
     This class represents the top-level feature type. This class is 
     equivalent to GFI_Feature defined in ISO 19156:2011, and it is 
     superclass of all feature types.
   </rdfs:comment>
   <owl:disjointWith rdf:resource="#Geometry"/>
   <dc:creator>OGC GeoSPARQL 1.0 Standard Working Group</dc:creator>
   <skos:definition xml:lang="en">
     This class represents the top-level feature type. This class is 
     equivalent to GFI_Feature defined in ISO 19156:2011, and it is 
     superclass of all feature types.
   </skos:definition>
   <rdfs:subClassOf rdf:resource="#SpatialObject"/>
   <dc:date rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2011-06-16</dc:date>
 </owl:Class>

 <owl:Class rdf:ID="SpatialObject">
   <dc:date rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2011-06-16</dc:date>
   <dc:creator>OGC GeoSPARQL 1.0 Standard Working Group</dc:creator>
   <dc:description xml:lang="en">
     The class spatial-object represents everything that can have 
     a spatial representation. It is superclass of feature and geometry.
   </dc:description>
   <rdfs:isDefinedBy rdf:resource="http://www.opengis.net/spec/geosparql/1.0"/>
   <skos:prefLabel xml:lang="en">SpatialObject</skos:prefLabel>
   <skos:definition xml:lang="en">
     The class spatial-object represents everything that can have 
     a spatial representation. It is superclass of feature and geometry.
   </skos:definition>
   <rdfs:label xml:lang="en">SpatialObject</rdfs:label>
   <dc:contributor>Matthew Perry</dc:contributor>
   <rdfs:isDefinedBy rdf:resource=""/>
   <rdfs:comment xml:lang="en">
     The class spatial-object represents everything that can have 
     a spatial representation. It is superclass of feature and geometry.
   </rdfs:comment>
 </owl:Class>

Relevant standards

One of the goals of updating GeoSPARQL is to make it better rooted in existing standards from both the OGC and W3C domain, to improve interoperability and extensibility and to avoid misinterpretation. The following standards can be considered relevant for future work on GeoSPARQL:

1. ISO 19150-1 (Ontology - Part 1: Framework)
2. ISO 19150-2 (Ontology - Part 2: Rules for developing ontologies in the Web Ontology Language (OWL))
3. ISO 19107 (Spatial schema)
4. ISO 19109 (Rules for application schema)
5. ISO 19111 (Spatial referencing by coordinates) / OGC 08-015r2
6. ISO 19125-1 (Simple Feature Access - Part 1: Common Architecture) / OGC 06-103r4
7. SIO 19156 (Observations and measurements) / OGC 10-004r3
8. W3C Basic Geo (WGS84 lat/long) Vocabulary
9. W3C GeoRSS Model and Ontology
10. the NeoGeo Vocabulary
11. ISA Programme Location Core Vocabulary
12. Ontologie des primitives géométriques

Some ISO standards are not freely available, but all models are available at http://www.isotc211.org/hmmg/HTML as UML class diagrams. A definition of terms in multiple languages in also available from ISO/TC211. A preliminary Linked Data representation of that glossary is made available by CSIRO.