Alignment with BFO (was: Definition of :Geometry)

[dr-shorthair]

Is geosparql:Geometry a region of space, or is it a set of coordinates that defines a region of space?

I am attempting to reconcile GeoSPARQL with the Comon Core Ontologies GeospatialOntology module.
See the issue I have raised over there: CommonCoreOntology/CommonCoreOntologies#758

Common Core Ontologies are a set of 'mid-level ontologies' in the BFO/OBO family.
They are significant because they are required to be used by parts of the US Government.
The CCO GeospatialOntology has a mixture of concepts, some of which overlap with the scope of various OGC standards.
It mentions :asWKT but this is pretty much isolated, and I'm trying to figure out how to relate GeoSPARQL more formally.

A key distinction within the class hierarchy of BFO is between

• 'independent continuant' which has subclasses spatial region & continuant fiat boundary (in BFO), and
• 'generically dependent continuant` which has a subclass information content entity (in CCO)

A generically dependent continuant exists in relation to some independent continuant(s), providing descriptive information about it (them).

So the primary question is: can a :Geometry exist without thing(s) (e.g. :Feature) that it provides the geometry for?
Also: may one :Geometry have multiple serializations (e.g. WKT and DGGS)?

If yes to either of these, then - as @alanruttenberg points out here - the current textual definition of :Geometry is misleading, in particular as it refers to the direct positions that delimit the Geometry, rather than to the Geometry purely as a region of space. (He makes additional comments on the mention of the SRS and the adjective 'coherent'.)

As you will see from my (perhaps overlong) comment that opens the CCO GitHub issue, I had always assumed that :Geometry was the region of space, and the coordinates were merely a (perhaps imperfect) description of it. In BFO terms I had :Geometry aligned with 'spatial region', with the serialization being an 'information content entity' that describes it. If only one serialization is permitted, then clearly the coordinates are the geometry, and I'm maybe barking up the wrong tree.

[alanruttenberg]

the primary question is: can a :Geometry exist without thing(s) (e.g. :Feature) that it provides the geometry for?
Also: may one :Geometry have multiple serializations (e.g. WKT and DGGS)?

This is not the question, as the dependency that is meant for generic continuants is to the material medium which bears a concretization of a GDC. As soon as you have written it down, you have satisfied that criteria.

A relevant question pertaining to information content entities is whether a Geometries is about something. Which they are.

[dr-shorthair]

Thanks @alanruttenberg I'm coming around to your explanation (see CommonCoreOntology/CommonCoreOntologies#760).

This discussion and your comments at CommonCoreOntology/CommonCoreOntologies#758 do imply the need to examine the definition and perhaps axiomatization of :Geometry.

First, I'm thinking about the scenario where we have multiple alternative descriptions of the geometry of a feature, say as WKT and DGGS. Is this through

1. repeated :hasGeometry properties on the Feature, or
2. repeated :hasSerialization properties on its Geometry.

The former is supported by the second sentence in section 8.4.1 of GeoSPARQL 1.1 "A given Feature may have many associated geometries." and is also implied by the need for a :hasDefaultGeometry property.

The definition of :hasSerialization in section 10.7.10 is "The property geo:hasSerialization is defined to connect a Geometry with its text-based serialization (e.g., its WKT serialization)." The word "its" perhaps implies that there is exactly one serialization per Geometry, but this should be made explicit. It could be expressed axiomatically with a cardinality constraint, though I think that takes the OWL profile outside DL (?). And the text should be updated to indicate that only one serialization is permitted. This understanding also means that the other properties (resolution, accuracy) are clearly related to only this representation.

The textual definition of :Geometry: in section 10.6.1 is "A coherent set of direct positions in space. The positions are held within a Spatial Reference System (SRS)". I think this was inspired by ISO 19107:2003 (emphasis added)

6.2.2 GM_Object
6.2.2.1
GM_Object (Figure 6) is the root class of the geometric object taxonomy and supports interfaces common to
all geographically referenced geometric objects. GM_Object instances are sets of direct positions in a
particular coordinate reference system. A GM_Object can be regarded as an infinite set of points that satisfies
the set operation interfaces for a set of direct positions, TransfiniteSet. Since an infinite
collection class cannot be implemented directly, a Boolean test for inclusion shall be provided by the
GM_Object interface. This International Standard concentrates on vector geometry classes, but future work
may use GM_Object as a root class without modification.

The term "coherent" appears to have been added for GeoSPARQL. What does it mean? @alanruttenberg asks "what is an incoherent set of direct positions in space. Assuming 'coherent' means something in that description, and if it means something, the opposite must mean something."

[nicholascar]

What do you make of the GeoSPARQL <--> BFO alignment in the standard?

Is geosparql:Geometry a region of space, or is it a set of coordinates that defines a region of space?

A set of positions - coordinate perhaps but possibly also ordinates - that describes a region of space.

