Distinguish `Property` and `PropertyOfInterest`

[maximelefrancois86]

There still is a confusion between whether properties should be specific or generic to features of interest.

This ambiguity is reported in https://www.w3.org/TR/vocab-ssn/#SSNProperty-instances

See also footnote 10 in Haller, Armin, et al. "The modular SSN ontology: A joint W3C and OGC standard specifying the semantics of sensors, observations, sampling, and actuation." Semantic Web 10.1 (2019): 9-32.

In SSNX, the class of observable properties was defined as a subclass of dul:Quality and as the class of “observable Quality of an Event or Object. That is, not a quality of an abstract entity as is also allowed by DUL’s Quality, but rather an aspect of an entity that is intrinsic to and cannot exist without the entity and is observable by a sensor.” Section 5.3.1.3.4 in [36] further adds that types of properties, such as temperature or pressure should be added as subclasses of oldssn:ObservedProperty instead of individuals. Yet, usage reports [19] of SSNX revealed that most datasets were using observable properties as applicable to many features of interest. See https://www.w3.org/2015/spatial/wiki/What_is_an_instance_of_ssn:Property for more details on this point

Some users of SOSA use ssn:Property to classify properties that can be generically used on many features of interest. One advantage is that existing code lists, vocabularies, and taxonomies, may be used. For example:

