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

Inconsistent semantics of Property and hasProperty

See also the slideset on the sharepoint

The property saref:hasProperty relates a feature of interest to a property:

###  https://saref.etsi.org/core/hasProperty
saref:hasProperty rdf:type owl:ObjectProperty ;
                  owl:inverseOf saref:isPropertyOf ;
                  rdfs:comment "A relationship between a feature of interest and a property of that feature"@en ;
                  rdfs:domain saref:FeatureOfInterest ;
                  rdfs:range saref:Property ;
                  rdfs:label "has property"@en .

There are 17 subproperties of hasProperty throughout the extensions: s4agri (1), s4auto (6), s4lift (9). Additionally, there are two properties in saref core and one in s4ehaw that have as their domain a subclass of saref:Property. See below for a list.

All these properties expect an actual value of that property. Take a few examples:

  • s4auto:hasLength: "A relation to express the length of an entity, e.g., a vehicle"
  • s4lift:hasVoltage: "A relationship defining the voltage of a feature of interest."

In issue #6 we saw that several extensions model Properties as individuals. This is inconsistent with the above examples, since it would result in the following incorrect graph pattern:

ex:Platoon_1 a s4auto:Platoon ;
   s4auto:hasLength s4auto:PlatoonLength . 
   # Incorrect example, s4auto:PlatoonLength not actually in saref4auto. 
   # The s4auto:hasLength property cannot have the length of 
   # the entity as it should have according to its comment.

The s4auto examples instead indicate:

:Platoon1 rdf:type owl:NamedIndividual, s4auto:Platoon ;
  saref:hasProperty :Platoon1Length .
  
:Platoon1Size rdf:type owl:NamedIndividual, s4auto:Length ;
  saref:relatesToMeasurement :Measurement_1.

Concluding, the semantics of saref:hasProperty and its subproperties that expect to relate a FoI to a measurement of that property are inconsistent with the several extensions that model Property individuals.

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

The Ontology is of Measurement is also relevant as input: https://github.com/HajoRijgersberg/OM

The inconsistency seems to exist because some extensions take a Property/Quantity-centric approach, whereas other extensions take a Measurement-centric approach. The Ontology of Measurement takes the former approach, while SOSA takes the latter. We give both options, so both are used among the extensions, leading to inconsistencies.

===

Result: The expected result is that we have clarity on an approach regarding intended usage of saref:Property and saref:hasProperty.

==== 1 saref:hasPrice 2 s4agri:generates 3 s4auto:hasHeight 4 s4auto:hasLength 5 s4auto:hasMovement 6 s4auto:hasShape 7 s4auto:hasSize 8 s4auto:hasWidth 9 s4lift:hasVoltage 10 s4lift:hasCoverage 11 s4lift:hasCarTemperature 12 s4lift:hasEngineRoomTemperature 13 s4lift:hasShaftTemperature 14 s4lift:hasElectricPowerConsumption 15 s4lift:hasChannelBitErrorRate 16 s4lift:hasReceivedSignalStrengthIndicator 17 s4lift:hasTimeOfLastPeriodicTest72hAttempt 18 s4lift:hasTimeOfConfirmationOfLastPeriodicTest72hAttempt 19 saref:hasTime