w3c/wot-scripting-api

Semantic ConsumedThing part of Scripting API

danielpeintner opened this issue · 3 comments

danielpeintner commented

With the current Scripting API one can interact with a ConsumedThing by knowing the interaction name, e.g., readProperty("temp"). If the interaction name is "temperature" instead of "temp" this needs to be updated accordingly.

Hence, what the current API does not offer is to interact with a thing based on the semantics attached to it like "read the temperature" no matter how the resource is named.

A possible addition to the current API could be to add a semantic layer around ConsumedThing that allows to ask for the temperature in a way that is independent of the interaction name, e.g, readSemanticProperty("iot:Temperature")

class SemanticConsumedThing extends ConsumedThing {

  readSemanticProperty(semanticType: string, options?: WoT.InteractionOptions): Promise<WoT.InteractionOutput> {
    // look for @type": "iot:Temperature" and call it based on the interaction name as of today
  }

  ...
}

The reason why I created this issue

  • I am wondering whether a SemanticConsumedThing API should be specified or left as an extension to implementations. In node-wot we have a VERY early version
  • Does it even make sense to standardize this behaviour? The benefit I see is that we could really say we can offer scripts that work across different vendors since any vendor is free to use any interaction name as long as the interaction is properly semantically typed

Note: There are many open points/questions. I just would like to get a first feedback about the feasibility to specify this.

zolkis commented

The question is how often the semantics change. If they change, then a parametrized API like this makes sense.

Otherwise, it can be mapped 1:1 to a standardized readTemperature() call, which is the approach most web API's are taking.

In either case, I think it should be a different API object, for instance create a SemanticThing out of a ConsumedThing (instead of extending), and group there all semantic interactions. Or, use a factory method to do that, from inside ConsumedThing (e.g. createSemanticReader()).

danielpeintner commented

@zolkis thank you for your feedback

In either case, I think it should be a different API object, for instance create a SemanticThing out of a ConsumedThing (instead of extending), and group there all semantic interactions. Or, use a factory method to do that, from inside ConsumedThing (e.g. createSemanticReader()).

I wonder "why" you don't like extending ConsumedThing since this seems to be the perfect match for me since then I have the freedom to do both at the same time.
Maybe we find time to discuss the topic it in one of our next calls...

relu91 commented

Linking this issue with #204. Should we close 204 and favor this one?

  • 👍1