RE: hasResult / Sampling in SOSA & ISSUE-90

I think it would help a lot here if we had some understanding of what a “Result” from an actuation is intended to be. Especially around our own use cases.
Is it “error” or “temperature is now 50 degrees” or “done” or “scheduled  to be done” ,  or “25” or….? Could we get some examples on the wiki please?

Maxime’s suggestion could work, except that a use of sosa data in  ssn means that ssn would not know how to use the instance of sosa:Result. Possibly this does not matter --- as it could be done by extra contextual inference (e.g. using forall quantification in a restriction?).

And just a comment:

Ø  “object such change as”
The change would be to change TO “Result” ; the status quo is “ObservationValue”.

-Kerry
From: Maxime Lefrançois [mailto:maxime.lefrancois@emse.fr]
Sent: Tuesday, 14 February 2017 4:11 AM
To: janowicz@ucsb.edu; Kerry Taylor <kerry.taylor@anu.edu.au>; Armin Haller <armin.haller@anu.edu.au>; Rob Atkinson <rob@metalinkage.com.au>; Simon.Cox@csiro.au; danh.lephuoc@tu-berlin.de; public-sdw-wg@w3.org
Subject: Re: hasResult / Sampling in SOSA & ISSUE-90

Hi,

For SOSA, I agree with Jano for the exact same reason --> try to use more generic terms that can also be applied to Actuating / Sampling.

On the other hand, we could propose a new Option that is similar to Option 3, but retains ObservationValue as a subclass of Result in SSN,

we could have

ssn:ObservationValue rdfs:subClassOf sosa:Result .
ssn:ActuationResult rdfs:subClassOf sosa:Result .

etc ?

Kind regards,
Maxime
Le lun. 13 févr. 2017 à 17:59, Krzysztof Janowicz <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>> a écrit :
I also prefer option 3, with some suggested changes. Most importantly that we use the term “ObservationValue” instead of “Result”. This is much better for backward compatibility (it was what ssn always used) and solves the “role” con that is raised too., and better complies with sensorML’s “observed value”.  “Result” is too generic. Please see comments on the wiki. https://www.w3.org/2015/spatial/wiki/Storing_Observation_Value


I would object such change as this closes the door on results that are not from observations (e.g., the actuator work), mixes the idea of a result (getting something back) with the value of what one gets back, and I fail to see how a naming issue can solve the thematic role discussion.

Best,
Jano



On 02/13/2017 08:33 AM, Kerry Taylor wrote:
I also prefer option 3, with some suggested changes. Most importantly that we use the term “ObservationValue” instead of “Result”. This is much better for backward compatibility (it was what ssn always used) and solves the “role” con that is raised too., and better complies with sensorML’s “observed value”.  “Result” is too generic. Please see comments on the wiki. https://www.w3.org/2015/spatial/wiki/Storing_Observation_Value


Btw – option 3 is incomplete as it is presented on the wiki.

-Kerry
From: Armin Haller
Sent: Monday, 13 February 2017 9:50 AM
To: janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>; Rob Atkinson <rob@metalinkage.com.au><mailto:rob@metalinkage.com.au>; Maxime Lefrançois <maxime.lefrancois@emse.fr><mailto:maxime.lefrancois@emse.fr>; Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>; danh.lephuoc@tu-berlin.de<mailto:danh.lephuoc@tu-berlin.de>; public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>; Kerry Taylor <kerry.taylor@anu.edu.au><mailto:kerry.taylor@anu.edu.au>
Subject: Re: hasResult / Sampling in SOSA & ISSUE-90

Yes, Option 3 will be the one I will put forward as a Proposal in our next teleconference. There was no objection yet on the list.

From: Krzysztof Janowicz <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>>
Reply-To: "janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>" <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>>
Date: Monday, 13 February 2017 at 9:09 am
To: Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>>, Maxime Lefrançois <maxime.lefrancois@emse.fr<mailto:maxime.lefrancois@emse.fr>>, "Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>" <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>>, Armin Haller <armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>>, "danh.lephuoc@tu-berlin.de<mailto:danh.lephuoc@tu-berlin.de>" <danh.lephuoc@tu-berlin.de<mailto:danh.lephuoc@tu-berlin.de>>, "public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>" <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>, Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>>
Subject: Re: hasResult / Sampling in SOSA & ISSUE-90

