Meeting minutes
Minutes
<kaz> Sep-16
note: it looks like multiple people were editing the building blocks section, we will have to resolve
… and yes, I think discovery should be considered a building block
mm: wondering about Ben's participation in the upcoming Plugfest next week
bf: kind of difficult due to other assignment
… but would like to work on implementation for WebThings
ml: minutes approved
Architecture
PR #600
<kaz> PR 600
"Add Description and Model Section"
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.
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:
I think a Thing can also be a virtual entity like a service, not just a physical device.
Introduce metadata. Thing Descriptions and Thing Models.
Detailed description of Thing Descriptions.
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.
Would like feedback.
Have some concerns about building blocks.
mlagally: I don't expect the diff is very helpful since it's such a big change.
McCool: It is quite complicated
mlagally: Let's merge it as a basis
McCool: Agree, I would prefer to do that
mlagally: Some issues with HTML stricture. Let's take that offline.
mlagally: A Thing Model has a specific purpose. It can be a partial TD, also used for composing models.
McCool: Can create constructs, reference other TDs. A TM is not just an incomplete TD. Can be used to generate TDs.
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.
McCool: I agree
benfrancis: Some concerns about advocating using Thing Descriptions to describe generic web services. Virtual devices yes, but not any web service.
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.
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.
… At the same time TD kind of does everything Swagger does and has the same semantic affordances.
McCool: Should we include edge computing? Is a time-series database a Thing?
mlagally: Would encourage supporting hubs and gateways.
What's the difference between edge and cloud devices...?
McCool: I have not added wording about this to the current text, needs discussing at some point. This PR doesn't include that change.
mlagally: Let's not over engineer this current PR.
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.
McCool: virtual device != service
… Services are a third category
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.
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.
I think digital twins are a reasonable use case.
mlagally: Digital twin is one kind of virtual device.
If we think about what we can do with TD & TM, can define an interface/metadata but can not describe behaviour.
E.g. A simulation model.
Have API description and scripting API.
Could be an interesting topic for upcoming IG/WG charter.
McCool: Already have edge computing listed in charter.
Can merge this as a starting point.
mlagally: I didn't mean edge computing, meant describing behaviour of a device. Let's go ahead and merge.
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.
mlagally: Consider this for the next charter, discuss in use cases call.
Resolution: PR merged.
PR 603 define and discuss hubs
<kaz> PR 603 - WIP: Define and Discuss "Hubs"
McCool: What we need here is a section. Talk about P2P (graph) vs. hub (star) topology.
Discuss whether both are supported by our architecture.
Not done yet, not ready to merge. Need to rebase and re-organise.
<mjk> Reference to ASHRAE CDL https://
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?
mlagally: "Edge" is just about where a device is.
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?
Acting as intermediary. Single device can be both.
<mjk> Conceptual framework for control description language: https://
benfrancis: The cloud is someone else's computer, off-premises in a data center. Edge is own computer on own premises.
McCool: Location and owership. Technology might be the same.
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.
mlagally: Any difference in a Thing Description depending on where it is retrieved from? Any conceptual difference?
McCool: Gateway is confusing because it sounds more restrictive.
benfrancis: A gateway bridges one network to another.
McCool: SmartThings hub also has orchestration capabilities. More than just bridging networks.
benfrancis: An ethernet hub is simpler than a home gateway. A smart home hub is different
McCool: ethernet hub is different. Maybe there's a better term.
McCool: One sticking point is the smart home gateway section may need to be renamed to smart home hub to be consistent.
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.
McCool: My current problem with the text is that the same terms are used in different ways.
… Edge devices sometimes used to mean a service like an AI service. A hub could provide an AI service.
mlagally: Should we be talking about services and service platforms, or stick to hardware.
McCool: Not a big deal if we don't talk about services.
mkoster: Is there a way we can avoid categorising things we don't need to?
?
… Maybe we can have the discussion without naming it. Can give examples to expose that there isn't a consistent term
mlagally: We could use edge device in the next iteration
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.
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 redefine these words.
McCool: Difference between gateway and intermediary is like the difference between device and thing.
McCool: This is talking about a physical box.
McCool: More of a physical category, intermediary is an abstraction of a service.
McCool: I think I have a plan of action to remove hub and use gateway.
profiles
ml: several prs to look at: 103, 87, 85, 93, 78
pr 103, queryallactions
ml: main issue is if a consumer crashes, can recover, or to let another device to look at what a thing is doing
bf: let me share my screen and walk through it
<benfrancis> https://
bf: we have existing action ops, and we just added queryallactions in TD spec
… main use case if one consumer invokes an action, and another needs to know about it
… or if consumer crashes
… in both cases, URL of action resource needs to be recovered
… change to spec introduced top-level form for actions
… add queryallactions as op to that, use a GET
… 200 status code, body is an object keyed by action name, then each is an array of actions
ml: what does the sequence tell us? does it have semantics?
bf: not really
mm: retention of action objects once completed?
<kaz> 5.2.2.4 queryallactions
bf: not a real good answer here; cancelled actions are deleted
… but if completed or failed, kept around for an implementation-specific length of time
… needs to stick around as long as a consumer might need to check status
… no rule, it depends
ml: such things cause corner cases; 0 retention time vs. infinity
bf: retension time of 0 or infinity both will not work
… but intermediate value is not clear
bf: but once it goes away, consumer can not longer find out about past actions
… agree ambiguity is not great
… if it gets a 404, knows it cannot get a status
ml: I wonder what we can do as a generic consumer
… suppose you initiate an action, crash, then try to find out actions you created
… which raises another question, is there a filter?
bf: authorization is orthogonal to API design
… but restriction to owners would be one way to do this
ml: question was not about authorization, but identification
bf: if system is designed that all actions are visible to all
ml: not sure this is a problem
ml: after crash, a device does not now if it should restart an action that it needed to do
kaz: was also wondering about this point as well
… in theory an intermediary can remember the various devices, and let the consumer know about the information based the request from the consumer.
mm: problem is we have to have some way to identify consumers, which is tricky
… if it's user-generated, then that has various problems (duplicates, etc)
… if server-generated, same problem as URLs getting lost in a crash
kaz: this point is one the reasons why I want to invite the Takenaka guy to our OpenDay. They use WoT to manage multiple buildings with various devices, so should have some mechanism already to handle this issue.
ml: in summary, retention time and consumer identity
… don't have timestamps
mm: timestamps raise issues of clock sync...
ml: could use sequence number instead
mm: this is better than nothing, though, and certs (authorization) is not a terrible way to handle identity
ml: there is also the issue of idempotent actions, etc.
… in this case "syncing up" is easier
… for example, checking if a motor is running
mm: I think if it CAN be handled by a property, it should be
… we probably want to think about use cases where properties are not suitable
… for example, a print queue
bf: note that resources will exist whether or not you query them
… and can still check status individually
… so this just adding a group operation
ml: I think the order should be the order in which the actions were invoked
mm: or at least the order in which the server dealt with them
bf: note that actions might take place in parallel... how do you order, start or end time?
… in web things also have start and end time, and timestamps
… is a separate issue for timestampes
mm: so let's worry about timestamps and ordering separately
kaz: have brought up problem of sequences many times
… there have been specs for this SMIL, MMI, and cars have some specs for this
… but that kind of detail is out of scope for WoT
… so we can create a dedicated issue for that, but details might have to be in separate charter
… it's complicated, so maybe we should defer it
<benfrancis> "Actions need a way to express time stamps" https://
mm: I am ok with sets semantically, just a little worries about things like signing
… want a canonical order (but it does not have to have "meaning")
bf: or can sort by timestamps
mm: but I think all we want at this point is a stable order
ml: assume I want to model just the three things in draft...
bf: queryallactions is currently the only top-level form action allowed
… but what IS missing is whether this is optional or mandatory
ml: so, what do we do
ml: could merge as it is, add owners, etc.
mm: I personally think we should merge and make issues for the various points raised
… identity, for instance, is complicated
bf: identity is a big issue
bf: happy to deal with consistent order, identity, and timestamps as followup activities
ml: also retention time
… how do we deal with that?
bf: first op that we have that deals with historical data
… everything else is about current state
… but this creates dynamic resources with independent lifetimes
mm: is this any worse than other restful apis? we should do some research to see if there is a better solution out there
bf: let's also have that as a followup issue
… if this was a push api, would push the status and then not worry about retention
ml: will create some issues...
… start with "action improvements"
… order of return, identity/owner of action invocation, retention time; already have timestamps
<kaz> Issue 104 - Actions Improvements: order of return values
<kaz> Issue 105 - Action Improvements: identity /owner of an action invocation
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
<kaz> Issue 106 - Action Improvements: retention time of action status
ml: then that would not work for nosec
mm: right; too bad
mm: for retention time, I will look into best practices for apis; but we could also just pick an arbitrary minimum retention time
ml: ok, merging pr
<kaz> PR 103 merged
AOB?
ml: call next week, 1h, discuss TPAC
<kaz> [adjourned]