252 remove propertyofinterest #274
Conversation
Elaborate isPropertyOf pattern in Common Patterns section
dr-shorthair
requested review from
ldesousa,
alexrobin,
maximelefrancois86 and
sgrellet
There was a problem hiding this comment.
in the first two paragraphs, it could be appropriate to mention existing usage of sosa:Property that consider it specific vs generic. See beginning of issue #106
in the note: SAREF defines saref:Property as the generic , and saref:PropertyOfInterest as the specific. They are unrelated (no subclass axiom in any direction)
maybe just use SAREF in the example
alignment would be: sosa:Property is super class of saref:Property AND saref:PropertyOfInterest
| </p> | ||
| <p> | ||
| For example, the Property <a href="https://qudt.org/vocab/quantitykind/Temperature"><code>qk:Temperature</code></a> | ||
| from [[QUDT]] may be specialized to a specific feature of interest, such as the temperature of a particular child or |
There was a problem hiding this comment.
Specialisation primarily refers to classes. Only with ArchiMate have I seen it used between instances, but even there rarely. Perhaps there is a different way to describe this mechanism?
There was a problem hiding this comment.
skos:broader/skos:narrower is a standard predicate for generalization/specialization between instances.
See https://www.w3.org/TR/skos-primer/#sechierarchy
It is widely recognised that there is crossover between the semantics of skos:Concept and rdfs:Class.
However, it is also widely recognised that the choice of whether to model a (lower case) concept as a Class or an Individual (e.g. a SKOS Concept) is application specific. Making 'property' a SSN (SOSA) class, and its members as individuals is seen as problematic in some quarters - from the pov of the ISO 19109 General Feature Model having 'Property' as a class already crosses meta-levels uncomfortably. But having 'properties' as individuals does reflect very common usage in observations, so that is what we did. But then when we try to model relationships between properties - particularly specialization/generalization - we inevitably hit the issue under discussion here.
My general preference is to declare the modeling of property definitions 'out of scope' for SSN, since there is a lot of prior work in the space which it is not necessary to replace. Just use the URIs.
There was a problem hiding this comment.
OK, but that was not my point, just the wording. I think the two examples are enough to convey these nuances. I just wonder whether using "generalisation" with instances leads to some misunderstanding.
| <code><myBodyTemperature></code>, <code><LightStatus></code>). | ||
| This version solves the ambiguity by differentiating: | ||
| The SSN Ontology does not provide a general pattern for describing observable or actuatable properties. | ||
| It is recommended to use entries from one of the many existing catalogues of properties, such as the <a |
There was a problem hiding this comment.
If you find it relevant: in most cases these properties vocabularies will be expressed with SKOS.
|
@maximelefrancois86 - I've converted the example to SAREF and generally re-worded to point in that direction. Also https://raw.githack.com/w3c/sdw-sosa-ssn/252-remove-propertyofinterest/ssn/index.html#SAREF-alignment - I'm not sure that we have the |
|
You're right, alignment needs to be reworked. Could you please copy your comments to issue #125 (reopened) ? |
Closes #252
Closes #212