Re: [sdw] modeling units on properties instead of results [SOSA/SSN] (#1267)

re "directly to a specific sosa:ObservableProperty / ssn:Property instance or subclass" 
and "you can define the observable property any way you like" 

 there is a bit of a disconnect here with O&M where to my mind it is ambiguous where a "ObservableProperty"  more naturally relates to an instance of type rdf:Property  - thats "a property" in most RDF contexts - and naturally supports statements about UoM and other "default values", and all the other types of useful constraints - such as it is necessary to observe both temperature and pressure  at the same time.

 the sosa examples are limited to the per-feature case which are basically reified statements of relationships between values and feature instances, and doesnt support much information about the property actually being observed. It also leads to a lot of redundacy and verbosity - such as the label ""the height of tree #124 in meter"@en"  - its hard to imagine any real world system that would choose to create such labels and lose information about the actual nature of the property rather than modelling the property and attaching a value for it to a feature (an instance of the property)

i.e. assigning UoM constraints to individual feature instance "properties" is sub-optimal half-way house in terms of both expressivity and verbosity.

The most obvious pattern would be to define constraints on the modelled Properties of Feature classes which could be used to entail property values of instances

e.g. 
 :Cat a owl:Class.
:fluffyness a owl:DatatypeProperty ;
  rdfs:Domain :Cat .

:flufftest a sosa:Observation ;
  sosa:featureOfInterest :mog ;
  sosa:observedProperty :fluffiness ;
  sosa:hasSimpleResult 3 .

entails...
:mog a 🐱 
  :fluffyness 3 .

and by defining a constraint on the property  :fluffyness that its UoM is the :fluffIndexUnit 

entails:
:mog_fluffiness a rdf:Statement  
   rdf:subject :mog ;
   rdf:property :fluffiness ;
   qudt-1-1:unit :fluffIndexUnit 
.


IMHO SSN needs  work to make the choice of options and implementation patterns clear - or if the intention is truly that there is no choice in this matter then another mechanism needs to be added to allow properties to be modelled in a systematic way.




-- 
GitHub Notification of comment by rob-metalinkage
Please view or discuss this issue at https://github.com/w3c/sdw/issues/1267#issuecomment-858256500 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 10 June 2021 03:44:14 UTC