Breakout Session Minutes

Summary

The participants of the breakout group on Service Descriptions deem it useful if the W3C published recommendations for device vendors and service providers about how to describe Web services. These descriptions should encompass functional as well as non-functional aspects of the service, i.e. should describe its basic functionality as well as input/output data and also aspects such as QoS, access rights, etc. This recommendation should focus on the concept of different services within the IoT than producing a technical specification. Furthermore, the participants emphasize that these descriptions should be targeted at developers. Device vendors and service providers should prefer simple APIs and also keep the service descriptions themselves easy to understand by hiding details of the underlying protocol. Service descriptions should thus facilitate the work of developers rather than targeting applications such as automatic service composition right away. Finally, to ensure good uptake of descriptions by the community, they should emphasize describing aspects of services that are relevant for service providers (e.g., with respect to monetization), for instance information that relates to finding a service, reviews, or payments.

Minutes

Backdrop and Requirements: Big expectations for services market (309bn, Gartner), i.e. *services* matter, sensors less - Interoperability is crucial!
- Platforms are valuable because of developer communities (network effects): How to make developers use "my" platform. Idea: Make it easy for them to monetize their work via the platform (findability of apps and services etc.)
- Highly heterogeneous application domains stipulate highly varying requirements on latency, scalability, fault handling, etc. - no one-size-fits-all
- Require common terminology w.r.t. service descriptions: Need to talk about the same thing - are we talking about services that are bound to a specific sensor, a class of sensors, a template for a sensor platform, etc.
- Abstraction Layers: Interpretation of sensor data w.r.t. context; Control commands in a synchronized and fault-tolerant/adapting way; Not necessarily req/rep, could be pub/sub

Creating Services
- Several different programming languages (JavaScript, Java for enterprise environments), several different abstract models for creating services
- Consider resource-constrained devices: XML is expensive when data is short. Does EXI provide a way out? XML != XML: EXI for efficiency; Consistent definitions via Infoset?
- Could standardized protocols make the choice of language obsolete - just like the browser!?
- Services at the Network Edge: Idea is to provide a standard framework that developers use to create services and that bridges (cloud) platforms

Service descriptions example: JSON(-LD)
- JSON + Linked Data "@context" to add semantics on top of JSON documents
- Remark: Discussion changed fast from discussing semantics to discussing API syntax
- Node-Red model: describe service composition and publish it, focus is not on execution platform
- JSON misses something like XML Schema. XSDs are great, we should have it for JSON. Important for M2M scenarios, data type definitions: Standardization gap here? It's possible to use XML Schema to validate JSON, however! Lighterweight XML grammars required?
- Take-home point: Efficient schema representations are required for data formats, both for XML and JSON

What should service descriptions consist of?
- Suggestions: API dependencies, exported APIs, ownership, developer ID, human/machinereadable descriptions, reputation, reviews, audits, payments, access control, semantic data, basics for enabling context-awareness -> i.e.: both non-functional and functional aspects
- W3C looking at payments for services

"APIs vs. Protocols"
- Is the WoT equal to a device exporting a REST API? Is it enough to export something that can be mapped to a REST/HTTP API (do we require standards for such drivers)?
- Service descriptions must focus on developers: Prefer simple APIs, hide protocol details, do mapping of internal and external IDs
- Can we define standards to help people find device drivers?
- Problem with having device vendors provide a way of finding out what the capabilities of a device are: No pressure on vendors to get it right, i.e. this targets the wrong end of the value chain. Perhaps better to have people provide open descriptions or devise a system that ties correct descriptions to business value

Analogy to Linux Packages that also expose dependencies, versioning metadata etc. (clear advantage over platforms without package management)
- Need something that works across clouds from different vendors - standardization required?
- Access restrictions must be modeled together with dependencies

Socially Aware Services: Models of devices, people, and their relationships (locations, friendships, etc.)
- Webinos "Personal Zones" to allow specific people to access specific services within own personal zone that includes "personal" cloud-based services. Central hub that manages policies, could also be done P2P (but tedious!)

Describing devices and services
- WebIDL is used a lot, could this be a basis for service descriptions? Probably not use WebIDL directly because there are additional constraints on interoperable services:
--- Machine-interpretable representations. Many labeling standards already used by the industry - can these be included in a new standard?
--- Access-control policy and integrity constraint specifications
- If data model is too weak, system will fail: why didn't Ricardo/IBM type its Node-Red composition platform. Is typing required specifically because we target physical environments because it is crucial that we don't input e.g. wrong units (+ is this still "typing" as it already require stronger semantics)?

Dave's camera example: could use WebIDL-like syntax to describe the API, but this doesn't do semantics i.e. give the meaning of values
- Service description: developer, version, owner, api (IDL contains input and output), behavior as behavior.js
- "What a Web application does cannot be described declaratively" - is that true?
- Final Goal: Purchase device that has a public API that humans understand. Write a Webapp. Done. What is missing on top of this is an enabler of an "open marketplace" (see above) ("Aren't all those open HTTP APIs out there already a open marketplace?" - No, because vendors are not exposing API information that one can make good sense of... just too cumbersome to understand for developers!)
- "Don't recreate WSDL" but rather define minimal best practices for device descriptions, e.g. how is QoS info presented; should several specific non-functional properties be defined "by default", e.g. "ping monitoring service"?

