Warning:
This wiki has been archived and is now read-only.

Storing Observation Value

From Spatial Data on the Web Working Group
Jump to: navigation, search

PLEASE NOTE THAT WE HAVE AGREED ON OPTION 3 - EXTENSIONS CAN NOW BE MADE TO OPTION 3 TO ANSWER REMAINING QUESTIONS


Option 1: Old SSN Observation and Value pattern

Error creating thumbnail: Unable to save thumbnail to destination

Pros

  • Generic pattern that can cover more observation value layout.

Cons

  • Depends on DOLCE.
  • Long-tail property-path to access to observation value, really verbose in data instantiation and introduce significant overhead for storage/query processing.
  • in the identified datasets that use SSN, no additional metadata is added to the SensorOutput.

Example

See also last section: Metadata associated with instances of SensorOutput and ObservationValue in referenced Datasets. 

@prefix oldssn: <http://purl.oclc.org/NET/ssnx/ssn#> .
@base <http://smartcity.linkeddata.es/lcc/> .

<resource/Observation/GasCouncilOfficesBelgraveHouse-2010-2011> a oldssn:Observation ;
 ssn:observationResult <resource/SensorOutput/GasCouncilOfficesBelgraveHouse-2010-2011> .

<resource/SensorOutput/GasCouncilOfficesBelgraveHouse-2010-2011> a oldssn:SensorOutput ;
 oldssn:hasValue <resource/ObservationValue/GasCouncilOfficesBelgraveHouse-2010-2011> .

<resource/ObservationValue/GasCouncilOfficesBelgraveHouse-2010-2011> 
  <ontology/EnergyConsumption#hasQuantityUnitOfMeasurement> <http://www.wurvoc.org/vocabularies/om-1.8/kilowatt_hour> ;
  <ontology/EnergyConsumption#hasQuantityValue> 199491 .

Option 2: SOSA pattern for Observation and Value: Collapsing ObservationValue and SensorOutput (current version at https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl)

Error creating thumbnail: Unable to save thumbnail to destination

Pros

  • Shorter property-path to store observation value
  • Does not depend on DOLCE

Cons

  • The restriction of hasValue to owl:DatatypeProperty will not cover the Observation Value that can be expressed by an RDF literal/OWL data object, e.g, multi-dimensional value.
  • Needs more work to align with old SSN.
  • hasValue becomes a owl:DatatypeProperty -> may confuse previous SSN users that used it as a ObjectProperty
  • where to put the unit of measure?
  • hasValue conflicts with well established vocabulary terms qudt:numericValue, om:numerical_value, ...
  • hasValue conflicts with http://schema.org/value

Example

Example: 

@prefix sosa: <http://www.w3.org/ns/sosa/> .
@prefix prov: <http://www.w3.org/ns/prov#> .

<observation/12> a sosa:Observation ;
 prov:generatedAtTime "2016-08-12T12:00:00Z"^^xsd:dateTime ;
 sosa:hasResult [ 
   sosa:hasValue 12.3 ;
   abc:xyz abc:degreeCelsius 
 ] .

Winning -- Option 3: SOSA pattern for Observation and Value: remove hasValue, keep class Result

Error creating thumbnail: Unable to save thumbnail to destination

Pros

  • Shorter property-path to store observation value
  • Does not depend on DOLCE
  • sosa:hasResult can directly link to an instance of qudt:QuantityValue, om:Measure, or a more complex OWL data object, e.g., multi-dimensional value.
  • no conflict with schema:value, could use it directly to structure data

Cons

  • Result is a role, not a proper class


Proposed implementation

ssnx.ttl 

oldssn:SensorOutput a owl:Class ;
  rdfs:label "Sensor Output"@en ;
  skos:definition "A sensor outputs a piece of information (an observed value), the value itself being represented by an ObservationValue."@en ;
  dc:source """http://www.w3.org/2005/Incubator/ssn/
  
  skos:closeMatch 'observation result' [O&M]
  http://www.opengeospatial.org/standards/om
  
  See comments at ObservationValue.""" ;
  rdfs:seeAlso "http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Skeleton#Skeleton" ;
  rdfs:subClassOf [ owl:onProperty oldssn:hasValue ; owl:someValuesFrom oldssn:ObservationValue ] .
  rdfs:subClassOf [ owl:onProperty oldssn:isProducedBy ; owl:someValuesFrom oldssn:Sensor ] ;
  owl:deprecated true ;
  rdfs:subClassOf sosa:Result ;
  rdfs:isDefinedBy <http://purl.oclc.org/NET/ssnx/ssn> ;
  
oldssn:ObservationValue a owl:Class ;
  rdfs:label "Observation Value"@en ;
  rdfs:comment "The value of the result of an Observation.  An Observation has a result which is the output of some sensor, the result is an information object that encodes some value for a  Feature."@en ;
  dc:source """skos:exactMatch 'measured quantity value' [VIM 2.10]
  http://www.bipm.org/utils/common/documents/jcgm/JCGM_200_2008.pdf
  
  skos:exactMatch 'observed value' [SensorML OGC-0700]
  http://www.opengeospatial.org/standards/sensorml
  
  skos:closeMatch 'observation result' [O&M]
  http://www.opengeospatial.org/standards/om
  
  O&M conflates what we have as SensorOutput and ObservationValue into observation result, though the OGC standard does say \"result contains a value\" and \"a result which has a value\", which fits naturally with the model here.""" ;
  rdfs:seeAlso "http://www.w3.org/2005/Incubator/ssn/wiki/SSN_Base#Data" ;
  owl:deprecated true ;
  rdfs:subClassOf sosa:Result ;
  rdfs:isDefinedBy <http://purl.oclc.org/NET/ssnx/ssn> ;

Kerry: Another lighter-touch here for ssn is to leave SensorOutput and ObservationValue in place and define hasResult to be the composition of observationResult o hasValue.

Armin: SSNX would still have these concepts, but deprecates them and relates them to the new sosa:Result. This modelling choice makes SOSA and SSN easier, an argument you made in https://www.w3.org/2015/spatial/track/issues/90 yourself.

Kerry: Does "hasResult" need to point to a Result? why? Should it be an ObservationValue instead of Result (fixes the con above) --- and then the ssn compatibility is much better.

Armin: There were arguments on the list for ObservationValue and ActuationResult and/or SamplingResult to be more specific cases of the Result Class. For SOSA only having one makes it easier to use. SSN could include the following relations: ssn:ObservationValue rdfs:subClassOf sosa:Result and ssn:ActuationResult rdfs:subClassOf sosa:Result .

Kerry: Also, it is not clear what happens to isProducedBy?

Armin: Remains for now unchanged as it can also be used for relating Processes to Outputs.

Kerry: Note that SENSORML uses "observed value" for this concept. -- Much better idea

Armin: The proposed name stems from O&M.

Kerry: ssnx alignment does not help oldssn users to transition - can we do better?

Armin: The above does, but extra ssn:ObservationValue rdfs:subClassOf sosa:Result and ssn:ActuationResult rdfs:subClassOf sosa:Result could be introduced to complete the transition.


sosa.ttl 

sosa:Result a rdfs:Class, owl:Class ;
   rdfs:label "Result"@en ;
   skos:definition """The Result of an Observation, Actuation, or Sampling. Such result can, for instance, store an observation's value via the hasValue property.
  
   The result may be an instance of sosa:Sample, an instance of qudt:QuantityValue, om:Measure, or any other OWL individual."""@en ;
   skos:example "The value of 20m as the height of a certain tree."@en .

ssn.ttl 

# what would be the equivalent axiom for sosa:Result ?
# it should be somehow equivalent to  rdfs:subClassOf [ owl:onProperty oldssn:isProducedBy ; owl:someValuesFrom oldssn:Sensor ] ;
# but more general, because Actuators can also generate results. 

sosa:Result rdfs:subClassOf [ owl:onProperty sosa:isResultOf ; owl:someValuesFrom ???ssn:ProcedureExecutor??? ] ;

Example

Example with QUDT 2.0: 

@prefix sosa: <http://www.w3.org/ns/sosa/> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix qudt: <http://qudt.org/schema/qudt/> .
@prefix unit: <http://qudt.org/vocab/unit/> .

<observation/12> a sosa:Observation ;
 prov:generatedAtTime "2016-08-12T12:00:00Z"^^xsd:dateTime ;
 sosa:hasResult [
   a sosa:Result ;
   a qudt:QuantityValue ;
   qudt:numericValue 12.3 ;
   qudt:unit unit:DEG_C ] .

Example with OM 1.8: 

@prefix sosa: <http://www.w3.org/ns/sosa/> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix om: <http://www.wurvoc.org/vocabularies/om-1.8/> .

<observation/12> a sosa:Observation ;
 prov:generatedAtTime "2016-08-12T12:00:00Z"^^xsd:dateTime ;
 sosa:hasResult [
   a sosa:Result ;
   a om:Measure ;
   om:numerical_value 12.3 ;
   om:unit_of_measure_or_measurement_scale om:degree_Celsius ] .

Example with schema.org (schema:result already exists, we just need to assume the existence of schema:Observation): 

 <div itemscope itemtype="http://schema.org/Observation" itemid="#observation">
   <div itemscope itemprop="result"
        itemtype="http://schema.org/QuantitativeValue">Result:
     <span itemprop="value">12.3</span>°C
     <meta itemprop="unitCode" content="CEL">
   </div>
 </div>

Option 4: Collapsing ObservationValue and SensorOutput, remove class Result (proposal in https://lists.w3.org/Archives/Public/public-sdw-wg/2017Feb/0168.html)

Error creating thumbnail: Unable to save thumbnail to destination


Pros

  • Shorter property-path to store observation value
  • does not depend on DOLCE
  • sosa:hasResult can directly link to an instance of qudt:QuantityValue, om:Measure, or a more complex OWL data object, e.g., multi-dimensional value.

Cons

  • The restriction of hasValue to owl:DatatypeProperty will not cover the Observation Value that can be expressed by an RDF literal/OWL data object, e.g, multi-dimensional value.
  • Needs more work to align with old SSN.
  • hasValue becomes a owl:DatatypeProperty -> may confuse previous SSN users.
  • where to put a unit of measure?

Example

Example with QUDT 2.0: 

@prefix sosa: <http://www.w3.org/ns/sosa/> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix qudt: <http://qudt.org/schema/qudt/> .
@prefix unit: <http://qudt.org/vocab/unit/> .

<observation/12> a sosa:Observation ;
 prov:generatedAtTime "2016-08-12T12:00:00Z"^^xsd:dateTime ;
 sosa:hasResult [
   a qudt:QuantityValue ;
   qudt:numericValue 12.3 ;
   qudt:unit unit:DEG_C ] .

Example with OM 1.8: 

@prefix sosa: <http://www.w3.org/ns/sosa/> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix om: <http://www.wurvoc.org/vocabularies/om-1.8/> .

<observation/12> a sosa:Observation ;
 prov:generatedAtTime "2016-08-12T12:00:00Z"^^xsd:dateTime ;
 sosa:hasResult [
   a om:Measure ;
   om:numerical_value 12.3 ;
   om:unit_of_measure_or_measurement_scale om:degree_Celsius ] .

Example with schema.org (schema:result already exists, we just need to assume the existence of schema:Observation): 

 <div itemscope itemtype="http://schema.org/Observation" itemid="#observation">
   <div itemscope itemprop="result"
        itemtype="http://schema.org/QuantitativeValue">Result:
     <span itemprop="value">12.3</span>°C
     <meta itemprop="unitCode" content="CEL">
   </div>
 </div>

Option 5: SOSA pattern for Observation and Value: without Collapsing ObservationValue and SensorOutput

Error creating thumbnail: Unable to save thumbnail to destination


Pros

  • Easier to align with old SNN
  • Does not depend on DOLCE

Cons

  • Might have the same issues of old SSN.

Best Practices in Storing Observation Values=

  • [TODO:put concrete working example here]

Other issues on relevant properties: hasResult,hasSample

  • Simon: Should the rangeIncludes of sosa:hasResult also mention sosa:Sample?

A SamplingActivity, using a SamplingDevice to implement a SamplingProcedure, would usually generate or transform a Sample ...

This might also need a tweak to the definition of sosa:Result - i.e. Either sosa:Result would not always apply to a SamplingActivity Else there is some complicated partial intersection of sosa:Result and sosa:Sample

We don't want to take all this too far in SOSA, since most details of Sampling will be formalized in another vertical extension/axiomatic-refinement to SOSA (parallel with SSN), but in the context of SOSA we may need to allow for all clearly anticipated options.

kjanowicz: In option 3 etc, we would use sosa:resultTime and not prov:generatedAtTime,right?

Metadata associated with instances of SensorOutput and ObservationValue in referenced Datasets

Objective: see in the datasets that are referenced at http://w3c.github.io/sdw/ssn-usage/ what usage is done of SensorOutput and ObservationValue.

Metadata associated with SensorOutput

PREFIX ssn:	 <http://purl.oclc.org/NET/ssnx/ssn#>
SELECT DISTINCT ?p WHERE {
 { ?x a ssn:SensorOutput } UNION { [] ssn:observationResult ?x}
 ?x ?p ?y .
} LIMIT 100

D1, D2, D6, D7, D8, D9: none

D3: none

D4:

  • rdf:type
  • ssn:hasValue

D5:

  • rdf:type
  • rdfs:label
  • ssn:hasValue

D10

  • rdf:type
  • rdfs:comment
  • ssn:hasValue

D11: SPARQL-endpoint unreachable


Metadata associated with ObservationValue

PREFIX ssn:	 <http://purl.oclc.org/NET/ssnx/ssn#>
SELECT DISTINCT ?p WHERE {
 { ?x a ssn:ObservationValue } UNION { [] ssn:hasValue ?x}
 ?x ?p ?y .
} LIMIT 100

D1, D2, D6, D7, D8, D9 none


D3:

D4:

D5:

D10

  • rdf:type
  • rdfs:comment
  • DUL:hasDataValue
  • DUL:isClassifiedBy

D11: SPARQL-endpoint unreachable

Retrieved from "https://www.w3.org/2015/spatial/wiki/index.php?title=Storing_Observation_Value&oldid=3209"