W3C home > Mailing lists > Public > public-wot-ig@w3.org > April 2015

Report on Things Description Language breakout session

From: Francois Daoust <fd@w3.org>
Date: Tue, 21 Apr 2015 18:18:45 +0200
Message-ID: <55367865.1050307@w3.org>
To: public-wot-ig@w3.org
Here is the report of today's Thing Description Language breakout session at the WoT IG F2F.

Thing Description Language breakout session

Starting point
- Analogy between the Web of Things and The Web of pages
- Proxy for things, IRI for addressing, HTTP, and Thing Description Language (TDL)

Review of the description language
- Data owner. Note the owner of the data may not be the owner of the device.
- Purpose: for users and for machines to understand. Informal human language is probable going to be valuable. Purpose is really just a description.
- Version
- Access control: who can use your data and for what purpose
- Terms and conditions: usage conditions. Contractually binding relationship. Whether we want that to be formal or not is entirely up for discussion.
- Relationships to other things: important to expose, so that search engines can index the Web of things. Also enables dependency management (analogy with Linux package).
- Security best practices: still fuzzy but there might be something to include

Reviewing the JSON-LD example
About property values: if you request temperature value, you could have either the raw value or you could have a full JSON-LD document that gives the value, its unit, etc. Architecture should perhaps accommodate both possibilities.

Generic goal of the description language to make things simple for developers.
Values tagged with metadata can also have very important use cases.

Media type per class of things? One media type for everything and then vocabulary. And then you might want to bind some properties to specific protocols. Granularity of desc. Role of content-type.

Mapping between CORE Link (derived from HTTP Link) and JSON-LD? Different levels of description. For discussion. Some on-going standardisation efforts at IETF on CORE Link.

- Discovery based on non-intrinsic properties should be possible, those added based on the context and those added as the result of further processing (e.g. domain-specific metadata). Action: look at "Object memories" work done in a Community Group.

- Basing format on triples (JSON-LD, RDF) makes it easy to extend the base schema.
- Note there could also be some unformatted tags attached to the description for discovery.

- Something to address: break down purposes of discovery. What are the things that we want to discover? Things? Services? P2P discovery? How does everything get set up when you bring a new device to your local network?

- Some overlap between discovery and provisioning. Provisioning is about entering configuration information into the system, discovery about using that configuration information.

- Remote discovery? Local discovery is usually based on multicast on a particular sub network. For remote, people are usually talking about extending mDNS beyond the network boundaries. Important to distinguish between the cloud situation and the local situation.

- Provisioning can be about provisioning a single device, or hundreds of devices at once.
- Provisioning is tricky. Typically requires human interaction for security because it depends on the device capabilities. Not sure at which level the IG will want to address that area.

- Also, how do you validate the identity of a thing? You want some confidence that some attributes are correct. Maybe not something to work right away, but might be important in the future.
- Besides security, resilience is another issue. At the device level, we're not equipped to face DoS attacks on a thing? At the cloud level, years of experience have led to best practices to mitigate the issue (caching, redundancy, load balancing)
- For semantics, we usually think RDF. But there are other alternatives that could be considered such as Thingsonomy or project Haystack (building automation).
- Looking at the resources created by things, and the syntax of the data formats, the payloads would be useful. We may want to create a URI for each property in the REST API, thus creating a hierarchy of URIs. We need to look at use cases to select the right granularity. In constrained environments, you may need PATCH to update only parts of a thing property.

Several of these topics are already addressed by other organizations (ETSI, OMA, etc.). RDF Streams Processing group at W3C also looking at getting semantics to the things level.
One idea would be to invite experts to some call to explain on-going works in the field.

Some leads, but practical details depend on the granularity level.
It would be worth to condense that and separate what falls into the scope of the Thing Description Language and what touches on other topics.

Received on Tuesday, 21 April 2015 16:18:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:26:28 UTC