apo:Cell is a 'Feature' not a pure 'Geometry'

[dr-shorthair]

The model for a DGGS cell shows that it has identity, type, and links to geometry(s) expressed as geo:Geometry so it is behaving like a Feature not a Geometry. Propose making this explicit in the ontology.

Note that this does not affect the API implementation.

[nicholascar]

So you mean:

aop:Cell ;
    ...
    rdfs:subClassOf geo:Feature ;
    ...

Not the current:

aop:Cell ;
    ...
    rdfs:subClassOf geo:SpatialObject ;
    ...

My thoughts were then that you could do something like this:

<x> a apo:Cell ;
    geo:hasGeometry "SPECIAL-DGGS-GEOMETRY"^^geox:dggsLiteral ;

Not just the current GeoSPARQL norm of:

<x> a apo:Cell ;
    geo:hasGeometry \"POLYGON ((148.88888888888889 -34.663795228918765,..."^^geo:wktLiteral

[dr-shorthair]

"SPECIAL-DGGS-GEOMETRY"^^geox:dggsLiteral

I wonder what that would look like ... ?

[nicholascar]

Actually it should be:

<x> a geo:Feature ;
    geo:hasGeometry "SPECIAL-DGGS-GEOMETRY"^^geox:dggsLiteral ;

where SPECIAL-DGGS-GEOMETRY is a string of integers, as per the DGGS addressing.

So not aop:Cell has a SPECIAL-DGGS-GEOMETRY but a standard geo:Feature.

[dr-shorthair]

OK. That's interesting. I had imagined an apo:CellAggregate class, with individuals like

auspix:Agg_1
  a apo:CellAggregate ;
  dcterms:identifier "Agg_1" ;
  rdfs:member apo:R7828 ;
  rdfs:member apo:R78520 ;
  rdfs:member apo:R78521 ;
  rdfs:member apo:R78522 ;
  rdfs:member apo:R78523 ;
.

But that must be accompanied by a predicate to link a Feature to its equivalent from another geography (see https://github.com/CSIRO-enviro-informatics/loci-ont/issues/13).

This is more direct, and preferable I think!

:F987 a geo:Feature ;
   geo:hasGeometry [
        a geo:Geometry ;
        geox:asDGGS "R7828 R78520 R78521 R78522 R78523"geox:dggsLiteral ;
     ] ;
.

(because geo:hasGeometry is an owl:ObjectProperty it must contain a blank-node or URI-reference. )

[dr-shorthair]

However, the AusPIX API http://pid.geoscience.gov.au/dggs/ausPIX/ delivers the description of a Cell so we also need a (Loc-I conformant) representation for the payload. This pattern is proposed:

auspix:R7852 a apo:Cell ;
  dcterms:identifier 'R7852' ;
  apo:hasNeighbourUp auspix:R7828 ;
  apo:hasNeighbourDown auspix:R7855 ;
  apo:hasNeighbourRight auspix:R8630 ;
  apo:hasNeighbourLeft auspix:R7851 ;
  geo:hasGeometry 'POLYGON ((148.88888888888889 -34.663795228918765, 150.0 -34.663795228918765, 150.0 -35.81859718358464, 148.88888888888889 -35.81859718358464))'^^geo:wktLiteral ;
  geo:sfContains auspix:R78520 , auspix:R78521 , auspix:R78522 , auspix:R78523 , auspix:R78524 , auspix:R78525 , auspix:R78526 , auspix:R78527 , auspix:R78528 ; 
  geo:sfWithin auspix:R785 ; 
  geox:centroid 'POINT (149.44444444444443 -35.23915910922053)'^^geo:wktLiteral ;
  geox:hasAreaM2 [ data:value 12971551595.0 ] ; 
.

So since

geo:hasGeometry rdfs:domain geo:Feature .

this entails

apo:Cell rdfs:subClassOf geo:Feature .

[nicholascar]

In the DGGS Testbed, we are thinking of a Cell as a Sampling Feature. Not that LocI needs to use such a definition but conceptually, does Cell subClassOf SamplingFeature (of which particular ontology I don;'t know, but conceptually at least) strike you as correct @dr-shorthair?

[dr-shorthair]

The only mandatory property of sosa:Sample is sosa:isSampleOf. What type or thing does a DGGS Cell sample? Does every DGGS Cell sample one of these?

(BTW - membership in multiple classes is fine by me, but need to understand whether this is a universal behaviour or only occasional.)

[nicholascar]

I think the thought is that since calling a service, e.g. a WFS, with a call ID will return a lumped/averaged single point reading of something it's a sampling Feature. Can't say this is all though through for now but I think as the DGGS vocab is built and as your modelling work progresses, we'll get to a satisfactory set of definitions for all of this soonish.

[dr-shorthair]

Resolved by #3