an Ontology-Based Dialogue Management System (DMS) for Virtual Personal Assistants

Please download to get full document.

View again

of 12
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report
Category:

Health & Fitness

Published:

Views: 0 | Pages: 12

Extension: PDF | Download: 0

Share
Related documents
Description
An Ontology-Based Dialogue Management System for Virtual Personal Assistants Michael Wessel, Girish Acharya, James Carpenter, and Min Yin Abstract Dialogue management (DM) is a difficult problem. We present
Transcript
An Ontology-Based Dialogue Management System for Virtual Personal Assistants Michael Wessel, Girish Acharya, James Carpenter, and Min Yin Abstract Dialogue management (DM) is a difficult problem. We present OntoVPA, an Ontology-Based Dialogue Management System (DMS) for Virtual Personal Assistants (VPA s). The features of OntoVPA are offered as potential solutions to core DM problems. We illustrate OntoVPA s solutions to these problems by means of a running VPA example domain. To the best of our knowledge, OntoVPA is the first commercially available, fully implemented DMS that employs ontologies, reasoning, and ontology-based rules for a) domain model representation and reasoning, b) dialogue representation and state tracking, and c) response generation. OntoVPA is a declarative, knowledge-based system which, consequently, can be customized to a new VPA domain by swapping in and out ontologies and rule bases, with very little to no conventional programming required. OntoVPA relies on its domainindependent (generic), but dialogue-specific upper-level ontologies and DM rules, which are implementing typical, re-occurring (and usually expensive to address) dialogue system core capabilities, such as anaphora (coreference) resolution, slotfilling, inquiring about missing slot values, and so on. We argue that ontologies and ontology-based rules provide a flexible and expressive framework for realizing DMS s for VPA s, with a potential to significantly reduce development time. 1 Introduction, Motivation, and Related Work Motivation for OntoVPA Dialogue management (DM), the core functionality of a Dialogue Management System (DMS), is notoriously difficult, if not AI-complete; see [20] for a recent overview. Even in more restricted dialogue systems, difficult problems such as anaphora (coreference) resolution and dialogue state tracking may have to be handled by a non-trivial DMS. The importance and difficulty of the dialogue state tracking problem is also testified by the recently established series of Dialog State Tracking Challenges [19], aimed at catalyzing progress in this area. To the best of our knowledge, state tracking and DM are still in its infancy in contemporary commercial VPA frameworks / platforms, with very little to no support offered by the frameworks. Commercial platforms usually offer some form of Corresponding author: Michael Wessel SRI International, 333 Ravenswood Avenue, Menlo Park, CA 94025, USA, 1 2 Michael Wessel, Girish Acharya, James Carpenter, and Min Yin current user intent-triggered action-reaction ( production) rules (e.g., in order to invoke a RESTful service in the Internet of Things). However, these rules are usually constrained to accessing the parameters ( slot values) of the current user intent only, and hence cannot access (nor assess) the dialogue history or state of a rich domain model their context is often limited to current intent and previous state. In contrast, our ontology-based DMS has access to the full dialogue history and domain model. Consequently, in these simpler commercial systems, the bookkeeping required in order to support more sophisticated DM has to be done programmatically by the VPA application developer, and dialogue history and state have to be encoded in proprietary data structures, with little to no reuse across domains. This model-less, programmatic approach to DM is acceptable for simple one-shot request-response VPA s that do not need to sustain complex conversations (possibly involving multiple dialogue steps) for fulfilling a user request, but becomes tedious with increased development times and hence costs in the long run in more complex VPA domains that require elaborate workflows for solving domain-specific problems (e.g., booking a business trip includes booking a flight, a hotel, a rental car, and so on). A system with deep domain knowledge which is capable to solve complex problems in cooperation with the user, such as Kasisto [9], is also called a Virtual Personal Specialist (VPS) [12]. Due to the complexity of the domain problems to be solved (e.g., bank transfers), dialogues will require multiple steps for workflow / intent completion, and both the user and the VPA should be able to steer and drive the dialogue in order to solve the problem cooperatively. Such systems will likely be mixed initiative dialogue systems [6], and frame-based, information state-based and agent-based DMS are a better fit than the less flexible finite state machine-based DMS. The challenges presented by conversational VPS s have shaped OntoVPA, our ontology-based DMS for VPA s. Introducing OntoVPA OntoVPA is offered as a generic, reusable VPA platform for implementing conversational VPA s and VPS s that require deep domain knowledge, complex workflows, and flexible (not hard-coded) DM strategies. It promises to significantly reduce development times, due to its reusable and generic features (see Section 2). OntoVPA employs ontologies for dialogue and domain representation, as well as ontology-based rules for dialogue management, state tracking, and response computation. OntoVPA s dialogue representation can be compared to the blackboard in information state space-based DMS s [20]. Ontology-Based Domain Model and Dialogue Representation For illustration, let us consider a Restaurant Recommendation VPA (see Section 2) that has suggested a specific restaurant of type ItalianPizzaRestaurant to the user in response to a FindRestaurantIntent(type : Restaurant). In subsequent dialogue steps, the user might refer to this previously discussed Restaurant with a phrase such as... the pizza place... or... the Italian restaurant... (e.g., What is the rating of the pizza place? ). OntoVPA uses its domain knowledge to realize that the previously presented ItalianPizzaRestaurant is an ItalianRestaurant as well as a PizzaPlace An Ontology-Based Dialogue Management System for Virtual Personal Assistants 3 consequently, these anaphora can be resolved with the help of a generic anaphora resolution rule. The rule considers the taxonomy of the ontology and is hence aware of hypernyms, hyponyms, and synonyms [7]. Such a system obviously requires some form of dialog representation in order to have a working memory of the dialogue, and it needs to be reflexive in addition to what the user said, it also needs to remember its own utterances; here, the presented restaurant. The runtime, dynamic dialogue representation is instantiating the classes and relation types defined in the static dialogue ontology; this vocabulary is inspired by speech act theory [14]. Ontology-based rules over these representations implement the dynamics of the dialog. Use of Ontologies in OntoVPA We are using the W3C standards OWL 2 for the ontology language, and have implemented a custom ontology-based rule engine based on the SPARQL 1.1 RDF query language. Mature implementations for OWL 2 and SPARQL exists [16], and modeling workbenches (Protégé 5) are available. The use of standards facilitates customer acceptance, and off the shelf ontologies are only readily available in standard formats. Ontologies facilitate the following: Domain Model Representation: The classes (types), relationship types, and instances and relations of the VPA domain. Often, we wish to reuse, extend, and specialize well-known upper level ontologies such as Schema.org [18]. Following standard OWL 2 Description Logic (DL) terminology [17], the classes ( concepts, types,... ) and object and datatype properties ( properties, slots, attributes, relations, parameters,... ) constitute the TBox (terminological box) of the ontology, representing the vocabulary of the domain, whereas the actual instances of these classes and relationships between them are kept in the ABox (assertional box). Dialogue Ontology: A TBox its classes and properties are speech act theoryinspired [14]. This vocabulary is instantiated in the dialogue ABox, which is the actual dialogue representation. The TBox contains dialogue step classes, such as UserIntents, which are special UserRequests, which are special DialogUserSteps, and so on, see Section 3. As the domain classes, many dialogue steps have parameters (slots), which are defined in terms of object and datatype properties. Ontology reasoning is applicable in a number of areas and offers great potentials: Domain-Specific Reasoning: A VPA with deep expertise in a domain (a VPS) requires extensive domain knowledge, and workflows and reasoning procedures are becoming more complex. Automatic reasoning and highly expressive ontologybased rule languages can solve complex application problems in a declarative way. Reasoning to Compute VPA s Responses: Ontology-based rules can be used to compute the actual utterances of the VPA. Reasoning to Handle Polysemy & Ambiguity of Natural Language and Dialogue: Ontologies provide a means to deal with the polysemy of natural language (NL). An ontology can structure the domain-specific vocabulary ( lexicon ) in terms of semantic relations between them, such as hypernym / hyponym, syn- 4 Michael Wessel, Girish Acharya, James Carpenter, and Min Yin Fig. 1 OntoVPA s processing pipeline. Automatic Speech Recognition (ASR) turn the audio signal into text. The text is then classified as a subclass of the DialogueUserStep ontology class, i.e., a specific UserIntent such as FindPointIntent. The ontology also specifies parameters / slots for classes, and the slot filler fills in their parameters from a parse tree. The instantiated intent class (the logical form) refers to individuals, classes, and relations from the ontology. The classifier and slot filler act as a semantic parser. The instantiated intent is asserted into the dialogue ABox, and the rule engine is invoked to compute OntoVPA s response. The ontology is used by the classifier, slot-filler and rule engine. Only the rule engine uses the ontology-based SPARQL rules. onym / antonyms, and so on. This knowledge can be exploited for a variety of context-specific NL interpretation and understanding tasks [7]. Basic Architecture of OntoVPA SRI s standard VPA processing pipeline is shown and explained in Fig. 1, also compare [6]. The focus of this paper is on the OntoVPA module. We will briefly discuss the role of the classifier and slot filler, too. Related Work Since the days of the LUNAR system, ontologies have been used successfully in NL Question Answering systems, recently in HALO/AURA [10]. One of the few dialogue systems that uses ontologies at runtime for response generation is [1], but neither standard reasoning nor ontology-based queries / rules are used. Dynamic use of ontologies is considered in [2] and led to the OntoChef system [15], which is equipped with a sophisticated cooking ontology, but uses a nonontology based DMS (Olympus/RavenClaw). Other case studies have focused on ontology modeling [11] and dialogue design based on task structures in OWL [3]. Frequently, ontologies are used for domain models. OWLSpeak [4, 5] is similar to our dialogue ontology in that it is capable to represent (speech act influenced) dialogue models as well as the state of the dialogue, but no ontology-based rules nor queries are used to compute the system s responses (it generates Voice-XML). A sophisticated Semantic Dialogue System for Radiologists is presented in [8], and it also relies on ontologies and SPARQL, but does not use these techniques for the implementation of the DM shell. Outline of the Paper First, we illustrate OntoVPA and its DM core capabilities in a Point Of Interest (POI) Finder VPA domain by means of a typical dialogue. We then discuss the ontology in more detail, before we elaborate on how OntoVPA s DMS uses ontologies and ontology-based rules for realizing these core capabilities. We finish with a conclusion and outlook for future work. An Ontology-Based Dialogue Management System for Virtual Personal Assistants 5 No. User Utterance (DialogueUserStep) OntoVPA Response (DialogueSystemStep) 1 (none, OntoVPA initiates the dialogue by greeting the Hello, how can I help? user upon sign in) 2 Is there a Chinese Restaurant in Menlo Park? Sorry, I can t find any. Do you want me to find something similar? 3 Okay! I found Gombei Japanese Restaurant in Menlo Park, at 0.34 miles. 4 Can you show it on the map? I am assuming with it you are referring to Gombei Japanese Restaurant. Now showing it on the map. 5 Is there a library close to the asian restaurant? Yes, the Menlo Park library is close to Gombei Japanese Restaurant, at 0.3 miles. 6 How about a Pizzeria in Menlo Park? I found Applewood Pizzeria in Menlo Park, at 0.2 miles. 7 In Palo Alto I found Olive Garden in Palo Alto, at 1.4 miles. 8 Is there parking close to the pizza place? Do you mean Olive Garden? 9 No Apple Wood Pizzeria has a parking lot. Fig. 2 An Example Dialogue with the OntoVPA-based Point Of Interest Finder VPA 2 Ontology-Based Dialogue Management Illustrated Dialogue Management Core Capabilities What are the core capabilities required for conversational VPA s (also see [21, 7, 6])? In our experience, in addition to anaphora (coreference) resolution as already discussed, conversational VPA s typically require the following: realizing when a user request (also: intent) is fully specified and ready for execution (i.e., all required parameters are fully specified); inquiring about missing required parameters; interpreting arbitrary user input in the context of the current dialogue (what does In Palo Alto? mean in the current context?); canceling a currently open, but not yet fully executed sub-dialogue or subworkflow; support for refining, generalizing, deleting or overwriting slot values of previously executed requests (intents), and re-executing them; and recognizing and disambiguating ambiguous input (does Stanford refer to the city, or the college?). We will now illustrate some of these core capabilities by means of the example dialogue from Fig. 2 with a Point of Interest Finder VPA, and discuss how these are handled on a generic level in OntoVPA, cross-domain and once and for all. After an initial greeting from the system in Step 1, the user initiates the dialogue in Step 2 by asking for a Chinese Restaurant in Menlo Park. The domain ontology contains a taxonomy of POI classes, such as ChineseRestaurant, which is a subclass (= kind) of AsianRestaurant, which is a kind of Restaurant, which is a kind of POI, and so on. In addition, there are classes such as City. The system also has a domain data source, which is an OWL (RDF) ABox of instances of POI classes (POI database for short). These POI s have their typical attributes (properties), i.e., name, address, geographic coordinates, and so on. Cities, such as MenloPark, are instances as well; a POI instance refers to the city in which it is located via the incity object property (slot). In Step 2 of Fig. 2, the user s request can be classified as a FindPOIIntent, a subclass of UserIntent. DialogUserStep classes are defined in the dialogue ontology; the dialogue ontology defines the vocabulary for the dialogue ABox, see Fig. 3. The user s utterances (often, instances of UserRequest or UserIntent) are normally created by the semantic parser, whereas OntoVPA s utterances (usually SystemResponses) are created by OntoVPA s ontology-based rule engine. OntoVPA 6 Michael Wessel, Girish Acharya, James Carpenter, and Min Yin keeps track of the current dialogue user step and current dialogue system step by annotating the corresponding instances in the dialogue ABox with so-called control marker classes, i.e. CurrentDialogUserStep and CurrentDialogSystemStep. The FindPOIIntent is asserted into the dialogue ABox by the semantic parser, along with an instance of a ChineseRestaurant as filler for its dialogueentity slot (object property). In addition, the parser realizes that Menlo Park is a name for the MenloPark City individual from the POI ABox, and fills it in for the incity slot of the freshly created ChineseRestaurant instance, given that the range of the incity property is City, and MenloPark is an instance of City. The freshly constructed ChineseRestaurant POI instance can be considered as a query-by-example POI for the FindPOIIntent query. We will discuss in Section 4 how a generic, query-byexample semantic search can be implemented with ontology-based rules. OntoVPA now realizes that the FindPOIIntent is completely specified (i.e., all required parameters are specified), and hence is ready for execution the semantic search over the POI database is performed. In this example, OntoVPA does not find a matching ChineseRestaurants in MenloPark, and it takes the initiative by pro-actively asking the user whether the query should be generalized. Now, a YesOrNoAnswer is expected from the user. For both possible answers, OntoVPA has set up positive and negative continuation requests; the negative continuation is a GreetingIntent, whereas the positive continuation is a FindPOIGeneralizedIntent. The parameters required for the latter intent are copied over from the previous FindPOIIntent. Hence, depending on whether a YesUserResponse or NoUserRes ponse is received, the corresponding continuation is triggered automatically by OntoVPA. In Step 3, the FindPOIGeneralizedIntent intent is triggered based on the user s Okay! response, which is classified as a YesUserResponse. For the FindPOIGeneralizedIntent, a relaxed semantic matching condition is implemented, where the structure of the taxonomy is exploited to compute a semantic similarity measure between the query-by-example POI, and the actual candidate source POI. A JapaneseRestaurant is more similar to a ChineseRestaurant than a SteakHouse, given that the former two have a common direct superclass AsianRestaurant, whereas ChineseRestaurant and SteakHouse do not. In Step 4, Can you show it on the map?, OntoVPA realizes that it refers to the most recently discussed POI. Like the already discussed FindPOIIntent, the MapPOIIntent has a dialogueentity slot of range POI. The parser has created a blank POI instance that also instantiates the ItDeterminerMixin class in OWL, individuals can instantiate multiple classes. The ItDeterminerMixin anaphora resolution rule now identifies the most recently discussed instance from the dialogue ABox that satisfies the given types, here: POI, and the most recent POI instance slot filler of any UserIntent or SystemResponse is identified as referent for it. Hence, the sourceentity filler of the previous FindGeneralizedPOISystemResponse in the dialogue ABox is identified as the referent of the it anaphora. OntoVPA contains anaphora resolution rules for it, the, a, his, her, and so on. Anaphora resolution involving the TheDeterminerMixin is illustrated in Step 5 (... the asian restaurant ). Realizing that the presented JapaneseRestaurant is also an instance of AsianRestaurant (a superclass), the anaphora can be resolved. An Ontology-Based Dialogue Management System for Virtual Personal Assistants 7 Fig. 3 Illustration of the Dialogue ABox. UserDialogueSteps are below the line, and SystemDialogueSteps above. The dialogue ABox after Step 4 is shown. Grey circles visualize OntoVPA s dialogue steps, mostly instances of response classes. Blue circles visualize user utterances, instances of UserDialogueStep. Blue shapes are created by the semantic parser; blue rectangles are instances of domain classes (e.g., ChineseRestaurant). Yellow triangle visualize ontology individuals from some data source (MenloPark). White circles are created programmatically via follow up request processing rules, and by the dialogue rule engine. In order to demonstrate disambiguation, we are adding some more dialogue objects to the discourse, by requesting a Pizzeria in MenloPark in Step 6. In Step 7 it is demonstrated how arbitrary input can be interpreted in the current context of the dialogue based on the dialogue history, OntoVPA understands that the most likely user intent behi
Recommended
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x