07:11:00 RRSAgent has joined #wot 07:11:00 logging to http://www.w3.org/2017/07/11-wot-irc 07:11:02 Zakim has joined #wot 07:11:08 Meeting: Tech Day1 07:11:20 meeting: Tech welcome 07:11:30 mk: welcome to the 3rd meeting of the WG! 07:11:50 ... would remind you of the W3C Patent Policy for the WG work as Kaz mentioned yesterday 07:11:58 https://www.w3.org/2017/Talks/0710-w3c-pp-ka/ 07:12:24 mk: you need to become an official WG participant to make contribution 07:12:25 dape has joined #wot 07:12:29 uday has joined #wot 07:12:33 sebastian has joined #wot 07:12:36 Soumya has joined #wot 07:12:46 ... we're taking minutes on IRC 07:12:49 DarkoAnicic has joined #wot 07:13:00 ... please help minutes taking 07:13:01 ryuichi has joined #wot 07:13:11 dsr: microphones are available 07:13:13 present+ DarkoAnicic 07:13:18 mk: agenda bashing 07:13:20 ktoumura has joined #wot 07:13:20 present+ Soumya 07:13:44 i/agenda/topic: Agenda Bashing/ 07:13:48 mjkoster has joined #wot 07:13:56 mk: would like to start with Mozilla's contribution 07:14:27 ... they've just made a Member submission 07:14:58 ... after the morning break 07:15:02 ... TD serialization 07:15:12 ... open-source strategy 07:15:45 ... won't go into the detail but the proposed agenda is available online 07:16:11 mm: maybe short summarization from the Osaka meeting? 07:16:33 mk: good to repeat what we discussed in Osaka 07:16:48 ... we should talk together 07:16:54 ... we go for single slots this time 07:17:08 ... and then Day2 07:17:26 agenda: https://www.w3.org/WoT/IG/wiki/F2F_meeting,_9-13_July_2017,_D%C3%BCsseldorf,_Germany#Agenda 07:17:42 mk: security use cases/scenarios 07:17:58 ... security next steps 07:18:12 dsr: can contribute to serialization today and data types tomorrow 07:18:37 mk: data types 07:18:44 ... Victor? 07:18:56 ... status, etc. 07:19:15 victor: maybe shorter than 1h? 07:19:34 mk: and the last day, Jul 13th 07:19:48 ... security, Elena will join remotely 07:20:00 mm: threat model, etc. 07:20:08 ... would like more input 07:20:16 ... online survey 07:20:18 mccool: has a questionnaire for security requirements 07:20:32 s/survey/questionnaire/ 07:20:40 please fill out in preparation for the meetings this week 07:21:00 i/mccool:/scribenick: mjkoster/ 07:21:24 mk: please give your input 07:21:38 ... next LD 07:21:48 ... and in the afternoon, marketing topics 07:22:09 ... and then modularization of TF work 07:22:33 q? 07:22:34 q+ 07:23:05 ack k 07:23:16 kaz: planning session? 07:23:23 mk: right. TPAC, etc. 07:23:38 s/etc./security conf., etc./ 07:23:40 victor has joined #wot 07:23:55 mm: for next year 07:24:11 mk: will talk with McCool offline as well 07:25:04 topic: Mozilla's submission 07:25:18 https://lists.w3.org/Archives/Public/public-wot-ig/2017Jul/0000.html 07:25:43 http://iot.mozilla.org/wot/ 07:25:58 mk: would impact our work 07:26:13 mm: important to consider this 07:26:20 ... and other input from Members 07:26:35 ... this proposal is descriptive 07:26:47 ... here we do action, event, etc. 07:26:55 ... need gateway and other things 07:27:03 ... our work is different 07:27:13 q+ 07:27:23 ... we should take this proposal seriously and think about the pros/cons 07:27:59 mk: let's look at this 07:28:03 q+ 07:28:17 ... would have much more fruitful discussion from this 07:28:26 ... could be discussed during TPAC as well 07:28:52 ... straight description on what they want 07:29:28 ... ideas on a possible default binding 07:29:42 mm: could be a default HTTP binding 07:30:08 koster: this is a concrete API 07:30:26 q? 07:30:32 ack d 07:30:56 dsr: agree inviting them to give talk on this 07:31:01 McCool has joined #wot 07:31:07 ... very similar with what I'm proposing 07:31:27 present+ Michael_McCool 07:31:46 seb: 80% of this proposal is copied from what we've been doing 07:32:08 q+ 07:32:09 ... related to the serialization discussion 07:32:15 q- 07:33:06 ... almost aligned with what we've been doing since 2 years ago 07:33:18 q+ 07:33:18 ... this is a JSON approach 07:33:38 mk: this shows developers' hypothesis 07:34:03 ... kind of JSON serialization option 07:34:06 q? 07:34:12 ack McCool 07:34:24 mm: need some tweeks 07:34:36 s/tweeks/tweaks 07:34:37 q? 07:34:39 q- 07:34:45 mk: let's look at this 07:35:38 http://iot.mozilla.org/wot/#web-thing-description 07:35:50 mm: this is descriptive 07:36:24 ... they're doing exposing thing 07:36:34 mk: we do both expose/consume 07:36:49 ... they're doing another side of consuming 07:37:22 mm: they're using only expose, so simple 07:37:45 mk: if you look at "actions" here... 07:38:00 [[ 07:38:01 v 07:38:03 "actions": { 07:38:03 "reboot": { 07:38:03 "description": "Reboot the device" 07:38:03 } 07:38:03 }, 07:38:05 ]] 07:38:31 mk: there is no detail on how to handle this yet 07:38:37 ... it's a draft 07:38:45 ohura has joined #wot 07:38:57 dsr: good to have their proposal 07:39:19 q? 07:40:08 mk: want to go through this 07:40:17 +1 07:40:35 mk: goes through 2.5- 07:40:46 ... 3. Web Thing REST API 07:42:06 ... defining resource type 07:42:24 -> http://iot.mozilla.org/wot/#thing-resource Thing resource 07:42:37 ... example in JSON 07:43:13 mm: there is a "links" section 07:43:23 ... shouldn't be in the example 07:43:46 koster: design in progress 07:43:55 q? 07:44:12 mk: individual URIs and fragments to be concatenated 07:44:49 mk: 3.2 Property resource 07:44:50 http://iot.mozilla.org/wot/#property-resource 07:45:04 mk: doesn't really comply 07:45:22 seba: our approach is just using name-value pair 07:45:54 mk: would see RFC@@ 07:46:14 ... there are so many different IoT platforms 07:46:47 json interchange rfc 07:47:21 mk: we kind of got stuck with actions 07:47:24 ohura has joined #wot 07:47:31 mm: they have concrete idea 07:47:47 koster: expressing some intention we should look at this 07:47:54 ... to see what the main idea is 07:48:20 mm: scripting API 07:48:33 ... you could expose different APIs 07:48:45 ... and this could be a default API 07:49:03 ... we already had discussion when we generated the Charter 07:49:12 mk: network API could be REST API 07:49:35 mm: not conflicting 07:50:06 mk: identify actions and retrieve them 07:50:29 mm: websocket is another option 07:50:49 mk: there is websocket proposal as well 07:50:52 ... goes doen 07:50:58 s/doen/down/ 07:51:16 ... 3.4 Events resource 07:51:57 koster: our concept of "events" is a bit different 07:52:36 mk: 3.5 Things resource 07:52:53 ... 3.6 Alternative Protocol Bindings 07:53:15 http://iot.mozilla.org/wot/#alternative-protocol-bindings 07:53:36 ... 4. Web Thing WebSocket API 07:53:46 http://iot.mozilla.org/wot/#web-thing-websocket-api 07:54:36 mk: easy coupling between the server and the client 07:55:15 ... need to talk about protocols for various vendors, though 07:55:25 ... how to open WebSocket, etc. 07:55:31 ... establishing connection 07:55:52 ... 4.2 setProperty message 07:55:59 http://iot.mozilla.org/wot/#setproperty-message 07:56:32 mk: here you have socket connection 07:57:15 ... and 4.3 requestAction message 07:57:16 http://iot.mozilla.org/wot/#requestaction-message 07:57:37 ... then 4.4 addEventSubscription 07:57:49 http://iot.mozilla.org/wot/#addeventsubscription-message 07:57:57 ... 4.7 event message 07:58:21 http://iot.mozilla.org/wot/#event-message 07:58:46 mk: equivalent to the REST API 07:59:06 ... wouldn't go deeper here 07:59:18 ... 5. Web Thing Types 07:59:30 http://iot.mozilla.org/wot/#web-thing-types 07:59:45 mm: simple built-in vocabulary 08:00:08 mk: 5.4 Extensibility with JSON-LD 08:00:26 http://iot.mozilla.org/wot/#extensibility-with-json-ld 08:03:50 Dave: we should also consider this from the perspective of what would be needed from a thing description to support the Mozilla IoT platform, given that the web of things needs to support a very broad range of IoT platforms 08:04:09 q? 08:04:17 q+ lindsay 08:04:48 mm: having simple default Web API 08:05:14 ack l 08:06:07 mm: mentions OCF approach 08:06:10 zkis has joined #wot 08:06:20 ... RAML and Swagger 08:06:29 ... Swagger more momentum these days 08:06:44 q? 08:07:03 mk: RAML and Swagger are tightly coupled to what the server is offering 08:07:15 ... the key is loose-coupling 08:07:45 koster: big plus 08:08:15 q? 08:08:23 q+ 08:08:45 mk: how should JSON serialization should be? 08:08:52 ... concise and developer friendly way 08:09:20 ... so that we can convert it to another serialization 08:09:37 ... we saw a parameter of "actions" here 08:10:25 ... there are patterns of property, action and event 08:10:33 ... may need some interaction pattern 08:10:34 q? 08:10:45 dsr: we have metadata for TD 08:11:32 ... we have to live with driver model given existing various devices 08:11:53 ... simple interaction model 08:12:05 ... TD just has minimal information for drivers 08:12:25 mk: you can't model that simple interaction model 08:13:43 lindsay: do you plan to enforce some guideline? 08:14:04 ... setting actions and write parameters, etc. 08:14:15 mjkoster has joined #wot 08:14:17 mk: there is a device with some property 08:14:30 ... the other thing has reset button, etc. 08:14:44 ... think about interaction between them 08:15:07 ... layering on top of discussion yesterday 08:15:23 victor: this is already modeled 08:15:31 ... e.g., for building automation services 08:15:45 ... action on some property 08:15:55 ... equivalent to changing property 08:16:13 mm: we need response from Mozilla 08:16:20 victor" modeled in SAREF 08:16:36 s/victor"/victor: 08:16:59 mm: how to integrate with our document 08:17:22 mk: we have good questions about this proposal 08:17:35 ... it's a complicated theme 08:17:58 mm: having an analysis would be good 08:18:14 mk: we'll have activity on JSON serialization 08:18:25 ... and see gaps 08:18:47 ... this is another IoT platform which we (WoT) would like to describe 08:19:10 ... any other opinions? 08:19:22 mm: the other possibility is defining a simple default 08:19:34 ... simple descriptive definition 08:19:59 mk: we won't create yet another standard 08:20:21 ... our description should be easily mapped 08:20:30 mm: there is a definition on eventing 08:21:30 ... could be a hybrid way 08:21:43 q? 08:22:41 mm: we should seek to make it really easy to provide a thing description for their platform. 08:23:23 zkis has joined #wot 08:23:53 kaz: this proposal is about interface between component, e.g., servient A and sevient B, with our context 08:24:11 mk: maybe gateway and client possibly 08:24:45 kaz: let's invite them to our telcos and TPAC f2f, etc. 08:24:48 mk: actions: @@@ 08:25:25 ... go through possible responses on Thursday and let's invite them 08:31:29 s|@@@|1. next step is (1) draft response to them by Thursday, (2) get JSON serialization TF which compare/integrate/extend Mozilla's proposal, (3) have a joint call with them and (4) invite them to TPAC| 08:31:45 s/mk: actions:/RESOLUTION:/ 08:31:49 rrsagent, make log public 08:31:55 rrsagent, draft minutes 08:31:55 I have made the request to generate http://www.w3.org/2017/07/11-wot-minutes.html kaz 08:32:45 i|meeting: Tech|scribenick: kaz| 08:32:45 rrsagent, draft minutes 08:32:45 I have made the request to generate http://www.w3.org/2017/07/11-wot-minutes.html kaz 08:33:15 s/meeting: Tech/topic: Tech/ 08:33:16 rrsagent, draft minutes 08:33:16 I have made the request to generate http://www.w3.org/2017/07/11-wot-minutes.html kaz 08:33:42 i/please give your input/scribenick: kaz/ 08:33:43 rrsagent, draft minutes 08:33:43 I have made the request to generate http://www.w3.org/2017/07/11-wot-minutes.html kaz 08:34:00 i/1. next/next/ 08:34:01 rrsagent, draft minutes 08:34:01 I have made the request to generate http://www.w3.org/2017/07/11-wot-minutes.html kaz 08:42:38 mjkoster has joined #wot 08:44:03 dsr has joined #wot 08:47:59 i/RESOLUTION:/mk: summarizes the discussion and defines the nest step/ 08:50:53 dsr has joined #wot 08:52:03 McCool has joined #wot 08:52:52 naka has joined #wot 08:54:15 s/maybe/they don't have servient, so maybe/ 08:54:28 rrsagent, draft minutes 08:54:28 I have made the request to generate http://www.w3.org/2017/07/11-wot-minutes.html kaz 08:54:33 [break] 08:54:45 topic: Serialization - Daniel 08:54:57 slides tbd 08:55:29 dp: [TD Serialization test-bed] 08:55:50 ... on github: github.com/w3c/wot-thing-description/tree/master/test-bed 08:56:11 ... started to collect data from various sources: WoT CP document, PlugFests, SDO mappings 08:56:30 ... [Measurements Osaka PlugFest] 08:57:34 ... shows graph including the data serialization variations: JSON, CBOR, SMIL, EXI4JSON 08:57:44 ... [Measurements Dusseldorf PlugFest] 08:58:04 ... [Outlook] 08:58:11 ... how can we improve even further? 08:59:45 ... [Optimized JSON-LD Example] 09:05:26 ... shows an example 09:05:42 (got a trouble with screen sharing...) 09:06:32 victor: devices are deployed somewhere not owned 09:06:44 q? 09:06:48 ack k 09:07:45 carsten: shows his slides 09:07:45 slides tbd 09:08:18 zkis has joined #wot 09:09:01 McCool: ways to reduce size: standard fields in fixed order; defaults; query parameters on API to get td (eg include semantic tagging only if asked) 09:09:36 carsten: [Objectives] 09:10:10 McCool: regarding very small devices (eg SigFox) - might be best to return a simple identifier (eg a URL) rather than a TD; we want a TD to describe how to talk to small devices, but those devices don't necessarily need to generate or consume TDs themselves 09:10:44 ... represent TD information 09:11:08 ... what do we want optimize? - compactness/usefulness for processing? 09:11:29 McCool; BTW, defaults and multiple serializations also lead us to one possible way to align with the Mozilla/Evrything "prescriptive" network apis 09:11:45 ... what are our assumptions about the devices - holding TDs? 09:11:52 ... [Maximizing compactness] 09:12:03 ... use traditional data compression 09:12:23 ... e.g., deflate, LZ77 09:12:53 ... need some memory for decompression 09:12:56 McCool: eg one particular choice of serialization (and the defaults in that serialization...) could end up looking a lot like the Mozilla proposal... but still could be serialized in a more explicit, expanded serialization that make all the default values explicit could still be available. 09:13:27 s/... what/carsten: what/ 09:13:38 carsten: [Choosing a compressor] 09:13:55 ... LZ77: sharing via 09:14:07 ... need entropy encoder too 09:14:38 ... classical algorithms: deflate (LZ77+Huffman), LZ4 (low complexity) 09:15:37 ... [Maximizing processability] 09:15:45 ... [Experiment 09:15:46 s/t/t]/ 09:16:05 ... wot-thing-description/test-bed/data/plugfest/2017-05-osaka/MyLED_f.sonld 09:16:29 ... JSON file: 3116 09:16:37 ... JSON withoug whitespace: 1447 09:16:50 ... deflate: 323, lz4: 415, lz4hc: 411 09:16:55 ... CBOR: 1210 09:17:06 ... deflate: 325, lz4: 416, lz4hc: 404 09:17:19 ... CBOR packed (semantic sharing only): 793 09:17:29 ... CBOR packd (prefix compression, too): 564 09:17:54 ... 2 steps 09:18:21 ... semantic sharin gonl vs prefix compression as well 09:18:47 ... [Conclusion] 09:19:05 ... packing (exploiting structural sharing) 09:19:46 ... maintains processability, saves 1/3 (implementation not yet complete) 09:19:57 ... prefix sharing helps with URLs, another 20% 09:20:03 ... but reduces processability 09:20:16 ... could further improve by adding static dictionary? 09:20:27 ... in the example: 119 bytes of mostly static data 09:20:55 ... name, type, links, application/json, outputData, mediaType, href, etc. 09:21:14 dp: ideas we can share 09:21:55 ... get rid of static data 09:23:37 ... different ways to achieve it 09:23:55 ... questions? 09:24:29 mm: 3000 characters reduced 09:24:46 (Carsten goes back to [Experiment]) 09:24:50 carsten: yes 09:24:55 tokuyama has joined #wot 09:26:44 mk: would go for easy processing, e.g., CBOR, EXI 09:27:27 seba: deflate-based compression would be useless, I think 09:27:44 ... quite heavy to install on small devices 09:27:57 ... what can be the maximum compression ratio is not the best question 09:29:12 ... need some more clarification how it works 09:29:31 mk: TD includes set of property, action, event 09:29:43 ... same way of having a dictionary 09:30:31 dsr: could do compression on Arduino, etc. 09:30:37 ... but keeping battery down 09:30:57 cabo has joined #wot 09:31:04 dp: you need more memory for data without compression 09:31:14 ... processing may be ok 09:31:34 ... on a powerful device, it's worth trying 09:31:50 mk: we have deep dive on JSON and CBOR 09:32:14 ... Mozilla proposal also mentioned JSON serialization 09:32:46 topic: Open-Source Strategy 09:33:02 s/topic: Open-Source Strategy// 09:33:08 seba: what is the next step? 09:33:18 mk: we can collect examples 09:33:34 ... people can present like Carsten too 09:33:53 ... size of the representation, compression ratio, ability/usefulness, etc. 09:34:09 dp: which data should be used as the basis? 09:34:29 dsr: have some material on GitHub 09:34:49 q+ 09:35:02 mm: can do the discussion offline 09:35:12 mk: let's put the items on a short list 09:35:15 q? 09:35:28 topic: Open-Source Strategy 09:35:36 slides tbd 09:36:04 zk: [WoT WG deliverables] 09:36:24 ... normative specs: WoT Arch, TD, Scripting, Test cases 09:36:36 ... [Implementation(s) as Deliverables] 09:36:54 ... WG Charter says under "Success Criteria" 09:37:14 ... requirement for implementation experience 09:37:39 ... [W3C Software...] 09:37:45 ... [node-wot] 09:38:04 ... should node-wot be a WG oss implementation? 09:38:24 ... if yes, need to apply W3C license 09:38:44 mk: we've been contacting eclipse as well 09:38:55 ... open source management in general 09:39:21 ... possibly on eclipse foundation with W3C license 09:39:49 ... we need 2 implementations anyway to make specs RECs 09:39:59 mm: do we need a resolution? 09:40:11 ... implementation deliverable 09:40:20 q? 09:40:23 q+ 09:40:29 q- 09:40:51 dsr: proposed resolution given not all of the participants are here 09:41:05 kaz: also suggested that to McCool 09:41:30 mk: do we need to update our Charter? 09:41:35 dsr: don't think so 09:41:45 kaz: agree 09:41:57 zk: also talked with Anssi about this 09:42:06 ... and the Chair can make decision 09:42:54 mm: the Chairs would recommend to make the wot-node implementation a deliverable of the WoT WG 09:43:07 q- 09:47:36 topic: Web of Things - Dave 09:47:45 dsr: [Developer Feedback] 09:47:57 ... startups and SMEs 09:48:04 ... [Current Practices] 09:48:20 ... TD based on JSON-LD and JSON Schema 09:48:34 ... some drawbacks 09:48:46 ... [Mozilla Web Things] 09:48:58 ... simple, obvious use of JSON for TD 09:49:04 ... [My proposal] 09:49:21 ... similar to Mozilla's proposal 09:49:31 ... PoC server implemented with node.js 09:49:50 ... tested against OCF, oneM2M, Echonet 09:49:58 ... [Mapping JSON to Linked Data] 09:50:10 ... property names treated as either predicates/names 09:50:37 ... predicates mapped to RDF URIs via @context 09:50:57 ... enumrations as JSON arrays 09:51:09 s/enumrations/enumerations/ 09:51:21 ... short cut when you only need to state property type 09:51:37 ... JSON object property reserved terms: types, properties, actions, events 09:51:48 ... names must not start with "@" 09:52:01 ... (shows GitHub repo) 09:52:27 ... w3c/wot/proposals/dsr-td/json-to-ld-dsr.md 09:53:07 ... www.w3.org/WoT/demos/td2ttl 09:53:15 ... would group's review 09:53:52 mk: this is an example serialization proposed by you 09:54:04 dsr: yes 09:54:19 ... (shows jsonto-ld-dsr.md again) 09:54:33 ... "properties" is metadata 09:54:44 ... acceleration is a name 09:55:04 ... shows spec on what I'm working on 09:55:44 mm: good to have multiple options for serialization depending on the need 09:56:03 ... could have a library for node.js 09:56:19 dsr: good idea 09:56:33 ... so far quite flexible 09:57:25 seba: TD is generated automatically by servient 09:57:52 ... why do we need to think about non-semantic-based TD serialization? 09:58:00 q? 09:58:07 q+ 09:58:12 q+ 09:58:29 mjkoster has joined #wot 09:59:21 mk: we should think about different serialization examples 09:59:44 ... there are proposals for serialization 09:59:49 ... actual data is semantic data 10:00:00 ... we need tools for serialization 10:00:26 ... essential building block is still TD 10:02:01 mm: agree we should handle core TD model and serialization separately 10:02:31 ... regarding another point that developers don't touch TD 10:03:05 seba: agree to need for easy structure for TD 10:03:49 q+ 10:03:55 ack Mc 10:04:48 mm: we need more concrete examples 10:05:49 mk: you have prototype 10:05:57 ... some parts missing 10:06:16 dsr: idea here is extensible support for Linked Data 10:06:36 ... generic mechanism for mapping JSON to LD 10:06:44 q? 10:06:54 mk: but seems like you're reinventing JSON-LD... 10:07:18 ... that is not good for WG discussion 10:07:32 dsr: the idea is that LD is underlying data model 10:07:50 q+ 10:07:52 ... simple JSON it's simpler than JSON as a possible serialization 10:07:56 ack v 10:08:34 matthias: how does protocol binding work with this? 10:08:51 victor: this is not 100% corresponding to what we've been doing 10:09:21 ... can try to link it to our spec? 10:09:34 dsr: depends on which predicate is used 10:09:55 victor: compatibility with our proposals so far? 10:10:51 q? 10:11:35 mk: we have a problem 10:11:48 ... this is a different proposal than Mozilla's proposal 10:12:11 ... there is no connection at the moment 10:12:13 q? 10:12:26 kaji: agree with Matthias 10:12:34 ... we should fix the spec asap 10:12:49 s/we/as WG, we/ 10:13:03 ... and as IG, this is a new input for v2 10:13:18 ... so would ask Dave to split this proposal from WG work 10:13:26 ... this should be an input for IG 10:13:44 q? 10:13:57 ... we should be careful how to handle this 10:14:10 lindsay: interested in the problem space 10:14:23 ... extensible exchange of metadata 10:14:44 ... would be good to have a beauty contest (survey?) 10:14:48 mk: would wrap up 10:14:59 ... we decide core model 10:15:16 ... this is a model formally defined by semantic web technology 10:15:27 ... e.g., JSON-LD is already a standard 10:15:45 ... we could do some beauty up things 10:15:58 ... there is still constraints with JSON-LD of course 10:16:31 ... there is no concrete specification on serialization 10:16:48 ... as Kajimoto-san mentioned this could be an input for next version 10:17:03 ... concise serialization as well 10:17:12 s/as well/also possible/ 10:17:23 ... let's continue the discussion tomorrow as well 10:17:25 q? 10:17:43 ack z 10:17:51 q- zkis 10:17:52 q- 10:18:59 kaz: purpose of this? 10:19:04 ... who/how/where to use this? 10:19:14 dsr: consume thing and expose thin 10:19:45 kaz: e.g., between consume thing servient and expose thing servient 10:19:51 ack k 10:20:13 s/expose thin/expose thing/ 10:20:24 [ lunch ] 10:20:28 rrsagent, draft minutes 10:20:28 I have made the request to generate http://www.w3.org/2017/07/11-wot-minutes.html kaz 11:21:38 naka has joined #wot 11:25:47 cabo? 11:35:23 naka has joined #wot 11:35:24 nwidell has joined #wot 11:38:36 dsr has joined #wot 11:39:01 scribenick: dsr 11:39:55 ryuichi has joined #wot 11:40:24 topic: Binding Templates 11:41:00 Michael Koster presents some slides setting out the background to protocol binding 11:41:19 i|Michael|slides tbd| 11:41:58 The protocol binding refers to the information needed for a driver for the chosen IoT platform/protoocol 11:42:01 dape has joined #wot 11:43:11 Shows a JSON example witg protocol binding within a “links” section 11:43:24 s/witg/with/ 11:43:47 Introduction using OCF as an example platform 11:45:27 Michael shows how @type can be used in JSON-LD to identify the OCF type for each property 11:45:44 ohura has joined #wot 11:46:29 In addition, there are fields for href, content-format, method, resource type etc. as needed by OCF. 11:48:40 naka has joined #wot 11:48:44 Michael displays a slide the depicts two ways to intergrate with OCF. One is where a WoT application acts as a client for a thing provided by an OCF device. Another is where a WoT application provides a thing that is exposed to clients as an OCF device. 11:49:10 In otherwords, both providing and consuming things using the OCF standards 11:50:18 Discovery: enabling apps to discover thing descriptions containing given semantic constraints 11:51:08 Discovery could be supported in terms of WoT thing descriptions as well as in terms of the OCF discovery protocols 11:51:45 Karen has joined #wot 11:52:45 Sebastian: are you assuming CBOR? 11:52:48 zkis has joined #wot 11:53:09 q? 11:53:11 Michael: you could use CBOR, but this is not specific to CBOR 11:54:41 Matthias provides his personal summary 11:56:12 When mapping from the interaction by apps to the protocol level, the mapping depends on the protocol. This could be very simple for JSON based protocol payloads 11:56:43 q+ 11:57:56 Dave: where is the IoT platform identified? 11:58:21 I would expect a link to a platform identifier 11:58:53 ack z 11:59:41 Zkis: we have properties, actions and events for the interaction model, do you see a reason for exposing capabilities? 12:00:14 Matthias: I will let Michael respond to that one 12:00:50 The same capability could be exposed via different interaction models 12:01:34 Michael: we could refer to a shared vocabulary for the capabilities 12:02:08 It could be useful to include this directly 12:02:51 Dave: this is really part of the semantic models 12:03:07 q+ 12:03:31 Zoltan: do we need standard vocabularies for capabilities? 12:03:45 sebastian has joined #wot 12:04:07 Matthias: this is something from groups that define domain specific vocabularies, and not something we will do in this group 12:04:09 +q 12:04:36 uday has joined #wot 12:04:37 Zoltan: an example is an on-off capability 12:05:07 Matthias: this could be used as part of a semantic query 12:05:43 q? 12:06:02 Zoltan: how is this attached? 12:06:47 Matthis provides an explanation … 12:06:50 ack Dar 12:07:23 Darko: capabilities are essentially semantic annotations 12:07:31 * DarkoAnicic please move closer to the mike 12:08:20 This is to be discussed 12:09:44 mjkoster has joined #wot 12:09:45 ack Darko 12:10:07 q? 12:10:09 ack d 12:10:25 We need to look at how the annotation mechanisms 12:11:25 Dave: we need to distinguish interaction models and semantic models. The semantic models describe the capabilities and how a specific device implements these in its specific interaction model that may vary from one device to another 12:12:19 Not all apps will need the semantic models, so we shouldn’t require them to be included in the interaction model 12:12:48 Sebastian: such apps could ignore the semantic annotations 12:13:33 Sebastian: what is the status of the node-wot implementation in respect to the OCF binding? 12:14:15 Kaz displays a slide by Kajimoto-san on a protocol binding building block 12:15:06 This has a protocol binding module that in turn binds to IoT platform specific modules. 12:16:50 Examples include oneM2M with JSON over HTTP, OCF with CBOR over CoAP, WoT with CBOR over CoAP, WoT with CBOR over HTTP, and WoT with JSON over HTTP. 12:17:43 Kajimoto-san describes his ideas for identifying the IoT platform, transport protocol, serialization format and security technology 12:19:06 He shows a slide with mapping from abstract operators to HTTP/CoAP Methods 12:21:49 Panasonic have been exploring some ideas for implementing this, along with the details for the thing description 12:23:22 mjkoster has joined #wot 12:23:24 Dave: the protocol and serialisation could be part of the platform identifier, and the operations could be implicit, resulting in considerable simplications in the thing description. 12:25:08 Matthias: yes, there is a choice in how this is done 12:26:33 Matthias: there are many web platforms, where the transformations are very simple 12:27:15 Michael_McCool: this could be a useful default, as a further means of simplifying the TD 12:28:06 McCool has joined #wot 12:28:19 Kajimoto-san: my approach is applicable to the Mozilla proposal 12:28:19 present+ Michael_McCool 12:28:47 Sebastian: … 12:30:13 i|Sebastian:|kaz: right. that's why I also confirmed at the end of the morning session that Mozilla's proposal was about inter-component I/F| 12:30:24 topic: OCF Binding Prototype - McCool 12:30:32 scribenick: kaz 12:30:45 mm: [Outline] 12:30:59 ... goal is working perfectly at TPAC 12:31:09 ... [Goal] 12:31:15 ... consume OCF metadata 12:31:18 ... output a TD 12:31:42 ... attempt *automatic* translation of metadata 12:32:01 ... for better scalability 12:32:08 ... [Prototypes 12:32:12 s/s/s]/ 12:32:23 ... ocf-bridge, ocf-generator and ocf-client 12:32:44 ... different project for ocf generator 12:33:15 ... also testing 12:33:22 ... issue on name collision 12:33:27 ... [Architecture] 12:33:37 ... issues come from multiple places 12:34:03 ... need to extract OCF metadata from multiple sources 12:34:20 ... integrate instance metadata, type metada and OCF standard metadata 12:34:32 ... how to get introspection 12:34:39 ... which resource is actually useful? 12:34:47 ... implicit in the spec 12:35:05 ... most of them are currently encoded in my code 12:35:52 ... some additinla hand-written metadata required per OCF "resource type" still needed 12:36:22 ... annotation metadata 12:36:48 ... would make it (hand-written part) as small as possible 12:36:55 ... [Annotation Metadata] 12:37:44 ... semantic tagging, which resourece types should be exposed?, which combinations of interfaces make sense?, actions/events, names and writable properties? 12:39:08 ... [Annotation Example] 12:39:30 ... currently doing some cheat and would like to gather information automatically in the future 12:39:53 ... a bit different from what Koster does 12:40:21 ... protocolCOntent shows mapping between protocol and data format 12:40:36 ... [TD Example (one Interaction)] 12:43:33 naka has joined #wot 12:44:06 ... [Prototype Limitations] 12:44:12 ... one complication 12:44:17 ... extension mechanism of OCF 12:45:10 ... doesn't handle multiple rt/if combinations 12:45:28 ... including some unnecessary "OCF internal" resources in the output 12:45:35 ... [Issues] 12:46:19 ... [TD Example (one Interaction) - revisit] 12:46:47 ... offline device joins the network 12:47:37 ... [Suggestions] 12:47:39 OCF device identifiers are dynamically generated each time the device boots 12:47:47 ... protocol binding templates as strings 12:48:02 ... separate template media type that can be converted to wire media type 12:48:22 s/... protocol/mm: protocol/ 12:49:02 ... alternatives: make template always be JSON, get rid o template and make it equivalent to parameter map, e.g., make generation of payload the full responsibility oof the driver 12:49:24 ... add additional "driver" parameter so that target device ecosystem, e.g., OCF, can be identified 12:50:14 ... [Next Steps] 12:50:24 ... update to intercept protocol binding protocol 12:50:31 ... implement protocol binding templates 12:50:46 ... implement oocf-gather to ingest existing OCF type metadata 12:50:53 ... additional semantic annotation mechanisms 12:50:59 ... pull request on node-wot 12:51:07 ... try some other IoT standards 12:51:14 ... [Conclusions] 12:51:24 ... it's possible to do mapping automatically 12:51:31 ... but OCF is relatively easy 12:51:42 ... since webish 12:51:55 ... need to repeat this exercise with additional standards 12:52:02 q? 12:52:05 q+ 12:52:14 q+ 12:52:17 lindsay: would go back to some slide 12:52:26 mm: [Prototypes] 12:52:35 lindsay: have to have some software package? 12:52:45 mm: modular decision 12:52:54 ... rather than implementing bridges 12:53:07 ... you can use bridges 12:53:17 ... consumes OCF TD 12:53:28 ... generator is more online 12:53:32 q? 12:53:33 mjkoster has joined #wot 12:53:38 q? 12:53:44 ack kaz 12:53:58 Kaz: how to integrate this work with the plugfest? 12:54:09 i/how/scribenick: dsr/ 12:54:43 mk: helpful to get actual use cases 12:54:47 Mm: ideally we would get this running with a variety of devices for the next plugfest 12:54:55 s/mk: helpful to get actual use cases// 12:55:11 Matthias: we need to agree on the details for that 12:57:12 naka has joined #wot 12:57:18 mm: more generally we need a translation, OCF is an easy case, so we need to look at a more challenging IoT platform 12:57:44 Matthias agrees 12:58:41 mm: we can say it is the driver’s responsibility to create the payload, so we can then drop the details in the protocol binding 12:59:18 Matthias describes how whether we use JSON or CBOR, we can keep the translation simple 12:59:33 q? 13:00:40 mm: JSON over CBOR is straightforward, but for other cases the driver could transform from JSON to the on the wire format 13:01:00 mk: LwM2M is such an example 13:01:24 q? 13:01:26 ack d 13:02:53 Dave: as we expand beyond REST, we will need a more general approach - an identifer for the platform and the associated metadata 13:03:15 mk: some of those platforms are migrating towards IP and REST 13:03:37 q? 13:03:44 q+ seba 13:03:44 ack s 13:04:21 Sebastian: iot would be helpful to have a set of online devices that we can experiment with 13:04:36 mm: we can do that for OCF 13:04:51 using virtual devices. 13:05:29 Sebastian: we want this for a broad range of platforms 13:06:39 mm: if anyone wants to look at code and has any questiions please contact me 13:06:52 mm: I am thinking now about other platforms 13:07:28 LwM2M is a good candidate as it also uses CoAP, as is oneM2M 13:09:06 mkovatsc has joined #wot 13:12:54 Kazu_ has joined #wot 13:24:33 naka has joined #wot 13:37:50 mkovatsc has joined #wot 13:38:05 uday has joined #wot 13:38:06 mjkoster has joined #wot 13:38:19 Topic: IoT Marketplace 13:38:25 Topic: IoT marketplace 13:38:36 scribenick: uday 13:38:51 i/IoT Market/[ break ]/ 13:40:06 Seba: Need standard way to deploy IoT capabilities 13:41:15 Seba: there is also an economic perspective to IoT Marketplace 13:42:55 Seba: describes the motivation and scope of IoT Marketplace 13:43:17 q? 13:43:20 q+ 13:43:58 Philip: what other marketplaces out there? 13:44:35 Stefan: lots of marketplaces but none for IoT data 13:46:45 ack mkovatsc 13:46:45 Matthias: should consider this while designing TD 13:47:24 Mccool: can distribute scripts, thing and data 13:47:48 Mccool: Bid IoT mostly concentrates on data but can share other oarameters to 13:48:17 parameters 13:48:47 q? 13:48:51 stafan: cannot share code 13:49:01 soumya has joined #wot 13:49:03 McCool has joined #wot 13:50:27 Seba: need to setup a charter, what to be in the charter, licensing info, pricing info etc., 13:50:42 q+ 13:51:20 Seba: Describes the architecture 13:52:14 Seba: marketplace to be aligned with WoT concepts, thing's metadata ... 13:53:56 Dave: idea to allow people to design services and instantiate it with specific devices, discover and consume these services. Then what kind of APIs doe we need to support that? 13:54:16 Darko: Most will be covered with the idea of recipies 13:55:08 Lindsay: description of data in the project called "Inspire" 13:55:31 I very much support starting work on this and will also do my best to channel the lessons learned on IoT marketplaces that we learned in the EU Compose project on highly scalable IoT cloud based platforms 13:56:22 Kajimoto-san: Marketplace is a good idea, can refer to advertisement technology 13:56:24 q? 13:56:35 ack dsr 13:56:40 q+ 13:57:04 q+ 13:57:30 Seba: software not in scope. Idea is to have semantic description to setup and interact with a service 13:58:04 ack mc 13:58:12 Mcool: to limit the scope, search which connects to linked data- discovery 13:58:13 q? 13:59:54 Seba: Marketplace is just a href 14:00:27 ack dsr 14:00:57 Matthias: could use manager thing mechanism 14:01:30 Dave: there is a business opportunity for installable services, e.g. to install them on a home hub, perhaps from the vendor’s websiite or in the case of native apps, from Google Play or the Apple app store etc. 14:02:31 so I respectfully think it would be a mistake to preclude installable services 14:03:05 stefan: discovering things is linked to TD 14:03:50 Nimura-san: missing point would be related security. How do we deal with this and also the payment? 14:03:51 sebastian: download a servient component in the process of receiving a service 14:04:14 Sebastian: the metadata could list preconditions such as services or drivers that need to be installed. These could be referenced and hosted elsewhere 14:05:40 McCool: I think that a marketplace that just includes existing services and data makes sense to START; but it naturally leads to installable services 14:05:41 Seba: consumer has always to request the thing to get the data 14:06:10 however, there are some preconditions to installable services: a secure runtime implementation that can run untrusted third-party code 14:06:29 accomplishing that will probably require some collaboration with eg. OpenFog, etc. 14:06:38 q+ 14:06:44 Seba: should be complete independent of the protocol used 14:07:25 Seba: who do we address: IoT Platforms, Cloud providers, Infrastructure providers 14:08:17 Date: also add search engine providers 14:08:25 s/Date/Dave/ 14:08:40 Seba: is WoT the right place? 14:08:58 Mcool: falls in general category of discovery, so in scope 14:09:09 Search engines will be interested in indexing services via metadata on vendor’s websites 14:09:30 s/via/advertised via/ 14:10:02 stefan: as long as open issues in TD it may be early, but if TD is done then this might be the right time 14:10:47 Matthias: might be implications on requirements, good startting point if Big IoT could share their findings 14:11:37 Stafan: decided not to limit to things, want to deal with data from many things 14:12:31 Seba: most of the content is the same as current TD 14:13:13 Matthias: good to have pointers form project working for the future 14:13:42 Seba: its a bit early now, might meet after 6 months to move forward 14:14:26 seba: can invite e-commerce partner as well 14:14:50 Topic: Local device protocol 14:15:22 Mcool: could a thing access interfaces of the device 14:15:50 Matthias: how to handle local hardware is 1 year old discussion 14:16:41 q+ 14:16:58 Matthias: too big of a topic. Interaction to local hardware should also go through the thing. 14:17:20 Mcool: should we define standard local things? 14:18:48 Dave: W3C has experience with APIs which can be used 14:19:35 Mcool: GPIO thing accessible to the outside world is chaotic. Good to have it within the local network 14:20:38 Mcool: Can I put in examples in node-wot folder? 14:20:59 Matthias: defining various API should be marked in a branch 14:21:01 Dave: we can provide some guidelines, but we can’t preclude IoT platforms from exposing their own APIs (e.g. Arduino modules) locally to application scripts. 14:21:23 -> https://docs.google.com/presentation/d/10xeircxLQzC7cOgArfMkxPMd1_kFjlQjiyan5zT-11k/edit#slide=id.g223c523f22_0_224 WoT Stack 14:21:42 jeff has joined #wot 14:21:47 Kaz need some help with scribing 14:22:55 Michael and Matthias discuss the idea of some standardised local things 14:23:18 thanks Dave, please add what you can! 14:24:18 Matthias: as Dave mentiioned we could consider adopting the browser APIs for local hardware and seeing what we can learn from their approach to security and privact 14:24:28 s/privact/privacy/ 14:25:46 kaji: [WoT Model Description and APIs] 14:26:09 i/we can provide/scribenick: dsr/ 14:26:19 i/kaji:/scribenick: kaz/ 14:26:26 Kajimoto-san: explians two API concept. one for physical world and one for cyber world 14:26:55 s/kaji:/Kajimoto-san:/ 14:27:08 rrsagent, draft minutes 14:27:08 I have made the request to generate http://www.w3.org/2017/07/11-wot-minutes.html kaz 14:27:15 Mcool: treat both physical and cyber things same, so we can have a common API 14:27:18 mm: the conclusion from the Panasonic F2F was to use things and thing descriptions for both 14:28:05 Dave: what about arduino, rasberri APIs 14:28:15 s/explians/explains/ 14:28:30 Mcool: can wrap them to have access to the hardware 14:28:33 i/two API concept/scribenick: uday/ 14:28:50 i/the conclusion/scribenick: dsr/ 14:29:02 i/what about/scribenick: uday/ 14:29:05 rrsagent, draft minutes 14:29:05 I have made the request to generate http://www.w3.org/2017/07/11-wot-minutes.html kaz 14:29:19 Matthias: need the API available everywhere, gets hard with individual APIs 14:30:12 Mcool: we need to make a list of resources 14:30:32 Dave: we need to clarify our messaging: things provide an elegant means to wrap access to local hardware, but platform specific APIs are also going to happen, and will require care with security 14:30:52 Matthias: more important to document the learnings 14:31:05 Matthias: the thing approach offers greater portability 14:31:34 [ Tech Day 1 ends] 14:31:42 rrsagent, draft minutes 14:31:42 I have made the request to generate http://www.w3.org/2017/07/11-wot-minutes.html kaz 15:38:11 dsr has joined #wot 16:01:13 Karen has joined #wot 16:24:27 Zakim has left #wot 16:52:28 zkis has joined #wot 18:59:48 jeff_ has joined #wot 19:08:02 jeff__ has joined #wot 20:58:18 zkis has joined #wot 22:42:19 yatil has joined #wot 23:11:03 Karen has joined #wot