Consider describing Qualified Geometries

[nicholascar]

I have made an extension to GeoSPARQL 1.1 called the Extended Geometries Ontology (EGO) that allows for the qualification of a Feature/Geometry relationship, in the manner in which PROV allows for the qualification of an Entity/Agent or Activity/:Entity role.

Figure 1 in the link above indicates the additions to GeoSPARQL to do this.

Geometry qualification

Qualification could take many forms but the ones that I'm motivated to directly support here are "confidence" and "evidence", i.e. you might want to qualify the relationship that a Geometry has to a Feature by given the existence of the Geometry a confidence score or perhaps support its existence with evidence.

Time qualification

Time qualification is already partially handled in GeoSAPRQL 1.1 although Qualified Geometries would allow you to indicate a time-bound Geometry like this:

ex:feature-x
    a geo:Feature ;
    ego:hasQualifiedGeometry [
        a ego:QualifiedGeometry ;
        geo:hasGeometry [
            a geo:Geometry ;
            geo:asWKT "..."^^geo:wktLiteral ;
        ] ;
       time:hasTime [
            a time:properInterval ;
            time:hasBeginning [ ... ] ;
            time:hasEnd [ ... ] ;
       ] ;
    ] ;
.

Here the qualified geometry elements are allowing the time-bound geometry to be seen more clearly (I think) than the way GeoSPARQL 1.1 allows for time where the first example is probably wrong - it indicated temporality for the Feature, not the Geometry, and the second example indicates a temporal projection of the Geometry but not a time-bound relevance of the Geometry with respect to the Feature.

Fuzzy Geometries

A Feature with a series of Qualified Geometries with confidence scores for each can act as a fuzzy geometry by treating the set as a geometry distribution. Visualisation tools could draw fuzzy geometries by blurring between qualified geometries with different confidence scores.

Narrative geometries

This ontology extension also introduced a narrative geometry which is just a language description of a Geometry's position. This might be considered separately from geometry qualification.

Another option here is just to use a standard description property, perhaps sdo:description for a Geometry to describe it, rather than creating a specialised property for such a description.

[oldskeptic]

Isn't this overkill? Your example adds the time-bound geometry using a new property when the same can be achieved by simply adding a class to the geometry:

ex:feature-x
    a geo:Feature ;
        geo:hasGeometry [
            a geo:Geometry, time:TemporalEntity;
            geo:asWKT "..."^^geo:wktLiteral ;
        ] ;
    ] ;

A number of real-world cases will have temporal components to both Features and Geometries. The exemplar in the document does attach temporality to the Feature which can be perfectly valid depending on the design: a flood will occur in a locality / area for a set period of time while the actual flooding area will also change over time as the water rises and recedes.

There are no constraints on the number of Geometries in OWL which allows for multiple hypothetical geometries to co-exists using prov as you suggest. I like the idea of Narrative Geometries but since a geo:Geometry has no constraints that force a serialization to exist, isn't a Narrative Geometry a geo:Geometry with a skos:definition attached and no serialization? I have a (dated, and likely buggy) example that deals with uncertain geopolitical boundaries using only functions.

[nicholascar]

Isn't this overkill?

Could be overkill for temporality, just as you describe, but my main interest in a Qualified Geometry is for handling uncertainty or other forms of qualification, not really time. I want to have a Feature with multiple Geometries defined, separable by confidence - how confident am I that this boundary contains the Feature?

Evidence is a corollary to certainty/confidence: you can indicate multiple Geometries separable by something other than a 0 - 1 number and that's not certainty so must be something else, generically "evidence".

...isn't a Narrative Geometry a geo:Geometry with a skos:definition attached and no serialization?

Something like that yes: a Geometry with some sort of non-serialization property. I guess we just need to decide if we should indicate a specific one to be used. I personally do like skos:definition as it defines the thing, rather than just commenting on it (rdfs:comment) or describing it (dcterms: or sdo:description). So I agree: let narrative geometry just be:

ex:feature-x
    a geo:Feature ;
        geo:hasGeometry [
            a geo:Geometry ;
            skos:definition "Feature X is bordered to the North by the town of Sandgate, to the East by Moreton Bay, to the Suth by Cabbage Tree Creek but to the West the boundary is hard to determine but certainly the maximum extent is the Bruce Highway" ;
        ] ;
    ] ;

[situx]

Finally looking at your proposal, I would agree with it and have the following considerations:

