<inserted> scribenick: kaz

Guests

Philippe_Le_Hegaret from W3C Team, Geun-Hyung_Kim from Gooroomee, Li_Lin from China Mobile and Takio_Yamaoka from Yahoo Japan

sk: please be aware of the W3C Patent Policy

Scribes

1. Zoltan

2. Ege

<zkis> scribenick: zkis

<kaz> 3. Cristiano

Publications

SK: editors, please check the documents, ReSpec errors, links, references
... please point to the new drafts that are going to be released
... deadline: this week

Cancellations

SK: some web meetings were cancelled, please check the wiki
... next week we have the breakout session

MM: usually we also keep a break after F2F

Thing Description Session

SK: overview of the day
... what is new in TD 1.1
... then Daniel gives a summary on dynamic TD
... then, the Thing Model is one of the major topics today
... then, Component approach for TD, by Taki
... Finally, System Description by Ege

What's new in TD 1.1

<inserted> slides

SK: we use some new terms in TD and TD model
... we now have the 'multipleOf' term, coming from JSON Schema
... IntegerSchema and StringSchema extended
... DataSchema also has new terms, for encoding and media type
... also, SecurityScheme was improved
... so why having contentMediaType and contentEncoding: if we have some JSON doc and also some image files as JSON elements
... to point out that, we could use the new keywords (represented in base64 for JSON)
... then, mapping of DataSchema to content types has been improved
... the list is just a direct overview, but TD does not restrict other content types
... The new ComboSecurityScheme

MM: currently we can combine schemes with AND, while OpenAPI does that with OR, so this Combo was needed to support both AND and OR.
... also, avoids redundancy of having to repeat schemes

SK: 2 more OAuth flows are supported

MM: discussed tomorrow

SK: location based annotations also supported
... see 7.1.3 Example in the spec
... we can define position as object property, based on geo base context, long/lat/elevation
... also other geo ontologies can be used
... also new is that we moved the Thing Model (TD Template formerly) to the main body
... with explanation about the differences
... we will discuss that later
... we have "at type" i.e. @type: "ThingModel"

<mjk> Is the "ThingModel" value a URI or is it a plain string?

SK: So that's been a quick overview.

KA: will you upload the pres?

SK: yes, as usual

Dynamic TD discussion, by Daniel

<inserted> slides

DP: a short overview in 2 slides
... not only about dynamic TDs, but also on how to manage dynamic resources
... we have an issue that discusses this

<inserted> wot-thing-description Issue 899

DP: check TD issue#899 [link]
... we want to be able to query the state of the interaction
... currently the TD has no mechanism to describe this
... TDs could change, and one can track or cancel with an action
... another approach would be to have a static TD, i.e. remains the same but defines all resources
... for instance, to append to an action, you need to do this or that
... we investigated during the last plugfest and turned out to be complex
... a lot of security issues as well, breaking hashing and signing
... also, the TD can be hosted not only on the Thing
... this would break with dynamic TDs
... also, clients need to update TDs regularly, the consumer should always track the TD changes etc
... we found out we didn't feel comfortable with either dynamic or static TD solutions
... so far the process seems to be stalled
... this is an ongoing discussion
... we will continue the discussion in the issue

ML: were these approaches implying new vocabularies?

DP: yes
... we need to express that one resource is meant for canceling another, etc

<mjk> q

ML: if we take the TD as today, is there a guideline or design pattern we could use for solving these use cases?

DP: we didn't decide yet which way to go
... it is a new area, it is complex, there was work done, also on IETF side, Matthias was opposing since out of scope

Ege: Matthias' proposal was to prescribe how to do this, since no standards can be used
... we would not exclude anyone by prescribing this

ML: this has relevance to profiles

Ege: in a profile we could constrain how a TD should look like, so we count describe this
... profiles are meant to be prescriptive, so this would be possible

DP: we should talk to Klaus Hartke for advice

ML: we should take it on the Profile discussion's agenda and get the relevant people in the discussion

SK: would it make sense to consider this as a sub-protocol?
... since it's hard to describe with one TD
... both client and server are involved, so it's a protocol

<mjk> +1 sub-protocol approach

ML: I'd think it's not a protocol, but a semantic behavior of certain operations
... that depends on the model of the actions

<mjk> hypermedia is a sub-protocol

<taki> +q

