Although a large amount of spatial data has been published on the Web, so far there are few authoritative datasets containing geometrical descriptions of their boundaries. Their number is growing (e.g. at the time of writing there are three authoritative spatial datasets publicly available as linked data in the Netherlands containing topographic, cadastral, and address data), but currently there is no common practice in the sense of the same spatial vocabulary being used by most spatial data publishers. Direct georeferencing of data implies representing coordinates or geometries and associating them to a CRS. This requires vocabularies for geometries and CRSs. The consequence is the lack of a baseline during the mapping process for application developers trying to consume specific incoming data. Datasets describing administrative units, points of interest or postal addresses with their labels and geometries, and identifying these Spatial Things with URIs could be beneficial not only for georeferencing other datasets, but also for interlinking datasets georeferenced by direct and indirect location information.
-Currently, no single standardized vocabulary is available that covers all needs. Version 1.0 of the [[GeoSPARQL]] vocabulary is too limited to provide a good basis, but work to update the [[GeoSPARQL]] spatial ontology is underway. The first iteration of this update includes the addition of common classes for spatial object collections, and common properties for spatial object size, centroid, bounding box, etc. A companion CRS ontology is also on the way. This work will provide an agreed spatial ontology, i.e. a bridge or common ground between geographical and non-geographical spatial data and between W3C and OGC standards; conformant to the [[ISO-19107]] abstract model and aligned to existing available ontologies such as [[GeoSPARQL]] 1.0, the [[W3C-BASIC-GEO]] vocabulary, [[NeoGeo]] and the ISA Programme Location Core Vocabulary [[LOCN]].
+Currently, no single standardized vocabulary is available that covers all needs. Version 1.0 of the [[GeoSPARQL]] vocabulary is too limited to provide a good basis, but work to update the [[GeoSPARQL]] spatial ontology is underway. The first iteration of this update includes the addition of common classes for spatial object collections, and common properties for spatial object size, centroid, bounding box, etc. A companion CRS ontology is also on the way. This work will provide an agreed spatial ontology, i.e. a bridge or common ground between geographical and non-geographical spatial data and between W3C and OGC standards; conformant to the [[ISO-19107]] abstract model and aligned to existing available ontologies such as [[GeoSPARQL]] 1.0, the [[W3C-BASIC-GEO]] vocabulary, [[NeoGeo]] and the ISA Programme Location Core Vocabulary [[LOCN]]. Still, as GeoSPARQL 1.1 Annex E describes, at least 15 different vocabularies to encode geometries on the web exist. While this annex provides a much needed way to relate and interlink data in these different vocabularies, the adoption of an improved GeoSPARQL vocabulary will take a significant amount of time.
The ideal vocabulary would define basic semantics for the concept of a reference system for spatial coordinates, a basic datatype, or basic datatypes for geometry, how geometry and real world objects are related and how different versions of geometries for a single real world object can be distinguished. For example, it makes sense to publish different geometric representations of a spatial object that can be used for different purposes. The same object could be modelled as a point, a 2D polygon or a 3D polygon. The polygons could have different versions with different resolutions (generalization levels). And all those different geometries could be published with different coordinate reference systems. Thus, the vocabulary would provide a foundation for harmonization of the many different geometry encodings that exist today.
- +Finally, a spatial data vocabulary would need to be validatable. For Semantic Web Standards, this is usually achieved by defining SHACL shapes which can validate the graph structure defined by the spatial vocabulary and its valid datatypes. For a complete validation, also the contents of geometry literals need to be considered, which is at the time of writing not possible using SHACL alone and requires the usage of GIS software libraries.
+