W3C

- DRAFT -

WoT Architecture

27 Aug 2020

Agenda

Attendees

Present
Kaz_Ashimura, Michael_Lagally, Michael_McCool, Ryuichi_Matsukura, Michael_Koster
Regrets
Chair
Lagally
Scribe
kaz

Contents


Agenda

Lagally: two specs: Profiles and Architecture
... profiles has 2 MRs
... architecture needs spec drafting
... work split and contributions as well

Prev minutes

Aug-6

Lagally: kind of long discussion on wot-profile

McCool: we need to go back and think about the components
... required features possibly including communication protocol should be the core profile

Lagally: would be good to define core data model as well

McCool: interoperability would be on the protocol level

Lagally: yes
... at least one protocol

McCool: yeah, if some device works with HTTP and another one also works with HTTP, those two should work with together

Lagally: regarding the minutes themselves, any objections to approve them?

(none)

Lagally: approved

Profiles

Lagally: wondering about compound multi-protocols

McCool: the structure of the Profile document is quite abstract
... get-out-of-box interoperability is important
... everything satisfies the core profile
... possibly have a HTTP Profile

Lagally: note that we should avoid data fragmentation

McCool: right

WoT Profile draft

Lagally: (shows the ToC of the above draft)

McCool: Security is important and to be included in the core

Lagally: (then shows the TD spec's "5. TD Information Model")

TD - 5. TD Information Model

Lagally: that is the datamodel
... for digital twin use cases, we don't have to think about protocols

McCool: on the other hand, actual device interaction requires protocol binding
... starting with HTTP
... then MQTT
... CoAP might be a bit difficult

Lagally: ok
... we have core data model as section 5 within WoT Profile

McCool: the Core Profile could assume HTTP

wot-profile issue 2

Lagally: way to identify profiles

McCool: new version of @context could be used?
... like this format using "#" for the detail
... [["@context": "https://www.w3.org/2019/wot/td/v1#core"]]
... additional protocols could be specified like:
... [["@context": "https://www.w3.org/2019/wot/td/v1#http"]]
... [["@context": "https://www.w3.org/2019/wot/td/v1#coap"]]

Lagally: profileCompliance = core
... profileProtocol = http, coap, ...
... ?

McCool: yeah
... seems reasonable

Lagally: (adds a comment to issue 2 about that point)
... this could be addressed by two new keywords (vocabulary terms): profileCompliance, profileProtocol
... profileProtocol can be an array

Koster: question about protocol binding constraints
... and data model part
... specifically, "core data model"
... out-of-box interoperability could be constraints?
... could define smarthome data model
... don't see super-tied use cases yet

Lagally: if you look into the current strawman draft...
... would like to identify some specific devices
... e.g., for geolocation use cases

Koster: common object to define locations and address discovery, etc.
... you have to have some object for that purpose
... for out-of-box interoperability

Kaz: think I can understand the concept of switching profiles using "@context"
... but would see how to do that based on concrete use cases
... maybe we can use the existing use cases as the basis

Lagally: we should be careful about how to deal with the data model part and the protocol part

McCool: would agree with Kaz that we should think about use cases
... some vocabulary could be involved like geolocation vocabulary
... we don't have any concrete geolocation context file itself yet, and that is frustrating, though

Lagally: we could define some mandatory features for actions, properties, etc.

Kaz: if the geolocation use cases are important, we should start with them and clarify what is included in the core profile and what is extension

Lagally: yeah

McCool: think we can do that

Lagally: btw, what can we do for the FPWD publication until the end of September?

McCool: we don't need to define the detail for the FPWD

Lagally: (shows the Editor's Note at the end of 5.1.2.2 Recommended practice)

[[

It will be evaluated whether the profile also recommends some new TD terms that may be introduced in TD 1.1. Currently the following terms are discussed: serialNumber, hardwareRevision, softwareRevision, loc_latitude, loc_longitude loc_altitude, loc_height, and loc_depth. If these, or some of them, are defined in the TD 1.1 model, they may be recommended here in one of the next draft updates.

]]

McCool: we could walk through the spec and identify issues

Lagally: that's actually the plan

Koster: there are both "Interaction Affordance" and "Event Affordance"
... probably "Interaction Affordance" should be "Action Affordance"

-> https://w3c.github.io/wot-thing-description/#dataschema TD - https://w3c.github.io/wot-thing-description/#dataschema

(discussion on units)

Lagally: make units mandatory?
... (creates a new issue on wot-profile)

Koster: would suggest we align with OneDM which uses SenML units

McCool: would say you must use SenML units if exists, otherwise you must use QUDT

QUDT Ontologies Overview

(discussion about the concrete description on how to deal with units)

SenML

issue 29 - consolidated comments on how to deal with units

<mjk> https://tools.ietf.org/html/rfc8428#section-12.1

McCool: also we should create another issue on if we allow only a finite set of vocabulary extensions

Lagally: (generates another issue on that)

Issue 30 - Allow only a finite set of vocabulary extensions?

Lagally: (going back to Issue 2)

Issue 2 - Way to identify profile(s)

(discussion about data annotation)

Lagally: (creates yet another issue)

Issue 31 - Annotate the data model with common elements

(also discussion on how to indicate preference on annotation scheme

Issue 32 - Standardized way to indicate capabilites

Pull requests

PR 23

Lagally: (merged PR 23)

PR 28

Lagally: (merged PR 28)

wot-architecture PR 505 - Create a new requirements from agriculture

rm: will work on that

Lagally: tx

wot-architecture PR 531 - Define Discovery requirements

McCool: need to link it with motivated use cases
... also other related verticals
... already ha sections on security, privacy, user needs and accessibility

Lagally: good piece of work
... also looks good
... we can once merge this and then update it later

Kaz: sounds good

Lagally: (merged PR 531)

Architecture

current draft

Slides

Lagally: recollection of the structure
... current structure on the slide as well
... and proposed structure for 1.1
... 1. Introduction
... 2. Conformance
... 3. Terminology (+ delta for discovery, thing templates, profiles, lifecycle)
... making "4.1 Application Domains" a level 1 chapter
... also making "4.2 Common Patterns" another level 1 chapter

McCool: what about edge computing?

Kaz: adding the edge computing use case itself would be nice, but we should think about how to structure those three topics, "application domains", "common patterns", and "edge computing"

McCool: yeah, we could say "verticals", "horizontal" instead?

Lagally: verticals, horizontals, and placeholder for the others

NOTE: Edge computing is a horizontal use case.

Kaz: how to deal with the content within the current "4.3 Summary"?
... maybe multiple system integration or something like that?

McCool: yeah

Lagally: "6. WoT Architecture" to be "Abstract System Architecture"
... rework on the existing chapter 6 and improve the whole structure
... "6.1 Overview" to be split into subchapters
... "6.5 Hypermedia Controls" to include "Semantic annotations" and "Thing Model Concept" (Templates)?

McCool: would like to propose we go for incremental improvement

Lifecycle

Lagally: new subchapter under the "Abstract System Architecture" section?
... including:
... * Introduction (Zoltan and Lagally)
... * System Lifecycle (Lagally)

(out of time)

Lagally: will upload these slides

Kaz: also it would be good to put the content on some MD file(s) so that people can raise issues directly

McCool: like outline.md

Kaz: right

[adjourned]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2020/09/03 14:22:42 $