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

[dr-shorthair]

@alanruttenberg have you been able to review my proposal?

[alanruttenberg]

Not yet. I hope to take it up this week.

[alanruttenberg]

I'm waffling on the inclusion of process boundary as a feature. It can't do much harm. But I'm struggling to find an example where it would be necessary. On the other hand I might include quality. I'm thinking of e.g. hyperspectral imagery where an area might be only characterized by a signature.

Several definitions include the double quotes surrounding them. I'll use single quotes to surround things I'm quoting turtle serialization '"""x is defined by ....."""' Literal value '"x is defined by ....."' Should be: 'x is defined by .....' (no double quotes in the definition text)

Geometry: You can add axioms 'uses reference system' some 'Geospatial Reference System' The definition seems broader in referring to Euclidean space, but the scope of GeoSPARQL is Geospatial according to the spec, which I quote

'This standard supports representing and querying geospatial data on the Semantic Web. GeoSPARQL defines a vocabulary for representing geospatial data in RDF, and it defines an extension to the SPARQL query language for processing geospatial data.'

Something you probably can't fix is that the use of rdf:Property and rdfs:member in OWL 2 ontologies. That needs to be fixed in GeoSPARQL if it is to be compatible with OWL 2. This makes me question whether the bridge ontology should import geoSPARQL or leave it to the user to decide whether they need anything else. I lean towards the latter. Also, GeoSPARQL doesn't have an ontology IRI, which can cause problems importing as the ontology should be accessible at the ontology or versionIRI. (It did in the version of Protege I'm using, not loading it as an import)

You are using the Common Core namespace in your ontology URLs. Since that namespace is owned by CCO you should get permission to use it, for instance if CCO takes ownership of the bridge. Otherwise, it's impolite to mint IRIs in a namespace for which you don't control the domain.

[dr-shorthair]

I'm waffling on the inclusion of process boundary as a feature.

I don't have a strong opinion here, but the general idea is that geosparql:Feature is anything whose properties may be estimated through observation, or adjusted through actuation.

I'll remove all the double quotes.

Geometry: You can add axioms ...

The textual definition within GeoSPARQL mentions a CRS, but the formal axiomatization of geosparql:Geometry is weak (non-existent). Are you suggesting some formal axiomatization? GeoSPARQL does not have a CRS class, and within individuals the CRS reference is embedded inside the serialization, so it can't be done in GeoSPARQL. Are you suggesting pulling in the CRS reference from CCO Geospatial? Or am I missing your point?

Something you probably can't fix is that the use of rdf:Property and rdfs:member

opengeospatial/ogc-geosparql#646
GeoSPARQL v2 is under consideration.

You are using the Common Core namespace in your ontology URLs.

#763 is a PR in CCO, so use of a CCO namespace seemed appropriate if it were housed there.
Else the bridge should replace https://github.com/opengeospatial/ogc-geosparql/blob/master/alignments/bfo-alignments.ttl in which case an OGC namespace for the Ontology IRI should be used.

[alanruttenberg]

The textual definition within GeoSPARQL mentions a CRS, but the formal axiomatization of geosparql:Geometry is weak (non-existent). Are you suggesting some formal axiomatization? GeoSPARQL does not have a CRS class, and within individuals the CRS reference is embedded inside the serialization, so it can't be done in GeoSPARQL. Are you suggesting pulling in the CRS reference from CCO Geospatial? Or am I missing your point?

I am suggesting that in terms of CCO, Geometry would have the axiom

'uses reference system' some 'Geospatial Coordinate Reference System'

Where 'uses reference system` is cco:ont00001912 and 'Geospatial Coordinate Reference System' is cco:ont00000469

It would have that axiom, because it seems to be true, reading the definitions and GeoSPARQL scope.

This recommendation is strictly in the scope of a CCO bridge.

[avsculley]

@alanruttenberg Why should bfo:Processes be geo:Features?

[alanruttenberg]

@avsculley Because they are spatiotemporally located. Because they are the sort of thing that can appear on a map, which is my shortcut for what constitutes a feature in GeoSPARQL.

[avsculley]

@alanruttenberg I just don't see anything in the GeoSPARQL documentation that suggests that it is intended to model occurrents, especially using geo:Feature. I see some evidence against. In the alignments of GeoSPARQL with PROV-O and DC, for example, geo:Features are PROV/DC locations. In the alignment with BFO in the official docs, it explicitly says GeoSPARQL doesn't handle "temporality", so cannot map to occurrents (it says "continuant" but means "occurrent"). It goes on to say that "a future version of GeoSPARQL that handled spatio-temporal Features could perhaps claim that geo:Feature is a bfo:SpatiotemporalRegion."

[alanruttenberg]

@avsculley Read between the lines. GeoSPARQL is for giving and querying information on maps of Earth. While it is possible that a spatiotemporal region could be a feature perhaps, its not very interesting, just as I don't think marking out spatial regions are - usually a site is the subject of interest if we're talking immaterial 3d things.
However, seeing where the hurricane is on a map IS interesting, as would be the area in which a protest takes place.

As far as taking evidence from other mappings, I don't put much effort into following them, and I wouldn't put much stock in them, just as I didn't put stock in the initial mapping here that had Geometry being a spatial region.

explicitly says GeoSPARQL doesn't handle "temporality", so cannot map to occurrents (it says "continuant" but means "occurrent")
points in Geosparql tuples can have a time argument. It typically isn't indexed or queriable in a useful way, but I think it would be wrong to say its out of scope.

And what official docs are you talking about, and why would you trust that they were written completely coherently. The published GeoSPARL BFO mapping is inconsistent. This new one is at least not that.

And then there's their scopeNote which says says

A Feature represents a uniquely identifiable phenomenon, for example a river or an apple. While such phenomena (and therefore the Features used to represent them) are bounded, their boundaries may be crisp (e.g., the declared boundaries of a state), vague (e.g., the delineation of a valley versus its neighboring mountains), and change with time (e.g., a storm front). While discrete in nature, Features may be created from continuous observations, such as an isochrone that determines the region that can be reached by ambulance within 5 minutes. [my emphasis]

I think your claim is unambiguously wrong.

[avsculley]

@alanruttenberg The documentation I'm referring to is the official GeoSPARQL spec written by OGC. While I don't put stock in the BFO alignment, this is only because the authors clearly didn't understood BFO well enough. I think it is fair to assume that they understood their own ontology, and whether it is intended to model entities with temporality.

I don't think that scope note establishes geo:Feature was meant to model processes. (1) it establishes that geo:Feature is meant to model things whose boundaries change over time. Plenty of continuants have boundaries that change over time. So its not necessarily evidence that it was intended to model processes. (2) it establishes that geo:Feature is meant to model things that take time to come into existence. Isochrones are still continuants - perhaps they're a collection of fiat lines that come into existence over time via observation. They are still continuants. So, I don't think this part of the scope note establishes that geo:Feature is intended to model processes, either.

GeoSPARQL can model both storm fronts the change over time of its boundaries, or isochrones growing over time, without modeling occurrents. It is possible by modeling any occurrent-like-thing as a continuant (e.g., the air masses that make up the storm front, or the collection of fiat lines that make up an isochrone) and then using data properties to show that thing at different times. So, I don't think the mention of those things in the scope note establishes that geo:Feature was intended to model bfo:processes, even in the case of things like stormfronts (and hurricanes) which are probably occurrents in BFO. The difference is that BFO can put all that info about time and process at the instance level, whereas GeoSPARQL needs to use data properties to do anything with time and process.

But anyway, I don't mind either way. I just want the alignment to be as close to the intended semantics of GeoSPARQL as possible. We're here in the GeoSPARQL github. Perhaps an author on the standard can clarify this issue for us.

[dr-shorthair]

This is the CCO GitHub.

The GeoSPARQL GitHub discussion is over at opengeospatial/ogc-geosparql#645

[CarterBeauBenson]

Can someone, in as plain of English as possible, explain exactly how I would model the following scenario with the proposed change? Bonus points if you write out the triples in mock-turtle.

A water vessel passed into a restricted fishing area.

I know how I would do this and I know that it works in systems with the use of only a few data properties from GeoSPARQL, but no classes or object properties.

[cameronmore]

I think the discussion above points out exactly why GeoSPARQL is a great addition to the BFO-CCO suite, but not a replacement of its parts. At any given time, we can make some Act of Measurement or other process that creates an ICE that has the location information about where something is, but at a later time, can can take another, which will have a different ICE, such that we do not conflate the thing that is being measured from the information about the thing. Whether it's something like the changing boundary of a riverbank or a fast moving vehicle, we can handle both cases with ease due to the complexity of our ontologies.