Meeting minutes
Preliminary
Kaz: reviews patent policy; this is a WG meeting
<kaz> W3C Patent Policy
Kaz: content in this call might be used for spec generation, at which point it will be provided on a royalty-free basis
… please see above FAQ for details
<gtfierro> Thanks for the heads up!
<Zakim> kaz, you wanted to mention the PP to make sure
<ryuichi> +
Lagally: several topics today; action semantics, echonet example, use case
… let's do minutes at the end of the call
… will try to wrap up tech discussion 30m from end
Lagally: we also have Gabe Fierro with a use case, but due to timezone issues could not join UC call
Gabe: I have ten slides
Lagally: ok, propose we take 30m for profiles, then do use cases, then architecture
profiles
action semantics
Lagally: we talked about this at the F2F, I have been working on a proposal and PR
… but let's start with the issue
<mlagally_> wot-profile Issue 81 - Action semantics
Lagally: ben has posted a detailed comment that looks like a good starting point for some specification text
Ben: there was some discussion about how to mark up different interactions
… this is organized around operation names
… and this is a proposal for how these operations would work in the HTTP binding
Lagally: let me also share the specification text so people have the context
Ben: so what is currently undefined is how to handle asynch vs. sync actions
… for long-running actions, do you get a response pointing at a dynamic resource?
… my proposal is there are two different ways for a device to respond to an action
… consumers should support both; but other options in this post, like query, etc. could be optional
… there is also an "action status object"
… just a simple JSON format with various members
… includes "status" which is an enum giving current state, also error, input, and output
… for sync, would immediately get the action status object
Ben: for async response, would get a 201 (created) code, and a *header* that points to the resources
McCool: two questions; is input echoing optional? possible problem with large inputs
… second, putting resources in the header is not pretty well supported right now
… perhaps we can also put in the body
Koster: really should support headers; could do both for now as a placeholder
… but legacy systems that already do this
McCool: although we are targetting greenfield systems with profiles
… so I think legacy support is not an issue
Sebastian: what about identification of the action?
… is that handled by the URL?
… oh, I see, yes, that's the intent of the dynamic resources
Ben: right, the resource is the id
Ben: in web things there is also an option to list the action queue, could add that
… but it's not completely required
Koster: although you could use ACLs to manage access, etc.
McCool: note in passing this requires polling, and does not support event notification
Ben: right; but let's defer that; one possible way would be to use SSE
Lagally: not meaning to cut things off, just want to show the other proposal briefly
<mlagally_> wot-profile PR 88 - action semantics
so this format adds a status element to the response
<kaz> diff
McCool: think we should merge the id and url
Ben: agree
… don't think using headers is feasible, even if not possible to describe in TD, but not ideal
Ben: we could implement the action based on a canonical TD
… could have an example TD for the core profile, and an informative TD with all the device
Lagally: let's go look at the other operations as well
… queryaction, updateaction; these relate to the actionstatus resource
Ben: and note these do take place on the dynamic resources, and are not described in the TD
Koster: aligns with REST
McCool: hypermedia like this can't really be described in a TD... yet
Ben: agree is not ideal, but would rather not block progress on profiles
Lagally: think we should incorporate it
Sebastian: agree, this is a reasonable
McCool: also agree it is reasonable, with a few small updates we can do after a PR is merged
Ben: okay. There are a few other perhaps optional features, e.g. updateaction
… this can change a running action; but this might have potential issues with race conditions
Koster: asking the server to reinterpret a payload
Sebastian: I think it also makes sense this is optional
McCool: also makes sense for device to decide whether to support or not; it may not make sense for some actions
Lagally: optionality does create issues for interoperability
… could just cancel an action and then recreate it
Ben: probably the only compulsory op should be invokeaction
… I can think of use cases for update action, but not essential
Kaz: we should be clear about what "optional" means here too
… from the point of view of a spec; is this MAY, SHOULD, etc. Also given WoT Profile is a profile of related WoT specs, e.g., TD, Binding Templates and Discovery, we should be clear about the potential impact to those original WoT specs too.
… and this is also relevant to PR#88
Ben: agree with optionality point in general, but in this case not a problem, since the producer decides
… so if it doesn't want support something, it would respond appropriately, e.g. with an error for an updateaction
McCool: don't think we have consensus yet on whether or not to include updateaction
Ben: another point is that resource URLs can expire
… so that we have to allow a device to return an error for completed actions...
… if the resource has been cleaned up
Lagally: why not body for 204 response for cleaned up resource?
Ben: odd given that the semantics of this is "no content", so returning a body weird
Ben: one other feature I mentioned before was listing the open actions
Lagally: let's keep it simple for now
Lagally: can also use error codes where appropriate
Lagally: ok, we need a PR for this; can either update mine or bf can do one
Ben: I'll write some specification text and send it over to you
Ege: is this for what profile?
McCool: let's just say it's for "this" profile for now :0
Kaz: in near future, may want to look at other IoT standards for bindings
Lagally: need a use case before we work on a detailed profile; and we also need the expertise from people involved in the standard
Ben: it would be good to get feedback from ECHONET though on this profile, since may be aligned
Ege: one final worry; profile is meant to be a subset of a TD, but this is not a subset, since can't be fully described in a TD
Ege: I need to know how to use actions
Ben: I agree with you, a normal consumer can only invoke actions
… I think this is something that need to be fixed in TDs
McCool: we agreed not to be blocked on this issue earlier
Ben: *ideally* it would indeed be nice to be able to write a canonical TD that can describe everything in this profile
use cases
<gtfierro> Brick use case: https://
Lagally: use case from Gabe Fierro, "Portable Building Apps" use case
<Ege> brb
McCool: relates to the Brick ontology as well, correct?
Gabe: yes, correct
<benfrancis> Apologies but I need to join a conflicting meeting for the second hour. Thanks for the discussion.
Gabe: (share slides on screen)
Gabe: lots of sensors in buildings, many are legacy
… but useful for data-driven analytics and control
… e.g. fault detection and diagnosis, model predictive control, demand response, virtual sensing (e.g. inferred measurements), etc.
… goals include reduced energy consumption, improved use comfort, etc.
… but very hetereogenous, legacy industrial controls, so very time consuming to integrate
… 70% of buildings have digital controls, only 4% have automated fault detection... data rich, information poor
… brick ontology, deploy cyber-physical applications at scale, and have a small number of implementations that can figure out how to integrate with a building
… rather than doing it custom every time
… would like a manifest with a set of resources needed for an application
… perhaps a SPARQL query
… that can be executed against the set of devices available in a building
… BRICK ontology defines data sources and their context
… does not itself handle discovery, and assumes data has already been ingested
… there are a few assumptions we have made that we have put off, but WoT may be able to fill those gaps
… brick does not define onboarding, device installation, etc.
… it is not enough to model capability
… also need location, purpose, connections (e.g. hvac ducting)
… my understanding of WoT is that it currently focuses on network interactions
… brick provides the context, wot can provide the interactions and the interaction abstraction to actually get the data out and ingested
… some future brick work: network view (how are devices connected and communicate; IT perspective); enumerations of device properties; schedules of operation (schema.org-style rules)
McCool: first, WoT Discovery has SPARQL support (for metadata); but is Brick about devices or about data from devices?
McCool: Thing can be other than devices; we have a standardized database (TDD) for Things, but not for data itself; although we can describe its structure
Lagally: we can link between Things; we have been looking at link relation types, would be worth to review and see if what we have should be extended
Gabe: not sure if people are familiar with ASHRAY; another ontology looking at finer detail than Brick
… Brick only has basic relationships, ASHRAY is more inspired by SAREF
Gabe: is there documentation of the link types we have?
Lagally: in the TD spec
Sebastian: need to look at the latest editor's draft
… look at the 5.3.4.1
<kaz> 5.3.4.1 Link from the Thing Description ED
Lagally: would you also like to present your actual PR?
#132
<kaz> wot-usecases PR 132 - Add portable building apps use case draft
Gabe: there is another level of abtraction; work through a controller
… as opposed to talking to devices directly
… brick model would define topology and composition
… some examples are included for rouge zone detection and detecting a defective chilling coil
… and note that the topology is needed to understand the second example, since the sensors before and after the cooling coil may not be provided by the same device, but need to be connect by the duct topology
Lagally: are you just looking at primitive types, or also A/V data?
Gabe: mostly primitive, there are a few A/V applications; future scope currently
Gabe: gaps listed are standard semantics for common things, like thermostat settings, motor states, etc.
… these have a consistent physical meaning but are expressed in different ways by different manufactures
Gabe: one challenge is the need for complex interpretation of values
Lagally: assume there is lot of legacy in buildings
Gabe: correct, and often see very strict siloing
… and... companies that installed systems may not even exist anymore
… lighting doesn't talk to heating, etc.
Kaz: gf, are you proposing this as part of the LBDG or as a rep of the university?
Gabe: as a representative of the Brick community
Kaz: so I think it would be useful to continue to talk with LBDG
… and we can certainly look at how to refer to brick ontologies from TDs
Koster: could also attempt to align with ASHRAE work
… consider BACNET; currently not a standard
… but they are using RDF/TTL, and WoT TDs are RDF, so...
Gabe: embedded in that community, so am connected to them
… US Dept of Energy is funding a semantic interop effort
… part my goal is to develop integrations between these
… 2D3P
Gabe: there is definitely an opportunity for WoT to solve problems here
Koster: BACNET is fairly simple so a good place to start
… and already exists in a form that is usable, although tooling needs to be implemented
… would be nice that instead of reading the specs for each device you could just get a TD
Gabe: is something that I will definitely look into
… bacnet world tends to access everything through bacnet, so...
Sebastian: this is one of the next tasks for WoT also; an official BACNET binding for WoT
… so collaborating with ASHRAE SDO
Gabe: there is already working being done to create the SHACL information by Joel Bender
… software engineer at Cornell in building systems group
Koster: my company is also working on this, and would be interested in promoting WoT as a common format
Gabe: definite room for improvement in BMS; we did have to convince people to go with LD
Lagally: can you share these slides, perhaps as a PR?
… to the contributions
architecture PRs
PR 602
<kaz> wot-architecture PR 602 - Refactor TD/Discovery Material in Section 8
McCool: have to do some more refactoring
... added a list of discovery
... another on summary
... would like to go ahead and merge this PR
... then let the Discovery TF review it
Lagally: would like to review it first
McCool: that's fine
PR 601
<kaz> PR 601 - Fixup Device Classes
McCool: new top level category
... a bit uncomfortable with the device name
<kaz> 4. Device Categories
McCool: in the comment, I have some suggestions
... not for merge yet
... suggest a paragraph
Lagally: question about the text
McCool: some of the text still odd
... the HTML diff is not really useful for this
... added a new sentence: Memory and storage size are both easier to quantify and more limiting than performance, so that is the basis of this categorization.
Lagally: name change?
McCool: let me add the change then
PR 603
<kaz> PR 603 - WIP: Define and Discuss "Hubs"
McCool: regarding smart home gateways
... add definitions for "hubs" and "gateways"
... also "smart home gateway" with consistent usage
Lagally: something to consider for industrial hubs too
McCool: yeah
Lagally: please talk with Matsukura-san, who originally provided description for gateways
ECHONET Liaison
Lagally: do we need a separate profile for ECHONET?
Kaz: we should handle the echonet discussion via the official liaison path
… and the question is if to industrial specs should be a profile or an implementation note?
… if really needed we can do that, but perhaps it should be just a protocol binding
Lagally: true, but felt we were very close and could just align if possible
adjourn