<kaz> scribenick: Soumya
<yamada> my PR is https://github.com/w3c/wot/pull/397
yamada-san: three main commits in
this pull req
... 1. adding panasonic TDs
... 2. link of those TDs
... 3. 3.1 event and observe using http
kaz: it is about plugfest scenario
matthias: section 3 is about servient features right?
matthias: could fit to both
yamada-san: last one is imp
... participants will be panasonic and fujitsu (and any
other)
... mentions purpose and application scenarios
... mentions functionalities and roles including application,
proxy and device (including the steps to run the
scenarios)
... please merge this pull req to master branch
kaz: pull req is a proposal about
how to describe a plugfest scenario?
... think about balance b/w proposals from yamada-san and
mjkoster
mccool+matthias: +1 for merging
mjkoster: this is fine
kaz: thanks yamada-san
darko: one question: fujitsu
local proxy: are we going to have multiple TD repo?
... main TD repo (normally we have), now there is one more from
fujitsu.. shall we have multiple repo?
matthias: what we saw is on eventing ...
matthais: ppl may have multiple directory for testing
mccool: register in more than one TD
<kaz> [note that we had multiple TD directories for Burlingame plugfest: https://github.com/yamagile/wot/blob/0ffc939cec812bec0df847ca6df383b88a0ff993/plugfest/2018-prague/images/burlingame.png?raw=true]
mccool: suggest: generate TD with
more than one base addresses
... addresses with a certain format
... network context is imp
mccool: more than one TD running
is possible
... is darko validating the TD?
darko: not really
matthias: TD playground, should be up
in AWS
... edit TD and then validate syntax and other checkers
mjkoster: thingweb TD is picky,
gives some errors in certain cases... there is an error with
cross origin resource sharing
... agree that we can have multiple TD... some local, some
remote...
... network segment may differ
matthias: TD URI directly in that
... combination of local IP and global URLs
mjkoster: maintain a small list manually
kaz: possibly we could add that as the section 8 on issues for plugfest
mccool: better to use the issue tracker,
suggest to have a section on validation
... someone should volunteer to create and track the issue
(multiple TD)
... i can do it
kaz: please add "PlugFest" label to that issue
mccool: ok
matthias: asking mjkoster about json-ld file
mjkoster: context is failing sometimes, i will file issue(s)
matthias: should be in the thingweb
directory
... valid json-ld is fine, thingweb parses TD and puts it in
tripplestore ...
... talk to victor about usability
kawaguchi-san: in summary, who is going to bring a proxy other than fujitsu?
kaz: proxy and thing directory?
matthias: victor is working on it
... locally run a patch version
kawaguchi-san: describe it in the prep doc.
<McCool> https://github.com/w3c/wot/issues/403
mjkoster: has an instance of
thing repo (public)
... proxy by node-wot
matthias: tunnel that has a local
endpoint and public hoster endpoint
... websocket b/w endpoints
... http proxy last time
... either panasonic or fujitsu should bring tested proxy
... is there any logistics issue?
mjkoster: exposing an instance
from a cloud
... create a local IP proxy for that
matthias: consuming thing on a cloud
that wants to consume a local thing - would not work - scenario
is complex
... panasonic and fujitsu did it using custom tunneling
lasttime
kawaguchi-san: fujitsu to bring
local and remote proxy
... panasonic to register local and remote things
mccool: tunneling worked for me last time, easy to setup but proxy is safer solution
kaz: intel and smartthings to connect to fujitsu proxy?
mccool: yes
kaz: other questions about this?
(none)
<kaz> Koster's PR
<kaz> changes
mjkoster: scenario is - reg
client, managing lifecycle
... easy 3rd party integration
... create and advertise
... client is going to use semantic discovery
... fill in the recipe ingredient
... manually ...
... using mqtt and http
... not using coap
... client has some o-auth for verification, delegation, 3rd
party security provider
... currently user gives permission ...
... read write execute permission
... system - node-red based local servient, client
servient
... use hosted proxies, either way works, local to cloud is
imp
... cloud-to-cloud is also possible
mccool: can we have bridging scenarios?
<kaz> rendered version fyi
mccool: two wi-fi and access points and then try to bridge them
mjkoster: bring a router myself,
could be possible
... last part - requirements
... iotschema annotation capabilities for discovery
... proxy compatible with node-wot
... need to check protocol binding
... additional context - semantic linkage some features of
interest
... lwm2m style binding
... no ocf this time
... node-wot based ...
... proxy - it is a dedicated one, using mqtt, http
coap though node-wot
mjkoster: TLS and DTLS should be
there
... policy interface
... not modeling any accessibility
kaz: good detailed version
... do you think you can extract a compact version?
mjkoster: bulleted summary, yes
matthias: what to fill-in now?
kaz: suggest we start with the summary version
Oracle provides an Oracle IoT Cloud Service Product instance which includes a device simulator that we are using to simulate the Festo Plant, a connected car, a HVAC and a pump, support additional device
Festo simulator+integration developed together with Siemens with siemens
more complex model of a thing
simulator for heating, pump
if you want to simulate other devices, please discuss with Michael Lagally
darko: lots of device, asking to
upload all TDs
... prepare iotschema capabilities for them along with semantic queries
<Zakim> yamada, you wanted to say As for the demo planning, would anyone plan to demo in other than PlugFest (like in Open Day)? If yes, I'd like to demo in the morning due to the time
yamada-san: anyone planned to demo during openday?
matthias: depends ...
scribenick: kaz
matthias: would like to clarify OCF summer meeting schedule so that we can avoid conflicts for the next f2f meeting in Korea
mccool: need to see the schedule
kaz: clarification question about the usage of
preparation.md vs preparation-panasonic.md for Yamada-san
... summary on the demo scenario, objective, servient structure, steps on preparation.md because it's shared by Panasonic and Fujitsu?
yama: yes
kaz: what about preparation-panasonic.md?
matthias+koster: details to be written on preparation-panasonic.md
kaz: no plugfest call next wednesday on March 21st
... possibly one more TD/LD calls, though
darko: Koster, available on 16th?
koster: not available
[adjourned]