[voiceinteraction] minutes October 19, 2022

I just realized I hadn't sent out the minutes from our October 19 call. Here they are.

https://www.w3.org/2022/10/19-voiceinteraction-minutes.html
and below as text.


   [1]W3C

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

                             - DRAFT -
                           Voice Interaction

19 October 2022

   [2]Agenda. [3]IRC log.

      [2] https://lists.w3.org/Archives/Public/public-voiceinteraction/2022Oct/0004.html
      [3] https://www.w3.org/2022/10/19-voiceinteraction-irc

Attendees

   Present
          debbie, dirk, jim, noreen

   Regrets
          -

   Chair
          debbie

   Scribe
          ddahl, debbie

Contents

    1. [4]implied requirements

Meeting minutes

   dirk: need to move the emergency use case to version 1.3

   noreen: will make a new pull request for the same changes in
   1.3

  implied requirements

   section 1

   Specialized assistants MUST be able to interoperate with
   general IPA's
   . we all agree

   dirk: IPA's SHOULD be able to execute operations in a user's
   environment

   noreen: the environment that the user controls regardless of
   the location
   . IPA's SHOULD be able to execute operations

   jim: IPA's should be about to execute user-requested operations
   . we agree

   dirk: IPA's MAY be able to interact with users through other
   modalities.

   2.1.1 IPA's MUST be able to transfer a partially completed task
   to another IPA

   IPA's MUST be able to transfer a task to another IPA, including
   incomplete tasks

   IPA's MUST be able to transfer a task to another IPA, including
   tasks that MAY be partially completed

   jim: some database tasks can't be partially completed, all or
   none

   noreen: a task could be a series of transactions

   we agree

   dirk: The architecture SHOULD support question answering

   dirk: The architecture SHOULD support information retrieval
   requirements

   dirk: need to number the requirements
   . then we can refer to them in other sections

   debbie: cross-reference The architecture SHOULD support
   executing local services to accomplish tasks The architecture
   SHOULD support executing remote services to accomplish tasks

   The architecture MUST support dynamically adding local and
   remote services or knowledge sources.

   jim: also dynamically remove

   dirk: for example, adding devices in a smart home

   noreen: that could be a task that needs to be completed by more
   than one IPA

   jim: if we move a lamp to another room, do we need to remove it
   and add it

   dirk: this is more about context

   noreen: when you move the lamp its attributes can change (like
   location)

   jim: just "add or remove"

   debbie: we should multiply out all the options

   It MUST be possible to forward requests from one IPA to another
   with the same architecture
   . this is similar to the partially completed tasks

   noreen: the topic level heading of section 2?

   dirk: problem statement and use cases

   It MUST be possible to forward requests from one IPA to another
   with the same architecture, omitting the client layer

   debbie: that rules out smart speakers

   dirk: this means one IPA becomes the client for another IPA
   . in the case of cars, the client can forward requests to
   Amazon, etc.

   noreen: It MUST be possible to forward requests from one IPA to
   another using the standard architecture

   (we just finished the 5th item in the architecture section)

   dirk: still working on changes to interfaces document, also
   trying to add some sample requests using JSON notation
   . there's one example in Github
   . we can talk about that next time

   debbie: will create a new requirements document

   dirk: reverted changes to 1.2 and noreen put in a new pull
   request for 1.3

Received on Tuesday, 1 November 2022 13:49:13 UTC