- From: Joshua Lieberman <jlieberman@tumblingwalls.com>
- Date: Wed, 28 Sep 2016 13:58:51 -0400
- To: Kerry Taylor <kerry.taylor@anu.edu.au>
- Cc: Maxime Lefrançois <maxime.lefrancois.86@gmail.com>, SDW WG Public List <public-sdw-wg@w3.org>
- Message-Id: <D28ECC02-FD6B-4206-8FA3-859F1CB6AC95@tumblingwalls.com>
This seems to be another consequence of the distinction between Observation as record and Observation as event. It makes sense that a record be disjoint with and later in time than a Stimulus (ResultTime vs PhenomenonTime) but if the event of sensing is disjoint with the Stimulus being sensed, there generally isn’t going to be any result. Therefore, if om:Observation is to be adopted, isPostconditionOf will not be the appropriate relationship between Stimulus and Observation. —Josh > On Sep 28, 2016, at 9:23 AM, Kerry Taylor <kerry.taylor@anu.edu.au> wrote: > > Maxime, > > Thank you so much for following up on this. > > isPostconditionOf looks ok to me because > -(1) its rdfs:comment annotation says “ Direct succession applied to situations. E.g., 'Taking some rest is a postcondition of my search for a hotel'.” > -(2) and another reference says ‘"Direct succession applied to situations. E.g., 'A postcondition of our Plan is to have things settled'."” > -(3) it seems to capture the intended relationship between a stimulus event and an observation. Certainly we would not want that a stimulus causes an observation, nor that an observation is a necessary consequence of a stimulus, but I think we are ok here. It does say that the stimulus comes first, and then the observation, but that seems quite ok too. > > Note that the domain and range of isPostconditionOf are both the union of Event and Situation, so no problem there. includesEvent had a range of Event, so this expansion of the range to Event or Situation is not going to get existing implementations in to additional trouble (ie beyond the trouble already implied by the descision to change Observation). > > It is a subproperty of directlyFollows (an intransitive ordering relation) and an inverse of hasPostcondition. While these may not have been intended by the original includesEvent (in which the situation of observation just includes the Stimulus event), I cannot see any problem in using isPostconditionOf, and indeed it looks to me like the difference in meaning is only the necessary difference that arises to the move of Observation to an Event. > > So I’d vote for isPostconditionOf, being the closest match possible to the previous. > > --Kerry > > > > > From: Maxime Lefrançois [mailto:maxime.lefrancois.86@gmail.com] > Sent: Wednesday, 28 September 2016 6:53 PM > To: SDW WG Public List <public-sdw-wg@w3.org> > Subject: SSN Thread for github issue 378 - Side effects of ssn:Observation being a kind of dul:Event instead of dul:Situation > > Dear all, > > If each github issue shall have its own thread on the SDW list, this is the one for issue 378 - https://github.com/w3c/sdw/issues/378 <https://github.com/w3c/sdw/issues/378> : > > > if ssn:Observation <http://www.w3.org/ns/ssn/Observation> is a kind of dul:Event <http://www.ontologydesignpatterns.org/ont/dul/DUL.owl#Event> instead of a dul:Situation > there is an immediate side effect to resolve: > > axiom: > > ssn:Observation rdfs:subClassOf [ owl:onProperty dul:includesEvent ; owl:someValuesFrom ssn:Stimulus ] . > context axioms: > > ssn:Stimulus rdfs:subClassOf dul:Event . > dul:includesEvent rdfs:domain dul:Situation ; rdfs:range dul:Event . > solution to solve the side effect: > > replace the mention of dul:includesEvent in axiom by a property that has for domain and rangedul:Event > the only such DUL properties are: dul:isPreconditionOf, and dul:isPostconditionOf. > Neither of them seem to fit, > so, should this axiom be simply deleted from the SSN-DUL alignment ? > > Kind regards > Maxime Lefrançois
Received on Wednesday, 28 September 2016 17:59:46 UTC