IRC log of wot-td on 2015-09-02

Timestamps are in UTC.

13:05:44 [RRSAgent]
RRSAgent has joined #wot-td
13:05:44 [RRSAgent]
logging to
13:05:53 [DanhLePhuoc]
present+ DanhLePhuoc
13:05:56 [dsr]
rrsagent, set logs public
13:06:15 [dsr]
meeting: Thing description task force
13:06:21 [Ari_Keranen]
Ari_Keranen has joined #wot-td
13:06:21 [dsr]
chair: Sebastian
13:06:57 [dsr]
scribenick: dsr
13:07:25 [dsr]
13:09:47 [dsr]
Sebastian summarises the agenda for today’s call
13:12:10 [dsr]
He shows us his idea for how to deal with an LED Lamp
13:13:28 [dsr]
The metadata includes the datamodel, the name of the lamp, and communications metadata
13:13:55 [cabo]
cabo has joined #wot-td
13:14:16 [dsr]
The action to turn the light on could also be modelled as a property.
13:14:41 [dsr]
He presents his idea for a JSON-LD representation
13:17:10 [dsr]
Sebastian has added metadata to allow a server to indicate which protocols it prefers
13:19:23 [dsr]
He switches the screen to show some ideas for how the data model could be bound to CoAO
13:19:31 [dsr]
13:21:07 [dsr]
Some question about how frequently given properties need to be sent
13:21:34 [dsr]
Question: will Sebastian make his ideas available on github?
13:21:43 [dsr]
Sebastian responds yes.
13:23:01 [dsr]
Dave asks what HATEOAS means?
13:23:32 [dsr]
XXX: it means metadata that allows ???
13:23:51 [jhund]
13:23:54 [yingying]
yingying has joined #wot-td
13:25:16 [dsr]
So it means the communications metadata that end points need to select the protocols, data formats, encodings etc.
13:25:19 [dsr]
13:26:17 [yingying]
present+ yingying
13:26:25 [dsr]
Michael: the metdata should be optional, i.e. you don’t need it in all cases
13:27:02 [dsr]
You can cache it and its use may depend on the power of the client, etc.
13:28:05 [taki1]
taki1 has joined #wot-td
13:29:07 [dsr]
Sebastian talks further about metadata details
13:30:26 [dsr]
Dave here a simpler example:
13:30:30 [dsr]
A data model for your example could look something like:
13:30:30 [dsr]
13:30:32 [dsr]
“name” : “MyLED”,
13:30:33 [dsr]
“properties”: {
13:30:35 [dsr]
on: {
13:30:36 [dsr]
“type” : “boolean”,
13:30:38 [dsr]
“writeable”: true
13:30:39 [dsr]
13:30:41 [dsr]
“colorTemp”: {
13:30:42 [dsr]
“type” : “uint16”,
13:30:44 [dsr]
“writeable” : true
13:30:45 [dsr]
13:30:47 [dsr]
“red”: “uint8”,
13:30:49 [dsr]
“green”: “uint8”,
13:30:50 [dsr]
“blue”: “uint8”
13:30:51 [dsr]
13:30:53 [dsr]
13:30:54 [dsr]
13:32:50 [schuki]
schuki has joined #wot-td
13:37:42 [dsr]
Sebastian: in last week’s AP task force call Michael asked us to look at HATEOAS approach.
13:38:35 [dsr]
Dave still doesn’t know what HATEOAS is and it would be great to have some more details
13:39:15 [dsr]
Johannes: we are working on the plug-fest plans and need to define the metadata involved
13:41:22 [dsr]
Johannes committed to set out a template for people to fill in and would send out last week
13:43:15 [dsr]
Johannes will email a pointer ...
13:44:39 [Sebastian_]
Sebastian_ has joined #wot-td
13:45:03 [dsr]
with interactions at
13:45:18 [dsr]
and protocol bindings at
13:45:24 [dsr]
for CoAP
13:46:08 [dsr]
Johannes presents the plug-fest draft info as per the above links
13:48:16 [dsr]
He describes a means for scripts to monitor or cancel long running actions
13:49:19 [dsr]
He then describes informal bindings to CoAP
13:50:16 [dsr]
This is our idea for the plug-fest for you to comment on
13:50:34 [dsr]
It would be good to have more people contributing to this
13:52:09 [dsr]
Dave volunteers to add some info on bindings to Web Sockets and to HTTP
13:52:43 [dsr]
This includes the question for how a server can push messages back asynchronously
13:53:17 [dsr]
Johannes: newer versions of HTTP include a basic pub-sub model which could be useful
13:53:35 [taki]
taki has joined #wot-td
13:54:41 [dsr]
Sebastian goes back to present his tutorial which he will post later
13:57:10 [dsr]
Topic: Sebastian’s question about “observe”
13:57:44 [dsr]
Sebastian wonders if it makes sense to be able to indicate that a property can be observed?
13:58:20 [dsr]
Carsten: we have something like that in the CoAP LINK format, but it isn’t so useful
13:58:46 [dsr]
If you are a client you can always use a GET with the observe option, so this is part of the protocol
13:59:23 [dsr]
You might have a property that is changing and if so you can just ask for it.
13:59:44 [dsr]
You have two different dimensions and it may be worth exploring that space some more
14:00:16 [dsr]
Danh: in our work we use a pub-sub approach to properties
14:02:12 [dsr]
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
14:03:42 [dsr]
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
14:04:01 [cabo]
(Dave: That is the transfer layer, not the transport layer...)
14:07:28 [dsr]
Carsten: the layers may need to be leaky, we will need to explore use cases to get a better feel
14:11:32 [dsr]
Dave and Danh talk through the need for metadata at the transfer layer
14:13:27 [dsr]
Sebastian: so we need to collect use cases to explore the question in more details
14:14:08 [dsr]
Dave: I have an idea for a progressive elaboration of use cases in mind, but it will take time to work through
14:14:59 [dsr]
Johannes: it seems reasonable to have metadata that indicates whether a given property is static or frequently changes
14:15:58 [dsr]
Sebastian: so what is the resolution here?
14:16:35 [dsr]
Dave: defer a decision, but allow people to experiment, let’s learn to walk before we learn to run
14:17:04 [dsr]
Danh: JSON-LD allows you to add properties and clients can ignore the ones that they don’t know
14:17:16 [dsr]
That’s the way RDF works
14:19:14 [dsr]
Sebastian: so we will make Johannes’s static/frequently changing attribute as an optional piece of metadata
14:19:21 [dsr]
14:21:03 [dsr]
Sebastian: ideas for naming this attribute?
14:21:44 [dsr]
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
14:22:00 [dsr]
Danh: how about “frequency” with a float for time interval or Hz
14:22:33 [dsr]
Carsten: for HTTP, you get a value that indicates how long a response is valid for
14:23:01 [dsr]
This is used for caching
14:24:10 [dsr]
We discuss the idea of giving an expiry time
14:25:43 [dsr]
Carsten: it could be hours, seconds or milliseconds
14:26:23 [dsr]
There is no infinity in JSON
14:26:45 [dsr]
Dave: we could add infinity via the default context
14:28:33 [dsr]
Sebastian will add a proposal for this
14:30:15 [jhund]
RRSAgent, draft minutes
14:30:15 [RRSAgent]
I have made the request to generate jhund
14:30:27 [jhund]
RRSAgent, make minutes public
14:30:27 [RRSAgent]
I'm logging. I don't understand 'make minutes public', jhund. Try /msg RRSAgent help
14:30:46 [dsr]
present: Dave, Sebastian, Ari, Arne, Carsten, Danh, Hans, Johannes, KH, Takuki, Yingying
14:30:55 [dsr]
rrsagent, make minutes
14:30:55 [RRSAgent]
I have made the request to generate dsr
15:33:21 [cabo]
cabo has joined #wot-td
19:00:30 [cabo]
cabo has joined #wot-td
23:46:57 [cabo]
cabo has joined #wot-td