Re: [voiceinteraction] minutes for the October 2, 2019 call

Sorry my schedule is a little volatile, but the architecture document makes
sense.  The one thing we could add later, a little detailed at this point,
is a shared authentication mechanism.  Healthcare APIs and Apps use SMART
on FHIR, which is basically OAuth2/OpenID Connect.  If we enforce a
standard authentication mechanism we can streamline the authentication and
perhaps automate it when the provider "registers" their IVA.  During
registration, they can give the OpenID well known metadata information and
we can hook the central registration system to theirs.  Hope to make the
next meeting, and thank you Debbie for the detailed minutes.

Standardization can happen a few places as I see it.  We can standardize
the API layer (yes, between Red and Blue), the Dialog/Intent sets and the
Provider registration.

API Layer/Provider Registration:
For an IPA provider to be registered and searchable, it would have to meet
certain standards and accept a list of network calls with known payloads
with known responses.  The basics like the semantics being sent via the
voice interaction, and also a metadata endpoint to describe itself.  I
also, from previous comments, think a standard authentication mechanism
should be part of the registration or approval of the Provider.

Dialog/Intent:
A set of well-known intents could be a standard that would be very
helpful.  Once again looking at healthcare we have ICD-10, SNOMED, LOINC
coding systems that aggregate like-terms into a standard naming system.
"Airline Registration", "Flight Information", etc. can be coded to a
certain nomenclature with a code and a readable term (such as "Flight
Plans") so when looking for an IPA Provider we can map the intention with a
well-known set of mappings.




On Wed, Oct 2, 2019 at 11:12 AM Deborah Dahl <
Dahl@conversational-technologies.com> wrote:

> Present: Debbie, Dirk
>
> Chair: Dirk
>
> Scribe: Debbie
>
> Regrets: Brian
>
> Dirk: try to find a new time
>
> Dirk: start with Phil Archer message
>
>
> https://lists.w3.org/Archives/Public/public-voiceinteraction/2019Sep/0007.html
>
> Dirk: 4 points, 1. updates to SSML
>
> Debbie: there's a lot interest, but not a priority for us right now
>
> Dirk: 2. defining additional hooks for Web pages to aid voice-driven
> navigation
>
> Debbie: probably not a priority either
>
> Dirk: 3. "The voice assistant platforms include a lot of proprietary
> technologies that are very unlikely to be standardised"
>
> ...we should find a way to find somethings to standardize
>
> Debbie: usually don't standarize technologies, mostly API's
>
> ... 4. good agreement around the room that a W3C workshop would be well
> worth exploring.
>
> Dirk: that would be a good idea
>
> Debbie: yes
>
> Debbie: big players don't always have to be on board, sometimes even a
> single person can get something going
>
> Debbie: W3C workshops are organized by the W3C, have a program committee,
> meet, produce a report
>
> ... also some discussions at SpeechTEK
>
> Dirk: talk about the use case
>
>
> https://lists.w3.org/Archives/Public/public-voiceinteraction/2019Sep/0005.html
>
> Debbie: (reviews use case of travel planning)
>
> Dirk: authentication could be something for the future
>
> Debbie: add use case to next version
>
> Dirk: can you create template and add use case?
>
> ...in the github repository (
> https://github.com/w3c/voiceinteraction/tree/master/voice%20interaction%20drafts
>
> )
>
> ...new document "Intelligent personal assistant architecture"
>
> Debbie: there should be an overview
>
> ...boxes would be connected by API's
>
> Debbie: what to standardize?
>
> ...format of dialog registry
>
> ...interface between the red parts and the blue parts
>
> ...what contacts the Provider Selection Service?
>
> Dirk: possibly the dialogs themselves
>
> Dirk: information needed is utterance string, url
>
> Debbie: maybe separate "core provider" into its own box
>
> Debbie: revise use case to be independent of the architecture
>
> Dirk: add explanation of how the use case is reflected in the
> architecture, in addition to the pure use case
>
> Dirk: how to gain more momentum? Ask group when they could attend a call
>
> Debbie: having a document will give people something to react to
>