Summary

What are conclusions? Some interest in conversation. Not clear on deliverables. How to follow this conversation afterwards.

Milan: What is basic problem that we are trying to solve. Configuration changes?

EW) a) not every state change needs to be reported, b) before WOT WG, would need statement of what we are about.

Laurent) Need to create use cases that leverage activity streams.

EW) Look at social web working group and see what they are doing.

Introduction

What is missing from today's web landscape.

1. Protocol/gateway
2. Domain models. Largely exist. Up to domain specialists to refine them. Use to create media type.
3. Find out what is needed. (not a good answer yet). Useful to look on use cases within verticals.

Web thrives on services: People care about what service and available transactions:

Atom feeds used for Pod Casts and other areas currently. Very extensible. Issue was that it was XML based. Basic Atom model of how to expose services is valuable.

Shift to Activity Streams. Already being widely deployed by Google and others.

Possibly collaborate with W3C Social Web WG.

Discussion:

Q) Web services type of approach may not be effective. Devices need to be able to speak to each other without interaction of web services.

EW) Could use activities model with web services model.

Q) Laurent? Works well with Social Web of Things. Represents Object related activities. Rest type API. Proposed protocols to create interactions between social networks. Initially based on ATOM. New draft of Activity Streams (2.0) incorporates some extensions from ATOM. Trying to use JSON-LD as well.

EW) JSON Activity Streams 2.0 document is a bit inconsistent currently. ITF draft will be republished as a W3C draft.

Q) Professor Tashka (SP) How extensible is it in relation to semantics. Progmatics need to be consider as well. Does it have a time model?

EW) Not happy with extensibility model. Nothing on commitment. Does support transaction B2B type of protocol effectively. A time model exists already.

Thomas: Example Mashup services, Gmail with other services but this is currently closed. This and That. Uses ATOM

EW) ATOM has about 10 activities. Extensibility is one of the reasons people like ATOM.

Q) Laurent? Ecosystem of players (social networking players). Likely to be adopted by those who care about users.

EW) How to expose resources so they can be used by other services.

Q) Could push model rather than pull model work:

EW) How you ship information around would be a pull but you could use push as well. ATOM model should work for both. Most people not interested in sensor feeds. Reports by sensors but services can then aggregate it in meaningful ways.

Q SP) Need to be sure it is people interacting with things as well. Not just people interacting with people.

EW) Once Social Web starts we will soon know if it includes web of things as well.

Q)Wolfgang Dorst. Can give examples of typical web of things scenarios and what would not be.

EW) Not a scenario … My car as one system. No external control of car. WOT – Services, tire pressure, fuel economy, smart home scenarios. Control of multiple spaces (home and office) from one service. Healthcare. Monitoring of health. Industry 4.0 (WOT could be one building block).

Two layers: Devices provide raw stream of data which is then aggregated and then high-level activities are generated(Web Of Things). Activities could be tailored to individuals.

Some people may need raw stream of data. Some may be interested in this (research etc). Aggregator could hold and publish raw data as well.

Distinction should be made Web of things and internet of things. Not based on volume of data.

Summary

1. Existing IoT solutions already exist. In particular in the industrial domain (e.g. manufacturing, smart building/home automation sectors), there are vertical/closed solutions. The point is to look at those bu sines models (benefits from linking devices, collecting and storing data, create services on top of data for the companies) and use them for the WoT.
2. WoT will provide new market opportunities, but we need standards to offer an open solution that works like existing vertical solutions (point 1) but at a larger scale. In particular, we need standards about the APIs facing sw developers and hw providers. We also need standards to cover the whole stack of WoT (e.g. security, privacy, etc.). Some standards that could fit do exist. We just need to select them, and in case just cover the existing gaps.
3. Platform for WoT should not be just an app store, but they should be much more. For example: (i) offering richer customer experience (not only sw developers, but also non-experts with innovative ideas); (ii) enabling HW vendors to develop plug-ins for their IoT devices.
4. Revenue models. Some ideas: partly based on SW developers (freemium approach) and leverage tracking the end-user experience to get insight and generate additional services (e.g. ads)

Participants

8 people participated in the session
6 of them were representing companies in the IoT sector (device producers/telco operator/big data solutions)
1 consulting company in innovation and technology transfer
1 W3C business developer

The Platform

It has been described three distinct types of platform:

1. an open platform covering multiple business sectors (google style)
2. an open platform covering one unique business sector (i.e. vertical on healthcare, energy, home automation, etc.)
3. a closed, customised platform for a specific device/hw vendor (apple style)

Current market solutions are most of type 3), and manufacturing companies are really thinking to enter this market.

A solution like 1) it may be difficult to accept for manufacturing companies (i.e. googling to access their devices could lead to privacy issues)

However solution like 2), but also 1), can be the future though they really bring some value to software developers and hw providers.

From a business model point o view, we can simply adapt the existing ones. For example: from the home automation sector, the value goes from deploying interconnected devices, collect data into the reference platform, and then create added-value services on top of it

