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
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
Lagally: we have separate md files in WoT architecture github
https://github.com/w3c/wot-architecture/tree/master/USE-CASES
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
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
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"
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
https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/thing-templates.md
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]
<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
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
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
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]