WoT vF2F in June - 21-30 June 2021

Agenda

McCool: presents the agenda
… topics today are testing results and rechartering
… Friday 2nd time slot is reserved for overflows, however really bad for people in Japan
… Resources: agenda is on the Wiki, will be updated
… presentations are in github, there'S a template

Please add link to the material to the outline, please follow the naming conventions

Testing

<kaz> McCool's Testing slides

McCool: will present "Draft TD implementation report"
… there's a PR (#1155), would like to merge it after review
… TDs for the testfest event are available in the wot-testing repo

(mmc presents the rendered version of the report)
… we would like to include testimonials, need to add several ones
… we also need to reorganize to not count node-wot more than once
… The main section is the test report section (chapter 8.1)

Ege: Why are there 29 ActionAffordances?

McCool: tool does not group things

Ege: why use companies and not implementations for the grouping?

McCool: I'm considering to create new directories for node-wot and count them once
… gaps are marked in red, but there may be more after the reorg
… we also should separate consumers + producers

Sebastian: Is there a cluster with new technologies that is not addressed?

McCool: I have it in the summary, e.g. canonicalization, validation
… Action with @type annotation
… expected responses + success defaults
… default language direction
… events, new link type
… thing model as a full new category
… we do have test data for thing models, however all are consumers
… we have 3 companies that provided TMs
… we don't need to have automatic testing for everything, but need evidence for implementations of new features
… these are identified by annotations in the spec
… implementers have to confirm whether they implemented a certain feature
… security - at the last minute we had received a TD from Huawei for the previous publication, need to check if we still can use it
… some assertions around deprecated flows, these obviously don't need to be implemented
… if we don't have an implementation of a feature at CR these must be marked as "at risk"
… if they don't get implemented by PR, they have to be removed

Ege: I have a PR with some name changes - these improve the sort order

Sebastian: why do we see 0 for several thing model assertions?

McCool: tooling issue, suggest we merge Ege's PR and use it as base

McCool: Next Steps
… get more test data, please submit your TDs to enable us to update the test results

Ege: how to handle the TDs from Matthias?

McCool: ideally we get a testimonial, Kaz, is Huawei still a member?

Kaz: let me check
… Matthias Kovatsch and Barry Leiba are still members

McCool: we are missing Fujitsu, Smartthings, ...
… we need to ask for testimonials from AC reps
… we should move/rename all TDs to indicate the implementer/organization
… MK has a tool that can generate TMs from SDF files
… if we use that we have 2 implementations
… we only need to check the additional TM assertions that are on top of TDs

Sebastian: mlagally, we can work together on a TM in a joint call

Lagally: yes

McCool: topic: Other Deliverables
… We should provide additional implementation reports for architecture, discovery and profiles.
… for Discovery we have testcases for Linksmart done by Farshid
… we can adapt the test report generator from TD for that
… directory tests are testing a network service
… end results are some csv files with test status

Sebastian: we need some people who collect results, I will focus on Canonicalization, Thing Model
… (discussions about assignments / worksplit - outcome is in a slide titled "Assignments")

Lagally: How to use the tooling for test report generation?

McCool: It is described in the readme, single node.js script, could be copied over

PR 1176

<kaz> wot-thing-description PR 1176 - Fix TM related assertion ids, explain a security assertion

McCool: (reviewing the PR, some issues with long lines ...)
… any objections to merge?
… (none)

(10 min break, will reconvene 20 past)

Rechartering

McCool:: 2 topics
… IG Charter and WG Charter

IG Charter

McCool:: expiring the end of June?

Kaz: right
… already got 6-month extension
… will work with the Comm Team about the announcement

McCool:: ok
… extension part is done
… still need to work on the new Charter

Proposed new IG Charter

McCool:: need to update the liaison lists
… wondering about the official liaison table

W3C Liaison table

McCool:: any missing liaison organizations here?
… also W3C groups

Kaz: we can look at the liaison list on our main call agenda as well

McCool:: update ECLASS name, add DID, remove "during the period of the first charter"

Lagally: question about the use cases document

McCool:: (goes through the "Deliverables" section)
… this is for the IG, so only "Other Deliverables" including the Use Cases and Requirements doc
… remove lifecycle, Thing Template
… what about Digital Twins, out-of-the-box onboarding, etc.?

Lagally: how about simulation models?

McCool:: let's talk about what to remove first
… (that said, adds topics to be added as well)
… add simulation models, relationship to edge computing
… how about out-of-the-box onboarding?

Lagally: let's keep it

McCool:: hypermedia-driven to be moved to WG
… what about binding templates?

Kaz: already a WG Note

McCool:: anything to be added?

Kaz: would be nice and useful to have a concrete guide for implementation including binding between TD and ECHONET Lite Web API

McCool:: part of the testing or profile?

Kaz: think it would be better and easier to manage to have a separate document

McCool:: what about the timeline?

Kaz: the procedure itself would take 3 months, so I'd say we should finalize our own draft within one month

McCool:: ok
… let's continue the discussion during the main call

Kaz: also GitHub Pullrequest :)

McCool:: yes

WG Charter

McCool:: the current WG Charter expires the end of January next year

current WG Charter

McCool:: what about the procedure?

Kaz: as similar to the IG Charter, W3C review, AC review and respond to the comments
… usually takes 3 months or so

McCool:: would submit our draft WG Charter to W3M by the end of Feb then
… (assuming a 6-month extension)
… need to think about topics and deliverables
… moving overflow from the current Charter: TD 2.0, hypermedia controls, ...
… new topics: access controls a la Solid PoD
… IG incubation or WG deliverables?
… edge computing, digital twin simulation

Sebastian: Discovery 1.1 which covers even more protocols
… use cases from OPC-UA

Kaz: we need to think about how to deal with liaisons in general

McCool:: yeah
… liaison on protocol binding should be handled separately

Kaz: yeah
… we should clarify that point within the new Charter as well

McCool:: will work on the first draft

Kaz: note we should be going to get input from the proposed Smart Cities IG as well

McCool:: yeah, potential use cases from the group

Tomorrow

McCool:: (goes through the agenda for tomorrow)

Agenda for tomorrow, June 22

McCool:: Profile topics

[day 1 adjourned]

Day 2 - 22 June 2021

Agenda

<kaz> Opening slides

McCool: today we'll speak about profiles

McCool: presentations are uploaded on github
… Lagally slides are missing
… I gave a presentation and uploaded my slide

Profiles

Lagally: agenda: quick intro on profiles, actions, events and HTTP protocol binding
… also PRs and Test plan
… anything else?
… a profile is a normative subset of a TD
… it guarantee interoperability between compliant implementations
… we defined a normative spec document called WoT Profile Specification

Lagally showing constraints on WoT terms
… what are we doing? we are focusing on http binding trying to define constraints and rules on data model
… also security and protocol binding semantics

Ege: what do you mean about representation constraints?

Lagally: it mostly about json-ld TD serialization

Actions

Lagally: we discussed a lot about actions, this slide try to formalize the definition of an action

<Ege> https://github.com/w3c/wot-profile/issues/81

Lagally: they can different request modes
… synchrounous or asynchronous

McCool: I am not convinced about the definition of async and sync

Ege: I am too have a lot of concerns

<Ege> https://github.com/w3c/wot-thing-description/issues/890

Lagally: Syncronous operation example: coffee machine do coffee
… sync returns after the while but it might return before the physical operation
… async should return immediately as soon the request is processed

Ege: I posted some issues with ideas on async/sync actions

Ege: I don't think this is profile material
… we have first need do discuss on the descriptive way

<Ege> ack

Lagally: there are different proposal on the TD about action models
… but we still don't have a definitive model
… we should work on what we have

