search

w3c / sdw-sosa-ssn

Repository of the Spatial Data on the Web Working Group for the SOSA/SSN vocabulary
7 stars 5 forks source link

sosa:Property values versus result values. #208

Open oldskeptic opened 3 months ago

oldskeptic commented 3 months ago

In #quantity-values-and-unit-of-measures we state "It is not in the scope of this specification to recommend any particular way of expressing results as quantity values." which is fine. To actually link the measurement, however it is recorded, to an observation we use hasSimpleResult / hasResult. There is no analogous mechanism for ssn-system:Condition, ssn:Property, ssn-system:Sensitivity, etc...

The DHT22 Description example makes use of schema.org. Unlike in an Observation, there is no ontological relationship in Sosa that indicates where the value of a Property resides, irrespective of it is expressed.

Can we fix this?

maximelefrancois86 commented 3 months ago

The SSN-System module and the examples could be improved in many ways. When working on that back in 2017, I faced two challenges:

  1. There is no other way to assign a value to a property than going through a sosa:Observation, yet expressing a simple sensitivity value found in a datasheet doesn't really match the definition of sosa:Observation: there is no sensor that observed this value.
  2. How to express the Ranges, that actually correspond to two values ?

Now that properties apply generically to many features of interest, and the notion of sensor is generalized, I think we could makes things more homogeneous:

  1. We should define Sensitivity etc. as instances of sosa:Property instead of sub-classes .
  2. For when a system property has a simple value that doesn't depend on conditions of any sort, we should rely on a mechanism similar to the one introduced in SAREF V3.2.1: saref:hasPropertyValue, and saref:PropertyValue. See https://saref.etsi.org/core/v3.2.1/#5.6.4
  3. When a system property value depends on a condition, one could use sosa:Observation annotated with sosa:inCondition.
  4. For all range property X, we should split them in minimumX and maximumX. For example instead of MeasurementRange: 
ssn-system:MinimumMeasurement a sosa:Property;
      rdfs:label "Minimum Measurement"@en ;
      skos:definition "The minimum of the set of values that the Sensor can return as the Result of an Observation under the defined Conditions."@en ;
      skos:broader ssn-system:SystemProperty ;
      rdfs:isDefinedBy ssn-system: .

ssn-system:MaximumMeasurement a sosa:Property;
      rdfs:label "Maximum Measurement"@en ;
      skos:definition "The maximum of the set of values that the Sensor can return as the Result of an Observation under the defined Conditions."@en ;
      skos:broader ssn-system:SystemProperty ;
      rdfs:isDefinedBy ssn-system: .
oldskeptic commented 3 months ago

I would be happy with reusing hasResult or creating hasPropertyValue. We don't have to solve the range problem as much as just document a property for the value.

We should define Sensitivity etc. as instances of sosa:Property instead of sub-classes .

I prefer subClass; otherwise it becomes unwieldy if someone decides to instantiate the Sensitivity of multiple physical receivers.

dr-shorthair commented 1 month ago

I would be happy with ... creating hasPropertyValue ...

Hmm. FeatureOfInterest is essentially a way of tagging features/entities from domain models with a role in the context of Actuations/Observations/Samplings - see discussion in https://github.com/w3c/sdw-sosa-ssn/issues/19 Otherwise, I would be very wary of building a meta-language for domain-models inside SSN, which I think is what you are talking about with Feature-Property relationships outside the context of Observations and Actuations.

dr-shorthair commented 1 month ago

Also see #108