Link between PropertyOfInterest and Property

[KathiSchleidt]

Do we have a way to indicate that a PropertyOfInterest is related to a specific Property? Understand that Temp of Room3 is Temperature

[maximelefrancois86]

Not yet. I would recommend sosa:hasPropertyKind, following https://saref.etsi.org/patterns/core_properties

[dr-shorthair]

I'm reconsidering whether the class PropertyOfInterest (which was added by #126) is actually needed.

Here's the thing: The predicate sosa:isPropertyOf allows you to (optionally) tie a Property to a specific FeatureOfInterest already. So any Property definition that uses the predicate sosa:isPropertyOf is duck-typed to "PropertyOfInterest" anyway. If this is not the application for sosa:isPropertyOf (which goes back to the 2017 version), then I'm not sure what this predicate is actually useful for ...

Should have spotted this earlier.

This still begs the question of how a specific Property (tied to a specified FoI) can be tied to a generic, reusable Property. Of course, the standard RDF way to tie an individual to a type (i.e. class) is rdf:type. At which point this all begins to look like the discussion that we already had on Systems and System-Types.

However, the problem with that solution would be that sosa:observedProperty and sosa:actsOnProperty have the range sosa:Property, which means instances of the class, not sub-classes. We could only reconcile this by punning, where any generic property (i.e. not tied to a specific FeatureOfInterest) is both an individual (so it can appear as the object of a sosa:observedProperty and sosa:actsOnProperty triple) and a class (so it can appear as the object of an rdf:type triple).

