The optimal group of people to review this topic are Senior Software Engineers specializing in AI/NLP, Knowledge Representation, and Functional Programming Languages (Lisp/Scheme).
Abstract
This presentation details the evolution of an ontology-based dialogue management framework, named onto-VPA, developed at SRI International for Virtual Personal Assistants (VPAs) using Common Lisp. The system progressed through four distinct representational layers, driven by requirements to balance technical sophistication (Description Logic, complex reasoning) with customer usability and industry standards (OWL, SPARQL). The initial Common Lisp/Racer prototype (Level 0) provided core semantic capabilities (e.g., anaphora resolution) but lacked generality and performance. The subsequent adoption of OWL and a Java-based SPARQL engine (Level 1) improved integration and reusability but proved overly complex for end-user modeling. This led to the development of higher-level abstractions: Dialogue Workflow Graphs (Level 2) and, finally, a Domain Specific Language (DSL) implemented via Common Lisp macros (Level 3). The DSL significantly reduced the Level of Effort (LOE) required for VPA modeling (up to 83% reduction) by providing a user-friendly, domain-specific vocabulary and leveraging Lisp’s metaprogramming capabilities for rapid adaptation and efficient prototyping.
Summary: An Ontology-Based Dialogue Management Framework
0:15 Project Context (SRI International): The project goal was to create smarter Virtual Personal Assistants (VPAs) by integrating sophisticated natural language understanding and contextual sense-making through Description Logic (DL) and ontology reasoning, enabling features like anaphora resolution.
3:22 Level 0: Initial Prototype (Racer/Lisp): The first prototype (2015) implemented the dialogue manager entirely in Common Lisp using the proprietary DL reasoner, Racer. The system used a terminological component (T-Box) for domain/discourse models and an assertional component (A-Box) for runtime dialogue state (dialogue graph). Runtime dynamics were managed by ontology-based rules assessing the A-Box.
11:43 Dialogue Dynamics (Level 0): Dialogue management was achieved via a Blackboard architecture using ontology-based "demon rules." These rules used A-Box queries as pre-conditions and augmented the A-Box with conclusions (responses), managing complex logic like perfect matches versus generalized queries.
15:22 Level 0 Limitations: Key shortcomings included inadequate performance, difficulty integrating with existing Java components, a lack of generality (rules were too domain-specific), and management pressure to adopt industry standards and off-the-shelf ontologies, driving the move away from proprietary Lisp DL reasoning.
15:56 Level 1: Adoption of Standards (OWL/SPARQL): To address integration and standardization, the system transitioned to the Web Ontology Language (OWL) and SPARQL. Reasoning was moved to a Java-based engine (Apache Jena) for faster runtime performance and seamless integration with existing Java components (ASR, classifier, TTS).
19:26 Rule Engine Implementation: Since SPARQL is a query language, not a rule language, a custom rule engine was implemented in Jena/Java. Generic dialogue management rules were created, leveraging SPARQL’s second-order quantification capabilities (quantifying over slots/properties) to perform complex logic, such as checking for missing required parameters.
21:37 Level 1 Limitations (Customer Usability): Despite technical improvements, the use of OWL and SPARQL was deemed too complicated and laborious for customers, requiring a simplified modeling approach.
21:56 Level 2: Dialogue Workflow Graphs: A conceptually simpler layer was introduced, allowing customers to define dialogue state using workflow graphs (nodes and edges) built upon the underlying Level 1 ontology. This reduced OWL/SPARQL modeling but increased complexity for the upper-level developers and required laborious instance construction using Lisp macros.
24:51 Level 3: Domain Specific Language (DSL): The final level introduced a Common Lisp-based DSL to define workflows. This language significantly reduced boilerplate, provided integrated error checking, and allowed for automatic visualization of the workflow graphs.
25:09 DSL Functionality: The DSL uses macro clauses (e.g., extract-and-store, immediate-transition) and allows conditions to be expressed using the customer's ontology vocabulary (e.g., checking if Hemorrhage location is near the eye).
28:36 Quantitative Results: Implementation of the DSL (Level 3) resulted in significant reduction in the Level of Effort (LOE) required for modeling two VPA projects: a 49% reduction for the "Medic" VPA and an 83% reduction for the larger "Shared Pal" VPA.
29:14 Key Takeaway (Lisp Flexibility): Common Lisp’s metaprogramming and flexibility were crucial, allowing for rapid prototyping and constant adaptation across four major architectural shifts, ultimately enabling the creation of the effective and highly abstract DSL, which was essential for customer usability and project efficiency.