Re: SSN Thread for github issue 378 - Side effects of ssn:Observation being a kind of dul:Event instead of dul:Situation

Hi,

I would also like Joshua to precise a bit his thoughts.
In my opinion, there can't be any observation without a prior stimulus.
(the inverse is not true though).

The other issue might be for existing data that make use of SSN + PROV. If
an existing dataset annotates an instance of ssn:Observation as a
prov:Entity, AND it it really wants to use SSN-full with the Dolce
alignment, then the Dataset will become inconsistent.
Some extra care will need to be taken during the migration process:
 - use the SSN version without PROV, or
 - change the PROV annotations to reflect that ssn:Observation is a
prov:Activity.

Kind regards,
Maxime

Le lun. 3 oct. 2016 à 17:04, Kerry Taylor <kerry.taylor@anu.edu.au> a
écrit :

> Hi Josh,
>
> I am not sure I follow – because I am not clear what you mean by
> “disjoint” here. For me, I meant it as “something cannot be both of those
> things”,
>
> but perhaps you mean something about non-overlapping time intervals?
>
>
>
> If we can’t live with “isPostconditionOf” (and I cannot find any other
> alternative in dolce myself, but I would be very grateful if someone can)
> then I can see only 3 other options.
>
> 1)       is to disconnect the observation from the stimulus – which seems
> pretty dumb to me and if so then  I would suggest we go even further and
> just drop stimulus entirely ( or it could remain connected to a sensor, but
> if a sensor could respond to multiple stimuli we would have no idea which
> one provoked this observation.  Which gives another option I suppose –
> insist that each sensor can have at most one stimulus and then the stimulus
> could be retrived with the observation by following the sensor – but this
> is yet another change).
>
> 2)       Make up a new term in ssn for the purpose --- but I am not keen
> to introduce new terms without a really strong reason.
>
> 3)      Make up a new term in the alignment (in a new namespace) but not
> in ssn proper --- I can’t see much value in that for anyone.
>
>
>
> I think I can live with “isPostconditionOf”
>
>
>
> Maxime, did you spot any other problems with changing observation this way?
>
>
>
> --Kerry
>
>
>
>
>
> *From:* Joshua Lieberman [mailto:jlieberman@tumblingwalls.com]
> *Sent:* Thursday, 29 September 2016 3:59 AM
> *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>
> *Subject:* Re: SSN Thread for github issue 378 - Side effects of
> ssn:Observation being a kind of dul:Event instead of dul:Situation
>
>
>
> 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
> <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
>
>
>