W3C

– DRAFT –
WoT Architecture

02 February 2023

Attendees

Present
Ege_Korkan, Kaz_Ashimura, Kunihiko_Toumura, Michael_Lagally, Michael_McCool, Ryuichi_Matsukura, Tomoaki_Mizushima
Regrets
-
Chair
Lagally
Scribe
kaz, McCool

Meeting minutes

Minutes

<kaz> Jan-12

Lagally: review minutes from 12 Jan 2023

Lagally: look at issue for wiki cleanup #889; was done, closed

<kaz> Issue 889 - Cleanup Wiki pages

Lagally: then charter updates, testing and dedicated call with devs (EN + JP), at-risk assertions
… was an md for testing under arch

McCool: maybe can add link from minutes?

<mlagally> https://github.com/w3c/wot-architecture/blob/main/testing/At-Risk-Requirements.md

Lagally: pls add above link to minutes

Lagally: any objections to approving minutes?
… no objections, approved

Testing

<kaz> 2023.03.DevMtg

McCool: (describes the discussion during the Testing call on the Dev Meeting)
… help people understand the assertions
… very similar to what we've already done

Lagally: sounds good
… (creates a subdirectory for the Architecture spec)

Lagally: sounds good, will copy over content there, start modifying to meet the content

<kaz> https://github.com/w3c/wot-testing/blob/main/events/2023.03.DevMtg/Architecture/atrisk-explanations.md

McCool: suggest we make it a PR and mark it as draft for now while we sort out the content

Kaz: the description within Issue 888 is not 100% precise, and still need thorough review. So we should add "DRAFT" at the top if we want to copy the content to the MD file

Lagally: (add a sentence saying "DRAFT")

McCool: we have a month to work on this; note we will only have an hour and four deliverables, so will have to be efficient
… may have to prioritize, trim this down

Kaz: want to include IG/WG members, maybe will result in informative clarifications within the spec itself as well

Lagally: yes, feedback from members will help

McCool: agree, we can use feedback to improve the document

<mlagally> https://github.com/w3c/wot-testing/blob/main/events/2023.03.DevMtg/Architecture/DRAFT-atrisk-explanations.md

McCool: note will be a joint IG/CG call, organized by McCool/Ege/Kaz for EN, for JP will be Mizushima/Kaz

Next Charter Brainstorming

Lagally: let's have some open ideas and discussion

McCool: DTDL alignment

McCool: first, l like the DTDL approach of using a graph; can use links in TD to do something similar
… second, if we can link to existing standards, e.g. behavioral descriptions, that's even better

Kaz: are we talking about everything in WoT, or just digital twins?

Lagally: well, architecture, which covers all of WoT

Kaz: so, for example, time synchronization?

Lagally: time is interesting, we mostly consider static aspects

Lagally: but there are a lot of use cases where things are dynamic, in space and on the network
… this impacts geolocation, URLs, behavior, etc.

Lagally: and also migration of tasks between compute nodes

Kaz: maybe we want to capture some keywords for topics people are interested in?
… and we already did a bit of that in use cases and requirements

Lagally: if we go an look at use cases, we will only see things we have already looked at

Kaz: thought you had an MD file mapping use cases to topics?

McCool: get back to the issues list
… multi-access, etc.
… also wanted to say geolocation
… have proposal to handle dynamic information
… WG deliverables to be put into the WG Charter
… or investigation by IG

Mizushima: we should clarify diff between arch and profile

Lagally: we do have an issue about that in profile repo
… arch is not easy to change at this point, but we can work on profile

Mizushima: arch doc is general wot technology, profile is for each service
… this discussion is on features
… arch and profiles need to be separated

Lagally: agree, and that is what we plan to do
… do you think we should that sooner rather than later?

Mizushima: no strong opinion either way

Kaz: at least in new WG charter we should clarify relationships between arch and profile

McCool: from my viewpoint, Architecture and Profile are complete different specs
… so we should add clarifications to the TF work as well
… e.g., separate TF wiki pages

Lagally: agree

McCool: doing it right now might set us up better for next charter

McCool: we already have two separate GitHub repos, so should start with wiki pages

Lagally: when to do that?

McCool: creating a wiki page is not difficult

<mlagally> proposal: create a new Profile Wiki page and start using it next week

Kaz: note that we don't need to copy over all the content, but just create a new Profile wiki and start to use it from next week for the Profile TF.

RESOLUTION: create a new Profile Wiki page and start using it next week

Lagally: what about the WoT Marketing page?

McCool: let's do that incrementally

Kaz: on brainstorming, would like to also propose some kind of consumer description

Kaz: for example, Audi, etc. have various services for time synchronization; we want to align with industrial approaches
… microservices and state-model-based controller

McCool: personally would not like to chase all the possible consumer descriptions, but would concentrate one specific description

Lagally: what would be the changes for Architecture?

<Ege> +1 to mm, "stuff" like google firestore also uses a broker like approach and WoT still works there very well

McCool: describing Things may consumed by Consumers
… including what callbacks would look like

McCool: so idea is to expand definition of TD to include contract between Things and Consumers; that makes it clear that things like callback APIs should go into the TD

Lagally: let's also take a look at the current architecture diagram
… see in particular the "Abstract Architecture", Figure 19

Ege: don't think we are lacking something on this figure, but back to wiki list, would add error description and state management

Kaz: mentioned state model based controller

Ege: something we are working on at Siemens, would be happy to contribute
… we are brainstorming for arch, but this ends up being everything

McCool: on point, be careful about "state", can mean multiple things (state machines, historical data, shadowing, etc)
… second, since this involves all of this, we should continue this in main call or charter call

Ege: had some overall ideas that I'd like to have time for

McCool: suggest we create PRs or issues, in the wot repo, and label as charter discussion topics, then we can schedule them

Lagally: ok, created issue: #1069 in wot repo

Kaz: as already mentioned, having this kind of brainstorming about WoT in general is good. However, it should be done not only for the WoT Architecture. So having further discussion during the Charter meeting would make sense. Also please put the results from today's discussion somewhere so that we won't lose them :)

[adjourned]

Summary of resolutions

  1. create a new Profile Wiki page and start using it next week
Minutes manually created (not a transcript), formatted by scribe.perl version 196 (Thu Oct 27 17:06:44 2022 UTC).