RE: Multiple values in one observation

For sure. This is a perpetual dilemma.
If you want to multiplex results, then either
a) you have to construct and register a bunch of vector definitions somewhere
b) you have to use some local schema mechanism ( eg the anonymous node here) and have a self-configuring client.

Neither of these is particularly good, so Imho the safest is to only allow scalar or simple results, and have multiple observations.

Caveat lector - Sent from a tablet using TouchDown

________________________________
From: Raúl García Castro
Sent: Friday, 11 April 2014 8:08:13 AM
To: Cox, Simon (CLW, Highett); markus.stocker@gmail.com; allaves@fi.upm.es
Cc: public-xg-ssn@w3.org
Subject: Re: Multiple values in one observation

El 11/04/14 08:05, Simon.Cox@csiro.au escribió:
> How about
>
> :o1 rdf:type ssn:Observation .
> :o1 ssn:observedBy :mySensor1 .
> :o1 ssn:observedProperty [ a my:CompositeProperty
>        my:member :magnitude ;
>        my:member :depth . ] # or maybe an ordered list structure
> :o1 ssn:featureOfInterest :earthquakePhenomenon .
> :o1 ssn:observationResult :sensorOutput1 . # -> links to the observation values as an ordered list

Hi Simon,

This approach is also suggested in the report. However, I see different
drawbacks.

The first one is the creation of ad-hoc classes for grouping properties
(i.e., my:CompositeProperty) or features. People needs to know about
this class in order to correctly use your data.

The second and more important is the risk of losing the link between a
property and its observation value. In the example above, you don't know
which value is related to :magnitude and which one to :depth (order of
triples has no meaning in RDF).

Using ordered lists could be a solution. The problem here is that the
relationship between a property and its observation result is implicit
by your design decision but is not explicit in the model (i.e., I know
that the first member of this list is related to the first member of
this list but this is just in my head, not in the model).

This can be made explicit by adding these relations between list
elements (e.g., explicit indexes) but at the end the model gets
overcomplicated.

Kind regards,

> -----Original Message-----
> From: Markus Stocker [mailto:markus.stocker@gmail.com]
> Sent: Friday, 11 April 2014 1:36 AM
> To: Alejandro Llaves
> Cc: public-xg-ssn@w3.org
> Subject: Re: Multiple values in one observation
>
> Alejandro,
>
> Sorry, I guess I was too quick, looks like you want only :o1. Haven't seen that being used. Also, I wonder what is the advantage (i.e. why are you trying to achieve that)? Reduced triple count? Other advantages? In my understanding a sensor observation is for a property of a feature. Is it so that in your domain a sensor observes two properties in a single measurement process (I consider an observation to be the result of the process of measurement)?
>
> Cheers,
> Markus
>
>
> On Thu, Apr 10, 2014 at 6:23 PM, Markus Stocker <markus.stocker@gmail.com> wrote:
>> Hi Alejandro,
>>
>> Could something like this work?
>>
>> :o1 rdf:type ssn:Observation .
>> :o1 ssn:observedBy :mySensor1 .
>> :o1 ssn:observedProperty :magnitude .
>> :o1 ssn:featureOfInterest :earthquakePhenomenon .
>> :o1 ssn:observationResult :sensorOutput1 . # -> links to the
>> observation value
>>
>> :o2 rdf:type ssn:Observation .
>> :o2 ssn:observedBy :mySensor2 . # Possibly :mySensor1
>> :o2 ssn:observedProperty :depth .
>> :o2 ssn:featureOfInterest :earthquakePhenomenon .
>> :o2 ssn:observationResult :sensorOutput2 . # -> links to the
>> observation value
>>
>> Cheers,
>> Markus
>>
>>
>> On Wed, Apr 9, 2014 at 9:00 PM, Alejandro Llaves <allaves@fi.upm.es> wrote:
>>> Hi all,
>>>
>>> I read in the group's final report [1], section 5.3.6.1 Observation
>>> module, the following: "Observations of multiple features or multiple
>>> properties of the one feature should be represented as either
>>> compound properties, features and values or as multiple observations,
>>> grouped in some appropriate structure."
>>>
>>> Is there any working example where the SSN ontology is used with
>>> observations involving multiple properties, and thus multiple values?
>>>
>>> In our case, we are struggling with earthquake observations that
>>> include properties such as magnitude and depth, which belong to the
>>> same FOI: the earthquake phenomenon.
>>>
>>> Any thoughts on this?
>>>
>>> [1] http://www.w3.org/2005/Incubator/ssn/XGR-ssn/
>>>
>>> Alejandro
>>>
>>> --
>>> Alejandro Llaves
>>>
>>> Ontology Engineering Group (OEG)
>>>
>>> Facultad de Informática
>>>
>>> Universidad Politécnica de Madrid
>>>
>>> Avda. Montepríncipe s/n
>>>
>>> Boadilla del Monte, 28660 Madrid, Spain
>>>
>>> http://www.oeg-upm.net/
>>>
>>>
>>> allaves@fi.upm.es
>
>
>


--

Dr. Raúl García Castro
http://www.garcia-castro.com/

Ontology Engineering Group
Departamento de Inteligencia Artificial
Escuela Técnica Superior de Ingenieros Informáticos
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 65 96 - Fax: +34 91 352 48 19