-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider describing Qualified Geometries #430
Comments
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:
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. |
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".
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:
|
Finally looking at your proposal, I would agree with it and have the following considerations:
|
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.
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. |
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 Again,
I can think of many ways to qualify a Geometry, I just need standard elements in GeoSPARQL to indicate that a qualification is occurring. |
I think we can do without
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 |
I could always think of a what to indicate a Geometry for which no amount of precision would be sufficient:
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. |
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
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 If the qualified geometries where time-split, perhaps like this:
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 |
OWL-Time followed the old ontology (anti-)pattern with the object-properties having global domain/range constraints. (For the example above In an application (i.e. GeoSPARQL?) you could define something like |
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. I side with @oldskeptic that all such props (and in the case of Time, a class) can be added directly in the Geometry node.
|
@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. From the practitioners' perspective, It may have a value in that an application can search for a I think that 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. |
Exactly! I meant the same with
but @oldskeptic said it much better |
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:
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.The text was updated successfully, but these errors were encountered: