WoT-IG/WG Virtual F2F Meeting - Day 2

18 Mar 2020


Kaz_Ashimura, Christian_Glomb, Michael_Lagally, Elena_Reshetova, Zoltan_Kis, Cristiano_Aguzzi, Daniel_Peintner, Ege_Korkan, Jennifer_Lin, Klaus_Hartke, Michael_McCool, Taki_Kamiya, Michael_Koster, Tomoaki_Mizushima, Takahisa_Suzuki, Ryuichi_Matsukura, Kunihiko_Toumura, Ben_Francis, Ari_Keranen
McCool, Sebastian
Zoltan, McCool, Koster, Kaz



Invited guests

scribenick: kaz

<inserted> Cristiano Aguzzi from Univ. Bologna

<kaz> W3C Patent Policy

<kaz> Patent Policy FAQ


<kaz> Architecture: Zoltan and Sebastian

<kaz> TD: McCool


scribenick: zkis

Recap from yesterday's meeting

Lagally: summarizing yesterday's presentation about use cases

[ML pres link]

Lagally: use case management
... use cases in the github repo, organized in domains
... we have assigned people to care about use cases in each domain
... Healthcare domain needs an owner

McCool: could take that up with Jennifer Lin
... but this is only one use case so far
... it might have regulatory issues

Lagally: TD could be still used

McCool: health has 2 categories, regulated and non-regulated, the latter is a problem

Lagally: ok, we keep it open

Taki: could also volunteer for Medical

Lagally: use cases in work

McCool: these are more like technologies than use cases
... we should look at existing use cases that match with these

Lagally: right, we want to detect the dependencies
... some use cases don't have an owner, like fleet management, data streaming, audio/video, agriculture

McCool, Jennifer, Philip volunteer for Fleet Management

For data streaming, Dave Raggett with question mark

For Audio/Video "treatment", issue-8 in architecture github

McCool: we can merge this

Kaz: we can combine this with other media-related use cases and close this one

Lagally: combined with issue-442 in architecture

McCool: we need to ask Dave whether could take Video/Audio domain

Lagally: Kaz, please ask Dave

<kaz> ACTION: kaz to ask Dave about his issue on data streaming use case

Lagally: finally about Agriculture domain

Taki: take it with Matsukura-san

<kaz> (Kaz will also ask the Agriculture CG guys as well)

Lagally: use cases are grouped based on business relevance, WoT member relevance and by number of active contributors
... that was recap from yesterday, now we move on to today's topics

McCool: presenting uses cases from architecture github

[link to USE-CASES]

<kaz> retails use case

McCool: presenting the retail use case
... related to the PoC to be presented tomorrow

Consolidating use cases

Lagally: we have separate md files in WoT architecture github


McCool: in each use case we need to make a list with related components
... so that we could relate these across use cases
... also for dependencies such as security related things

Kaz: what do we mean by "dependency" here?
... for instance "WoT Profiles" is listed
... maybe use a different name, like "dependent topics"

McCool: we should add description for each section in the template

Lagally: right, they are not very complete

McCool: what about "Target Users"

<kaz> ACTION: Lagally to improve the description on what the "Dependencies" section means in the use case template

Lagally: let's pick a realistic date and complete the use case consolidation
... for instance in 2 weeks time

Schedule and deliverables

Lagally: for Q1, completing requirements and use cases should be realistic

McCool: Jennifer was asking if we can go through the Singapore use cases
... will coordinate off-line

Initial requirements for selected use cases

Lagally: we have quite a list of use cases and requirements from the new WG charter
... these require architectural input

McCool: which version of the charter was that?

Lagally: last year Oct-Nov

McCool: the descriptions should be updated based on latest charter version

Lagally: OK
... presenting requirements

<mlagally> https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/requirements-template.md

<McCool> mm: regarding my comments regarding thing templates, never mind, I looked it up, and the current one-liner does mention classes, etc.

<McCool> mm: https://www.w3.org/2020/01/wot-wg-charter.html


<mlagally> https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/geolocation.md

McCool: is security included here?
... in each use case we need to consider dependency on security, discovery, etc

Lagally: McCool, please update the text
... with the security checklist
... and others may add others checklist

McCool: will create an issue and follow up

<McCool> mm: issue to add deliverables checklist to requirements template: https://github.com/w3c/wot-architecture/issues/457

<Zakim> kaz, you wanted to provide some resource on ISO 19116 "Geographic information"

Kaz: I was involved in the Geolocation WG, so thanks for including the Geolocation API.
... My suggestion is adding ISO 19116:2019 as well. There was discussion about the basic mechanisms and also accuracy of geolocation information

<kaz> ISO 19116:2019

McCool: also add OGC and ETSI to "related standards"

Thing Templates

Lagally: affects almost all specs
... this is a substantial change

McCool: yesterday we discussed the role of Scripting and protocol constraints
... we could capture that as a note or TODO


McCool: we should define Thing interface vs template
... for me template means "partial"
... it also shows up in discovery

Sebastian: we should be careful to not introduce so many TD related terms
... this would be confusing
... the concepts are not that different
... we can discuss that in the next session
... to avoid complexity

Lagally: agree, this just tries to capture eventual differences

Sebastian: we need a definition for "template"

Lagally: we can discuss this either this week or in architecture calls
... we need to keep terminology clear

McCool: we need to identify who needs templates
... for instance scripting, discovery, etc
... and then we can decide if they are the same thing or not

Zoltan: agree with McCool

Lagally: agreed

McCool: we need to investigate 3 things: interface, scripting, search template
... and see if they are the same or not

Ege: template is anything that does not have instance information
... for instance href with specific URI
... this is a requirement for Wotify

<McCool> mm: by the way, time check

Lagally: well, something like a stripped-down TD, or subset of a TD

Ege: everything that changes is not a template

Sebastian: this is a very old topic, we discuss this from the beginning
... I think we don't need more time on this, but work on technical realizations

<McCool> mm: I don't think we need to "collect" requirements, but we do need to write them down

Lagally: we anyway need to document what we mean by the terms

Sebastian: we also have plenty of issues in the TD repo related to this
... and I'd like to discuss that in the TD session

Kaz: technical details in TD session should be ok but it should be discussed based on how templates are used in use cases

[Architecture session adjourned; 3min break; and then TD session]

Thing Description

<McCool> scribenick: McCool


<kaz> Agenda for today

<kaz> @@@slides tbd

guest: Ben Francis, Cristiano Aguzzi

Sebastian: reviews agenda, notes many issues for templates, efficient TD encodings, security aspects (esp OAuth2)
... (sharing presentation)
... reviews what we have done and its motivations
...started with basic idea of affordances, now have a good data model and experience via plugfest
... we need to celebrate this accomplishment, unfortunately not together
... of course much work yet to do; right now we are like HTML1.0; lots of things, but basic functionality is there

TD templates

Sebastian: we have discussed requirements in the previous call
... also interesting to hear from Bosch that they are using something like templates in their system
... there are multiple reasons why we need templates
... there are different phases during development, and during some of these phases the information will be incomplete
... in the planning phase, may have some rough templates to decide on basic affordances, then look at data schemas, etc.
... we should consider the requirements for TDs in these early stages and applications
... we also want templates to describe "classes" of devices

McCool: comment, not just classes, but "sub-interfaces"

Sebastian: and in scripting we also see a need for a partial TDs

Lagally: we do have two use cases that apply; digital twin and big data

Sebastian: think there are many more use cases
... also, in digital twin, also represent classes of devices
... this topic is actually very old, we have lots of use cases

Lagally: we have been discussing this for a long time, is existing text
... we should be careful not to miss any requirements
... simulation
... we need to cross-check against what we have; if something is missing, we need to document it

Ben: two points
... looking at the use cases that relate to templates
... would argue that every TD is a digital twin
... when do we pass a TD?
... vs a template? why not just always compose on the server?

Lagally: there are uses when we are composing TDs from components, etc.

Ben: other question is difference between templates and capability schemas
... capability schemas describe classes of devices, and can be inherited that way
... seem to be some overlap between these

Lagally: we don't yet have capability schemas as a formal component of WoT

Koster: ODM does provide capabilty schemas

Ben: if think of templates as classes and objects
... TDs are instances, capability templates are classes

Koster: ODM do define an object and capability model, can b e composed
... see capabilities as a way to pregenerate metadata, but not at the level of specific instances

Ben: don't quite understand where and when the composition into instances happens, on the server or client
... do TDTs belong in the TD specification?

Koster: good question; do we need a spec for "partial TDs"; what parts you need depend on the workflow
... as noted, there are multiple applications
... for template-based search; for hypermedia forms (eg actions); and for classes as noted

Ben: makes sense you need templates "internally" on the server side
... one use case that is client-side is discovery templates

Sebastian: comment on why we need in spec
... right now we describe what is a valid TD
... need to clarify what is the difference between a full TD and a template
... example is a bulb, that has everything but the specific IP address it is at

Lagally: we mixing the notions of templates and partial TDs
... let me show you what the current spec says

<mlagally> A Thing Description Template is a description for a class of Things. It describes the properties, actions, events and common metadata that are shared for an entire group of Things, to enable the common handling of thousands of devices by a cloud server, which is not practical on a per-Thing basis. The Thing Description Template uses the same core vocabulary and information model from ยง 5. TD Information Model.

Lagally: is from the appendix, so is informative, but it is a definition
... more than just a partial TD, has specific required information, namely affordances

Koster: partial TD may not be consumed by the client, but may be used in other places
... hypermedia controls and search templates
... and then there is the process of creation
... library of things to compose things is useful

<inserted> scribenick: zkis

McCool: categorize use cases to client vs server side
... search templates is client side
... but first we capture requirements

<inserted> scribenick: McCool

McCool: I think we need to step back here and list use cases and requirements here
... also note that hypermedia controls are client-side use cases

Zoltan: would say that scripting use case isn't exactly a partial TD, but a dictionary

Sebastian: problem is we need a concrete definition; to my understanding, everything mentioned so far would be a template

Kaz: discussion reminds me that we should look at classes and interfaces
... we should open up the discussion to additional use cases

Sebastian: how complex do we want to make this?

Kaz: we have to consider what use cases we really need

Lagally: complexity will depend on what we need

Sebastian: in the slides I tried to come up with a minimal definition
... it is clear that TDT <= TD
... but how minimal? is {} a TDT?
... do we want to add an @type to identify a TDT?

Lagally: there are identifiers in TDs
... we need to have two things; unique identifier for templates so they can be referred to (eg as interfaces), e.g. templateID
... we may need an extension

Zoltan: why do we need ids for templates?

<benfrancis> How about a separate context for TDTs vs. TDs which could have different validation requirements...

<benfrancis> {

<benfrancis> "@context": "https://www.w3.org/2020/wot/tdt/v1"

<benfrancis> }

<benfrancis> (note "tdt" vs. "td")

Lagally: so we can manage them and refer to them

Sebastian: why not just put them in a database?

Lagally: need to find them

Ege: agree that we need an id, but it should be a new field to avoid conflict with existing spec

<benfrancis> The URI of the template resource could be used to identify a template, no need for an ID inside the JSON payload

Koster: we may not always need an id if it is something like a hypermedia control

Ben: should we have a separate context URI for TDTs? And maybe a different specification?
... do you need an ID, or just a url?

<Zakim> dape, you wanted to if we introduce a *new* ID for template... -> TDT is not a subset of TD anymore?

Daniel: comment on ids vs. contexts
... if we add a separate context, then the subset relationship might get broken
... new id, or new context, then we won't have TDT subset of TDs
... won't be the case if TDTs have extensions

Lagally: comment on bf's comment about URIs
... because URI is a way to look something up where it is stored, but for databases we need the ID independent of location

McCool: note that ids are currently URIs, but if we want to decouple IDs from location we should use something like DIDs

Sebastian: we are looking for what is the minimal definition that fits the use case we want to target

McCool: we should define the use cases first, then...

Lagally: we have a working definition...

Sebastian: but it is just informative; not binding

Lagally: let's take this offline, let's work on the issues to create definitions for TDTs and partial TDs
... once we have definitions, we can discuss details
... we each have a different definition in our heads; let's discuss using a concrete text

Zoltan: for the id, is use case for databases, etc.
... suggest we take it use case by use case, identify universal requirements
... still need to understand a few of them, eg management use case

Lagally: I understand at least three: hypermedia, discovery, interfaces

Kaz: agree that we should go back to use cases to clarify this discussion
... we should not think about concrete notation just yet, but about requirements

Taki: one use case I have seen is interface management; have been assuming each has an ID
... since it is a "definition", and we want to relate instances to the interfaces they implement

Sebastian: seems we still need to clarify the motivations and requirements, especially for IDs
... as proposed, we have to continue discussion based on use cases and issues

Lagally: (put issues here in minutes)

<mlagally> https://github.com/w3c/wot-architecture/issues/453

<mlagally> https://github.com/w3c/wot-architecture/issues/454

Sebastian: another TDT related topic is whether we have relationships between TDTs, e.g. components, inheritance, etc.
... what if we want to override something in an instance?
... do we want to do this?
... is this desirable?

McCool: I would like to see this, and support it with a link and a specific relation type

Lagally: not just for TDTs, but motivates link relation types in general
... so maybe we pool those requirements together when we talk about relation types
... for example, component relationships include TDTs but also other concepts

Sebastian: what do we want on the end?
... considering the TDT context... when we exchange it with someone, should it be self-contained
... or do we have a feature where we have links to refer to other documents that then have to be fetched?

McCool: I think we should realize that links to well-known concepts don't necessarily have to be fetched
... and other standards use links much more extensively; it avoids redundancy

<mjk> @mccool yes

Kaz: links would be useful in many applications, eg. automotive, CE devices

Ben: requiring the client to resolve relationships is a problem; consider the situation of HTML templates

Sebastian: I do think TDTs need to be self-contained
... then don't need inheritance etc. in my opinion

Lagally: problem on this slide; "overwrites the name" is a problem described in requirements document; needs to be a way to manage name scopes, etc.
... need to look into namespaces, etc.
... second, think it is premature to make design decisions without understanding requirements

McCool: first, we may still want to know what TDT a TD is and instance of even if we don't fetch it
... second, if we use semantic annotations the namespace issue already has a solution; but that is an implementation choice we should look at later

Kaz: we should see actual need from the vendors and service providers based on concrete use cases
... there is a possibility we could live with some preprocessing mechanism which provides resulted self-contained TD to the clients for this purpose (=referencing outside TDTs)

Sebastian: we still need a lot more discussion, use cases, and motivation
... on slides, did make a proposal for next steps
... but based on the discussion, maybe have to reconsider; but this slide does point to various issues
... we definitely do need a formal definition
... and we still need to keep the complexity at an appropriate level
... ml has proposed that ml and seb collaborate on a proposed definition, then bring back to group to discuss

Lagally: sounds like a plan. Let's do it
... stakeholders who are interested, please take a look at what we already have and please bring up additional use cases and requirements

Initial connection

Sebastian: (put link here...)
... base term is currently used to define the base URI for affordances
... but may need more information, for example, default contentTypes, subprotocols, protocol settings shared by all interactions, etc

<kaz> Issue 878

Sebastian: this would be useful to avoid redundancy
... (links to issues 878 and 803)

<kaz> Issue 803

McCool: is this specifically a TDT issue?

Sebastian: for a class of devices, want to say that this class of devices uses coap

<kaz> Sebastian's comment on Issue 803

<kaz> [[

<kaz> In the past, we had a base that could be used as an array for multiple protocols. However, this was criticized because of the arithmetic that you have to take care of (as TD designers and implementations).

<kaz> ]]

<kaz> https://github.com/w3c/wot-thing-description/issues/803#issuecomment-532986494

Sebastian: but we need a way to identify a protocol but not a full URL
... suggest that we use URL patterns/templates to do that

<zkis> https://url.spec.whatwg.org/

Kaz: mentioning TDT here (=Improves the design of TDTs) is a bit confusing though there is a possibility TDT could be a solution
... it's not specifically related to TDTs, but is a general issue for TDs
... so maybe should change the title of this bullet point from "Improve the design of TDTs" to something generic based on the issue 803 itself

McCool: I see the issue of identifing a protocol without a URI is TDT-specific; but other things are TD improvements

Ben: interesting since still chair of subprotocol websocket CG
... current design is that we use use a link, and would be a subprotocol member of that link
... but what if a web thing has multiple protocols or subprotocal

McCool: maybe we could reuse the "definitions" structure used for security

<inserted> scribenick: mjk

Ben: the wss scheme has a single URI

<inserted> scribenick: McCool

McCool: although we need to simplify it for the common case

Ege: using links like bf describes would useful; common case is only one

Sebastian: slides have some examples based on github discussion
... would expand base with an object
... in addition to an href, would have other information for the protocol binding

Ben: example on the left, however, is not how Mozilla's approach works
... instead we provide a top-level link

Lagally: where are we going to spec this, how do we test?

Sebastian: not decided yet; subprotocols still a large list, many in the market
... sse, webthings protocol, etc

<benfrancis> Correct example of link to WebSocket endpoint in Mozilla implementation (see wss:// URI) https://iot.mozilla.org/wot/#example-6-example-links-member

Lagally: could define various payload formats for a single protocol, so we may not want an exclusive list, just some examples, informative, leave it open

<Zakim> dape, you wanted to breaking change of base, maybe use other term

Daniel: need to be careful about changing meaning of base term; may result in breaking changes
... better to define a new term

Koster: just naming a subprotocol may not be sufficient; we have to describe in some detail how it is used

Ben: webthings is defined explicitly for web of things, though

Ege: relation type "alternate" used in example; rel may not be appropriate here

<mjk> @ege agree

Ege: what is in base is what ALL forms should use

Ben: don't think "rel" makes sense in the base... would put it in a "link" instead, if using websocket alternative

Sebastian: a related topic, should base be both a string and as an array?
... might be a breaking change (?)
... can introduce same feature as for @context
... may also want objects, as in previous example (to include protocols settings, etc)
... propose that object should follow the Form class

Zoltan: is getting very complex
... what is the benefit we are after?

Sebastian: as discussed in the beginning, have all protocol settings in a single place
... of course we currently do it per-form, but it gets redundant

Ege: and actually, in mqtt, not actually very clear
... current system implies we open a socket to the broker for each interaction

<mjk> establish a persistent connection

Ege: but actually we want to open a connection to the broker first, and leave it open...
... also applies to websocket connections

<mjk> don't we have a discussion point scheduled later for this topic?

<Ege> https://github.com/w3c/wot-binding-templates/issues/14

McCool: time check

Ege: in case of mqtt of node-wot, I need to configure, out of band, the URI of the broker
... it's not in the TD...

<Zakim> dape, you wanted to extending base to array causes issues in deployed applications

Daniel: proposal does not consider existing implementation; proposal may be a breaking change

Lagally: how many TDs would benefit from this feature?
... how is appropriate base being selected if there is more than one?
... which base would be used for which context?

Sebastian: need to explain in more detail
... would use multiple bases when there are multiple endpoints

<kaz> scribenick: kaz

Kaz: we should clarify our actual need for this capability
... maybe we want to have a sub-manager which bundles multiple things for a mashed-up service
... but we should clarify that to continue the discussion

Sebastian: would like to continue the discussion
... also we should discuss the remaining topics
... e.g.,e efficient formats by Taki and Daniel

Tomorrow's meeting

McCool: let's quickly skim the agenda
... joint calls
... me and David Ezell working on Conexxus/EdgeX topic
... Koster, can still do the topic on CHIP/ODM?

Koster: yes
... mind if move to earlier?

Sebastian: what about swapping with eCl@ss topic?

Koster: that would be fine

McCool: should create my slides
... the agenda looks OK to me

Sebastian: ok
... thanks for joining, all!

[Day 2 adjourned]

Summary of Action Items

[NEW] ACTION: kaz to ask Dave about his issue on data streaming use case
[NEW] ACTION: Lagally to improve the description on what the "Dependencies" section means in the use case template

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2020/03/18 00:09:26 $