Skip to content
GitLab
Open
Issue created by Mauro Dragoni@dragoniDeveloper

Harmonise modeling pattern for Property taxonomy: Specific vs Generic, or both, or separate ?

See also the slideset on the sharepoint

The large majority of saref extensions defines one or more subclasses of saref:Property. The saref4bldg en saref4city extension are the sole exceptions that do not provide additional properties. However, the definition of additional properties is inconsistent. The main difference is on how the leaves of the property taxonomy are modelled: as individuals or as classes.

A comparison between saref4ener and saref4envi highlights the differences:

  • Saref4Ener defines the low-level properties as subclasses (documentation link). See the following snippet from saref4ener, where I removed comments and labels for brevity.
s4ener:Energy
  rdf:type owl:Class ;
  rdfs:subClassOf saref:Energy ; #saref:Energy rdfs:subClassOf saref:Property
.
s4ener:EnergyExpected
  rdf:type owl:Class ;
  rdfs:subClassOf s4ener:Energy ;
.
s4ener:EnergyMax
  rdf:type owl:Class ;
  rdfs:subClassOf s4ener:Energy ;
.
s4ener:EnergyMin
  rdf:type owl:Class ;
  rdfs:subClassOf s4ener:Energy ;
.
s4ener:EnergySkewness
  rdf:type owl:Class ;
  rdfs:subClassOf s4ener:Energy ;
.
s4ener:EnergyStandardDeviation
  rdf:type owl:Class ;
  rdfs:subClassOf s4ener:Energy ;
.

Concerning patterns, this would require each measurement to refer to an instantiation of the class in the data graph:

ex:measurement_1
  a saref:Measurement ;
  saref:relatesToProperty ex:Temp_1 .

ex:Temp_1
  rdf:type s4ener:EnergyMax.

This approach is also followed by saref4auto.

  • Saref4Envi defines the low-level properties as individuals (documentation link). See again the abbreviated snippet from saref4envi:
:LightProperty rdf:type owl:Class ;
               rdfs:subClassOf saref:Property ;
               rdfs:comment "An aspect of light that can be observable by a sensor."@en ;
               rdfs:label "Light property"@en .

:Luminiscence rdf:type owl:NamedIndividual, :LightProperty .
:Phosphorescence rdf:type owl:NamedIndividual, :LightProperty .
:ReflectionOfLight rdf:type owl:NamedIndividual, :LightProperty .
:ScatteringOfLight rdf:type owl:NamedIndividual, :LightProperty  .

Concerning patterns, this would enforce the usage of the property as a codelist element.

ex:measurement_2
  a saref:Measurement ;
  saref:relatesToProperty s4envi:ScatteringOfLight.

The second approach of modelling individuals on the lowest level is additionally followed by saref4agri, saref4wear, and saref4watr.

Relevant material and considerations: The SOSA considerations are also relevant here to consider: https://www.w3.org/TR/vocab-ssn/#SSNProperty-instances

Quote: "This specification does not specify whether an instance of ssn:Property should be generic to all features of interest (e.g., ex:Temperature, ex:OnOffStatus), or specific to a single feature of interest (e.g., , ). Implementers are free to choose one way of modeling things or the other."

The approach with owl:Class follows SOSA's approach of leaving it to a user whether an instance of saref:Property should be generic or specific. The approach with owl:NamedIndividual enforces the decision that an instance of saref:Property is generic.

Additionally, we can consider what is more user-friendly. Leaving the choice of whether a Property instance is generic or specific to the user, may actually be less user-friendly.

Goals: I expect this issue to be resolved when we decide on a harmonised pattern for modelling saref:Property subclasses.