The platform can be open (enabling third parties to create applications via APIs), but if you want your specific, closed solution you have to pay the adaptation / customisation

The Stakeholders and The Value Proposition

The discussion focused on the possible requirements from the possible customers, in particular device providers.

In order to fit many device vendors, the platform (or better the interfaces to access the platform, i.e. APIs) should be standard

We need reference specifications to drive business models of different stakeholders. And this should/could be the role of W3C

The standardisation should cover:

• APIs for linking devices to the Web of Things;
• APIs for programming on top of the Web of Things
• but also all the necessary layers (stack) within the Web of Things (e.g. security, data/service description, etc.)

The availability of clear standards will boost the market since, for instance, more companies will ask for solution that stick to the reference standards and this will also support the creation of open, reference platforms (marketplaces).

The open, reference platforms should be something more than a simple app marketplace. They should offer a real value on top of integrated devices. For example, from a sw developer perspective, the platform should be an effective Integrator for the IoT.

The Revenue Stream

In order to define opportune revenue streams, we should first distinguish between between industry (e.g. manufacturing) and open marketplace customers (software developers, citizens, cities, etc.)

In the manufacturing sector the customers are aware they have to pay for new devices/services in the IoT. And they would be happy to do it, if the resulting services will introduce a real added-value.

In the case of open platform, who is paying?

Charging SW developers for the use of platform APIs is ok, if, in turn, SW developers can use the platform to sell their applications. Freemium is the best payment approach (and also pay as you grow). Testing and basic services are free. Added value services + additional resources, you need to pay. However, according to current marketplaces, we cannot charge more than 30% of the revenue stream of SW developers.

We should also consider that device providers can participate to IoT platform, if part of the generated revenue can come back to them (selling HWs, Data, etc.) For example, they can offer Hw for free but then you pay the use of the services on top + the idea that at the begging the solution is free and then you move to premium solutions.

Finally, a credible revenue stream to sustain the platform could come from advertising: with the adequate limitation (privacy, asking user permission, etc.), tracking the users of platform applications to check what they want/what they do can create services for selling products.

Notes: Micheal Bruss, DFKI

DFKI introduces concept of digital object Memories based on W3C-XG OMM format

• Idea: show what we've done at DFKI within German research projects, then take a look at workshop participants' experiences, which topics are not yet addressed and should be
• DFKI developed concepts and did an incubator group to evaluate if the idea can be standardized
• Result: it could be done but the activity stopped
• Problem: it doesn't fit perfectly in running activities, new activity couldn't be started because our partners not being involved in W3C

Question by Darko Anicic: What are the competing approaches?
GS1 has RFID standard that is set up well and used already, but it is very focused on commercial use cases. OMM approach is much more open and versatile

Question by Darko: is GS1 focused on special businesses?
Manufactured goods and logistics

• EVRYTHNG approach, similar to OMM, attach memory to object and add key value pairs, but nothing else, it's very simple. implementable in almost every device
• OMM-XG result: too simple for some use cases, you might want more sophisticated approaches
• OMM approach is not perfect but a first approach. DFKI has set up demonstrators using this technology; developed this in two projects, second is now finished

Question by Pedro Reboredo: Point out differences to GS1 approach?
Sample Scenario of production/logistics chain

Question by Yusuke Doi: Scenarios for composed and separated objects?
Supported by OMM (see slides)

Question by Pedro: Why to use memory on RFID chip instead of cloud/server?

Yusuke:

OMM aspects like open-loop scenarios, partitioning, meta data, defined blocks, embedded memory for integrated parts

Question Yusuke: Synchronization between embedded objects and “mother object” after part is removed? It should be well defined where the synchronization is done and how it should be done to avoid for example outdated memories

Question by Darko: How is data from DOMes normally used? How is it queried/retrieved/monitored? Depends on the implementation. Different memory access methods. Depending in the object solutions must differ, pizza vs. aircraft parts monitoring for example. three ways: 1) barcode, data stored on server; 2) RFID tag stores either ID in the tag, data on server or add data info on tag or hybrid system; 3) CPS

Question by Owada: What's the motivation of this project? Is there any specific application that helps to evaluate the idea? Why not go with proprietary systems for each company?
Darko: As soon as it becomes complex it will be helpful to be so flexible
Jens: It's a research approach and we want to allow everybody to store everything they want. We have two use cases e.g. a lot of info that was present during early stage of production is lost and must be measured/evaluated again, doesn't happen here

Note by Yusuke: also certification of quality is a point, monitoring of logistics, get rid of parts of quality check process. Must comply with regulations of course; another interesting use case, e.g. recycling in cars, consist of many different materials and parts. Recycling company needs to know what to do with which part, which materials can be used maybe RFID can be used to carry this information.

Question by Darko: what's the price point?
barcode “nothing”, RFID depends on the tag from 0,1 cent to 10 euro per tag
hardware cost like readers, depends on the technology you use and application you want to realize; large factories might need thousands of point to read this info

