Cater for and define basic Geometry roles

[nicholascar]

The role that a Geometry may play with respect to a Feature allows for Features with multiple Geometries that can be known to do different things.

Roles might subsume specialised versions of hasGeometry, e.g. hasCentroid.

If GeoSPARQL allows roles for Geometries:

• it should supply some (expected) common roles
  • centroid, bounding box etc
• indicate how the role target is defined
  • i.e. a Geometry has a role with respect to what?? A Feature, but what if it's used by multiple Features?
• provide a register of roles for expansion outside the standard development lifecycle

[dr-shorthair]

While property-specializations make sense from a semantic viewpoint, they can obfuscate queries.
So I think we need to be circumspect in coining too many specialized predicates.
Roles on qualified associations might be a way to go, but that suggests that we would need something like

geo:hasQualifiedGeometry a owl:ObjectProperty ;
    rdfs:range geo:QualifiedGeometry . 

geo:QualifiedGeometry
  rdf:type owl:Class ;
  rdfs:subClassOf [
      rdf:type owl:Restriction ;
      owl:cardinality "1"^^xsd:nonNegativeInteger ;
      owl:onProperty geosparql:hasGeometry ;
    ] ;
  rdfs:subClassOf [
      rdf:type owl:Restriction ;
      owl:cardinality "1"^^xsd:nonNegativeInteger ;
      owl:onProperty geosparql:hasGeometryRole ;
    ] ;
.

[nicholascar]

...suggests that we would need something like...

I'm still concerned about how the Roles are targeted, e.g. for this data:

ex:qual-geo-01 
    a geo:QualifiedGeometry ;
    geo:hasGeometry ex:geom-01 ;
    geo:hasGeometryRole ex:role-x ;
.

Can this make sense without a Feature? Surely not as the role is relative. So how do we ensure to context of the role? Perhaps we need:

ex:geo-01 
    a geo:Geometry ;
    geo:asWKT "..." ;
    geo:hasRelativeRole [
        geo:role ex:centroid ;
        geo:roleFor ex:feature-01 ;
    ] ; 
.

So here the role is only defined with respect to ex:feature-01. We don't need a qualified Geometry as a normal Geometry can have multiple roles, with respect to multiple Features, defined.

geo:roleFor range could be geo:SpatialObject so that roles can be w.r.t a Feature or another Geometry. The we can use roles for derivation roles, not just spatial roles.

[VladimirAlexiev]

#430 gives application-specific examples:

        ex:hadRole <high-tide-level> ;
        ex:hadRole <low-tide-level> ;

Unlike the universal concepts of Centroid and BoundingBox, I think these cannot be part of a central register and should be simply skos:Concept.

Furthermore, roles can be multivalued:

• The bounding box of an island moves with the tide (reduces with the high tide)
• Even the centroid moves, eg if the island has high north shores but low south shores, the centroid will move north with the high tide

@nicholascar Are geometries often shared between features?
Kazanluk is said to be right in the middle of Bulgaria.
I think we should follow the schema:Role pattern (Feature-Role-Geometry) and we could model it like this:

:Bulgaria geo:hasGeometry :centerOfBulgaria. # schema.org does that; if you dislike it then use geo:hasGeometryRole
:centerOfBulgaria a geo:GeometryRole; geo:hasRole geo:Centroid; geo:hasGeometry :geoKazanluk.
:Kazanluk geo:hasGeometry :geoKazanluk.
:geoKazanluk a geo:Geometry; geo:asWKT "...".

But given that #430 may introduce more varieties (time, confidence, evidence), is such sharing still important/relevant?
If not then we can omit the intermediate node GeometryRole (at the expense of having 2 Geometry nodes):

:Bulgaria geo:hasGeometry :centerOfBulgaria. # schema.org does that; if you dislike it then use geo:hasGeometryRole
:centerOfBulgaria a geo:Geometry; geo:hasRole geo:Centroid; geo:asWKT "...".
:Kazanluk geo:hasGeometry :geoKazanluk.
:geoKazanluk a geo:Geometry; geo:asWKT "...".