DP: if we want a solution, it's more likely to be a static one, because the security implications

<mjk> several schemes to support hypermedia controls need to be supported

ML: agree with that

Ege: there was some value in dynamic TD's to take parts of the TD, send back a part as response
... so we don't need to register that small part anywhere
... it could be used in a sub-protocol if we prescribed that payloads would look like that
... like the response is a JSON object
... status is "time left" etc

<mjk> +1 zkis yes as a hyperemedia sub-protocol

Ege: then this starts to become sub-protocol

<mjk> CoAP has a way to do it, http has a way to do it, and it can be mapped to others

ML: should we talk about sub-protocols? not sure if it's the right way

MM: we could use templates with static definition
... we could check how OpenAPI does it

SK: they don't have it

<mjk> yes openAPI doesn't support hypermedia controls

Ege: they do have solutions

DP: today's discussion is similar to what happened in the issue
... we cannot really agree yet

MM: we should have a set of well defined proposals and then decide

DP: we do have proposals, linked from the issue
... Victor, Ege, mixes
... but this is not concluded yet

Kaz: we should clarify the actual use cases and use case scenarios for the needs of dynamic TDs
... this point is related to discovery as well
... both should be tied to use cases

SK: we have 2 use cases, one from Oracle, another from Mozilla WebThings

Kaz: those are implementation examples, but I mean we should clarify concrete description on use cases and requirements (possible based on those implementations, though), with what data, how to distributed, etc

MJK: I agree with that.
... we might look at it from a different angle. Neither OpenApi nor TD support hypermedia
... HTTP and CoAP use query parameters, a kind of hypermedia system
... what's missing from hypermedia systems is good semantic affordance
... we should consider supporting hypermedia patterns in the TD
... this may qualify us as sub-protocol
... the underlying system needs to support a hypermedia state machine
... as Sebastian also told

Ege: there are patterns, but no standards people agree on

MJK: that's what we try to do
... we should spec a static TD that could also handle a dynamic interaction

DP: we have worked out the hypermedia proposal and also the other one

Taki: the dynamic TD means complexity
... we should not create very complex TDs
... we should create some note on how to avoid making it complex

DP: good points, the 2 proposals say we are shifting complexity from server to client, or vice versa

CA: the hybrid approach seems more promising (static TD with dynamic parts)

<mjk> client complexity as needed - argues for the hypermedia sub-protocol approach

CA: why don't we return a TD that represents a virtual temporary action?
... also from Scripting pov clients just consume whatever is returned

DP: agree

MM: this is similar to a previous discussion about ongoing actions
... we have a privacy issue: if someone can observe TD changes
... extra care falls on directories to track who can know what
... it becomes very hard to maintain privacy

<mjk> whether to include the TD element as a part of the static TD vs. emit it each time is a design question

DP: this was another level of complexity

MM: it could be a token based design

DP: I'd disagree, e.g. in a factory, tokens should not be bound to persons, but roles

MM: we could adapt the mechanism
... then, we already have a mechanism to support TD updates in Thing Directory

<mjk> whether the generated address/thing is private or public is a design choice

MM: complexity also manifests in the extra load on the network
... every subscription adds complexity

<Ege> summary for hypermedia in OpenAPI: https://github.com/OAI/OpenAPI-Specification/issues/577

MM: I strongly prefer the static approach.

<mjk> depends on the use case and underlying system, e.g. we could map to a dynamically created public MQTT topic as a particular sub-protocol

SK: the next steps are a bit fuzzy
... ML mentioned this could be further discussed in the Profiles call?

ML: yes, it could belong there if we could make a solution

<mjk> profile is definitely a good place due to lack of a universal pattern

<mjk> e.g. special support is needed

Ege: if we want a TD for Thing Directory, we must solve this problem

<mjk> +1 this is also a discovery issue

Ege: we could reuse an ID to query
... this is what hypermedia tries to do

<Ege> https://swagger.io/docs/specification/links/

