10:05:46 <RRSAgent> RRSAgent has joined #wot-arch
10:05:46 <RRSAgent> logging to https://www.w3.org/2021/12/02-wot-arch-irc
10:05:52 <kaz> meeting: WoT Architecture
10:05:59 <kaz> chair: Lagally
10:06:26 <kaz> present+ Kaz_Ashimura, Ben_Francis, Kunihiko_Toumura, Michael_Lagally, Michael_McCool
10:07:38 <kaz> Agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Dec_2nd.2C_2021
10:08:23 <ryuichi> ryuichi has joined #wot-arch
10:11:06 <kaz> present+ Ryuichi_Matsukura
10:13:11 <kaz> present+ Sebastian_Kaebisch
10:13:52 <kaz> scribenick: benfrancis
10:14:14 <kaz> topic: Minutes
10:14:20 <kaz> -> https://www.w3.org/2021/11/25-wot-arch-minutes.html Nov-25
10:14:24 <benfrancis> topic: Minutes from Last Meeting
10:15:12 <kaz> s/topic: Minutes//
10:15:19 <kaz> s|-> https://www.w3.org/2021/11/25-wot-arch-minutes.html Nov-25||
10:15:22 <kaz> -> https://www.w3.org/2021/11/25-wot-arch-minutes.html Nov-25
10:15:25 <Mizushima> Mizushima has joined #wot-arch
10:15:35 <kaz> present+ Tomoaki_Mizushima
10:20:08 <benfrancis> subtopic: Canonicalization
10:20:33 <benfrancis> Removed canonicalization from Thing Description, still needs removing from Architecture
10:21:13 <benfrancis> mlagally: Doesn't appear to be mentioned in Architecture
10:21:38 <benfrancis> Any objections?
10:21:42 <benfrancis> No, minutes approved.
10:22:01 <benfrancis> topic: New Time Slot
10:22:22 <kaz> -> https://doodle.com/poll/a6ibrh5cg6e9s2yx previous doodle poll
10:23:05 <benfrancis> mlagally: Everyone except Sebastian suggested new Doodle poll
10:23:17 <benfrancis> Many people also OK with the current slot
10:23:25 <benfrancis> But some unhappy
10:23:30 <benfrancis> McCool: Yes, unhappy
10:24:10 <benfrancis> q+
10:24:25 <benfrancis> There are no fully green columns on the original Doodle poll
10:25:26 <benfrancis> We need a two hour time slot
10:25:52 <benfrancis> One hour on different days perhaps?
10:28:47 <benfrancis> benfrancis: May be easier to find 1 hour time slots for architecture and profiles
10:29:13 <benfrancis> McCool: I suggest for next week we keep the current slot, then have a new Doodle poll for separate slots
10:29:43 <benfrancis> mlagally: I thought about that too, the only disadvantage is that we have to stick to the schedule
10:30:04 <benfrancis> mlagally: Let's do what McCool suggested. Stick to current time slot next week, then separate Doodle polls for after that
10:30:37 <benfrancis> McCool: Suggest adding links to the wiki
10:30:48 <benfrancis> mlagally: I suggest I create Doodle polls and kaz adds them to wiki
10:31:01 <kaz> ->https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#Under_Discussion main wiki's "Under Discussion" section
10:31:05 <benfrancis> topic: Architecture
10:31:33 <benfrancis> subtopic: PR 615 - Address Binding Templates related issues
10:31:46 <benfrancis> https://github.com/w3c/wot-architecture/pull/615
10:32:02 <benfrancis> mlagally: Does anyone suggest any changes?
10:33:08 <benfrancis> mlagally: Adds link to new W3C process document, any problems with that?
10:33:38 <benfrancis> McCool: The formal process is AC review, opportunity to complain
10:33:58 <kaz> q+
10:34:01 <benfrancis> mlagally: Seems sensible and well written
10:35:37 <benfrancis> benfrancis: Term "blueprint" may create some confusion regarding templates vs. profiles. I will file an issue.
10:35:44 <benfrancis> Happy to merge
10:36:53 <benfrancis> kaz: During this charter period we use the old patent policy. On the other hand the process document has been updated but referring to the process document is OK from a procedure viewpoint.
10:37:01 <benfrancis> mlagally: So you don't have concerns?
10:38:17 <benfrancis> Resolution: Merge.
10:38:34 <kaz> s/updated but/updated, so/
10:38:35 <benfrancis> subtopic: PR 644 Move common terms from Discovery to Architecture
10:38:52 <kaz> s/to the process document/to the latest process document/
10:39:29 <benfrancis> McCool: Some comments on the "discoverer" term, still under discussion
10:39:44 <benfrancis> I propose merging this and change later if needed
10:40:07 <benfrancis> s/McCool: Some comments on the "discoverer" term, still under discussion/mlagally: Some comments on the "discoverer" term, still under discussion
10:40:16 <benfrancis> Any concerns?
10:40:20 <kaz> i/Merge/kaz: right. the more important point here is we continue to refer to the 2017 Patent Policy for the current Charter period./
10:40:25 <benfrancis> Resolution: Merge
10:40:54 <kaz> i/the more/scribenick: kaz/
10:41:05 <kaz> i/Some comments/scribenick: benfrancis/
10:41:11 <kaz> rrsagent, make log public
10:41:15 <kaz> rrsagent, draft minutes
10:41:15 <RRSAgent> I have made the request to generate https://www.w3.org/2021/12/02-wot-arch-minutes.html kaz
10:41:19 <benfrancis> McCool: We moved terms over but had one term remaining. Still some discussion on Discoverer/Registerer but haven't reached a resolution, will do this at the same time.
10:41:47 <kaz> q?
10:41:53 <kaz> ack ben
10:41:54 <kaz> ack k
10:42:30 <benfrancis> McCool: Suggest merging. Generally suggest keeping all definitions in Architecture.
10:42:45 <benfrancis> Merged.
10:42:59 <kaz> i|Some comments on|https://github.com/w3c/wot-architecture/pull/644|
10:43:48 <benfrancis> subtopic: PR 645 - Improve description of device categories
10:43:52 <benfrancis> https://github.com/w3c/wot-architecture/pull/645
10:43:53 <kaz> https://github.com/w3c/wot-architecture/pull/645
10:44:45 <kaz> s|https://github.com/w3c/wot-architecture/pull/645||
10:44:52 <kaz> rrsagent, draft minutes
10:44:52 <RRSAgent> I have made the request to generate https://www.w3.org/2021/12/02-wot-arch-minutes.html kaz
10:45:48 <sebastian> q+
10:46:07 <kaz> q+
10:46:10 <benfrancis> McCool: I'm glad you did this. Suggest changing some sections as a follow-up as part of hub work. Fine with merging this, it is a step forward.
10:46:24 <benfrancis> sebastian: Is this your work or from IETF? It would be cool if this was aligned.
10:46:32 <benfrancis> mlagally: It is aligned.
10:46:42 <benfrancis> McCool: The lower ones are the same, we extrapolated from there.
10:47:03 <benfrancis> kaz: OK with content, but maybe the style for the table could be improved. E.g. background colour to identify the lines.
10:47:10 <kaz> ack k
10:47:13 <benfrancis> McCool: We did this for other tables, that could be cleanup, re-use CSS
10:47:34 <benfrancis> mlagally: Any volunteers?
10:47:51 <benfrancis> McCool: I think we can leave it until the end when we do bugfixes
10:48:03 <benfrancis> McCool: An issue for cleanup, with this as a checkbox.
10:49:13 <benfrancis> Resolution: Merge.
10:50:04 <benfrancis> subtopic: Issue 646 - Section structure, assertions, and issues
10:50:22 <benfrancis> ktoumura: A clarification about which sections are normative
10:50:37 <benfrancis> https://github.com/w3c/wot-architecture/issues/646
10:51:01 <benfrancis> mlagally: What do the question marks mean?
10:51:53 <benfrancis> ktoumura: Asks to clarify whether this section is normative or not
10:52:47 <benfrancis> McCool: Categories should be informative like terminology
10:53:07 <benfrancis> mlagally: I guess System Integration section should also be informative
10:53:51 <benfrancis> mlagally: A good example of the question of approval
10:54:09 <benfrancis> mlagally: Can we pre-approve that?
10:54:19 <kaz> q?
10:54:32 <benfrancis> sebastian: Yes, OK
10:54:36 <benfrancis> mlagally: Do we agree?
10:54:40 <benfrancis> (No objections)
10:55:17 <benfrancis> Filed issue https://github.com/w3c/wot-architecture/issues/647
10:55:51 <benfrancis> And https://github.com/w3c/wot-architecture/issues/648
10:57:05 <benfrancis> There are normative parts relating to Thing Description and Discovery
10:57:18 <benfrancis> Two main sections which are normative, section 8 and the conformance section
10:57:23 <benfrancis> And section 9
10:58:08 <benfrancis> mlagally: Do we have issues about the normative statements?
10:58:24 <benfrancis> McCool: I think the discovery assertions are appropriate since they are requirements.
10:58:40 <benfrancis> McCool: They're really requirements on other specifications.
10:58:41 <benfrancis> q+
10:59:10 <benfrancis> mlagally: It looks to me like they should be preserved
10:59:22 <benfrancis> McCool: Negative things are hard to test for, but more design questions
10:59:28 <benfrancis> Don't have to worry about having test cases for everything
10:59:50 <benfrancis> mlagally: Shouldn't go into details here, but this is a good summary
11:00:11 <benfrancis> McCool: Should decide what is an appropriate level of detail for WoT Architecture
11:00:30 <benfrancis> Not a problem if requirements aren't testable
11:00:54 <kaz> q+
11:01:24 <kaz> ack s
11:01:26 <kaz> ack b
11:01:49 <kaz> q++ ben
11:01:57 <kaz> q- ben
11:01:59 <kaz> q- +
11:02:21 <benfrancis> benfrancis: Should requirements not be in use cases and requirements document
11:02:45 <benfrancis> For the record I think all sections of WoT Architecture should be non-normative and normative assertions should be moved to other specifications
11:03:21 <benfrancis> mlagally: We should not take the word requirements to mean the same thing across all documents. Use Cases & Requirements is written by a different set of people.
11:03:54 <benfrancis> mlagally: Does that answer your question benfrancis?
11:04:11 <benfrancis> benfrancis: My point still remains, but I don't expect any action
11:04:42 <benfrancis> kaz: Thank you to ktoumura. This is exactly the kind of thing I have been asking editors to do, with this kind of structure.
11:05:19 <benfrancis> Regarding benfrancis' point, after some discussion we can define which assertions should be in the architecture document and tested for the architecture specification and which features should be defined and tested by the other specifications.
11:05:45 <benfrancis> There is the possibility that WoT Architecture should define abstract design and other specifications should define features
11:06:23 <kaz> q?
11:06:24 <kaz> ack k
11:07:55 <benfrancis> subtopic: Spec Alignment and Publication Blockers
11:07:59 <benfrancis> https://github.com/w3c/wot-architecture/issues?q=is%3Aissue+is%3Aopen+label%3A%22blocks+publication%22+no%3Aassignee
11:08:06 <benfrancis> sebastian: I can take all issues related to the Thing Description
11:10:08 <McCool> topic: common data model and constraints in profiles
11:10:22 <McCool> q+
11:10:37 <McCool> ml: put together a presentation to collect the discussion on this
11:11:20 <McCool> ... has been a lot of discussion around this
11:11:53 <McCool> ... original profile doc was a strawman, done over a couple of days two years ago
11:12:11 <McCool> ... we focused on considerations for small devices at first
11:12:41 <McCool> ... and wanted to help with adoption, and small devices had the most constraints
11:13:40 <McCool> ... generic consumer of a TD is not implementable; too open and extensible, TD permits too many things, too few guarantees
11:13:54 <McCool> ... even if we just limit ourselves to HTTP
11:14:53 <kaz> i/put together/@@@slides tbd/
11:15:03 <kaz> ack m
11:15:06 <McCool> ... includes an example consumer scenario for a weather station, also maps, predict weather conditions...
11:17:01 <McCool> mm: btw, I have a system that pretty much does everything listed, including a web api: the Tempest weather station
11:17:09 <McCool> ... from WeatherFlow
11:19:42 <sebastian> q+
11:20:25 <McCool> ml: sensor on maps also needed human readable names, etc.
11:20:42 <McCool> mm: to summarize, key interop issue here is data interpretation
11:21:06 <McCool> mm: in general, we want to focus on interop
11:21:45 <McCool> seb: the elements of human readability opens a large number of complex questions, eg. about internationalization, target audience, etc.
11:22:07 <McCool> ... also location is a very complex topic (indoor vs. outdoor locations)
11:22:12 <McCool> ack s
11:22:15 <McCool> q+
11:23:46 <kaz> q+
11:23:52 <kaz> ack m
11:24:08 <McCool> ack m
11:24:34 <McCool> mm: agree that geolocation is very complex and will probably have to be deferred
11:24:46 <McCool> ... but units are something we may be able to deal with
11:25:17 <McCool> ml: also want to address both sensors and gateways
11:26:11 <McCool> ... gateways may need to aggregate data (for example, computing averages, min/max, smoothing, extrapolation, etc)
11:26:52 <McCool> kaz: to clarify, this is for issue 125?  How many slides?  Should we wait for the last page...
11:26:54 <kaz> ack k
11:26:58 <McCool> ml: five more slides
11:27:13 <McCool> ... common data model and operation semantics are important
11:27:38 <McCool> ... common payload format, common data model and operation semantics
11:28:21 <McCool> ... for example, properties should be consistent, error formats should be consistent, etc.
11:28:56 <McCool> ... want event models to also have consistent behavior
11:28:58 <McCool> q+
11:29:43 <McCool> ml: also define a minimum sensor, which is actually a *client*, supporting only push events
11:30:22 <McCool> ml: home gateway would have more: a server, can read and write properties, and actions
11:30:39 <McCool> ... industrial gateway would in addition have a scalable event system
11:31:11 <McCool> ... needs a different event model, but still has common datamodels and operation semantics
11:31:37 <sebastian> q+
11:32:21 <McCool> ml: so today we are focused on one protocol and this narrow view may not get us to something that addresses these broader use cases
11:32:43 <McCool> ... in particular this is the motivation for including webhooks, etc.
11:32:44 <kaz> q+ to ask which part the Core Profile is within this diagram
11:33:25 <McCool> ml: in summary, I think the current profile does not address industrial use cases, so should not call it the "core" profile
11:33:51 <McCool> ... so we could define different profiles for each of these scenarios
11:34:31 <McCool> ... and then based on what each profile does we should pick an appropriate name
11:34:52 <kaz> q?
11:34:58 <kaz> ack m
11:35:29 <benfrancis> q+
11:40:58 <kaz> ack s
11:47:19 <kaz> ack k
11:47:19 <Zakim> kaz, you wanted to ask which part the Core Profile is within this diagram
11:47:32 <McCool> kaz: thanks for detailed description
11:47:52 <McCool> ... two points; where and which part should be described as a core profile
11:48:21 <McCool> ... (note that mm stopped taking notes, but ml was capturing some in the presentation...)
11:48:36 <McCool> kaz: what is the core profile?
11:48:46 <McCool> ml: this is the green parts in the diagrams
11:49:05 <McCool> kaz: tend to agree with concrete use cases and requirements and bottom-up approach
11:49:25 <McCool> ... but in that case looking at particular IoT standards such as OPC-UA and ECHONET
11:49:34 <McCool> ... these also have a set of basic data models, etc.
11:49:43 <McCool> ... and event handling mechanisms
11:50:02 <McCool> ... at some point we need to consider how to bind these, eg. for BIM systems
11:51:54 <kaz> q?
11:51:58 <kaz> ack b
11:52:02 <McCool> mm: however, the HTTP focus is still appropriate if what we are looking at the output of HTTP web proxies/APIs
11:52:24 <McCool> bf: want to agree with mm and seb about difficulty of defining constraints that apply to everything
11:52:42 <McCool> ... however, there are some constraints that would be useful, like units, but even that is hard
11:52:45 <kaz> i/thanks for/scribenick: McCool/
11:52:52 <McCool> ... agree with a bottom-up process
11:53:10 <McCool> ... disagree that the current profile is only good for home gateways
11:53:24 <McCool> ... but constrained devices may need another profile
11:53:41 <McCool> ... am a little concerned about not enabling inter-domain applications
11:54:11 <McCool> ... discussion of events perhaps misses the point, the issue is really TCP which is not efficient for this purpose
11:54:23 <McCool> ... and do we want interop within profiles or between profiles?
11:54:42 <McCool> ... regarding my PR that removes data model and moves things around
11:54:44 <kaz> i/you wanted to ask/@@@McCool's points and Sebastian's points recorded on Lagally's slides directly/
11:54:49 <McCool> ... would like to discuss scope, etc.
11:55:19 <McCool> ... we agreed a while back to focus only on interop, and remove others (human and constrained)
11:55:44 <McCool> ... also, there was a large amount of initial text that was never reviewed
11:56:04 <McCool> ... and we need to review each assertion and see if it supports the goals we have agreed to
11:56:06 <McCool> ml:
11:56:47 <McCool> ml: object that proposal has not been properly reviewed; did agree to start with strawmen; there were many opportunities for review
11:57:38 <McCool> ... regarding the two goals: small devices, no problem
11:57:49 <kaz> s/ml: object/Lagally: object/
11:57:53 <kaz> s/ml://
11:57:53 <McCool> ... but human readability not being a primary concern I have a problem with
11:58:14 <McCool> ... if TD does not allow you to build a UI, it is useless for many purposes
11:58:23 <McCool> ... only supports M2M use cases
11:58:26 <McCool> q+
11:58:56 <kaz> ack m
12:00:21 <sebastian> sorry, I need to go another meeting
12:00:37 <kaz> s/sorry, I need to go another meeting//
12:00:52 <kaz> q+
12:00:53 <McCool> mm: so what I'm hearing is that *some* human readability issues are interop issues, such as "interop with a dashboard".  But we need to clearly and narrowly define these
12:01:27 <McCool> ... in particular, making titles and descriptions mandatory may not be the right solution; semantic tagging might be better (since they can be mapped into local langauges more easily)
12:01:48 <McCool> q+
12:02:23 <McCool> ml: regarding PR 125, I feel it does too many things at once, so it is too hard to come to a conclusion
12:02:37 <McCool> kaz: we are overtime; but I felt the discussion was useful
12:03:04 <kaz> ack k
12:03:06 <kaz> ack m
12:03:39 <McCool> ... but I think we may need an even deeper restructuring
12:04:01 <McCool> mm: perhaps we archive the current doc and start again from an outline, bring things in?
12:04:13 <McCool> bf: we already did that, and this PR is part of that
12:05:24 <benfrancis> My proposed outline https://github.com/w3c/wot-profile/issues/73#issuecomment-804252286
12:06:05 <McCool> ... and why there are multiple changes in one PR is that removing things required changing references
12:07:30 <McCool> ml: like idea of starting from a fresh outline and pulling things in
12:08:09 <kaz> q?
12:08:16 <McCool> bf: good, ok with that
12:08:38 <kaz> s/... and/bf: and/
12:08:46 <kaz> rrsagent, draft minutes
12:08:46 <RRSAgent> I have made the request to generate https://www.w3.org/2021/12/02-wot-arch-minutes.html kaz
12:09:47 <McCool> mm: suggest creating an issue to create a new outline, and an MR to do the archival
12:10:08 <McCool> ml: let's start with the issue, can do the MR later
12:10:15 <McCool> ml: creates issue 152
12:11:35 <kaz> -> https://github.com/w3c/wot-profile/issues/152 Issue 152
12:11:38 <kaz> [adjourned]
12:11:43 <kaz> rrsagent, draft minutes
12:11:43 <RRSAgent> I have made the request to generate https://www.w3.org/2021/12/02-wot-arch-minutes.html kaz