Remove IRI hijack of GeoSPARQL 'asWKT'

[jonathanvajda]

The CCO Geospatial Ontology hijacks an IRI that is curated in another namespace.

###  http://www.opengis.net/ont/geosparql#asWKT
<http://www.opengis.net/ont/geosparql#asWKT> rdf:type owl:DatatypeProperty ;
                                             skos:scopeNote "ISO 19162:2015"@en ;
                                             rdfs:label "as WKT"@en ;
                                             skos:definition "A Data Property that has as its range a string formated according to the Well-known text standardization for geometric objects."@en ;
                                             skos:example "Polygon ((10 10, 10 20, 20 20, 20 15, 10 10))" ;
                                             cco:ont00001760 "https://www.commoncoreontologies.org/GeospatialOntology"^^xsd:anyURI .

This IRI is under continued maintenance and copyright by the Open Geospatial Consortium (OGC). Its official ontological specification is documented here:

https://defs.opengis.net/prez/catalogs/ogc-cat:datamodels/col/catalog:geosparql/it1/ns349:geosparql#asWKT

geo:asWKT
    a rdf:Property, owl:DatatypeProperty ;
    rdfs:subPropertyOf geo:hasSerialization ;
    rdfs:isDefinedBy geo: ;
    skos:prefLabel "as WKT"@en ;
    skos:definition "The WKT serialization of a Geometry."@en ;
    rdfs:domain geo:Geometry ;
    rdfs:range geo:wktLiteral ;
.

However, hijacking explicitly not best-practice in ontology development in our community. Morevoer, this specific use of intellectual property goes against the OGC's license. According to the license by the Open Geospatial Consortium (OGC):

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

Source: https://www.ogc.org/about/policies/document-license-agreement/

---

Recommended immediate fix:

• remove http://www.opengis.net/ont/geosparql#asWKT from the Geospatial ontology.
  • see pull request to this effect.
• create a SPARQL QA check for IRIs that are subjects of semantic statements but not in CCO's namespace. (ignoring dc, dcterms, skos, etc.)
  • see pull request to this effect.
• add semantic design pattern documentation, recommending reuse of 'as WKT'. E.g.:

graph TD;
    x('Operational Area'<br>IRI: cco:ont00000958) --is subject of<br>IRI: cco:ont00001801 --> y
    y('Information Content Entity'<br>IRI: cco:ont00000958) --as WKT<br>IRI: geosparql:asWKT --> z
    z('POLYGON...'^^xsd:string)

Loading

Potential additional fixes:

• consider importing GeoSPARQL ontology en toto or as a slim, with a compliant license statement that it includes an unapproved modification, etc., OR coordinate with GeoSPARQL developers about their importing CCO.
• create new datatype property that captures the semantics, but within CCO's namespace.

---

This also solves the debates over CCO's third-party use of WKT:

• Use of GeoSPARQL geometry - BFO Spatial Region vs CCO Information Content Entity question #758
• geosparql:asWKT usage (was "Make Geospatial Position a subclass of geosparql:Geometry") #760
• Alignment to BFO is seemingly not satisfiable opengeospatial/ogc-geosparql#610
• geosparql:asWKT usage in CCO #827
• Version 2.0 #539 (review)

Moreover, it resolves QA errors in CCO's assertion:

• missing rdfs:domain: <http://www.opengis.net/ont/geosparql#asWKT>
• missing rdfs:range: <http://www.opengis.net/ont/geosparql#asWKT>

If the above errors were solved by importing the original alongside CCO's as an overlay, then it would create a different QA error, namely:

• more than one skos:definition: <http://www.opengis.net/ont/geosparql#asWKT>

[dr-shorthair]

Perhaps this will help.

GeoSPARQL is currently in revision, on the schedule documented here: https://opengeospatial.github.io/ogc-geosparql/

Most significantly, the (official, though non-normative) GeoSPARQL-BFO mapping has been completely overhauled.
The mapping can be inspected

• in a tabulation in the Editor's Draft here: https://opengeospatial.github.io/ogc-geosparql/geosparql-next/spec.html#basic_formal_ontology_bfo_and_common_core_ontologies_cco
• or in an RDF (TTL) file here: https://github.com/opengeospatial/ogc-geosparql/blob/master/geosparql-next/rdf/alignments/source/bfo.ttl

This mapping provides a bridge between BFO/CCO and GeoSPARQL.
Note that geo:asWKT is a subproperty of geo:hasSerialization, which will usually appear as a property of an individual geo:Geometry, which is understood as a descriptive information content entity.

The mapping was influenced by the conversation here: #827

@nicholascar and @situx assisted.

[jonathanvajda]

Thanks. I read the threads I cited, but I didn't see anywhere that geoSPARQL would cede the IRI for asWKT to CCO to own and maintain. I don't take this to be the case, and so the hijack would still be a concern.

[dr-shorthair]

There is no suggestion that CCO should own and maintain anything from GeoSPARQL.
GeoSPARQL is owned and maintained by OGC, together with ISO/TC 211 through its longstanding collaboration with OGC.

There is also no problem with users of CCO also using GeoSPARQL in the same graphs.
That is the nature of OWL, RDF, and IRIs.

My efforts in developing this bridging resource are precisely to allow everyone to 'stay in their lane', while providing a resource to allow them to maximise the use of ontology resources across governance boundaries.
My comment here is to draw attention to the existence of the bridge.
I believe this complements your proposal in #947 to remove direct reference to GeoSPARQL resources in CCO.

Of course, anyone is at liberty to attach any other axioms to any other resources denoted by IRIs, in their own documents.
This is allowed for under the basic assumptions around OWL.
But you obviously wear the consequences and risks of introducing inconsistencies.

BFO/CCO currently makes use of terms from several external, pre-existing ontologies and vocabularies, starting naturally with OWL, RDF, RDFS, but also SKOS from the W3C ecosystem, and Dublin Core from elsewhere, primarily for annotations.

The BFO/CCO community is understandably cautious in introducing dependencies on external ontologies where stronger axiomatization might compromise consistency.
However, that does mean that you might find yourselves reproducing work done elsewhere, sometimes with a weaker underlying familiarity with specialized concepts and practices.
GeoSPARQL is an obvious case where there is an existing effort standardizing community practice as an OWL ontology, with the involvement and consent of that community.