Ege: we need to decide if we invent a new method or to adapt to previous solutions

McCool: profile spec is prescriptive and I think that there might be other action models
… we should leave the door open to specific solution rather on

Ege: we need tests

McCool: if we keep it simple we could leave out some tests

Lagally: we'll discuss testing later

Ben: there is a proposal on the TD about query action status
… profiles should define a subprotocol
… not ideal but we can even define a prescriptive protocol before we get full TD semantic

McCool: we should define sync as actions that return when complete.
… it is up to the implementer to use sync action in the correct way

Cristiano: why are we limiting actions to effect status?

Lagally: the definition was not limiting I tried to write down a possibile definition, but we can restructure it

Ben: I am concerned about polling action status

McCool: I was talking about the protocol for sync action which is similar to long polling

McCool: the trouble about the first definition is that we have other primitives dedicated to state changes

Lagally: do we have an alternative definition?

McCool: we should mention about side effects and the fact that they could be pure operations

<McCool> ack

Lagally: ok let's assume we have an intuitive understanding of an action and we'll address the definition later

lagally presents a proposal for request modes and timeouts in slide 8

McCool: by query parameter do you mean in the uri?

Lagally: it could be placed anywhere even in the payload

McCool: maybe it is best to be open to different modes
… we could come up with other modes in the future

Ege: it is not feasible to request an implementation to present the same action in different modes

Lagally: actually you could emulate different modes

Ege: well yes it is possible but I think implementers would chose the easy way out and just implement one mode

McCool: also producers might don't want to be constrained to requests
… example: producers might need to reduce battery consumption and don't want to be always on for sync actions

Ege: sync to async is easy the other way around it's hard

Ben: first I agree that the producers should indicate the action mode
… but profiles is for greenfield devices so we does not need to adapt to existing implementations

Ege: even if we are doing it for green field devices it is not easy to support both modes

Kaz: I'm kind of surprised because (1) we had been discussing this kind of topics about sync vs async for actions during the TD calls and (2) the technical details about this should be done during the TD calls instead of the Profile calls.
… we have to keep in mind that we need to clarify our requirements for Actions in async mode or sync mode like expectation for time-criticalness with Actions.
… note that we should think about our requirements for Actions based on concrete use cases like the ones within the Use Cases document, Plugfest implementations and input from liaison SDOs like ECHONET.

Lagally: if we defer this to 2.0 the problem is that TD spec is not really usable so far
… we don't have a clear action model

Kaz: TD itself is a specification on the data model, and we should generate a dedicated document on implementation guideline if we want to describe the detail on the expected behavior of the devices and how to control them from the consumer side.
… our liaison SDOs like ECHONET could help us for that purpose given Matsuda-san's presentation during the previous vF2F in March.

McCool: the purpose of profile is to narrow things down so that people can starting using wot right now
… the focus are greenfield devices but we have to keep an eye on existing implementations
… we should also clarify the scope, we are not doing critical time constraint applications

<sebastian> https://github.com/w3c/wot-thing-description/issues/890

Sebastian: I just want to make your aware that we have an issue on TD repository

<McCool> (sebastian mentions a TD issue - action hints)

Sebastian: we are still waiting for a PR about this new semantic
… we had consensus about annotate a TD mode

Ege: the easiest way out is just defining any action asynchronous

<benfrancis> Proposal for asynchronous action queues: https://github.com/w3c/wot-thing-description/issues/302#issuecomment-802159857

Ben: the discussion is pretty long (is there since 2018), what are we missing to make this happen?

Lagally: we need to discuss about different issues about the proposal

Ben: I just looking for a way to close the issue

McCool: some action can be cancellable but others not

Lagally: it is an odd mode to define action modes

<benfrancis> See also corresponding profile issue https://github.com/w3c/wot-profile/issues/81

McCool: people would probably end up adding cancel*action if we don't close this

Kaz: I am skeptical about this discussion because it is not only about the sync/async flag for actions within TD but also about our expectation on the behavior of the devices.
… So we should define our expectations on the device behavior based on concrete use cases and use case scenarios like the smart home scenario within the Use Cases document first before thinking about how to resolve the issues.
… that's why there is a possibility we need to defer the detailed definition of how to deal with Actions to the next Charter period.

Lagally: we should just define the interface not devices behavior

Kaz: I agree
… However, it would not make sense to just define sync/async flags for Actions within TD. We also need to define what would happen based on the flags and show how to implement actual IoT systems based on the TD and the Binging Template along with the existing standards, e.g., ECHONET, OPC-UA and ITU-T.

McCool: the TD is describing protocol interface but also its behavior
… if we get an extension we have time
… not sure it is the best to just defer it, we are discussing for 3 years
… we could aim for 1.1 keeping in mind that we need to be backward compatible

Kaz: We should look at concrete implementations based on the other SDOs' standards, e.g., ECHONET.

McCool: we could get inspiration from them

Kaz: Please note that when we define the detail of Actions for TD, we should think about the granularity of the actions on the device side, e.g., (opt a) going down and grabbing the target as one action or (opt b) going down is one action and then grabbing the target is another action.

Lagally: we need a resolution

<sebastian> +1

Lagally: let's define a good solution that would work for 90% use cases

Lagally: let's try to not defer everything for the next iteration

Sebastian: I agree
… we discussed this also with Thing to Thing group but we reached the same conclusion: no standard defer
… we should take action instead and propose something based on our experience
… and be the first standard to have a concrete proposal about actions

Ege: I agree to create something from scratch
… sync and async can be closed in this version. More complex modes maybe later

Kaz: I am not objecting to everything, we need use cases about this new possible modes. We already have good implementations
… We could start with those implementations with a concrete scenario.
… If this is really needed, we should add the new features.
… Also I'm not saying we need to blindly follow the potential requirements from ECHONET but there's already a possible use case we can consider, e.g., the one included in Matsuda-san's presentation in March.

Lagally: what you specifically suggest

Kaz: As mentioned during the main call, I've started to ask the ECHONET guys to join the OpenDay meeting next Monday so that we can discuss how to handle Actions for their devices based on a TD.
… If async/sync flag solves all the possible problems, that's great.

Lagally: remember that we are working for greenfield we should not follow closely ECHONET implementation

Kaz: As I've already mentioned, I'm not saying we need to closely follow only ECHONET's approach.
… However, ECHONET has already started to define Actions in their specification and are asking as about how to bind them to Actions within TD.

Lagally: I would start from creating specification text and invite other colleagues for review

Lagally: about opc-ua it should go on the TD not Profiles,

Lagally: we are defining an action model that is workable based on existing plug fest implementations

