TD Lifecycle breakout

kaji: shows his slides
... TD Template and Lifecycle Eco System
... how to implement this kind of mechanism?
... not familiar with JSON-LD operation
... but shows some initial idea

(some more discussion)

nimura: need to protect some of the information
... some part of the information
... so we need a protection mechanism

seba: each device has internet access

ari: could compile all the information

fer: separation of TD documents
... seems this idea is different from usual "linked data"
... if we have to support device discovery, we could use some repository
... what is the reason of separation?

vic: you have a part of TD with all temperature sensors

fer: any sensors could be described
... we can simply follow the links, can't we?

vic: we have more than communication layers

kaji: in short, this model has two weak points
... 1. update time lag
... when the update is reflected?
... 2. synchronization between multiple devices
... but immediate update/synchronization really needed?
... don't think there is actual need
... but there are time-related issues with this model

seba: when/how the whole TD information is processed?
... TD Template integrates all the TD instances
... maybe we could call it "TD skelton"
... red piece within TD Template has a link to TD instance's red piece

vic: do we need to decide which way to use?
... would be good to use the same vocabulary

kaji: we should consider this kind of lifecycle

maxime: would like to propose you raise this use case with linked data model

fer: have an implementation for photometer
... putting data using MQTT
... if you want, I can show you some examples

vic: using linked data platform?

fer: yes

vic: there is a subscriber to MQTT?

andrei: there is a fundamental difference
... linked data platform is data-driven interaction model

vic: not sure how it would be helpful here
... we can't force some specific interaction model

andrei: the difference is how you describe the interaction

vic: we'll discuss Hydra in the afternoon

maxime: maybe it could be link capability rather than include

vic: you need some special semantics
... JSON-LD doesn't have hyperlink capability itself

fer: may I show my idea?
... (shows some example notation)

seba: can be "change" rather than "delete"

maxime: two instances could be linked to each other

vic: it depends on our need for online resolution or offline resolution

kaji: offline resolution is ok
... but online resolution is also important
... and there are issues on synchronization

vic: having traceability is important

nimura: done need to exclude the possibility of online resolution

maxime: we need some simple mechanism even if we need online resolution

fer: may be too hard
... (shows his example)
... we provide data like this
... "@prefix ldp: <http://www.w3.org/ns/ldp#>"

<http://localhost:5005/systems/tess> a s4all:photometer,

ldp: Resource,

wot: System ;
...

seba: this description is for after getting some concrete instance?

maxime: you need to go to the system to know about the device's capability
... I can't delete any capability on the manufacture's TD

vic: this model looks great but we don't want to prevent people from using their preferred protocol

kaz: within Kajimoto-san's model "delete" doesn't really mean deletion but just means "disabling". right?

kaji: yes
... (summarizes)
... some portion could be reflected to TD itself
... but this issue depends on implementations
... would like to continue discussion
... as the next step
... please participate in that discussion :)

[ morning breakout adjourned ]

<Maxime_> looking at http://hydra-cg.com/spec/latest/core/

Hydra breakout

<Maxime_> for those that just joined: looking at http://hydra-cg.com/spec/latest/core/

<Maxime_> demonstration of a server that adds hydra description to the resources

<Maxime_> one can describe API for some thing, a temperature sensor for instance

vic: explains the mechanism of Hydra and example temperature-sensor.api script

cabo: operation like "action"?

vic: HTTP operation like GET

cabo: what if we want coffee?

vic: the coffee has a property for that purpose
... RDF property and Hydra property
... clicks the Hydra property
... there is some definition for making coffee action
... and then you have operations by dereference

<Maxime_> (actions on the real world are not part of the hydra api description model)

vic: what is interesting with Hydra is separation of static data
... you could have one API spec for all sensors somewhere on the Web
... and another is API spec only for Panasonic

darko: with this Hydra approach, we still could specify property using TD
... we could use TD to extend Hydra's capability
... we're following some minimal vocabulary
... not to be general but to be efficient
... on the other hand, Hydra provides general mechanism

vic: more linked data-driven

zoltan: you can express anything?

vic: all the Hydra properties are serializable as RDF

zoltan: also using JSON-LD?

vic: yes
... no semantics within Hydra itself

