Architecture Requirements for Intelligent Personal Assistants

Abstract

This document was prepared by reviewing version 1.3 of the Intelligent Personal Assistant Architecture Report and extracting requirements for the architecture that were implied by the report. This was done in order to have a standalone list of architecture requirements. The headings in this document correspond to the headings in the architecture report. Sections of the Architecture document which are not referenced here were not considered to contain any requirements. The terms "MUST", "MAY" and "SHOULD" are used in this document as defined in IETF RFC 2119.

Status of This Document

This specification was published by the Voice Interaction Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

1. Introduction

1. Intelligent Personal Assistants (IPA's) MUST be able to provide general purpose information
2. Specialized virtual assistants MUST be able to provide enterprise-specific information
3. Specialized virtual assistants MAY be able to provide non-enterprise-specific information
4. IPA's SHOULD be able to perform transactions
5. Specialized assistants MUST be able to interoperate with general IPA's
6. IPA's SHOULD be able to execute operations in a user's environment
7. IPA's MUST be able to interact with users through voice or text or both.

2. Problem Statement

8. IPA's MAY be able to transfer a partially completed task to another IPA

3. Architecture

9. IPA's MAY include a Client layer
10. IPA's MUST include a Dialog layer
11. IPA's MAY include an API/Data layer
12. Components MAY be shifted to other layers as needed
13. The architecture SHOULD support question answering and information retrieval applications
14. The architecture SHOULD support executing local services to accomplish tasks
15. The architecture SHOULD support executing remote services to accomplish tasks
16. The architecture MUST support dynamically adding local and remote services or knowledge sources.
17. It MAY be possible to forward requests from one IPA to another with the same architecture
18. It MAY be possible to forward requests or partial requests from one IPA to another with the same architecture, omitting the client layer
19. IPA extensions MAY be selected from a standardized marketplace

3.1 Client Layer

3.1.2 User Input and System Output

20. The Client layer MAY include a microphone
21. The Client layer MAY include a means for text input
22. The Client layer MAY include a speaker
23. The Client layer MAY include a display
24. Additional (non-speech) output modalities MAY be employed to render output or to capture input

3.1.3 IPA Client

25. The IPA Client MUST allow activation and deactivation by means of a Client Activation Strategy.
26. IPA Clients MAY also capture input via text and output text
27. IPA Clients MAY also capture input from various modality recognizers
28. IPA Clients MAY also capture contextual information, e.g., location, time, environmental sounds or other inputs that it obtains from Local Data Providers
29. An IPA Client MAY also receive commands to be executed locally in the Local Services.
30. An IPA Client MAY also receive multimodal output to be rendered by a respective modality synthesizer
31. IPA Clients MAY reference a session identifier.

3.2.2.1 Client Activation Strategy

32. The IPA Client MUST be activated with a Client Activation Strategy
33. The Client Activation Strategy MAY be push-to-talk
34. The Client Activation Strategy MAY be hotword
35. The Client Activation Strategy MAY be triggered by an interpreted text string (either from audio or text)
36. The Client Activation Strategy MAY be a change in environment
37. The Client Activation Strategy MAY be triggered by a script or environmental condition
38. The Client Activation Strategy MAY be a different strategy not enumerated here

3.2.2.2 Local Service Registry

39. The IPA Client MUST include a Local Service Registry
40. The Local Service Registry MUST maintain a list of Local Services
41. The Local Service Registry MUST maintain a list of Local Data Providers

Dialog Layer

3.2.1 IPA Service

42. The IPA Client MUST forward audio data and metadata (if any) to the ASR
43. The IPA Service MUST forward text data and metadata (if any) to the NLU
44. The IPA Service MUST forward audio output output from the TTS to the IPA Client if supported
45. The IPA Service MUST forward multimodal output from the Dialog Manager to the Client if supported
46. The IPA Service MUST forward text output from the NLG to the IPA Client if supported

3.2.2 ASR

47. The ASR MUST generate one or more recognition hypotheses from voice input that it receives from the IPA Service
48. The ASR MAY associate recognition hypotheses with confidence scores
49. The ASR MUST forward the recognition hypotheses to the NLU
50. The ASR MAY update the History with the recognition hypotheses

3.2.3 NLU

51. The NLU MUST extract textual interpretations from text strings (either from audio or text)
52. The NLU MAY extract multiple interpretations from input text strings (either from audio or text)
53. The NLU MUST be able to interpret input Core Intent Sets
54. The NLU SHOULD be able to interpret utterances that are a combination of activation strategies and commands.
55. The NLU make make use of the Data Provider to access local or external data
56. The NLU MAY make use of the Context to check for complementary information such as information in the history or knowledge
57. The NLU MUST forward the semantic interpretation of the input to the Dialog Manager
58. The NLU MAY associate statistical confidences with interpretations
59. The NLU MAY extract emotion or sentiment from text strings either from audio or text)

3.2.4 Dialog Manager

60. The Dialog Manager MUST recognize when the user goals are changed
61. The Dialog Manager SHOULD confirm when the user goals are changed
62. The Dialog Manager MAY consider ongoing workflows that must not be interrupted when the user switches goals.
63. The Dialog Manager SHOULD update the History with dialog moves
64. The Dialog Manager SHOULD determine the next dialog move
1. based on internal considerations
2. based on output from other components in the same dialog system
3. based on output from other agents (IPA services)
4. how the Dialog Manager determines the next move is outside the scope of these requirements
5. The Dialog Manager SHOULD make use of the TTS to generate audio data to be rendered on the IPA Client
6. The Dialog Manager MAY provide commands to be executed by the IPA Client or the External Services

3.2.5 Context

65. The Context MAY make use of the Local Service Registry to include external knowledge from Local Data Providers
66. The Context MAY make use of the External Service Registry to include external knowledge from Data Providers
67. The Context MAY provide external knowledge temporarily to the Knowledge Graph to be considered in reasoning

3.2.5.1 History

68. The Dialog History MAY store the past dialog events per user

3.3 API's/Data Layer

69. The Provider Selection Service MAY receive input from the Dialog Manager to query data from Data Providers
70. The Provider Selection Service MAY receive input from the Dialog Manager to execute External Services
71. If the Provider Selection Service is called by the Dialog Manager with a preselected identifier of an IPA provider, it MUST use the preselected provider
72. If the Provider Selection Service is not called with a preselected identifier of an IPA provider, the Provider Selection Service MUST follow a Provider Selection Strategy to determine those IPA Providers that are best suited to answer the request