W3C home > Mailing lists > Public > public-wot-wg@w3.org > October 2017

[PlugFest] minutes - 4 October 2017

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Thu, 5 Oct 2017 18:14:30 +0900
Message-ID: <CAJ8iq9WO+OMHAVTG0uKNEU4WL7CHayWLG4--Y7voU3x73V8g1w@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at:
  https://www.w3.org/2017/10/04-wot-pf-minutes.html

also as text below.

Thanks,

Kazuyuki

---

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                              WoT PlugFest

04 Oct 2017

   [2]Agenda

      [2] https://www.w3.org/WoT/IG/wiki/PlugFest_WebConf#Agenda

   See also: [3]IRC log

      [3] http://www.w3.org/2017/10/04-wot-pf-irc

Attendees

   Present
          Kaz_Ashimura, Ryuichi_Matsukura, Takeshi_Yamada,
          Zoltan_Kis, Tomoaki_Mizushima, Daniel_Peintner,
          Soumya_Kanti_Datta, Uday_Davuluru, Michael_McCool,
          Sebastian_Kaebisch, Michael_Koster, Kazuaki_Nimura,
          Masato_Ohura

   Regrets
   Chair
          Kaz

   Scribe
          kaz_

Contents

     * [4]Topics
         1. [5]TPAC/PlugFest registration
         2. [6]PlugFest proposal update
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   <scribe> scribenick: kaz_

TPAC/PlugFest registration

   Registration site (for TPAC/PlugFest attendees):
   * [9]https://www.w3.org/2002/09/wbs/1/WoTPlugFest201711/
    https://www.w3.org/2002/09/wbs/1/WoTPlugFest201711/

   * [10]https://www.w3.org/2002/09/wbs/35125/TPAC2017/

     [10] https://www.w3.org/2002/09/wbs/35125/TPAC2017/

