W3C

- DRAFT -

Thing Description Task Force call

16 Sep 2015

See also: IRC log

Attendees

Present
Regrets
Chair
Darko
Scribe
dsr

Contents


<scribe> scribenick: dsr

Michael Koster to present: Hypermedia Design for Machine APIs

This presentation references the work by Roy Fielding on REST and work by Klaus Hartke.

Michael gives a definition for REST - represntation state transfer

In 2008 Roy wrote a new article on the need for hypermedia as part of REST APIs

Hypertext has been around for long time, e.g. with HTML’s links and forms.

Present: Dave Raggett, Dark Anicic, Michael Koster, aparna, Arne Broering, Carsten Bormann, Daniel Lux, Frank Reusch, Johannes Hund, Klause Hartke, Takuki Kamiya, Thomas Uslander, Victor Charpenay, Yingying Chen

Links relate the current context via a relationship type to a target URI with target attributes.

The attrubutes can say anything you want including media types.

Apps update their state by following links.

Links can be classfied into outbound and embedded links (e.g. HTML’s IMG element).

Forms can be considered as reverse links

Michael introduces the “collection” pattern. Thus is a resource that has links to other resources that ca be considered as items in a collection.

Some examples of hypermedia languages include HTML, microdata, RDFa (embedded in web pages), CoRE link format, JSON-LD and many others.

How is the hypermedia exposed in the API? How does it drive application state?

Things expose events, properties and actions. How can the semantics of HTML links and forms be applied to that?

Common attributes, media types, params, data types and templates, methods like PUT and PATCH, and a way to process responses.

Michael presents a table mapping actions, events and properties to hypermedia controls.

Actions and Events map to POST methods, Properties map to GET and PUT

A POST creates action resources and schedules the action for execution. Action resources can be used to track/control ongoing execution of actions.

Events are associated with subscriptions and can be managed in collections.

Properties may be any mediatype, and we may want to be able to use PATCH.

Michael elaborates through a lighting domain example.

Michael uses a transition action that changes properties over a given period of time.

He then shows some JSON with an array with two objects as its elements. Each object describes a single link.

He shows another example for a link representing an actuator.

He then presents a JSON representation of a form for an action.

This describes the fields to be passed with form’s submission, and the data expected back for the response.

Actions return an id that can be used to cancel on going actions.

Michael briefly discusses CoAP + IPSO bindings

He finishes with the references to Fielding’s work in 2000 and 2008, and the O’Reilly book on RESTful Web APIs.

Questions?

Johannes: Is there a distinction between the two parts of the description and the relation to HYDRA and RAML

Michael: I am not trying to invent the whole language, but rather to introduce design patterns

A constrained device could link to a more powerful device …

This looks like part of a protocol binding, but that would need aditional semantics and details.

Carsten: you can do exactly the same things in CoAP as HTTP, so that could help with the continuum of devices

Michael: protocol translation is more complex for say mapping between HTTP and ZigBee

Carsten: CoAP observe …

Michael: HTTP2 “observe” isn’t quite the same as CoAP’s

HTTP2 is aimed at proactive push of web page resources to reduce latency

Carsten: could we add the CoAP observe semantics to HTTP2?

Michael: that would be interesting, and we need to push the use case in the IETF HTTP WG

Darko thanks Michael and suggests that further questions are taken to the email list.

Frank Reusch gives a presentation on the Lemonbeat smart device language (LsDL)

This has been developed within RWE in Germany.

RWE is working on smart home solutions.

We believe in creating distributed and linked inteligence rather than smarter devices

Assumption: intelligent networks of devices are built at the application layer

More than 80% of IoT devices are very simple and cheap. We need to integrate these.

IoT concepts should be universal with information that enables effective integration.

Lemonbeat is an XML based language for configuring IoT devices. We support CoAP and EXI.

We’re open to other ideas, e.g. JSON

Frank presents an example of a thermostatic radiator valve with an embeddd LCD display.

This can be linked to actuators for closing a room’s window.

The approach includes support for event driven state machines.

Each device has a unique serial number. When provisioning devices, they are set up with a public key pair and can use this to exchange an AES symmetric key for encrypting messages.

We use a trust centre to track the public keys for devices.

We’ve implemented a Lemonbeat chip with an embedded 800Mhz radio transceiver.

I’ve sent you all the Lemonbeat specification and look forward to comments.

Questions?

Darko: what capabilities are embedded on this chip?

Frank: ARM Cortex-M3 CPU, Silicon Labs SI 446x radio transceiver, plus the usual MCU I/O capabilities e.g UART, SPI, I2C, GPIO.

XXX: is the description used within each device or is it shared across devices?

Daniel Lux: it can be shared across devices, including communication metadata for sleeping devices etc.

We have services for many different functions

Daniel: most devices are very constrained, but you can create service compositions in a gateway

Devices aren’t really relevant and we focus on services.

The control rules for compositions are designed by programmers.

Darko: any other questions?

[no]

Please read and review the specification we’ve sent to the list.

Darko: any suggestions for the next TF-DI call?

We should start editing on a wiki page . . .

Thanks to Michael and Daniel for their presentations and talk to you in 2 weeks time.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/09/16 14:22:48 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/discussions/discusses/
Found ScribeNick: dsr
Inferring Scribes: dsr

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: Assumption Carsten Daniel Darko Darko_Anicic Frank Johannes Michael XXX dape scribenick yingying_
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Got date from IRC log name: 16 Sep 2015
Guessing minutes URL: http://www.w3.org/2015/09/16-wot-td-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


[End of scribe.perl diagnostic output]