Lagally: two specs: Profiles and
Architecture
... profiles has 2 MRs
... architecture needs spec drafting
... work split and contributions as well
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
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
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")
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
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
(discussion about the concrete description on how to deal with units)
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
Lagally: (merged PR 23)
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)
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
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]