RE: Forecasts and observations - was I RE: SSN Thread for github issue 378 - Side effects of ssn:Observation being a kind of dul:Event instead of dul:Situation

SSN-people,
I am trying to close off this subject as originally posed - and without diverting into  the bigger issue of forecasts and observations. It relates to solving issue-62 and issue-67 (how does ssn:observation get re-worked as an activity/act?)


(1) Please see the conversation thread here. https://lists.w3.org/Archives/Public/public-sdw-wg/2016Oct/0089.html


(2) it was rooted in Maxime's observation that

        ssn:Observation rdfs:subClassOf [ owl:onProperty dul:includesEvent ; owl:someValuesFrom ssn:Stimulus ] .

and Maxime's suggestion (among others that were discussed extensively) that


?  should this axiom be simply deleted from the SSN-DUL alignment ?


(3) I propose that we do exactly as posed here --- that is, delete the axiom ssn:Observation rdfs:subClassOf [ owl:onProperty dul:includesEvent ; owl:someValuesFrom ssn:Stimulus ]
from https://github.com/w3c/sdw/blob/gh-pages/ssn/ssn_separated/dul-alignment.owl

(4) figure 5.9 here may help understanding https://www.w3.org/2005/Incubator/ssn/XGR-ssn-20110628/

(5) I don't think  deleting the axiom creates a big problem as the Stimulus can still be reached from the Observation via the Sensor that observed it and Stimulus it detects. And if there is an issue with sensors detecting multiple stimuli (which ssn allows) and so we would not know which stimulus was involved in the observation (which can happen), then someone using ssn is going to have to work harder and define a fresh sensor for each distinct stimulus if they need this.

(6) What to do with the alignment to old ssn? The change to the dul alignment of Observation itself is already problematic :

ssn:Observation<http://www.w3.org/ns/ssn/Observation> becomes a kind of dul:Event<http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Event> instead of a dul:Situation

So... I don't think we can align old and new ssn in an ontology fragment for this. I propose that the best we can do is explain the change in documentation. Any better idea?

Does anyone object to this path forward?

-Kerry