13:56:06 <RRSAgent> RRSAgent has joined #wot-arch
13:56:06 <RRSAgent> logging to https://www.w3.org/2021/07/15-wot-arch-irc
13:56:13 <kaz> meeting: WoT Architecture
13:57:06 <kaz> present+ Kaz_Ashimura
14:00:16 <mlagally_> mlagally_ has joined #wot-arch
14:01:22 <kaz> present+ Michael_McCool
14:02:00 <kaz> present+ Gabe_Fierro
14:03:25 <kaz> present+ Michael_Lagally, Michael_Koster
14:03:31 <McCool> McCool has joined #wot-arch
14:06:31 <Mizushima> Mizushima has joined #wot-arch
14:06:49 <gtfierro> gtfierro has joined #wot-arch
14:07:17 <kaz> scribenick: McCool
14:07:42 <kaz> present+ Ben_Francis, Tomoaki_Mizushima
14:07:58 <kaz> q+ to mention the PP to make sure
14:08:24 <McCool> kaz: reviews patent policy; this is a WG meeting
14:08:50 <kaz> -> https://www.w3.org/2003/12/22-pp-faq.html W3C Patent Policy
14:08:58 <McCool> ... content in this call might be used for spec generation, at which point it will be provided on a royalty-free basis
14:09:11 <McCool> ... please see above FAQ for details
14:09:19 <gtfierro> Thanks for the heads up!
14:09:22 <McCool> q?
14:09:24 <McCool> ack k
14:09:24 <Zakim> kaz, you wanted to mention the PP to make sure
14:09:26 <ryuichi> +
14:09:27 <kaz> present+ Ryuichi_Matsukura
14:09:46 <McCool> ml: several topics today; action semantics, echonet example, use case
14:09:47 <kaz> zakim, who is on the call?
14:09:47 <Zakim> Present: Kaz_Ashimura, Michael_McCool, Gabe_Fierro, Michael_Lagally, Michael_Koster, Ben_Francis, Tomoaki_Mizushima, Ryuichi_Matsukura
14:09:58 <kaz> rrsagent, make log public
14:10:07 <McCool> ... let's do minutes at the end of the call
14:10:29 <kaz> Agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#June_17th.2C_2021
14:10:30 <McCool> ... will try to wrap up tech discussion 30m from end
14:11:00 <McCool> ml: we also have Gabe Fierro with a use case, but due to timezone issues could not join UC call
14:11:10 <kaz> present+ Sebastian_Kaebisch
14:11:12 <McCool> gabe: I have ten slides
14:11:29 <McCool> ml: ok, propose we take 30m for profiles, then do use cases, then architecture
14:12:05 <kaz> s/17/15/
14:12:50 <McCool> topic: profiles
14:13:33 <kaz> s/#June/#July/
14:14:14 <McCool> subtopic: action semantics
14:14:40 <McCool> ml: we talked about this at the F2F, I have been working on a proposal and PR
14:14:50 <McCool> ... but let's start with the issue
14:15:02 <mlagally_> https://github.com/w3c/wot-profile/issues/81
14:15:53 <McCool> ml: ben has posted a detailed comment that looks like a good starting point for some specification text
14:16:28 <McCool> bf: there was some discussion about how to mark up different interactions
14:16:39 <McCool> ... this is organized around operation names
14:17:01 <McCool> ... and this is a proposal for how these operations would work in the HTTP binding
14:17:28 <McCool> ml: let me also share the specification text so people have the context
14:18:05 <McCool> bf: so what is currently undefined is how to handle asynch vs. sync actions
14:18:30 <McCool> ... for long-running actions, do you get a response pointing at a dynamic resource?
14:18:49 <McCool> ... my proposal is there are two different ways for a device to respond to an action
14:19:09 <McCool> ... consumers should support both; but other options in this post, like query, etc. could be optional
14:19:12 <kaz> s/https/-> https/
14:19:21 <McCool> ... there is also an "action status object"
14:19:34 <kaz> s/81/81 wot-profile Issue 81 - Action semantics/
14:19:39 <kaz> rrsagent, draft minutes
14:19:39 <RRSAgent> I have made the request to generate https://www.w3.org/2021/07/15-wot-arch-minutes.html kaz
14:19:43 <McCool> ... just a simple JSON format with various members
14:20:04 <kaz> Chair: Lagally
14:20:17 <McCool> ... includes "status" which is an enum giving current state, also error, input, and output
14:20:33 <McCool> ... for sync, would immediately get the action status object
14:20:40 <kaz> i/views patent policy/topic: Preliminary/
14:20:40 <McCool> q+
14:20:43 <kaz> rrsagent, draft minutes
14:20:43 <RRSAgent> I have made the request to generate https://www.w3.org/2021/07/15-wot-arch-minutes.html kaz
14:22:12 <McCool> bf: for async response, would get a 201 (created) code, and a *header* that points to the resources
14:24:12 <McCool> mm: two questions; is input echoing optional?  possible problem with large inputs
14:24:31 <McCool> ... second, putting resources in the header is not pretty well supported right now
14:24:38 <McCool> ... perhaps we can also put in the body
14:25:10 <McCool> mk: really should support headers; could do both for now as a placeholder
14:25:25 <sebastian> sebastian has joined #wot-arch
14:25:27 <sebastian> q+
14:25:29 <McCool> ... but legacy systems that already do this
14:25:58 <McCool> mm: although we are targetting greenfield systems with profiles
14:26:03 <kaz> q?
14:26:05 <kaz> ack m
14:26:08 <kaz> ack s
14:26:09 <McCool> ... so I think legacy support is not an issue
14:26:23 <McCool> seb: what about identification of the action?
14:26:35 <McCool> ... is that handled by the URL?
14:26:50 <McCool> ... oh, I see, yes, that's the intent of the dynamic resources
14:26:58 <McCool> bf: right, the resource is the id
14:27:17 <McCool> bf: in web things there is also an option to list the action queue, could add that
14:27:38 <McCool> ... but it's not completely required
14:28:01 <McCool> mk: although you could use ACLs to manage access, etc.
14:29:21 <McCool> mm: note in passing this requires polling, and does not support event notification
14:30:02 <McCool> bf: right; but let's defer that; one possible way would be to use SSE
14:30:31 <McCool> ml: not meaning to cut things off, just want to show the other proposal briefly
14:30:55 <kaz> q?
14:31:29 <mlagally_> https://github.com/w3c/wot-profile/pull/88
14:32:11 <kaz> s/https/-> https/
14:32:27 <McCool> so this format adds a status element to the response
14:32:29 <kaz> s/88/88 wot-profile PR 88 - action semantics/
14:32:49 <McCool> q+
14:33:26 <kaz> -> https://pr-preview.s3.amazonaws.com/w3c/wot-profile/88/f1ec8e2...45d4497.html#actions diff
14:35:24 <McCool> mm: think we should merge the id and url
14:35:28 <McCool> bf: agree
14:36:01 <McCool> ... don't thing using headers is feasible, even if not possible to describe in TD, but not ideal
14:36:03 <McCool> q+
14:36:41 <McCool> bf: we could implement the action based on a canonical TD
14:37:05 <kaz> s/don't thing/don't think/
14:37:18 <kaz> q?
14:37:20 <kaz> ack m
14:37:52 <McCool> ... could have an example TD for the core profile, and an informative TD with all the device
14:37:59 <sebastian> q+
14:38:24 <McCool> ml: let's go look at the other operations as well
14:38:50 <McCool> ... queryaction, updateaction; these relate to the actionstatus resource
14:39:23 <McCool> q+
14:39:58 <McCool> bf: and note these do take place on the dynamic resources, and are not described in the TD
14:40:21 <McCool> mk: aligns with REST
14:41:25 <McCool> mm: hypermedia like this can't really be described in a TD... yet
14:41:59 <McCool> bf: agree is not ideal, but would rather not block progress on profiles
14:42:28 <McCool> ml: think we should incorporate it
14:42:36 <McCool> seb: agree, this is a reasonable
14:43:22 <McCool> mm: also agree it is reasonable, with a few small updates we can do after a PR is merged
14:43:48 <McCool> bf: okay.  There are a few other perhaps optional features, e.g. updateaction
14:44:10 <McCool> ... this can change a running action; but this might have potential issues with race conditions
14:44:27 <McCool> mk: asking the server to reinterpret a payload
14:44:54 <McCool> seb: I think it also makes sense this is optional
14:45:34 <McCool> mm: also makes sense for device to decide whether to support or not; it may not make sense for some actions
14:45:52 <McCool> ml: optionality does create issues for interoperability
14:46:18 <kaz> q+
14:46:22 <McCool> ... could just cancel an action and then recreate it
14:46:48 <McCool> bf: probably the only compulsory op should be invokeaction
14:47:04 <mlagally_> q?
14:47:04 <McCool> ... I can think of use cases for update action, but not essential
14:47:06 <kaz> ack s
14:47:10 <McCool> ack m
14:48:09 <McCool> kaz: we should be clear about what "optional" means here too
14:48:24 <McCool> ... from the point of view of a spec; is this MAY, SHOULD, etc.
14:49:16 <McCool> ... and this is also relevant to PR#88
14:49:47 <kaz> ack k
14:50:00 <McCool> bf: agree with optionality point in general, but in this case not a problem, since the producer decides
14:50:25 <kaz> present+ Ege_Korkan
14:50:39 <McCool> ... so if it doesn't want support something, it would respond appropriately, e.g. with an error for an updateaction
14:52:09 <kaz> s/SHOULD, etc./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./
14:52:32 <benfrancis> q?
14:52:58 <McCool> mm: don't think we have consensus yet on whether or not to include updateaction
14:53:21 <McCool> bf: another point is that resource URLs can expire
14:53:53 <McCool> ... so that we have to allow a device to return an error for completed actions...
14:54:06 <McCool> ... if the resource has been cleaned up
14:55:20 <McCool> ml: why not body for 204 response for cleaned up resource?
14:55:42 <McCool> bf: odd given that the semantics of this is "no content", so returning a body weird
14:56:18 <McCool> bf: one other feature I mentioned before was listing the open actions
14:56:24 <McCool> ml: let's keep it simple for now
14:57:13 <McCool> ml: can also use error codes where appropriate
14:57:32 <McCool> ml: ok, we need a PR for this; can either update mine or bf can do one
14:57:53 <McCool> bf: I'll write some specification text and send it over to you
14:58:23 <kaz> q+
14:58:26 <McCool> ege: is this for what profile?
14:58:37 <McCool> mm: let's just say it's for "this" profile for now :0
14:59:13 <McCool> kaz: in near future, may want to look at other IoT standards for bindings
14:59:52 <McCool> ml: need a use case before we work on a detailed profile; and we also need the expertise for people involved in the standard
15:00:10 <McCool> s/for people/from people/
15:00:31 <McCool> bf: it would be good to get feedback from ECHONET though on this profile, since may be aligned
15:00:55 <kaz> ack k
15:01:16 <McCool> 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
15:01:39 <McCool> q+
15:01:55 <McCool> ege: I need to know how to use actions
15:02:15 <McCool> bf: I agree with you, a normal consumer can only invoke actions
15:02:27 <McCool> ... I think this is something that need to be fixed in TDs
15:03:01 <McCool> mm: we agreed not to be blocked on this issue earlier
15:03:33 <McCool> bf: *ideally* it would indeed be nice to be able to write a canonical TD that can describe everything in this profile
15:03:54 <McCool> topic: use cases
15:04:29 <gtfierro> Brick use case: https://github.com/w3c/wot-usecases/pull/132
15:04:37 <McCool> ml: use case from Gabe Fierro, "Portable Building Apps" use case
15:04:41 <Ege> Ege has joined #wot-arch
15:04:48 <Ege> brb
15:05:09 <McCool> mm: relates to the Brick ontology as well, correctly?
15:05:16 <McCool> s/correctly/correct/
15:05:24 <McCool> gf: yes, correct
15:05:37 <benfrancis> Apologies but I need to join a conflicting meeting for the second hour. Thanks for the discussion.
15:05:46 <McCool> gf: (share slides on screen)
15:07:01 <McCool> gf: lots of sensors in buildings, many are legacy
15:07:18 <McCool> ... but useful for data-driven analytics and control
15:08:05 <McCool> ... e.g. fault detection and diagnosis, model predictive control, demand response, virtual sensing (e.g. inferred measurements), etc.
15:08:34 <McCool> ... goals include reduced energy consumption, improved use comfort, etc.
15:09:07 <McCool> ... but very hetereogenous, legacy industrial controls, so very time consuming to integrate
15:09:59 <McCool> ... 70% of buildings have digital controls, only 4% have automated fault detection... data rich, information poor
15:11:08 <McCool> ... 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
15:11:19 <McCool> ... rather than doing it custom every time
15:11:33 <McCool> ... would like a manifest with a set of resources needed for an application
15:11:41 <McCool> ... perhaps a SPARQL query
15:11:57 <McCool> ... that can be executed against the set of devices available in a building
15:12:18 <McCool> .. BRICK ontology defines data sources and their context
15:12:51 <McCool> ... does not itself handle discovery, and assumes data has already been ingested
15:13:42 <McCool> ... there are a few assumptions we have made that we have put off, but WoT may be able to fill those gaps
15:14:26 <McCool> ... brick does not define onboarding, device installation, etc.
15:14:49 <McCool> ... it is not enough to model capability
15:15:10 <McCool> ... also need location, purpose, connections (e.g. hvac ducting)
15:15:32 <McCool> ... my understanding of WoT is that it currently focuses on network interactions
15:16:34 <McCool> ... brick provides the context, wot can provide the interactions and the interaction abstraction to actually get the data out and ingested
15:18:17 <McCool> ... 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)
15:18:35 <McCool> q+
15:18:44 <mlagally_> q+
15:18:48 <kaz> q+
15:19:52 <mjk> mjk has joined #wot-arch
15:19:54 <kaz> ack mc
15:19:56 <mjk> q?
15:20:16 <McCool> mm: first, WoT Discovery has SPARQL support (for metadata); but is Brick about devices or about data from devices?
15:21:59 <McCool> mm: 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
15:22:23 <mjk> q?
15:22:32 <kaz> ack ml
15:22:59 <McCool> ml: 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
15:23:34 <McCool> gf: not sure if people are familiar with ASHRAY; another ontology looking at finer detail than Brick
15:24:02 <McCool> ... Brick only has basic relationships, ASHRAY is more inspired by SAREF
15:24:16 <McCool> gf: is there documentation of the link types we have?
15:24:41 <McCool> ml: in the TD spec
15:24:51 <McCool> seb: need to look at the latest editor's draft
15:25:07 <McCool> ... loot at the 5.3.4.1
15:25:37 <McCool> s/loot/look/
15:25:56 <kaz> -> https://w3c.github.io/wot-thing-description/#link 5.3.4.1 Link from the Thing Description ED
15:25:59 <McCool> ml: would you also like to present your actual PR?
15:26:08 <kaz> q?
15:26:10 <McCool> #132
15:27:14 <McCool> bf: there is another level of abtraction; work through a controller
15:27:25 <McCool> ... as opposed to talking to devices directly
15:27:28 <kaz> i|there is|-> https://github.com/w3c/wot-usecases/pull/132 wot-usecases PR 132 - Add portable building apps use case draft|
15:27:40 <kaz> s/bf:/gf:/
15:27:50 <McCool> ... brick model would define topology and composition
15:28:39 <McCool> ... some examples are included for rouge zone detection and detecting a defective chilling coil
15:30:14 <McCool> ... 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
15:30:52 <McCool> ml: are you just looking at primitive types, or also A/V data?
15:31:10 <McCool> gf: mostly primitive, there are a few A/V applications; future scope currently
15:31:53 <McCool> gf: gaps listed are standard semantics for common things, like thermostat settings, motor states, etc.
15:32:20 <McCool> ... these have a consistent physical meaning but are expressed in different ways by different manufactureres
15:32:41 <McCool> s/manufactureres/manufactures/
15:33:11 <sebastian> rrsagent, create minutes
15:33:11 <RRSAgent> I have made the request to generate https://www.w3.org/2021/07/15-wot-arch-minutes.html sebastian
15:33:15 <McCool> gf: one challenge is the need for complex interpretation of values
15:33:27 <kaz> q?
15:33:51 <McCool> ml: assume there is lot of legacy in buildings
15:34:07 <McCool> gf: correct, and often see very strict siloing
15:34:29 <McCool> ... and... companies that installed systems may not even exist anymore
15:34:43 <McCool> ... lighting doesn't talk to heating, etc.
15:35:37 <McCool> kaz: gf, are you proposing this as part of the LBDG or as a rep of the university?
15:35:50 <mjk> q?
15:36:01 <McCool> gf: as a representative of the Brick community
15:36:01 <mjk> q+
15:36:15 <McCool> kaz: so I think it would be useful to talk to LBDG
15:36:57 <kaz> s/talk to/continue to talk with/
15:36:59 <McCool> ... and we can certainly look at how to refer to brick ontologies from TDs
15:37:13 <McCool> mk: could also attempt to align with ASHRAY work
15:37:37 <McCool> ... consider BACNET; currently not a standard
15:38:10 <McCool> ... but they are using RDF/TTL, and WoT TDs are RDF, so...
15:38:45 <McCool> gf: embedded in that community, so am connected to them
15:39:03 <McCool> ... US Dept of Energy is funding a semantic interop effort
15:39:23 <McCool> ... part my goal is to develop integrations between these
15:39:34 <McCool> ... 2D3P
15:40:13 <McCool> gf: there is definitely an opportunity for WoT to solve problems here
15:40:37 <McCool> mk: BACNET is fairly simple so a good place to start
15:41:11 <McCool> ... and already exists in a form that is usable, although tooling needs to be implemented
15:41:30 <sebastian> q+
15:41:38 <McCool> ... would be nice that instead of reading the specs for each device you could just get a TD
15:41:54 <McCool> gf: is something that I will definitely look into
15:42:18 <McCool> ... bacnet world tends to access everything through bacnet, so...
15:42:38 <McCool> seb: this is one of the next tasks for WoT also; an official BACNET binding for WoT
15:43:13 <McCool> ... so collaborating with ASHRAE SDO
15:43:21 <McCool> s/ASHRAY/ASHRAE/
15:44:05 <McCool> gf: there is already working being done to create the SHACL information by Joel Bender
15:44:21 <McCool> ... software engineer at Cornell in building systems group
15:44:53 <McCool> mk: my company is also working on this, and would be interested in promoting WoT as a common format
15:45:16 <McCool> q+
15:45:22 <kaz> ack k
15:45:24 <McCool> ack mjk
15:46:20 <mlagally_> q?
15:46:38 <McCool> gf: definite room for improvement in BMS; we did have to convince people to go with LD
15:46:58 <McCool> ml: can you share these slides, perhaps as a PR?
15:47:09 <McCool> ... to the contributions
15:47:52 <kaz> q?
15:47:56 <McCool> ack s
15:47:57 <McCool> ack m
15:48:16 <McCool> topic: architecture PRs
15:49:45 <kaz> subtopic: PR 602
15:50:03 <kaz> -> https://github.com/w3c/wot-architecture/pull/602 wot-architecture PR 602 - Refactor TD/Discovery Material in Section 8
15:50:15 <kaz> mm: have to do some more refactoring
15:50:40 <kaz> ... added a list of discovery
15:51:03 <kaz> ... another on summary
15:51:15 <kaz> ... would like to go ahead and merge this PR
15:51:23 <kaz> ... then let the Discovery TF review it
15:51:50 <kaz> ml: would like to review it first
15:51:53 <kaz> mm: that's fine
15:52:20 <kaz> subtopic: PR 601
15:52:31 <kaz> -> https://github.com/w3c/wot-architecture/pull/601 PR 601 - Fixup Device Classes
15:52:41 <kaz> mm: new top level category
15:53:06 <kaz> ... a bit uncomfortable with the device name
15:53:22 <kaz> -> https://pr-preview.s3.amazonaws.com/mmccool/wot-architecture/pull/601.html#device-categoriesdevices 4. Device Categories
15:53:41 <kaz> mm: in the comment, I have some suggestions
15:53:58 <kaz> ... not for merge yet
15:54:10 <kaz> ... suggest a paragraph
15:54:43 <kaz> ml: question about the text
15:54:59 <kaz> mm: some of the text still odd
15:55:13 <kaz> ... the HTML diff is not really useful for this
15:55:44 <kaz> ... 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.
15:56:13 <kaz> ml: name change?
15:56:19 <kaz> mm: let me add the change then
15:56:46 <kaz> subtopic: PR 603
15:56:57 <kaz> -> https://github.com/w3c/wot-architecture/pull/603 PR 603 - WIP: Define and Discuss "Hubs"
15:57:15 <kaz> mm: regarding smart home gateways
15:57:55 <kaz> ... add definitions for "hubs" and "gateways"
15:58:14 <kaz> ... also "smart home gateway" with consistent usage
15:59:14 <kaz> ml: something to consider for industrial hubs too
15:59:18 <kaz> mm: yeah
16:00:28 <sebastian> I have to go... cu
16:00:55 <kaz> s/I have to go... cu//
16:00:56 <kaz> q+
16:01:19 <kaz> ml: please talk with Matsukura-san, who originally provided description for gateways
16:01:53 <kaz> topic: ECHONET Liaison
16:02:07 <kaz> ml: do we need a separate profile for ECHONET?
16:02:19 <McCool> ack k
16:02:51 <McCool> kaz: we shoudl handle the echonet discussion via the official liaison path
16:03:25 <McCool> ... and binding to industrial specs should be a profile or an implementation note?
16:03:46 <kaz> s/shoudl/should/
16:03:52 <McCool> ... if really needed we can do that, but perhaps it should be just a protocol binding
16:04:16 <McCool> ml: true, but felt we were very close and could just align if possible
16:04:25 <kaz> s/and binding/and the question is if/
16:04:50 <McCool> adjourn
16:05:16 <kaz> rrsagent, make log public
16:05:20 <kaz> rrsagent, draft minutes
16:05:20 <RRSAgent> I have made the request to generate https://www.w3.org/2021/07/15-wot-arch-minutes.html kaz
18:09:38 <Zakim> Zakim has left #wot-arch