search

w3c / sdw-sosa-ssn

Repository of the Spatial Data on the Web Working Group for the SOSA/SSN vocabulary
7 stars 5 forks source link

SAREF-SOSA alignment and first approx doc, closes #125 #206

Closed maximelefrancois86 closed 1 month ago

maximelefrancois86 commented 3 months ago

Closes #125

Alignment to SAREF and draft documentation

to previsualize:

maximelefrancois86 commented 3 months ago

@rgcmme Maybe you want to check this out ?

rgcmme commented 3 months ago

SOSA has no formal axiomatization, since all of it has been moved to SSN. Therefore, since the mapping is only between SOSA and SAREF, the relationships should be in the other direction.

That is, by making sosa:FeatureOfInterest (no axioms) subclass of saref:FeatureOfInterest (with axioms), sosa:FeatureOfInterest is inheriting many axioms that may not apply.

If the mapping would be between SAREF and SSN, every class should be analysed in detail. SSN has some cardinality restrictions that would make such mapping difficult (e.g., is it needed for every sosa:Execution to always have both a start time and a result time?).

Also, the mappings between inputs and outputs are strange; because of the "/sosa/saref" URIs, and there is a typo in the sosa:hasOutputValue one. In SAREF inputs and outputs are only applied to commands, but in SOSA/SSN to procedures.

maximelefrancois86 commented 3 months ago

I based the alignment on the literal definitions, mostly. The goal here would only be that nothing breaks when importing SSN + SAREF + this alignment,

Regarding the mappings between inputs and outputs, they are strange indeed. I don't think either is more specific than the other, so I created a common super-property. Note that in SAREF inputs and outputs apply not only to commands:

saref:hasInput has Domain ( saref:Command or saref:CommandOfInterest or saref:Operation or saref:ProcedureExecution ) saref:hasOutput has Domain ( saref:Command or saref:CommandOfInterest or saref:Operation )

rgcmme commented 3 months ago

If the mappings are based in the textual definitions, from the "textual" perspective they compile. 😄

However, if they are formally encoded (using for example rdfs:subClassOf), then there will be formal entailments.

In the case of SOSA, with no axiomatization, nothing will break (even if the mappings are not correct).

If the mapping would be between SSN and SAREF, this may not be the case, since both ontologies impose their own restrictions that may not be compatible (or produce the intended result). But I haven't made that detailed analysis. And it also depends on the definition of "break", but it may happen that one SSN individual is not a valid SAREF individual (e.g., because of cardinality constraints).

dr-shorthair commented 3 months ago

SSN has some cardinality restrictions that would make such mapping difficult

I'm not fully confident in the cardinality restrictions. Most of them are my clumsy way of adding some 'expectations'. But cardinalities are probably better handled in the application, or using SHACL (which is planned by OGC in the next phase).

Would it be best to remove all cardinality constraints from the ssn graphs?

rgcmme commented 3 months ago

I am in favour of the cardinality restrictions and any other axiom that further specifies the meaning and restrictions of the concepts.

Ontologies are a good way of sharing those restrictions in a machine-procesable way; leaving applications the role of handling those restrictions will cause heterogeneity and hinder interoperability.

And using SHACL will require implementors to know/learn both OWL and SHACL and having to search for the restrictions in two places.

In any case, every option is valid in principle. My take would be, for those restrictions that are clear, to have them in OWL and in the future in SHACL.

I would try to avoid having restrictions in SHACL that do not appear in OWL (for those restrictions that can be defined in both places).

dr-shorthair commented 2 months ago

On cardinalities:

e.g., is it needed for every sosa:Execution to always have both a start time and a result time?

The way I understand it is that every Execution does necessarily have a start and end (result) time in the world. However, these may not be known or expressed in any particular representation ... but that is handled by the OWA.

Does putting a minCardinality=1 in the OWL mean that a dataset without that property is 'wrong'? I don't think so, OWL processing does not allow for that judgement, it can only generate entailments. The entailment in such a case is that there is an unknown value ...

rgcmme commented 2 months ago

Of course, OWL and the OWA are able of handling this correctly.

However, sooner or later someone will define closed world constraints (SHACL is mentioned in this same thread) and the restriction "every execution has a start date and there is no problem if you don't find it" becomes "every execution has a start date and your data is incorrect because it does not".

The fact that every execution always has a start time can be documented in the rdfs:comment of sosa:Execution (with no strong semantics associated to it) and leave to users the decision of whether they want that to be a strong constraint (by extending SSN with further restrictions) in their applications.

At least in this case I think that it is a restriction that will not hold for many applications.

dr-shorthair commented 2 months ago

sooner or later someone will define closed world constraints (SHACL) [that are too strict or onerous]

We recognise that risk, and propose to address it by providing shared SHACL constraints that manage things like cardinality. This is on the agenda for related work to be done inside OGC - see https://github.com/w3c/sdw-sosa-ssn/issues/142 and https://github.com/opengeospatial/ogcapi-sosa/issues/4

There is a placeholder space for standard SHACL resources here https://github.com/w3c/sdw-sosa-ssn/tree/gh-pages/ssn/rdf/shapes

dr-shorthair commented 1 month ago

@rob-metalinkage can you check if your concern has been addressed?