Re: Multiple values in one observation

Thanks, Simon et al.!

After discussing my problem with Raúl, we agreed on having multiple
one-value-one-property observations connected by the same instance of FOI.
Basically, what Markus answered first. For instance:

:earthquake_2013-09-01T01:02:02Z_W-FRONTERA-IHI rdf:type
ssn:FeatureOfInterest .

:o1 rdf:type ssn:Observation .
:o1 ssn:observedProperty sweet:magnitude .
:o1 ssn:featureOfInterest :earthquake_2013-09-01T01:02:02Z_W-FRONTERA-IHI .
:o1 ssn:observationResult :sensorOutput1 .

:o2 rdf:type ssn:Observation .
:o2 ssn:observedProperty sweet:depth .
:o2 ssn:featureOfInterest :earthquake_2013-09-01T01:02:02Z_W-FRONTERA-IHI .
:o2 ssn:observationResult :sensorOutput2 .

@Markus: I was looking for a way of reducing the amount of triples, yes. In
stream processing environments with much higher throughput than in the
earthquake monitoring context, decreasing the volume of transferred data
may derive in a more efficient processing.

Cheers,
Alejandro


2014-04-11 14:48 GMT+02:00 <Simon.Cox@csiro.au>:

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


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