- From: Kerry Taylor <kerry.taylor@anu.edu.au>
- Date: Wed, 28 Sep 2016 13:23:54 +0000
- To: Maxime Lefrançois <maxime.lefrancois.86@gmail.com>, "SDW WG Public List" <public-sdw-wg@w3.org>
- Message-ID: <PS1PR06MB174006B62C65FA85EA4379EBA4CF0@PS1PR06MB1740.apcprd06.prod.outlook.com>
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 : 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 13:24:33 UTC