Question Darko: did the W3C group produce an implementation?
formal report, DFKI developed a OMM-library + Object Memory Server for Java and C#, not public but can be distributed, not that well documented at the moment

Summary

13 people attended. Agreement that this is important, a make or break issue for the web of things. Also agreement that it is a very hard issue to solve. Combined data can identify a person even if individual data do not. Little technical enforcement can be done. Trust and reputation will play an important role. Possible to do legal enforcement. Need to find that a breach has occurred. Different opinion on Regulation:

• Regulation is the only way. Regulate heavily and make it cost. No technical enforcement possible.
• Regulators often regulate to specific and misses the bad things. Users take best decisions. Need freedom of contract. Very different regulations in different countries, and complicated with legal action when users and services are in different contries.

Send privacy policy with data. Privacy flags. Problematic in device-device communication if the user has no contract with the second device. Right to revoke access is a minimum requirement. Short term licencing of data might be one option. Data transfers needs to be tracked. Automatic detection of breaches. Users need to know who is tracking them. There is a place for simple rules (like creative commons) to be communicated with the user.

Conclusion: W3C should create a technical mechanism to pass policy data around in the Web of Things.

Summary

There was general agreement that standardization of a WoT Runtime is highly desirable

This group recommends starting a W3C activity or working group to tackle this task

This group recommends inviting several companies with partial or full implementations and/or high level of interest to participate in the activity or working group

Minutes

WoT Runtime Introduction (Ricardo's Presentation)

W3C should develop a concrete proposal for a browser equivalent for the WoT: Application Runtime for WoT

Browser standardization has been a great success for the W3C and has helped create today's most popular application development platform

It is highly desirable to pursue a similar goal for the WoT by leveraging existing technologies standardized by W3C such as HTML5 and JavaScript and applying them to the WoT; Node.js is an example of a starting point for the concept that fits well the WoT and many efforts are already underway utilizing this framework

The WoT runtime needs to cover the spectrum from “headless” scenarios where there is no User interface (UI), to minimalistic UIs (e.g., control panels) all the way to fully functional browsers (e.g., smart signage devices use full browsers)

The WoT Runtime should support the concept of packaged applications to address deployment and connectivity restrictions, as WoT applications may not be pulled from the Web all the time

The WoT Runtime should address asymmetry of device capabilities (from powerful edge device, to Rasperry Pi-like devices, all the way down to small sensors); this asymmetry may require the definition of device-class profiles; at some point, full Javascript may be too heavy for certain severely constrained devices, so lightweight subsets may be required

The WoT Runtime needs to support multi-tenancy, because it should be possible to deploy new applications after devices have been deployed and developed by an ecosystem of different developers — therefore, there needs to be a robust security model defined, similar to browsers, that isolates applications from each other

The WoT Runtime needs to include an API to manage and provision applications dynamically which needs to be protected with a standard authorization protocol (e.g., UMA)

General Discussion

Q (Dave): What is an app runtime?

A (Ricardo): Node.js is a good example of an app runtime

Q (Matthias): The browser was always the client, what are “things”? Clients or servers? In CoAP small “things" are servers

A: (Ricardo) It has to be both and node.js is a good example of that, as it can be a server as well as a client

There was general agreement that the WoT Runtime has tu support both client and server modes of operation

Q: Why have applications on devices and not just cloud? What is the use case?

A (Andreas/Ricardo): There are multiple use cases: a) if everything goes to the cloud you relinquish control (e.g., cannot switch off light bulb if cloud provider is not available), b) privacy requirements may impose that some data cannot travel to the cloud, c) network optimization (both latency and bandwidth), for example there are hundreds of sensors in industrial machinery such as HVAC units and it is not necessary to transfer all that data to the cloud, only filtered data makes sense, also lots of IoT devices in the field need to report information via expensive communication links (e.g., cellular, satellite) and application logic deployed in the device can optimize communications usage by doing such things as filtering

Q: What happens when deployed applications fail? Whose fault is it?

A (Ricardo): Certainly there needs to be good sandboxing to prevent applications from bringing down devices; in addition, WoT Runtime won't necessarily be used to program everything, as there will always be the need for dedicated functionality and realtime control functionality

Q: Node.js seems to have no way of imposing limits (e.g., prevent hanging applications)

A (Ricardo): Multitenancy can be done by spawning separate processes and using Linux containers for sandboxing; it is not suggested to have multiple tenants on a single node.js instance

Q (Pedro): May need a cleaner way to do sandboxing (there is a sandboxing API in node.js already)

A (Ricardo): Agree that this is an area for further exploration

Q (Joerg): We like the idea of distributing logic to devices in the field, but how to cope with different behaviors on different devices?

A (Ricardo): The standard could define a limited number of “profiles” for different device classes; in addition, the WoT Runtime needs to define the expected set of APIs available (for each profile); the Java community attempted this with J2ME, it may have not been a huge success, but there may be some thing to learn from the experience

Comment: There are some cools things happening with Javascript on IoT constrained devices, here are two examples: Espruino and Tessel

Q (Lyon): Do we need to focus on JS, or higher level, such as SCXML state machines?

