See also: IRC log
<inserted> scribenick: kaz
mk: this is a joint meeting of
the WoT IG and the WoT WG
... the first meeting for the WG
... it's open day today
mm: host and another co-Chair
mk: third co-Chair, Kajimoto-san
from Panasonic can't join this meeting in person but will join
remotely
... Yongjing Zhang, the co-Chair for the IG also will join
remotely
... (shows "W3C WoT Mission")
... (Semantic Metadata for Interoperability)
... communication between platform A and platform B
... designing simple interaction model
... essential elements: properties, actions and events
... all the information described by TD (=Thing
Description)
... the challenge is protocol
... HTTP, CoAP, OCF CoAp, OneM2M CoAP, etc.
... how to configure them and let the other side
understand?
... (Binding Templates)
... (Simplify Application Development)
... (Scripting API)
... (Portable Apps Across Vendors)
... (Across Components)
... from gateway to cloud
... (TD to Augument Existing Things)
... get TD from TD repository
... (W3C WoT Building Blocks)
... WoT Servient
... has both server/client capabilities
... WoT Scripting API
... WoT Thing Description (TD)
... WoT Binding Templates
... Security&Privacy
-> http://plugfest.thingweb.io/ Plugfest.thingweb
-> Project Thingweb@@@
jh: (WoT Architecture)
... Scripting API
... Runtime Environment
-> http://w3c.github.io/wot/current-practices/wot-practices.html#quick-start-td-samples Example 1
jh: shows Example 1 and then
Example 2
... (Feedback(1): Client side)
... can a ConsumedThing instance be narrowed to a single
protocol?
... which protocol to choose if several are availabie?
... is there a use case for using different ones for each
call?
... would I ever retriee the TD from the Thing itself and then
use a different protocol to access it?
... why is Mediatype (serialization) on link and model
(valueType) on interaction?
... (Feedback (2): Thing lifecycle)
... another feed back is lifecycle
... we have addXYZ but we need also removeXYZ
... we can create but not delete Things
... we can create but not retrieve existing ExposedThings
... where does the WoT object originate (global?
require/module)?
... (Feedback(3) Accessing local Things)
... discover gives me a ConsumedThing, how do I retrieve an
ExposedThing from my runtime?
... (Feedback(4) Security and scoping of scripts and
things)
... Things have a place, a servient where they are hosted - how
about scripts?
... Isolation: can I access exposed things on the local
servient "priviledged"?
... Assumption made: scripts are sandboxed, they do not share
global scope but sahre the local ExposedThings
... (Feedback(5): Multi-protocol)
... Resource structure: the same for all protocols?
... Or: is there a resource for each thing and each interaction
and the protocols assign there specific URIs?
... Current assumption: rules to convert (Thing, Interaction)
_> URI
... Protocols and Media Types are now on interaction level -
why not thing level?
eve: : use case of driving?
jh: so far a gateway use
case
... edge processing, local control and back-end
processing
... huge variety of edge level devices
... main use case driving our discussion
austin: ConsumedThing vs ExposedThing?
jh: I expose thing to share
service
... consume is using service
mm: one way to use HTTP esp. for
events
... more than protocol than HTTP?
jh: thoughts about that
... exposing thing is some way of data analysis
... decoupling actual device from the data
... you could use multiple protocols
... so far focused on Node.js but interesting to see other
implementations
@3: optional type of script?
jh: shows
github.com/thingweb/node-wot.../consumed-things
... based on promises
peter: proper ECMAScript 215?
jh: possibly
dsr: thinking about generalizing
TD
... security, access control, business use cases, etc.
... more heavy use of linked data
... people could use the same protocols for different uses
fr: (Success criteria for
WoT)
... which kind of requirements are needed from an
implementation perspective?
... (We are a global leader in wind energy and operate; More
than 3100 MW of renewable capacity)
... (Future oriented products and services)
... decentralized IoT
... decentralized energy solutions
... (What if the complete genetic material of a human being was
stored in a single cell?)
... (A life, depending on the proper funcitonality of a single
cell, would be...)
... (With DNA ("the intelligence of life") ther eis a
decentralized control...)
... (Lemonbeat positioning in the OSI layer model)
... application layer: Lemonbeat smart Device Language "LsDL"
(XML/XSD/EXI)
... over HTTP/CoAP
... over TCP (for HTTP) and UDP (for CoAP)
... Network functionality: Lemonbeat Radio 868MHz, Long rage,
low power (LoRa Modulation)
... (How to make devices intelligent)
... Lemonbeat DNA structure
... all necessary services on board - in every device
... (How to make devices intelligent)
... Lemonbeat Chip: Silicon Labs 32-bit, ARM Cortex-M3 CPU
Processor; Silicon Labs SI 446x Tranceiver
... Flash memory inckuding Firmware, Stack
... Lemonbeat Studio: access to all devices, Initial
implementation, Updates flash memory, 99% offline
... (Use cases for private households (B2C - Micro
level))
... smart energy can be linked to eMobility and Smart
Home
... Tesla Model 3, Chevrolet Bolt (EU: Opel Ampera-e,
Aauxhall), Mercedes EQ
... (Use cases for private households (B2C - Macro
level))
... a cluster of power storages in a decentralized use
case
... (Self learning mechanism on field level (1))
... (Self learning mechanism on field level (2))
... (Self learning mechanism on field level (3))
... authorization
... (Benefits of an integrated Web of Things)
... the use of primary devices is benericial for WoT
... (Benefits of an integrated Web of Things - contd)
... benefits of integrated WoT
... use of primary devices leads to a cost reduction
... (Increasing total integration and value of all components
of a network)
... devices as a data supplier, gateway with central
controller
... devices as a data supplier, primary device includes virtual
proxy
... network of autonomous devices without central control
... network of autonomous devices without central control, self
learning mechanism on field level
... network of autonomous devices without central control,
complex self learning mechanism
... (Alternatives for WoT)
... device to device communication
... options: physical gateway, virtual proxy, light WoT
stack/full WoT stack, small WoT stack
... (Alternatives for WoT - contd)
... a power supply company ofers its customers power storages
in different versions
... (Findings from Silicon Valley companies and pioneers)
... in each network, the benefit increases for all
participants, when adding new participants
... the vlue of a telecommunications network is
proportional...
... (Feedback "International VDI Conress on IoT" 14.12.16 -
Berlin)
... how intelligent devices can enhance IoT
... (Feedback "IoT Tech Expo" 23.01.17 - London)
... (Suggestion: Adding these options to the WoT
architecture)
... (1) Thing to thing interaction without gateway:
... (2) with gateway
jh: two different kind of WoT
stacks
... what is the main difference?
fr: covering a lot of
devices
... can speaking with constraint devices using light-weight
WoT
... full-spec vs light-weight
... my best choice is light-weight WoT
moh: energy area?
fr: decentralized energy and IoT
moh: there is some active device
zk: can you configure 2 different services at once?
fr: we have one generic
protocol
... if you want to use different use cases, you can use the
lemonbeat chip for those use cases
... we could combine different things
zk: different protocols have
different provisions for security
... do you have enough computing power for various
provisionings?
mk: kajimoto-san is the editor
for the architecture document
... you proposed via gateway communication
... that's already included in the architecture doc
fr: talked with Kajimoto-san several times
mk: e.g., they have gateways for
ECHONET
... abstraction for them as well
mm: document now on GitHub repository
mm: OCF Overview and
Collaboration
... Open Interconnect Consortium + UPnP + Electrolux,
Microsoft, Qualcomm + Allseen Alliance = Open Connectivity
Foundation
... working on new standards
... sharing public resources today
... (OCF Basics)
... defining data model
... 4 main things: OCF Specification, oneIoTa, IoTivity Open
Open Source, OCF Certification
... (OCF Goals)
... easy for developers, interoperability, future
consolidation, multiple vertical markets, scalability
... (OCF Goals - Implications)
... (OCF & IoTivity)
... 2 different organizations: OCF and Linux Foundation
(IoTivity)
... (OCF - Conceptual Framework)
... Resource Model & RESTful Interactions (RAML)
... Discovery, Provisioning, Comms
... security, identity & permissions
... Transports: cable connection, wifi, zwave, bluetooth,
...
... (Accessing Resources over the Network)
... Application of Service - Resource Model & RESTful
Interactions
... (Some Details)
... I'm happy to talk with you about OCF
... Michael Koster is also available
... Interaction model based on CLUDN
... traditional web type of API
... request-response and publish-subscribe
... we can't mandate what devices do
... Data models are defined using RAML
... Standards status:
... only OIC and AllJoyn standards are currently public
... Current IoTivity release supports OIC 1.2
... OCF 1.0 standard is under development
... OCF 1.0 standard will merge features of OIC 1.2 qnd
AllJoyn
... Bridges being developed to allow access to OIC and AllJoyn
devices from OCF
[ morning break ]
<dsr> scribenick: dsr
Presentation about the ongoing work on [Henry Andrews] JSON Schema: status and outlook
A series of drafts with draft 6 in final review in February 2017
Currently tidying things up and getting ready for a release
We now require references to be to whole schemas
We also now have more uniform treatment of terms that start with $ e.g. $id
Finalizing media type registration for IANA
Most of the validation keywords are stable, but we've added a few new ones.
We considering support for limited conditionals.
Hyper-schema is under active development.
This is about adding hyperlinks to JSON.
We're not trying to compete with other approaches, e.g. JSON-LD
We're looking into a UI schema for JSON, but this is at a very early stage
Another idea is to consider metadata keywords for document generation.
We expire our drafts after 6 months (like the IETF) and want to ensure that our working documents are updated in a timely fashion.
We plan to prove hyper schema with some automated user agents.
A some point we want to roll over into an IETF working group.
We're using URI templates.
Daniel: are there any plans to specify semantic properties, e.g. age in years?
Answer: so far no, there are other approaches that are better suited
Matthias: there are some mechanisms in JSON-LD for semantic links.
Driving the design through semantic vocabularies is a valuable approach to take
Sebastian: we want to build upon existing vocabularies where practical
Another consideration is suitability for resource constrained devices, is this something where we might collaborate on?
Henry: we're open for adding new keywords but less so for changing existing stable keywords
In particular, if you could point to where JSON schema proved difficult for some use case, we would definitely like to hear about that
We can express CBOR more or less, and am definitely interested in further discussion.
Greg introduces himself. He is one of the co-editors for the JSON-LD spec
I want to talk about the change requests we've had and are considering for JSON-LD 1.1
An October 2016 common crawl revealed extensive use of JSON-LD
Some of the topics we're looking at include collections and hypermedia API
A design goal was to allow JSON developers to use Linked Data as regular JSON
These developers focus on accessing the data and not on RDF
We use @context as an object property that maps names to RDF concepts
It also enables us to describe the type for string values, e.g. IRIs, dates, numbers etc.
Arrays are treated as unordered unless otherwise noted.
We encourage the use of @id and @type for identifiers
JSON-LD has some core algorithms, e.g. to use the @context to expand terms to full IRIs
We expected a common use case would be canonicalise terms via an expand and compact steps, so we're strong on round trip without changes
Gregg and Matthias discuss some examples
We're trying to make objects easier to find using different keys
This makes use of @container together with @id within @context.
We want to make it easier to do a good job when mapping from RDF to JSON-LD via a document frame
We're addressed nested properties via a new keyword @nest
JSON-LD 1.1 adds support for scoped contexts with a means to implicitly insert @contexts.
The work is happening in a W3C Community Group. If there is sufficient interest, it could morph into a Working Group for an updated W3C Recommendation.
We're hoping to complete our CG drafts in Q2 2017
No C implementation, so volunteers are welcomed!
But the changes are easily applied to existing implementations, e.g. Python, PHP, Java, C# and Go
Today, only one implementation fully supports the CG spec (Greg's Ruby implementation)
Greg: RDF shape expressions could be interesting for JSON schema, and can be defined using JSON-LD
This pretty much allows for arbitrary validation of RDF graphs
Happy to talk about this tomorrow
scribe: we break for lunch and resume at 2pm PST
<kaz> [ lunch ]
UNKNOWN_SPEAKER: or what the Physical Web taught me about ecosystems
We have a huge vision for the IoT rather than just little devices.
The question is how we get there. We have some insights about the value for smart homes, but it can be a little underwhelming to explain.
[joke about digging through horse manure pile to find the "pony" that must be there]
Short story about a designer in Copenhagen who made a device that recognized when he put on safety glasses and turned the workshop grinder on and likewise off when he removed the glasses.
We are seeking to create a flexible platform
Video interview with Jeff Jaffe talking about the broader implications over time for the Web of things
Too many people are creating App store APIs rather than building blocks for everyone to build on
Scott says that too many people think that the Web sprang fully formed from TimBL's head - but it wasn't like that - Tim needed to find a way to share information across the heterogeneous systems at CERN
Back to the physical web. Having one mobile app you need to install for everything you want to do or to control doesn't scale
The location field at the top of the browser is like forcing people back to a DOS prompt when they've gotten used to high res color video
The physical web bypasses entering the web address taking you direct to the web app.
Rather than having an app per device, get the device to point to the web app!
People change the address (the beacon) the device emits according to the time of day and context
a 50 cent beacon could in principle be put into medicine bottles.
A video of a Bluetooth smart toy that embeds a beacon and can be controlled from a browser via the Web Bluetooth API
<scribe> New Bluetooth spec can allows you to scan for the set of beacons, causing the UX to change automatically as you walk around a store or museum.
We've been very pleasantly surprised by the awesome ways people are using the physical web
Beacons could also start to discover each other, e.g. via JSON descriptions.
IEEE Computer article on building a Lexus out of Lego.
(from Feb 2017)
The biggest problem we've had with the Physical Web are the onboarding issues for getting people up to speed, e.g. with security.
Right now adding a bunch of new devices to your home WiFi is enough to make you break out into a cold sweat
We've got to make enrolling new devices really really easy
So smart setup is key!
How can devices easily gain access to semantic descriptions, e.g. of the rooms in your house
So the semantic map is key!
We need standard descriptions so that devices can understand each other
We know that machine learning and big data are incredible. We need a way to pull data together from different devices into one place for that machine learning to take place. How can we tell devices where to send their data?
Some kind of middle layer for devices to communicate on
A first step is centralized data.
A further idea is centralized coordination - i.e. to be able to coordinate all the devices in your home.
"The best way to ruin your product's UX is to add security to it", that's because security is almost never fully thought through
My challenge to you guys is JSON+HTTP+JS = ?
Johannes: show the slide for the 4 points you have, can you expand ...
Scott: joining the network should be easy, and the device should at that time get information about the house and its context
I buy a new lamp, plug it in, and the nearest switch then controls it. This requires the house to learn about the new device and do something that is valuable and smart for me
Eve: How about a virtual centralized perspective, i.e. coordination rather than centralization
Scott: we want to see what happens when these semantic descriptions meet with the protocols
Dave: is this a re-run of the surprise that people find when they see freshly targeted ads, how do we avoid the uncanny valley/the spooky house?
Scott: we're already there!
Scott talks about the need to balance different human needs. We want this to evolve from simple actions.
Earlier Scott worries about the failures associated with spaghetti code
If we can have machines talking to each other with shared semantics then we can explore interesting emergent behaviors
Michael: distributed RDF database would allow queries across devices in your home
Scott: identity is a can of worms, it's hard ... can we avoid the battles it brings
Dave: its my home I can name
things the way I want (e.g. as for mDNS)
... there will need to be systems of authentication through
Johannes: can we split discussion of identity into the human level and the machine level for lower layers of communication.
Scott: I want to avoid not understanding why things behave the way they do, and to avoid rigid control rules.
Bruce introduces himself as an HP Fellow
Bruce reminds us of Mark Weiser's vision of ubiquitous computing from 1988.
We've seen shifts from mainframes (many people one computer) to PCs (one person one computer) to one person many computers.
Ambient computing involves computers supporting you in making intelligent, helpful decisions, and in the process disappearing into the background of our daily lives.
He shows a short video
Bathroom mirror with embedded display, voice interaction to help prepare you for the day ahead
In the kitchen helping with preparation of dishes
Keeping you on track and always present during your day
Computers weren't visible, and all the interaction was triggered by your natural interactions including spoken requests
Bruce talks about the security and privacy challenges
With smart surfaces, the systems need to know who is in eyesight or earshot
The systems constantly learn from your reactions to each situation.
We have a long way to go, but the Web of things is clearly relevant
Ambient computing is a re-emerging buzzword (Deloitte, Gartner, Microsoft, TechCrunch)
People will get used to instant answers to their questions.
Bruce shows some video of smart surface desktop concepts
Behaviors suitable at home can't be assumed to be appropriate at the office
Placing your phone on the smart surface, your phone is instantly recognized, enabling the surface to pick up where you left off
Casting, voice & audio, computer vision, gestures, smart layout, connectivity, sensors, security and hardware
Bruce summarises challenges to overcom
These include self power devices that are always on always connected, sensors everywhere require strong security, constant connectivity can lead to constant work which can be a drawback
We need to figure out how to ensure ambient intelligence addresses societies needs
Questions?
Any thoughts on monetization?
Answer: today everything is transactional, but everything you saw here, assumes commodity computing
We've found several paths to monetization, e.g. frictionless services
What kinds of ecosystem does ambient computing enable/require?
Bruce: we're going to partner
with companies for the solution spaces
... the operating systems will also be a commodity
This is a multi-device, multi-OS environment and there has to be interoperability
The OS is good at resource management, but everything on top of that is from an intelligent layer above
Don't you think that Microsoft, Apple and Google won't want to play in this area?
If you go to a Microsoft conference, all they talk about is services
Zoltan: are there one or more semantic spaces and how do they interact
Bruce: the difference between home and work is fading, you're probably better connected at home
The context will be different though.
Dave: we presumably need to work on human values and a shift to cognitive computing, how do you see that happening?
Bruce: we are exploring this through a number of different approaches.
This involves a major transformation and will require a major cultural change. We've been very selective about the standards group we participate in.
[in response to a question about HP as an original equipment manufacturer]
Some companies are entrenched and change will be forced upon them by "disruptors"
<kaz> [ Day 1 ends ]
<kaz> scribenick: kaz
mk: check agenda
... and WebEx logistics
<scribe> ACTION: kaz to allocate another WebEx for the breakout session [recorded in http://www.w3.org/2017/02/07-wot-minutes.html#action01]
<trackbot> Created ACTION-100 - Allocate another webex for the breakout session [on Kazuyuki Ashimura - due 2017-02-14].
mk: (WG Charter Feedback I)
... Scope:
... Make Thing Description the main deliverable
... TD work has priority in the case of conflicts
... RDF dependency:<br/>... don't reinvent a similar
framework
... don't make RDF a prerequisite
... Security:
... conduct security reviews before releasing WG doc
... include systematic security testing in the test suite
mm: do we hire outside reviewers for security work?
mk: one possibility is submitting an
internet draft and submit it to IETF
... IRTF T2T has joint meetings as well
... (WG Charter Feedback II)
... why a scripting API for interaction?
... we expect a REST API for Things
... go back to...
... (Scripting API)
... 2 different APIs: scripting API and WoT API
... Scripting API used inside the servient
... simplifies app development for the IoT using patterns from the
Web
mm: note that Scripting API is an optional feature for Servient
mk: WoT API for
interoperability
... (REST API)
... given by TD and its interaction model
... client-server, stateless, cache (tricky for legacy protocols;
patch through TD?), uniform interface, layered system,
code-on-demand
... similar elements: data, components, connectors
... (EVRYTHNG Web Thing Model)
... 4. Web Things Integration Patterns
... 5. Web Things Requirements
... 6. Web Things Model
... how does it compare to the current practices?
... (4. Web Things Integration Patterns)
... direct connectivity: WoT API on Things
... gateway-based connectivity: WoT API on gateway
... (4. Web Things Integration Patterns - contd)
... cloud - gateway - direct
(discussion on physical devices and its shadow on cloud)
mk: (5.1 Web Things
Requirements)
... R0.1: MUST use HTTP
... R0.2: MUST have Entry point URI ("root resource")
... R0.3: MUST support GET, POST, PUT, DELETE
... R0.4: MUST utilize HTTP status codes
... R0.5: MUST support JSON
... R0.6 --R0.1 (MUST support GET on it)
... note the "MUST"s above came from the Member Submission
-> https://www.w3.org/Submission/2015/SUBM-wot-model-20150824/ Web Thing Model Member Submission
(discussion on requirements for REST)
mk: (5.2 Web Things
Requirements)
... R1.1: SHOULD use secure protocol ("HTTPS")
... R1.2: SHOULD use WebSockets
... R1.3: SHOULD support [6.] Web Thing Model
...
... (5.3 Web Things Requirements)
... (6. Web Things Model)
... 6.0: Standardized relative URI paths
... 6.1: Common Constructs
... 6.2: Link to related resources
... 6.3: Values
... 6.4: Typed resources (allowed verbs and responses)
... 6.5: Semantic Extensions
... (EVRYTHNG Web Thing Model)
... (WoT Current Practices)
... mostly in line with the Web Thing Model
... evolved to: machine-understandable descriptions, multi-protocol
REST support
... hypermedia controls
(JSON-LD equivalent format for small devices, e.g., CBOR or EXI)
mk: in Montreal there was discussion on level of types
henry: looking at how put was
described
... within: https://www.w3.org/Submission/2015/SUBM-wot-model-20150824/
mk: our uniform interface is a bit
higher
... (Hypermedia-driven WoT)
... TD already as hypermedia controls
... links: readable property, see linking breakout
... forms: inputData for actions
... (Start Work on Hypermedia)
... Actions: response to invoke might need to describe interactions
on the created running Action, e.g., monitor, update, cancel
... Events: some events such as alarms might need interaction,
e.g., confirm, mark resolved
... Errors: error responses should provide interactions to solve
the problem, e.g., 401 unauthorized->link to auth server
... (Hypermedia Client)
-> https://github.com/t2trg/2016-03-san-jose/blob/master/slides/11-Kovatsch-2016-03-Interaction-Model.pdf pdf on github
mk: project of mine
... high-level browse path description to interaction resource
based on link relation types
... programming abstraction based on Futures/Promises
... entry point
... link relation type
... returns Future
... lazy evaluation of Future, not GET
(discussion)
mk: (Generic Process Relation
Types)
... detailed state machine and high-level state machine
... (Handle Change)
... control alternative things
... add new things
... still control old things
... also control future things
... (Idea)
... diagram of ideas
... programming abstractions?
jh: comment on hypermedia client
mk: we can extend the model based on this hypermedia model
henry: think it's something actually
working for WoT
... building a hyper media client
mk: think about use cases like
this
... would like to create a TF
... also work for error model
... report errors and recover from them
... overlaps between those two topics
dsr: overlap with semantic work as well
mk: next Sebastian?
<dsr> A thing description can be considered as an RDF graph with links to other such graphs. So for an RDF API you have a means to follow such links to access the linked graphs
sk: would like to go a bit
backward
... to make clearer understanding
... (WoT TD Basic Assumption)
... Servient1 using JS and Servient2 using C/C++
... S1 provides information and S2 consumes it
... S2 understands what S1 provides
... what is the core information of the TD?
... TD should be independent of any platforms and programming
languages
... reflect the core data model
... (JSON-LD vs TD Model)
... promising candidate for TD serialization
... quite human readable, good experience in plugfests
... (Inputs for the TD Information Model)
... (Tool?)
... what kind of graphic tools?
dsr: have some idea
sk: (TD (core) Model)
... Thing has name
(discussion on "name")
sk: (starts to draw a diagram on the whiteboard)
mk: would suggest we clarify the
basic pieces needed for implementations
... and then we can agree on the terms
... recommending bottom-up approach
mm: building a model based on use cases
mk: we can optimize the model but
don't have to use the whole RDF mechanism
... would like to summarize the discussion
... we go based on implementations using bottom-up approach
... the most important point is how many boxes are needed here
(=within the TD Model)
mm: we should write down requirements
dsr: we should look at existing specs generated by other SDOs, e.g., OCF
mk: we can see their implementations via liaison
mm: grounded with the PlugFest
results is important
... prototyping using RDF
mk: we have the Current Practices as
the starting point
... (draws a diagram of discussion cycle on the whiteboard)
mk: RDF prototyype => Serialization => Implementation => ER Model => RDF again
mm: like that
dsr: in addition, other SDOs' IoT platforms as well
greg: mentions importance of test suites
mk: (adds "Existing platform")
mm: wonders how to handle, e.g., OCF test suite
kaz: would it make sense to invite OCF guys and/or oneM2M guys to PlugFest?
sk: already trying, though...
mk: why don't we have a morning break now and calm down :)
<kaz> [ morning break ]
<scribe> scribenick: dsr
Matthias introduces the session and talks about JSON Schema
A discussion around the type system and which one should we choose.
Can we use an existing one or do we need to define our own?
Greg: in any case you should ground this in RDF.
<kaz> Type System discussion on GitHub
Matthias displays a table that has rows for different kinds of types and columns for different type systems, e.g. JSON schema, Schema.org, and so forth
JSON schema can be mixed into other frameworks, e.g. RAML
Specs for JSON Schema have been geared around having a media type
Matthias: the aim is to have a machine interpretable format, so that a servient can understand the data model types.
<kaz> 3.2.4 Type System from the Best Practices document
Interactions can be considered as web forms that guide how to interact with a remote server
Hyperschema covers both client requests and server responses.
Some discussion around REST APIs in relation to what is needed in the request and response.
Matthias: the thing description enables a client to know how to interpret the server's response.
In the WoT IG current practices, we have used JSON Schema to describe the structure of the data in the requests/responses.
Greg: one of the reasons for using URIs for naming is to allow you to dereference them to get further information.
Time for thinking about how to evolve JSON schema to better support the increased level of interest in Linked Data and JSON-LD
Matthias: the recent discussion around iot.schema.org sounds promising.
Its great to have people from the different groups here today, and it would be great to continue this remotely (some discussion about number and timeslots for telecons)
Matthias: we need to be careful to avoid tying the data models to the serialization formats
Sebastian shows a slide where JSON Schema is used to link to an external model (modelReference)
Some issues around use of "properties" and potential role of scoped contexts in JSON-LD as a work around
<kaz> BIG IoT EU Project
Sebastian shows an example from the EU project BigIoT which he is a part of
MichaelK: I've seen "describedBy" rather than "modelReference".
Greg talks about having a document being both JSON-LD and JSON-Schema
Both specs need a namespace for their core concepts. In JSON-LD is is common to alias terms beginning with $, except for @context where must use the term as is.
The $id in JSON schema does provoke a lot of discussion as it can be a little confusing
There is a means to set the base URI when combining several schema into one document.
MichaelMc: We can used JSON-LD's scoped context to only apply some aliases within the scope of a valueType object.
Greg and Henry agree to further discussions on avoiding conflicting identifiers in JSON-LD and JSON Schema.
JSON Schema exists to describe the structure of a document, whereas JSON-LD exists to express Linked Data in JSON.
They therefore serve different purposes and are complementary.
Greg: it would be interesting to use JSON-LD to embed annotations into a JSON Schema description of a JSON document.
Matthias: for thing descriptions
we have requirements where both JSON-LD and JSON Schema are
relevant.
... we will have the security break out at 13:30 PST
<kaz> [ lunch ]
Zoltan introduces the session, starting with a review of security in OCF.
A platform can host multiple devices, and a device can host multiple resources.
Security is needed for connectivity, discovery, access control and device management.
Each device as a globally unique UUID that is validated by OCF
Access control is granted on the level of the device resources
The access control information is held in secure storage.
All requests are passed through the OIC resource manager.
Security bootstrapping is complex: on-boarding, provisioning and configuration are defined by OCF.
Configuring resources and provisioning cloud services are application specific.
OCF hasn't discussed how to provision cloud based services.
OCF devices may act as clients and/or servers.
Access control lists are held in the server or in an external resource.
OCF on-boarding involves a transfer of ownership, which entails anonymous key exchange using the Diffie-Hellman algorithm.
Alternatively, you can use a clean room transfer (to avoid man in the middle attacks)
Or you could use a second channel, e.g. NFC or Bluetooth
Provisioning deals with certificate exchange.
This is followed by a configuration step.
Message integrity is based upon DTLS over CoAP, along with JSON Web Encryption + Web Signatures.
What are the prerequisites for the Web of things in respect to security?
Is on-boarding and provisioning in scope for the web of things, or are these something specific to the given IoT platform?
Zoltan: I've described OCF's approach to security as relevant background knowledge, but we need to discuss the requirements more broadly for the web of things
Do we go by the web browser security model along with an origin URI?
I don't think so, as it doesn't scale well.
Black listing is poor practice. White listing is better.
Zoltan: Ownership transfer is best done with manufacturer's certificates.
Matthias: we need authorization in addition to authentication
Dave: last year we were discussing organising a joint white paper on security with individual contributions from people from a broad range of organisations.
Zoltan: perhaps we just need to
establish a secure tunnel and defer security to the
platform.
... I have no opinion in respect to the joint white paper
MichaelMc: One suggestion is to involve the IETF to help drive a dialogue on security.
Matthias: We could write an Internet Draft on a particular scenario and use that for discussions within the IETF, and to focus on how to use the mechanisms that the IETF groups have developed.
Michael: the WoT WG charter makes a number of requirements on the work we are expected to do, including strong security review.
Matthias: different platforms use different security building blocks.
If a device hasn't been onboarded then we wouldn't have a means to talk to it.
Discovery is dependent on the kind of network things are hosted on.
Johannes: the IG discovery task force came up with a handful of categories of techniques for discovery.
In principle, thing descriptions could include certificates signed by device manufacturers.
The biggest problem is that we now need to attract security experts for the task force.
scribe: end of session ...
<kaz_> [ Day 2 ends ]
<kaz> scribenick: kaz
mm: shows the draft charter for the
OCF/WoT Liaison TF
... will merge the latest pull requests
... scope
... Enabling the use of web technologies enabled by the W3C WoT
recommendations to OCF devices
... OCF has its own data model based on RAML
... (put proposals on the whiteboard)
... Next plugfest:
... OCF
... -> convert RAML data models to TDs
... -> generate interfaces
... -> based on T.S. WoT-node interface
mk: what kind of interface?
mm: (draws a diagram on the whiteboard)
<img />
mk: description using TD for OCF devices?
mm: may have multiple RAML files for one TD
sk: mapping TD to RAML as well?
mm: (adds another direction from TD
to RAML)
... conversion from RAML to TD and then go back to TD from RAML,
and get the same content
zk: so the TD can be converted to RAML and work for the OCF devices using REST/CoAP protocols
(discussion on action and operation)
dsr: naming convention?
zk: you need to generate OIC request
mm: (adds test cases to the interface
conversion portion)
... round trip tests
dsr: what about IoTivity?
mm: bunch of physical devices
... we can have a simulator
... how do we create that?
zk: we could use real devices
... do we have RAML Things?
mk: this is all scratch and handling both the areas (WoT and OCF)
mm: we should accumulate our efforts
dsr: could you please gather TDs from PlugFests?
sk: we can upload all the TDs
jh: good to have some specific repo for that purpose
mk: do we want just TDs or including background information as well?
zk: good to have background information as well
dsr: collecting ideas is valuable
mm: we need more structured approach for testing
dsr: you can start with TDs
... but need some more data, e.g., JSON, to generate tests
kaz: who would lead this work?
... part of this OCF/WoT liaison?
mm: right
yz: (shares his screen)
... Initial Discussion on WoT-oneM2M Interworking
... Content: Interworking Scenarios, Information Model
Mapping
... (Interworking Scenarios (1))
... exposing oneM2M interfaces to WoT systems
... (Interworking Scenarios (2))
... transparent interworking
... encapsulate the whole WoT data model into oneM2M
containers/flexContainers
... sensors expose interface using WoT I/F
... application entity (AE) as inter-working proxy encapsulates
TD
... another AE uses the TD
... not the best solution, though
... (Interworking Scenarios (3))
... direct resource mapping with TD (like SDT/HAIM mapping or
AllJoyn Interworking)
... fine granularity but still some limitation
... (Interworking Scenarios (4))
... semantic interworking (using generic interworking framework and
base ontology mapping)
... semantic interoperability and automated
... limitation: ontology mapping may not be fully compatible
... those are potential scenarios
... (Information model mapping (1))
mm: what is the priority?
... what to start with?
yz: scenario 1 would be the
best
... other scenarios would let oneM2M to consume TD
mm: oneM2M might have more flexible
mechanism than OCF
... automated test for oneM2M situation?
yz: don't have clear view yet
... need some solution
... would ask oneM2M guys for ideas
dsr: would like to continue collaboration for next plugfest
mm: generating TD (for WoT) and RAML
(for OCF)
... how do we arrange testing?
dsr: oneM2M model is XML-based
... maybe we could generate TD based on that
mm: who does what?
dsr: need more volunteers
yz: maybe somebody from the oneM2M side as well
dsr: node.js for accessing oneM2M
module?
... maybe we can look into that
... should be able to create one with your help
mk: there is a oneM2M module
mm: we need to have something opensource-based
dsr: any companies for volunteers?
yz: would like to check within oneM2M
mm: is anybody here in the meeting room actively involved in oneM2M?
(no...)
mm: we should get some representation from oneM2M
dsr: we could invite external experts to PlugFest as well
mk: question on scenario 4
... have you identified the mapping issue?
... we might want to have a narrow base ontology
... for atomic use cases
yz: conflict from one domain to another
kaz: question about how to coordinate
mm: discussion on testing
kaz: maybe at some point we might want to have a dedicated testing tf
mm: make sense
... any volunteers?
mk: raises his hand :)
... already done some work
... can give some guidance as well
mm: you might want to generate a charter for that
yz: continues his slides
... (Information model mapping (2))
... oneM2M Base Ontology
yz: note that oneM2M doesn't model
'event'
... base ontology deines upper layer semantics for human
understanding
... (Information model mapping (3))
... (Information model mapping (1)) again
... WoT TD also describes interface while SDT doesn't
... instantiation as HAIM
... (Information model mapping (3))
... semanticDescriptor
... oneM2M SD (semanticDescriptor) supports semantic
discovery/query while WoT TD doesn't yet
... oneM2M SD is more distributed to resource level while WoT TD is
more at the "thing" level
... oneM2M SD is using RDF/XML while WoT TD uses JSON-LD
... (Information model mapping (4))
... there are a lot of more metadata points
... WoT metadata/data is stored in more centralized way in TD while
oneM2M metadata/data is more scattered into different resource
types
mm: questions?
mkoster: driving use cases?
... two way bridging from one to another
dsr: use cases which the current TD don't cover
mm: event model difference is
generic
... should have concrete use cases
zy: basic mapping rules then concrete use cases, maybe
mm: you're using ER diagram and RDF
diagram
... we need information for TD model
... discussion yesterday as well
... what's the right way for information model regardless of
serializations
zy: don't have any specific
preference
... maybe RDF?
mm: zoltan, can you mark observable
within OCF?
... any way to distinguish property within oneM2M?
s/zonlatn, can you/can we/
sk: would like to see this oneM2M
ontology within our PlugFest
... nice to include it
mm: compatibility between oneM2M ontology and TD?
zy: mapping or annotation link?
mm: another point is modularity
zy: note it's difficult for oneM2M people to understand different data model like TD
mm: thanks, coffee break now
mk: after break, there will be
scripting workshop at Santa Clara
... and semantics/connection to RDF at Board room
[ morning break ]
<dsr> The IRC channel for the Linked data and semantic processing break out is #wot-ld
[ remote: Daniel, Darko ]
(nimura-san is preparing for his presentation)
kn: (Scripting API)
... scripting API provides means for discovery, provisioning and
control of Things
... programmers don't have to care about protocols
... (1. ExposedThing)
... provisioning: development and setup
... exposeThing generate a TD and expose the server API
... 1. developer writes an app script using exposedThing with
callback accessing a Thing
... (Runtime: Control of Thing)
... (Runtime provisioning: add Thing)
... (ExposedThing can be used in any layers)
... omitting consumedThing intentionally
... (ExposeTHing in various layers and combinations)
... (2. ConsumedThing)
... Provisioning: search a device initiates a discovery and setup a
thing API to use
... 1. discover device
... 2. download TD
... 3. parse TD
... 4. expose client API
... (Runtime: Control of Thing)
... (Runtime provisioning: search and use another Thing)
... (ConsumedTHing can be used in any layers)
... layered mechanism
... client, cloud, gateway, device
... (ConsumedThing in various layers and ...)
... (Example: WoT Server/WoT Client)
... electronic applicance with WoT server is controlled by a remote
controller with WoT client
... (3. WoT Servient (Consumed/Exposed Thing))
... the server on the right side exposes "Thing"
jh: device side on the server and application side on the client?
kn: yes
jh: same app script for various setup, e.g., direct connection or remote?
kn: right
mk: the light should be connected
with the server side, shouldn't it?
... script for device control is for low-level hard ware
control
zk: TD repository includes TD instance?
jh: we need to describe interaction model first
mk: what is the expectation for TD
template?
... use case behind template?
jh: possibly we could have one
declarative template
... or generate it programmatically
... keep it open for the both way
mk: TD is generated on-the-fly
... what is the right time to put that to the TD repository?
jh: maybe not all the runtime support
on-the-fly generation
... we don't have any method to communicate with the TD repository
so far
... there is a TF for discovery discussion
zk: we could have a property and
interpretation by some ontology
... OCF has some meta property
... including if the Thing is discoverable
... ontology for that could be standardized
kn: we don't have that kind of
ontology now
... comments from the telco includes
... consistency with TD format of the Santa Clara version
... semantic expressions as an optional parameter to the addXYZ
methotds of ExposedThing
... also ConsumedThing/Discovery does provide semantic part already
by "discovery filter"
jh: we don't need to change those methods if the ontology changes
zk: implementations need to know what is provided
mk: this is application level
zk: what my binding needs to
do?
... how to generate some concrete OCF binding?
jh: I see your point
... we could offer an API for semantic annotation
zk: assuming applications can get information transparently?
jh: yes
mk: we don't have a model in which property can be observed
jh: so far all the interaction is request/response
zk: need a separate request about observable or not?
jh: let's take another example for
this discussion
... what is needed for the Thing level or the interaction level
mk: question on Scripting API
... page 1
... "using scripting API..."
... need addition, e.g., to tell what the vocabulary and annotation
is like
zk: how to do that in a generic
manner
... giving an example would be helpful
jh: let's go through Nimura-san's slides and then have discussion later
kn: p14
... (Example: Voting)
kaz: question about the "client" and
"server" inside the servient
... maybe it's misleading to have them within a servient
mk: we should fix the diagram and
have discussion during lunch, etc.
... this diagram is a good starting point
kaz: ok
kn: (Comments from telco)
... how to deal with installing apps
... exposeThing is less important because Things are already
there
... but not the case for gateway/edge, etc.
... inspection model of TD
... consistence with TD format of Santa Clara version
jh: tx
... many discussions on exposeThings and consumedThings
... (shares his screen on WebEx)
... Open Issues on the W3C Web of Things Scripting API
... session tomorrow
... had discussion on ConsumedThing
mk: had added some comments here
jh: consumedThing API
... getDescriptin() call
[[
interface ConsumedThing {
readonly attribute DOMString name;
Promise<any> invokeAction(DOMString actionName, any parameter);
Promise<any> setProperty(DOMString propertyName, any newValue);
Promise<any> getProperty(DOMString propertyName);
ConsumedThing addListener(DOMString eventName, ThingEventListener listener);
ConsumedThing removeListener(DOMString eventName,
ThingEventListener listener);
ConsumedThing removeAllListeners(DOMString eventName);
object getDescription();
};
jh: do we need method to get property?
zk: why the consumed side does
discovery?
... not sure why we need getDescription here
mk: how to access the semantic
description?
... more specific access through API for semantic description?
jh: properties that belong to the representation vs meta-properties that belong the ConsumedThing
[[
interface ExposedThing {
readonly attribute DOMString name;
Promise<any> invokeAction(DOMString actionName, any parameter);
Promise<any> setProperty(DOMString propertyName, any newValue);
Promise<any> getProperty(DOMString propertyName);
Promise<any> emitEvent(DOMString eventName, any payload);
ExposedThing addEvent(DOMString eventName, object payloadType);
ExposedThing addAction(DOMString actionName,
object inputType,
object outputType);
ExposedThing addProperty(DOMString propertyName, object contentType);
ExposedThing onInvokeAction(DOMString actionName, ActionHandler callback);
ExposedThing onUpdateProperty(DOMString propertyName,
PropertyChangeListener callback);
ExposedThing addListener(DOMString eventName, ThingEventListener listener);
ExposedThing removeListener(DOMString eventName,
ThingEventListener listener);
ExposedThing removeAllListeners(DOMString eventName);
object getDescription();
};
]]
jh: what invokeAction returns
... might be a simple type or an object
scribenick: mjkoster
<dsr> The draft slide is at https://github.com/w3c/wot/blob/master/TF-LD_charter.md
External standards to look at: echonet lite, OPC/UA
discussion of how the connectivity protocols relate to data model standards
(dsr) we should engage people around these protocols
(dsr) focus on the information model more than serializations
(dsr) example of linked data grammar graph based on RDF shape constraints
shape rules
(sk) does this define a standalone vocab or is it mapping to another ns?
(vc) there is some similar work using owl to constrain instances
(dsr) this focuses on validation vs. inferencing
discussion on data type rules on slide 9
does this constrain syntax or semsntics?
This is toward constraining semantics
this should define a higher level of semantics on top of JSON schema type definitions
discussion on composability
Discussion on core data types
(dsr) need to coordinate these definitions across across different organizations
(dsr) need to coordinate units definitions across different orgs
discussion of IoT platform as a defined RDF concept which can include metadata for
discussion on how to use ontology
(sk) question on working mode; where there seems to be a lot of overlap with other work being done in the IG/WG
discussion of modeling context and environment
(dsr) communities to get together to create application vocabularies
(mccool) review charter and deliverables and discuss the time frame, etc
(sk) start with a prior art review
<scribe> new topic: charter review
(victor) should we identify platforms to inform use cases
(mccool) identify priorities
(koster) need to identify items to constrain scope to some specifics
AI foa all to review the charter on github and make issues, PRs
(mccool) could this be a good way to define an information model for TD? THis could be a deliverable
(sk) there is already an RDF model for TD, the WoT Ontology
<victor> Out-of-scope: Dave, one of your slides mention SHRL (shape rule language). Is that your own terminology or does it have a spec somewhere?
(sk) what can we deliver into plugtests?
(victor) identify vocabs that we could already use
(mccool) another example, we could look at normalizing semantics fopr units
(sk) should focus on the gaps, on what is missing from our current approach
(mccool) we should distinguish between IG wotk and WG work
(mccool) suggest making this a TF of the IG that can also have impact on the spec
(dsr) what is the time scale?
(mccool) firm draft by EOY, this should impact in about 6 months for first deliverables
(mccool) first task could be the information model
discussion on how to generate use cases and requirements
actions today: review slides and charter, make github issues, start discussion on schedule
actions: get needs from other groups in WoT
discussion of structure, dsr will be th einitial point of contact
<Sebastian> Victor and Darko are interested to be involved in this TF
use the mailing list and use [tf-td] in subject
<Sebastian> Darko is interested to be the chair of this group
who are volunteers? where is the roadmap maintained, etc.
(taki) hsould define goals so people can decide their participation level
goals: define the technology intersection and identify value add points
<kaz> [ Lunch until 2:30pm ]
<scribe> scribenick: dsr
Michael Koster introduces the session: linking in respect to related Interactions, sub-Things, groups, collections
or "WoT Linking and Collections"
Let's talk about when you have a collection of things, e.g. buttons, or a refrigerator with a freezer compartment and a cooler compartment.
Let's start with a row of buttons. This could be modeled as an array or a collection or ...
Dave: can you identify a button with a number in an ordered collection, or perhaps a name in an unordered collection.
Another consideration is hierarchical compositions of re-usable sub-things or capabilities.
We want to describe the things that we want to compose.
The properties of the items may be different, e.g. a switch on the left or a switch on the right.
How do you cater for indexing or grouping.
The collections and compositions could be dynamic
Dave: I found vectors convenient for some of the use cases where the items were named and had the same model.
e.g. x, y and z coordinates
How do you dynamically create, update or delete items in a collection/composition?
What are the set of verbs for operating on a collection/composition?
Dave summarizes his model of collections and compositions which is formally described in terms of linked data and graph unification.
Michael: I would like to understand how you do this for thing descriptions, what story do we tell to app programmers?
Johannes: you could have linked from one TD to another.
(Dave indeed, things as named properties, or import relationships)
What is the impact of collections on security?
Michael: access control lists need to be able to handle collections and items.
Sebastian: you can use contexts to reference the metadata terms.
Dave: with a property whose value is a thing, you need to link to the thing's model
Michael: we could introduce "link" as a peer of "property", "action" and "event".
We need to enable the IoT platform's support for multicasting to a collection of things, e.g. OCF batch collections.
The links between collections and items could be traversed in either direction, e.g. a light that knows the room it is in, and the room that knows the lights in that room.
If you want to invoke an action on a specific item in a collection, it can be convenient to model the item as a thing.
If you want to invoke an action on the collection you define the action on the thing with that collection.
Zoltan: when you have things that have things as properties, when do you instantiate them?
Dave: my Node servient does this automatically when the referring thing is created.
Zoltan: how do you refer to sub things, e.g. for discovery?
Dave: via a path expression as in JavaScript a.b.c[2].
You can update the thing model directly via the thing API as the model is exposed as a property of the thing.
Michael: we could also look at a declarative means to update thing descriptions.
scribenick: kaz
rm: (Background).
... synchronization is necessary for some conditions
... WoT servient have Things corresponding to devices
... WoT servient on a gateway tied with devices
... application can control the device (=original device)
through another WoT servient on cloud
... (Use case 1: Smart home)
... application can't control the device directly
... (Use case 2: Smart factory)
... WoT client on cloud collects data from WoT servients that
arae connected to factory devices.
... Services analyze the data and users monitor the status from
a browser
... all the devices and network facilities are connected within
some factory
... and sometimes the internal network is split into sub
networks
... (SYnchronize WoT Servients)
... a legacy device is connected to a Servient on a
gateway
... this is the original device
... notifies the device's capability to the cloud side based on
the TD
... the servient on the cloud side has a shadow device
... (Control actual device from App script)
... if the app script changes the property of the
shadow...
... (Handle event from actual device)
... when the legacy device generates an event, the original
devices synchronize it to the shadow
... synchronization between the gateway side and the cloud
side
... (Sample implementation on this PlugFest)
... some devices connected to their gateways with legacy
protocols
... server and gateways synchronize with WoT APIs
... (How it works?)
... local device is discovered by the local gateway
... i.e., a local servient
... gateway notifies those devices to the server, and then both
of the WoT servients start synchronization
... (What are the issues?)
... we should specify:
... how to search original devices on gateway from cloud?
... how to expose Things to other servients and consume
them?
... how to synchronize device resources between WoT
servients?
... set and get operations are supported by WoT API but how to
communicate ia firewall between the gateway and the
cloud?
... we should also consider:
... how to handle time critical devices from the cloud?
... process on local gateway first, and then notify the results
to the shadow device
... requires edge-computing capability
... would like to start discussion about this within the
IG/WG
mk: part of the architecture
discussion in general
... property/action/event
... depending the implementers
... Siemens has something looks a bit different
... maybe same vocabulary but different work flow
... the second alternative is really standardize
something
... those are the 2 options
... more flexible or standardization (or half way
solution)
... context for cloud mirroring
... or replication
... implementers can make their choice
rm: who manages the whole
description?
... universal repository?
... within our implementation, all the information was on the
server side
... the architecture document specifies the basic
mechanism
... expose/consumed Thing within the servient
mk: we should start with flexible
use cases
... cloud mirroring
... we don't need to standardize anything other than the
vocabulary
... both the use cases (smart home and smart factory) are quite
similar
... Johannes has been doing something similar
... please go back to the schema thing
rm: go back to (SYnchronize WoT Servients)
mk: light-weight oneM2M
architecture
... what you expose the Things
... there is a Siemens internal project
... OCF also goes in this direction
... Samsung, etc.
rm: our implementation uses
HTTP
... would like to implement protocol binding for MQTT, etc.
mk: so does the "app script" provide HTTP interface?
rm: yes
mk: proxy or shadow on the cloud
side
... this can be implemented just using scripting API
... and then we can compare with the existing approach
... you can put your ideas on the discovery document
... we need local discovery
... where the "legacy" stuff would fit?
rm: many standards include discovery capability
mk: we can present in detail in
Ohsaka
... so need to finish by the end of April
... Nimura-san also made presentation
... also how to manage the certificate?
rm: would like to create functional use cases
mk: the transitions are mandated?
rm: would try several devices
mk: gateways are already registered with the cloud
rm: any other comments?
ohura: no specific comments
mk: activating the shadow is
starting the Thing
... could you share the slides?
rm: yes
... will send them
kaz: this topic will be handled within the main call rather than a separate TF. right?
mk: this topics should not take too long time
kn: @@@
mk: there is a hook missing
... topic to consider
... the topic on time-sensitiveness
... the application may move the logic to the gateway
... think that's possible
... but how to associate local things?
rm: application running on the
gateway side
... in this condition with time critical devices
... not collaborating actually
... should we discuss this within the group?
mk: need to make sure APIs and possibility
kaz: maybe implies global time
stamp within TD?
... not only time stamp but time management mechanism based on
time stamp within TD
... further discussion should be held within the group
... but if we want to handle time-critical devices, we need
some kind of time management mechanism
[ afternoon break ]
-> https://www.w3.org/WoT/IG/wiki/images/8/8b/Subscriptions-sc.pdf Johannes' slides
jh: (Proposal for Events and
"streaming data" use cases)
... (Separate subscription management from actual data
flow)
... Source <-> Sink
... Source<-Subcribe-Client-Publish->Sink
... (Proposal)
... establish resource-based management for subscription
... subscription managemetn separated from the actual data
flow
... define interaction types for W3C WoT model
... DataSource / (EventSource)
... semantic type, output type, links
... DataSink
... (Datastreams Thing model extension: Thing description
view)
... DataSource example and DataSink example
... (Datastreams Thing model extension: Scripting API
view)
... (Datastreams Thing model extension: Protocol binding
view)
... (Next steps)
... discuss proposals/feedback
... write down proposa to current practices
... trial in running code
mm: interested in demo with video streaming
mkoster: edge computing things are good
mm: OpenVX is good to see
... good to have edge-based video camera
mk: note we should concentrate on IoT side
jh: might want to have video streaming during the next PlugFest
zk: need to put some use cases
mk: event going along with video stream
mkoster: possibly HTTP plus MQTT
(which covers what HTTP doesn't handle)
... data source could be a video camera
mk: can we collect what people really would like to do?
jh: my point is this protocol
binding part
... shows (Datastreams Thing model extension: Protocol binding
view)
mm: think we need additional property
zk: where to connect
... a sensor to be connected to one specific device?
... provide data to outside?
mk: would like to collect concrete ideas
jh: everybody can elaborate their use cases
kaz: would like to see the relationship between this discussion and (1) TV group's Cloud Browser discussion and (2) VW's VIWI proposal which uses combination of HTTP and WebSocket
jh: shows: http://resthooks.org/docs/
mk: we already have very
specialized protocols
... REST hooks may actually handles them
... we need to implement protocols
... started some notes
zk: would like to talk about the possible API structure with Johannes
mk: would clarify the next
steps
... REST hooks for Johannes
... exposing data source, etc. for Zoltan
... using OCF? BLE?
zk: doesn't matter
... thinking about the TD part
mk: what would be the data source for the streaming?
zk: at this point not interesting
in protocols
... rather interested in default resources
mkoster: IoT REST API server
zk: right
mm: HTTP, WebSocket, TCP
mk: panasonic using WebSocket?
naka: we have local devices using legacy protocols
mk: JSON object?
naka: events
jh: JSON document?
mk: you might want to try converting to this model
jh: TD stuff
mk: anyone else?
(none)
mk: good starting point
kaz: at the moment, we're not interested in adaptive streaming but would start with simple streaming. right?
mk: yes
scribenick: dsr
Sebastien describes the role of contracts in Big-IoT EU project.
This has an app store with suppliers and consumers, and
One question is around the dependencies on a consumer to be
Sebastian explains how in BigIoT a provider registers a TD
The provider registers a large TD, but the client is a
We discuss an example in the current practices document
This is provided to enable a SPARQL query so that the
Dave notes that by using a URI to identify the IoT platform,
It is up to the platform to indicate what metadata it
Note that the platform URI identifies the kind of IoT
[ brief break ]
-> https://github.com/w3c/wot/blob/master/proposals/td-lifecycle/TD_Lifecycle_Syntax_on_JSON-LD.pptx Kajimoto-san's proposal
naka: (TD Template and Lifecycle
Eco System)
... TD template
... (The relationship example of organizations and TD)
<inserted> W3C/WoT-WG
naka: organization of each
vertical industry
... mas production manufacturer
... platform provider
... service provider
... ("include" example)
... left-hand example is TD template
... right-hand example is TD for a Panasonic air
conditioner
... we can refer to the template from the TD for the specific
Panasonic air conditioner usint "@include"
... can include part of the template by specifying
"air-conditioner:actions"
dsr: thinking about oneM2M
case
... module itself could be a URI
mm: assuming section could be optional
scribenick: kaz_
mk: if the purpose is linking template from instance TD, we could use RDF-like model for that purpose
naka: some more use cases
... adding features
... or removing part of features
henry: we also thought about that kind operation using $add, etc.
... within JSON Schema
mk: the requirement is clear here
... good to know about what you need
... but we don't need to reinvent this kind of new notation
mk: JSON patch may be used for this purpose
naka: tx
mk: btw, do you want to avoid RDF extension capability?
... probably need to ask Kajimoto-san
<kaz_> [ Day 3 ends ]
<kaz> https://www.w3.org/2014/automotive/charter-2016.html
<kaz> https://github.com/GENIVI/vehicle_signal_specification
<scribe> scribenick: dsr
<kaz2> www.w3.org/Submissionj/2016/01/
Kaz introduces the Automotive Working Group charter which
Kaz explains the work on using Web Sockets to connect web
The car is modelled as a hierarchy, e.g.
The use of Web Sockets to connect the server to the client
The object hierarchy is defined by GENIVI.
<mjkoster> browsavle GENIVI model in JSON
Last October, Volkswagen submitted a proposal for the
This makes use of HTTP for access to resources and Web
Kaz would like to see continued discussion between the auto
MichaelMc: I think in this group we need to work on
Dave: just to check my understanding, you want this group to
Michael: not necessarily.
Matthias boldy asserts that Web Sockets isn't a protocol as
Kaz: ideally, the auto WG would re-use an existing protocol
Dave: one alternative to Web Sockets for eventing is W3C's
The Volkswagen proposal uses standard web security
Dave asks what more we should be doing in respect to
Kaz: they have their own security task force, and I am
Johannes: we would like to continue working through the
See:
Johannes encourages people to contribute to the issue list.
Matthias: we need to be careful as the WG has taken over the
Johannes talks about how to formally specify the scripting
MichaelMc: I think should pick some target languages to
Johannes: I agree in principle, specifying the IDL for a
s/strong/strongly/
Zoltan: WebIDL is frequently used as an alternative to just
Matthias: perhaps the W3C staff contacts could check if
Johannes: Typescript is used by Microsoft, Google and other
If we want to specify a portable API we should avoid a
Kaz: this also came up in the Auto WG who found that WebIDL
Johannes: how does ECMA handle this?
Zoltan: prose based descriptions
Johannes: perhaps the W3C staff could ask W3M if it is okay
There are tools for mapping TypeScript to specific
Matthias: I propose we use both WebIDL and TypeScript for now
General agreement with this.
Dave: perhaps we could make a tool to map between WebIDL and
Michael: perhaps we should state one of them as the
Johannes switches topic to promises versus callbacks versus observables.
He gives some explanation of how the three approaches relate
Zoltan: promises for a single result or error, otherwise
Dave: what do the various programming language communities
Johannes: promises are being added to a good range of
A minimum requirement for supporting promises is function
Michael: some environment do not support function pointers,
Zoltan: Observables are nice for cancellable promises
Johannes asks Zoltan to propose a detailed solution.
Zoltan: I will submit a pull request that documents the
Johannes: we should investigate the use of Observables when
Dave: we just need to be sensitive to the cultural norms of
Johannes changes topic to the issue of a root API object.
Zoltan: either the object needs to be present or it needs to
<yongjing> yes, but i'm in another meeting in the same time, so
Zoltan: for Node, right now we use a Node require statement
MichaelMc: this doesn't need to be part of the standard.
Matthias: what Michael suggested is very Node centric, and
We want to enable portability
Johannes: for our spec we just define the interfaces exposed
We could include some informative recommendations on how to
Johannes: let's now talk about the client API
Johannes talks through several alternatives for using
Zoltan: for broadcast protocols, you typically can't cancel
If you want a sequence of objects, I would recommend a call
Johannes agrees
Johannes: is there a convenient means for the client to stop
Zoltan: if the discovery call returns a handle, it can be
Matthias describes how Observables applies to this.
Michael: if we're planning on using Observables in our
Matthias: so one outcome is for us to reach out to ECMA for
Some discussion on how to support deleting things
scribe: discussion wanders a bit ...
Johannes sums up.
<scribe> scribenick: kaz
mk: WoT IG and WG Next
Steps
... GitHub repos for each group
... Chairs/Editors/Staff have write permission
... others use pullrequests
... (WoT Task Forces)
... WG:
... Architecture, Thing Description, Scripting API, Security,
Hypermedia, Type System
... IG:
... Linked Data and Semantic Processing, Testing,
Synchronization of Servients
... hypermedia for actions and error handling
... type system for JSON Schema
mm: protocol binding?
mk: don't really have a TF for
that
... that's informative work
... TF means a dedicated call
... would get feedback
jh: maybe linked to hypermedia discussion?
mkoster: concrete method
... wondering about the same thing
mk: liaison work is also
important for binding
... (adds "prepare binding template" to hypermedia tf)
... we should have somebody as the Editor
... and regarding the IG side
... Dave has started LD and semantic processing work
... and Testing
... then Synchronization
... anything else?
(none)
mm: scripting api might be misleading?
mkoster: how to handle semantic discussion?
mk: let's move forward to the
detail
... (WG Architecture TF)
... WG deliverable
... need Editors
... one of them would be Kajimoto-san
... Frank as well?
dsr: architecture layers
mk: taxonomy?
dsr: e.g., application layer, protocol layer, ...
mk: we already have application layer, interaction model, protocol binding, ...
(some discussion on possible layering of the architecture)
mk: (updates the "Topics" for
architecture)
... Topics:
... overall architecture
... how to combine building blocks, what do they give you
... servient architecture (layer model?)
... (TD TF)
... WG deliverable
... Editors:
... Sebastian already
sebastian: maybe Taki?
taki: ok
mk: (adds Taki)
... Topics:
... overall model (prototype -> graphical -> RDF ->
...)
... type system
... (Scripting TF)
... WG deliverable
... Editors: Johannes, Zoltan
... Topics:
... related to architecture work
... language-independent definition
... implementable in embedded environments and Web
browsers
... part of the test suite
... informational document on rationale
... (Security TF)
... need to support other deliverables
... Lead: still searching for candidates
... Topics:
... outreach with good TF Charter
... reach out to IETF security area through I-Ds
... work with liaisons for platform security models
kaz: mccool, are you willing to act as a tentative lead for this work until we find actual lead?
mm: as one of the co-Chairs maybe
mk: (Hypermedia TF)
... subteam to help TD
... Lead: Matthias
... Topics:
... define model for complex actions
... define error handling model
... align with binding template
... McCool, ok with acting as a tentative lead?
mm: searching for a permanent lead. maybe McAfee?
mk: adds "please give
suggestion"
... (go back to "Hypermedia")
... Henry was interested
... (IG Linked Data and Semantic Processing TF)
... Lead: Dave?
dsr: ok with being the initial contact
mm: timeline and input for WG?
[ lunch ]
<img alt="group photo" />
kaz: need to update conf/liaison pages
mk: there are monthly calls
mk: (OCF Liaison)
... joint meeting with OCF and T2TRG
mm: OCF meeting in Amsterdam on
March 6-10 + 11
... McCool will join MKoster won't
mk: March 11 will be T2T
mm: TF Charter available
mk: goals until the next
f2f
... demonstrate (OIC) interoperability at PlugFest (OIC spec if
OCF spec is not published in time)
(some discussion on OCF's standard work)
mkoster: OCF specs are not yet published
mk: compile input fro TD TF
... (oneM2M Liaison)
<inserted> (OPC Foundation Liaison)
mk: presentation at OPC March
meeting
... 20-23 March 2017
... can pitch during the meeting
... what's the public things we can do?
... manufacturing automation factories
... there is knowledge about that there
... possible horizontal liaison
... goals until next f2f
... agree on strategy
... get access to example UA models
... roadmap for PlugFest contributions (e.g., I4.0 demo)
-> https://github.com/mmccool/wot/blob/a9e934e52b2296a1088a82eb25ac27c1ca33864b/proposals/liaison-ocf/charter.md OCF Liaison TF Charter
scribe: (IETF/T2TRG
Liaison)
... next joint meeting: f2f July 2017, Duesseldolf
... goals until next f2f
... see joint meeting
mm: joint meeting with T2T?
mk: during the Duesseldolf
meeting
... also plugfest during breakout day?
... request full-day room for PlugFest
kaz: preparation on Sunday?
mk: maybe 4 slots on Wednesday
for PlugFest?
... at least 3 hours on Wednesday
kaz: so 1-day or half-day prep on
Sunday
... 2-day meeting
... plus 4 or 3 hours on Wednesday for PlugFest
mk: updates the slides
... PlugFest prep: open space or room on Sunday (wired
Etherenet uplink, power strips)
... Plan observers/groups (inbound + outbound)
... further plan?
mm: joint meeting with security guys?
mk: (F2F Meeting March
2018?)
... co-located with security conference
... todos:
... organize academic conference workshop
... TPAC is in November and then we'll have Christmas
mm: IEEE security in May
... in California
-> http://www.ieee-security.org/TC/SP2017/ IEEE Symposium on Security and Privacy
mk: mccool, did you do any outreach?
mm: not yet
-> https://www.internetsociety.org/events/ndss-symposium/ndss-symposium-2017?gclid=Cj0KEQiAw_DEBRChnYiQ_562gsEBEiQA4Lcssv0CQ7OoLsJyYygkBZCPd_FieUUJGPErVpgAmimK8-AaAgtI8P8HAQ NDSS Symposium of ISoc
barry: both NDSS and IEEE are good
mk: updates (F2F Meeting Feb?
2018)
... co-located with security conf?
... http://www.ieee-security.org/TC/SP2017/
barry: maybe could join only the workshop
mk: note all these security
conferences occur in California
... need to invite experts from Asia and Europe as well
... (another F2F Meeting Feb? 2018)
... co-located with security conf?
...
https://www.internetsociety.org/events/ndss-symposium/ndss-symposium-2017
kaz: before ending the meeting, please remember that we need to care about the W3C Patent Policy for the work on the WG deliverables.
<kaz_> [ f2f ends ]