Values of properties may not be expressible as literals - blurry difference between states and properties ?

changed milestone to %V4.1.1

Issue saref-portal#76 (closed) is also related. Movement in SAREF4AUTO and Posture in SAREF4EHAW are now modeled as states, but this issue initially referred to properties. This shows that the distinction between properties and states is not really clear

mentioned in issue saref4auto#16 (closed)

Interesting issue! Conceptually a state is for me something endures for a period of time, such as ill versus healthy, employed/unemployed, of on/off. Values on the other hand, I intuitively see as either static or fluctuating, such that you only know it when you measure it. E.g., eye colour is static so a Property, and heart rate is a Property because you explicitly have to measure it.

In SAREF, I would find the state intuitive for IoT devices, to indicate on/off or paused/running, or error-mode/normal/energy-saving.

Additionally, in SAREF you may describe explicitly the measurement of something/someone being in a particular state. I don't think the modelling fits measuring states instead of measuring properties.

allow for a OP variant of the DP saref:hasValue (option 1), or define a variant of saref:PropertyValue for qualitative properties (option 2)

Can I suggest something controversial? Can we define saref:hasValue as an rdf:Property instead of DP or OP? I would find two different properties for an Individual versus a literal highly confusing (for users), but I would support having the same modelling structure to measure a temperature as well as to measure something that's defined as a state.

potentially: define saref:State as a subclass of saref:Property

Conceptually, I would tend to agree, but only if we can hide this subclass relation from users.

mentioned in issue #67 (closed)

I don't like the idea of having a rdf:Property here, reasoners will scream..

I think the easiest solution would be have hasValue optional on PropertValue, and to define a hierarchy

State rdfs:subClassOf Property (those properties that are qualitative properties)
StateValue rdfs:subClassOf State, PropertyValue (the terminal states, that can be used in place of a property value)

It would makes the modeling of states , state values, observations on states, cleaner and more parallel to properties.

Instead of

:Button saref:hasState :OnOffState .

<button> saref:hasState :OnOffState , :On .

We would write:

:Button saref:hasProperty :OnOffState .

<button> saref:hasState :OnOffState ; 
  saref:hasPropertyValue :On .

and the observations would remain untouched:

[] a saref:Observation ;
  saref:observes <button> ;
  saref:observes :OnOffState ;
  saref:hasResult :On .

Proposal: define a hierarchy

Value

PropertyValue

StateValue

CompositeValue

?

[] a :PropertyValue ;
  saref:hasValue "#124558"^^cdt:color ;

[] a :PropertyValue ;
  s4abcd:hasRedComponent 12 ;
  s4abcd:hasBlueComponent 45 ;
  s4abcd:hasGreenComponent 58 .


[] a :PropertyValue ;
  saref:hasValue "#124558"^^cdt:color ;
  saref:consistsOf [ a :PropertyValue ; saref:hasValue 12 ] ;
  saref:consistsOf [ a :PropertyValue ; saref:hasValue 45 ] ;
  saref:consistsOf [ a :PropertyValue ; saref:hasValue 58 ] .

<on> a :PropertyValue ;
  saref:hasValue true .

[] a :PropertyValue ;
  saref:hasIndividualValue <blue> ;

This hierarchy at the end is a datatype hierarchy. Here there are some links for inspiration and to check the potential datatypes that we may find (some can already be defined with literals, of course):

https://specifications.openehr.org/releases/RM/latest/data_types.html#_data_types_information_model

https://www.postgresql.org/docs/current/datatype.html

agreed with @garciacastro 2024-06-18

should not be used for regular properties.

:propertyIsComposedOf a owl:ObjectProperty ;
  owl:domain [ owl:unionOf ( :CompositeProperty :CompositePropertyValue ) ] .
  owl:range  [ owl:unionOf ( :Property :PropertyValue ) ] .
  
:CompositeProperty a owl:Class ;
  rdfs:subClassOf :Property , [ 
    a owl:Restriction ; 
    owl:onProperty :propertyIsComposedOf ; 
   owl:allValuesFrom :Property ] 

:CompositePropertyValue a owl:Class ;
  rdfs:subClassOf :PropertyValue , [ 
    a owl:Restriction ; 
    owl:onProperty :propertyIsComposedOf ; 
   owl:allValuesFrom :PropertyValue ]

resolution 2025-01-17:

at least: add a note and an example in the TS where the result of an observation is an individual of type person, or something else, to clearly illustrate that values of properties can also be individuals (URIs, not literals)

TODO: think more about the face recognition sensor: how to model an observation:

that a person is the result of an observation of a room ?
or a observation of the person is made by the sensor, and there is no result ?
or the hasResult and observes link to the same entity ?

Discussion with Laura 2025-01-24:

For the time being, keep Properties and States parallel but distinct, let's collect more evidence from the users before deciding if we we want to merge them or not

how to model an observation: to me best answer is:

the result is a composite property value.

This example shows how we can combine everything with the solution accepted in #67 (closed)

ex:Person a saref:FeatureKind .

ex:PresenceOfPeopleInARoom a saref:Property ;
  saref:consistsOf
    ex:Person , 
    ex:PresenceOrNotPresence .

ex:PresenceOrNotPresence a saref:State .
ex:Presence a saref:StateValue ; saref:isValueOfState ex:PresenceOrNotPresence .
ex:NoPresence a saref:StateValue ; saref:isValueOfState ex:PresenceOrNotPresence . 


<room> a saref:FeatureOfInterest .

<smartcamera> a saref:Device ;
  saref:observes <room> ;
  saref:observes ex:PresenceOfPeopleInARoom ;
  saref:madeExecution <observationxyz> .

<observationxyz> a saref:Observation ;
  saref:madeBy <smartcamera> ;
  saref:observes <room> ;
  saref:observes ex:PresenceOfPeopleInARoom ;
  saref:hasResult [ 
     saref:consistsOf 
       ex:Presence ,
       <laura> ,
       <cornelis> 
  ] .

add in 5.7.1 introduction:

States and Properties are parallel, distinct, but not disjoint, so users are free to chose whicheve seems to best fit their needs. Clause 5.14 discusses Composite Properties, that help to combine properties, states and features of interest in one composite property.

move composite properties definition to 5.14.

closed

Values of properties may not be expressible as literals - blurry difference between states and properties ?

Child items ...

Activity