How much sub-classing is actually required for SSN to import SOSA?

I checked exactly this yesterday and committed to a GitHub branch for review - https://github.com/w3c/sdw/pull/517 .

AFAICT there is only one class and three properties where the scope of SOSA is broader than a corresponding SSN resource, so sub-class or sub-property is indicated:

ssn:ObservationValue rdfs:subClassOf sosa:Result .

-          Because sosa:Result applies to sampling and actuation as well as observation
ssn:sensingMethodUsed rdfs:subPropertyOf sosa:usedProcedure .

-          Because sosa: usedProcedure applies to sampling and actuation as well as observation
ssn:observationResult rdfs:subPropertyOf sosa:hasResult .

-          Because sosa:hasResult applies to sampling and actuation as well as observation
ssn:observationResultTime rdfs:subPropertyOf sosa:resultTime .

-          Because sosa:resultTime applies to sampling and actuation as well as observation

In a significant number of other cases the definitions are (or could be) identical, specifically

ssn:FeatureOfInterest             = sosa:FeatureOfInterest
ssn:Observation                      = sosa:Observation
ssn:Platform                            = sosa:Platform
ssn:Property                            = sosa:ObservableProperty
ssn:Sensor                               = sosa:Sensor
ssn:attachedSystem                = sosa:hosts
ssn:featureOfInterest              = sosa:hasFeatureOfInterest
ssn:madeObservation             = sosa:madeObservation
ssn:observationSamplingTime            = sosa:phenomenonTime
ssn:observedProperty             = sosa:observedProperty
ssn:observes                            = sosa:observes
ssn:onPlatform                        = sosa:hostedBy

Relates to ISSUE-115 and ISSUE-139 .

Simon

From: Kerry Taylor [mailto:kerry.taylor@anu.edu.au]
Sent: Tuesday, 31 January, 2017 12:20
To: Rob Atkinson <rob@metalinkage.com.au>; janowicz@ucsb.edu; Armin Haller <armin.haller@anu.edu.au>; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; phila@w3.org; public-sdw-wg@w3.org
Cc: ssimmons@opengeospatial.org; fd@w3.org
Subject: RE: State of SSN

Rob,
>Only if the formal axioms for the SSN concept are reasonably identical to the informal ones for the SOSA concept should we reuse the SOSA concept directly."

And that is exactly what we should be doing. We can make it so. There is nothing preventing us from making it so!

>“hopefully (and my understanding of the process) SOSA is identical to SSN semantics except where some limitation or extended scope has been identified, in which case the original SSN concept should be a subclass of the SOSA term.

I would go a step further ---  “except where some limitation or extended scope has been identified”.
If such a  limitation or extended scope is identified  (and I don’t think  any such has been aired at all yet, with the possible exception of platform issue-88),  then this is solvable too without resorting to mindless subclassing. I hope my worked example for platform  demonstrates  that. Judicious changes to old ssn to adjust to scope requirements (especially when driven by our  use cases) is perfectly appropriate in this standards phase. Arbitrary changes to ssn *just because,*  are a bad idea, though. There is no reason at all to believe that SOSA as currently on github is the SOSA that we are forced to accept, either. Indeed our evaluation of our new SOSA badly needs an architectural/modularity framework in which to judge it.

Only laziness prevents that happening well. How could we even consider, as I understand the alternative architecture relying on alignments has,
to publish something anywhere that requires  ssn:Sensor rdfs:subClassOf sosa:Sensor  ?

Your 1-5 summary is helpful.  I would add to that
6) Terms of the same intended meaning with different names
7) Poorer documentation – counterpart in case your (1) does not cover both cases which  both exist

>So, if all is good, SSN-2 just uses SOSA namespace and entities and is just a graph holding axioms that support a specific logic, and gives the user the power (and requirement) to perform additional reasoning.  As Jano says, SOSA users  may not comply with the SSN axioms, but probably ought to as they are probably formalisms of the wordy definitions in SOSA.  If we have no subclassing in SSN, or broadening of semantics, and only "extend" the expressivity - then SSN could be a semantic validator for SOSA instances perhaps?

+1. I like your “semantic validator” idea a lot but noting that (a) I am  personally not certain that the same namespace cannot or should not be used.  This seems to be an unsupported assertion (not entirely unsupported, but almost ). Is there someone arguing for different namespaces willing to put the pro argument out there in public, please? (b) SSN will also add new terms that are not even present in SOSA, but I suspect that is what you mean anyway.

>This still gives SOSA and SSN different functional roles, but common semantics - and that makes a lot of sense as a rationale to me. i think this is what Kerry is getting at - but as always we humans have imperfect communication :-)

Thank you for making the effort!



Kerry