PlugFest proposal update

   [11]Matsukura-san's slides

     [11] https://lists.w3.org/Archives/Public/public-wot-ig/2017Oct/att-0005/Servients_TPAC2017_171004d.pptx

   matsu: updated the slide based on the information on the f2f
   wiki
   ... you can see there are 5 colors
   ... application servient, remote proxy servient, local proxy
   servient, device servient and devices
   ... the left most row is Panasonic
   ... the second row is Siemens
   ... then Lemonbeat, Intel, SmartThing, Eurecom
   ... will get concrete information on Eurecom from Soumya

   soumya: next week

   matsu: the right most row is Fujitsu
   ... Nimura and myself
   ... also Mizushima-san from IRI will provide an application
   servient

   mccool: sorry have not put info on the wiki yet
   ... would provide various devices
   ... not device servient itself but device servient generator

   matsu: application as well?

   mccool: yes
   ... using Alexa
   ... web service is visible globally
   ... bridge between Alexa and WoT devices

   uday: allocate devices dynamically?

   mccool: want to talk to whatever Things dynamically
   ... and generate voice interface for them
   ... turn on/off
   ... would see semantic tagging
   ... the idea is more generic one
   ... likewise OCF Thing

   uday: Alexa already knows about the devices?

   mccool: no, dynamically asks about that

   kaz: it seems there is a list of issues on p3

   mccool: yeah
   ... would like to demonstrate semantic interoperability
   ... proxy things could be useful but not unique
   ... there could be more dynamic mechanism
   ... also think we need some directory service somewhere

   matsu: tx for your comments
   ... would be useful to have those points on the wiki
   ... and discuss it in detail later

   mccool: ok

   (Michal_Koster joins)

   matsu: Koster, do you have any update on your side?
   ... device servient, etc.

   kaz: expectation for your devices and servients?

   koster: Smart Thing devices
   ... exposed as a "device"

   mccool: as an OCF device?

   koster: yeah
   ... light and motion sensor
   ... will show the information on the f2f wiki

   matsu: ok
   ... maybe Matthias could provide a remote proxy as well
   ... Daniel and Sebastian, do you know if Siemens can provide
   app servient and proxy servient?

   dape: finish by beginning of Nov but not completed

   sebastian: working on that
   ... some slide maybe in 2 weeks
   ... about how it works
   ... btw, "TD repository" is missing here
   ... to find all the accessible Things

   mccool: yeah, how to discover Things/services
   ... web services are visible and accessible, though

   matsu: TD repository is one of the important issues
   ... would like to talk about that in detail later

   dape: not only who but one in the local side and another in the
   Internet side

   kaz: why don't you explain the 2nd slide, Matsukura-san?

   matsu: (go ahead to the 2nd slide)
   ... devices on some locations
   ... applications can be located in the Internet side

   mccool: one assumption here is all the applications work on the
   Internet side
   ... on the other hand there can be apps on the local side like
   fog apps
   ... also NATs accept all the global addresses?

   koster: accepts all the incoming addresses. right?

   mccool: we can reach between different networks
   ... there are 3 different networks here

   koster: 2 different networks via a remote proxy

   mccool: right

   matsu: this slide shows the combination of possible servients
   ... we want to get information for the PlugFest
   ... e.g., what kind of devices will be used
   ... and application scenario

   kaz: and the interface between servients

   matsu: yes
   ... (p3: Issues for TPAC plugfest)
   ... issues
   ... 1. interface between servients
   ... need to think authentication, discovery/TD exchange,
   firewall/NAT, Event operation
   ... 2. TD management
   ... need to think about how to create the URI

   mccool: we should try discovery API
   ... e.g., the one of node-wot
   ... should be set up to look up local TD directory
   ... and need to set up TD directory
   ... other people use something other than node-wot
   ... in that case, how to handle discovery?
   ... where is "it"?

   koster: one common directory to discover TD?

   mccool: Fujitsu may have their own implementation for discovery
   ... local proxy could delegate discovery capability to remote
   proxy

   koster: we've not clarify how to handle that yet
   ... the basic case is having everything within home

   mccool: the basic case could be having one global cashing
   directory
   ... would be happy to have one single point for now

   kaz: confirm everybody happy and provide servients
   ... and file issues

   mccool: wot repo?

   kaz: that's fine

   mccool: we have 2 local proxies for the local network in SF

   matsu: and each of the two remote servients correspond to one
   of them
   ... we should clarify the way how to register Things

   mccool: idea here to create a generic proxy service?

   matsu: right

   mccool: we need to document the interface for that purpose
   ... discover and identify the devices

   koster: proxies have both the capabilities of expose/consume

   mccool: need to define TD for the local proxy servient
   ... how to search devices within the local network from the
   outside?
   ... discovery the Things dynamically or any provisioning?

   koster: we have multiple problems
   ... we have local proxy and remote proxy
   ... what is exposed for the north-bound?

   mccool: OCF device talks with CoAP

   koster: the assumption here is
   ... possibly have multiple protocols, CoAP, MQTT, etc.
   ... or simply HTTP

   mccool: I'm creating a bridge
   ... could create a proxy as well
   ... this diagram is misleading
   ... OCF device doesn't know the local proxy servient
   ... on the other hand, the local proxy servient need to talk
   with the device servient

   kaz: we should clarify that the green box "device servient" is
   just a device which handles the specific devices

   mccool: yes, for my side, the blue box itself is a servient

   kaz: I guess the point here with the blue box is describe the
   pattern of Panasonic's system

   mccool: yeah
   ... both patterns make sense
   ... device servient+device vs servient device(which includes
   both device servient and device at once)

   koster: in that case, some of the blue boxes can be directory
   connected to the yellow box (=local proxy servient)

   kaz: so we should rather start with green boxes which expose
   device capability

   mccool: right

   matsu: ok
   ... would suggest you also generate diagrams of your systems
   and descriptions :)

   mccool: where to store the resources?

   kaz: how about wot repo
   ... under plugfest sub directory?

   <McCool>
   [12]https://www.w3.org/WoT/IG/wiki/F2F_meeting,_4-10_November_2
   017,_Burlingame,_CA,_USA

     [12] https://www.w3.org/WoT/IG/wiki/F2F_meeting,_4-10_November_2017,_Burlingame,_CA,_USA

   mccool: visit the above f2f wiki
   ... point the wot repo
   ... and diagrams, etc.

   <McCool> issue prefix "PlugFest4Q17"

   mccool: and issues should have prefix like "PlugFest4Q17"

   kaz: and we can create a label "PlugFest4Q17" as well

   mccool: right

   <McCool> and please document that in a section of the wiki page
   above...

   kaz: at some point we could think about MD and HTML on the
   wot/plugfest repo as well
   ... btw, the minutes to be published publicly?

   all: fine

   [adjourned]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [13]scribe.perl version
    1.147 ([14]CVS log)
    $Date: 2017/10/05 09:09:17 $

     [13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [14] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 5 October 2017 09:15:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 09:15:38 UTC