You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mostly I added them where I though they made sense, but cardinalities are probably better managed at the application level using SHACL, rather in the Ontology layer where they affect reasoning and can cause difficult-to-control inconsistencies.
The text was updated successfully, but these errors were encountered:
I would like to follow on the comment by @rgcmme. Constraints modelled alone at application level (e.g. with SHACL) would inevitably lead to misinterpretations of the ontology.
An example I am currently dealing with is the relation between Observation and Procedure. Can/should an observation refer to more than one procedure? In OMS the restriction is set by the class diagram itself, wheres in SOSA/SSN the sosa:usedProcedure object property has no cardinality indication. Therefore a SOSA observation with two different procedures is valid, whereas it is not so in OMS/STA.
I don't have the experience with reasoning to sense the troubles cardinalities could imply. Therefore I admit those difficulties to eventually prevent their specification, but in that case I would prefer to have them absent altogether.
I would suggest leaving cardinality restrictions in SOSA. They are unlikely to break things on the reasoner side and if that's the SOSA design, that's what the ontology should say.
OWL and SHACL tend to draw different people but this level of restriction isn't problematic IMHO.
I have found it necessary to remind people that OWL cardinality restrictions are not validation constraints.
The OWA still seems to be a step too far for some smart users.
AFAICT the one that really matters crossing over from OWA to CWA is where cardinality=1 - that means that if there is more than one, then either they are identical or there is an inconsistency.
But I will close this issue now as no-one else wants to deprecate cardinalities.
SAREF-SOSA alignment and first approx doc, closes #125 #206 (comment)
107 Add
SystemKind
class and its subclasses #209 (comment)probably more.
Mostly I added them where I though they made sense, but cardinalities are probably better managed at the application level using SHACL, rather in the Ontology layer where they affect reasoning and can cause difficult-to-control inconsistencies.
The text was updated successfully, but these errors were encountered: