- From: Brian Susko <brian.susko@gmail.com>
- Date: Tue, 8 Oct 2019 09:38:46 -0400
- To: Deborah Dahl <Dahl@conversational-technologies.com>
- Cc: public-voiceinteraction@w3.org
- Message-ID: <CAJQM+00m+1Df7wov8FQUPNsRbJ7FSJYz9f0g0oyLReUz=tC3Sg@mail.gmail.com>
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 >
Received on Tuesday, 8 October 2019 13:39:21 UTC