• Narrative Geometry: skos:definition would also be my preference here
• The property ego:hasQualifiedGeometry would indicate that we have a special version of a Geometry in which we can expect some sort of qualification. So I see no harm in not defining it as a subproperty of geo:hasGeometry. However, we should possibly define a SHACL shape that requires an additional class besides geo:Geometry to be present
• Finally, I see some overlap with my style proposal. Differently qualified geometries might be styled differently as well Draft to include styles for features #418

[oldskeptic]

My pushback on ego:hasQualifiedGeometry is that it doesn't define what the qualification actually is. geo:hasCentroid implies a point and geo:hasBoundingBox an envelope. hasNarrativeGeometry could potentially imply a non-zero enumeration of skos:definition. geo:hasBoundingBox inherently provides a 100% confidence solution if at a low overall precision.

From memory, WKT/GML assumes precision is derived from using xsd:decimal and significant digits. I have not read of any formal way to record accuracy, but PROV will provide a means of recording both provenance and evidence out of the box.

"skos:definition "Feature X is bordered to the North by the town of Sandgate, to the East by Moreton Bay, to the Suth by Cabbage Tree Creek but to the West the boundary is hard to determine but certainly the maximum extent is the Bruce Highway" ;

Which can be currently recorded directly in GeoSparql without a utilising a narrative. What I see missing is definition of what you mean by "confident am I that this boundary contains the Feature". A probability model would cover use cases such as Circular Error Probable, Probability of Location and/or HDOP a-la-GPS. Besides adding a new generic property like "confidence" or "probability", how do you think it should be recorded?

If a Feature has multiple Geometries defined, we need something more than ego:hasQualifiedGeometry to identify the one that is needed in the current context.

[nicholascar]

My pushback on ego:hasQualifiedGeometry is that it doesn't define what the qualification actually is

It shouldn't. If you look at how PROV uses qualified things, e.g. qualifiedAttribution you see that they provide no expected qualification mechanism. The example for qualifiedAttribution uses an ex:hadRole property to qualify the attribution and that property isn't defined by PROV - it's using the example namespace. The expectation is that there will be an indication of what the qualification is but it doesn't have to be one thing - could be anything.

Again, qualifiedAttribution could be qualified by time instead of role:

:nationalRegionsList 
   a prov:Entity;
   prov:qualifiedAttribution [
      a prov:Attribution;
      prov:agent :civil_action_group;
      time:hasTime [
        ... # time details
      ] ;
   ]
.

I can think of many ways to qualify a Geometry, I just need standard elements in GeoSPARQL to indicate that a qualification is occurring.

[nicholascar]

geo:hasCentroid implies a point and geo:hasBoundingBox an envelope. hasNarrativeGeometry could potentially imply a non-zero enumeration of skos:definition. geo:hasBoundingBox inherently provides a 100% confidence solution if at a low overall precision.

I think we can do without hasNarrativeGeometry by just using:

:geom-x
    a geo:Geometry ;
    sdo:description "Bordered to the North by the town of Sandgate, to the East by Moreton Bay, to the South by Cabbage Tree Creek but to the West the boundary is hard to determine but certainly the maximum extent is the Bruce Highway" ;
.

So the Geometry may be given in WKT, DGGS, GeoJSON etc but it may also just be given in prose and any old prose property indicating a description, like sdo:description could be used for this.

[nicholascar]

From memory, WKT/GML assumes precision is derived from using xsd:decimal and significant digits. I have not read of any formal way to record accuracy, but PROV will provide a means of recording both provenance and evidence out of the box.

I could always think of a what to indicate a Geometry for which no amount of precision would be sufficient:

:atlantis
    a geo:Feature ;
    sdo:name "Atlantis" ;
    geo:hasGeometry [    
        a geo:Geometry ;
        sdo:description "Somewhere in the Atlantic ocean, north of the equator and closer to Europe than America" ;
    ] ;
.

so you could include a low-precision BoundingBox for this, but likely you'd also benefit from the description. As per the comment above, I think an ordinary description will do, no need for a specialised natrrative geometry property.

[nicholascar]

If a Feature has multiple Geometries defined, we need something more than ego:hasQualifiedGeometry to identify the one that is needed in the current context.

That depends on how things are qualified and there are many ways to do this - type, time, precision etc. Only a time-based multiple geometry would have a "current" one as a qualifiedGeometry like this has two current geometries:

:moreton-island
    a geo:Feature ;
    sdo:name "Moreton Island" ;
    geo:hasQualifiedGeometry [    
        a geo:Geometry ;
        geo:asWKT "..."^^geo:wktLiteral ;
        ex:hadRole <high-tide-level> ;
    ] ,
    [    
        a geo:Geometry ;
        geo:asWKT "..."^^geo:wktLiteral ;
        ex:hadRole <low-tide-level> ;
    ]