A (Andreas): It is a good idea, many people use finite state machines in this area to validate systems and it also take care of resource restrictions and being sure that programs terminate, but not a lot of people understand state machines, they understand activity diagrams instead

A: (Ricardo) Also, it should be possible to layer a different paradigm such as state machines on top of Javascript — the models could be compiled to asm.js as target, which can produce very efficient code

Q (Andreas): Why use finite state machines on devices?

A (Lyon): Because Javascript may not be available

Q (Lyon): How do we know that a device can support what I need

A (Ricardo): The WoT Runtime needs to have an API to discover what capabilities are available (e.g., compute power, multi tenancy) in order to decide at runtime whether an application can be placed there

Q (Pablo): Shouldn't there be consistent APIs to access resources? A problem with browser at the beginning was that each did DOM in different ways

A (Ricardo): Correct, the WoT Runtime needs to include definition of standard APIs

Web vs Runtime (Andreas' Presentation)

In Web versus Runtime a couple of things don't quite fit; Runtime has procedures, Web has request/response, Web has URIs, runtime has pointers/references and objects, Web has user agent versus runtime headless server, Web is single party versus runtime multiparty

For example, node-red assumes streaming versus pure form of Web Architecture is request/response

Web vs Runtime Discussion

Ricardo: Streaming vs REST - it is possible to use REST as “control plane” and once the conversation (e.g, channel) is set up then hand-off to P2P or media streaming; us rest to set up and describe the resources

Andreas: Error handling can be a complication

Pablo: Our use cases are 90% streaming; the paradigm should work in different situations; REST according to Fielding is not limited to http, streaming could still be RESTful, some nodes may fail and REST can handle very well

Andreas: what I like about HTTP is its universality, what streaming protocol could replace HTTP?

Pedro: CoAP has “observe” which allows pub/sub; could also have a special kind of get that allows several responses

Matthias: There is no request/response in REST, it is client/server, you can have one request and multiple responses an you can have multipart responses

Q: Are there systems out there that already do what we are looking for? What about Node-RED?

Ricardo: The runtime we are talking about here is below what Node-RED produces

Matthias: We have a paper from 2012 that describes a RESTful runtime container (Actinium) for IoT applications, including sandboxing, REST APIs, application implementing resource trees; we have a working prototype which is Rhino-based and it is not up to the latest version of CoAP, but we could use as reference and source of ideas

Pablo: Why are we talking about REST? We are talking about runtimes, why do we need to tie to REST?

Ricardo: For clarification, when we talk about REST in this context we are referring to a meta-API that it is used to manage the runtime itself, applications can use whatever methodology they wish to implement functionality, so no conflict here

Matthias: Inside the container you have “normal” APIs

Andreas: What about using the runtime without the APIs?

Ricardo: Depending on the specific scenario, it should be possible to deploy the runtime with a locked-out API, if you don't want applications to be installed afterward, for example; by-the-way, you could totally simulate an entire WoT topology in the cloud using virtualization

Jochen: We have browser-specific extensions; you have to be able to write code in languages other than JavaScript (e.g., Java)

Ricardo: There is no reason why we should not be able to have multiple runtimes in a device

Jochen: Current JavasScript runtimes use different APIs for accessing files, etc — this needs to be standardized

Matthias: hybrid apps for mobile devices should aim for something similar

Ricardo: Yes, APIs need to be standardized, not just the runtime; in addition, for constrained devices there need to be lightweight implementations of JavaScript as current node.js may be too big; standardization should encourage optimization as there is room for improvement in JavaScript today

Standardization Process Discussion

Pablo: If we want to proceed a good reference implementation is important and we may need a better JavaScript implementation as the existing one, which is not great

Ricardo: W3C requires two implementations before reaching recommendation status; What are the next steps after publishing the minutes: How do we start a group? Do we join another group?

Dave: We can make a submission and propose a charter

Cuno: Some time ago we did our own JVM implementation for constrained devices; it was a lot of work and it was very costly; at that time we could get royalties, that is no longer possible because of open source popularity; we would be interested in doing something like this but don't know how to finance it

Ricardo: there are a number of companies exploring JavaScript of IoT and they should benefit from this; not sure if browser companies are interested

Dominique: Resin.io is a company doing a JavaScript runtime for constrained environments; they are venture-backed and the are trying to sell their product

Ricardo: Would they benefit from standardization?

Dominique: Probably yes

Ricardo: There might be interest from several companies to contribute to this effort; I will gauge interest from Intel when I return

Andreas: Are we there yet? How pressing is the need to stitch together devices? We are still the early days, from what i can tell as a researcher

Pablo: We will have ~500 devices next year in production; I will try to convince one of my industry partners to get involved; there are a lot of industrial requirements and I need to be able to give my customers a standard way of deploying something on my devices, so I believe this is a general requirement, i.e., deploying logic for the customer

Dominique: We deploy a lot of devices at everything, for example, a champagne ordering button and we need to update the button software? A runtime would be very interesting; we don't build hardware, and having common runtime would be very useful - how to maintain - currently we build code injectors for each platform, which is not ideal

Matthias: Wireless communication companies have many devices out there - some of them legacy - they are working on OMA lightweight to do device management and for customer apps a runtime would be very useful

Dave: Node.js only part of the solution - what is the best way forward?

Ricardo: We could use the community group in W3C and invite resin.io and other companies to join

Dave: There is a difference of cultures between W3C and node.js and this is reflected in the design patterns for APIs

Ricardo: HTML5 got bigger when people started using it - so we should start small

Dave: Also need APIs for platform that hosts these things - make them searchable etc.

Ricardo: Everything should be a URL

Dave: JSON based manifest work in W3C - could be expanded to make them searchable

Lyon: The more declarative the better

Pablo: What you describe sounds more like an open source project than standardization, we should start with reference implementation, then propose standard

Ricardo: I think we should start small, with an implementation that is there already

Paschke: Talk to the event processing community - it shares many problems with this discussion - Oracle, IBM should participate

Dave C-J (IBM): We are supporting node.js

Dominique: Start with node.js, and then extend

Pablo: You cannot propose node.js as a standard - it's an implementation

Ricardo: Agree; node.js is just an implementation that could be used as starting point

Coordination of groups re. DATA

list of W3C standards we would want

A. +1 Activity streams: interaction model, social WG
B. RDF shapes (validation)
C. How to use things such as web sockets
D. +4 Geospatial Data Logical Data Logical and physical reference mapping
E. Reasoning (rules) e.g. for mapping between vocabularies
F. +6 RDF Stream Processing
G. +2 Semantics for constraint devices
H. Annotation (Accessibility, PoI, documents)
I. URIs schemes/resolution algorithms
J. +1 Names, query conventions, metadata definitions: Coordinated developments of naming and taxonomies that helps you ask a set of questions the service would like to ask
K. +2 Agrifood and Logistics: something similar to what is in W3C the healthcare and life science
L. SSN
M. Web scale discovery

Something is done, something is in process (can be influenced)

A. There is a WG (not trying to re-invent FB)
Activity Stream charter is almost ready, will provide use cases from WoT scenarios

B. RDF Shapes is a draft charter starting soon (publicly available).
The draft is about creating a constraint language for RDF. Introduces rules that can be very expressive and powerful to describe combinations (NP complete).
Possible to take an UML module (CWA) to XML Schema (OWA) specifying the closure.
Useful for generating user interfaces (for tools to produce RDF under some constraints).
Pointer to a formal semantics might help understanding what can/can't be done.
Members: group does not exist, we have member support but need explicit representatives of companies to approve it (Siemens, GS1 are interested)
Time dedicated for participation is the real cost

D/H. Spatial Data on the Web Working Group Charter. Draft, going to membership soon.
Scope: it's a join W3C OGC WG. No replication. Not restricted to LD but Linked/Linking GEOdata is in scope.
Out of scope: map annotation, accessibility to map (rendering). Other WG would might come, looking at annotations.
Does it include indoor location? YES, from geodata to spatial data.
Geolocation is not enough, e.g. in healthcare analysis.
Need use cases (e.g. smart building, healthcare, indoor geofencing, automotive)
1st doc: best practices
- how do you describe a location? (competing standards: geosparql/UK/Geo, neogeo/French/LD, ISA vocabularies
- URIs for location
- granularity (different level of metadata, e.g. when you need provenance)
- APIs for returning data (politically tricky): GeoJSON not a formal standard but widely used (not recommended by UK gov.). Discussion in place on when/where to use GeoJSON (with or without some adaptation). TopoJSON competitor.


L/H. Time and SSN (Spatial Data on the Web WG)
Time Ontology used massively, not standardized yet. There will be something compatible, as a recommendation, but might be different)
SSN (backward compatible recommendation coming). Easy ways to use it.
Coverage: earth observation

What about schema.org talking about geospatial things?
When you can/can't use it will come under best practices. Currently there is an interoperability issue between those and SSN, this should be in scope.
Change of SSN to match to schema.org or viceversa point to schema.org ppl to align?
The process for the viceversa is behind closed doors, mostly influenced by the usage.
The group should look at that (yes, in scope for best practices).


Things not planning to do, but discussion can happen.

C. Roger. Try form a community group to see who is interested, what's the focus and if there is enough audience.

K. Monika to form a community group on that. That would help all the logistics and there's huge potential.
Is it not getting too domain specific? It can be in some cases.


E. Loads of initiatives. SWRL no candidate recommendation but the doc is in there (2004)
Any interest in that?
There is interest BUT can we do a post-mortem analysis to see what didn't work, why the need was there and still the need is here now?
Is it all about number of members that could run the group?
Most ppl don't care if it's a standard or not, they have the need and they implement it (e.g. SWRL in protege).
The motivation and effort to turn it into recommendation is difficult and time-consuming (not worth doing most of the time).

Did ever happen other way around: having a standard that is either superseded or withdrawn for serious errors that are causing damages (very rare, maybe happened once).
No retroactive analysis for the stability promise.

Rule-based working group needs member support. A lot of ppl would like it.
RuleML, RIF (recommendation since Feb 2013)

Difficulty of RIF in the variety of rule formats. Maybe better to apply something easier that can be picked up by the community in WoT (light rule format).

G. Constrained devices
Definitions in the capacity.
IETF has a format core-link, http header style link format, meant for constrained devices.
Can be registered with a server for discovery based on relation and attributes.
Devices provide this description embedded in the device as well.
Separate from COAP.

LDP can also be used to send small packages of triples for constrained devices.
JASON-LD can also manage this.

Text-based representation on micro-controller is very expensive.
Special serialization is also in scope here.

No need for a server: Sensor has small semantics links to it. You can discover more through links (e.g. JasonLD).

Openness of semantic description might be a problem.
LD Fragments is also moving which might be a problem from the utility side.

How to incorporate the domain expertise in that? e.g. smart cities domain.
UML might be good candidate for description
Can be part of WoT activities.


I. URIs Possible new working group is intriguing since there is a problem with URIs.
Unicode issue might give different results when dereferencing the same URI.

J. Naming etc.
P3P example: encoded too much of the data model (too prescriptive)
The vocabulary needs to be kept separate from the protocol

Doing all that would enable M.

Open Data includes City Data.
Hypercat, CKAN, DCAT project was about that opening data and being aware.

Summary

- XML vs JSON can be taken to EXI vs. CBOR for the interaction with the internet
- internal, hard-coded data formats for intra-node communication
- common opinion seems is that EXI and CBOR should be sufficient for the constrained internet for end-to-end communication scenarios
- gateway: application and architecture dependent, there will not be THE solution
- security: transport vs. application layer have to be chosen dependent on the application

Foundation of the discussion

- definition of constrained devices: talking about kilobytes of RAM and ROM in contrast to mega- and gigabytes
- for physical connectivity the predominant solution is based on low-power and lossy networks as IEEE802.15.4 and Bluetooth Low Energy instead of ethernet, GSM or Wifi
- packet and frame sizes for these kind of networks are significantly lower on these networks

Architecture of networks of constrained devices

- as of today, solutions using proxies and hubs connecting different silos of nodes of different technologies are predominant
- through new technologies on the network and transportations layers (i.e. 6LoWPAN), IPv6 enables constrained devices become feasible
- this enables end-to-end connectivity between constrained nodes and anything in the internet
- in the discussion it was agreed, that we will not see the one or the other architecture being preferred
- the used architecture is very much dependent on the application and also non-functional requirements

Network stack

- notable requirements for protocols/encondings were identifies as i) interoperability, ii) efficiency and iii) scalability
- on the transport and network layers inter-operable solutions feasible for constrained devices exist, namely 6LoWPAN
- through this end-to-end connectivity on the transport layer is possible for constrained nodes
- on the application layer the predominant internet protocols/encodings are HTTP and JSON and XML on top of this
- for these more efficient binary 'representations' exist, namely CoAP, CBOR and EXI
- for end-to-end scenarios these protocols/encodings were considered sufficient
- for many scenarios (e.g. real-time local node communication) hard-coded proprietary solutions will however always be used -> for connection to the internet these protocols will have to be translated on some kind of gateway