(I'll try to get a sketch of what this means in practice done, so those readers who work better through examples can understand, but I need to save this comment for now.)

[ldesousa]

@dr-shorthair That was pretty much my point all along. While I reckon there were also relevant arguments for its introduction, I still believe we can leave without it.

[dr-shorthair]

This still begs the question of how a specific Property (tied to a specified FoI) can be tied to a generic, reusable Property. Of course, the standard RDF way to tie an individual to a type (i.e. class) is rdf:type.

Perhaps dcterms:conformsTo or dcterms:source would save us having to add a new predicate if it is needed to link a specific Property (that has a FeatureOfInterest) to a more generic property from a property catalogue.

[alexrobin]

@dr-shorthair I agree that PropertyOfInterest may not be needed.

I don't even think we should start from the assumption that a Property tied to a specific FoI is more specific that the Property in the property catalog. I personally see it as the same Property. It just happens that such Property is also associated to the FoI using the isPropertyOf association (or the reverse association).

In other words, I'm not sure the parallel with System/SystemKinds is really valid here. I don't think a Property is "instantiated" every time it is associated to an FoI like we instantiate system kinds.

That said, we still have to decide how to model this in RDF. We surely need a way of deriving properties from more generic ones (e.g. Air Temperature derived from Temperature). So, modeling Property as a class like all other SOSA concepts seems logical. The question is whether we can point to the Property class directly as an RDF property value (for example as the value of sosa:forProperty).

I have seen a few patterns to achieve this in the following draft: https://www.w3.org/TR/2005/NOTE-swbp-classes-as-values-20050405/

Would any of this work?
Are we trying to stay OWL DL compliant?

[rob-metalinkage]

Thats a useful link @alexrobin

I note some key points - one is the distinction between general and special reasoning - we already commit to special reasoning with the semantics of ObservationCollections I think - so I see little advantage in saying the solution must be supported by general reasoning.

Secondly, the idea we can control descriptions of ObservedProperties would be over-reach - Classes, SKOS hierarchies, with and without punning all ought to be implementation choice.

Thirdly, relying on subClassOf reasoning is problematic, as building heirarchies from inferred subClassOf relationships is a nasty hard thing to do - skos:broader and skos:broaderTransitive is much more tractable.

I cant see how a generic (non FOI specific) Property can use isPropertyOf to a specific FOI in a meaningful way - it just becomes a list of all FOIs - we would want to link Property to the model (FeatureType) not the instance surely.

[dr-shorthair]

Telecon discussion favours removing PropertyOfInterest.
The definition is effectively the same as Property.

Discussion about whether hasProperty/isPropertyOf should also be removed.
This is overlaps with feature-type definition language, which is really outside the scope of SSN.

(Maybe even forProperty / propertyFor.)

[maximelefrancois86]

Well, I suggest recommending using SAREF for when a foi-specific property is needed, then.

[dr-shorthair]

@alexrobin pointed out:

I don't even think we should start from the assumption that a Property tied to a specific FoI is more specific that the Property in the property catalog. I personally see it as the same Property. It just happens that such Property is also associated to the FoI using the isPropertyOf association (or the reverse association).

You are correct. Unless sosa:isPropertyOf is rdf:type owl:FunctionalProperty (which it is not) or has a cardinality restriction, then a sosa:Property can be linked to many or no features (entities), and can also be used in connection with other features (entities) with no inconsistencies.

The only real difference between Property and PropertyOfInterest is the cardinality restriction.
Is this enough to merit a separate class? (Note that cardinality restrictions takes us outside OWL-DL as well.)

[dr-shorthair]

I see two broad options to describe a property-of-interest, without needing the new class sosa:PropertyOfInterest.
Picking up on the sick child temperature example:

First

• grab a 'Property' definition from a well-known external source: qk:Temperature.

Option 1:

• cast qk:Temperature as a sub-class of sosa:Property
  • this implies punning an instance of qudt:QuantityKind to an owl:Class
• define an individual property ex:SickChildATemperature as an instance of qk:Temperature, bound to the FoI (the sick child) using sosa:isPropertyOf
• SickChildATempObs
  • has sosa:observedProperty ex:SickChildATemperature
  • doesn't need a sosa:hasFeatureOfInterest

qk:Temperature
  rdfs:subClassOf sosa:Property ;
.
ex:SickChildA
  a sosa:FeatureOfInterest ;
.
ex:SickChildATemperature
  a qk:Temperature ;                             # also implies the superclass sosa:Property
  sosa:isPropertyOf ex:SickChildA ;
.
ex:SickChildATempObs
  a sosa:Observation ;
  sosa:hasSimpleResult "38.2"^^unit:DEG_C ;
  sosa:madeBySensor ex:Mums-clinical-thermometer ;
  sosa:observedProperty ex:SickChildATemperature ;
.

Advantage - doesn't require an arbitrary choice of predicate to link the special case to the general.

However, qk:Temperature is a class, so would probably not appear in the same register of sosa:Property instances as ex:SickChildATemperature, else/and OWL punning is implied.

Option 2:

• cast qk:Temperature as a instance of sosa:Property
  • no punning required
• define an individual property ex:SickChildATemperature as a specialization of qk:Temperature, bound to the FoI (the sick child) using sosa:isPropertyOf.
• SickChildATempObs
  • has sosa:observedProperty ex:SickChildATemperature
  • doesn't need a sosa:hasFeatureOfInterest

qk:Temperature
  a sosa:Property ;
.
ex:SickChildA
  a sosa:FeatureOfInterest ;
.
ex:SickChildATemperature
  a sosa:Property ;
  skos:broader qk:Temperature ;
  sosa:isPropertyOf ex:SickChildA ;
.
ex:SickChildATempObs
  a sosa:Observation ;
  sosa:hasSimpleResult "38.2"^^unit:DEG_C ;
  sosa:madeBySensor ex:Mums-clinical-thermometer ;
  sosa:observedProperty ex:SickChildATemperature ;
.

Advantage: qk:Temperature and ex:SickChildATemperature are 'siblings' in the context of a register of sosa:Property instances; no punning required.

However, the choice of the predicate skos:broader to link back from the specific property to the more general case, is somewhat arbitrary, and I am open to other suggestions.
Note also that under SKOS semantics, the use of skos:broader entails that sosa:Property rdfs:subClassOf skos:Concept. - which I am very comfortable with, but might annoy some of the more picky OWLites.

---

Note: overall I am not a fan of binding a property tightly to a FoI.
I prefer to keep properties generic, and then only bind them to a FoI in the context of an execution (observation).
But I recognize that some applications prefer the 'PropertyOfInterest' pattern, so we need to give them guidance how to achieve that.

---

Proposed action

Follow through on the telecon decision above to resolve this issue as follows:

• remove sosa:PropertyOfInterest (also implies closing Extend domains and ranges to PropertyOfInterest  #212)
• elaborate this Common Modeling Question with one or both of these examples as patterns.

What I need from you

Opinions on which direction to head.

[maximelefrancois86]

I dislike when group decisions are volatile. Proposing an alternative modeling to ours after we've reached a decision we thought was going to be common to SAREF and SSN is creating noise, and hampering future interoperability between the two standards.

The two alternatives you propose would be valid, obviously. They could even coexist with qk:Temperature identifying both a class and an instance (punning).

• Option 1 is the one already used the most, but not desirable. It's hell to have sometimes hierarchies of Property classes, and sometimes catalogs of Property instances. Encouraging to use punning whenever it seems fit is not a wise decision I believe.
• Option 2 is what we propose in https://saref.etsi.org/patterns/core_properties , except you squash generic and specific properties in a single taxonomy:
  • class sosa:Property remain ambiguous, and can type either generic or specific properties. That's statu quo.
  • we (SAREF developers) decided that saref:Property was best kept for generic properties only, and to introduce saref:PropertyOfInterest to type specific properties - they are nodes in your taxonomy that should remain leafs (should not be specialized).
  • we (SAREF developers) considered that skos:broader is not ideal to link the specific property to the more general case. we chose to introduce hasPropertyKind, already implemented there https://saref.etsi.org/patterns/core_properties

We have different other properties (hasPropertyOfInterest/isPropertyOfInterestOf) that allow the pattern to remain OWL2 DL, even with the cardinality restriction.

At this point, I see we have little chance to reach a perfect common ground, so I would recommend to mention Option 2 only, and to:

• discourage the definition of sub-classes of Property, except when it's to categorise them based on their provenance or other things. for example ex:ISO80000Properties
• add a note on Property that it has always been, and will remain, an ambiguous concept.
• point to SAREF if users want more control on what they model.