Re: hasResult / Sampling in SOSA & ISSUE-90

+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>
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]
> 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
>
>
>
>
>
>