IRC log of wot-arch on 2021-07-15

Timestamps are in UTC.

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