Removed parts about validation and compliance benchmarking

bp/index.html

@@ -4458,8 +4458,7 @@ <h3>Spatial data vocabulary</h3>
         <p>Although a large amount of <a>spatial data</a> 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 <a>linked data</a> 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 <a>geometries</a> and associating them to a <a>CRS</a>. 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 <a>Spatial Things</a> with URIs could be beneficial not only for georeferencing other datasets, but also for interlinking datasets georeferenced by direct and indirect location information. </p>
         <p>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 <a>spatial data</a> 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.</p>
         <p>The ideal vocabulary would define basic semantics for the concept of a reference system for spatial coordinates, a basic datatype, or basic datatypes for <a>geometry</a>, how geometry and real world objects are related and how different versions of <a>geometries</a> 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 <a>coordinate reference systems</a>. Thus, the vocabulary would provide a foundation for harmonization of the many different geometry encodings that exist today.</p>
-	<p>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.</p> 
-	<p>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 <a href="https://doi.org/10.3390/ijgi10070487">GeoSPARQL Compliance Benchmark</a> 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.</p>  
+	<p>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.</p>
 
       </section>
       <section>