Meeting minutes
Scribe
kaz and tbd
Agenda
McCool: (goes though the agenda slides)
… ECHONET, SDW, break and Netzo
Guests
McCool: please be aware of the W3C Patent Policy above
… also the minutes will be publicly published
McCool: resources
… Wiki and Presentations
McCool: please upload your slides there
… PDF preferred
Guests' self intro
Arturo: Arturo Romero, CEO of Netzo
… Miguel and Gabriel also from Netzo
Ota: Hiroshi Ota from Yahoo Japan
McCool: Van_Cu_Pham from ECHONET
Yamaoka: Takio Yamaoka from Yahoo Japan
ECHONET
Matsuda: tx for giving this opportunity
… ECHONET Consortium Liaison Activity
… Agenda
… liaison acitivities
… plugfest results
… mapping ECHONET Device Description
… starting with Liaison activities
… Use Case Proposal
… Leaving and Coming Home
… (goes through the ECHONET use case which is already included in the Use Cases draft)
… Plugfest
… provided four ECHONET Lite devices
… via intermediary
… LED, air conditioner, illuminance sensor, temperature sensor
… developed by Pham-san
… Plugfest Results (1)
… Hitachi connected to the Echonet devices using Node-RED
… Fujitsu also connected using their local proxy
… TUM also
… Plugfest Results (2)
… Toumura-san raised some issue
… on direct access to the ECHONET Lite Web API
… for this plugfest, we access ECHONET device via a gateway, though
… by adding the encapsulating object schema, it might be possible to accept it directly
… that proposal can be an option
… however, not sure how to handle the value combination, e.g., "rgb"
… the real property value is "r" something, "g" something and "b" something
… Mapping ECHONET Device Description to TD
… Example: General Lighting (1)
… DD on the left side and TD on the right side
… binding template is additionally generated for TD
… e.g., "op" with "readallproperties"
… Summary of mapping from DD to TD
… @context for ECHONET Lite Web API added
… "id" in TD generated automatically based on "deviceType" and "deviceId"
… "title" taken from "deviceType"
… HTTP message translation
… Read One Property
… WoT on the left side and ECHONET on the right side
… translate the target path if needed
… read request, read response
… then
… write request, write response
… translate the target path if needed
… translate the HTTP body to property/value pair
… then return empty HTTP body with code 200 OK
… ECHONET has updated property, though
… Summary of the HTTP Message Translation
… target path of read and write request is translated if needed
… ECHONET Lite Web API reads response HTTP message body
… thanks
Sebastian: tx!
… question about slide 8
… payload structure
… "PlugFest Result (2)"
… client requests the RGB value
… and the question is how the payload structure is like
… similar problem with Philips Hue as well
… what can we do using TD?
… subprotocol problem or binding template problem?
… we need to clarify the situation
… and then improve the specs
Matsuda: personally think it's issue with binding templates
… using sub protocol might be a feasible option, though
McCool: agree we definitely need clarification
… my question is about p9
… Example: General Lighting (1)
… issue about the ID
… this time "echonet" prefix is used
… need some clean up
Matsuda: tx for your comment
… I appreciate it
… no detailed discussion how to generate the ID
… so this is just an example
<mjk> I'm confused by the payload issue. Why is { "r": 20, "g": 200, "b"10 } acceptable where { "brightness": 80 } is not
McCool: my second point is, should the "id" be always a URL?
… that's rather a question to myself
Ege: tx
… very detailed
… payload on p7
… schema problem?
Matsuda: this was proposal from Toumura-san
Ege: highly undesirable for an intermediary to process the conversion
… counter requirement for interoperability
… put the full schema
… for consumer to consider
<cris> +1
Matsuda: yeah, that's right
… ECHONET Lite Web API's Device Description describes {"r": 20, "g": 255, "b": 0}
Ege: what part of the properties to be converted is handled by the Binding
Matsuda: thanks to Toumura-san, we've noticed this issue
Kaz: we should continue to think about variety of property structure from existing standards
… should look into existing mechanisms and then think about how to solve the problem
Lagally: Oracle Cloud IoT platform
… also handled RGB mapping
… encoding the structure into property combination
… so this is my second time to see this issue
… we should this as one of the specific examples to solve the issues
… would agree we need to solve this specific issue of encoding a rgb color in the TD
Koster: tx for ECHONET to participate first :)
… potential endpoint for WoT
… great presentation
… need discussion for this issue
… my assumption is data schema part of TD is on the wire
… agree the problem is a long-standing one
<mlagally_> ./property combination: rgb_r, rgb_g, rgb_b/property combination: rgb_r, rgb_g, rgb_b/
Koster: information model
… we do need to have a sort of abstract data schema
… unbound way
… and another wired schema
… maybe protocol binding used for the conversion
Matsuda: thank YOU for your comment
… defining schema in abstract format?
… and another wire data schema
… that is the purpose of the binding. right?
Koster: data schema was part of binding originally
… but getting another view
… semantic schema never changes but protocol schema could change
Matsuda: I see
Ege: ECHONET can write a binding template?
<cris> I like mjk proposed solution. +1 we already have schemas on forms with additionalExpectedResponses
Matsuda: can't answer right now
… need discussion on the ECHONET side
… and would like to continue via the liaison
Kaz: we should simply ask matsuda san and ECHONET to work with us to improve the Binding Template Note
Ege: ok
Matsuda: let's continue the discussion offline
Kaz: ok
McCool: should wrap up
… seems SDW group has issue on WebEx connection
… so would suggest we take break earlier
[10-min break]
TD issue based on ECHONET discussion
Ege: would create a TD issue unless somebody else would
McCool: go ahead and put the URL here on the IRC
SDW collaboration
Jeremy: Jeremy Tandy, the Chair of the SDW group (co-Chair is Linda)
… collaborating with OGC
… Scott and Linda also here
Linda: Linda van den Brink from Geonovum
… member of W3C and also OGC
… chairing the SDW group with Jeremy
… Scott, you can also introduce yourself
Scott: Scott Simmons from OGC
Jeremy: a few more people from SDW
Bill: Bill Roberts
… very interested to here
Peter: Peter Rushforth
Rob_Atkinson: Rob Atkinson from OGC
Joost: Joost van Ulden
Note for guests
McCool: please be aware of the W3C Patent Policy
Spatial Data on the Web and WoT Geolocation
McCool: (shows the slides)
… WoT working on discovery as well
… including geospatial discovery
… want to integrate with the existing standards
… and include best practices
… use cases are smart cities, smart homes, automotives, etc.
… geolocation data to cover various use cases
… include data description or getting that from the device (or both)
… Geolocation Project Report
… geolocation requirements have been discussed
… encoding of geolocation data. also issue with query
… creating a group Note
… how to encode and use geolocation data for WoT purposes
… develop a working document
… presentation on Monday, Oct 11 about smart building
… also requirements from Singapore
… we need to collaborate (with SDW)
… Collaborations Needed
… concrete set of recommendations needed
… Next Steps
… some proposals myself
… but would ask the SDW group for advice
Jeremy: bring the people working on the topic into the loop
… key initiative in the geolocation area is OGC API
… how to interact with geospatial data
… covers query
… common features and records
… are you aware of that work?
McCool: yes
… the question is we have our own discovery spec
… which part to be reused/imported?
… we need to capture the plan
… my hope is basic discovery for WoT first during this charter period
… and the question is do we need informative thing first?
… other things also going on
… and wanted to ask you
… in addition to OGC, IEEE P287 working on geolocation, time series data, interval queries, etc.
Jeremy: yes
… time and space together
McCool: acceleration, velocity, etc., are not well handled for robotics, etc.
… alignment with the existing W3C specs would be good
Jeremy: Scott, you've been involved in IEEE, ISO, etc.
… any other touch points?
… identifying some common patterns both in WoT doing and OGC is doing
… aim converge at some point
… thinking about same query, etc.
… any ideas from SDW?
ss: OGC APIs and the features
… convenient API to handle data
… but if there is some existing work on the WoT side
… would see that
… bigger convenient API may or may not be usable
… would see the intersections
McCool: we have discussion on descriptive vs prescriptive
… big problem with IoT is out-of-box interoperability
… would have recommended practices
… but what are those recommended practices
ra: Rob Atkinson
… bunch of different points
… different aspects of interoperability
… distinction among methods for bunch of stuff
… exact same sensors should work the same, but what if put in different locations?
… collaboration with WoT, starting with the data
… another aspect
… commonality of implementation
… a profile of SSN for WoT purpose may be useful
… and finally
… where the touch point is?
… have to work on interoperability across different platforms
McCool: yeah
… might have particular use cases
… and put some common one
… on the other hand, would get a bigger picture for the next step
… we're looking at JSON-LD for vocabulary extension
… also experimental extension for JSON
… would figure out some compromise
… issue of encoding for the short term
… and then privacy concern
… need to figure out possible solutions
Jeremy: we have a group preparing for a Note
… bunch of work in hand
… looking at privacy issues
… in terms of starting with small part
… encoding geolocation data using JSON-LD?
McCool: yes, JSON-LD
… specifically WoT Thing Description based on JSON-LD
… data schema for actual definition
… how to unify the things for queries
… struggling with that
<RobSmith> Responsible Use of Spatial Data: https://
McCool: still a proposal
Jeremy: query pattern
… you're using
… smaller part of the building block
… about semantic alignment of WoT and Spatial world
… wondering if Rob can give description on his work about GeoPse
McCool: we need a structure
… how to address the problem
… (shows an example TD)
… responding with position property
… including longitude, latitude, accuracy and accuracyUnit
… making things modular
… and pieces to be combined
Jeremy: something Rob Atkinson is also working on
McCool: @context has geolocation vocabulary
Rob_Atkinson: we might want to use the context of DCAT
… scalability issues there?
McCool: you could have other sub namespaces for geolocation ontology
Rob_Atkinson: schema.org, etc., changes everyday
McCool: we'd like to find some ontology to be imported
… that's the theory of @context within TD
… there is also privacy issues
… when geolocation is exposed
Rob_Atkinson: would imagine semantic annotation to be added
McCool: downstream implementation should assume fixed items
… still need to spend time to see the OGC specs
… also WoT to capture their use cases
… and see requirements for geospatial data
… we (WoT WG) have to write an updated Charter
… actually, we have both WoT-WG and WoT-IG
… our WG recharter may request a 6mo extension
Jeremy: what's the right way then?
… normative recommendation on this topic?
… what's the risk and impact?
… identifying one or two key SDW communities would make sense?
… any thoughts from SDW?
Linda: OGC experimentation would be useful
… collaboration on some specific topic
… joint session between WoT and OGC
McCool: due to COVID situation, our F2F schedule has been changed
… purpose of project is clarifying the issues
… use the concrete example for further discussion
… map for territory, etc.
Jeremy: an opportunity to leverage WoT machinery using Plugfest and OGC?
McCool: make sense for IoT geolocation
… what would be the next meeting?
… maybe early next year?
… e.g., February
… for the sprint dash
… let me reach out by email
Kaz: for the next step, I'd suggest we define one specific core use case
… smart city is OK, but some concrete core use case would be useful
… and think about our identifies issues based on that use case
… also we should learn our generated specs with each other
McCool: would capture the points on the GitHub issue as well
Jeremy: can share my notes as well
… let me ask if anybody in the OGC space have any other points
(none)
Jeremy: linda, what about you?
Linda: nothing
McCool: who is the right person as the contact point?
Jeremy: Scott with Linda and myself
McCool: ok
… thanks a lot for joining this call!
(SDW guys leave)
<RobSmith> OGC GeoPose seems relevant to location with orientation issues for WoT: https://
Netzo
Ege: Introducing Netzo
Arturo: Introducing Netzo
… We are three brothers
… from mexico
… We moved to Munich
… studied in Germany
… The problem of IoT today is that it is fragmanted with not interoperability.
… current solution are siloed, lacking unified interface
… or are very expensive
… How does Netzo solve this?
…It does this by unfiying IoT of software level
… We now introduce the Netzo Platform
… It is an application enablement platform
… Getting started with Netzo is easy
… It allows adding things
… or simulating them just by having their TD
… A TD can be added either by writing it from scratch, by creating them from TMs, importing them or discovering them
… Netzo creates multi-Thing Dashboard, allow sharing and more
… How does Netzo look like?
…We offer an IDE
… drag and drop widgets for value visulaization
… viewing the WoT API etc.
… Our roadmap:
… enroll early adopters
… aquire beta testers
… create a community
… then promote
… we will begin with a private beta in November
… we ask you to apply with the link we will provide
… early adopters are forerunners and gain a say in Netzo
… and therefore get an advantage
… We reached the end of the presentation
… For applying to beta test please visit https://
Ege: Thank you for presentation Arturo
Kaz: Thank you for presentation. Do you have trouble with WoT standards, either v1 standard or v1.1 draft?
Miguel: To understand your question correctly, are we having trouble with the context?
Kaz: I mean did you have any problem understanding v1 standard when you implemented your implementation?
Miguel: We do not have problems with understanding the standard
Miguel: We still did not implement it.
Miguel: The marketplace now has 3 types of plugins, and more can be added and can be monetized
McCool: There are no orchestration plugins. Do you intend to implement orchestration plugin?
Miguel: We intend to implement something like this, we call it scripting
Christiano: I was wondering, how much of this is ready to be tried in the beta?
Miguel: All the things that you saw in the screenshots are already implemented. You can expect everything to we presented in beta state by the middle of November
Daniel: Is the basis for some of the things in Netzo in node-wot? Are you contributing to node-wot?
Miguel: We use it internally, yes and fully embrace it
Ege: What kind of limitations do you see in node-wot?
Miguel: We see node-wot lagging a bit behind in features
Kaz: Your system is like an emulation platform. What types of devices be used with it?
Miguel: Any device that can use the protocols in node-wot can be emulated
Kaz: in that case, would suggest you join the Plugfest next time :)
Miguel: happy to :)
Yamaoka: why did you choose WoT as your platform?
Miguel: We tried many things, but we heard about WoT we knew it was going to solve the problem we want to solve
Ege: Is it possible to do a live demo?
Miguel: We are not prepared to do it now.
Ege: For me it is fine, but I thought it would be nice to show the others
McCool: We can schedule a live demo
Miguel: We would love to do that
McCool: We can schedule a meeting, let's discuss this offline
Sebastian: Thank you
for presentation and it's nice to see what WoT can be
… Please join our plugfest so we can test your
system
Arturo: We are reaching
our release date, that's why we want to hear your feedback
… and start a joint collaboration
McCool: What is your first feature you want to finish?
Arturo: Bring data to the platform, to see them in the platform
McCool: you mean live data?
Miguel: Yes. And fill a dashboad with widgets with live data
McCool: The queue is
empty
… you have a contact already, Ege
… you should continue working
… and tell us about any issues you
encounter
… so that we can address it
… anyone else has further comments?
… I see no one else in the queue
AOB?
McCool: next week there are two breakouts
… Smart Cities organized by Kaz
… The edge-computing breakout is new and is on Friday
… I am trying to figure out my schedule for next week
… we are going to cancel architecture and profiles
…we should track down the breakouts next week
… Kaz, do you have an update regarding breakout?
Kaz: let me see
… Smart Cities breakout session on Oct 18 at 15UTC and Oct 21 14UTC.McCool: Are there any
other breakouts?
… Kaz, do you know when the voice interactions one
is?
… I will look it out
Kaz: Is it ok to put the link in wiki even when it is protected by password?
McCool: It should be working
Kaz: my point is so far the W3C Event Team has not put the actual CVent link on the public pages, so maybe we should also avoid putting that on our public wiki
McCool: Next week will have to wing it. Are there any organization matters for next week?
McCool: Let's assume the editor's call will happen as planned (6 am eastern)
Kaz: will distribute a doodle poll to find a better slot soon.
[adjourned]