dom: how to describe range, etc.?

vic: goes back to the diagram at: http://hydra-cg.com/spec/latest/core/
... must use JS for data type

dom: having type, range, etc., would be useful
... something JSON Schema supports

vic: good point

matthias: Hydra is kind of standalone API
... it has its own interchange format
... significant difference from RAML is that this is a separate specification
... if you want to have hypermedia, Hydra uses its own format

vic: we'll need some specific model
... this is intended as a generic model

<domguinard> I'm after something along these lines: https://www.w3.org/Submission/2015/SUBM-wot-model-20150824/#values which is spimple but powerful

matthias: would be useful to have some method to change/delete classes within the tree

(as discussed during the TD lifecycle breakout)

(discussion on how to handle classes)

dsr: assumption on state handling?
... would like to know about the scope

vic: this is description for APIs

dsr: data model/format is not included

vic: right

maxime: we have classes of source
... and set up links
... interested in metadata
... coffee machine exposes "make coffee"?
... all coffee machines should have same operations
... should have an action to "make coffee"

vic: Hydra allows both
... other comments?

matthias: what's the progress?
... we have to improve knowledge

vic: the example is based on TD in the current practice doc

matthias: what is the relationship?

http://www.hydra-cg.com/spec/latest/core/

link to the Hydra doc above

vic: we could use Hydra as interface

matthias: what does it offer?
... do they provide protocol binding?

<victor_> https://github.com/bergos/wot-examples/

vic: they use abstract name for operations
... we can use that abstract layer

andrei: good to have some unified mechanism

darko: would be good to think about how to map TD properties/actions to Hydra's ones

matthias: we should be clear about the concept behind
... capability to monitor and change the status?
... we need more explicit information for the interaction model

vic: there several competitors like RAML

maxime: we should double check
... also what about request/response?

vic: Michael's proposal include pub/sub
... you should expect to be notified
... need to add sub-class definition
... they mainly use "method"
... in the Hydra engine
... need extension

matthias: we need some more elaboration
... how the APIs look like
... how they work with this mechanism

vic: the interface is same

seba: what is the main goal of this discussion?
... want to switch to Hydra mechanism?

vic: not so
... Hydra defines some APIs
... would like to see if its mechanism is appropriate

seba: what do we want for Hydra?

darko: we should have some general semantic API

vic: could have some instance to communicate with Hydra

seba: good to see the delta on the major difference between TD and Hydra

andrei: this is more extension of Hydra
... better to have some unified mechanism

kaz: one question
... is Hydra useful to handle TD lifecycle?

vic: not really sure
... to apply to our own TD description
... we need to find some way for that purpose anyway, though
... we need some more comparison between TD and Hydra
... any other topics to discuss now?

matthias: good to have brainstorm?

dsr: schema for data types is not included here

matthias: you have to create concrete data model separately

dsr: how to handle different kinds of sensors?

vic: there is a way to identify things using media type
... it's a limited kind of media type

cabo: question on domains?

vic: (shows some example)
... temperature-sensor.api
... you have a "PUT" operation
... and event resource
... defined here
... you expect a class and describe resources using specific property
... it's also limited. good point

seba: value type description?

vic: class returns some event
... and the Hydra engine recognizes it

<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.

<dsr> I can’t see how Hydra helps you deal with the semantics for the data passed through RESTful APIs

(some more discussion about monitoring the status and change/update it)

vic: there is an Action class within Hydra
... it returns about some invoked action

matthias: yes, you return something

vic: can transfer time stamp, etc.
... we could provide default invoked action class as well
... to monitor the status

matthias: TD also can handle the status
... we need a representation for resources
... and model for interaction
... maybe we can call it "action description"
... some metadata on it
... we already have similar capability within TD

maxime: what if we want coffee but the coffee machine doesn't have any more coffee?

matthias: error handling in general
... we can list some figures about the concept
... work by both the IG and the WG

cabo: TD describes things
... on the other hand in this kind of abstract action layer, things are more dynamic

matthias: how do you use hypermedia?
... abstract layer and detailed transition layer

seba: good topic for the T2T joint meeting

cabo: yes
... 12 people have got registered for the joint meeting

[ afternoon break adjourned ]