<dsr> scribenick: dsr
Takuki welcomes us to Fujitsu with a brief account of the history of the site and its current role
Takuki hands the microphone back to Joerg to introduce the meeting
Joerg presents some slides setting out the context for this meeting
What is the motivation for the web of things? The goal is to overcome domain silos and enable cross domai IoT applications
The upper OSI layers are often proprietary due to the lack of standards
We’re investigating what web technologies are applied to the IoT today?
Joerg takes us through the Interest Group charter, see http://www.w3.org/2014/12/wot-ig-charter.html
The IG is looking at use cases and requirements across application domains. Liaisons with external organisations, the Web of Things framework, security and privacy.
Joerg: we are we currently in respect to the charter’s roadmap?
We had our first face to face in Munich in April this year with a focus on understanding use cases.
We want to examine use cases to extract the core aspects or “atomic use cases”
Examples include device registration, something that is common across application domains.
The next step is to identify technology candidates and understand the landscaope and identify gaps.
Coming out of the first face to face we chose to work on scripting API and protocol mappings, thing discovery, thing descriptions, and security and privacy.
Can we conclude on the model of building blocks and agree on the setup for work on the technology landscape?
Dave: we will also be discussing ideas for launching a working group, and I will describe this in more detail on Friday.
Joerg displays a diagram depicting the relationship between Web things, web browsers and servers.
How do we make things accessible from today’s web? Most people would expect to do this via a web browser. However, it is also about how things interact with each other over the Web
Web of Things building blocks are intended to map to existing IoT platforms and protocols.
This includes integratio of things in today’s web, with web applications integratin things.
We also expect to integrate applications via their semantics
Joerg summarises with the list of task forces that having been looking at the building blocks.
We will be hearing summaries of their progress this morning.
Joerg notes that as today we have guests plus regular IG members, that we should go around the room for brief introductions.
Everyone briefly gives their name, affiliation and interests in respect to the Web of Thiings.
Joerg presents the agenda for today.
We will start with reports from the various task forces, then a report on the joint meeting with the IRTF T2T RG. After lunch we look forward to hearing from the invited guests and finally from some practical work experimenting with implemention work.
Johannes Hund presenting.
We have sought to agree on an architecture model, use cases & requirements, the technology landscape, and the abstract resource model.
Johannes presents a diagram introducing the architecture model.
This has three servers (aka “servients”), each of which has scripts, resources, protocol mappings and modules for acting as client or server.
Legacy devices can be supported via adapters.
The client and server roles are exposed by the corresponding client and server scripting APIs
We’re beeng working on a use case document http://w3c.github.io/wot/wot-ucr.html
Johannes next summarises the abstract resource model in terms of events, properties and actions.
He presents a coffee machine as an example.
Properties include the water level, number of cups served, etc. Actions include brewing, cleaning, refunds, and events included coffee poured, service required
This bring us to the technology landscape. We’re looking at protocols, resource models and API patterns.
How can existing protocols be used for the abstract model. What are the common resource models. What are the patterns used on the Web.
Johannes summarises his expectations for the outcome of this face to face.
Can we achieve a consensus on the taxonomy and picture?
What do we expect to achieve by the next face to face in October (TPAC2015)
He presents the agenda points for the break out session for this meeting.
Questions?
[none raised]
Joerg: we had some discussion around the resource model and whether or not to go with a strict mapping to REST.
Johannes: if you have a pure hypermedia framework, you can use a pure REST style interface. For me it is more about agreement on the model, and finding the granularity for the representation.
Michael: that’s an interesting discussion. Hypermedia descriptors allow different models to be included in the framework. To what extent do we rely on media types, or link relations.
This makes it important to take a prototyping approach to evaluate different choices.
Soumya couldn’t make it today, so Johannes will present on his behalf.
We’re been seeking to evaluate different understandings of discovery, to survey the current landscape, and to identify different dimensions of discovery.
We’ve looked at the relationship between thing descriptions and discovery? What are you trying to discover, what is the context for that, e.g. where is it, and what is its role.
How does discovery fit into the overall Web of Things framework? We want to agree on a generic approach to discovery along with a taxonomy.
We made a use case analysis and identified a set of categories for discovery,
find things around me, find things on my network, searching across peers, accessing thing metadata. Details are on the wiki page https://www.w3.org/WoT/IG/wiki/Discovery_Categories_and_Tech_Landscape
Joerg takes us through the wiki document.
Soumya wanted to highlight current plans for the discovery task force.
One task is to draft initial requirements, another is to evaluate technologies in each discovery category,
An example is to look at how search can be made using directories.
Another task is to simplify discovery for application developers.
An example is to make use of the relationships between things.
The approach will be discussed in more detail in the break out session.
Soumya has prepared some high level questions for the break out to address.
Dave: social context makes discovery more tractable
Information about relationships between you and your devices, between you and other people, information about your home, your organization and so forth.
Michael: (comment lost)
Joerg asks the audience for opinion on the importance of discovery
Michael: it is hugely important, and it is also a question of scale
the need to attribute based, web scale discovery.
Vlad: the context matters, e.g. personal discovery of things near you versus global discovery. There isn’t one way to do discovery. What is important is the way that data is represented as to how you find the data.
Joerg: discovery is also related to provisioning and configuring services.
Vlad: discovery can be contextualised by the kinds of IoT devices, how do I find the URL of a particular device.
Can you find the resource tree for a device, once you have its URL
This isn’t quite enough to knowing how to interact with it.
Joerg asks the room if he has had experience with having to use multiple discovery mechanisms due to the environment tanyone service has to be installed in
Michael: Bluetooth and the need for a proxy to map data from Bluetooth protocol into the approach needed for SSDP.
Any further comments/questions?
[no]
We take a short coffee break.
Sebastian presents the session.
First I want to explain the motivation for why we set up this task force.
Picture of a person scratching their head whilst considering an IoT device. What are you? What kind of data do you serve? How can I access that data?
The task force is clarifying and defining what the description language can be used for, what aspects of things need to be described. We are seeking to achieve a broad consensus.
We started in mid-May and have had about 10 teleconferences so far.
We have been surveying the technology landscape, looking at existing work.
More details at https://www.w3.org/WoT/IG/wiki/Thing_Description
Sebastian displays a meta model covering things, properties, data and resources.
He talks us through an example of a LED lamp which allows you to control the brightness and the colour of the light it emits
Properties include the name of a specific lamp and its location. The data includes the brightness and colour.
Sebastian relates this example to the CoAP protocol and the well known location based means for retrieving server metadata. CoAP supports link descriptions and encourages a fine grained description.
Sebastian presents a JSON-LD representation and notes that we will be going into details in tomorrow’s break out session.
He notes the comparative sizes of the models in plain JSON-LD and EXI/RDF.
For the break outs, Sebastian wants to discuss the refinement of the framework, to look at some interesting data types, relevant use cases as a basis for a gap analysis and plans for implementation work.
Question about how you are reaching out to look at work in other organisations, e.g. IPSO, OIC, IIC, AllJoyn etc.
Dave: we’re reaching out to these organisations to see how we can share ideas and use cases.
We will here some detail for the OIC on Friday.
[no more questions]
Oliver is the presenter.
First of all, with rich sensors, personal data needs to be protected from unauthorised monitoring.
The task force wiki page is [to be supplied]
In the last few years, people have either ignored IoT security or they have taken an ad hoc approach.
There is confusion around new security mechanisms. As a result, it makes sense to provide a landscape study.
Our work in progress includes a high level structure for the landscape study, an initial list of design time mechanisms, and an initial elaboration for JOSE (IETF), OAuth for CoAP, DTLS.
We’re also working on a document cataloguing security and privacy requirements.
This includes an initial elaboration for entity authentication, SSO and thing authorisation.
We have some supporting documents we plan to write. These include a summary of the challenges.
Another of these documents looks at advanced concepts, e.g. end to end security.
We are also working on a glossary and references
We have a spreadsheet relating use cases to security requirements.
We’re clustering requirements to keep things manageable.
Legal entities are used to creating security policies up front, but this doesn’t work in the consumer space.
We’re also considering requirements fulfillment through design-time mechanism clustering.
Classical solutions (i.e. invented prior to 2010) are primarily about enterprise solutions.
More recently we have web application solutions appearing, including FIDO, JOSE, OAuth, OIDC, SCIM and UMA, etc.
In the future, we can look forward to solutions aimed at the IoT/WoT.
We’re discussing recipes for the WoT. This will be based upon the classification of the use cases.
The aim is to help you identify categories of solutions, but you will still need to work on how these apply in detail for your specific context.
Oliver poses actions for the audience. First of all to ensure that your use cases are passed to the security and privacy task force. Make sure that your security and privacy mechanisms include your favourites techniques.
If the recipes aren’t practical for you please let us know.
Questions?
How does security requirements for things differ to other web services?
Oliver: services can apply contextual information when it comes to security decisions, e.g. where you log in from.
Joerg encourages people to review the work of the task forces.
We will return to this on Friday when we have looked some more into the details.
Comment from the audience: I am concerned that the current approaches won’t scale up effectively, e.g. when you need to manage millions of keys
Will this IG address scaling challenges?
Oliver: some people still think that classic solutions will be sufficient. This is unrealistic.
Part of the solutiuon will depend on the application domain. Devices may only need to know about a limited numbers of other devices. Right now we are trying to compile questions.
Question: is there an establishment of a framework ..., different industries will have different requirements, what can we do across industries?
Oliver: right now I think more about a toolkit/chocolate box rather than a framework.
Comment: data will be very prolific, there has to be a level of a minimum base level requirement.
Oliver: yes, and data will need to remain in connection with the policies relating to it.
Joerg: we will return to security tomorrow.
Johannes is the presenter.
This is a report of a joint meeting between people from the W3C WoT IG and a research group in the IETF.
(The Internet Research Task Force Thing to Thing proposed Research Group)
This took place as part of the IETF ’93 week in Prague in mid-July 2015.
We shared use cases and participated in discussions of a cookbook for applying REST style APIs.
We discussed ideas for using REST for subscriptions.
We looked at hypermedia driven CoAP applications via developing user stories for each
When it comes to subscriptions, how does this work when you want to subscribe to multiple things.
We’re looking to continuing the discussions and to have a further joint meeting in Japan given than the W3C TPAC is in Japan the week before the IETF meeting which also will be in Japan.
Dave: any ideas for how we can extend this discussions across other SDOs, e.g. OASIS (MQTT, AMQP), OMA, OneM2M etc.?
Johannes: that will be easier to address when we have made further progress on the web of things framework.
Joerg: joint discussions is helpful, and can operate top-down and bottom up.
We shouldn’t stay with the scientific research issues, but also look at the practical challenges for implementation and products.
Joerg: working bottom up from a protocol is good to forging links with other communities.
Johannes hands the microphone over to Oliver to report on the track relating to security and privacy.
Oliver: we had a longer breakout on the Saturday. We discussed security and privacy related features in current IoT projects. We spent 2 hours on the Sunday discussing potential next steps with a view to ensuring complementary roles of the IETF and W3C groups.
There is interest in use cases from the home automation and building automation domains.
We hope to identify patterns and white-spots and follow up with further joint discussions.
In our Prague meeting, most of us were involved with capital goods rather than consumer goods. IoT devices are often of low value, but the context of the application is to control something of high value.
A focus on cross domain (cross vendor) domain scenarios.
The ad hoc approach to authorization is not going to work when it comes to cross domain/cross vendor solutions.
The people in the Prague meeting preferred symmetric crypto over public key based crypto. Concerns over certificate management for PKI.
Standards are needed for cross vendor solutions, but will also reduced costs even for single vendor solutions.
Unfortunately most current security and privacy solutions assume a single vendor solution.
Michael: a brief comment on the finding. On constrained devices, public key is practical on 32 bit microcontrollers, but certificates can be a challenge for small packet network technologies.
... we break for lunch ...
We start with a presentation from Andrea Trasatti, Samsung
He shows a video introducing the ARTIK family of microcontrollers.
These range in the amount of RAM etc. and the integrated connectivity technologies. An embedded secure element supports the security operations.
Samsung is inviting developers to apply for developer kits.
Andrea will also talk about their cloud based SAMI platform.
The Samsng Strategy & Innovation Center is based in the Silicon Valley.
Andrea: we use open software (e.g. Linux) and an end to end security solution.
ARKTIK comes in three sizes: 1, 5 and 10. These are targetted at wide range of IoT related applications
The devices feed data into the cloud, where the SAMI platform manages privacy and access control.
A form based UI is used to create a device description (aka manifest). There is a JSON based query mechanism.
We support REST and WebSocket ingestion APIs.
For privacy, users own their data and decide who to share what data with. Users can revoke these rights as needed.
Applications can write on behalf of users.
At this point we don’t have a vocabulary, but we can define terms as needed.
For example to add a new unit of measure.
For more info: http://www.artik.io and https://developer.samsungsami.io @AndreaTrasati @SamsungIoT
Andrea: the boards run a particular version of Linux. In principle, you could replace this with say a version of Android if that is what you wanted.
You might need to develop the drivers though.
Andrea is happy to review the W3C WoT IG work on thing descriptions.
Oliver: are you using OAuth and if so with what flow?
Andrea: right now we want to ensure that users grant access rights for each service individually. This could become cumbersome if there were a large number of services to deal with.
Arnaud: JSON-LD with global identifiers has some benefits, but ...
Andrea: we want to allow developers to name their properties rather than to have to use someone else’s. The cloud backend can do the conversions.
Arnaud: do you have the means to control what information is sent to say weight watcher, e.g. weight but not location?
Andrea: not right now
Joerg: are you looking into the discovery challenges?
Andrea: we are interested in doing so
We are definitely interested in interoperaibility as an aim
We switch talks — Michael Koster, ARM, Web to the Edge - REST and Hypermedia for Machine APIs
Michael: I want to talk about some of the IoT related standard we are using at ARM.
This includes the following groups: IETF, OMA LWM2M, IPSO
The Internet/Web provides useful design patterns. Innovation mostly in the end points, layered protocols, uniform addressing and stateless interaction.
He presents an architecture diagrm for IP for constrained environments.
followed by a brief introduction to CoAP.
RFC 6690 defines the CoRE link format for triples. This is reasonably compact with a few defined abbreviations.
CoAP servers support discovery via resource directories using the CoRE link format.
IPSO smart objects define data models
OMA LWM2M reference architecture uses REST based APIs over CoAP.
Resources are atomic pieces of information that can be read, written or executed.
Objects and resources have 16 bit identifiers.
IPSO smart objects can be composed to create models of complex things.
IPSO can work with MQTT as well as CoAP, and other IP based protocols.
Basic data types include strings, decimal, boolean, time, dates etc.
IPSO has been working on a wide range of smart objects.
RFC 6690 can be used for associating additional semantic descriptions with smart objects and resources.
Michael is interested in how IPSO can be made part of the Web of Things.
A common web client could be used to control IoT devices via a REST based interface. APIs can be autmated through hypermedia.
Web linking, relations and attributes are a good foundation for this hypermedia.
Models conform to schemas and can be used to generate APIs and bindings to protocols.
This approach allows you to compose models for richer capabilities.
For discovery, catalogs and brokers are useful building blocks.
Follow on work: how to describe events, actions and properties. What functional abstractions will enable vertical specialisation whilst still providing broad capabilities.
Michael: many organizations who claim to be making the one approach for data modelling for everyone else to use.
How can we get to a common approach?
Johannes: what do you see as being in common across all these approaches?
Michael: encapsulation is one example, some kind of annotation mechanism, similar goals. However, each group seems to be creating their own namespaces for what are essentially the same ideas.
Arnaud: who are the main players behind IPSO and LWM2M?
Michael lists some of the stakeholders involved.
Arnaud: I wasn’t quite sure how the Web of Things layer fits in
Michael: the device is the server, this is what makes the web scale.
The service layer bridges the device and the Web.
Constrained devices should support the same architecture although perhaps with less ....
Bryan: in AT&T we have an active M2M group.
Michael hands over to Scott Jenson to talk about Google and the Physical Web
The first slide is “W3C intro to the Physical Web”
Scott notes that he is with the Chrome team. It is not altogether clear that the Physical Web is directly relevant to the WoT IG.
In last October we opened a GitHub project on the Physical Web.
The Physical Web is based upon a Bluetooth beacon standard and a phone scanner standard.
The browser window is controlled by the DOM and is cool, the location field is dull!
We want to improve the user experience by reducing user friction (no typing of URLs)
Bluetooth Smart beacons transmit their URL once a second. This is one way communication with no return path.
The phone shows the URLs from beacons within range and the user picks one of interest and opens the corresponding web page.
Some people say this is just like QRCodes. But that misses the point. We can get URLs from many devices up to 50m away without any effort on behalf of the user.
Another criticism is spam. We don’t want to spam the user. Instead users have to actively ask to see what URLs are in their neighbourhood.
<bryan> at the same time, QR code scanning is an intent-driven activity, i.e. the user is explicitly seeking additional info about a device with a visible QR code.
<bryan> as compared to getting a lot of URLs for devices in the local area, without really knowing which is which
A local proxy server hides the user’s identity from the remote server. This is open source and not a “Google product"
Once you’ve connected to a website, the web app can use websockets etc. to communicate with the device, e.g. to pay for a parking slot.
We expect that mobile devices that connect to the Internet with zero user configuration will be very popular.
We can also use JavaScript Bluetooth APIs to talk to devices directly once we have the web page loaded. (based upon the API from the W3C Bluetooth CG)
Devices can be dumb, but a beacon can provide the link to related services in the cloud, e.g. recipes
<bryan> question: for the turtle example, how does the web app control the device directly via bluetooth once downloaded?
[answer chrome supports the bluetooth API]
Questions?
<bryan> cool. glad to see BT API implementation
Johannes: how does the browser present the choices for the beacons in range?
The local proxy pulls a snippet from the web server for the browser to display.
Bryan: how does the proxy ensure privacy?
Scott: the proxy server’s HTTP request is bare of user identifying info
This is why we open sourced the proxy server to ensure that people can trust it.
Question: do you have to have Chrome for this to work?
<bryan> answer: the user knows there is a proxy service at work in the app and trusts it to protect the user's privacy (it would be interesting to see the policy at the proxy server)
Scott: today, yes, but we expect this to be more broadly adopted.
In future, we expect to support more sophistocated clients, e.g. using ranking to alter the way the beacons are listed.
Oliver: is the proxy server using OAuth?
Can it be shared across users?
<bryan> i would hope that the ranking is purely based upon some relevance or reputation model, and not an economic relationship to the proxy service operator...
Scott: not right now.
Oliver: when people share a device, there could be problems.
Scott: we’re abolutely in agreement with you ...
Scott hands over to Jane Yin, Fujitsu for an Introduction to IIC Activities
She starts with asking how many of us have heard about the IIC [quite a lot of hands go up]
The IIC has 186 members currently and is now just over a year and a half old.
The term “Industrial Internet” was coined by GE as the “third wave of the Internet”.
The aim is to combine people, devices and computers via the Internet to achieve transformational business outcomes.
Low cost devices and connectivity are driving the opportunities.
This will create a vast amount of data.
70% of professionals say that interoperability is the biggest challenge, whilst only 14% say that security is the main challenge!
The IIC membership is still dominated by North America
The IIC is not a a standards organization.
Instead, the IIC aims to evaluate existing standards and to influence global SDO’s.
Jane: we are working on testbeds to ensure interoperability
We are collecting use cases from our members as input for our discussions on security and the reference architecture.
Security is an increasing focus for us.
Jane describes the operation of the testbed working group.
Bosch are particularly interested in tracking handheld tools in the work place.
Another testbed focuses on microgrid applications.
China is putting a big emphasis on Industrial Internet
For more info http://www.iiconsortium.org/
Questions?
Joerg asks about the reference architecture and testing
Jane: maybe we need a testbed for the reference architecture?
... we break for coffee
... we resume from the coffee break
... we resume from the coffee break
Bryan Sullivan (AT&T) presenting.
GotAPI expands to generic open terminal API.
This is a candidate standard from the OMA. It enables web apps to access arbitrary local or connected device APIs.
There is an open source implementation from NTT Docomo.
This is an example of a smart phone (or tablet) approach for the Web of Things.
It involves an embedded web server on the same device as the browser. Web apps can discover this server using standard web APIs (XHR, WebSockets, Server Sent Events, WebRTC) to access APIs through the GotAPI server.
There is an extension plug-in mechanism to different kinds of devices.
In principle this could also be used by native and hybrid apps.
The server uses the operating systems inter process communication mechanism as a building block to obtain the user’s permission for access to a particular device and API.
We spent a lot of time on security. This includes application registration and authenticity, so that the GotAPI server can detect app spoofing by rogue apps.
Privacy via user mediated permissioning. Detection of GotAPI server spoofing by rogue apps.
Likewise for plugins. We assume that the host device is not rooted, and that apps are from legitimate sources (app stores and web servers).
Bryan shows a video of a demonstration.
The GotAPI 1.1 will complete the specs for WebSocket based APIs. We’re developing APIs for common bluetooth healthcare devices, and for 3D printers.
Questions?
Joerg: have you applied this to controlling several devices at the same time?
This may require apps to be coded for specific combinations of devices.
Answer: the plugins are for classes of devices.
These are the top 6 IEEE specs,
Oliver: you already mentioned that you don’t yet fully support OAuth. Are you considering this further?
Bryan: either cloud based or some other solutions, e.g. an OAuth server on a secure element, there are many possibiities.
Presenter: Vlad Trifa, EVRYTHNG
Vlad introduces EVRYTHNG.
The aim is to track the whole lifecycle of a product whether consumer packaged goods or durable products and assets,
We asked ourselves why so many groups are creating so many different IoT protocols?
We came the the conclusion that the Web is a good way to go. It can bring order to chaos through accepted web good practices.
The Web of Things has a book
We came up with a 4 layer architecture above the actual things: access, find, share, and compose.
We focus on the use of HTTP and JSON.
HTTP client, web thing client, extended web thing client, semantic web thing
We’ve come up with blueprints for REST APIs for web things
Type 1 is where a web browser running a web client can talk directly to a web thing on another device.
Type 2 involves a gateway, e.g. supporting protocol translation from HTTP to CoAP.
Type 3 involves the cloud, e.g. using MQTT to feed data from the device to a server on the cloud that web thing clients can access.
Vlad presents examples of JSON payloads.
We’re submitting these ideas as a W3C Members submission.
Vlad presents a demo involving a smart plug that pushes data into the cloud
This uses MQTT as described above.
He shows how to send a command to turn the plug on.
Vlad then presents a model for a Raspberry Pi.
The model covers properties and actions.
He demo’s changing a text string on a display in London via sending a command.
Questions?
Oliver: is the spec public?
Vlad: we preparing our W3C submission via a draft hosted on GitHub.
Oliver: if I know the syntax for the URL, then I can invoke the action?
Vlad: yes
Oliver: what is your plan for access control?
Vlad: this is described in out book via the layered architecture, including best practices for securing the web
Sebastian: the model looks similar to what we’re discussing for thing descriptions. Where do you put location?
Vlad: this can be treated as a property like other properties
Oliver: so you have your own vocabulary?
Vlad: it is geo Jason
We emphasise extensibility
Arnaud: are you asserting that everything should be over HTTP?
Vlad: no, but if you are building an application in an open environment, then yes
If you are interested in using lots of data from a database, the protocol used to push the data to the database could be another protocol like MQTT.
But the apps should use HTTP to access that database.
<Karen> scribenick: Karen
"Open Source Projects for a suite of Web of Things Services
... talk about open source projects
... idea is WoT is distributed platforms
... follow link to more slides
... different platforms from different vendors
... can we use abstraction layer to connect them
... different protocols are appropriate in different contexts
... if we can do this, we can do in different scales
... small to embedded servers, to home hubs
... or up into the cloud based server farms; big data services
... can we apply this abstraction layer
... Different devices has different requirements to support correctly
... cameras that extract in real time; privacy in healthcare,
... sense of networks; large number of sensors with lots of data collected
... push interpretation to network edge so we don't flood the network
... perhaps push scripts into servers
... and likewise push control to network edge; to groups of servers that are synchronized, like robot hands with many separate controls for each joint
... At Munich meeting we talked about accessing things from web browsers
... a web page scripting library for accessing things
... Made a list here
... HTTP
scribe: Web Sockets, CR
... Server sent events, Rec
... Push API, working draft
... WebRTC, working draft
... allows data channel to be used peer to peer, one device to another
... All is restricted by browser security model
... Implementation work used HTTP to access models and WebSockets for the messaging
... Resource headers
... Why should we put effort into open source
... Go back to early days of web where servers played a vital role in growth of the web
... Rough consensus and running code vital for success of standardization work
... Reading out to people, a number of projects underway
... at very beginning
[Slide references various GitHub projects]
... Lots of horizontal metadata
... early stage projects focus on data models
... lots of work to be done
... Data models allow service to create a bunch of objects
... allows developers interactive things; reduce cost of building applications
... idea is not to standardize models but to standardize the vocabularies
... have to know what they mean
... we've seen some of these things
... property values of basic types
... Json, events that can carry data
... Example of hotel room door handle
... to bridge gap between web developers who are not keen on SemWeb
... Json LD is pretty effective there
... events for door, light switch
... property name and type
... or types of stream as object which is next level down
... could have another object for next level of annotation
... Json LD is cheating; hiding the linked data
... says things like bell or key
... can be connected to URIs, but can be suppressed
... if we have a thing description language, then we can register default context at same time, and mapping of URIs
... provides simplicity
... additional context is provided
... We can also have things as agents
... idea is to use things as a means
... How to do this
... Starting point is the data model
... Two APIs; one to register the thing
... sensors, actuators
... server creates a virtual object and binds that to @
... Can use proxy fora thing on another server
... provide URI for data model
... Can chain proxies across services if needed
... Different servers may support different protocols
... Find out what that service supports
... All up in the air
... GitHub projects have some suggestions for how that might be done
... Looking at embedded systems
... Microcontrollers have kilobites
... change in capabilities
... have a whole bunch of stuff [reads from slide]
... devices have different cycles
... a lot of them use the Harvard architecture
... other devices like timers
... support standard buses
... How to turn on a LED
... digital converters
... Can we build momentum through WoT through the Maker Community?
... do some hackathons next year
[reviews photos on slide]
... these devices are low-costs
... some have wifi built into boards
... lots of sensors
... So we could make a community, do hackathons
... Demo ideas I'm working on
... Temperature and humidity senor
[describes images on slide]
... bottom one is electrocardiogram, not medical grade
... you pass cleaned up signal from chip
... analog to digital converter
... Idea is to see what we can do with a small amount of RAM
... use static memory
... find compact encoding like six bytes per node
... not C++ have to find way to handle objects
... Looking at ways if both servers
... in communication have access to server model, both can compress information
... In principals, don't have to download them into the device
... Lots of possibilities for maximization
... Hello world Arduino Sketch
... My minimal implementation of Agent using C++
... it gets called when thing is set up
... make mapping from names to symbols
... sets up an event listener
... C++ does not know about Json objects
... scratch events pulls and dispatchees
s/dispatches
... Has to be work to avoid MCU blocking
... use interrupt rather than blocking calls
... extra work to do
... Using timers
... for timeouts
... Dependencies across things
... One thing may depend upon another
... Means you have to set things up in a way that's distributed and synchronous
... Got it on @ server but not on Aduina
... Strong security plans neeeded
... In US, NIST is encouraging strong security
... to develop trustworthy systeme
s/systems
... Small devices don't have enough resources
... option to either use system on a chip devices or other chips
... Can combine these things to make a low-cost but secure device
... Looking to help with these open source projects to push through
... Looking for offers of help
... people who want to contribute to open source, or to provide resources to help
Juerg: Thank you, Dave
... Any comments or questions?
Johannes: I was wondering about different servers; did you manage to connect them?
Dave: We're not there yet. Looking to create test cases and test beds to support that
... smaller devices support one or two protocols, but larger devices support many more protocols so it makes it challenging
Joerg: Further comments?
Dave: If you want to see more details on open source projects, catch me over the next two days
Joerg: yes, we'll be discussing that on Friday
... how test framework will be worked out; use some coffee time for that
... Looking at today's agenda
... Today we had on one hand, review of IG activities and your contributions
... Tomorrow is to split up into the task forces
... Look at road map
... Prepared discussions and that will be done in the TF again
... We will have something a lunch about this
... Find more details on the wikis of each TF
... Please take a look; we will split up tomorrow after a short joint session
... Be prepared to have some hand raising to see size of groups
... That is tomorrow
... We have another agenda point for dinner
... Table reserved at Pedro's restaurant
[shows map]
... meet in one hour
... Looking forward to further discussion
... See you tomorrow at 9:00am tomorrow
<dsr> scribenick: dsr
Joerg runs through the agenda for today and for tomorrow.
<kaz> Agenda: https://www.w3.org/WoT/IG/wiki/F2F_meeting_29-31_July_2015_in_Sunnyvale_CA
He invites Karent to say a few words about outreach. She proposes to moderate a lunchtime discussion on outreach and how we might want to address a more business focused discussion of the impact of the Web of Things, as she won’t be here tomorrow.
Joerg displays a diagram depicting the WoT IG timeline. We need to conclude on the model of building blocks and agree of the set up for the technology landscape.
We need to plan out work over the next weeks in the run up to the Sapporo face to face in October.
Joerg invites the task force leads to present their aims for today’s break out sessions.
Sebastian introduces his plans for the thing description breakout. We aim to define a minimal vocabulary for thing description data models.
We should discuss some use cases and see how they map into JSON-LD. If there is time left, we will need to discuss how to define the data types, as well as plans for implementation.
He asks for a show of hands for how many people want to joint the session [5]
Johannes introduces the break out for the APIs and protocols session.
He wants to prepare a consensus for the report back. The resource model, architecture, technology landscape, examples of protocol mappings, white gaps and next steps.
Johannes has prepared a form on GitHub for collecting input for the technology landscape from each task force.
A show of hands [8]
Oliver introduces the security and privacy session. So far we have only collaborated using the phone and wiki.
I want us to share ideas and propose a Scrum style mini workshop on sharing the meaning and plans for next steps.
show of hands [2]
Joerg: each breakout is responsible for taking minutes in their respective IRC channel
The APIs and Protocols session will remain in the main room. The thing description session will be in room 115, and the security and privacy discussion will be in room 120.
We meet back here at 12:30.
<kaz> kaz is taking notes for TF-AP on #wot-ap channel
<kaz> please join #wot-ap for WoT AP-TF
<kaz> sebastian: makes report from TF-TD
<kaz> johannes: makes reports from TF-AP
<kaz> TF-AP minutes
<kaz> oliver: makes report from Security&Privacy
<inserted> scribenick: kaz
Sebastian: makes report from TF-TD breakout
Johannes: makes report from TF-AP
breakout
... architecture model
... technology landscape
... lifecycle states
... abstract resource model
... complete and transfer Tech Landscape
kaz: we did great discussion and got
a basic consensus yesterday (and probably today as well)
... but given not all the IG participants could attend this
meeting, we'll bring all the results to the telco, etc., and let
the other participants as well know about the result. Right?
johannes: right
joerg: makes report from the
TF-DI
... sketch of landscape
... relationship with TD
... discussion on requirements
... discovery should be independent of the communication
technologies
... communication technology should be visible in the
metadata
... things should be capable to automatically register
themselves
... interaction patterns of discovery categories
... evaluation criteria for discovery tech landscape
... next steps: complete evaluation criteria, conduct evaluation of
discovery tech
oliver: makes report from TF-S&P
johannes: will have discussions on interaction, security model, etc., during the upcoming calls
joerg: what's the best to discuss
security&privacy?
... atomic use cases on security and privacy
... mapping and deep understanding
... how the different TFs started their contributions are different
with each other
... wondering about the best way
... initial contributions are made on the wiki
dsr: don't have strong opinion at the
moment
... GitHub is accessible as well
... issue tracking through pull request is available
johannes: just took a template
... looked into the wiki to see tech landscape
... got pull request from Jonathan
... GitHub is a possibility
... as a resource control system
... can continue to use wiki
... and make a decision when to transfer the content
... it's just copy&paste
joerg: working draft of
deliveralbles
... format:
... continue the wiki until structure is confirmed
... for finalization benefit for tracking in GitHub
... structure of the documet has been proposed
johannes: have some
contribution
... valuable to keep them
sebastian: overview landscape on the
wiki
... can put it on GitHub
joerg: initial contributors provide support to the document structure
sebastian: yeah
johannes: three TF moderators should work with each other
joerg: review of TF of the document
structure
... evaluations supported by contributors
... next step: ask for support in evaluation by controbutors
... sync in cases, where technologies are studied in several
TFs
<dsr> scribenick: dsr
Jerry introduces himself. Delta Electronics was formed in 1971. We have a broad business areas focusing on power electronics, etc.
We have sites all over the world. I come from Delta Research Center.
We are like an incubator for new ideas.
<JonathanJ2> Delta - http://www.deltaww.com/default.aspx?hl=en-US
IDC says the IoT market will reach $7.1 trillion by 2020. We all want a place in this market, but it isn’t easy.
There are many niche solutions from a long tail, and a fragmented market
Low popularity and difficulties in crossing domains.
We need to adapt dynamically to the client’s requirements. They may not know what they want, but do know what they don’t want
A common platform would increase economies of scale and reduce the costs.. We need a loosely coupled architecture.
We want to build commonalities on the IoT ecosystem.
Our current focus is on smart manufacturing, smart life and smart service
We plan to combine existing Delta business and needs to create IoT solutions.
We are working in an IoT common programming model. This currently uses Java but we want to also support JavaScript. This supports event driven, parameter driven, dynamic binding and rule based approaches.
We use an ontology editor that is web based and supports multiple views
We have a common component library and a universal kit (multisensory, flexible customisation and edge computing)
Thanks for listening.
Questions?
Joerg: you showed this long tail perspective, however, you also have first movers. Would you be interested in helping us to examine your use cases and the atomic use cases they involve?
Jerry: yes I will look into that
Note that Ravi asked us not to minute this session.
See: http://openinterconnect.org
“The Open Interconnect Consortium is focused on delivering a specification, an open source implementation, and a certification program for wirelessly connecting devices.”
IoTivity is an open source software framework enabling seamless device-to-device connectivity to address the emerging needs of the Internet of Things, see https://www.iotivity.org
<kaz> scribenick: kaz
dsr: we're an IG
... we're developing use cases and requirements
... would talk about possible WG
[ From the Web of Pages to the Web of Things ]
[ Web of Things ]
dsr: clarifying the idea of proxy
[ The Web as the Global Data Bus ]
[ Horizontal & Vertical Metadata ]
[ Focus of W3C Contribution ]
[ Role of WoT Interest Group ]
dsr: collecting use cases
... studying requirements
... reachout other groups and share vision
<scribe> ... ongoing role to support work
[ Web of Things Working Group ]
dsr: proposed scope and work
items
... define a core vocabulary for describing thing data models
... define a serialization to JSON-LD
... define bindings to common Internet protocols in collaboration
with external groups
... define a vocabulary for servers...
[ Some Considerations ]
dsr: need to check WG's decisions are
appropriate for a range of stakeholders
... also horizontal reviews
[ Data Models - Objectives ]
dsr: standard vocabulary for thig
data models will enable servers to construct virtual objects
... enabling developers to interact
[ Data Models - Details ]
dsr: what kind of data type?
... building atomic use cases
... complex types including lists and maps from names to
values
... analogous to "typedef" of C language
[ JSON-LD ]
dsr: RDF, JSON-based serialization of RDF, need for JSON-LD
[ JSON-LD and Data Types ]
dsr: RDF re-uses many of the XML
Schema built-in datatypes
... JSON-LD context would allow "boolean"
... application/tdl MIME type
... additional terms: events, properties and actions
... stream data type
... "writable"
[ Bindings to Protocols ]
dsr: standard for how to signal
events, property updates, action invocations, action results,
metadata updates, etc.
... need to define this for common protocols: HTTP, Web Sockets,
CoAP, MQTT, etc.
[ Compact Encoding ]
dsr: limited memory/packet
sizes
... very high throughput
... data model of a thing
... compact encoding of JSON/JSONLD
johannes: why would this require us to form a new WG?
dsr: not sufficient this group to do
standardization
... possible to joint work of the proposed WG and this IG
johannes: some thing special on
WoT?
... there are already WGs on this work
... what is the real difference?
dsr: IG can't do
standardization
... need to talk with WGs
... what is the expected relationship with other groups can be
clarified in the Charter
johannes: horizontal technology like JSON-LD
dsr: a WG is needed for actual standardization
johannes: any specific WGs who are already working on our topics?
dsr: WoT datamodel could be a topic for the new WG
[ Out of Scope ]
dsr: vocabularies for specific
application domains
... work related to security, assurance, prvacy and
resilience
... could be added to future versions of the WG Charter, though
ravi: won't do fundamental work on security, but some security-related discussion possible?
dsr: narrow enough description is expected for the new WG's Charter
[ Opportunities ]
dsr: where there is a clear need based on agreed use cases, the WG could standardize vocabularies
[ What Next? ]
dsr: W3C staff contacts to prepare
draft charter
... use GitHub for review and update it based on feedback
... identify candidates for the role of the Chair
... seek approval from the W3M
... AC review comments
... lanch the new WG
... first f2f
sebastian: WG vs IG?
dsr: IG does pre-standardization work
sebastian: not clear to me...
dsr: WG could do vocabularies, etc.
sebastian: doesn't make sense to simply stop the IG?
dsr: WG need to have a narrow
scope
... IG can have broader scope
johannes: regarding the narrow
scope...
... you mentioned some points in your presentation
... but didn't quite understand it
dsr: (proposed scope and work
items)
... core vocabulary
johannes: negotiation for protocol
mapping?
... make sense to have a bit more tight scope
dsr: two set of vocabularies
joerg: might want to identify our
need
... IG started 3-4 months ago
... we're still on a transition state
... wonder if this is a trigger
... one of the points is that this IG is expected to identify
requirements
... should we try to trigger new work for the WG?
... not sure if we already shared our understanding
... collecting tech landscape
... how to process compiling our deliverables?
... comments?
jonathan: how many deriverables?
dsr: 4 (plus optional one)
... after lunch we'll have discussion on implementation
Simon: would agree with Johannes that we (IG) could work with other WG
@@2: interested to see the relationship with OIC
scribe: duplication with their work?
ravi: see some complementary
aspects
... semantic information independent of tech domains
... internet protocols
... resource modeling aspect
... potential conflict
dsr: possible collaboration with this group
ravi: just for answer to the previous question
Arnaud: WG is chartered for
specification
... that is the biggest difference between WG and IG
dsr: W3C don't have to define
concrete mapping for websocket, etc.
... can work with IETF
johannes: need clarification
... your opinion cover APIs?
dsr: bigger questions
... maybe standardized or maybe not
johhannes: protocol binding?
dsr: how to express it?
... there is a need for collaboration
joerg: based on the discussion so
far, what would be the realistic way for us?
... would take this as a trigger to start discussion
... on scope, relationship with this IG/other groups, etc.
[ Lunch ]
<yo> quit
<dsr> we resume after lunch.
<dsr> scribenick: dsr
Joerg summarises his expectations in regards to collecting input for the working group charter.
(see his slide)
In respect to teleconferences, we’ve been rotating task forces through time slots. Some people are asking for fixed timeslots saying that this will be more convenient in practice.
The proposal is to have APIs and Protocols on Wednesday and Thing descriptions and Security and Privacy on Thursday.
Any other proposals?
The idea is to have calls at 4pm CEST on Wednesday.
Kaz: I agree that it is better to have calls at fixed slots, but I personally couldn’t make the 4pm CEST call.
<kaz> sorry but I mistook 4pm PST for 4pm CEST, so should be able to make 4pm CEST :)
Joerg asks for a show hands for keeping the rotation (none) or fixed times (around 6 people)
Joerg: we need to find the fixed timeslot according to the people interested in a particular task force.
Kaz: 3pm CEST would be 10pm in Japan and 6am in California
Joerg: we may make the call up to 90 mins.
In respect to face to face meetings, we have TPAC in Japan in October this year.
<inserted> TPAC 2015 in Sapporo: 26-30 October
He proposes Europe in January, and wonders if we could co-locate with the W3C AC meeting at MIT in March.
Dave: I can check to see if that is logistically feasible
Joerg: this would be followed by a meeting in July in Asia.
Joerg asks for people to check if they companies could host the January and July meetings.
Joerg: I would now like to discuss opportunities for joint meetings e.g. with the IETF
He asks for a show of hands in respect to the Yokohama IETF (1-6 Nov. 2015) the week following TPAC.
About 6 people put their hands up.
Question: would the joint meeting take place between TPAC (26-30 Oct. 2015) and IETF meeting (1-6 Nov. 2015) or during the IETF meeting?
Joerg: we propose the Saturday (31 Oct. 2015) and Sunday (1 Nov. 2015) in between.
Osamu offers to help with meeting rooms in Tokyo.
The focus would be on joint discussions with WoT TF AP / T2T Beyond REST, as well as privacy and security.
<scribe> meeting: Web of Things IG, day 3
<scribe> chair: Joerg
Joerg asks for volunteers to help with preparing slides for addressing the IoT vertical perspective.
Dave: the W3C staff contacts and Business Development staff could help.
Joerg: at TPAC we can have a demo session and should start to plan for that.
Joerg: can we aim to support demo sessions and a plugfest at TPAC?
Can we agree on some guidance on this and possible links to the IETF Thing to Thing activities.
<kaz> Announcement on demo area during TPAC 2015 (Member-only)
Joerg: at the IETF T2T session, the approach involved agreement on a restricted scenario, and to explore how REST can be applied.
Johannes: We have the idea that three people will create implementations of entities that can communicate with each other and then see how well they interoperate.
This involves setting out some minimal set of ground rules.
Johannes: who is interested in participating in such a plugfest?
Vlad: we have had some experience with this at EVRYTHNG
Simon: we’re doing an implementation with Andrea of T2T.
Johannes: Michael is also working on an implementation.
So we have the potential for several implementations, and need to agree on the ground rules.
Simon: agreeing on a TDL data model vocabulary should be easy enough.
Johannes: we would need to agree on the protocol bindings.
Simon: T2T is focusing purely on REST, which is perhaps oversimplifying the set up
(Dave worries about details of protocol bindings and encodings)
Johanes: I will set up a page on GitHub for us to work on the ground rules for the plugfest.
Dave: we would need to avoid developing servers without any protocols in common.
Johannes: we could create a register (table) listing implementations and the protocols they support.
Joerg asks Dave for his comments.
Dave: this sounds quite ambitious given the Summer break and other commitments. Another idea is to ask people to try to build IoT demos with other people’s Web of Things servers.
Kaz: what does plugfest mean? Maybe Japanese members are also interested in providing IoT demos
Dave notes that he is aiming for having servers ready for other people to use in 2016. October in 2015 is probably too ambitious.
Joerg: if people are just building on REST perhaps they don’t need to do so much coding from scratch.
Dave offers to show people the details of the code he has been working on the Arduino C++ and the NodeJS projects.
Johannes: the aim is to show case the building blocks we are working on.
He shows a slide describing the T2T framework scenario.
Kaz: very interesting idea. How about using some Japanese smart home devices for demo purposes.
kajimoto: Can we also have demos for the WoT principles?
Johannes: if we have some interesting use cases we could indeed feature them
Kaz: some of the Member companies
might want to provide their own demos.
... The W3C TPAC management team are currently seeking ideas for
the demo activities.
Joerg: how would we collect the proposals, using GitHub?
Kajimoto: we don’t have a concrete WoT specification as yet, so we can set up two kinds of demonstrations (plugtest and IoT demos)
Kaz: maybe Fujitsu, Toshiba, etc., also will have their own demo ideas, and anybody can put their ideas on the GitHub demo wiki
Dave: I am planning on some demos around the Arduino and some common sensors: DHT111, BMP180, HC-SR04 and the AD8232 ECG board.
Joerg: given the Summer vacation period, we need to have the plugfest ground rules in place within a week or two. Let’s say 8th August.
Kaz: so the demo proposals are needed by 15th September according to the W3C TPAC team.
<Kajimoto> <kaz>Demonstration of Application dead line is Sep. 15
Joerg: if there are no further agenda items, then I would very much thank Fujitsu for hosting is, it was really a pleasure and a nice environment.,
Joerg brings the meeting to a close.