10:33:48 <RRSAgent> RRSAgent has joined #wot-td
10:33:48 <RRSAgent> logging to http://www.w3.org/2016/09/22-wot-td-irc
10:33:54 <kaz> Meeting: TD Breakout
10:34:02 <kaz> Chair: Kajimoto
10:34:16 <ryuichi_> ryuichi_ has joined #wot-td
10:34:24 <kaz> kaji: shows his slides
10:34:34 <kaz> ... TD Template and Lifecycle Eco System
10:35:35 <kotakagi_> kotakagi_ has joined #wot-td
10:36:06 <mdadas> mdadas has joined #wot-td
10:36:07 <kaz> ... how to implement this kind of mechanism?
10:36:17 <kaz> ... not familiar with JSON-LD operation
10:36:30 <kaz> ... but shows some initial idea
10:38:01 <katsu_> katsu_ has joined #wot-td
10:41:33 <jungbin> jungbin has joined #wot-td
10:45:21 <kaz> kaz has joined #wot-td
10:46:01 <wonsuk> wonsuk has joined #wot-td
10:46:04 <wonsuk> wonsuk has left #wot-td
10:46:05 <wonsuk> wonsuk has joined #wot-td
10:46:28 <kaz> (some more discussion)
10:46:46 <kaz> nimura: need to protect some of the information
10:46:58 <kaz> ... some part of the information
10:47:05 <kaz> ... so we need a protection mechanism
10:47:29 <kaz> seba: each device has internet access
10:48:00 <kaz> ari: could compile all the information
10:48:24 <kaz> fer: separation of TD documents
10:48:51 <kaz> ... seems this idea is not really usual "linked data"
10:49:07 <kaz> s/not really/different from/
10:49:31 <kaz> ... if we have to support device discovery, we could use some repository
10:50:19 <kaz> ... what is the reason of separation?
10:50:45 <kaz> vic: you have a part of TD with all temperature sensors
10:51:06 <kaz> fer: any sensors could be described
10:51:55 <kaz> ... we can simply follow the links, can't we?
10:52:45 <kaz> vic: we have more than communication layers
10:53:07 <kaz> kaji: in short, this model has two weak points
10:53:14 <kaz> ... 1. update time lug
10:53:30 <kaz> ... when the update is reflected?
10:53:53 <kaz> ... 2. synchronization between multiple devices
10:54:12 <kaz> s/lug/lag/
10:54:39 <kaz> ... but immediate update/synchronization really needed?
10:55:06 <kaz> ... don't think there is actual need
10:55:30 <kaz> ... but there are time-related issues with this model
10:56:18 <kaz> seba: when/how the whole TD information is processed?
10:56:36 <kaz> ... TD Template integrates all the TD instances
10:57:06 <kaz> ... maybe we could call it "TD skelton"
10:57:48 <kaz> seba: red piece within TD Template has a link to TD instance's red piece
10:58:33 <kaz> vic: do we need to decide which way to use?
10:58:48 <kaz> ... would be good to use the same vocabulary
10:59:25 <kaz> kaji: we should consider this kind of lifecycle
11:02:15 <kaz> @@@: would like to propose you raise this use case with linked data model
11:03:37 <kaz> fer: have an implementation for photometer
11:03:46 <kaz> ... putting data using MQTT
11:04:04 <kaz> ... if you want, I can show you some examples
11:04:27 <kaz> vic: using linked data platform?
11:04:30 <kaz> fer: yes
11:04:57 <kaz> vic: there is a subscriber to MQTT?
11:05:24 <kaz> andrei: there is a fundamental difference
11:05:50 <kaz> ... linked data platform is data-driven communication
11:06:45 <kaz> s/communication/interaction model/
11:07:02 <kaz> vic: not sure how it would be helpful here
11:08:22 <kaz> ... we can't force some specific interaction model
11:09:11 <kaz> andrei: the difference is how you describe the interaction
11:10:07 <kaz> vic: we'll discuss Hydra in the afternoon
11:10:44 <kaz> @@@: maybe it could be link capability rather than include
11:11:43 <kaz> vic: you need some special semantics
11:12:16 <kaz> ... JSON-LD doesn't have hyperlink capability itself
11:14:21 <kaz> s/@@@:/maxime:/g
11:14:33 <kaz> fer: may I show my idea?
11:15:10 <kaz> ... (shows some example notation)
11:16:07 <kaz> seba: can be "change" rather than "delete"
11:17:16 <kaz> maxime: two instances could be linked to each other
11:17:57 <kaz> vic: it depends on our need for online resolution or offline resolution
11:18:47 <kaz> kaji: offline resolution is ok
11:19:33 <kaz> ... but online resolution is also important
11:19:45 <kaz> ... and there are issues on synchronization
11:20:12 <kaz> vic: having traceability is important
11:20:31 <kaz> nimura: done need to exclude the possibility of online resolution
11:21:15 <kaz> maxime: we need some simple mechanism even if we need online resolution
11:21:36 <kaz> fer: may be too hard
11:21:46 <kaz> ... (shows his example)
11:21:56 <kaz> ... we provide data like this
11:25:34 <kaz> ... "@prefix ldp: <http://www.w3.org/ns/ldp#>"
11:26:03 <kaz> <http://localhost:5005/systems/tess> a s4all:photometer,
11:26:12 <kaz>   ldp:Resource,
11:26:24 <kaz>    wot:System ;
11:26:26 <kaz> ...
11:26:43 <kaz> seba: this description is for after getting some concrete instance?
11:27:15 <kaz> maxime: you need to go to the system to know about the device's capability
11:28:04 <kaz> ... I can't delete any capability on the manufacture's TD
11:28:50 <kaz> q+
11:30:16 <kaz> vic: this model looks great but we don't want to prevent people from using their preferred protocol
11:31:33 <kaz> kaz: within Kajimoto-san's model "delete" doesn't really mean deletion but just means "disabling". right?
11:31:35 <kaz> kaji: yes
11:31:44 <kaz> ... (summarizes)
11:32:02 <kaz> ... some portion could be reflected to TD itself
11:32:15 <kaz> ... but this issue depends on implementations
11:32:25 <kaz> ... would like to continue discussion
11:32:36 <kaz> ... as the next step
11:32:45 <kaz> ... please participate in that discussion :)
11:32:52 <kaz> [ adjourned ]
11:33:00 <kaz> rrsagent, make log public
11:33:05 <kaz> rrsagent, draft minutes
11:33:05 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/22-wot-td-minutes.html kaz
11:37:32 <kotakagi> kotakagi has joined #wot-td
12:00:48 <jungbin> jungbin has joined #wot-td
12:28:09 <jungbin> jungbin has joined #wot-td
12:41:48 <kotakagi> kotakagi has joined #wot-td
12:42:20 <taki> taki has joined #wot-td
12:43:28 <ryuichi> ryuichi has joined #wot-td
12:43:37 <domguinard> domguinard has joined #wot-td
12:43:47 <domguinard> domguinard has left #wot-td
12:44:07 <yingying> yingying has joined #wot-td
12:45:05 <yingying_> yingying_ has joined #wot-td
12:45:45 <Maxime_> Maxime_ has joined #wot-td
12:46:03 <jungbin> jungbin has joined #wot-td
12:46:33 <mdadas> mdadas has joined #wot-td
12:46:35 <cabo> cabo has joined #wot-td
12:46:54 <dsr> dsr has joined #wot-td
12:46:55 <Maxime_> looking at http://hydra-cg.com/spec/latest/core/
12:47:05 <Milan> Milan has joined #wot-td
12:47:09 <ahaller2> ahaller2 has joined #wot-td
12:47:40 <Andrei> Andrei has joined #wot-td
12:47:46 <ahaller2> ahaller2 has left #wot-td
12:47:56 <mkovatsc> mkovatsc has joined #wot-td
12:48:06 <katsu> katsu has joined #wot-td
12:48:28 <domguinard> domguinard has joined #wot-td
12:48:50 <Maxime_> for those that just joined: looking at http://hydra-cg.com/spec/latest/core/
12:49:17 <sebastian> sebastian has joined #wot-td
12:49:31 <kaz> kaz has joined #wot-td
12:49:34 <Maxime_> demonstration of a server that adds hydra description to the resources
12:49:53 <kaz> rrsagent, draft minutes
12:49:53 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/22-wot-td-minutes.html kaz
12:50:21 <Maxime_> one can describe API for some thing, a temperature sensor for instance
12:50:58 <kaz> s/adjourned/morning breakout adjourned/
12:51:34 <kaz> i/looking at/topic: Hydra breakout/
12:52:18 <kaz> vic: explains the mechanism of Hydra and example temperature-sensor.api script
12:52:30 <kaz> cabo: operation like "action"?
12:52:38 <kaz> vic: HTTP operation like GET
12:52:59 <kaz> cabo: what if we want coffee?
12:53:10 <kaz> vic: the coffee has a property for that purpose
12:53:25 <kaz> ... RDF property and Hydra property
12:53:37 <kaz> ... clicks the Hydra property
12:54:14 <kaz> ... there is some definition for making coffee action
12:54:39 <kaz> ... and then you have operations by dereference
12:54:55 <Maxime_> (actions on the real world are not part of the hydra api description model)
12:55:04 <kaz> ... what is interesting with Hydra is separation of static data
12:55:30 <kaz> ... you could have one API spec for all sensors somewhere on the Web
12:55:43 <kaz> ... and another is API spec only for Panasonic
12:56:07 <kaz> darko: with this Hydra approach, we still could specify property using TD
12:56:24 <kaz> ... we could use TD to extend Hydra's capability
12:56:35 <kaz> ... we're following some minimal vocabulary
12:56:45 <kaz> ... not to be general but to be efficient
12:57:04 <kaz> ... on the other hand, Hydra provides general mechanism
12:57:27 <kaz> vic: more linked data-driven
12:57:41 <kaz> zoltan: you can express anything?
12:58:06 <kaz> vic: all the Hydra properties are serializable as RDF
12:58:17 <kaz> zoltan: also using JSON-LD?
12:58:25 <kaz> vic: yes
12:59:23 <kaz> ... no semantics within Hydra itself
12:59:33 <masato_> masato_ has joined #wot-td
13:00:05 <kaz> dom: how to describe range, etc.?
13:00:31 <kaz> vic: goes back to the diagram at: http://hydra-cg.com/spec/latest/core/
13:01:09 <kaz> ... must use JS for data type
13:01:38 <kaz> dom: having type, range, etc., would be useful
13:01:52 <kaz> ... something JSON Schema supports
13:01:55 <kaz> vic: good point
13:02:06 <kaz> matthias: Hydra is kind of standalone API
13:02:15 <kaz> ... it has its own interchange format
13:02:43 <kaz> ... significant difference from RAML is that this is a separate specification
13:03:10 <kaz> ... if you want to have hypermedia, Hydra uses its own format
13:03:20 <kaz> vic: we'll need some specific model
13:03:33 <kaz> ... this is intended as a generic model
13:03:43 <domguinard> I'm after something along these lines: https://www.w3.org/Submission/2015/SUBM-wot-model-20150824/#values which is spimple but powerful
13:05:44 <kaz> matthias: would be useful to have some method to change/delete classes within the tree
13:06:05 <kaz> (as discussed during the TD lifecycle breakout)
13:07:51 <kaz> (discussion on how to handle classes)
13:09:20 <kaz> dsr: assumption on state handling?
13:09:43 <kaz> ... would like to know about the scope
13:10:28 <kaz> vic: this is description for APIs
13:10:37 <kaz> dsr: data model/format is not included
13:10:39 <kaz> vic: right
13:11:05 <kaz> maxime: we have classes of source
13:11:15 <kaz> ... and set up links
13:11:33 <kaz> ... interested in metadata
13:12:15 <kaz> ... coffee machine exposes "make coffee"?
13:12:43 <kaz> ... all coffee machines should have same operations
13:13:18 <kaz> ... should have an action to "make coffee"
13:13:29 <kaz> vic: Hydra allows both
13:13:40 <kaz> ... other comments?
13:13:50 <kaz> matthias: what's the progress?
13:14:02 <kaz> .... we have to improve knowledge
13:14:16 <kaz> vic: the example is based on TD in the current practice doc
13:14:35 <kaz> matthias: what is the relationship?
13:14:51 <kaz> http://www.hydra-cg.com/spec/latest/core/
13:15:03 <kaz> link to the Hydra doc above
13:15:26 <kaz> vic: we could use Hydra as interface
13:15:30 <kaz> matthias: what does it offer?
13:16:09 <kaz> ... do they provide protocol binding?
13:16:31 <victor_> victor_ has joined #wot-td
13:16:35 <victor_> https://github.com/bergos/wot-examples/
13:18:06 <kaz> vic: they use abstract name for operation
13:18:11 <kaz> s/operation/operations/
13:18:18 <kaz> ... we can use that abstract layer
13:18:53 <kaz> andrei: good to have some unified mechanism
13:20:29 <kaz> darko: would be good to think about how to map TD properties/actions to Hydra's ones
13:21:00 <kaz> matthias: we should be clear about the concept behind
13:22:22 <mdadas> mdadas has joined #wot-td
13:22:44 <kaz> ... capability to monitor and change the status?
13:23:35 <kaz> ... we need more explicit information for the interaction model
13:24:13 <kaz> vic: there several competitors like RAML
13:24:37 <kaz> maxime: we should double check
13:24:57 <kaz> ... also what about request/response?
13:25:20 <kaz> vic: Michael's proposal include pub/sub
13:25:41 <kaz> ... you should expect to be notified
13:25:55 <kaz> ... need to add sub-class definition
13:26:08 <kaz> ... they mainly use "method"
13:26:17 <kaz> ... in the Hydra engine
13:26:24 <kaz> ... need extension
13:27:26 <kaz> matthias: we need some more elaboration
13:27:35 <kaz> ... how the APIs look like
13:27:48 <kaz> ... how they work with this mechanism
13:28:07 <kaz> vic: the interface is same
13:29:58 <kaz> seba: what is the main goal of this discussion?
13:30:05 <kaz> ... want to switch to Hydra mechanism?
13:30:08 <kaz> vic: not so
13:30:14 <kaz> ... Hydra defines some APIs
13:30:32 <kaz> ... would like to see if its mechanism is appropriate
13:30:50 <kaz> seba: what do we want for Hydra?
13:31:24 <kaz> darko: we should have some general semantic API
13:31:38 <kaz> vic: could have some instance to communicate with Hydra
13:32:10 <kaz> seba: good to see the delta on the major difference between TD and Hydra
13:32:29 <Maxime_> q?
13:32:39 <kaz> ack k
13:33:04 <kaz> andrei: this is more extension of Hydra
13:33:26 <kaz> ... better to have some unified mechanism
13:34:50 <kaz> q+
13:36:44 <kaz> kaz: one question
13:36:55 <kaz> ... is Hydra useful to handle TD lifecycle?
13:37:05 <kaz> vic: not really sure
13:37:20 <kaz> ... to apply to our own TD description
13:37:37 <kaz> ... we need to find some way for that purpose anyway, though
13:38:09 <kaz> ... we need some more comparison between TD and Hydra
13:38:12 <kaz> [
13:38:17 <kaz> s/[//
13:38:33 <kaz> ack k
13:38:48 <kaz> vic: any other topics to discuss now?
13:39:10 <kaz> matthias: good to have brainstorm?
13:39:26 <kaz> dsr: schema for data types is not included here
13:39:59 <kaz> matthias: you have to create concrete data model separately
13:40:26 <kaz> dsr: how to handle different kinds of sensors?
13:40:39 <kaz> vic: there is a way to identify things using media type
13:40:49 <kaz> ... it's a limited kind of media types
13:40:53 <kaz> s/types/type/
13:41:18 <kaz> cabo: question on domains?
13:41:28 <kaz> vic: (shows some example)
13:41:42 <kaz> ... temperature-sensor.api
13:41:50 <kaz> ... you have a "PUT" operation
13:41:54 <kaz> ... and event resource
13:42:04 <kaz> ... defined here
13:42:47 <kaz> ... you expect a class and describe resources using specific property
13:42:57 <kaz> ... it's also limited. good point
13:43:26 <kaz> seba: value type description?
13:43:34 <kaz> vic: class returns some event
13:43:50 <kaz> ... and the Hydra engine recognizes it
13:44:01 <dsr> media types aren’t sufficient, e.g. you could have application/jason which only states that you have got JSON, not what data model the JSON conforms to.
13:45:46 <dsr> I can’t see how Hydra helps you deal with the semantics for the data passed through RESTful APIs
13:46:19 <kaz> (some more discussion about monitoring the status and change/update it)
13:47:19 <kaz> vic: there is an Action class within Hydra
13:47:41 <kaz> ... it returns about some invoked action
13:48:00 <kaz> matthias: yes, you return something
13:48:26 <kaz> vic: can transfer time stamp, etc.
13:48:39 <kaz> ... we could provide default invoked action class as well
13:48:44 <kaz> ... to monitor the status
13:49:46 <kaz> matthias: TD also can handle the status
13:50:04 <kaz> ... we need a representation for resources
13:50:13 <kaz> ... and model for interaction
13:50:27 <kaz> ... maybe we can call it "action description"
13:50:39 <kaz> ... some metadata on it
13:52:10 <kaz> ... we already have similar capability within TD
13:53:07 <kaz> q+
13:54:07 <kaz> maxime: what if we want coffee but the coffee machine doesn't have any more coffee?
13:56:43 <kaz> matthias: error handling in general
13:57:17 <kaz> ... we can list some figures about the concept
13:57:26 <kaz> ... work by both the IG and the WG
13:57:28 <kaz> q-
13:57:50 <kaz> cabo: TD describes things
13:58:10 <kaz> ... on the other hand in this kind of abstract action layer
13:58:25 <kaz> s/layer/layer, things are more dynamic/
14:00:14 <kaz> matthias: how do you use hypermedia?
14:00:29 <kaz> ... abstract layer and detailed transition layer
14:00:46 <kaz> seba: good topic for the T2T joint meeting
14:00:48 <kaz> cabo: yes
14:01:04 <Andrei> Andrei has left #wot-td
14:01:17 <kaz> ... 12 people have got registered for the joint meeting
14:01:56 <kaz> [ afternoon break adjourned ]
14:02:01 <kaz> rrsagent, draft minutes
14:02:01 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/22-wot-td-minutes.html kaz
14:10:56 <cabo> cabo has joined #wot-td
14:25:28 <mdadas> mdadas has joined #wot-td
14:27:43 <ying_ying> ying_ying has joined #wot-td
14:28:09 <mdadas> mdadas has left #wot-td
14:35:30 <dsr> dsr has joined #wot-td
15:24:06 <kotakagi> kotakagi has joined #wot-td
15:24:43 <taki> taki has joined #wot-td
16:13:25 <Zakim> Zakim has left #wot-td
16:17:21 <kotakagi> kotakagi has joined #wot-td
16:52:01 <cabo> cabo has joined #wot-td
17:26:48 <jungbin> jungbin has joined #wot-td
17:44:00 <jungbin> jungbin has joined #wot-td