• the QUDT Quantity Kind vocabulary (ex: Nozzle Walls Thrust Reaction,
• the British Oceanographic Data Centre Parameter Usage Vocabulary (ex: Absolute temperature standard deviation of the atmosphere by dry bulb thermometer),
• the ETIM classification standard for technical products (ex: Tray width in horizontal direction), etc.

Other users of SOSA use ssn:Property to classify properties that are specific to one feature of interest. Below are a few papers and ontologies that use SOSA/SSN with this modeling choice:

• Rasmussen, M. H., Lefrançois, M., Pauwels, P., Hviid, C. A., & Karlshøj, J. (2019). Managing interrelated project information in AEC Knowledge Graphs. Automation in Construction, 108, 102956.
• Esnaola-Gonzalez, I., Bermúdez, J., Fernandez, I., & Arnaiz, A. (2020). Ontologies for observations and actuations in buildings: A survey. Semantic Web, 11(4), 593-621.
• Esnaola-Gonzalez, I., Bermúdez, J., Fernandez, I., & Arnaiz, A. (2021). EEPSA as a core ontology for energy efficiency and thermal comfort in buildings. Applied Ontology, 16(2), 193-228.
• Donkers, A., de Vries, B., & Yang, D. (2022). Creating occupant-centered digital twins using the Occupant Feedback Ontology implemented in a smartwatch app. Semantic Web, (Preprint), 1-26.
• Klotz, B., Troncy, R., Wilms, D., & Bonnet, C. (2018, October). VSSo: The Vehicle Signal and Attribute Ontology. In SSN@ ISWC (pp. 56-63).
• Klotz, B., Troncy, R., Wilms, D. "VSSo: Vehicle Signal Specification Ontology". W3C First Public Working Draft 03 March 2022. W3C Automotive Working Group https://www.w3.org/TR/vsso/
• Graupner, A., & Nüst, D. (2020). Serverless GEO labels for the semantic sensor web. In 11th International Conference on Geographic Information Science (GIScience 2021)-Part I. Schloss Dagstuhl-Leibniz-Zentrum für Informatik.
• Esnaola-Gonzalez, I., Bermúdez, J., Fernandez, I., & Arnaiz, A. (2021). Two ODPs Towards the Notion of Influenceable Features of Interest. In Advances in Pattern-Based Ontology Engineering (pp. 89-106). IOS Press.
• Holten, M., Rasmussen, C. A. F., Hviid, C. A., & Karlshø, J. (2018). Integrating building information modeling and sensor observations using semantic web. In 9th International Semantic Sensor Networks Workshop (pp. 1-9).
• Alvarez-Coello, D., Wilms, D., Bekan, A., & Gómez, J. M. (2021, January). Generic semantization of vehicle data streams. In 2021 IEEE 15th International Conference on Semantic Computing (ICSC) (pp. 112-117). IEEE.

My proposal to disambiguate the concept while maintaining backward compatibility with these different usages would be to split sosa:Property (formerly ssn:Property) in two classes:

sosa:PropertyKind

An instance of sosa:PropertyKind can apply to different features of interest. Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of sosa:PropertyKind.

EXAMPLE: Air temperature, pressure, luminance, etc. are all property kinds.

NOTE: Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of sosa:PropertyKind.

sosa:PropertyOfInterest

An instance of sosa:PropertyOfInterest is specific to a feature of interest. It is inherent to and cannot exist without that feature of interest. A property of interest is the property of (OP sosa:isPropertyOf) exactly one feature of interest.

sosa:PropertyOfInterest a owl:Class ;
  rdfs:subClassOf sosa:Property ;
  rdfs:subClassOf [
    owl:onProperty sosa:isPropertyOf ; 
    owl:onClass sosa:FeatureOfInterest ;
    owl:cardinality 1 ] .

EXAMPLE: The air temperature of the atmosphere sample at a certain location and altitude, the received signal strength indicator of an wireless IoT connection, the temperature of a specific room.

[dr-shorthair]

Would sosa:PropertyKind also be a sub-class of sosa:Property? I think this would be necessary to support backward compatibility of instances.

Note that items in the NVS P01 vocabulary are linked to more generic qualities listed in the NVS S06 vocabulary

(The S06 value sits alongside various other attributes of the parameter description - see https://github.com/CSIRO-enviro-informatics/PUV-ont .
The very large number of items in P01 is due to the combinatorial explosion arising from the several smaller sets.)

[maximelefrancois86]

Indeed, sosa:PropertyKind would be defined as a sub-class of sosa:Property, to allow for backward compatibility.

sosa:PropertyKind a owl:Class ;
  rdfs:subClassOf sosa:Property ;
  rdfs:label "Property Kind"@en ;
  skos:definition "Characteristic of a feature kind. An instance of sosa:PropertyKind can apply to different features of interest."@en ;
  rdfs:comment "Characteristic of a feature kind. An instance of sosa:PropertyKind can apply to different features of interest."@en ;
  skos:note "Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of sosa:PropertyKind."@en ;
  skos:note "The value for an instance of an observable property kind can be estimated through an act of observation."@en ;
  skos:note """In chemistry-related applications, the term “determinand” or “analyte” is often used."""@en ;
  skos:example "Air temperature, pressure, luminance, etc. are all property kinds."@en ;
  skos:example "Cars (a feature kind) all have a characteristic colour, where “colour” is a property kind."@en ;
  rdfs:subClassOf [ a owl:Restriction ; owl:onProperty sosa:isPropertyOf ; owl:allValuesFrom sosa:FeatureOfInterest ]  ;
  rdfs:isDefinedBy ssn: .

[maximelefrancois86]

As part of our work at ETSI on the development of a new version of SAREF, we reached last week an agreement on how to solve this issue. This is implemented in PR #126

Note that this is a compromise that resolves a six year long dispute between two former contributors to SOSA/SSN 😉, so I hope it will be well received by the group.

[KathiSchleidt]

I much like this differentiation, only have the question of the relation between sosa:PropertyOfInterest and sosa:PropertyKind

Continuing with @maximelefrancois86 examples, how could one indicate that the sosa:PropertyOfInterest::temperature of a specific room is a specific instance of sosa:PropertyKind::air temperature?

[maximelefrancois86]

Note the proposal is to go for: sosa:Property and sosa:PropertyOfInterest. The two reasons for this change are:

• avoid having a common super-class that we hope nobody will use
• sosa:Property is already most commonly used to represent generic properties

Continuing with @maximelefrancois86 examples, how could one indicate that the sosa:PropertyOfInterest::temperature of a specific room is a specific instance of sosa:PropertyKind::air temperature?

Good question. This would be the next thing to decide. At the moment our proposal is to introduce an object property hasPropertyKind. Turtle equivalent of your example:

<taxonomy/air_temperature> a sosa:Property .

<dataset/room/429#temperature> a sosa:PropertyOfInterest ;
  sosa:hasPropertyKind  <taxonomy/air_temperature> .

We also include two object properties to organize properties in a taxonomy. Current proposal is: hasNarrowerProperty and hasBroaderProperty.

[sgrellet]

While I understand the underlying semantic distinction I think it will be hard to achieve at the implementation level.

In many environmental and scientific domains I'm working with, we already have hard time setting up clean and maintained reference linked data registries of observable properties (and methods etc...). BODC is a good one that succeeds but this is a success that's hard to achieve.

I don't see how we could succeed in a reasonable amount of time

• maintaining both Properties and PropertiesOfInterest registries
• and successfully explain which one to use in which context to people that may not get the abstraction. There are many people stuck at the hierarchical thesaurus approach

I think the scope of SOSA is not in describing every possible domain ontology (river, geology, soil, ...) that will declare the properties that can be observed on a given feature.

But we could come up with a middle-ground pattern

• to have sosa:PropertyKind to cover the generic approach, and point to it in the context of an observation (sosa:observedProperty),
• and suggest that in domain ontologies one could list/poin to the various PropertyOfInterest applicable to a Feature using
  • an Object Property called propertyOfInterest (would be more like an association role in UML) which we could define in SOSA. having sosa:PropertyKind for Range and Domain open (to maximise reuse in domain ontologies)
  • or a constraints (SHACL ?) pointing to linked data registries of sosa:PropertyKind

[maximelefrancois86]

PropertyOfInterest is not intended to be described in registries, nor to be instantiated in domain ontologies. It's useful in actual applications, where the association between a feature of interest and a property (i.e., the property of interest) needs to be identified and related to other properties of interest.

In our ongoing work on SAREF, more specifically the ongoing work on ETSI Technical Specification 103 548 v2.1.1 (SmartM2M; SAREF reference ontology patterns) we state:

SAREF extensions should not create specific instances of the class saref:PropertyOfInterest, as they are meant to be specific to an application. The only exceptions to this provision are if the associated feature of interest is intended to be used by most applications of the SAREF extension.

A specific instance of the class saref:PropertyOfInterest shall link to its kind (an instance of saref:Property) using property saref:hasPropertyKind, and to the unique feature of interest it is a property of using property saref:isPropertyOf.

SAREF extensions should not define a hierarchy of classes of property of interest, as this would duplicate information already part of the taxonomy of properties.

As one use case, see for example the AffectedBy ontology design pattern proposed by @iesnaola. In this design pattern, the Figure below explains clearly how properties of interest would be used.

Esnaola-Gonzalez, I., Bermúdez, J., Fernández, I., & Arnaiz, A. (2018, October). Two Ontology Design Patterns toward Energy Efficiency in Buildings. In WOP@ ISWC (pp. 14-28).

As another use case, when describing the topology of a system, it may be useful to assert how properties of interest are related. For example in the presentation of SAREF4SYST at the Workshop on Ontology Design and Patterns 2023 (slide 19) I showed how two properties of interest, each belonging to a different feature of interest could be asserted to be equal.

Lefrançois, M. (2023, November). SAREF4SYST: a SAREF Reference Ontology Pattern for Representing Systems and their Interconnections. In WOP2023: 14th Workshop on Ontology Design and Patterns, at the International Semantic Web Conference.

[sgrellet]

It's useful in actual applications, where the association between a feature of interest and a property (i.e., the property of interest) needs to be identified and related to other properties of interest

Makes then a lot of sense to me. Thanks for the explanation

sosa:hasPropertyKind

+1 as well