Provide validation shapes for ObservationCollection patterns

[rob-metalinkage]

Currently the SHACL validation shapes require Observations to have mandatory fields, which may in future be better handled by ssn-extension ObservationCollection objects containing common metadata.

This has implications for three factors: 1) slimmer data transfer 2) more efficient validation 3) potential for more metadata about collections that are commonly applicable.

The proposal is to create two profiles of Tern: 1 "data at rest" - fully populated observations with all inherited collection attributes (similar to current shapes) 2 "compact exchange" - using Observation collections and allowing implicit properties to be checked against containing collections.

(it may also be worth examining the duplication of property shapes on sub-classes - possibly these are better inherited from parent superclasses and only modified where a sub-class has a specific requirement)

[edmondchuc]

Hi @rob-metalinkage, does SURROUND store observation collections at rest or are observation collections only used during the data exchange?

[rob-metalinkage]

"store" is slightly complex in the world of forward-chaining - inferencing rules may cache temporarily or permanently.

We would aim for inferencing rules in Observation shapes that "hydrate" observations - but we may not want to turn these on by default.

Property chain based rules that are agnostic as to the at rest model would be preferable - but acknowledge engineering concerns might want us to use different strategies and rule subsets.

[edmondchuc]

"store" is slightly complex in the world of forward-chaining - inferencing rules may cache temporarily or permanently.

In some cases, the current set of shapes require an RDFS reasoner to validate correctly.

E.g. this is the property shape for an Observation's sosa:hasResult.

tern-shapes:Observation-hasResult
    a sh:PropertyShape ;
    reg:status reg:statusStable ;
    skos:prefLabel "has result" ;
    sh:message "A `tern:Observation` _MUST_ have exactly 1 `sosa:hasResult` where the value node is a blank node or IRI of type `tern:Value`." ;
    sh:class tern:Value ;
    sh:description "Relation linking an Observation or Actuation or act of Sampling and a Result or Sample." ;
    sh:maxCount 1 ;
    sh:minCount 1 ;
    sh:name "sosa:hasResult" ;
    sh:nodeKind sh:BlankNodeOrIRI ;
    sh:path sosa:hasResult ;
.

The shape checks that the value node has an rdf:type predicate with the value tern:Value. But if the value is any of the subclasses of tern:Value, for example tern:Integer, then some kind reasoning is required.

We would aim for inferencing rules in Observation shapes that "hydrate" observations - but we may not want to turn these on by default.

RDFS/OWL or SHACL? I haven't used SHACL rules much yet.

Is it a problem for the shapes to be written in the way where they expect at least basic RDFS reasoning to be applied before validation?