Meeting minutes
Agenda bashing
Guests and W3C Patent Policy
McCool: by joining this call, we assume everybody agrees to the W3C patent policy above
McCool: today's call is organized for the IG side, though
McCool: (quickly shows the agenda of the vF2F this week and next)
... IG: joint on March 15
… joint sessions with liaison orgs today
… WG: Discovery on March 17
… Use Cases on March 18
… IG: Architecture and Profiles on March 22
Lagally: includes some use cases discussion with ITU-T as well on March 22
McCool: ok
… (adds that to the slides)
… any other changes?
(none)
… (shows today's agenda)
scribes
Kaz: will take notes for the first part
… need one more
McCool: volunteer?
Ege: will do
McCool: presenters, please send your slides to me
… will install them on GitHub
(Sebastian gives all reminder on the IRC)
WoT summary and status
McCool: because we have many guests today
… would like to summarize what WoT is like
McCool: [W3C Web of Things (WoT)]
… adapting Web technologies to IoT
… we're on our 2nd Charter
… TD metadata format is already done, and big chunk is for this charter includes discovery
… [WoT Descriptive Interoperability]
… WoT Architecture and WoT Thing Description
… affordances are abstract layer to handle devices
… [Usage Patterns Overview]
… vertical use cases based on the industry needs
… [WoT Orchestrations]
… multiple things there to be combined with each other
… opensource implementation based on Node-RED named node-gen
… and node-wot for Scripting API
… including discovery capability
… will be mentioned during the plugfest report
… [Current WoT WG Charter Work Items]
… a lot of topics
… [Current Status]
… links here
… architecture 1.1 draft
… TD 1.1
… Discovery
… Profiles
… Binding Templates
… Scripting API
… new Group page at https://
… questions?
(none)
IEC CDD
-> Murayama-san's slides @@@
Hiroshi_Murayama(hm)
Hiroshi: [Common Data Dictionary (CDD) on Parcellized Ontology Model and related standards]
… [CDD in a nutshell]
… Common Data Dictionary
… based on IEC 61360-2, ISO 13584-42
… by IEC SC 3D and ISO TC184/SC4
… evolution of ontology elements
… [CDD in a nutshell 2/2]
… ontology developed over time
… used in system infrastructures
… [Base standards]
… data model: IEC 61360-2, ISO 13584-42, IEC 62656-1 and ISO 13584-35
… exchange formats: ISO 13584-32, IEC 62656-1, IEC 62656-8... doain data dictionaries / ontologies being stored and to be stored: IEC 61987-11, 62683, ISO 13584-501, 13584-511, ISO 13399, ISO 23584
… plant automation, switch gear/control panel, laboratory instruments, ...
… IEC DD has been extended in coverage as well as in its functionality
… current IEC CDD is implemented as a subset of IEC 62656-1
… relational ontology model and evolved from ISO 13584-35
… multi-lingual model
… [Cooperation among TCs/SC in IEC & ISO]
… (diagram on the activity)
… [4-layer ontology data model]
… 1. axiomatic ontology (AO)
… 2. meta ontology (MO)
… 3. domain otology (DO)
… 4. domain library (DL)
… [Every layer of ontology in POM is defined as a set of instances of its upper layer, except the Axiomatic Ontology layer at the top]
… M4-M3 for AO M3-M2 for MO, M2-M1 for DO, M1-M0 for DL
… DL is provided by each company
… [Reference mechanism in IEC61360(PLIB) & IEC62656(POM)]
… structure of the ontologies
… class ID -> class -> translated text -> property -> property ID
… relationship between the elements over time to be maintained
… [Class needs to point eactly the specific version, when ontology evolves over time]
… [Reference mechanism in POM/CDD]
… ICID defined in IEC 62656-1 (IO 13584-35) adds separator1 (default "#")
… and separator 2 (default "##") which may be redefined
… [Detail of the RAI]
… [IEC CDD as online DB]
Hiroshi: [Domain standard development with IEC CDD]
… actual definition is stored within the CDD
… actual content is maintained and updated on the ontology side
… [Concept of Class, Property, and Relation]
… [Concept of class in CDD/POM]
… Class C = {X| P1(x1)} ^ P2(x2) ^ ... ^ Pn(xn)}
… [Concept of class and property in CDD/POM]
… [Future? COR on POM as an extended CDD]
… (diagram)
… (this is inline with DPPC final report)
… Common Ontology Repository (COR)
… [Collaboration and cooperation]
… ISO TC184/SC4 and IEC...
… [Summary]
… CDD implemented opnsource
McCool: tx!
… time check
… ok to have discussion within 10mins
… if we need to add anything
… need to understand concrete applications
… we're aiming for finalizing the procedure
… point for connection should be Thing Description and Thing Model
… any existing method to be adapted based on RDF?
Hiroshi: ontology overtime
McCool: additional capability might be version management
… sounds like maybe not completely
… we do support SPARQL
… important to figure out how to access CDD
… maybe search over versions
Sebastian: thanks a lot first
… wondering you use the term "Ontology"
… assuming it's based on RDF
Hiroshi: RDF is just format for the ontology
Sebastian: tools to discover the actual definition?
… what kind of format to be exported?
Hiroshi: mostly XML is used
… JSON is also possible
… there is a list of exposed format
Lagally: many thanks
… online DB
… how many entries?
… how many types?
Hiroshi: more than 20 ontologies
… and maybe 10 thousand entries?
Lagally: what is the typical target areas?
Hiroshi: semiconductor, etc.
… but it's just a part
yoshiaki_sonoda(ys)
Yoshiaki: let me provide some information
… oil, gas, power, etc., is included
… more types of dictionary for ISO community
… originally oil and gas but recently extended for electric power
… imported CDD
… one of the purposes of the open CDD DB
… we'll have more sort of dictionaries (for broader vocabularies)
Hiroshi: (shows the diagram again)
… [Cooperation among TCs/SCs in IEC & ISO]
Lagally: engineering purposes?
Hiroshi: including engineering
Kaz: tx
… think we should continue collaboration on how to refer to the data defined CDD from the WoT side
McCool: should work on 2 levels
… 1. short-term for this Charter period
… and 2. longer-term for the future work
… long-term liaison to be considered for the next Charter too
… btw, wondering about the IEC CDD and ECLASS's work
McCool: does ECLASS depends on the IEC work?
Block: IEC CDD is data model
… and basis of ECLASS
… ECLASS defined data as part of CDD
<mjk> Can someone please send me the teleconference coordinates?
Block: IEC work is industry-independent
Block: ECLASS develops its own JSON model as well
Sebastian: so was wondering about RDF export of CDD
Sebastian: if there is an RDF version, could be integrated with Thing Description easily
McCool: would like to focus on the next step
Kaz: we should continue more collaborative discussion to reuse CDD data for WoT purposes
… maybe we can do that via official liaison but should have more discussion first
McCool: right
… should have more discussion to define the goal
… how to proceed?
Kaz: if it's OK by the IEC side, we can establish/extend a simple liaison for that purpose
Sebastian: would see use cases as well
McCool: makes sense
… we have vertical/horizontal use cases
… concretely and logistically, we hold use cases call biweekly
Lagally: we'll have use cases session during the vF2F as well on Thursday, March 18
McCool: note that this is the virtual F2F call this week and next
… we hold regular calls biweekly as well
McCool: (shows the use cases session agenda on March 18)
<McCool> https://
McCool: or you can join the regular Use Cases call
… when will be the next call?
Lagally: in April but should confirm
Kaz: would like to continue the discussion with Murayama-san and Sonoda-san about further collaboration
Hiroshi: btw, please note that IEC and ECLASS are completely different organizations
McCool: got it
Block: can provide information about ECLASS as well
McCool: ok
(Murayama-san and Sonoda-san leave)
[10min break]
WebThings
-> Ben's slides tbd
Ben: (introduces himself)
… [WebThings Gateway]
… backend with NodeJS
Ben: gateways is a producer and consumer at the same time
… to consume TDs and re expose them to the internet securely
… The exposed TDs can be made W3C compliant quite easily
… consuming is different
… thanks Siemens for contracting Cristiano to make the gateway TD compliant
… we have drafted a plan
… I have created a PR for the repo to add the slides
… these are the links for issues
<sebastian> find all issues here: https://
Ben: I have also submitted feedback for the profile TF
… also this week I have reviewed the discovery spec and I have provided feedback
McCool: we had some work on the additional and error, did you check that?
Ben: yes I have been following those discussions
… error and additional responses are in a good direction since they are needed for describing the full API
McCool: maybe there should be a testbed for these dynamic resources
Ben: TDs cannot describe collections of resources
<kaz> ek: wondering how the data consumption is done
Ben: making the WebThings W3C compliant is the question here
… (shows the WebThings Gateway diagram again)
… adapters communicate on the backends
… the individual adapter communicates with the backend
Ege: if I have a Zigbee device, should use some specific API?
Ben: you can use some Thing Description for that purpose
Ege: in that case, why there is compatible problem there?
Ben: good question
<mjk> We have a TM which was converted from the OneDM model for a Zigbee Level cluster?
Ben: the gateway may bridges some local network and the Internet
Ben: so the gateway consumes WebThings in the network (via Thing URL adapter) and this follows the WebThing API. This requires each adapter to adapt to this
Sebastian: I am very happy to see that Webthings will be also using TDs
... what do you think is the best way to approach the 3rd party library developers
... for the python I know someone who can have a look
Daniel: can the third party libraries stay behind?
Ben: They can but this will be a breaking change and we want all users of the gateway to upgrade timely
Kaz: thank you for considering compatibility with TDs
... we should work on a best practices kind of guideline together and clarify which entity uses what data models and interfaces
McCool: thank you for the presentation and guiding this
T2TRG
<McCool> Agenda
<McCool> Minutes
McCool: sadly Ari, Carsten or others from the group could not join this call
... the main outcome was Koster's working on converting ASDF <-> TD converter
... (shows website of IETF meeting on ASDF)
... I did a WoT update session
... trying to put a table with a taxonomy
... I need to get together with Koster and Milan to continue on this work
Koster: you can have a TM for a zigbee device that doesn't have network addresses
<sebastian> sdf-2-TM tool: https://
McCool: there is another paper under review about iot edge challenges Secure IoT Bootstrapping: A Survey McCool: I gave feedback on removing some words like "Configuration" from the IoT bootstrapping analysis Koster: we have finalized ASDF and have draft 5 which is a stable release for implementations Koster: we can create TMs from SDF definitions McCool: for ben, maybe you can take TMs instead of TDs for integrating into the gateway Sebastian: regarding edge discussion, was there any discussion on edgex foundry? McCool: that is a completely different project, like webthing
... next on bootstrapping terminology
Ben: I need to look at onedm
... Have you tried zigbee definitions with physical devices?
... there is another project called "zigbee2mqtt" and the community did an amazing job of classifying zigbee devices
Koster: onedm will help with defining new zigbee devices
... bluetooth is also onboard
Ben: we have capability schemas on our repository
Koster: we were lagging behind with oneM2M
... regarding iotschema.org, we talked with Dan Brickley. They will not be merged. They want to focus on datatypes and not interested in affordances
Kaz: after onedm bringing sdf idea to ietf, is this repository still used by onedm?
Koster: mk: we will also have our CI tool so that you can use it in your own repos
echonet
-> Matsuda-san's slides tbd
Tetsushi Matsuda (tm)
Tetsushi: I am representing Hirahara-san
... who is the liaison contact from ECHONET
... each device is described via properties
(tm shows the structure of the ECHONET Lite Web API Guidelines)
Tetsushi: devices are modeled with property, action and event as in WoT
... there are read status, control and notication funcitons
... notify function is like observable in WoT
... you can define a group of devices and client can set them with one API call
... the cloud can do the individual requests
... it is also possible to implement historical data in servers. The client cannot ask for the recording to begin but can read historical data
... we also have guidelines for the API such as HTTPS, HTTP 1.1, json, utf8
... For INF (notification) it is desireable to support push notification mechanisms
... echonet specifies websocket, MQTT and longpoll
<McCool> ok
Tetsushi: differences with WoT
… syntax, ...
McCool: would extend the meeting by 5 mins to finalize the discussion
… interested in the "grouping" functionality
Sebastian: thank you for the nice presentation and comparison to WoT. how do you realize eventing
Tetsushi: we use longpolling, websocket, mqtt and webhook to implement eventing
<Ege> https://
Sebastian: is there no form data in the device description?
<McCool> (right, so it seems the URLs etc. are implied by the property name, etc)
Tetsushi: since we support only http, we simplify the device description and do not include binding templates
<Zakim> kaz, you wanted to ask if "getting the list of devices" is kind of discovery and to ask if there is any specific API to group multiple devices and to ask what the data model for history is like
Kaz: wanted to ask (1) if "getting the list of devices" is kind of discovery and (2) if there is any specific API to group multiple devices
<McCool> (so discovery starts with the hub URL, where you can get list of devices, and also devices by type, but there is not a general content-based query mechanism)
Tetsushi: regarding grouping, the client can define a group of devices with some expected actions
<Zakim> dape, you wanted to bulk actions revoced if one action fails?
Daniel: regarding the href, a WoT thing can choose to that kind of hierarchy but does not have to
Tetsushi: if the transaction succeeded, you'll get the new property value back from the device side
(=equal to the set property itself)
Daniel: regarding the bulk operation, what happens if one does not turn on? do you notice it somehow?
... what if we turn on several lamps at once and part of them failed?
... it is best effort
... the client can identify if the action failed
<Ege> https://
Tetsushi: the client can get a history object
Ege: question on hitory
<McCool> (we have to wrap up though... so I'm going to have to close the queue and ask for next steps)
McCool: would like to have a follow-up call, e.g., during the Use Cases calls
… can you join the Use Cases call?
Tetsushi: yes
… but the liaison procedure on the ECHONET side is still being discussed
Kaz: will talk with them again about that
McCool: ok
Sebastian: also would be great if ECHONET can join the upcoming Plugfests
McCool: yeah
… that would be in October
Ege: wondering if there is any API publicly exposed?
Tetsushi: no
… maybe could provide something for the WoT guys for Plugfests
… but need confirmation from the ECHONET org
Wrapup
McCool: Discovery on Wed
[adjourned]