From a2363dccf26389689b57e3f14a1121de028a47fc Mon Sep 17 00:00:00 2001 From: Timo Date: Tue, 10 Jan 2023 19:09:40 +0100 Subject: [PATCH 1/2] GeoSPARQL Compliance, SHACL Shapes, OGC API Features Compability --- bp/index.html | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/bp/index.html b/bp/index.html index 34b9aa64..a2f5cb6b 100644 --- a/bp/index.html +++ b/bp/index.html @@ -4456,9 +4456,11 @@

Requesting different representations of geometries

Spatial data vocabulary

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.

- +

In addition, the spatial data vocabulary should be able to be integrated with spatial webservices such as the OGC API Features family. OGC API Features could act as a frontend to spatial data encoded in the GeoSPARQL standard and might use a conversion of CQL functions to GeoSPARQL queries to access Features and FeatureCollections stored in a SPARQL endpoint. To that end, GeoSPARQL 1.1 Annex F provides mappings between the two query languages, which allow operating OGC API Features services to expose FeatureCollections exposed in common geometry formats querying spatial data using OGC API Features functions in CQL should be mapped to GeoSPARQL query functions of the same type.

+

Finally, compliance tests and possibly certifications and spatial data implementations based on spatial data vocabularies such as GeoSPARQL will need to be developed and adopted to help organizations and users with the specification of correctly structured knowledge graphs. The GeoSPARQL Compliance Benchmark provides a first means of compliance testing for GeoSPARQL triple stores and the newly defined GeoSPARQL 1.1 SHACL shapes will make validation of spatial data graphs easier to accomplish.

+

Describing dataset structure and service behaviors

From 52acdd9db29de5f3f2a7fa5f8072627372eb6d8c Mon Sep 17 00:00:00 2001 From: Timo Date: Tue, 31 Jan 2023 14:42:31 +0100 Subject: [PATCH 2/2] Removed parts about validation and compliance benchmarking --- bp/index.html | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/bp/index.html b/bp/index.html index a2f5cb6b..16af8a65 100644 --- a/bp/index.html +++ b/bp/index.html @@ -4458,8 +4458,7 @@

Spatial data vocabulary

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]]. 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.

-

In addition, the spatial data vocabulary should be able to be integrated with spatial webservices such as the OGC API Features family. OGC API Features could act as a frontend to spatial data encoded in the GeoSPARQL standard and might use a conversion of CQL functions to GeoSPARQL queries to access Features and FeatureCollections stored in a SPARQL endpoint. To that end, GeoSPARQL 1.1 Annex F provides mappings between the two query languages, which allow operating OGC API Features services to expose FeatureCollections exposed in common geometry formats querying spatial data using OGC API Features functions in CQL should be mapped to GeoSPARQL query functions of the same type.

-

Finally, compliance tests and possibly certifications and spatial data implementations based on spatial data vocabularies such as GeoSPARQL will need to be developed and adopted to help organizations and users with the specification of correctly structured knowledge graphs. The GeoSPARQL Compliance Benchmark provides a first means of compliance testing for GeoSPARQL triple stores and the newly defined GeoSPARQL 1.1 SHACL shapes will make validation of spatial data graphs easier to accomplish.

+

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.