Summary

The concept of the decision loop in robotics where data transits and is transformed or generated through the three main points of the loop: Perception - Decision - Action. Robotics is a large domain where different disciplines interact: sensor data acquisition and modelisation, autonomous planning, electronics, semantic of the human machine interactions, probabilistic reasoning, simulation and hybrid simulation (interaction between real robots and simulated ones), inter-process communication, and a lot more.

A lot of ideas have already be shared around the web of things about the modelisation of data and services which help the processing between the perception and the decision which are in fact only a third of the decision loop.

During this working group session, we have discussed about enlarging this focus to actuators in order to be able to close the decision loop with standards by the modelisation of actions. Actions are the features of actuators. Actuators are a key concern when drawing the interactions people can have with objects. We should not only consider visual interactions but also auditive, olfactory and tactile interactions.

Models always to be thought in pairs with their environment. The action model should interact with the environment model. The data models should interact with the services models, etc.

When considering sets of attached objects (such as robots) we should consider not only the composition of services but also their decomposition accordingly to constraints within the set of objects. Models must facilitate the decomposition and recomposition of services involving pieces in sets of objects.

The Web of things is like Robotics, it covers a great variety of disciplines. The WOT working group should take this into account in the great essence of its composition as it is essential to have strong coordination with other groups working on standards that would define the models of the world which is the objects' environment and also the humans' one.

