[VIWI/Convergence] minutes - 23 January 2017

available at:
  https://www.w3.org/2017/01/23-auto-minutes.html

also as text below.

I've added the link to Patrick's slides in the minutes as well.

Thanks,

Kazuyuki

---
   [1]W3C

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

                               - DRAFT -

                    Automotive BG - VIWI/Convergence

23 Jan 2017

   See also: [2]IRC log

      [2] http://www.w3.org/2017/01/23-auto-irc

Attendees

   Present
          Kaz, Adam, Rudi, patrickB, Hira, patrickL, Kevin

   Regrets
          Ted

   Chair
          Rudi, PatrickL

   Scribe
          kaz

Contents

     * [3]Topics
         1. [4]Logistics
         2. [5]Use cases
     * [6]Summary of Action Items
     * [7]Summary of Resolutions
     __________________________________________________________

Logistics

   rudi: wondering which group this call is associated
   ... BG or WG?

   kaz: should be BG

   rudi: ok

   hira: might want to make this call a bit earlier
   ... it's 2am in Japan

   rudi: can see it
   ... unfortunately, we have various participation and it's
   difficult to find a perfect time
   ... let's do another doodle poll at some point

   patrickL: depending on the attendees who participate in the
   discussion
   ... getting knowledge about VIWI the key
   ... would be OK to have a second call which fits Asia better

   rudi: setting up another doodle is a good thing

   patrickL: about use cases
   ... more or less concrete example on protocols

   rudi: maybe we should talk about logistics a bit more?
   ... every week or every 2 weeks?
   ... will put the option as well into the doodle poll
   ... the last item is who would like to lead the discussion?
   ... BG Chairs?
   ... or somebody else?
   ... BG leads should agree with who to run the call

   patrickL: can lead the discussion for today

Use cases

   [8]PatrickB's slides

      [8]
https://lists.w3.org/Archives/Public/public-autowebplatform/2017Jan/att-0019/VehicleAPI_UseCases_20170123_PB.pdf

   patrickL: 5 categories for use cases

   (patrickB to present slides)

   patrickB: (Vehicle API Use Case analysis - a proposal)
   ... (Interesting Use Case for a Vehicle API 1/3)
   ... Vehicle information and configuration
   ... wheel speed, engine speed, battery status,...
   ... air conditioner, temperature, ventilation mode, seat
   position,...
   ... things we see in vehicle information
   ... setting configurations
   ... (Interesting Use Case for a Vehicle API 2/3)
   ... notifications
   ... broader scope than the WG work
   ... sending notifications from a WebApp or an external device
   ... and registration for notifications
   ... notifications are interactive
   ... if getting an email, there will be a button to "read email"
   ... there are different types of notifications
   ... also companion apps for media handling
   ... indirect access for pandra, etc.
   ... managing the player queue
   ... and LBS, Media Tuner
   ... (Interesting Use Case for a Vehicle API 3/3)
   ... LBS
   ... accessing vehicle location
   ... adding a POI to the map
   ... sending a destination
   ... tracking route progress
   ... companion apps would use the information
   ... Media Tuner
   ... browsing station lists
   ... tuning into a station
   ... scanning a band
   ... program guide

   kaz: some specific program guide mechanism like EPG for TV in
   you mind?

   patrickB: we can discuss what is expected
   ... and how could be adopted

   rudi: media tuner TF's work?

   kaz: Ryan Davis is working with the TV Control WG, which works
   on tuner API
   ... they're handling media tuning in general
   ... so we can share use cases for media handling with them

   rudi: asked since the Media Tuner TF wiki is not very active

   kaz: the main place of media tuner discussion is done within
   the TV Control side these days

   adam: how to extend VSS for media?

   rudi: think that would be possible
   ... current VSS has simple data types, though

   kevin: VSS can't handle complex data types at the moment

   rudi: yeah, but it should support complex data types as well

   patrickL: do you want to see it for VIWI as well?
   ... what's your opinion?
   ... comparing the VIWI data model and to VSS

   patrickB: can help you

   kaz: comparing the data model of VIWI to VSS would be useful

   rudi: would be helpful to have list of data types
   ... which query returns which data types, etc.

   patrickB: member submission already includes some information

   -> [9]https://www.w3.org/Submission/2016/01/ VIWI submissions

      [9] https://www.w3.org/Submission/2016/01/

   patrickB: we're defining services and objects
   ... VIWI doesn't support very complicated data types
   ... how to model it?
   ... complex or not complex within VSS
   ... streams for vehicle signals?
   ... request/response?
   ... I explained 5 areas of interest
   ... maybe we should start prioritizing them
   ... are there any opinions about that?

   rudi: vehicle information and configuration is what VSS started
   with
   ... good point to start with

   patrickL: good idea to use concrete use cases
   ... let's compare them during the next call

   patrickB: about vehicle information and configuration?

   patrickL: yes

   patrickB: quite interesting is notification from my viewpoint

   rudi: ok

   patrickB: opening APIs public for notification

   kaz: so we need to think about security and permission for that

   patrickB: yes
   ... and important for vehicle information in general :)
   ... access right
   ... and API management
   ... would become a big issue

   kevin: we focused on pure vehicle signals
   ... maybe there is an agent consuming the data
   ... websocket server itself could mention that
   ... in reality the client agent/service agent consuming the
   vehicle data
   ... we're just exposing data

   patrickB: VSS is for vehicle signals but not for media, etc.
   (currently)
   ... in that case, we need another instance for media
   ... for Android, etc., we could have a separate agent
   ... on the other hand, we could combine media handling
   capability with VSS

   kevin: interesting comparison, isn't it?

   adam: we had been working on high-level API spec
   ... but got feedback it would be better to have a low-level
   interface
   ... non-normative section on agent for the service spec

   patrickB: how shall I send the slides?

   kaz: sending the slides to the public list
   (public-autowebplatform@w3.org) would be great

   patrickB: so we'll discuss vehicle signal part during the next
   call. right?

   rudi: yes

   kevin: sounds good

   [ adjourned ]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [10]scribe.perl version
    1.148 ([11]CVS log)
    $Date: 2017/01/23 18:41:42 $

     [10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [11] http://dev.w3.org/cvsweb/2002/scribe/