Allow to directly attach a value to the property of a feature of interest

[maximelefrancois86]

It's an overkill to use procedures and observations to model the simple situation when some property of a feature of interest has a stable/constant value.

For example:

• the size of apartment 134 in example B.3 is 54.6 m2
• the maximum measurable wind speed of the wind sensor in example B.7 is 105 km/h
• the average sensing period of sensor DHT22 is 2 s
• the minimum voltage for the dc power supply of sensor DHT22 is 3.3 V
• the minimum operating temperature of the DHT22 is -40 °C

It would be a pity not to rely on the SOSA/SSN way of modeling these properties (size, maximum measurable wind speed, etc.)

It would also be an overkill to rely on procedures and observations in each of these situations.

My proposal is: introduce the class sosa:PropertyValue, to allow to use sosa:hasProperty to directly link a feature of interest to a sosa:PropertyValue, and to define sosa:isValueOfProperty to link back to the property for which a value is given.

sosa:PropertyValue

Class sosa:PropertyValue describes a situation where a property has a certain value. Links to the feature of interest it belongs to using sosa:isPropertyOf. Links to the property for which a value is given using sosa:isValueOfProperty.

EXAMPLE the size of apartment 134 in example B.3 is 54.6 m2:

<apartment/134> sosa:hasProperty [
  a sosa:PropertyValue ;
  qudt:numericValue 24.6 ;
  qudt:unit unit:M2 ;
  sosa:isValueOfProperty quantitykind:Area 
]

EXAMPLE the minimum operating temperature of the DHT22 is -40 °C

<DHT22> a sosa:SensorKind ;
  sosa:hasProperty [
    a sosa:PropertyValue ;
    qudt:numericValue -40.0 ;
    qudt:unit unit:DEG_C ;
    sosa:isValueOfProperty <minimum_operating_temperature>
  ]

NOTE: the result of an observation could be classified both as sosa:Result, and sosa:PropertyValue

NOTE: property value mimics the class qudt:QuantityValue from QUDT.

[maximelefrancois86]

By the way, that would simplify SSN-System a lot:

<average_accuracy_at_12_DEG_C> a ssn:PropertyKind , ssn-system:Accuracy ;
   ssn:inCondition [
    qudt:numericValue 12 ;
    qudt:unit unit:DEG_C 
  ] .

<DHT22> a sosa:SensorKind ;
  sosa:hasProperty [
    a sosa:PropertyValue ;
    qudt:numericValue 0.5 ;
    qudt:unit unit:DEG_C ;
    sosa:isValueOfProperty <average_accuracy_at_12_DEG_C>
  ]

[dr-shorthair]

This analysis appears to arise from a context where some property values are defined a priori and are thus exact. Looking at the ones in the examples above, I'm not sure that I agree. All of those properties might be designed with those values, however the actual values can only be determined by observation, and will be subject to error or uncertainty.

However, I wonder if you are attempting to apply SOSA outside its original scope, creating a general entity-description language.

Some other takes on this:

A.

In ISO 19109 three kinds of property value assignment are described:

1. assertion - where the value is assigned by a competent authority (e.g. price by a vendor, ownership by a land titles office)
2. derivation - where the value is a consequence of some other properties (e.g. a classification derives from a combination of simple properties)
3. observation, with a systematic and random error arising from a procedure and observer

Only the last of these is in scope for O&M (SOSA). The rest of ISO 19109 does indeed establish the framework for general feature models.

B.

The OBOE ontology from DataONE models all values the same - which includes observation metadata. They argue that this simplifies data management by putting it all in one structure.

[maximelefrancois86]

When a manufacturer publishes a datasheet about some feature type/kind, they assign values to some performances or other characteristics of the feature (e.g. average value, a typical value, a typical range, engineering tolerances, or a nominal value)

It doesn't mean an observation of that property of a specific feature of interest of this kind would actually yield the exact same value.

This maybe adds up another kind of property value assignment to the three ones described in ISO 19109:

4. determination/specification - where the value is asserted by an authoritative source such as the manufacturer of the feature (e.g. average value, a typical value, a typical range, engineering tolerances, or a nominal value)

Even if assertion and derivation are out of the scope of O&M, do you think it could be relevant and useful to include them in SOSA/SSN as other possible sub-classes of sosa:ProcedureExecution ?

This aside, how does ISO 19109 and O&M deal with physics constants ? for example if physics particles electron, proton, neutron, muon, tau,... are defined as feature kinds, then their mass would be constants. Are they asserted ?

[dr-shorthair]

@maximelefrancois86 and @alexrobin I suggest you guys collaborate on the topic of describing systems and sensors.

However, my inclination is that this belongs in a separate module, outside SOSA core. Unclear at this stage if that would use the sosa: namespace.

[oldskeptic]

Certain sensors / systems make use of "magic values" to indicate values out of range, sensor faults or missing data. While everyone here likely knows a horror story involving this practice, it is still used.

NETCDF has the _FillValue attribute to record this; where does this fit in SOSA/SSN?

[dr-shorthair]

@maximelefrancois86 is this issue affected by #126 ?

[dr-shorthair]

The other risk here is that it starts looking like a general modeling language. This is kinda what ISO 19109 did. The 2013 update did attempt to integrate O&M ideas, but I'm not sure that anyone really uses 19109.

I think we should steer clear and try to stay in our lane.

[dr-shorthair]

Can we close this? @maximelefrancois86 @oldskeptic ?

[KathiSchleidt]

I DO like this approach, mirrors thoughts I've recently been having on a slightly different use case.

Background is the realization that in many (most) use cases using observational data, there are often actually two distinct sub-use-cases:

• Check if the data is fit for purpose. Here you need all the nitty-gritty details SOSA provides
• Once the data source has been checked, all that's often needed is just a geometry and a number

At the same time, not sure we really need this nailed down in SOSA, as we could probably define the same with a bit of creative refactoring. Could maybe be created as an extension to keep communities following such an approach aligned.