Present

Red_Boumghar, Kaz_Ashimura, Helena_Rodriguez, Marcello_Missiroli, Stefan_Lueder, Tomoki_Ogawa, Wolfgang_Dorst

Chair

Red Boumghar

Scribe

kaz

Round of Introductions

Everyone introduces themselves in turn.

Presentation

red: (The World of Robots)
... various robots available
... outdoor/field robotics, ground robots, etc.
... (THe World of Robots (Contd.))
... many different robots
... (Robot Interactions)
... describe knowledge
... (Robots and the Web of Things)
... middleware
... (Middleware/Platform/Operating System)
... OpenRobots, ROS, Orocos, Yarp, MOOS, etc.
... (ROS)
... full OS for robots
... have to install all the package yourself

marcello: memory usage of ROS ?

red: it depends of many factors but it is mainly depending on usage of your running modules. In OpenRobots the middleware footprint is very small so it really depends only on your modules.

kaz: realtime capability?

red: hard-realtime?

kaz: yes

red: not sure about hard-realtime
... (PR2)
... Willow Garage
... smart home
... fake appartment
... this (in the picture) is a big robot
... (Open Robots)
... two main pieces: module generator and middleware
... you have to call libraries
... modules do mapping

tomoki: controller (processing module) on the cloud-side or on the robot locally?

