geosparql:asWKT usage (was "Make Geospatial Position a subclass of geosparql:Geometry")

[dr-shorthair]

Line 189 of the GeospatialOntology module (TTL serialization) adds geosparql:asWKT.
But there are no axioms bringing it into use in the context of any of the CCO GeospatialOntology classes.

Meanwhile, over in GeoSPARQL the axiomaization of geosparql:asWKT links it directly to the class geosparql:Geometry:

geosparql:asWKT
	a rdf:Property, owl:DatatypeProperty ;
	rdfs:subPropertyOf geosparql:hasSerialization ;
	rdfs:domain geosparql:Geometry ;
	rdfs:range geosparql:wktLiteral ;
.

The global domain constraint means that any use of geosparql:asWKT entails that the subject is a geosparql:Geometry.
For consistency, I suggest that the following subclass axiom should be introduced on cco:ont00000373 (Geospatial Position):

<http://www.ontologyrepository.com/CommonCoreOntologies/ont00000373> 
    rdfs:label "Geospatial Position"@en ;
    rdfs:subClassOf <http://www.opengis.net/ont/geosparql#Geometry> ; 
    rdfs:comment "When coordinates are provided using a Literal this *must* be a POINT" ;
    .

[alanruttenberg]

Geometry should not be a subclass of Geospatial position, for two reasons.

1. Per Use of GeoSPARQL geometry - BFO Spatial Region vs CCO Information Content Entity question #758 (comment) Geometry is an information content entity.

2. Also, Geospatial position is a fiat point and not all geometries are points

[dr-shorthair]

My suggestion for sub-classing was the other way round.
Position is a kind of geometry (not geometry is a kind of position).

I've looked a bit harder at the core GeoSPARQL structure and I can now understand your proposition that geosparql:Geometry is a generically dependent continuant. If we take this path, then I suggest that BFO site, spatial region, and continuant fiat boundary could be understood to be sub-classes of geosparql:Feature. It has the property geosparql:hasGeometry, which chains through to geosparql:hasSerialization, which has the sub-property geosparql:awWKT etc.

So if it is desired that the CCO GeospatialOntology module use geosparql:hasWKT (which is ultimately what triggered this issue) then the following axioms should be added in CCO:

<http://purl.obolibrary.org/obo/BFO_0000141> 
    rdfs:label "immaterial entity"@en ;
    rdfs:subClassOf <http://www.opengis.net/ont/geosparql#Feature> ; 
    rdfs:comment "a geosparql:Feature has an association with a geosparql:Geometry through the object-property geosparql:hasGeometry" ;
    .

<http://www.opengis.net/ont/geosparql#Geometry>
    rdfs:subClassOf <https://www.commoncoreontologies.org/ont00000958> ;
    rdfs:comment "geosparql:Geometry is a kind of Information Content Entity" ;
    . 

(This is in place of the original proposal which only related to Geospatial Position.)

I am aware, however, that geosparql:Feature does not fit generally into the BFO hierarchy, in particular since I think that some material entities and some occurrents would be modelled as geosparql:Features as well.

[alanruttenberg]

My suggestion for sub-classing was the other way round.
Position is a kind of geometry (not geometry is a kind of position).

My mistake, sorry.

Regarding Feature, I'm not keen on adding it to CCO proper because it lands hurting the relatively clean hierarchy - as you say

geosparql:Feature does not fit simply into the BFO hierarchy

But if added, the least disruptive thing would be to make it a defined class at root level, possibly in a separate bridge file
Feature equivalentTo ObjectUnionOf(independent continuant, process, process boundary)
This would let the reasoner place it where you want it (mostly), but not mess up the otherwise clean single asserted hierarchy.

We could add hasGeometry domain Feature, range Geometry and add asWKT and friends as a data properties domain Geometry, and make hasGeometry a subproperty of 'is subject of'

[dr-shorthair]

I prepared a potential bridge ontology that ties GeoSPARQL into BFO/CCO, thus allowing for use of GeoSPARQL geometry serializations in a compatible manner.

See draft PR #763