Semantic Annotations - Referencing Individuals instead of Classes

[AndreaGiulianelli]

EXAMPLE 2 shows an example of a TD annotated with the SAREF ontology.

The example uses the JSON-LD @type keyword to reference a class (e.g., saref:OnOffState, saref:ToggleCommand).

In the new version of SAREF, saref:OnOffState (a subclass of saref:State) and saref:ToggleCommand (a subclass of saref:Command) will be deprecated, and the recommended way to implement states, properties, and commands will be by creating instances of the base classes saref:State, saref:Property, and saref:Command (see https://saref.etsi.org/patterns/).

EXAMPLE 45 deals with this situation using the external vocaboulary ssn:forProperty that links an affordance to a previously defined individual of the class saref:OnOffState.

Generally, depending on the way the ontology is defined, it should be possible to relate affordances to specific semantic terms, independently to whether they are classes or individuals.
Now the specification only supports classes natively, and resorts to external solutions to reference individuals.

OWL punning allows to reference an individual as a class, but it is considered an antipattern and should be avoided.

[lu-zero]

Which would be the right way to describe a switch that can be toggled so a consumer would be able to present it to the user as a toggable switch?

[sebastiankb]

@AndreaGiulianelli Thank you very much for this information. May I ask you to provide TD examples that use the new SAREF version? This might then be part of the new TD 2.0 REC.

[AndreaGiulianelli]

@sebastiankb @lu-zero
The problem is in the association of semantic annotations to TD elements.
I will make you a very simple example based on SAREF, considering the example 2 of the recommendation.

In example 2, the status property is annotated with the saref:OnOffState which, considering the older version of SAREF was a subclass of saref:State (https://saref.etsi.org/core/OnOffState.ttl).
In this scenario, it was simple to annotate the property using the JSON-LD @type.

With the new version of SAREF, as reported in skos:historyNote in the above link and in the SAREF patterns doc, there will be no more subclasses, but instances -- and subclasses will be associated to categories of states/properties/commands. An example from the SAREF doc:

saref:OnOffState a saref:State .

saref:OnState a saref:State ;
    skos:broader saref:OnOffState .

saref:OffState a saref:State ;
    skos:broader saref:OnOffState .

With this new scenario, it is no more possible to use @type to annotate the status property with saref:OnOffState because we will have an instance inferred as a class (possible via OWL punning, but considered an antipattern).

So this issue is to raise the possible need for approaches that makes possible to relate TD elements to specific semantic terms, independently to whether they are classes or individuals. In fact, at the moment the specification only supports classes natively (via @type), and resorts to external solutions to reference individuals (individuals that characterize a “type”, like the new saref:OnOffState).

[maximelefrancois86]

Dear all,

Note that the correct namespace for SAREF Core is "https://saref.etsi.org/core/" , not "https://w3id.org/saref#" (three occurrences in the TD spec)

SAREF Core undergoes a transition to a new major revision 4, where we distinguish more clearly:

• Properties: instances of properties are generic and can exist independently of features of interest. Temperature, Luminosity, would be instances of saref:Property. They typically populate SKOS models online (catalogs of properties etc.)
• Properties of interest: an instance of a property of interest identifies unambiguously the property of a (unique) feature of interest. For example: the luminosity level of light bulb xyz
• Property values: an instance of a property value holds a decimal value and potentially a unit.

In the "OnOff" example above, we may end up having:

• OnOffState as an instance of saref:Property
• OnState and OffState as instances of saref:PropertyValue : they are the values that an OnOffState property can take.

If we agree on this modeling, the class to which individuals OnState and OffState belongs (say: "OnOffStateValue") could be used as the value for @type to annotate the status property

Properties vs States is currently looked at very carefully, this exact proposal is discussed here: https://labs.etsi.org/rep/saref/saref-core/-/issues/62#note_11156
Note that it is possible to weight in the discussion by creating an individual user account here: https://labs.etsi.org/signup/

Best,

[AndreaGiulianelli]

I agree on this particular case, that creating a "OnOffStateValue" is a possible, elegant, and consistent solution.

But what about other cases?
For instance, still in example 2 we have the “toggle” action with type "saref:ToggleCommand" that, referring the saref pattern doc, needs to follow the same pattern.

Could it be useful to have a more generic way to annotate properties/actions/events that consider the possibility when the "semantic tags" are not classes, but also individuals?
This could also accommodate cases in which we have poor ontologies/vocabularies, where we do not have a clear type to refer (annotating with a more domain-oriented semantics instead of simply indicating a literal type -- that at the moment is the only possibility in that cases).

[maximelefrancois86]

I believe the solution to your problem is to use something else than "@type", then.
As per the JSON-LD spec, "@type" is an alias for the predicate rdf:type, which will make the value always interpreted as a class (rdfs:Class if RDFS semantics, owl:Class if OWL).

The td context https://www.w3.org/2022/wot/td/v1.1 refers to different vocabularies that you may look up for such an annotation, including "dct": "http://purl.org/dc/terms/". What about using dct:description ?

[AndreaGiulianelli]

Maybe dct:description is not the most appropriate to the problem I tried to highlight, because the idea/issue was to be able to refer mainly to URIs, and not having a text-based description.

So for example, I imagined a solution where I am able to refer to an existing predicate or individuals like in the previous case with the ToggleCommand.

For the moment, based on your previous advice, I have created an annotation property (with an open range -- so that I can associate classes/individuals/predicates) that I include in the TD via Context Extension. Surely I will take a look at the Dublin Core to understand if they already provide something similar.

Thank you very much!