red: it may be anywhere, just a need to consider having a good connection for large data transfers
... (MANA)
... different models have different priority
... directly handle actuators
... decision of layer

kaz: question about network within a robot?

red: robot itself has a local network
... also has a gateway for remote connection

marcello: artificial intelligence inside?

red: yes
... transform data for understanding
... model behind the data

marcello: higher level rather than lower level?

helena: how complete information need to be?

red: depends on what you want to do
... the whole environment is probabilistic

kaz: using HMM, etc.?

red: yes depends on the project
... but constraint on resources

stefan: influence of behavior
... local things to do?
... connected to other apps?

red: robot itself is an application, but could work with the others
... should be autonomous

kaz: so a robot is an autonomous system
... and could work with the other robots and/or apps collaboratively

red: right
... motion behavior
... connected to some specific places
... (MORSE)
... open robot simulator
... contributed to it myself
... exchange data using the same middleware
... simulated a helicopter robot
... while a ground robot is a real one
... as if both of them were real

kaz: so you can make the helicopter fly on the moon

red: yes, in simulation

marcello: discovery?

red: they know each other

kaz: so they have local IP addresses

red: yes

helena: service oriented

kaz: and there is a specific gateway for those two robots

red: yes
... (Models around a robot)
... perception, decision and action

helena: interpretation of actions?

red: climbing, etc.
... robots are supervised
... there is a stereo-camera
... but sometimes doesn't work in case of fogs
... maybe need radar/laser capability
... this means replanning the chain of actions

helena: natural language?
... good English vs. bad English
... depending on the culture

red: working more on human-robot interaction
... representations of what the human feels, knows, etc.
... emotions, feelings
... information acquisition strategy
... (Models around a robot (Contd.))
... perception model
... communication model
... localization model
... motion model
... etc.
... we have to integrate models for WoT
... for objects to talk to each other

wolfgang: sensors but what about actuators?
... most people have been talking on sensors during this workshop
... what we need reactions to people made by actuators
... e.g., move to a specific place
... why this side was not mentioned?

red: motion model is related to actuators as well
... in my way, the motion model is an action model
... e.g., fast, slow, mid depending on what is the terrain
... depending on the data content of the environment model

marcello: question on granularity

helena: perception of object divides into two pieces
... also that is a periodic activity
... multi-modal interactions can handle that
... we should understand well the input-output cycle

red: the system itself communicate
... there is a decision loop
... and use actuators
... evacuation from accident at a gas station
... feedback from a vibrating actuator within a belt

wolfgang: multi-modal itself is different from feedback, isn't it?

helena: multi-modal handles both input and output
... based on a specific mechanism
... robotics use multi-modal interactions (input and output)

red: yes
... e.g., camera and arms
... human has the ability to selectively focus their attentions
... demonstration with counting basketball passes of one team

tomoki: safety?

red: there could be a big loop and a small loop

helena: directly from perception to actions

red: yes, reactive decisions

kaz: that's an event-based loop, and the robot can get any interruption at any point

red: right

wolfgang: got some comments from the industry side saying "realtime is not possible"
... the internal logic calculates how long the required task takes

red: human talks with robots

helena: low data captured by sensors could be classified into two categories, important or not

kaz: mentions his work on realtime speech dialog mechanism
... esp. the importance of selecting responses based on the processing time, i.e., time critical or not

marcello: different levels of sensors

red: you could have a camera on your car and that car in your garden
... but not be able to view your garden with you car's camera

... moving is important

helena: make my air conditioner cooler or hotter
... search of services
... this is a big issue

red: how to change its behavior
... how the IoT interacts with things

helena: based on user behavior

red: (Data)
... what is used for robotics?
... scalar values
... vectors of scalar
... matrices
... set of layers/vectors of matrices
... metadata

kaz: what kind of data format?

red: integer, etc. for scalar
... images, occupancy grids
... every information or thing must be geolocalized

kaz: does the middleware can handle matrices directly?

red: yes

helena: semantics?

red: can be handled

kaz: what kind of format is used for metadata?

red: GPS line data for location

helena: what about symbolic data?
... e.g., need to specify the time specifically?

red: yes

kaz: wondering about time difference
... some specific time, e.g., UTC, is used?
... esp., for your robots?

red: e.g., UNIX timestamp
... another important point is the origin of location

kaz: synchronizing time and location is essential if there are more than one robots
... this point is important for WoT as well

red: (looking for video demo)
... accidents will happen because of misunderstandings between machines and humans
... for instance a part of plane accidents occurs because of misunderstanding between the human pilot and the auto-pilot
... that is the focus of this demo about selective attention