<kaz> (yeah, that's why I mentioned this topic is related to Discovery and we need to clarify the use case scenario including that viewpoint as well)

Ege: also in OpenAPI

MM: we don't want to update the Thing Directory TD
... so we prefer the static approach

ML: what could be the starting use case?

SK: let's postpone this discussion.
... let's continue in the Profile call.

<mjk> The use case is a static TD for the Thing Directory that supports hypermedia controls

ML: makes sense.

SK: 7 mins break

<kaz> (and use case call collaboratively, I'd suggest)

<kaz> [ reconvene in 7 mins; 5 mins past the hour ]

Thing Model

<Ege> ack

<kaz> scribenick: Ege

sk: Thing Model was called TD Templates in TD1.0
... what is TM needed for in the first place?
... We can onboard models into a system, we can simulate Things before developing them
... to reuse parts of models so that you don't define it again
... another way to look at it is to instantiate TD instances from TM
... this is relevant for deployment scenarios
... you can write the affordances, put string templates and then replace them with instance information during deployment
... now I will talk about how we can combine different models
... we should use existing solutions, examples are from JSON Schema, JSON-LD and SDF

<mjk> $ref uses json-pointer

sk: we can also use the ids for TMs to use as import mechanism
... JSON Schema has the name clash problem

<mjk> it's "sdfRef" for references

mjk: we use JSON Pointers as the value of the reference and we use sdfRef instead of $ref

<mjk> the way we use json-pointer avoids name conflicts in oneDM

mm: the components discussion is coming up, we can maybe define a mechanism with the components and also use it here

<mjk> in SDF, every reference is a unique URI consisting of a namespace and a unique json-pointer

<kaz> kaz: would agree with McCool basically, and suggest we start with JSON-LD approach as the basic one given TD is a kind of JSON-LD, and we can think about the other approaches like JSON Schema and JSON Pointer. And for that purpose, we should elaborate concrete use cases for the two basic categories, (1) standalone usage and (2) template usage based on people's need and interest. For example, in which case and time/location, we need which capability and notation for what kind of devices, etc.

<McCool> (also my main point was that @context used inside an object overrides definitions in enclosing object... which I think is what we want, especially if "components" are handled in sub-objects)

cris: Using $ref would give the impression that TD is a JSON Schema

sk: sort of, we would just use the vocabulary but not the mechanism entirely

<kaz> /

<mjk> we decided to create sdfRef as a way to avoid confusion about the side effects, etc.

<mjk> json-pointer can be used to point to a part of a TD

sk: the problem with @context is that you don't know what is used from the context, maybe nothing is used, maybe it is inserted accidentally

<mjk> +1 what sebastian just said

<mjk> we can point to what we need in a TD

https://swagger.io/docs/specification/using-ref/

ege: OpenAPI also uses the $ref and not only for schemas

sk: so now let's see an example for combining

ege: what about a processing the models and letting the processor handle name clashes

sk: so you mean that the processor would deal with this on its own

ml: we should think of the data model first, this diagram is a bit complex

<mjk> we need some structure in the composed thing ...

ml: I don't know if we have the requirement of handling combinations of thing models into a new model

<mjk> in SDF and iotschema, there are separate "capabilities"/"objects" that keep the conflicting names in separate paths

kaz: I agree with ml. Do we have this requirement for a concrete use case?

<mjk> +1 sebastian we can review current art in the industry including zigbee/CHIP, OCF, OMA and others which are all composed models

<inserted> kaz: seems to me a bit too complicated to have this inheritance capability. would see concrete use case for this if we really need this capability

cris: I agree with kaz
... Also problematic when we think of template strings in a TM, what if there are name clashes there?

mm: We should define the use cases and make sure that simple cases are simple and focus on those

mjk: I agree. You can do components in a TD, put the models in there and then handle the name clashes via paths which will be different

<McCool> (I also said I feel strongly we should solve this as part of dealing with components, and resolve conflicts (if there are any) by having a clear priority order (so you always know which import overrides other imports))

sk: So I will note this. Most seem to be interested in the simple case
... It would be nice to have more examples. Oracle and Eclipse Vorto?

kevin: Yes I can bring generic models for the discussion

<kaz> [5min break]

thing description components

<inserted> scribenick: cris

<inserted> scribenick: cris

taki: recently, in the TD we discussed about how to define components. This is related to the previous topic about Thing Model
... I have a couple of slides to discuss
... but if somebody else wants to show something please feel free

ege: I have some slides about the topic

taki: mccool do you want to show something?

mc: I don't have any, but I think that oneDM is a good candidate for this task

taki: I just want to give a context about this issue
... everything starts from our charter document
... for example link relation types are mentioned in the document

<Mizushima> --> https://www.w3.org/WoT/IG/wiki/images/6/6f/2020-10-21_TD_mechanisms_for_components.pdf thing description components

taki: composition is a relationship type that should be discussed. Another one is the "controlBy" relationship
... we discussed a lot about how to define relationships between TDs
... slide two gives a little summary about what we are discussing.
... we can use UML Associations as a staring point
... I think we should start from UML composition when talking about TD components
... in Munich Benjamin described a car represented with different TD. Using only one TD would be really messy (i.e. the TD will be huge)

<kaz> wot-thing-description Issue 168

taki: issue 168 is relevant to the composition discussion. It offers an use case and an example about how to do composition using inheritance

<Ege> https://swagger.io/docs/specification/components/ is also related maybe?

taki: issue 958 is more recent and talks about components

ege: I am not sure if the components are separated files or just declarations inside TDs

taki: the proposal in 958 seems to have all the definition inside one single file. I think we could discuss where components are defined later. It depends also from the use case

mc: I think the main issue is to spit big api definitions in smaller components
... the car may not be the best example for components use case.

taki: about WoT Directory is more to categorize apis in sub parts.

<mjk> q

mc: we need an hericacl way to access different APIs. Scripting could leverage on that. Probably, component word is misleading ... module would be better
... I'd like to have still one single thing but divided in sub parts
... namespaces would avoid name clashes. I think OneDM do the same

mjk: exactly

mc: anyway I think the example shown in slide 5 satisfy the use-case from WoT Thing Directory
... I think model implementation is orthogonal to this issue

kaz: we are talking about two issues: in 168 should be handled in the TM discussion. The 958 this is reminded me speech interface. However this approach failed. w3c used another approach in the end, e.g., Multimodal Architecture, to integrate multiple devices and applications and SCXML is the key spec to control the state machine for multiple components

mc: I agree that inheritance is another issue

kaz: right

mjk: in OneDM we have semantic bread-crumbs

taki: are flat models similar to semantic bread-crumbs?

mjk: it is similar to what you are showing in slide 5
... sdfRef is exactly the link to the Television TD Model
... client can use the component knowing that it is a Television easly.
... we also use this feature at orchestration level.

mc: this implies that the scripting api should know about this model

mjk: they just need to expose it to applications

mc: scripts could align this component model too

taki: time check. we can switch to Ege's presentation

ege: ok for me

system descriptions

ege: we are focusing on mashups and how to represent them
... we started from a simple use case. Consume different things and then expose them as an a new aggregate thing
... we could do this in different ways. Scripting api is the more natural way
... node-red is a visual apprach
... mash ups are not really portable as node scripts
... code and node-red flow might be complex to read and understand
... also we can't formally verify and visualize the behavior
... however in industrial automations we have formal ways to describe behaviors
... like sequence diagrams
... so we started from sequence diagrams to describe WoT systems
... than we evolved it to a specilize thing description format
... it is called System Description
... from a SD you can generate code
... this work has been published recently
... (shows an example of WoT sequence diagram)
... from this sequence diagram we can generate a SD
... we have defined JSONLD context and the ontology as well
... (shows a SD example)
... we this simple SD we could describe the whole logic of a mashup
... In the paper we explained a scenario taken from one of our PlugFest
... the most interesting is about smart home scenario
... we defined also more a complex scenario. Like controlling a robot arm and different sensors

lagally: this is really interesting application. I really liked it. How do you handle the parallel execution described in slide 10?

ege: so this means that you can execute the block in any order

lagally: it think this could raise some problems due to non-deterministic behavior
... the system description could be used to implement simulations. Did you think about it?

ege: yes we are working on it. We also working on how to verify that the system is behaving as described

<taki> +q

<kaz> MMI Interoperability Test Report

<McCool> (comment: par just reflects the reality that these things *might* be running on different processes(ers), so it may be unavoidable)

kaz: thank you really much. 8 years ago w3c was working on the same topic. I just linked an implementation report document
... might be interesting

ege: I used it sometime ago. it is pretty similar to what we have done

kaz: thinking about concrete requirements should be in this context

taki: I'd like to know more on this topic. also about the component part

sebastian: thank you everybody

<Zakim> kaz, you wanted to ask about scripting note publication

<kaz> kaz: given we're out of time, let's talk about that tomorrow :)

<kaz> [adjourned]