W3C home > Mailing lists > Public > public-sdw-wg@w3.org > February 2017

Re: hasResult / Sampling in SOSA & ISSUE-90

From: Maxime Lefrançois <maxime.lefrancois@emse.fr>
Date: Mon, 13 Feb 2017 17:11:09 +0000
Message-ID: <CALsPASU+Lydg0N2kfcSmd=Oe8DHsCvqj_9=-tRGvnpm=1cDvnw@mail.gmail.com>
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" <Simon.Cox@csiro.au>, "danh.lephuoc@tu-berlin.de" <danh.lephuoc@tu-berlin.de>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
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> 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; Rob Atkinson <rob@metalinkage.com.au>
> <rob@metalinkage.com.au>; Maxime Lefrançois <maxime.lefrancois@emse.fr>
> <maxime.lefrancois@emse.fr>; Simon.Cox@csiro.au; danh.lephuoc@tu-berlin.de;
> public-sdw-wg@w3.org; Kerry Taylor <kerry.taylor@anu.edu.au>
> <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>janowicz@ucsb.edu>
> *Reply-To: *"janowicz@ucsb.edu" <janowicz@ucsb.edu>
> *Date: *Monday, 13 February 2017 at 9:09 am
> *To: *Rob Atkinson <rob@metalinkage.com.au>, Maxime Lefrançois <
> maxime.lefrancois@emse.fr>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>,
> Armin Haller <armin.haller@anu.edu.au>, "danh.lephuoc@tu-berlin.de" <
> danh.lephuoc@tu-berlin.de>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>,
> Kerry Taylor <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>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>
> armin.haller@anu.edu.au]
> Sent: Friday, 10 February, 2017 11:18
> To: Le Phuoc, Danh < <danh.lephuoc@tu-berlin.de>danh.lephuoc@tu-berlin.de>;
> Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au> <Simon.Cox@csiro.au>;
> public-sdw-wg@w3.org; Kerry Taylor <kerry.taylor@anu.edu.au>; Krzysztof
> Janowicz < <janowicz@ucsb.edu>janowicz@ucsb.edu>; Maxime Lefrançois <
> <maxime.lefrancois@emse.fr>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>
> 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
>
> Webpage: http://geog.ucsb.edu/~jano/
>
> 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
> Webpage: http://geog.ucsb.edu/~jano/
> Semantic Web Journal: http://www.semantic-web-journal.net
>
>
Received on Monday, 13 February 2017 17:11:55 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:29 UTC