[voiceinteraction] minutes January 10, 2023

https://www.w3.org/2024/01/10-voiceinteraction-minutes.html

and below as text

   [1]W3C

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

                             - DRAFT -
                           Voice Interaction

10 January 2024

   [2]Agenda. [3]IRC log.

      [2] https://lists.w3.org/Archives/Public/public-voiceinteraction/2024Jan/
      [3] https://www.w3.org/2024/01/10-voiceinteraction-irc

Attendees

   Present
          debbie, dirk, gerard

   Regrets
          -

   Chair
          debbie

   Scribe
          ddahl

Contents

    1. [4]dirk's implementation

Meeting minutes

  dirk's implementation

   dirk: no client yet
   . ipa registry
   . ipa provider is chatGPT
   . using client input, sends text to dialog layer
   . the concepts are working
   . creates provider selection service

   implementation is C++

   dirk: only uses "multimodal input" parameter
   . this is a container of various multimodal inputs
   . returns client response
   . session id, request id, multimodal output
   . the ipa service must know about the provider selection
   service
   . provider selection service knows about the provider registry
   . provide registry is hard-coded, knows about providers
   . chatGPT is one provider
   . uses provider selection strategy, which hasn't been
   implemented yet, just uses the first one
   . eventually will need to use keyboard and display in client
   . need to add more logic about how to select IPA

   debbie: seems like picking the IPA is the job of the provider
   selection service
   . not the registry
   . location of chatGPT is part of the adapter, not the registry

   debbie: could use a similar pattern for Amazon Lex, for example

   dirk: provider selection strategy should know about supported
   modalities
   . could try to match input with output
   . adapter should mention what it supports
   . in terms of modalities
   . we never discussed error situations
   . for example, ChatGPT gave an error for incorrect credentials

   dirk: should return exceptions if the input is bad
   . rather than error codes
   . we need to decide this strategy soon
   . this is in the repository, where to put the documentation

   debbie: should be in the "source code folder

   dirk: what we've defined so far seems to be working

   debbie: next priority is provider selection service and
   registry need to be fleshed out
   . maybe the client isn't that critical

   dirk: would need that if we don't want to recompile every time

   dirk: need to check license of source code

   debbie: check to see if w3c has a preference
   . could use Apache 2.0 if the W3C doesn't have a preference

   dirk: then elaborate on provider selection strategy
   . decide on return values vs. exceptions

   debbie: providers should advertise what modalities they support

   dirk: this would be part of the provider selection strategy
   . highest priority is to document in the README
   . invite others to support

   dirk: still planning to look at dialog events

   debbie: should also look at conversation envelope spec, which
   will be published in the next few days

   dirk: didn't run into any major problems with implementation

   dirk: should create issues for next steps
   . any questions from gerard? security?

   gerard: implementation of small LLM's on smartphone
   . European project called "Evita", coaching older people
   . want to avoid cloud access

   dirk: would it make sense to add this as a wrapper around your
   project?

   gerard: not sure


    Minutes manually created (not a transcript), formatted by
    [5]scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).

      [5] https://w3c.github.io/scribe2/scribedoc.html

Received on Wednesday, 10 January 2024 18:10:23 UTC