WoT Open Day - Day 2

Scribe

kaz and tbd

Agenda

McCool's slides

McCool: (goes though the agenda slides)
… ECHONET, SDW, break and Netzo

Guests

W3C Patent Policy

McCool: please be aware of the W3C Patent Policy above
… also the minutes will be publicly published

McCool: resources
… Wiki and Presentations

vF2F wiki

presentation area

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

ECHONET's Slides

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

wot-thing-description issue 1251

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 Smith

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's slides

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://w3c.github.io/sdw/responsible-use/

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

Joint call with SDW #981

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://www.ogc.org/projects/groups/geoposeswg

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://netzo.io/private-beta-signup

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

Do you implement the WoT Discovery spec?

Miguel: We still did not implement it.

What was your open source strategy?

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