13:59:46 <RRSAgent> RRSAgent has joined #wot-arch
13:59:46 <RRSAgent> logging to https://www.w3.org/2021/09/23-wot-arch-irc
14:04:45 <kaz> kaz has joined #wot-arch
14:05:11 <kaz> meeting: WoT Architecture
14:05:50 <McCool> McCool has joined #wot-arch
14:06:47 <kaz> present+ Kaz_Ashimura, Ben_Francis, Michael_Lagally, Michael_McCool, Michael_Koster, Tomoaki_Mizushima
14:06:49 <kaz> chair: Lagally
14:07:52 <Mizushima> Mizushima has joined #wot-arch
14:10:14 <kaz> Agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Sept_23rd.2C_2021
14:12:27 <mlagally> mlagally has joined #wot-arch
14:13:08 <mjk> mjk has joined #wot-arch
14:14:04 <kaz> topic: Minutes
14:14:13 <kaz> -> https://www.w3.org/2021/09/16-wot-arch-minutes.html Sep-16
14:15:36 <McCool> note: it looks like multiple people were editing the building blocks section, we will have to resolve
14:15:48 <McCool> ... and yes, I think discovery should be considered a building block
14:18:25 <kaz> mm: wondering about Ben's participation in the upcoming Plugfest next week
14:18:40 <kaz> bf: kind of difficult due to other assignment
14:18:54 <kaz> ... but would like to work on implementation for WebThings
14:19:08 <kaz> ml: minutes approved
14:19:30 <kaz> scribenick: benfrancis
14:19:47 <kaz> i/note:/scribenick: McCool/
14:19:55 <kaz> i/wondering/scribenick: kaz/
14:19:55 <benfrancis> topic: PR #600
14:20:23 <benfrancis> "Add Description and Model Section"
14:21:30 <benfrancis> Re-wrote section 8 to be about abstractions. Focused on Things and Consumers. Short section on metadata, but moved to another section. Added into to Thing Model as classes.
14:22:19 <benfrancis> McCool: Sebastian's text had two descriptions of Thing Models. I decided to re-focus introduction about Thing Models to not describe them as incomplete TDs:
14:22:46 <benfrancis> I think a Thing can also be a virtual entity like a service, not just a physical device.
14:22:57 <benfrancis> Introduce metadata. Thing Descriptions and Thing Models.
14:23:57 <benfrancis> Detailed description of Thing Descriptions.
14:24:33 <benfrancis> Thing Models re-written to be primarily about classes. Introduce the idea of using it as incomplete information for an instance. I have some concerns about this, perhaps we need a separate thing called an incomplete TD.
14:25:28 <benfrancis> Would like feedback.
14:25:29 <benfrancis> q+
14:26:07 <benfrancis> Have some concerns about building blocks.
14:27:07 <kaz> i|Add Description|-> https://github.com/w3c/wot-architecture/pull/600 PR 600|
14:28:18 <kaz> s/topic: PR #600/subtopic: PR #600/
14:28:35 <kaz> i|PR #600|topic: Architecture|
14:28:41 <kaz> rrsagent, make log public
14:28:45 <kaz> rrsagent, draft minutes
14:28:45 <RRSAgent> I have made the request to generate https://www.w3.org/2021/09/23-wot-arch-minutes.html kaz
14:29:02 <benfrancis> mlagally: I don't expect the diff is very helpful since it's such a big change.
14:29:12 <benfrancis> McCool: It is quite complicated
14:29:24 <benfrancis> mlagally: Let's merge it as a basis
14:29:34 <benfrancis> McCool: Agree, I would prefer to do that
14:29:35 <kaz> q?
14:31:51 <benfrancis> mlagally: Some issues with HTML stricture. Let's take that offline.
14:33:01 <benfrancis> mlagally: A Thing Model has a specific purpose. It can be a partial TD, also used for composing models.
14:33:26 <benfrancis> McCool: Can create constructs, reference other TDs. A TM is not just an incomplete TD. Can be used to generate TDs.
14:33:58 <benfrancis> mlagally: A Thing Model has a specific purpose, the term should not be abused to describe something which looks like a Thing Model but is something else. If we need something else we should create it.
14:34:06 <benfrancis> McCool: I agree
14:36:07 <benfrancis> benfrancis: Some concerns about advocating using Thing Descriptions to describe generic web services. Virtual devices yes, but not any web service.
14:36:51 <mjk> q?
14:37:19 <kaz> ack b
14:37:31 <benfrancis> McCool: I don't think the current text does that, but would be good to clarify this. Have seen people using it to describe AI services. Benefit of using WoT for that is it's easier for everything to use TDs. No reason a service couldn't have both an OpenAPI description and a Thing Description.
14:38:20 <kaz> q+
14:39:03 <benfrancis> mkoster: Thing Description is a good way of describing the smart object pattern in general, beyond IoT. We don't have a way to restrict how people use it, don't have to accommodate changes to broaden use cases beyond IoT.
14:39:21 <benfrancis> At the same time TD kind of does everything Swagger does and has the same semantic affordances.
14:40:53 <benfrancis> McCool: Should we include edge computing? Is a time-series database a Thing?
14:41:04 <benfrancis> mlagally: Would encourage supporting hubs and gateways.
14:41:18 <kaz> s/At the same/... At the same/
14:41:24 <benfrancis> What's the difference between edge and cloud devices...?
14:41:50 <benfrancis> McCool: I have not added wording about this to the current text, needs discussing at some point. This PR doesn't include that change.
14:42:03 <benfrancis> mlagally: Let's not over engineer this current PR.
14:42:52 <mjk> q?
14:43:39 <kaz> ack k
14:43:48 <benfrancis> kaz: Building management as a starting point. Think about how to model virtual devices and digital twins. Takenaka architecture has two systems, UI and batch. Separate systems. If they can join the open day meeting next month they can contribute.
14:43:59 <benfrancis> McCool: virtual device != service
14:44:15 <benfrancis> Services are a third category
14:44:51 <kaz> s/Services/... Services/
14:44:56 <kaz> q?
14:45:23 <benfrancis> mkoster: Need to update digital twin use case. The obvious thing is to use WoT to adapt data and protocols to a digital twin. One way to talk about all devices, adapting. Then there's services (like Swagger). Refining the digital twin use case could be helpful.
14:46:02 <benfrancis> McCool: I think a digital twin is a service. If it's a virtual model of a pump that's a virtual device. Current text is vague, could be interpreted as a service.
14:46:10 <benfrancis> I think digital twins are a reasonable use case.
14:46:22 <benfrancis> mlagally: Digital twin is one kind of virtual device.
14:46:43 <benfrancis> If we think about what we can do with TD & TM, can define an interface/metadata but can not describe behaviour.
14:46:55 <benfrancis> E.g. A simulation model.
14:47:20 <benfrancis> Have API description and scripting API.
14:47:29 <benfrancis> Could be an interesting topic for upcoming IG/WG charter.
14:47:40 <benfrancis> McCool: Already have edge computing listed in charter.
14:47:51 <benfrancis> Can merge this as a starting point.
14:48:10 <benfrancis> mlagally: I didn't mean edge computing, meant describing behaviour of a device. Let's go ahead and merge.
14:49:00 <benfrancis> mkoster: There is some work being done on that. Control Description Language. Started as actions, turned into description language. A parallel spec to describe that. Should be aware of that as a use case. If not part of TD, can we link to/integrate with it. I hear this a lot so good to capture as a use case.
14:49:15 <benfrancis> mlagally: Consider this for the next charter, discuss in use cases call.
14:49:39 <benfrancis> Resolution: PR merged.
14:50:03 <McCool> topic: define and discuss hubs
14:50:56 <benfrancis> McCool: What we need here is a section. Talk about P2P (graph) vs. hub (star) topology.
14:51:09 <benfrancis> Discuss whether both are supported by our architecture.
14:51:15 <kaz> s/topic:/subtopic:/
14:51:24 <benfrancis> Not done yet, not ready to merge. Need to rebase and re-organise.
14:52:05 <benfrancis> s/subtopic:/topic: PR 603
14:52:55 <mjk> Reference to ASHRAE CDL https://www.sciencedirect.com/science/article/pii/S0360544221017497
14:53:30 <benfrancis> Difference between gateway and hubs. Whether it provides a service, proxy etc. An edge device is a category of all possible edge computer usages. Do we include all kinds of edge computing? Just hubs/gateways/network boxes?
14:53:54 <benfrancis> mlagally: "Edge" is just about where a device is.
14:54:57 <benfrancis> McCool: Suppose I have a smart camera doing computation. Still doing computation, is it an edge device? What if it provides a service? Is that an edge computer?
14:55:15 <benfrancis> Acting as intermediary. Single device can be both.
14:55:35 <mjk> Conceptual framework for control description language: https://www.researchgate.net/figure/Class-diagram-in-UML-describing-the-modelling-principle-of-encapsulating-functionality_fig2_317063872
14:56:12 <benfrancis> benfrancis: The cloud is someone else's computer, off-premises in a data center. Edge is own computer on own premises.
14:56:26 <benfrancis> McCool: Location and owership. Technology might be the same.
14:56:57 <benfrancis> The definition of cloud might be reasonable. Edge as part of the cloud, the boundary of the cloud, as opposed to boundary of consumer area. Edge devices might a fuzzy middle ground.
14:57:14 <benfrancis> mlagally: Any difference in a Thing Description depending on where it is retrieved from? Any conceptual difference?
14:57:28 <benfrancis> McCool: Gateway is confusing because it sounds  more restrictive.
14:58:12 <benfrancis> benfrancis: A gateway bridges one network to another.
14:58:20 <kaz> i|What we need|-> https://github.com/w3c/wot-architecture/pull/603 PR 603 - WIP: Define and Discuss "Hubs"|
14:58:27 <benfrancis> McCool: SmartThings hub also has orchestration capabilities. More than just bridging networks.
14:58:27 <kaz> rrsagent, make log public
14:58:34 <kaz> rrsagent, draft minutes
14:58:34 <RRSAgent> I have made the request to generate https://www.w3.org/2021/09/23-wot-arch-minutes.html kaz
14:59:13 <benfrancis> benfrancis: An ethernet hub is simpler than a home gateway. A smart home hub is different
14:59:47 <benfrancis> McCool: ethernet hub is different. Maybe there's a better term.
15:00:25 <benfrancis> McCool: One sticking point is the smart home gateway section may need to be renamed to smart home hub to be consistent.
15:00:52 <benfrancis> mlagally: I think orchestration may be something which differentiates a hub from a gateway, but also true for an edge device. Want to pick a common sense term.
15:01:11 <benfrancis> McCool: My current problem with the text is that the same terms are used in different ways.
15:01:49 <benfrancis> Edge devices sometimes used to mean a service like an AI service. A hub could provide an AI service.
15:01:56 <kaz> q+
15:02:04 <benfrancis> mlagally: Should we be talking about services and service platforms, or stick to hardware.
15:02:12 <benfrancis> McCool: Not a big deal if we don't talk about services.
15:02:12 <kaz> s/Edge/... Edge/
15:03:03 <benfrancis> mkoster: Is there a way we can avoid categorising things we don't need to.
15:03:10 <benfrancis> ?
15:03:43 <benfrancis> Maybe we can have the discussion without naming it. Can give examples to expose that there isn't a consistent term?
15:03:57 <kaz> s/need to./need to?/
15:04:03 <kaz> s/?//
15:04:09 <kaz> s/Maybe/... Maybe/
15:04:13 <kaz> rrsagent, draft minutes
15:04:13 <RRSAgent> I have made the request to generate https://www.w3.org/2021/09/23-wot-arch-minutes.html kaz
15:04:27 <benfrancis> mlagally: We could use edge device in the next iteration
15:05:19 <benfrancis> McCool: Could not use the term hub and say that gateways can do other things like orchestration. Could mention that some use the term hub.
15:05:23 <kaz> q?
15:07:27 <benfrancis> kaz: Agree with mkoster's position. We already have a name "intermediary" in addition to consumer and device. Ideally we should use those three components. If we really need to identify devices named hubs and gateways we need to define them. Do we want to expand the terms to include other hardware configurations? If yes then we need to re-define
15:07:28 <benfrancis> these words.
15:07:35 <kaz> ack k
15:07:46 <benfrancis> McCool: Difference between gateway and intermediary is like the difference between device and thing.
15:07:53 <kaz> s/these words.//
15:08:00 <benfrancis> McCool: This is talking about a physical box.
15:08:02 <kaz> s/re-define/redefine these words./
15:08:31 <benfrancis> McCool: More of a physical category, intermediary is an abstraction of a service.
15:08:57 <benfrancis> McCool: I think I have a plan of action to remove hub and use gateway.
15:09:32 <McCool> topic: profiles
15:09:50 <benfrancis> scribenick: McCool
15:10:04 <McCool> ml: several prs to look at: 103, 87, 85, 93, 78
15:10:19 <kaz> s/topic: PR 603/subtopic: PR 603/
15:10:19 <McCool> topic: pr 103, queryallactions
15:10:32 <kaz> s/topic:/subtopic:/
15:10:37 <kaz> rrsagent, draft minutes
15:10:37 <RRSAgent> I have made the request to generate https://www.w3.org/2021/09/23-wot-arch-minutes.html kaz
15:10:50 <McCool> ml: main issues is if a consumer crashes, can recover, or to let another device to look at what a thing is doing
15:11:09 <McCool> bf: let me share my screen and walk through it
15:11:27 <benfrancis> https://github.com/w3c/wot-profile/pull/103
15:12:09 <McCool> bf: we have existing action ops, and we just added queryallactions in TD spec
15:12:33 <McCool> ... main use case if one consumer invokes an action, and another needs to know about it
15:12:39 <McCool> ... or if consumer crashes
15:12:51 <kaz> s/main issues is/main issue is/
15:12:51 <McCool> ... in both cases, URL of action resource needs to be recovered
15:13:16 <McCool> ... change to spec introduced top-level form for actions
15:13:30 <McCool> ... add queryallactions as op to that, use a GET
15:14:06 <McCool> ... 200 status code, body is an object keyed by action name, then each is an array of actions
15:14:19 <McCool> ml: what does the sequence tell us?  does it have semantics?
15:15:21 <McCool> bf: not really
15:15:32 <McCool> mm: retention of action objects once completed?
15:15:49 <kaz> -> https://pr-preview.s3.amazonaws.com/benfrancis/wot-profile/pull/103.html#queryallactions 5.2.2.4 queryallactions
15:15:52 <McCool> bf: not a real good answer here; cancelled actions are deleted
15:16:10 <McCool> ... but if completed or failed, kept around for an implementation-specific length of time
15:16:33 <McCool> ... needs to stick around as long as a consumer might need to check status
15:16:44 <McCool> ... no rule, it depends
15:17:13 <McCool> ml: such things cause corner cases; 0 retention time vs. infinity
15:17:35 <McCool> bf: retension time of 0 or infinity both will not work
15:17:48 <McCool> ... but intermediate value if not clear
15:17:59 <McCool> s/if/is/
15:18:26 <McCool> bf: but once it goes away, consumer can not longer find out about past actions
15:18:37 <McCool> ... agree ambiguity is not great
15:18:47 <McCool> ... if it gets a 404, knows it cannot get a status
15:19:10 <McCool> ml: I wonder what we can do as a generic consumer
15:19:43 <McCool> ... suppose you initiate an action, crash, then try to find out actions you created
15:19:57 <McCool> ... which raises another question, is there a filter?
15:20:10 <McCool> bf: authorization is orthogonal to API design
15:20:24 <McCool> ... but restriction to owners would be one way to do this
15:20:45 <McCool> ml: question was not about authorization, but identification
15:21:23 <McCool> bf: if system is designed that all actions are visible to all
15:21:32 <McCool> ml: not sure this is a problem
15:21:33 <kaz> q+
15:21:34 <McCool> q+
15:22:05 <McCool> ml: after crash, a device does not now if it should restart an action that it needed to do
15:22:26 <McCool> kaz: was also wondering about this point as well
15:22:42 <McCool> ... in theory an intermediary can remember the various devices
15:23:46 <kaz> ack k
15:23:48 <kaz> ack m
15:24:23 <kaz> s/devices/devices, and let the consumer know about the information based the request from the consumer./
15:24:55 <kaz> q+
15:25:44 <McCool> mm: problem is we have to have some way to identify consumers, which is tricky
15:26:15 <McCool> ... if it's user-generated, then that has various problems (duplicates, etc)
15:26:29 <McCool> ... if server-generated, same problem as URLs getting lost in a crash
15:26:33 <kaz> ack k
15:27:05 <kaz> kaz: this point is one the reasons why I want to invite the Takenaka guy to our OpenDay
15:27:14 <McCool> ml: in summary, retention time and consumer identity
15:27:23 <McCool> ... don't have timestamps
15:27:53 <McCool> mm: timestamps raise issues of clock sync...
15:27:55 <kaz> s/OpenDay/OpenDay. They use WoT to manage multiple buildings with various devices, so should have some mechanism already to handle this issue./
15:28:06 <McCool> ml: could use sequence number instead
15:28:23 <kaz> i/this point/scribenick: kaz/
15:28:34 <kaz> i/in summary/scribenick: McCool/
15:28:48 <kaz> rrsagent, draft minutes
15:28:48 <RRSAgent> I have made the request to generate https://www.w3.org/2021/09/23-wot-arch-minutes.html kaz
15:29:32 <McCool> mm: this is better than nothing, though, and certs (authorization) is not a terrible way to handle identity
15:29:51 <McCool> ml: there is also the issue of idempotent actions, etc.
15:30:10 <McCool> ... in this case "syncing up" is easier
15:30:23 <McCool> ... for example, checking if a motor is running
15:30:47 <kaz> q?
15:31:05 <kaz> q+
15:32:25 <McCool> mm: I think if it CAN be handled by a property, it should be
15:32:40 <McCool> ... we probably want to think about use cases where properties are not suitable
15:33:46 <McCool> ... for example, a print queue
15:34:20 <McCool> bf: note that resources will exist whether or not you query them
15:34:32 <McCool> ... and can still check status individually
15:34:48 <McCool> ... so this just adding a group operation
15:36:05 <McCool> ml: I think the order should be the order in which the actions were invoked
15:36:15 <kaz> q?
15:36:16 <McCool> mm: or at least the order in which the server dealt with them
15:37:13 <McCool> bf: note that actions might take place in parallel... how do you order, start or end time?
15:37:27 <McCool> ... in web things also have start and end time, and timestamps
15:38:14 <McCool> ... is a separate issue for timestampes
15:38:24 <McCool> mm: so let's worry about timestamps and ordering separately
15:38:38 <McCool> kaz: have brought up problem of sequences many times
15:39:03 <McCool> ... there have been specs for this SMIL, MMI, and cars have some specs for this
15:39:19 <McCool> ... but that kind of detail is out of scope for WoT
15:39:41 <McCool> ... so we can create a dedicated issue for that, but details might have to be in separate charter
15:39:55 <McCool> ... it's complicated, so maybe we should defer it
15:40:29 <kaz> ack k
15:40:50 <McCool> q+
15:41:31 <benfrancis> "Actions need a way to express time stamps" https://github.com/w3c/wot-profile/issues/101
15:41:43 <McCool> mm: I am ok with sets semantically, just a little worries about things like signing
15:41:56 <McCool> ... want a canonical order (but it does not have to have "meaning")
15:42:53 <McCool> bf: or can sort by timestamps
15:43:08 <McCool> mm: but I think all we want at this point is a stable order
15:43:35 <McCool> ml: assume I want to model just the three things in draft...
15:43:54 <McCool> bf: queryallactions is currently the only top-level form action allowed
15:44:09 <McCool> ... but what IS missing is whether this is optional or mandatory
15:44:21 <McCool> ml: so, what do we do
15:44:43 <McCool> ml: could merge as it is, add owners, etc.
15:45:48 <McCool> mm: I personally think we should merge and make issues for the various points raised
15:45:57 <McCool> ... identity, for instance, is complicated
15:46:11 <McCool> bf: identity is a big issue
15:47:11 <McCool> bf: happy to deal with consistent order, identity, and timestamps as followup activities
15:47:38 <McCool> ml: also retention time
15:48:16 <McCool> ... how do we deal with that?
15:48:31 <McCool> bf: first op that we have that deals with historical data
15:48:41 <McCool> ... everything else is about current state
15:49:02 <McCool> ... but this creates dynamic resources with independent lifetimes
15:50:17 <McCool> mm: is this any worse than other restful apis?  we should do some research to see if there is a better solution out there
15:50:27 <McCool> bf: let's also have that as a followup issue
15:50:50 <McCool> ... if this was a push api, would push the status and then not worry about retention
15:51:33 <McCool> ml: will create some issues...
15:52:28 <McCool> ... start with "action improvements"
15:53:23 <McCool> ... order of return, identity/owner of action invocation, retention time; already have timestamps
15:54:24 <kaz> -> https://github.com/w3c/wot-profile/issues/104 Issue 104 - Actions Improvements: order of return values
15:54:41 <kaz> -> https://github.com/w3c/wot-profile/issues/105 Issue 105 - Action Improvements: identity /owner of an action invocation
15:55:26 <McCool> mm: one thought about the identity issue is to add an op for "queryallmyactions" that would use aspect of protocol, i.e. TLS certs, to determine identity
15:55:29 <kaz> -> https://github.com/w3c/wot-profile/issues/106 Issue 106 - Action Improvements: retention time of action status
15:55:34 <McCool> ml: then that would not work for nosec
15:55:41 <McCool> mm: right; too bad
16:00:34 <McCool> mm: for retention time, I will look into best practices for apis; but we could also just pick an arbitrary minimum retention time
16:00:44 <McCool> ml: ok, merging pr
16:01:19 <kaz> -> https://github.com/w3c/wot-profile/pull/103 PR 103 merged
16:01:36 <kaz> topic: AOB?
16:01:36 <McCool> bf: call next week, 1h, discuss TPAC
16:01:55 <kaz> s/bf:/ml:/
16:02:04 <kaz> [adjourned]
16:02:09 <kaz> rrsagent, draft minutes
16:02:09 <RRSAgent> I have made the request to generate https://www.w3.org/2021/09/23-wot-arch-minutes.html kaz
17:58:52 <Zakim> Zakim has left #wot-arch