.

Here there is a classification of the role that the Geometries play: high & low tide indicators. Both are current.

You could model the above using just geo:hasGeometry but then you would perhaps not realise that the multiple geometries have a qualifying factor - here the role that they play

If the qualified geometries where time-split, perhaps like this:

:stradbroke-island
    a geo:Feature ;
    sdo:name "Stradbroke Island" ;
    rdfs:comment "Stradbroke island's geometry changed after a very large storm 1910 that swept away much of the island's northern sand dunes" ;
    geo:hasGeometry [    
        a geo:Geometry ;
        geo:asWKT "..."^^geo:wktLiteral ;
        time:hasTime [ # ProperInterval until 1910 ] ;
    ] ,
    [    
        a geo:Geometry ;
        geo:asWKT "..."^^geo:wktLiteral ;
        time:hasTime [ # ProperInterval after 1910 ] ;
    ]
.

The a SPARQL query that used elements of OWL TIME could work out that the second geometry is the current one by asking which has hasTime that continues now.

[dr-shorthair]

OWL-Time followed the old ontology (anti-)pattern with the object-properties having global domain/range constraints.
Unfortunately, the utility property hasTime is the only predicate that has no entailments on its subject, so it is the only real option.

(For the example above hasEnd and hasBeginning might have been better, except that would have entailed that the Geometry was also a TemporalEntity which is probably a stretch.)

In an application (i.e. GeoSPARQL?) you could define something like validTime with the range TemporalEntity to be more precise.

[VladimirAlexiev]

Adding Time is in line with CIDOC-CRM (aligned to GeoSPARQL here: https://opengeospatial.github.io/ogc-geosparql/geosparql13/document.html#_03e07d72-8a75-45e6-90d8-8cb8160031f6) that talks of a spatio-temporal continuum.
@nicholascar adds confidence, evidence, and role.

I side with @oldskeptic that all such props (and in the case of Time, a class) can be added directly in the Geometry node.
We already have hasDefaultGeometry vs hasGeometry: I don't think we also need hasQualifiedGeometry.
Reasons:

• If hasGeometry means a "valid" geometry at current time, in a default role; then what precisely does hasQualifiedGeometry mean?
• If I want to specify the start time of a geometry and it's still valid, then is it qualified or unqualified?
• As described above, "Qualifiedness" is an innate characteristic of the Geometry.
  So if I use hasQualifiedGeometry to point to an unqualified geometry, is that an error? Who'll check that?
• We can have a boolean function isQualfiied just like we have is3D, isMeasured, isEmpty
• But such a function is unspecific: we should first have boolean functions hasTime, hasConfidence, hasEvidence, hasRole,
  then we could define isQualified as a disjunction of them
• If it's felt that we need materialized triples, we can express it with a class QualifiedGeometry
• Following the pattern that hasDefaultGeometry is a subprop of hasGeometry,
  then we need to make hasQualifiedGeometry a subprop of hasGeometry,
  and have yet another sibling hasUnqualifiedGeometry also subprop of hasGeometry...

[oldskeptic]

@nicholascar The primary objective to prov's prov:qualifiedAttribution is to provide a node to qualify a relationship which prov:wasAttributedTo cannot support, both semantically and syntactically. hasGeometry has no such obstacle.

From the practitioners' perspective, hasQualifiedGeometry presents an annoying problem: it implies that something is attached to the Geometry node without defining what that is. Thus the application must already be aware of the qualification attached to the Geometry instance in order to interpret it, which in turns makes hasQualifiedGeometry redundant because an 'aware' application will query the Geometries directly with (out) the actual qualifiers it understands outright.

It may have a value in that an application can search for a Geometry that is free of... representational encumbrances? But isn't this what we had in mind for hasDefaultGeometry?

I think that NarrativeGeometry has value for recording operational or historical narratives. It also implies that the consuming application needs a textual rendering engine as opposed to a GIS / graphical renderer that handles WKT/GeoJSON/GML. Lastly, it also differentiates the use of skos:description for data-facing descriptions 'main geometry at highest zoom' versus user-facing narratives 'Bordered to the North by...'.

Qualification makes sense, but over-generalization creates more problems than it solves. Looking at @VladimirAlexiev 's comment in #430, the idea of roles is interesting ontologically, but I would like to nail down the 90% use cases explicitly.

TL;DNR: Would rather expend effort on specific known qualifications, such as accuracy or HDOP, rather than a loosely defined general approach that impacts inter-operability. The more geo-specific solutions we can solve simply in geosparql, the better.