Looking at the comments and reactions so far, option 3 seems to be the favorite, right? Put differently, so far nobody called option 3 a deal-breaker.

[I am *not* implying any kind of formal vote here and I am not assuming that these comments imply a decision by the group. I am just trying to coordinate my actuation part with the observation part to keep them in sync and that would work well if we use option 3.]

On 02/10/2017 01:57 PM, Rob Atkinson wrote:

+1

Roles as classes in a polymorphic sense works.

Just noting that in the xml world the o&m placeholders worked but caused significant challenges (i.e. needed an explicit mechanism to map implementation types into these placeholders - i.e  the role needed to be handled outside the schema mechanism.

Rob

On Sat, 11 Feb 2017, 1:17 AM Maxime Lefrançois <maxime.lefrancois@emse.fr<mailto:maxime.lefrancois@emse.fr>> wrote:
Hi Simon,


> Result is a role, not a proper class

Yes, I agree. In O&M we left it as a wildcard, and that was when dealing only with observation results, which are at least only 'values'!

In SOSA the scope is explicitly increased to include Actuation and Sampling, the results of which are less clear. As mentioned in my mail earlier this week, the result of a sampling activity is primarily a new (or transformed) sample. Actuation usually changes the value of some property so is probably closer to the observation/sensing world.

Using OWL it is quite reasonable to model roles as classes. So I guess I would see sosa:Result as being a superclass of (at least) sosa:Sample and ssn:ObservationValue.

So preferably 3 than 4 for you ?

I added a section "proposed implem" for solution 3. Can you check this reflects your proposal ?

Kind regards,
Maxime



-----Original Message-----
From: Armin Haller [mailto:armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>]
Sent: Friday, 10 February, 2017 11:18
To: Le Phuoc, Danh <danh.lephuoc@tu-berlin.de<mailto:danh.lephuoc@tu-berlin.de>>; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au><mailto:Simon.Cox@csiro.au>; public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>; Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>>; Krzysztof Janowicz <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>>; Maxime Lefrançois <maxime.lefrancois@emse.fr<mailto:maxime.lefrancois@emse.fr>>
Subject: Re: hasResult / Sampling in SOSA & ISSUE-90

Thanks Danh for your detailed analysis of the Observation Value issue! I have added Option Numbers to the Wiki, to make it easier to refer to them.

I encourage everyone to look at the current proposals. As far as I can tell from previous discussions on the list several group members prefer Option 3, collapsing the property path in SOSA (and also in SSN) and not offering a hasValue relation. This also aligns to the decisions made in our best practices document. It also follows the Pareto principle.

I will watch the ensuing discussion and if there is a compromise emerging on the list, I will also try to put this issue for vote in our next meeting.

On 10/2/17, 2:07 am, "Le Phuoc, Danh" <danh.lephuoc@tu-berlin.de<mailto:danh.lephuoc@tu-berlin.de>> wrote:

    Hi all,

    As requested from Armin to outline a solution for attach values to observations as a part of the solution mentioned in this issue: https://www.w3.org/2015/spatial/track/issues/90, I  created a Wiki page at https://www.w3.org/2015/spatial/wiki/Storing_Observation_Value with some figures to illustrate the possible patterns : collapsing or not collapsing ssn:SensorOutput and ssn:ObservationValue.

    I’m trying to collecting inputs/proposals from previous minutes to populate the wiki page but I got lost. I would appreciate if you could point me to your proposals in the minutes or even better put them directly to the Wiki so that I could consolidate them before the next call.

    Best,

    Danh






--

Krzysztof Janowicz



Geography Department, University of California, Santa Barbara

4830 Ellison Hall, Santa Barbara, CA 93106-4060



Email: jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu>

Webpage: http://geog.ucsb.edu/~jano/<http://geog.ucsb.edu/%7Ejano/>

Semantic Web Journal: http://www.semantic-web-journal.net





--

Krzysztof Janowicz



Geography Department, University of California, Santa Barbara

4830 Ellison Hall, Santa Barbara, CA 93106-4060



Email: jano@geog.ucsb.edu<mailto:jano@geog.ucsb.edu>

Webpage: http://geog.ucsb.edu/~jano/


Semantic Web Journal: http://www.semantic-web-journal.net