Additional GeoSPARQL requirements from Loc-I project

[dr-shorthair]

We have been adding features to a 'GeoSPARQL Extensions' ontology that are required for a significant deployment in Australia. See https://github.com/CSIRO-enviro-informatics/geosparql-ext-ont

This includes

• predicates for length, area, volume
• predicate for centroid
• inverse property for geo:hasGeometry
• explicit link to CRS description
• predicates for spatial resolution

[FransKnibbe]

@dr-shorthair: Do you think everything added by the extension should be adopted by the core GeoSPARQL ontology? Or are there benefits to the extension being an extension (for example, you having more control over it)? The process leading to a possible next version of GeoSPARQL has been to file change requests in the OGC StandardsTracker (see http://ogc.standardstracker.org/requestlist.cgi?quicksearch=geosparql). One easy option would be to add a request to migrate additions from the extensions ontology to the GeoSPARQL ontology. There is bound to be overlap with other change requests, but comparing them all for (partial) duplicates may be too much work at this stage (it hasn't been decided yet that work on a next version of GeoSPARQL will go ahead).

[dr-shorthair]

Not necessarily. I'm just putting it on the table. These are properties that are required for our application (actually length and volume not yet, but they were obvious once we were looking at area). They are rather minor additions mostly.

[FransKnibbe]

I see geox is mentioned in the draft of the charter for an update of GeoSPARQL, so even if it doesn't translate to an issue in the tracker, it should not remain under the radar.

[jabhay]

Created MoSCoW poll

[dr-shorthair]

Yikes - never saw a moscow poll before. Accidently voted. Didn't understand what I was clicking.

[FransKnibbe]

@dr-shorthair: I hope you didn't torpedo your own proposal. Anyway, I voted M. I do wonder if anyone can see who voted for what.

[nicholascar]

The proper location for the GeoSPARQL extensions ontology is https://linked.data.gov.au/def/geox

[nicholascar]

GEOX defines the following:

• Classes

  • Bounding box - a subClassOf geo:Geometry
  • Spatial measure - a subClassOf a Qualitative Measure class which defines a data value, units and uncertainty properties

• Object Properties

  • has area
  • has area in m2
  • has bounding box - specialization of geo:hasGeometry
  • has centroid - specialization of geo:hasGeometry
  • has length
  • has length in m
  • has spatial resolution
  • has spatial resolution in metres
  • has volume
  • has volume in m3
  • In Coordinate Reference System
  • is geometry of
  • transitiveSfOverlap

• Datatype Properties

  • asDGGS
  • lower-left
  • upper-right

1.1 inclusions

Following the agreed procedure of non-controversial changes for GeoSPARQL 1.1 and more complex changes for 1.2, truly radical changes for 2.0, I propose the following additions to GeoSPARQL 1.1 from GEOX:

• Object Properties
  • In Coordinate Reference System

This property is much requested and clearly useful however, in GEOX, its domain is a SpatialMeasure which is not something in GeoSPARQL so additions to GeoSPARQL, other than the property itself, will be needed. How controversial these are will be determined by the SWG but I feel they can be introduced without breaking any backwards comparability and therefore are pretty uncontroversial.

Basic use may look like this:

From GEOX:

Therefore:

(I'm not thrilled by the linking of SpatialMeasure and SpatialObject in this way - something not present in GEOX - but it is required to keep the Geometry / SpatialObject relations unchanged. The logic must surely be that even a measurement is an objects... not a Feature though.)

This insertion of the SpatialMeasure class will introduce a number of possibilities (see next) but will not break any existing GeoSPARQL constructs.

If GeoSPARQL were to include a SpatialMeasure class then the following GEOX properties could also be added:

• Object Properties
  • has area
  • has length
  • has volume
  • has spatial resolution

Compared to GEOX, I think the domain values for these properties should be Feature, not the more general SpatialObject. This prevents the silly situation of a Geometry, which is a type of SpatialObject also having a measurement made of it, rather than the thing it is also a measure of, some Feature.

In GEOX, examples of the use of SpatialMeasure look like this:

my:swimmingPool99
  :hasVolume [
    data:unit <http://qudt.org/vocab/unit/M3> ;
    data:value 3050.0 ;
  ] ;
.

This pair of value/unit properties is analogous to current geo:asWKT where the value is the literal and the unit is the recording system - WKT.

I propose we use QUDT qudt:unit & qudt:value properties in place of GEOX's data:unit & data:value properties. We cannot define these - they are already defined - so they won't appear as normative elements in the ontology but we should, in the specification, indicate their expected use.

1.1 exclusions

We should not include the following from GEOX in GeoSPARQL 1.1 at least yet:

• Classes

  • Bounding box

• Object Properties

  • has bounding box
  • has centroid
  • has area in m2
  • has length in m
  • has volume in m3
  • has spatial resolution in metres
  • is geometry of
  • transitiveSfOverlap

• Datatype Properties

  • asDGGS
  • lower-left
  • upper-right

The reasons are:

• Bounding box - we need to resolve geometry roles first
• has bounding box & has centroid - as above
• has area in m2, has length in m, has volume in m3 & has spatial resolution in metres- GeoSPARQL is a reference ontology and should not be polluted by endless specalised properties
• is geometry of - no need for inverse properties (open for convincing here)
• transitiveSfOverlap - we have to consider whether these sorts of properties are needed when we might just write entailment rules instead
• asDGGS - not yet well defined enough - there is no DGGS literal standard
• lower-left & upper-right - excluded until Boundig box is included as it is their domain

1.2 inclusions

more to come...

[dr-shorthair]

Yikes - I had missed this discussion. The subsumption hierarchy is clearly wrong, and the domain/range axioms questionable.

• inCRS is clearly needed on geometry
• some spatial measures (length, area, volume) are sensitive to CRS. But spatial-measure is a scaled number, so associating it with a CRS is a bit more tricky.

[nicholascar]

The class hierarchy as focussed above is not implemented in the Ont or Spec now: SpatialMeasure is not subclass of anything currently and, as per GeoSPARQL 1.0, Feature and Geometry remain subclasses of SpatialObject.

[FransKnibbe]

The class hierarchy as focussed above is not implemented in the Ont or Spec now: SpatialMeasure is not subclass of anything currently and, as per GeoSPARQL 1.0, Feature and Geometry remain subclasses of SpatialObject.

@nicholascar: Shouldn't SpatialMeasure be a subclass of SpatialObject?

[FransKnibbe]

@nicholascar: Shouldn't SpatialMeasure be a subclass of SpatialObject?

On second thought, I think that does not make sense. GeoSPARQL defines topologic relationships between SpatialObjects. I don't think topologic relationships can be applied to sizes of things.

Would it help to relate SpatialMeasure terms like qudt:Quantity, schema:Quantity or uom:Quantity?

[dr-shorthair]

All sensible requirements have been included.