Use of TD Templates (Thing Models) as abstractions for consumers

[fennibay]

Dependency inversion principle states that implementations should depend on abstractions (interfaces) instead of on implementations to avoid coupling between implementations.

This principle can be applied to consumed interaction affordances, by using abstract thing description templates, and realizing these abstractions using concrete thing descriptions.

An abstract thing description template consists mainly of interaction affordance templates, which then consist of @type for semantic annotation and a logical data schema.

A concrete thing description realizing an abstract thing description template has to fulfill following constraints:

• It must implement all InteractionAffordanceTemplates, additional InteractionAffordances are allowed
• For every InteractionAffordance fulfilling an InteractionAffordanceTemplate
  • @type must be rdfs:subClassOf template’s @type
  • Data schema must be a superset
  • For properties, observable must be identical
  • For actions, safe and omnipotent must be identical

This concept can also be used in the discovery phase. The discovery would then search for TDs fitting a given TD template by the consumer.

In case of a hybrid thing (consuming InteractionAffordances as well as exposing other InteractionAffordances), it can be a mix of TD and TD templates, where some InteractionAffordances are actually just InteractionAffordanceTemplates.

Proposals:

• In TD Specification, extend the section C. Thing Description Templates:
  • With the consumer abstraction use case in addition to the listed use cases
  • With the concrete definition of what it means for a thing description to implement a TD template (restriction above)
• In the scripting API specification, extend the section 2.3 Discovery:
  • With TD Template as search criteria

p.s. If TD Template is going to be renamed to Thing Model (#930) we should switch to that terminology.

cc: @sebastiankb

[vcharpenay]

that sounds like a very good idea. In the last WoT workshop, I suggested something that goes into the same direction (see paper and slides). At the time, I was thinking of using "JSON-LD frames", which can be seen as queries to run over TD documents. But using ThingModels is functionally equivalent, that'd work.

My suggestion went even slightly further: there should be a way to specify the relationships between the various Things that are accessed in a Consumer's script. For instance, a light bulb should be turned on only if it is in the same room as the occupancy sensor that detects movement (TD2). The two corresponding Things should have a certain relationship that can be expressed in RDF/JSON-LD. E.g. <urn:ex:room> brick:hasPoint <urn:ex:lightBulb>, <urn:ex:occupancySensor>.

[vcharpenay]

A concrete thing description realizing an abstract thing description template has to fulfill following constraints:

Note that you could shorten the definition as follows: "a TD must be an instance of a ThingModel under RDFS entailment" (and other entailment regimes could be considered, e.g. OWL-QL or OWL-RL).

[relu91]

I'd like to see this mechanism taking place. It goes in the same direction as my idea exposed here. I also link a couple of other issues where we discussed similar features to keep track of the discussion:

• Add a class field to the TD - Issue 268 from w3c/wot #935 (what about using SHACL?)
• TDT shall allow to define placeholders #897
• Extend API with semantic capabilities wot-scripting-api#204

[sebastiankb]

@fennibay
Thank you very much for your contribution. Currently I am working on this PR #938 for the next draft of the Thing Description. I like your diagram. Can you share the sources? To better understand the relationship between a TD instance and a Thing Model, I would like to include such an illustration in the specification.

@vcharpenay

a TD must be an instance of a ThingModel under RDFS entailment

How would that look in a practical example? How can the TD instance indicate that it follows a certain Thing model? @type would not work, right?

[fennibay]

Hi @sebastiankb, please find the zipped Visio file here: td_template_for_consumer.zip Maybe I should have drawn this draw.io.

@ all: Many thanks for the comments, I'll respond.

[fennibay]

draw.io could convert from Visio just fine. (Diagram is embedded into the png, so you can edit it with draw.io).

[sebastiankb]

@fennibay many thanks for sharing the file. draw.io works perfect

[fennibay]

Note that you could shorten the definition as follows: "a TD must be an instance of a ThingModel under RDFS entailment" (and other entailment regimes could be considered, e.g. OWL-QL or OWL-RL).

What would RDFS entailment contain in addition to rdfs:subClassOf relationship in this context?

I also link a couple of other issues where we discussed similar features to keep track of the discussion:
#935 (what about using SHACL?)
w3c/wot-scripting-api#204

Can we also address data model compatibility between Thing Model and TD with semantic means? I saw this until now as a separate part, which needs to be addressed using more conventional means, e.g. check that the data model is identical, or maybe a superset or check if a conversion (as proposed in w3c/wot-scripting-api#204) is available. However, looking at TD Ontology, we could also do these checks semantically. But I miss there for instance the link to the data schema for a property, and also the contents of the data schema is not representable in this ontology.

I certainly like the idea in w3c/wot-scripting-api#204 that parts of data model can also be semantically annotated with @type.

My suggestion went even slightly further: there should be a way to specify the relationships between the various Things that are accessed in a Consumer's script. For instance, a light bulb should be turned on only if it is in the same room as the occupancy sensor that detects movement (TD2). The two corresponding Things should have a certain relationship that can be expressed in RDF/JSON-LD. E.g. urn:ex:room brick:hasPoint urn:ex:lightBulb, urn:ex:occupancySensor.

Would this be then like a WoT-based version of IFTTT?

p.s. sorry for the long delay. It was a busy week.

[sebastiankb]

I would like to check briefly whether this Issue is now fulfilled by the opportunities that TM supports:

• we have the required statement that forces which affordances have to be implemented by TD instances
• The link relation ("rel":"type") can be used to express which TM was used to create TD instance (this can be used for discovery as example)

[fennibay]

Thanks for the query @sebastiankb.

Regarding this issue; I think the remaining point is if we should model the needs of a WoT consumer formally, i.e. a "uses/consumes" relationship between the consumer and the now-specified TM.

p.s. We also had a discussion about this with @mkovatsc. I think we have a good basis with TMs now, although they could maybe benefit more from semantic matching (@type and rdfs:subClassOf, or similar means) instead of matching via given links rels (tm:extends, tm:ref). This is an open issue, but we can address it separately.

[sebastiankb]

ok, I will label this issue "Defer to 2.0". In fact, a "Consumer Description" is currently missing and should be officially considerd in the next version.

Btw: there is the discussion to remove the "tm:required" feature and replace them with "tm:optional". Also see here: #1594