- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 27 Apr 2020 17:46:21 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/04/09-wot-arch-minutes.html
also as text below.
Thanks,
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT Architecture
09 Apr 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Agenda
Attendees
Present
Call 1: Kaz_Ashimura, Michael_Lagally, Taki_Kamiya,
Tomoaki_Mizushima, Ryuichi_Matsukura, Kunihiko_Toumura
Call 2: Kaz_Ashimura, Michael_Lagally, Michael_McCool,
Tomoaki_Mizushima, Zoltan_Kis, Elena_Reshetova,
David_Ezell
Regrets
Chair
Lagally
Scribe
kaz
Contents
* [3]Topics
1. [4]Call 1
1. [5]Agenda
2. [6]Previous minutes
3. [7]Issues
4. [8]Use cases
2. [9]Call 2
1. [10]Agenda
2. [11]WoT Architecture is now a W3C Recommendation!
3. [12]Previous minutes
4. [13]Use cases
5. [14]Govtech use case
6. [15]Lifecycle
* [16]Summary of Action Items
* [17]Summary of Resolutions
__________________________________________________________
Call 1
Agenda
Lagally: (goes through the agenda)
... some housekeeping for today
... then use cases
... agriculture would make sense
... McCool also will join the second call
... would like to make all synchronized about lifecycle
discussion
... then profile
... whether having a separate call or not
... we'll see
... anything to be added?
(none)
Previous minutes
[18]Apr-2 minutes
[18] https://www.w3.org/2020/04/02-wot-arch-minutes.html
Lagally: (goes through the minutes)
... any objections to approve the minutes?
(none)
Lagally: approved
Issues
[19]Issues
[19] https://github.com/w3c/wot-architecture/issues
Lagally: would close #473
[20]Issue 473
[20] https://github.com/w3c/wot-architecture/issues/473
Lagally: (adds a comment)
[21]Lagally's comment
[21] https://github.com/w3c/wot-architecture/issues/473#issuecomment-611349446
Use cases
Lagally: Agriculture use case by Matsukura-san?
[22]Pullrequest 471
[22] https://github.com/w3c/wot-architecture/pull/471
Matsukura: Smart agriculture
... agriculture use case includes several small cases
... (goes through the template description)
... target users: Agricultural corporation, Farmer,
Manufacturers (Sensor, other facilities), Cloud provider
... motivation:
... a green house could be controlled by a computer
... expected devices: Sensors ( temperature, humidity,
brightness, UV brightness, air pressure, and CO2)
... expected data: Sensors¢ values to clarify the gaps between
conditions for maximizing photosynthesis and the current
environment.
... Following sensors values at one or some points in the
greenhouse: temperature, humidity, brightness, and CO2.
... (then goes through the description)
* Sensors and some facilities like heater, CO2 generator, sheet
controller are connected to the gateway via wired or wireless
networks. The gateway is connected to the cloud via the
Internet. All sensors and facilities can be accessed and
controlled from the cloud.
* To maximize photosynthesis, the temperature, CO2
concentration, and humidity in the greenhouse are mainly
controlled. When the sunlight comes in the morning and CO2
concentration inside decreases, the application turns on the
CO2 generator to keep over 400 ppm, the same as the air
outside. The temperature in the greenhouse is adjusted by
controlling the heater and the sunlight shielding sheet.
* The cloud gathers all sensor data and the status of the
facilities. The application makes the best configuration for
the region of the greenhouse located.
]]
Matsukura: gaps
... In the case of the wireless connection to the sensors, the
gateway should keep the latest value of the sensors since the
wireless connection is sometimes broken. The gateway can create
a virtual entity corresponding to the sensor and allow the
application to access this virtual entity having the actual
sensor status like sleeping.
Lagally: tx for your input
... it's a good description
... a couple of questions here
... typical measurement for sensors?
... what kind of requirements here?
Matsukura: requirements for the WoT Architecture
... role of virtual devices
... to keep the values from the devices
... to be connected with the wireless network
... the lifecycle discussion is ongoing no
... a requirement is status of a Thing
... a Thing could have a few states
... available or not, sleeping or not, etc.
Lagally: on the lifecycle
... potentially some new state
... is the location of the sensors managed?
... where it's actually located
Matsukura: good question
... location information is usually given by humans
... during the installation process
... keeping the location of sensors is important
... note that the wireless connection may change everyday
... sometimes the farmers might move the sensors to somewhere
else
... but at that time the location is reconfigured manually
Lagally: ok
... as configuration data
... what about the temperature?
... if different sensors generate different kind of data?
... JP vendors may use Celsius but the others may use
Fahrenheit
Matsukura: depends on the countries, etc.
Lagally: need to have some unique way to handle that
... humidity, brightness, etc.
... we need to have types
... some kind of type system
Kaz: similar to the previous discussion by Automotive
... default value could be SI unit but we should have a type
feature as well
Lagally: yeah, some kind of type system is needed
... one group may use some metrics and others may use other
metrics
... need to have some common basis so that they can communicate
with each other
... how to deal with that is a good question
... is there type information at all?
Toumura: is there some special requirement on
discovery/onboarding for agriculture use case?
Matsukura: maybe something needed
... but so far no detail yet
Lagally: currently we have sensors for onboarding
... potentially some configuration there
... (looks at the td draft)
<mlagally>
[23]https://www.w3.org/TR/wot-thing-description/#dataschema
[23] https://www.w3.org/TR/wot-thing-description/#dataschema
Lagally: any arbitrary values?
... put some of the features
<mlagally> C, Cel, Celsius, Deg, K , Kelvin,
Lagally: what we need here is either some way of enumeration
for possible values?
... reference some standards for possible values?
... there are a couple of time-handling specs
... (visits wot-profile repo)
... latitude, longitude, altitude, ...
... and reference here
... ISO 6709
<mlagally>
[24]https://en.wikipedia.org/wiki/ISO_6709#String_expression_(A
nnex_H)
[24] https://en.wikipedia.org/wiki/ISO_6709#String_expression_(Annex_H)
Lagally: specific format for GPS
... not prepared for today, though
... there has been another group
... (goes through "SI unit")
<mlagally>
[25]https://en.wikipedia.org/wiki/International_System_of_Units
#References
[25] https://en.wikipedia.org/wiki/International_System_of_Units#References
Lagally: any concrete resources about SI unit?
Kaz: we can look into the specs from the Automotive WG and the
Devices and Sensors WG
Lagally: let me create an issue about this
[26]Vehicle Information Service Specification
[26] https://www.w3.org/TR/2018/CR-vehicle-information-service-20180213/
[27]Generic Sensor API
[27] https://www.w3.org/TR/2019/CR-generic-sensor-20191212/
<taki> +1
<ktoumura> [28]ontologies for Units of Measure, Quantity Kinds,
Dimensions and Types
[28] https://qudt.org/
<taki> +1
[29]fyi, obsolete Vehicle Information API Specification
[29] https://www.w3.org/TR/2018/NOTE-vehicle-information-api-20180626/
Taki: when we talk about profile
... one aspect is a small device with limited resources
... SenML defines common set for small devices
<taki> [30]https://www.iana.org/assignments/senml/senml.xhtml
[30] https://www.iana.org/assignments/senml/senml.xhtml
Taki: the draft above is interested
... the data is encoded in several different ways
Lagally: SenML itsef is an RFC. right?
Taki: right
Lagally: this is very valuable
<mlagally> [31]https://tools.ietf.org/html/rfc8428
[31] https://tools.ietf.org/html/rfc8428
Kaz: Ari and Carsten are involved
Lagally: right
... CBOR serialization also to be considered
... (adds comments to the new issue)
... consider to use RFC8428
Toumura: I also put some resource on the IRC
<ktoumura> [32]ontologies for Units of Measure, Quantity Kinds,
Dimensions and Types
[32] https://qudt.org/
Toumura: paste it again above
... general information about units
Taki: in the TD TF, we had some discussion
... we can revisit the issue
... several participants preferred OM data type system
... some prefers QUDT, though
<ktoumura> [33]The Ontology of Units of Measure?
[33] http://ontology.eil.utoronto.ca/icity/OM/1.2/
Lagally: need to select a default and define a standardized way
for an override for specific industry
... anything else missing?
... (add some more comments)
... states: running, stopping, sleeping, available disabled
... is somebody interested in taking this?
... (shows requirements template as well)
... somebody volunteers?
Matsukura: can work on that
Lagally: (assigns the new issue 479 to Matsukura-san)
[34]Issue 479
[34] https://github.com/w3c/wot-architecture/issues/479
Lagally: there will be no architecture call next Thursday,
April 16
[Call 1 adjourned]
__________________________________________________________
Call 2
Agenda
Lagally: it's Easter vacation season...
Lagally: (goes through the agenda)
WoT Architecture is now a W3C Recommendation!
Kaz: has just been published along with the press release
[35]W3C Top page news about that
[35] https://www.w3.org/blog/news/archives/8436
Lagally: really happy with that
Kaz: the top page news includes links to architecture, TD and
the press release
Lagally: thank you!
Previous minutes
[36]Apr-2 minutes
[36] https://www.w3.org/2020/04/02-wot-arch-minutes.html
Lagally: (goes through the minutes)
... approved
Use cases
Lagally: (goes through the use cases)
[37]Issues for use cases
[37] https://github.com/w3c/wot-architecture/issues
McCool: regarding the agriculture use case
... location is also important
Lagally: let's go through the use case issue
[38]Issue 479 - agriculture use case
[38] https://github.com/w3c/wot-architecture/issues/479
Lagally: requirements for agriculture
... states: (running, stopping, sleeping, available, disabled)
... units with clear reference points and defaults, e.g. SI
units (for location, temperature, time, ...)
McCool: thought we had dedicated discussion about units during
the TPAC f2f in Lyon
Lagally: (adds a note about that)
... a set of candidates were considered
McCool: each possible approach has pros/cons
Lagally: (adds some more)
... no choice was made (in Lyon)
... standardizing on a specific default could be part of a
profile
... to be discussed during the profile requirements discussion
... let's not dig into the detail at the moment
[39]Pullrequest 471
[39] https://github.com/w3c/wot-architecture/pull/471
Lagally: would merge this Pullrequest 471
... (goes through the proposed changes)
... merged
Govtech use case
[40]Pullreques 468
[40] https://github.com/w3c/wot-architecture/pull/468
McCool: this is for the Singapore Govtech use cases
... the issue is privacy here
... we do have event mechanism for pushing data
... this use case uses property to return location information
... kind of related to localization use cases
Lagally: the question is should we have external data
definition?
McCool: similar issue to the unit issue
... something might be considered for profile too
... also geolocation API
... that's W3C-friendly
... note that aggregation is also possible
... total number makes sense for aggregation
... what would you do when you get data?
... another use case came up was counting people's number
... (explains the variants section)
... some of them are actually requirements
... for example, it's difficult to integrate the sensor system
and the gates at a building, etc.
Lagally: in terms of gaps
McCool: gap is not currently worked o
Lagally: could we summarize the requirements?
McCool: need to capture the gaps explicitly
... e.g., image plus JSON
Lagally: maybe we could work on 2nd level of use case
description for that purpose?
[41]requirements template
[41] https://github.com/w3c/wot-architecture/blob/master/REQUIREMENTS/requirements-template.md
McCool: just realized "location" probably should be
"geolocation" insead
... can do a Pullrequest
Lagally: ok
Lifecycle
[42]Pullrequest 478
[42] https://github.com/w3c/wot-architecture/pull/478
Zoltan: (goes through the proposed changes)
Lagally: do you want me to review this pullrequest?
Zoltan: don't have to review this now, we can have informal
discussion at some point
Elena: tx very much
... would encourage everyone to review this
Lagally: the structure is a bit different about the states
sections
Zoltan: possibly operations with WoT or OCF
Lagally: thanks
... this is very useful
... btw, any problems with the diagrams?
Zoltan: diagram still stays
... would like to hear different opinions
Lagally: we should take some time to discuss this
... everybody should review this Pullrequest
Zoltan: if it's merged, would be much more readable
... the content is just a MD file
Lagally: (creates an action)
<mlagally> ACTION: All - Please review:
[43]https://github.com/w3c/wot-architecture/pull/478
[43] https://github.com/w3c/wot-architecture/pull/478
Lagally: the next topic is the lifecyce diagram itself
<mlagally> ACTION: all - Please review
[44]https://github.com/w3c/wot-architecture/blob/master/proposa
ls/unified%20device%20lifecycle.svg
[44] https://github.com/w3c/wot-architecture/blob/master/proposals/unified device lifecycle.svg
<mlagally> ACTION: all- Please review:
[45]https://github.com/w3c/wot-architecture/blob/master/proposa
ls/lifecycle-states.md
[45] https://github.com/w3c/wot-architecture/blob/master/proposals/lifecycle-states.md
[46]Lificycle states
[46] https://github.com/w3c/wot-architecture/blob/master/proposals/lifecycle-states.md
Lagally: this should be also reviewed by all
McCool: I like the new one generated by Lagally
... but need to add some more information
Zoltan: some of the states should be clarified
... what kind of registration to be done when/where?
[47]device lifecycle.svg Lagally's unified diagram
[47] https://github.com/w3c/wot-architecture/blob/master/proposals/unified
Zoltan: what "bootstrap" means?
Lagally: you have 2 entities
McCool: devices become discoverable
Zoltan: for onboarding? or operational?
Kaz: we're at the end of the hour, so I'd suggest that
everybody start to think about your expectation for each state,
what should happen where and when
... don't think the existing 3 diagrams (Oliver, Elena and
Lagally) are contradictory with each other
... it's just that those diagrams have a bit different levels
of granularity
<mlagally> ACTION: all - review:
[48]https://github.com/w3c/wot-architecture/blob/master/proposa
ls/WoT%20lifecycle%20diagram-WoT%20new%20lifecycle.svg
[48] https://github.com/w3c/wot-architecture/blob/master/proposals/WoT lifecycle diagram-WoT new lifecycle.svg
Lagally: ok
... let's start to think about the expectation for each state
... maybe we should start with Elena's diagram above?
... any other business?
(none)
Lagally: there will no architecture call next Thursday on April
16 due to Easter
[Call 2 adjourned]
Summary of Action Items
[NEW] ACTION: all - Please review
https://github.com/w3c/wot-architecture/blob/master/proposals/u
nified%20device%20lifecycle.svg
[NEW] ACTION: All - Please review:
https://github.com/w3c/wot-architecture/pull/478
[NEW] ACTION: all - review:
https://github.com/w3c/wot-architecture/blob/master/proposals/W
oT%20lifecycle%20diagram-WoT%20new%20lifecycle.svg
[NEW] ACTION: all- Please review:
https://github.com/w3c/wot-architecture/blob/master/proposals/l
ifecycle-states.md
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [49]scribe.perl version 1.154 ([50]CVS log)
$Date: 2020/04/27 08:40:57 $
[49] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[50] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 27 April 2020 08:46:09 UTC