Re: hasResult / Sampling in SOSA & ISSUE-90

I would be also fine with option 3 (or 5). Am I right assuming that we 
would use sosa:resultTime and not prov:generatedAtTime ? Also, can you 
(or should I) add another pro to option 5, namely that it would allow 
the SOSA target audience to immediately store result values without 
having to read up on QUDT, O&M, and so forth? This may be an important 
issue as far as reducing the entry hurdles is concerned. There are also 
many possible ways in which the red box in O5 could be modeled nicely 
without restricting the kind of result value framework to be used.

Jano


On 02/09/2017 04:35 PM, Simon.Cox@csiro.au wrote:
> Yes, thanks Danh.
>
> Under Option 3 you note
>
>> 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.
>
> -----Original Message-----
> From: Armin Haller [mailto:armin.haller@anu.edu.au]
> Sent: Friday, 10 February, 2017 11:18
> To: Le Phuoc, Danh <danh.lephuoc@tu-berlin.de>; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; public-sdw-wg@w3.org; Kerry Taylor <kerry.taylor@anu.edu.au>; Krzysztof Janowicz <janowicz@ucsb.edu>; Maxime Lefrançois <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> 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

Received on Friday, 10 February 2017 04:26:59 UTC