See also: IRC log
<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 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.[End of scribe.perl diagnostic output]