<scribe> scribenick: dsr

Sebastian summarises the agenda for today’s call

He shows us his idea for how to deal with an LED Lamp

The metadata includes the datamodel, the name of the lamp, and communications metadata

The action to turn the light on could also be modelled as a property.

He presents his idea for a JSON-LD representation

Sebastian has added metadata to allow a server to indicate which protocols it prefers

He switches the screen to show some ideas for how the data model could be bound to CoAP

Some question about how frequently given properties need to be sent

Question: will Sebastian make his ideas available on github?

Sebastian responds yes.

Dave asks what HATEOAS means?

MichaelKoster: it means metadata that allows ???

So it means the communications metadata that end points need to select the protocols, data formats, encodings etc.

right

Michael: the metdata should be optional, i.e. you don’t need it in all cases

You can cache it and its use may depend on the power of the client, etc.

Sebastian talks further about metadata details

Dave here a simpler example:

A data model for your example could look something like:

{

“name” : “MyLED”,

“properties”: {

on: {

“type” : “boolean”,

“writeable”: true

},

“colorTemp”: {

“type” : “uint16”,

“writeable” : true

},

“red”: “uint8”,

“green”: “uint8”,

“blue”: “uint8”

}

}

see https://lists.w3.org/Archives/Public/public-wot-ig/2015Aug/0063.html

Sebastian: in last week’s AP task force call Michael asked us to look at HATEOAS approach.

Dave still doesn’t know what HATEOAS is and it would be great to have some more details

Johannes: we are working on the plug-fest plans and need to define the metadata involved

Johannes committed to set out a template for people to fill in and would send out last week

Johannes will email a pointer ...

with interactions at https://github.com/w3c/wot/blob/master/plugfest/interactions.md

and protocol bindings at https://github.com/w3c/wot/blob/master/plugfest/binding_coap.md

for CoAP

Johannes presents the plug-fest draft info as per the above links

He describes a means for scripts to monitor or cancel long running actions

He then describes informal bindings to CoAP

This is our idea for the plug-fest for you to comment on

It would be good to have more people contributing to this

Dave volunteers to add some info on bindings to Web Sockets and to HTTP

This includes the question for how a server can push messages back asynchronously

Johannes: newer versions of HTTP include a basic pub-sub model which could be useful

Sebastian goes back to present his tutorial which he will post later

Sebastian’s question about “observe”

Sebastian wonders if it makes sense to be able to indicate that a property can be observed?

Carsten: we have something like that in the CoAP LINK format, but it isn’t so useful

If you are a client you can always use a GET with the observe option, so this is part of the protocol

You might have a property that is changing and if so you can just ask for it.

You have two different dimensions and it may be worth exploring that space some more

Danh: in our work we use a pub-sub approach to properties

Dave: I believe it depends on the details of the context and we need to study the use cases before we can have a meaningful discussion

There is risk of mixing up perspectives at the application and transport layer and unless we clarify this, we risk constraining which protocols can be used for the web of things

<cabo> (Dave: That is the transfer layer, not the transport layer...)

Carsten: the layers may need to be leaky, we will need to explore use cases to get a better feel

Dave and Danh talk through the need for metadata at the transfer layer

Sebastian: so we need to collect use cases to explore the question in more details

Dave: I have an idea for a progressive elaboration of use cases in mind, but it will take time to work through

Johannes: it seems reasonable to have metadata that indicates whether a given property is static or frequently changes

Sebastian: so what is the resolution here?

Dave: defer a decision, but allow people to experiment, let’s learn to walk before we learn to run

Danh: JSON-LD allows you to add properties and clients can ignore the ones that they don’t know

That’s the way RDF works

Sebastian: so we will treat Johannes’s static/frequently changing attribute as an optional piece of metadata
... ideas for naming this attribute?

Dave: how about “changes” with a value that is never, rarely, frequently? The details don’t matter as this is just experimental at this stage

Danh: how about “frequency” with a float for time interval or Hz

Carsten: for HTTP, you get a value that indicates how long a response is valid for

This is used for caching

We discuss the idea of giving an expiry time

Carsten: it could be hours, seconds or milliseconds

There is no infinity in JSON

Dave: we could add infinity via the default context

Sebastian will add a proposal for this

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/CoAO/CoAP/
Succeeded: s/XXX/MichaelKoster/
Succeeded: s/make/treat/
Found ScribeNick: dsr
Inferring Scribes: dsr
Present: Dave Sebastian Ari Arne Carsten Danh Hans Johannes KH Takuki Yingying
Agenda: https://lists.w3.org/Archives/Public/public-wot-ig/2015Sep/0000.html
Got date from IRC log name: 02 Sep 2015
Guessing minutes URL: http://www.w3.org/2015/09/02-wot-td-minutes.html
People with action items: 

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