<kaz> (NOTE: My point is what is really needed for Action definition from all the implementers' viewpoints including Echonet, OPC-UA, ITU-T, etc., and also all the WoT participants.)

Protocol binding

Lagally: we focused on http protocol binding and in particular methods, response codes, headers, payloads
… we defined a subset of methods
… and proibit all the other

McCool: HEAD might be added to the allowed method or simply stating that it might be used

Lagally: we should keep pushing and we could exclude directory

McCool: let's discuss this tomorrow with all the guys from discovery

Lagally: I would not have dependencies with discovery

McCool: I agree

<mlagally> proposal: we should exclude directories from the profile for now

Lagally: response code is also easy somebody just need to put work on it
… is there any http error codes that are contentions or we should leave out?

Lagally: ok, then moving on we have headers. We need to be more specific which one are supported

Lagally: and finally ContentType, should we support also other formats?
… do we have encoding?

McCool: the naive solution would be only json
… and then moving on on binary (e.g. images)
… I would exclude cbor for now
… so I would go for json and encode binary data within json

Ben: I agree, +1 for json and not xml
… about encoding we could have problems for videos

McCool: video streams should handled just with links to endpoints

Ben: should we support video streams?

Lagally: we should not go down that road
… can we just put them out of scope for now

Ege: does this restriction applies to forms or also links

Lagally: well you can link everything

Lagally: no constraints on links

Ege: do you have use cases with multiple streams in different affordances

Ben: yes
… we can support on video from ip cameras cause the consumers supports it

Kaz: about this we should keep posted also Media group and ask for advice

Lagally: video formats cannot be used as payloads

Kaz: we can experiment on this, mccool used webcams

McCool: I just returned images no video
… let's put this on our to-do list

Kaz: ok by me, we should continue to think about it

Lagally: maybe something for the next charter?

Kaz: fine for deferring, but we should keep discussing use cases and requirements. think we could ask NHK guys for opinions.

Events

Lagally showing one implementation for events

<mlagally> https://github.com/cloudevents/spec

McCool: do we know about the IP implication of cloudevents?
… also we should consider openAPI
… is not a bad approach to adapt a standard

Ege: there's also asyncAPI ( we are compatible with them)

<Ege> https://github.com/w3c/wot-thing-description/issues/893

McCool: events and async actions are related
… so the twos should be compatible

Lagally: it depends where the discussion goes

Ben: I didn't know about cloud events, but we should need to define an event mechanism in profiles
… what about Server Sent Events?

Ben: how could event relates to SSE?

Lagally: I am not sure

Ben: it's critical to have a mechanism to push events from the server

Lagally: cloud events might be protocol agnostic

PRs

<kaz> wot-profile PR 82 - RFC 2119 markup: add css mark <span> into index.html

McCool: PR 82 should work with my tooling

McCool: I've just noted there's an assertion inside the editor note
… suggestion merge -> clean up

Mizushima: apparently there is some isue with the index.html itself with some missing tag.

Kaz: we can check the static index.html later and comment on the issue. I'll work with Mizushima-san.

Ben: can I ask which are the next steps about my two PRs?

Lagally: we'll discuss these the next Wednesday

McCool: closing the meeting, please check Profile PRs

<kaz> tomorrow's agenda

[day 2 adjourned]

WoT vF2F in June - Day 3
23 June 2021

agenda

<kaz> Agenda for today

<kaz> McCool's Opening slides

McCool: starting with Profile, followed by Discovery

<kaz> updated current IG Charter

Profiles

Lagally: will look into PRs today
… moreover, we will continue on the actions and test plan

PR 79

PR: New Profile Mechanism section #79 (https://github.com/w3c/wot-profile/pull/79)

Lagally: we need Ben Francis for this discussion
… will skip to other PRs while waiting for Ben

PR 70

PR: device categories - initial draft #70 (https://github.com/w3c/wot-profile/pull/70)

Sebastian: the device categories fit better in the architecture document

<mlagally> Proposal: retarget device categories https://github.com/w3c/wot-profile/pull/70 to the architecture specification

Resolution: retarget device categories https://github.com/w3c/wot-profile/pull/70 to the architecture specification

PR 69

https://github.com/w3c/wot-profile/pull/69

Lagally: We won't consider use cases where a small device consumes TD.
… closing the PR.

PR 57

Canonical representations 2: https://github.com/w3c/wot-profile/pull/57

McCool: full canonicalization is not necessary for profiles. We can consider partial canonicalization instead.

Ben: one use of the canonical TD in profiles is to provide a simple TD in core profiles and a canonical TD to show how a consumer applied the defaults

Sebastian: TD spec already describes how to canonicalize. We don't need an explicit section in profile

Lagally: it can be very brief and point to the TD spec

Lagally: we should also explain how to deal with a device which has no signing mechanism?

McCool: the encryption aspects may fit better in Discovery

PR 79

Lagally: resuming from where we left off...

Lagally: a significant part of the document is being replaced

Lagally: the added examples are very good

Ben: the existing diagram is too complicated. Adding limitations to what the profile can define is premature. The section has been replaced by a simpler text followed by examples.

McCool: we may still need to keep the introduction.

Lagally: the methodology was added after a lot of discussion. Simply removing the whole text is not a good idea.

McCool: the deletion is temporary to start simple and add useful pieces.

Lagally: why not try to remove extra parts after consensus?

<benfrancis> https://github.com/w3c/wot-profile/issues/73

Lagally: it is more effective to eliminate problematic parts instead of removing all and starting from scratch.

Sebastian: maybe such generic information can be moved to Architecture

Lagally: that's a good idea
… not sure if moving this to Architecture adds any value

<McCool> (time check - 4m left)

Ben: the discussion started in issue 73 (https://github.com/w3c/wot-profile/issues/73)
… this is one of the three PRs that implements the discussed changes
… the PRs have been there for two months.
… it is extremely unproductive to only discuss PRs during live calls. The working group should rely more on asynchronous communication channels.

Lagally: will move the section 4 to architecture. The proposed changes can be added to TD spec.

<McCool> proposal: move generic text for profile mechanism to arch and example of use of profile identification to TD

Resolution: move generic text for profile mechanism to arch and example of use of profile identification to TD

<kaz> [10min break]

Discovery

McCool: shows the outline
… start with what is new
… next about embedded metadata and thing types, open issues and finally implementation and testing gaps

McCool: about what's new
… did some TD refactoring
… such as listing for listing all TDs, actions for queries
… did some renaming
… separate events

McCool: most time we spend on embedded metadata to enrich TD

McCool: shows the current draft
… there is now an introduction of the mechanism section and exploration mechanism
… sectopm

McCool: for search there are 3 approaches possible

McCool: is there a recommendation which query approach should be used?
… JSONPath is mandatory

McCool: we need more examples how to use the search mechanism

McCool: shows and explains Figure 4 and 5 in the latest draft

<kaz> 6. Exploration Mechanisms

I miss another option in Figure 4. How about hosting a TD by someone else? E.g., USB stick,

or hosted by a file server, etc.

McCool: its not covered by this spec, however, I will think about this

Farshid: shows Figure 4.
… Directory can also be self-describing
… beside directory we have also Thing Link approach
… Thing Link can be used to link to a larger TD
… or can be used for dynamic desription

Can also multiple TDs be linked?

Farshid: no discussed yet

Farshid: we can provide the proposal to the TD spec

Farshid: now showing the information model

<kaz> 6.2.1.1 Registration Information

Farshid: there are some time parameters: expires (need some concrete time) and ttl (relative time in second, can be extended if needed)
… directories should purge TDs if they are expired

McCool: devices (or agents for devices) are responsible to re-register TDs at the directory and provide a patch before expering

Farshid: anonymous TDs are TDs with no IDs. Directory will produce an unique ID for the TD

how about signing TDs if you add more information as the origin TD have

Farshid: current proposal is only to sign a subset of the TD, ID field is not effected

Farshid: shows the news about notification
… notification is provided when TD is created or deleted
… there is also the option to get the diff
… we defined the payload

Farshid: XPath 3.1 that also covers JSON has a lack of implementations
… JSONPath, even is not a standardized, has much more implementations

McCool: API provides now SPARQL search as Action

Ben: browser limits the number of connections to 6
… in the case of server-sent-events

<benfrancis> https://github.com/w3c/wot-thing-description/issues/1082

Ben: this is true for each tab

McCool: shows slide about open issues
… pagination using explicit JSON payload
… TD/TM appropriateness for describing Disc. API
… RDF framing and round-tripping
… canonicalization and signing
… validation

Christian: whould be great to get feedback about my PR 168, especially from people that have large number of TDs

Ben: for TD/TM appropriateness we should add event subscription for all events

McCool: goes over some open issues
… chunking such as HEAD and PATCH
… missing ops for subscriptions

about properties vs actions is also discussed next week in the TD session
… regarding pagination would be good to be also more independent and make it applicable such as for Web Socket

Farshid: to be protocol agnostic we getting less efficient, however for directory we should be efficient as possible
… also PATCH is important, since constrained devices have less resources to submit always the full TD

cris: pagination is more application requirement. maybe is more a topic for Thing Description
… can be a generic topic such as if a Thing returns a long list of data

Kaz: these topics are very important for implementation. Maybe we need a separate document for implementation guideline but we need to clarify what can be exposed by the Thing side and what is expected to be consumed on the Consumer side, and then think about the gaps between those two, and then think about what features to be added to which specs, e.g., TD, Discovery and Profile.

McCool: there was a discussion about the differences between profiles and directory
… directory not following the core profile

McCool: lets talk about ontologies

Farshid: there is a use for Thing Link for expire
… a candidate for the TD model

<FarshidT> example with registration extensions: https://w3c.github.io/wot-discovery/#example-enriched-td

Farshid: maybe we have also to introduce registrationInfo

Kaz: regarding the issues on Ontologies, we should clarify the general relationship between the TD (and TD ontology) and the external ontologies, because TD is a framework defining the affordance (property, action, event) and ID, and the actual vocabulary for applications is provided by external ontologies.

McCool: the relationship of TM and ThingLink have to be clarified
… also open issue about round-tripping

JSON-LD and TD TF working on this topic. There is a workaround from Andrea

Christian: on open day there is a presentation from Eclipse Ditto. Maybe there we can get some inspiration about collections

McCool: outlook the next meeting on monday

<kaz> [Day 3 adjourned]

Day 4 (Open Day) - 28 June 2021

opening

Slides

McCool: shows the status of the vF2F
… and today's open day meeting
… start with T2TRG
… ECHONET, ITU-T
… in the second session we will have Eclipse Ditto and ISO TC184

McCool: shows the WoT logistics

<kaz> W3C Patent Policy

Kaz: we should also point to the Patent Policy

T2TRG/IETF

Slides

presentation from Carsten Bormann, University of Bremen

<cabo> Yes

<cabo> Trying to set up slides

Carsten: I'm the co-chair of the thing-2-thing research group
… I like to start with IRTF and IETF
… IETF is organized in over 100 groups
… however, there are also IRTF which mainly doing long-term research topics
… T2T group is a IRTF activity
… we have started crypto topics
… we have IoT-related IETF activities
… like 6LO and 6TISCH
… for routing there is, e.g., ROLL as a routing protocol
… for network management we have activities such as ANIMA and IOTOPS
… for application layer there is CoRE and CBOR
… in respect for security there is, e.g., COSE and ACE (similar approach like OAuth)
… RATS is doing attestation
… LAKE is for lighweight authenticated key establishment

Carsten: I like to talk about the SDF working group
… idea is to bring ecosystem specific data model to a common data model
… we have a simple definition format that defines classes of things
… we have interaction affordances such as properties, actions, events
… we planing more interactions such as for electronic components
… serialization is in JSON

Carsten: shows the abstract model

Carsten: there are property interactions which are readable, writable, observable

Lagally: in the WoT Profile we have some discussion about the action semantic, especially about synchronized and asynchronized. What you are doing in SDF?

Carsten: we just describing what is there
… everything could be defined as action, especially with POST

Carsten: SDF 1.1 is stable since March
… we have 200 data models in the playground
… new tools converting from SDF to DTDL
… and to YANG

Carsten: we planing Hackathon in July

ECHONET

Presented by Tetsushi Matsuda
Matsuda: My question is about if there is a document that describes the HTTP protocol binding with WoT?

Matsuda: I have no new slides, I will use the slides from last time

<kaz> Matsuda-san's slides

<kaz> (showing P25 of the slide set)

Matsuda: show a summary of ECHONET Lite Web API

Matsuda: no preference on property change vs action
… there is a difference of the Device Description and the syntax of TD like JSON vs JSON-LD

Matsuda: I have two questions

Matsuda: 1. any document on concrete binding?
… 2. how to map to HTTP header and body?

Lagally: we currently defining a Profile document that specifiy the HTTP binding

Lagally: I have a question about the property definition: Are there also some nested or complex property definitions?

Matsuda: yes, the properties definitions can be more complex

Matsuda: thought property name to be not specified as an object name

McCool: it would be redundant but could specify that

Matsuda: the property name is in the payload message

Matsuda: was not sure about the concrete specification about how to map the HTTP body, etc.

McCool: some examples within the TD spec
… also some of the details to be written in the Profile doc

McCool: any comments?

Lagally: would like to invite Matsuda-san to the Profile discussion

Sebastian: +1
… would make sense
… concrete HTTP protocols specification is not yet described
… because we've not collected enough examples of the metadata usage
… we can't force all the existing implementations to use some specific style
… kind of best practices to be collected
… another question about Profile
… if there is some long-term action, any method to detect the status?

Matsuda: I also had similar questions
… my own answer is
… we support action status
… action invocation with time specified
… we can tell which action to be cancelled
… and then would like to ask YOU
… usage of HTTP can't be specified by WoT, that's true
… but when you specify HTTP binding template with WoT TD
… implementations should use some specific style. right?
… also
… how to adapt the TD and Binding to the other IoT implementations which use different data models?
… we can expect binding template to specify the message body
… for Echonet Lite Web API, etc.
… regarding my participation, ECHONET as a whole is not ready for the discussion

McCool: how to proceed?

Lagally: could identify some specific example for further discussion

McCool: follow-up by email and another calls?
… Profile document to be updated
… Lagally, are you OK with working on that?

Matsuda: should be done via the official liaison

Sebastian: ok. we've already established an official liaison

Kaz: let's talk about the procedure offline later

McCool: ok

ITU-T SG 20

Slides

GyuMyoung: Marco Carugi will give presentation today

Marco: ITU-T Q2/20 (past) WoT lated studied
… sorry but not really updated
… but WoT related issues here
… Y.4111
… semantics based requirements and framework of the IoT
… worked on the use case scenarios
… where the semantics to be applied
… Y.4000
… semantics based requirements described with respect to the IoT reference model
… device layer, network layer, service and application support layer, application layer
… 2nd doc
… Y.4203
… requirements of things description in the IoT
… common requirements for the description
… Y.4203-2
… Things description maps Physical thing to virtual thing

<McCool> https://github.com/w3c/wot-usecases/blob/main/CONTRIBUTIONS/ITU-T-Use-case-summary.md

McCool: document?
… we've reviewed several ITU-T documents as above

<McCool> ... but not Y.4203, it seems

GyuMyoung: would like to include all the key activities

Marco: shows a list of specs

GyuMyoung: one of the key activities ia D2.1
… Technical Specification "Data processing..."
… that is the primary one
… D2.3 generic concept of the data model
… D3.2 sensor things API
… those three are relevant for the discussion wit the W3C WoT

McCool: ok
… as mentioned we've reviewed some of your docs
… want to review the latest docs again
… and continue further discussion
… would like to understand what you're working on

GyuMyoung: some of the docs are not really relevant for WoT
… so wanted to pick those three
… There is Q4 within SG20
… related work items include
… DPM related items and other data related items
… Y.4560, 4561, Sup69
… Y.cii, DFR-SM, energydata, SIS-fm and others
… like eHealth-Semantic, IoT-SPWE, UIM-cs-framework
… and expected collaboration
… W3C, IEEE and AIOTI
… WoT, Global Observatory for Urban Intelligence and Data spaces respectively

McCool: current WoT charters cover some of the topics
… but not cover the analytics, search, etc.
… could be done for the next Charter, though
… do we want to do data management and modeling by W3C WoT group?
… note we're generating another dedicated IG for Smart Cities

GyuMyoung: we've identified WoT-related documents
… would like to talk about use cases, etc.

Kaz: as McCool mentioned, we're forming another dedicated IG for Smart Cities
… and actually held a dedicated workshop on June 25
… so you might want to bring some of the topics to that group instead
… let's have detailed discussion later offline

Marco: yeah, would be very broad discussion, so let's have some more discussion

Hyeontaek: Hyeontaek Oh
… Y.Supple.69* (ex. Y.Sup.Web-DM)
… finalized in 2019
… Web-based data model for IoT and smart city systems and services
… metadata
… common descriptions of devices and data
… used for interoperability
… procedural metadata
… provide the common descriptions on composable procedures
… includes the information of common description
… and functions and flow
… example
… (diagrams on the left side and the right side)
… we can know what a thing can do
… how to manipulate things

Hyeontaek: contact the procedural metadata repository

<McCool> (note: currently 15m behind schedule... so no break, and we may go 5-10m over even if everyone stays on schedule from now on)

McCool: ok. thank you very much!

Eclipse Ditto

Slides

Thomas: opensource project
… released ver 1.0, 2.0
… about Digital Twins
… digital representation of real physical devices
… act as broker for communication with assets
… DT - our interpretation
… patern for working with things in IoT
… provide APIs - device a service
… in context
… (diagram)
… Ditto as Digital Twin "middleware"
… IoT solution, device twins, device connectivity, IoT devices
… device twins handled by ditto
… device connectivity handled by HONO and mosquitto
… additional API for event processing via HTTP
… also Kafka endpoint for Apache Kafka server
… turn device device data into APIs
… (example codes)
… JSON representation of a Thing on the left side
… REST API on the right side
… e.g., /api/2/things/io.foo:car1/attributes/manufacturer
… modeling thing capabilities
… attributes and properties are schemaless
… may be aware o several definition
… looking into WoT
… persistence of device state
… devices are not always connected to the Internet
… kind of cache there
… twin vs live access on the API level
… note the applications always need to be able to access the data
… authorization
… Ditto contains a built-in authorization mechanism
… using JWT
… search
… in addition to persistence
… static data vs runtime data
… resource query language like this
… filter=and(exists(attributes/manufacturer), gt(features/temperature/properties/value,23.0)
… get notified about changes
… notification via various channels
… Web Socket, SSE, MQTT, AMQP, Apache Kafka, HTTP hook
… server side filtering via RQL
… Ditto + WoT
… could benefit from each other
… bringing scalable cloud-ready digital twin framework
… but currently lacks the modeling for Things
… WoT's thing models could be a good fit
… wrap up
… tx

McCool: a few comments
… overlaps there
… e.g., proxy devices
… fuzzy boundary for things
… also we're working on discovery
… discovery of metadata (for devices/services) and data
… interesting to extend the scope for data
… there is a modeling of devices could be defined by TD

Kaz: we should collaboratively think about which vocabulary to be defined by which ontology or schema based on a concrete use case and scenario.

Sebastian: tx for presentation
… have been talking with Thomas before the presentation as well
… interesting discussion on TD repository
… interesting use case

<sebastian> https://github.com/w3c/wot-thing-description/issues/1177

Sebastian: how to define thing model
… very happy to continue further discussion
… would like to invite Thomas to the WoT discussion in the future

McCool: any other questions?

(none)

McCool: interesting discussion on digital twins
… Sebastian will follow up with Thomas?

Sebastian: yes

ISO TC184/SC4

Murayama-san's Slides

Sonoda-san's Slides

McCool: next ISO TC184/SC4 about IEC CDD

Murayama: Short introduction to the semantic project in ISO/TC 184/SC 4
… industrial data
… one of the WG convener
… JWG24
… SC4 structure
… secretariat: ANSI
… committee manager, chairperson, tech programme manager, etc.
… SC4 Formal scope
… standardization of the content, meaning, structure representation, etc.
… in a nutshell
… semantics related standard series in SC4
… common framework for ontologies
… ISO 13584 parts library, ISO 15926 oil&Gas standards, ISO 22745 open tech dictionary
… some others
… ISO 10303 standards for exchange of product data
… ISO 9002 exchange of characteristic data
… ISO 8000 data quality
… semantics related special activities
… PPC (AG1); policy&planning committee for coordination of all the activities within SC4
… AG3: core terminology for industrial data
… AhG3: ontology for shapes
… geometry and topology
… that is brief introduction on SC4's work
… should work with them

McCool: tx very much

Murayama: and some more from Mr. Sonoda

Sonoda: yes
… Report ISO/TC 184/SC 4
… brief talk about the activity
… some interesting topics related to IoT purposes
… WG 13: Industrial Data Quality
… dedicated to the standard
… (TC 184/SC 4/WG 13)
… ISO 8000 series
… 17 docs published
… 10 are ongoing
… ISO 8000 - 117 quality blockchains
… not published yet
… under way
… US community including ECMA
… 22749
… working for military stuff
… data set requirements
… referenced by the identifier shall be a quality data seta that conform to a published syntax
… generic blockchain
… block n, block n+1, block n+2 are chained
… the idea is
… blockchain technology would be useful to manage the data
… maybe some personal data or currency
… have to exchange huge size of data
… but not ideal to include all the huge data into a blockchain
… so going to think about two parts, on-chain part and off-chain part (immutable data set)
… combination of the data value can be referenced via the ID within the blockchain
… example encoding
… based on IEC 61360-4DB (IEC CDD)
… each identical class code can be used via the reference
… e.g., 0188-1#05-00845#1 as the value for "Reference"
… if we can have a standardized dictionary maybe including IoT devices, IoT devices could be also encoded like this
… after semantic encoded, people can use the semantics commonly

Kaz: would be useful for semantic interoperability
… so would like to see how this could be applied to WoT

McCool: 2 places for collaboration
… we should extend our scope for data management
… also useful for metadata interoperability

Sebastian: how to reflect the information to TD?

Kaz: probably they don't have the answer at the moment
… so we should collaboratively work on some concrete use case

McCool: right
… so how to proceed?

Sebastian: related to security management as well. right?

McCool: yeah
… e.g., based on blockchain
… do we schedule another joint call?
… would suggest we invite them to the use cases call

Kaz: +1

Sonoda: would like to work on some use case
… maybe one of the tables could be a schema definition for WoT TD
… and some high-level industry data to be mapped

McCool: ok
… let's have followup discussion by email
… thank you very much!
… any other business for today?

Murayama: would also agree we continue followup discussion by email

McCool: aob?

(none)

<McCool> https://github.com/w3c/wot/tree/main/PRESENTATIONS/2021-06-online-f2f

McCool: please send your slides to me, or directly upload to GitHub above, or let me know about the URL

[ Open Day adjourned ]

Day 5 - 29 June 2021

Opening

<kaz> Opening slides

McCool: shows today's agenda

Architecture

Lagally: shows the plan in this session such as new chapters like profile and discovery
… and updating chapters like TM and scripting
… we need also to talk about the implementation report
… something else?

Lagally: we have a stable specification
… some are outdated
… we have some PRs

PR 592

Lagally: as outcome of last profile discussion last week I have a PR

<kaz> wot-architecture PR 592 - WIP: Section on profiles

Lagally: we have TD and TM section

Maybe we can move the basic chapter from TD about TM to architecture

<kaz> 8.1 WoT Thing Description

<kaz> 8.2 Thing Model

Lagally: good idea, please be aware there are some other sections about TM in Arch

let's move the part in the TD section that is about discovery (A TD can created ... in case the Thing is updated.) to the discovery section

<mlagally> new issue for wot-architecture on the change

let's remove Thing Model section in System Component chapter

<kaz> 7.1.2 Thing Models (to be removed)

TM in the Building Block chapter would be enough

<kaz> 8.2 Thing Model (within the Building Block section)|

McCool: we can also keep the section and call it as "instance descriptions and class models"

Lagally: sounds good
… create an issue

<kaz> wot-architecture Issue 595 - Chapter 7.1.2 - rework "Thing Model" to new title/content "Instance descriptions and class models"

McCool: based on yesterday's open day we need to clarify the definition about digital twins, hub, shadows, etc.

Issue 581 - Consolidate usage of gateway, edge and hub

Lagally: we have some definitions in the specifiction document. There is also an issue about gateway, edge and hub

<Zakim> kaz, you wanted to ask OCF Staff to clarify their names

Lagally: who is OCF staff??

Koster: it's me, Michael Koster :-)

Lagally: coming back to my PR
… there is a new chapter about WoT Profile, it's about the generic concept of WoT Profile
… still to work on this
… suggest to merge and do cleanup afterwards

<kaz> +1 to once merge it

PR 593

Lagally: is it ok to merge the device class PR?

<kaz> PR 593 - Carry over of device categories from profiles

<kaz> (merged)

PR 592

<kaz> PR 592 - WIP: Section on profiles

any objection?

<kaz> (ML will resolve the conflicts to merge it)

Other updates

Lagally: are there some more updates?

McCool: discovery chapter is updated

McCool: I will review the discovery text in the TD section and cleanup if redundant

<kaz> 8.4 Discovery

Lagally: the binding template chapter have to be updated

<kaz> 7.7 Protocol Bindings

McCool: what is the status about the binding template?

Sebastian: we planning a prototype for the new structure based on Modbus
… cristiano is working on this

Implementation report

Lagally: missing a list of implementations which exists

Kaz: quickly reminds all that there are two points when we say "implementations of WoT", (1) W3C Process requires us for implementation experience for each REC Track doc, and (2) we should think about deployment of our WoT standards once they have reached the REC stage.

[ 5min break ]

Use Cases

Lagally: several UCs

wot-usecases PRs

Lagally: (goes through the UCs)
… digital twin, portable building apps, cultural spaces, ...

PR 136

PR 136 - Digital twin use case

Qing: Qing An from Alibaba
… there are existing use cases already
… highlighted one of them
… a group of physical devices are connected
… stakeholders include device owners and users
… motivation
… simply describing a single device capability would not be enough
… to accurate simulation, realtime status update is needed
… expected data
… device status, sensor data
… device relation
… Based on the virtual representation, further services can be provided, like real-time troubleshooting, simulation and prediction.
… gaps
… WoT does not define a way to describe the relationship and behavior of connected things to use for a simulation.

Lagally: would like to see the current UC document as well

3.3 Digital Twin

Lagally: there is some virtual representation there
… some realtime aspect too
… maybe we can combine your UC description with this

McCool: would suggest we update the current description based on Qing An's proposal
… rather than having two separate UCs
… simulation and prediction
… not currently mentioned by the Architecture doc
… and to be mentioned
… need to clarify the concept of digital twin, e.g., shadow, etc., as well
… the question here is do we need another use case for shadows?
… the current PR adds some clarifications to the current UC
… relationship with the physical device
… note that realtime implies some time restriction

Lagally: let's not interpret too much
… how to describe simulation and timing
… to be considered
… relation and rules among a collection of connected devices need be standardized

McCool: that part is new

Kaz: agree with McCool :)
… would be great to integrate this with Lagally's
… also we should be careful about the term of "realtime"

McCool: maybe time-sensitive?

Kaz: +1

Qing: ok

all: thanks!

<mjk> "Time Sensitive" is used by a specific network spec "Time Sensitive Networking" or TSN. We say or may not be using TSN

Lagally: are you already working on some implementations?

Qing: currently we're handling simulation of virtual devices on the cloud
… how to virtualize IoT systems is the key
… any possible extensions for TD?

Qing: describing a simulation model in the TD on how to virtualize devices would be helpful
… can join the discussion myself to help

Lagally: great; how about adding that point to the next charter?

<McCool> (re adding to next charter; agree, was on mute)

Sebastian: we already have a tool for the expression

Qing: would like to provide some actual example cases

Sebastian: cool
… if you have time, you can join the TD calls as well
… to see the detailed technical points

Lagally: first we should revise the UC description
… and then get detailed information on the actual data

McCool: look at use cases and see what to be done for the next Charter as well

Lagally: for the IG topics?

Kaz: given the timing for the WG Charter, we could think about WG topics as well

Koster: agree with the approach

Lagally: ok
… so we'll revisit this proposal during the next UC call

Qing: can ask some more questions?
… to be combined to the existing UC description?

Lagally: that's our suggestion but is that OK?

Qing: ok

Kaz: given we're getting more and more inputs form people for UCs
… maybe we should consider holding the UC calls weekly instead of biweekly

Sebastian: would agree
… at least tentatively for a while

Lagally: ok
… let's see

PR 132

PR 132 - Add portable building apps use case draft

Lagally: proposal from Gabe Fierro

Sebastian: related to the Building CG proposal?

McCool: need clarification on high-performance?

Lagally: (adds a comment)
… (goes through the proposal)

McCool: another question on ontologies

Lagally: (adds a question about if it's related to SSN and Geospatial work)

Koster: modeling for topology and composition?
… a lot to do for modularity
… could write up some requirements

Lagally: not entire HVAC but some of them based on the topology and geolocation?

Koster: yeah

Kaz: also possible feedback from the users by sensor data?

Koster: also weather condition, etc.

McCool: metadata is currently quite limited
… we should combine it with some other systems to make it more convenient

Lagally: we assume some strategy when we think about the topology and composition of the building
… that level of dynamism is to be considered

McCool: mobile geolocation

Lagally: (adds a question on if the topologies are dynamic
… e.g., elevator sensors changing their floors
… (goes through the "Description")

Kaz: btw, should we invite this person directly to the Use Cases call, shouldn't we?

McCool: make sense

Lagally: how to invite this person?

Koster: knows about this person :)

Lagally: could you ask him then?

Koster: ok

Lagally: please CC me

Koster: ok

Kaz: will we have the calls next week? or will we take rest as usual?

Lagally: thought Sebastian proposed we would work next week

Sebastian: let's have discussion tomorrow

Lagally: having a rest for one week right after the vF2F would be good as usual

McCool: need to decide
… also for summer vacation as well
… we'll discuss TD tomorrow

Kaz: what about the optional slot on Friday, July 2?

McCool: expectation is not having it but let's talk tomorrow

[ day 5 adjourned]

Day 6 - 30 June 2021

Agenda - Opening session

McCool: introducing agenda

<kaz> Opening slides

Thing Description

Sebastian: we have several parts to discuss
… roundtripping, TD 1.1, ThingModel,
… TM overwriting limitations
… TM composition
… TD Validation
… Sync vs async actions

TD RDF Roundtripping

Victor: Activity on GitHub ... e.g., issue 1168
… submitted PRs
… keeping security definitions in RDF
… another PR#1169 about indexing
… a easy fix was submitted

<victor> https://github.com/w3c/wot-thing-description/pull/1168 PR 1168 - fix: add wotsec context on securityDefinitions property

<victor> https://github.com/w3c/wot-thing-description/pull/1077 PR 1077 - Extend JSON-LD context to allow for round-tripping to/from N-Triples

Victor: thanks to those fixes I closed a number of issues
… the changes are only in JSON-LD context
… roundtripping should be possible now
… i will write test-cases in near future to check whether everything is covered

Sebastian: Great news
… I suggest we should go ahead merging

McCool: does it also solve rendering issues with security?

Victor: I think this is a different topic

McCool: Agree with merging
… move forward from here

McCool: PR#1168 has IPR issues

Kaz: is it just a bug fix?

Victor: Yes, would say so
… not sure if company logilab providing fix is W3C member?

McCool: It seems more than a typo fix
… does invited experts status help?

Victor: the change is very simple.. one line

Sebastian: one liner should not be an issue
… the rest is auto-generated .. so I don't see any issue

Kaz: Okay, makes sense
… marked the PR as non substantial
… PR can be merged now

<kaz> but again, please make sure non-participants should not create a PR other than editorial changes :)

Victor: Great, thanks --> PR 1168 has been merged
… merging PR#1077 also

Victor: Michael, can you point me to the issues that still need to be fixed

McCool: will check and let you know

Victor: Some minor JSON-LD issues are still open

McCool: Issue#915 solved also?

<kaz> Issue 915 - Vocabulary term "scheme" not defined when used inside securityDefinitions

Victor: Right, not sure if everything is fixed
… have to do a proper review

Sebastian: Great, thanks VC
… helps a lot

McCool: helps for discovery also ...
… e.g., relaxing requirements

Victor: Thanks goes to LogiLab

Whats new in TD 1.1

<victor> I'll have to leave now, sorry for not staying longer.

Sebastian: Please check FPWD 1.1. released in June
… some more aspects:
… TD Canonicalization
… work done by McCool
… we also have a first command line tool to do canonicalization

<kaz> latest WD of TD 1.1

<sebastian> https://github.com/fatadel/canon-td

Sebastian: some parts might still be missing

Kaz: w.r.t. to working draft.. it is June .. not March

Sebastian: other news
… links container has a new member "sizes"
… e.g., for icons

Sebastian: new also: ThingModel namespace
… at the moment still intermediary namespace
… tm:required is available in TD instances

McCool: TM context defined?

Sebastian: Yes, in in TD context

McCool: Not sure about the correctness of other namespaces .. like security
… misses prefixes?

Sebastian: Yes, MMC please check

Cristiano: What does it take to make these links referencable?
… real links are easier to handle

McCool: related issue for validation
… we should start doing this correctly

<McCool> mm: in particular, for validation, would use useful if ns URLs can be used to fetch ontology and also validation files (

McCool: can we direct them to actual servers?

<McCool> ... eg JSON Schema, SHACL

Sebastian: Questions goes to Kaz... I think
… could also use raw github link

McCool: TTL file could be default
… use content negotiation for others?

Sebastian: Simple forward could be done, right?

McCool: Yes
… but still handle different files.. e.g. for SHACL

Kaz: I mentioned in the past that we could add another redirection
… should be careful about the scheme

McCool: maybe use a convention
… also used for extensions

Cristiano: we could even use GitHub URIs

Sebastian: not sure about the benefits

Cristiano: shorter URL than raw github link

McCool: I have the concern about GitHub URIs...

Cristiano: +1 for creating issue to discuss further
… github pages is just a static webserver
… can also use W3C server.. both works fine for me

<McCool> Issue 1181 - Validation of extensions and fetching from context URLs

Sebastian: Those should be it for *new* features

Thing Models

Sebastian: should talk about overwriting existing definitions
… e.g., property dim typed as integer
… we can refer to this dim definition ... overriding integer type ..e.g. change maximum from 100 to 120
… i think this should not be allowed
… what about changing type integer to number
… also not Okay
… what about extending by limiting the integer range
… this is OKay
… we need to be clear in the specification what is allowed
… proof could be done by validation.. validating against both definitions
… I plan to work on this aspect

Lagally: Basic question: what are the boxes in the slides? UML inheritance ?

Sebastian: it is just an example how to use TMs
… by using ref
… examples are still TMs

Lagally: This leads to multiple inheritance, right?

Sebastian: We only allow one super-class
… ref can point to multiple other TMs

Lagally: What about naming conflicts?

Sebastian: does not happen
… we point to a dedicated url

Lagally: I see

Sebastian: tm:ref helps to reduce redundancy

McCool: Do we allow multiple references ?
… self-reference?
… open up problems and opportunities

Sebastian: We do not tackle this yet in the spec

McCool: Maybe we should currently limit it to full URL

Sebastian: Yes, should talk about it

Daniel: reminds me to the issue in TD... pointing to global definitions

Sebastian: Yes, we should think about the topics
… original question: shall we forbid the first 2 examples as sketched in the very beginning?
… SDF has the same restrictions
… I guess Vorto also

Lagally: I suggest we keep in mind versioning
… it could happen that the initial type/range is changed
… pointer to keep in mind

Sebastian: solved by the URL?
… updating content of *same* URL could cause this problem

McCool: informative note .. about changing base classes

Lagally: +1

McCool: Url should have version in it
… provide some best practices

Sebastian: Would like to move on to TM composition
… how to model things that consist of other things
… e.g., traffic light .. composed of 3 lights (red, yellow, green)
… see issue#1177

<kaz> Issue 1177 - Using composition in favor of inheritance in Thing Models?

Sebastian: proposal is to use links container
… using "rel" like "subthing"
… do you think relation type works?

McCool: semantically compatible with SDF?
… should make sure this is the case
… sdfObject
… transforming from SDF should be possible

Sebastian: Will study it
… alignment makes sense

Lagally: Suggestion by McCool with sub-components is useful
… terminology ... "subthing" seems not very useful
… what about "component"

Sebastian: This was just a proposal
… we should check IANA
… "collection" or "item" could be used

Lagally: Makes sense to align with IANA rel types

Cristiano: I like the link approach
… I am a bit puzzled about the expectations
… what are we looking at?

Sebastian: Had a similar question.. how would the TD look like
… I would expect a selfContained TD
… but this is the next step
… no answer yet

Cristiano: I see the same options
… everything or other smaller TDs

<sebastian> https://github.com/w3c/wot-thing-description/issues/1177

Sebastian: please also follow the issue

TD Validation

<McCool> https://github.com/w3c/wot-thing-description/issues/1181

<kaz> Issue 1181 - Validation of extensions and fetching from context URLs

McCool: created issue about validation extensions
… no formal way to validate extensions
… 2 approaches
… contentType
… using suffix following convention

McCool: should look at SHACL and how it is done there

Cristiano: Tried to use schema for binding ...schema including TD schema?
… in JSON schema this is not that easy

McCool: we could also have multiple extensions
… schemas for extensions should be simple
… we have to study this problem
… extension validation will be optional

WoT Action Model

McCool: where should it go?
… profile spec?

Lagally: First we need to discuss the need

McCool: Status of action
… cancelling action

Lagally: I would need some more time to discuss this... I have 10 slides

McCool: Okay... let's use the time now

Lagally: Action is similar to RPC
… input .. wait time ... response
… execution states of an action: received > dispatched > success/expired/failed/unknown

McCool: what about "blocked" ?

Lagally: could have that from received...

Lagally: Action status may contain these like "RECEIVED", "DISPATCHED", ...
… we know whether action is completed

Lagally: long running actions
… first confirms .. no result yet
… at some point in time there is a result
… how to cancel action
… RPC cannot be cancelled
… a generic cancel mechanism would introduce complex actions semantics
… on the other hand one can simply introduce cancel operation
… what about result
… polling?
… causes network traffic... processing overhead
… what about timeouts?
… motivates timeout parameter
… how to get result without polling
… SSE, LongPoll, WebHook, .. can we agree on a standard?
… question about actions queues:
… typically FIFO sequence
… what about emergency stop ...
… beyond scope of WoT?

McCool: I guess we need more time to discuss this topic
… Friday?

Lagally: immediate feedback would be very much welcome
… Ege is not available on Friday

McCool: Quick feedback is reasonable
… we extend actions to support status
… references
… status url

Lagally: defining status payload content?
… profile could use this work from TD

McCool: could be informative in TD
… could sort out details

Kaz: I agree with the direction
… clarify what is missing for TD and binding templates
… and also implementation guideline on how to use those spec for actual applications, e.g., HTTP binding, could be given in profile work

<Zakim> kaz, you wanted to ask about what "long" means here

Kaz: original question: what does "long" mean?
… should clarify criteria

Lagally: timeout parameter could be used

Sebastian: this is a big topic.. there is not *one* solution in the market yet
… should start but keep approach as simple as possible
… status mechanism makes sense to me
… avoid eventing mechanism
… advanced opportunities may come later
… T2T group could help in this area also

McCool: big topic, let's defer to next Arch call

<mlagally> Here's the github issue about action semantics: https://github.com/w3c/wot-profile/issues/81

<kaz> [ 5min break ]

Security

Improved localizers

McCool: uri and body. uri is when the security is in the uri. body is when you embedded the key in the payload and it is mixed up with other stuff.

mm goes through some examples of localizers

Canonicalization

McCool: Let's talk about Canonicalization. It is mostly about signing. We need to remove all the variants and reduce it one unique way in order to sign a document.

McCool: We also have some special cases. Default values etc. we decided to include them always. That makes it a bit verbose.

McCool: It is mostly an internal process, so it isn't critical to lose that space.

McCool: Prefix names must be retained. If you use a prefix, you have to use it.

McCool: There are also some weird things which timestamps.

McCool: I am not 100%, if I covered all corner cases. That is why we should test is in order to capture everything.

<Zakim> dape, you wanted to prefixes could be handled differently: Canonicalization could always remove any prefix and create ns1, ns2, ..by sorting namespaces

mm goes through some examples.

McCool: The example still includes security. That is wrong and gets removed.

Daniel: XML rewrites the prefix. Why don't we do that?

McCool: I did that originally. I need to look into my notes, why I didn't do it. Let's talk about it.

Daniel: If we make such decisions, we should note it down in the document.

Signing

McCool: The signature can verify, if the document is legit and signed by the correct key. We tried to use heavily already existing standards, even though we couldn't adopt a standard.

McCool: I looked at XML signatures, but since it is XML signatures, it doesn't work for JSON. But I used the structure of it.

mm shows some examples.

McCool: We currently have uris to refer to keys, but in the future we might use internal pointer to embedded keys.

Marketing

Animation video

Sebastian: We released our animation video and have a couple of translations available. Japanese, German, Italian, Chinese, French and Spanish.

Sebastian: Another news is our video is ranking very good within the W3C Youtube channel. We reached the top 20. Very successful video.

Visitor counts

Sebastian: Another topic is that we don't have a visitor count for our web pages.

Sebastian: I think that is very important, in order to recognize if we are good with our page. In order to identify broken links etc.

Sebastian: When we use Google Analytics, we also have to use Cookies. I am not a fan of this. We have to find a way to avoid this, but have some data.

Sebastian: If anyone has experience with it, it would be great, if you support us with it.

Dissemination

Sebastian: We should be involved more in the maker scene.

Sebastian: We currently don't have a good variation of articles, videos etc.

Sebastian: I am currently in exchange with Philipp Blum. I asked him to help me with that. I have a budget for this available, I would like to use for this.

Sebastian: This budget is only available until end of september. I cannot guarantee to get another budget for next year.

Sebastian: If anyone else is aware of channels, media, please contact us.

McCool: I think we should target the maker scene.

McCool: my point is that we should target professional developer, rather than hobbiests.

Sebastian: I am supporting this idea. If we want to have this kind of tutorials, we should invest more time in it.

McCool: I think we should think about the sequence of videos.

McCool: We also need to discuss orchestration.

Cristiano: I agree with this direction. I just want to say, that if we want to continue with that, we should improve our implementations first.

Cristiano: And then improve documentation.

McCool: We have node-wot. We also have the groud up C implementation.

Cristiano: I was thinking about the developer experience for node-wot.

McCool: I think there are two problems. Maturity. Another issue is that node-wot isn't deployable on small devices.

McCool: I think we should document it and make a list of tutorials we want to have.

Philipp: some confusion here. outreach by the end of september, and some longer-term work

Sebastian: right. on the other hand, let's think about our Twitter account

<cris> +1 we need people dedicated on dissemination

Sebastian: the question is there are too many things to do and who would work on marketing
... Siemens have some budget available now, so would think how we could use it

Philipp: I think we have two topics here. What Sebastian was mentioning is more short term until end of September. Having a sequence of videos is a good idea for our own Youtube channel. But we don't have the capacity for this.

Sebastian: Yes, I agree, we don't have the capacity for that. When we do this on our own. I don't think anyone has enough time to maintain that and participate in the standardization to that extend. I can support that until end of September, but we should think beyond that.

McCool: I think I can help with that.

Kaz: I think that is a good direction. On the other hand, I'd suggest we should think about a broader strategy of our work including all our Standardization, Implementations, Plugfest results etc. I am not objecting to that in general, though.

Daniel: I don't understand what direction we go. The tools we currently are not professional. But I think companies are going to start eventually their own implementation. I wonder, if we should start for a call for implementation again.

<McCool> followup - issues on wot-marketing, PRs here: https://github.com/w3c/wot-marketing/tree/main/tutorials

McCool: We ran out of time. I suggest we make PRs on the tutorial git.

Smart city workshop

Kaz: There was a smart city workshop. We discussed several topics, including use cases, standards and W3C possibilities. Several important topics.

Kaz: We are making dedicated groups for several topics.

McCool: Are you making changes to the charter in order to include that?

Kaz: We have to regenerate a report from the minutes. We need a dedicated chair for this.

Kaz: We can start then more detailed discussions in the IG.

Lagally: Will that also include specification work?

Kaz: Good question. No specification, only work on use case and requirements document, etc.

Administration

McCool: I just want to have a confirmation that we are not going to have a meeting on Friday on the 2 June.

Sebastian: I would suggest to have at least the main call for next week.

McCool: So then we cancel the other meetings, so that people have some free time.

McCool: Just let's assume for now that the meetings are canceled.

<McCool> https://github.com/w3c/wot/blob/main/charters/wg-ig-2021-proposed.html

McCool: We got a 6 month charter extention.

McCool: People should take a look on it and add topics, if they have any.

McCool: Let's discuss that in the next main call.

McCool: Let's get the IG done and then let's go to the WG.

<kaz> [ vF2F adjourned ]

Summary of resolutions

Day 1 - 21 June 2021

Agenda

Testing

PR 1176

Rechartering

IG Charter

WG Charter

Tomorrow

Day 2 - 22 June 2021

Agenda

Profiles

Actions

Protocol binding

Events

PRs

WoT vF2F in June - Day 323 June 2021

agenda

Profiles

PR 79

PR 70

PR 69

PR 57

PR 79

Discovery

Day 4 (Open Day) - 28 June 2021

opening

T2TRG/IETF

ECHONET

ITU-T SG 20

Eclipse Ditto

ISO TC184/SC4

Day 5 - 29 June 2021

Opening

Architecture

PR 592

PR 593

PR 592

Other updates

Implementation report

Use Cases

PR 136

PR 132

Day 6 - 30 June 2021

Agenda - Opening session

Thing Description

TD RDF Roundtripping

Whats new in TD 1.1

Thing Models

TD Validation

WoT Action Model

Security

Improved localizers

Canonicalization

Signing

Marketing

Animation video

Visitor counts

Dissemination

Smart city workshop

Administration

WoT vF2F in June - Day 3
23 June 2021