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)
Lagally: (goes through the
minutes)
... any objections to approve the minutes?
(none)
Lagally: approved
Lagally: would close #473
Lagally: (adds a comment)
Lagally: Agriculture use case by Matsukura-san?
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> 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> 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> 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
Vehicle Information Service Specification
<taki> +1
<ktoumura> ontologies for Units of Measure, Quantity Kinds, Dimensions and Types
<taki> +1
fyi, obsolete Vehicle Information API Specification
Taki: when we talk about
profile
... one aspect is a small device with limited resources
... SenML defines common set for small devices
<taki> 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> 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> ontologies for Units of Measure, Quantity Kinds, Dimensions and Types
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> The Ontology of Units of Measure?
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)
Lagally: there will be no architecture call next Thursday, April 16
[Call 1 adjourned]
Lagally: it's Easter vacation season...
Lagally: (goes through the agenda)
Kaz: has just been published along with the press release
Lagally: really happy with that
Kaz: the top page news includes links to architecture, TD and the press release
Lagally: thank you!
Lagally: (goes through the
minutes)
... approved
Lagally: (goes through the use cases)
McCool: regarding the agriculture use
case
... location is also important
Lagally: let's go through the use case issue
Issue 479 - agriculture use case
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
Lagally: would merge this Pullrequest
471
... (goes through the proposed changes)
... merged
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?
McCool: just realized "location"
probably should be "geolocation" insead
... can do a Pullrequest
Lagally: ok
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: https://github.com/w3c/wot-architecture/pull/478
Lagally: the next topic is the lifecyce diagram itself
<mlagally> ACTION: all - Please review https://github.com/w3c/wot-architecture/blob/master/proposals/unified%20device%20lifecycle.svg
<mlagally> ACTION: all- Please review: 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?
device lifecycle.svg Lagally's unified diagram
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: https://github.com/w3c/wot-architecture/blob/master/proposals/WoT%20lifecycle%20diagram-WoT%20new%20lifecycle.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]