Describes rather than defines as the conceptual definition (Feature) might have multiple Geometries (descriptions) in different formats - WKT, KML etc.

So the primary question is: can a :Geometry exist without thing(s) (e.g. :Feature) that it provides the geometry for?

Sure. You can declare a Geometry object without any Feature that hasGeometry indicating it. It's a set of positions describing a space...

the name "Nick" can exist without it being assigned to a person instance.

Also: may one :Geometry have multiple serializations (e.g. WKT and DGGS)?

Yes, explicitly allowed.

We haven't gone in to detail about whether a Geometries can have multiple WKT etc. values but we tend to think not.

A relevant question pertaining to information content entities is whether a Geometries is about something. Which they are.

Yes, but you can state them being a (description of) space without doing the GeoSPARQL expected thing of identifying the space as a Feature. GeoSPARQL would need a Feature declared if you wanted to associate any properties other than position with the space the Geometry is about.

[dr-shorthair]

Compare with CommonCoreOntology/CommonCoreOntologies#763

[dr-shorthair]

(For reference, here is the main BFO hierarchy.)

First, I note that the BFO alignment in GeoSPARQL uses BFO and IAO. CCO has emerged more recently, and is probably a better reference than IAO -- which is an OBO derivative that has strayed a bit from the main BFO/CCO thread.

On to the substantive questions.

I am now comfortable that Geometry is not itself an independent continuant, it is only a property of some independent continuant(s). It is a generically dependent continuant since one geometry may be associated with more than one feature. So geo:Geometry is best aligned to information content entity (ICE) only.

i.e. geo:Geometry itself is not a region of space. It is the description of the spatial properties of something in space. That something being a geo:Feature. So geo:Feature is the associated independent continuant. (If it is just a region of the earth it'll probably have no other physical properties i.e. an immaterial entity.)

And thus geo:SpatialObject is just a (subclass of) bland continuant, which is the superclass of independent and dependent continuants.

I recognise that this is a refinement of how we had been thinking about the GeoSPARQL classes. But I think it resolves some muddled thinking. The comparison with BFO has exposed this, but it is no tragedy since the solution is relatively simple. However, it does also require us to look at the cardinalities: if we accept this proposition that geo:Geometry is a pure ICE, then there can only be one geo:hasSerialization (and as a side effect we know what the resolution and accuracy values apply to). Alternative serializations are actually alternative geometries, since in general they will describe (slightly) different geometries - the most obvious case being polygons vs. DGGS. The game is given away already by having geo:hasDefaultGeometry alongside geo:hasGeometry. Allowing both for features to have multiple geometries, and for geometries to have multiple serializations, provides two ways to do the same thing, which is always bad for standardisation.

BFO site vs. spatial region vs. continuant fiat boundary is more subtle. AFAICT any location that is tied to a material entity is a site, but I'm not sure if the (surface of the) earth is such a material entity. I find the definitions of continuant fiat boundary and its subclass fiat point confusing on this matter. OTOH spatial regions are untethered. (Is this correct @alanruttenberg ?).

[dr-shorthair]

In summary, this change to GeoSPARQL:

geosparql:Geometry 
    a owl:Class ;
    rdfs:subClassOf [ 
        a owl:Restriction ;
        owl:maxCardinality "1"^^xsd:nonNegativeInteger ;
        owl:onProperty geosparql:hasSerialization ;
    ] ;
. 

and remember that geosparql:asWKT etc are subproperties of geosparql:hasSerialization.

And these changes to the BFO alignment:

@prefix obo: <http://purl.obolibrary.org/obo/> .
@prefix cco: <https://www.commoncoreontologies.org/> .
@prefix geosparql: <http://www.opengis.net/ont/geosparql#> .

geosparql:SpatialObject 
    a owl:Class ;
    rdfs:subClassOf [ 
        owl:unionOf ( 
            obo:BFO_0000002 # continuant  
            obo:BFO_0000015 # process
            ) 
        ] ;
. 

geosparql:Feature 
    a owl:Class ;
    owl:equivalentClass [ 
        owl:unionOf ( 
            obo:BFO_0000004 # independent continuant  
            obo:BFO_0000015 # process
            ) 
        ] ;
. 

geosparql:Geometry 
    a owl:Class ;
    rdfs:subClassOf cco:ont00000958 ; # information content entity
. 

geosparql:hasGeometry 
    a owl:ObjectProperty ;
    rdfs:subPropertyOf cco:ont00001801 ; # is subject of
.

geosparql:sfWithin
    a owl:ObjectProperty ;
    rdfs:subPropertyOf obo:BFO_0000171 ; # located in at some times
. 

Feature is shown as a subclass of the union of independent continuant and process. A Feature can be generally understood as something that appears on a map. While in many cases this is a continuant, it might also be an ''event'' with a location, so we have to add something from the occurrent branch of BFO to accommodate this.

[dr-shorthair]

The BFO alignment is also discussed here: CommonCoreOntology/CommonCoreOntologies#760