Patent Grant
7302394
Computer program listings and Table appendices comprising duplicate copies of a compact disc, named “DEJI 1008-2 CPLA,” accompany this application and are incorporated by reference. The appendices include the following files:
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the U.S. Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The invention relates to natural language interpretation systems, and more particularly to techniques for supporting natural user interaction with a back-end application via different kinds of I/O modalities.
U.S. Pat. No. 6,144,989, incorporated by reference herein, describes an adaptive agent oriented software architecture (AAOSA), in which an agent network is developed for the purpose of interpreting user input as commands and inquiries for a back-end application, such as an audiovisual system or a financial reporting system. User input is provided to the natural language interpreter in a predefined format, such as a sequence of tokens, often in the form of text words and other indicators. The interpreter sometimes needs to interact with the user in order to make an accurate interpretation, and it can do so by outputting to the user an inquiry or request for clarification. In addition, the back-end application also needs to be able to provide output to the user, such as responses to the user's commands, or other output initiated by the application. AAOSA is one example of a natural language interpreter; another example is Nuance Communications' Nuance Version 8 (“Say Anything”) product, described in Nuance Communications, “Developing Flexible Say Anything Grammars, Nuance Speech University Student Guide” (2001), incorporated herein by reference.
In the past, many natural language interpretation engines were designed to communicate with the user via a specific, predefined I/O modality. For example, some systems were designed to receive user input via a computer keyboard and to output results and clarification requests via a display monitor attached to the same computer as the keyboard. Other systems were designed to receive user input via a microphone and speech recognition software, and to provide output back to the user via text-to-speech software. Still other systems were designed to communicate with a user bidirectionally via the Web. Some systems were designed to support more than one I/O modality, but even then, the communication modalities were designed into the interaction system as a single unit.
Built-in communication mechanisms was problematical because, among other things, it was often necessary to re-program parts of the natural language interface whenever it was desired to support a new or different I/O modality. In addition, as the interface was reprogrammed to support new I/O modalities, it was difficult to maintain a consistent user feel for the application. A consistent user feel for a back-end application would afford a comfort level to the user, with both the application and the natural interaction platform, thereby increasing productivity and shortening the user learning curve.
Roughly described, the invention addresses the above problems by separating a user interaction subsystem from the natural language interpretation system. A user interaction subsystem can include an interaction block that is specific to a particular I/O modality and user device, and which converts user input received from that device into a device-independent form for providing to the natural language interpretation system. The user interaction subsystem also can take results from a back-end application in a device-independent form, and clarification requests and other dialoguing from the natural language interpretation system, and convert it to the appropriate format specific to the particular I/O modality and device. In this way all of the development for generating a natural language interpretation system optimized for a particular back-end application can be re-used for different I/O modalities and devices simply by substituting in a different interaction block into the user interaction subsystem. Similarly, all of the complications of interacting with particular modalities also can be concentrated in one module that is separate from the module(s) performing the natural language interpretation tasks.
In an embodiment, an interaction block includes an VO mode object that is specific to a particular I/O modality, and an I/O formatting object that is specific to the layout requirements of a particular I/O device. In an embodiment, the user interaction subsystem simultaneously supports more than one I/O device, such as by running several simultaneous instantiations of the I/O mode class for a particular modality, each referencing its own respective I/O Formatter object.
The following description, the drawings, and the claims further set forth these and other aspects, objects, features, and advantages of the invention.
The invention will be described with respect to specific embodiments thereof, and reference will be made to the drawings, in which:
1. System Overview
The interaction subsystem 114 includes one or more interaction blocks 118-1 . . . 118-n (illustratively 118). Each Interaction block 118 receives input from a user 112 via a different modality or I/O device and translates it into a device-independent form for use by the natural language interpreter 110. The interaction block 118 also receives output from the natural language interpreter 110 and/or the application subsystem 116, in a device independent form, and converts it to the appropriate form for presentation to the user 112 via the specific modality and device of the particular interaction block 118. As used herein, modalities are distinguished by the transport mechanism via which the interaction blocks communicate with the user 112. E-mail, World Wide Web, SMS, local computer console, and so on, are considered different modalities. I/O devices, the other hand, are distinguished by the layouts and amount of space available on the device for communicating with the user. PDAs, desktop computer consoles, and voice communication devices, for example, are considered different I/O devices. A single modality might be used to communicate with more than one kind of device. For example, e-mail transport might be used to communicate with desktop computer e-mail systems and also a PDA e-mail systems. The layout requirements of each of these devices might be very different even though the transport mechanism from the viewpoint of the interaction block 118 might be the same. On the other hand, multiple modalities might be used to communicate with a single kind of device. For example, the system 100 might communicate with a desktop computer device via e-mail, the Web, or via direct local computer console reading and writing. The layout requirements might be similar regardless of the transport mechanism used by the system 100 to reach the device, although the interaction block 118 must reach the device via different transport mechanisms. Typically (but not essentially) a different interaction block 118 is required for each combination of modality and I/O device. As used herein, an I/O agency is the combination of an I/O modality and an I/O device.
The system 100 runs on a Natural Interaction Platform that includes natural language interpreters 110, parts of the application subsystem 116, interaction agents 122, and interaction blocks 118, and also one or more interaction servers 120. Each instance of these components executes inside its own JVM, communicating with each other through RMI (Remote Method Invocation). Alternatively, in various installations some or all of the various components can execute together inside a single JVM.
The servers and components of the platform can be created or restarted independently with no particular sequence required. The I/O and interpretation components are launched with their RMI addresses and the RMI address of one or more interaction servers specified in the program argument list. The interaction servers 120 are launched with their RMI address and “Opal” configuration file specified in the argument list.
When an I/O or interpretation component is launched it binds itself to the RMI registry and starts a thread (PingServer) to check the state of servers 120 specified in the launch parameters. If a server 120 is available, the thread immediately registers the component with the server. If no server is available, then the thread periodically checks for an available server. When it finds one it will register the remote object component with the server. When an interaction server 120 is launched, it binds itself to the RMI registry and waits for remote components to register themselves. When a component registers, the server 120 creates a remote object property class (IOModeProperties for interaction blocks 118 and InterpretationNetworkProperties for natural language interpreters 110) that it stores to track and administer the components. This class starts a thread (PingRemoteObject) that periodically checks the existence of the remote object so that it can unregister the object from the server 120 if the object process terminates.
The remote components invoke methods in the interaction server through a NaturalInteractionServerInterface. These methods include mechanisms whereby components can register themselves with the server 120 and interaction blocks can request new interpretation sessions and register existing sessions. The interaction server 120 invokes methods in the I/O components through an IOModeInterface. The interaction server 120 and I/O components invoke methods in the interpretation components, including requests by the interaction blocks 118 for natural language interpretations, through an InterpretationNetworkInterface.
The interaction server 120 therefore manages the sessions with which an interaction block 118 works with a natural language interpreter 110. When an interaction block 118 receives input from a new user, it requests an interpretation session from the interaction server 120 with which the interaction block 118 is registered. The interaction block 118 can recognize a new user by methods that depend on the I/O modality, such as by email address for email modalities, phone number for SMS modalities, or HTTPSessionID for web modalities. The interaction server 120 accesses a user database 124 to validate the user and retrieve any required login information and session information for the back-end application subsystem 116, and then assigns a unique ID for the requested interpretation session. The interaction server 120 returns to the interaction block 118 with the interpretation session ID, the application login information and (in embodiments that support more than one natural language interpreter instantiation) an identification of an interaction agent 122 (discussed below) to which the interaction block 118 should route the user's requests. The interaction block 118 stores this information in a TimedHashtable and uses it to forward queries into the assigned natural language interpreter 110 originating from the particular user.
The system 100 is designed to recover automatically if any one of the processes fails, so long as there is at least one more instance of that process still running. If a natural language interpreter 110 fails, then any interaction block 118 that has a user assigned to that interpreter 110 will receive a remote exception when it tries to forward a user query to the interpreter 110. At this point the interaction block 118 returns to the interaction server, requests a new interpretation session, and submits the query to the new interpreter 110 assigned. If an interaction server 120 fails, pinging threads in the remote object components will detect this and try to register with another interaction server 120 or wait for a new one to be started. If an interaction block 118 fails, then it is up to the application subsystem 116 to detect this and route its output via other available I/O components.
2. Natural Language Interpreter
The natural language interpreter 110 can be any functional unit that attempts to discern from user input, the intent of the user relative to the back-end application. It receives commands from the user 112 (via the I/O subsystem 114), and outputs toward the back-end application subsystem 116 an indication of the function or functions that the NLI believes the user intends. Many NLIs operate in part by attempting to spot concepts in an incoming token sequence, typically by reference to specific keywords or classes of keywords. Some of the keywords are the concepts themselves (like “Monday” in the phrase, “I'll be there on Monday”), and some of the keywords are indicators of where the concept is likely to appear (like “on” in the same phrase). The NLI 110 can include, for example, Nuance Commumications' Nuance Version 8 (“Say Anything”) product or an AAOSA agent network from Dejima, Inc.
In an AAOSA agent network, agents contain policy conditions which either do or do not apply to the incoming text string, and if they do, they make a claim to at least a portion of the incoming text string. Such claims imply a tentative interpretation of part or all of the input string. For example, if the back-end application subsystem 116 includes an airline reservation system, then an agent network in NLI 110 might be designed to include policy conditions to look for any of the words “depart”, “departing” or “leaving”, earlier in the text string than the word “from”, which in turn is earlier in the text string than a city name.
Only a partial representation of the agent network 202 appears in
As described in the Dejima policy reference, an interpretation policy contains, among other things, a policy condition and a policy action. When an agent receives a message from another agent to attempt to interpret and input string, it compares the input string to each of the agent's policy conditions in sequence. If a condition does apply to the input string, or to part of the input string, then the policy makes a “claim” on the applicable portion of the input string, and returns the claim to the agent that requested the interpretation. A claim identifies (among other things) the agent and policy which is making the claim, the portion of the input string to which the claim applies (called the claim “focus”), the priority number of the agent or policy, and also a confidence level which indicates how well the input matches the policy condition. The priority and confidence levels, and the focus, all can be used subsequently by upchain agents for comparison with other claims made by other downchain agents, so as to permit the upchain agent to select a “best” one among competing claims.
Policy conditions are written as expressions made up from operators and operands. The various operators include unary operators such as <exists>, <exact>, <substring>, <accent>, <accent-substring>, REPEAT and RECURSIVE. They also include binary operators such as OR, AND, ORDERED, ADJACENT and COMBO. The operands on which an operator can act include tokens (words, strings, numbers, symbols, delimiters), text files (which can contain their own policy conditions), databases, and claims made by other policies. If a first policy condition (the “referencing policy condition”) refers to a second policy (the “referenced policy”) previously evaluated in the same agent, then any claim made by the referenced policy can be figured into the evaluation of the referencing policy condition in the manner specified by the operators. If a policy condition refers to another agent (the “referenced agent”) downchain of the current agent (the “referring agent”), then the claim or claims returned by the referenced downchain agent are figured into the evaluation of the referencing policy condition in the manner specified by the operators. Note that a policy condition that references a downchain agent cannot be completely resolved until the input string is passed to that other agent for comparing to its own policy conditions. In one embodiment, the referencing agent passes the input string to each downchain agent only upon encountering the agent's name while evaluating a policy condition. In the present embodiment, however, the referencing agent passes the input string to all downchain agents mentioned in any policy condition in the referencing agent, before the referencing agent begins evaluating even its first policy condition.
Returning to
When the Finance agent 214 receives the input token sequence, it first looks in its policies for policy conditions that make reference to further agents downchain of the Finance agent 214. If there are any, then the Finance agent 214 forwards the input token string to each of the further downchain agents in an “IntepretItMessage” and awaits replies. In the embodiment of
Thus in the embodiment of
The System agent 212 evaluates its own policy conditions in the same manner as other agents in the network, and each such policy again makes as many claims as it can on the input. But because the System agent 212 is the Top agent, it does not transmit any resulting claims (or NoClaims) to any further upchain agents. Instead, as the Top agent of a network, after selecting one or more “best” claim(s) in the manner described above, System agent 212 has the responsibility to delegate “actuation” to the agents and policies that made up the claim(s). This process, which is sometimes called “executing” the winning claim, takes place according to the “action” part of the winning policy or policies in the Top agent. The action part of a policy builds up an actuation string in a manner similar to that in which policy conditions build up the result of the condition, that is, by string operators and operands that can include words, numbers, symbols, actuation sub-strings already created by other policies within the same agent, and actuation sub-strings created by other downchain agents. Typically the downchain agents referred to in the action part of a policy are the same agents referred to in the condition part of the policy. Also typically, the actuation string built up by this process is an XML string.
In order to fill in the actuation sub-strings defined by downchain agents, the Top agent sends an object of class DelegationMessage to each downchain agent referenced in the action part of the winning policy(ies). In the embodiment of
Thus it can be seen that interpretation of the user's intent takes place in an agent network in a distributed manner. Each of the agents in agent network 202 can be thought of as having a view of its own domain of responsibility, as defined by its interpretation policies. Typically the application domain is organized by the designer into a hierarchy of semantic sub-domains, and individual agents are defined for each node in the semantic hierarchy. In the embodiment of
It can also be seen that the Top agent of a network is responsible for receiving input and initiating queries into the network, and the agents representing the functionality of the system (the agents constructing their actuation sub-strings without reference to further agents) are the lowest order nodes (leaf agents) of the network. The network operates in two main phases: the interpretation phase and the delegation phase. In the interpretation phase, an initiator agent (such as the Top agent) receives the input token sequence and, by following its policy conditions, queries its downchain agents whether the queried agent considers the input token sequence, or part of it, to be in its domain of responsibility. Each queried agent recursively determines whether it has an interpretation policy of its own that applies to the input token sequence, if necessary further querying its own further downchain agents in order to evaluate its policy conditions. The further agents eventually respond to such further queries, thereby allowing the first-queried agents to respond to the initiator agent. The recursive invocation of this procedure ultimately determines a path, or a set of paths, through the network from the initiator agent to one or more leaf agents. The path is represented by the claim(s) ultimately made by the initiator agent. After the appropriate paths through the network are determined, in the delegation phase, delegation messages are then transmitted down each determined path, in accordance with the action parts of winning policies, with each agent along the way taking any local action thereon and filling in with further action taken by the agents further down in the path. The local action involves building up segments of the actuation string, with each agent providing the word(s) or token(s) that its policies now know, by virtue of being in the delegation path, represent a proper interpretation of at least part of the user's intent. The resulting actuation string built up by the selected agents in the network are returned to the initiator agent as the output of the network. This actuation string contains the fields and field designators required to issue a command or query to the back-end application subsystem 116, to effect the intent of the user as expressed in the input token string and interpreted by the agent network.
3. Interaction Block
As mentioned, the interaction block 118 typically is specific to one I/O modality (or a group of very similar I/O modalities), and one I/O device (or a group of I/O devices that are very similar in their layout requirements). Although in one embodiment a single interaction block 118 class is usable with any back-end application, in the embodiment described herein it is specific, or somewhat specific, to a kind of application that includes back-end application subsystem 116. For example, if the back-end application is a financial reporting application, then the interaction block 118 might be generic to financial reporting applications from several suppliers. In the embodiment of
The I/O mode object 126 is the basic interface between a particular user interface modality (standard email, the web, SMS, a window on the user's screen, an e-mail modality that supports PGP encryption, etc.) and the NLI 110. The class defining each I/O mode object preferably is re-usable with any application and for any I/O device that supports the same transport mechanism as the I/O modality. There should be no application specific code in an I/O mode class definition. In some cases that might be unavoidable, however, so to include features specific to one kind of application, the I/O mode object 126 is instantiated from a generic base class, which is reusable for any kind of application, and a separate subclass specific to the kind of application targeted.
Each I/O mode object is responsible for:
I/O mode objects are designed to be as much as possible application independent, but the format of the output of one kind of application is most likely unique and very different than the format of the output for another kind of application. For example, the format of output from a contacts manager is very likely to be very different from that of a financial reporting application. In addition, even for a single application, the layout of output required for a computer monitor is likely to be very different than that required for a PDA. To allow the I/O mode objects to remain application and device independent, their presentation methods are encapsulated within I/O formatter objects 128. Thus an I/O mode object 126 can take an I/O formatter object AX_iof for an application of kind A and a device of kind X, and the same I/O mode class definition can be used to instantiate an I/O mode object for application of kind B and a device of kind Y merely by being assigned an I/O formatter BY_iof. The I/O mode objects would behave the same way in essence, but the output of each I/O mode object would depend on the particular I/O formatter object 128 to which it is assigned. As examples, I/O formatter objects 128 can be designed for displaying display web pages on PDA's, for displaying e-mail on desktop computer monitors, for displaying e-mail on PDA's, for displaying SMS messages on SMS devices, and for formatting voice output for voice devices. In another embodiment, all of the presentation methods could be encapsulated in subclasses of a parent I/O Mode class, rather than in a separate I/O Formatter object.
An I/O formatter object 128 is assigned to each I/O mode object 126 at initialization. System output destined for user 112 is provided to the I/O mode object 126 in a generic form, such as an XML string, and the I/O mode object 126 calls methods of the assigned I/O formatter object 128 in order to convert the string to a new format that the I/O mode object 126 then can simply transmit to the user via the particular transport mechanism that the I/O mode object 126 is designed to use.
The TextIO Format class 418 also has an XML IO Format subclass 420, which provides the system designer with a standardized method for defining the formats required for various I/O devices. In particular, an object of class XmlIOFormat uses XML Stylesheet Transformations (XSLT) to define the formats. Such an object takes in an XML input originating from the NLI 110 or back-end application subsystem 116, uses an application- and I/O device-specific stylesheet 422 to transform the XML, and sends the transformed data toward the user 112. An example XmlIOFormat class definition is set forth in the java file named CD-XmlIOFormat.java.txt in the accompanying Computer Program Listing and Table Appendices. Note that for stylesheets, it may be preferable to use parameters and named-templates. For instance, the layout for an entire back-end application can be based on one generic template layout, with specific parts filled in according to the particular nodes that are in the output XML. Instead of having similar logic repeated throughout the stylesheet, the stylesheet processing can begin with the logic, use the logic to assign values to parameters, then call the named-template (representing the basic layout of the application) with the parameters (representing the values that should be used to fill in the template). This technique also allows easier re-use of the same logic across different I/O modalities, for example since e-mail and web modalities often use the same general logic.
4. Interaction Agent
In one embodiment, the NLI 110 communicates directly with an interaction block 118, and directly with the back-end application subsystem 116. In the embodiment of
The messages sent by the NLI 110 or the application subsystem 116 to the interaction agent 122 for forwarding toward the user 112 are objects of class InteractionMessage. A message of this class can contain any object within it, though the I/O formatter object that will process the message must know how to handle the data within the InteractionMessage. Facts (data from the system), questions (when more information is needed), and lists (when a choice must be made between several items—for ambiguities—did you mean A or B?) are all different types of data that can be contained within an InteractionMessage and formatted appropriately by the I/O formatter object. An example InteractionMessage class definition, in java, is set forth in the file CD-InteractionMessage.java.txt in the CD-ROM appendix hereto. The InteractionMessage class extends a MessageContent class whose definition is set forth in the java file named CD-MessageContent.java.txt in the accompanying Computer Program Listing and Table Appendices.
The messages sent by the interaction agent 122 into the NLI 110 are objects of class InteractionResultMessage. A message of class InteractionResultMessage generally encapsulates a user query, which is processed into a command by the agent network in the interpretation subsystem. Occasionally, a message of class InteractionResultMessage contains followup information from the user 112 and prior context. For example, when the user has answered a question, the answer to the question and the context of the question is maintained. An example InteractionResultMessage class definition, in java, is set forth in the file CD-InteractionResultMessage.java.txt in the CD-ROM appendix hereto. The InteractionResultMessage class also extends the MessageContent class mentioned above.
It can be seen that the above-described system separates the particulars of user interaction via various I/O agencies, from the natural language interpretation system and the back-end application subsystem. In this way, all of the development for generating a natural language interpretation system optimized for a particular back-end application can be re-used for different I/O agencies simply by substituting in a different I/O interaction block 118 into the user interaction subsystem. Similarly, all of the complications of interacting with particular agencies also can be concentrated in one module that is separate from the module(s) performing the natural language interpretation tasks.
As used herein, a given signal, event or value is “responsive” to a predecessor signal, event or value if the predecessor signal, event or value influenced the given signal, event or value. If there is an intervening processing element, step or time period, the given signal, event or value can still be “responsive” to the predecessor signal, event or value. If the intervening processing element or step combines more than one signal, event or value, the signal output of the processing element or step is considered “responsive” to each of the signal, event or value inputs. If the given signal, event or value is the same as the predecessor signal, event or value, this is merely a degenerate case in which the given signal, event or value is still considered to be “responsive” to the predecessor signal, event or value. “Dependency” of a given signal, event or value upon another signal, event or value is defined similarly.
As used herein, an item is “identified” if sufficient information is provided to distinguish the item from other items. For example, information identifies an item if the information can be used to access data relating to the item rather than to access data relating to other items.
The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously, many modifications and variations will be apparent to practitioners skilled in this art. In particular, and without limitation, any and all variations described, suggested or incorporated by reference in the Background section of this patent application are specifically incorporated by reference into the description herein of embodiments of the invention. The embodiments described herein were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalents.
1 Introduction
Policies are written in a language called OPAL. This reference intends to describe the OPAL language. The current version of the platform can run in backward compatibility mode. In this mode some of the features described in this document would not be available. The comment “(not available in backward compatibility mode)” is written in front of each of these features. Set the system property USE_AMBIGUITY_XML to alse to run the platform in the backward compatibility mode. Example: java-DUSE_AMBIGUITY_XML=false IDE.
2 Policy
An AAOSA agent uses a set of policies to make claims on the input and to make actions based on those claims.
2.1 Overview of Claim
A claim is the part of the input that an agent policy recognizes as part of its domain. A claim may be built by putting together claims made by other policies or other agents. For example a HOME_ENTERTAINMENT policy may make claims based on claims made by a TV policy and a VCR policy. We would refer to TV and VCR claims as sub claims in the context of the HOME_ENTERTAINMENT claim.
2.2 Propagation of Claims
An AAOSA agent will use its policies to process the input when it receives an initiate interpretation, interpretation or reinterpretation message. Agents process the input in order from first policy declared in the agent to the last policy. Each policy makes all the claims it can on the input. Following policies can access these claims. After all policies have made their claims the agent selects the best claim. If the best claim is made from a non-grammatical condition (e.g. combo), then the sub-claims are also selected. The selected claims are handed up to up chain agents (i.e. using claim message).
2.3 Actuation of Claims
An Actuation is a standardized output. The actuation phase begins when the top AAOSA agent selects its best claim. The top agent will actuate the best claim using the action part of the policy that made that claim. The policy's action dictates whether the actuation of the claim should be delegated to other policies or agents. If the actuation is delegated to another agent a delegation message is sent to that agent. When an AAOSA agent receives a delegation message for actuating a claim, it will use the policy responsible for making that claim to actuate it. Each policy will either actuate the claim entirely or delegate parts of the actuation to other policies or agents responsible for making its sub claims.
2.4 Overview of Policy Components
A policy can have several components:
A claim quantifies how well an input matches a policy condition. The information associated with a claim includes:
3.1 Owner
The name of the policy making the claim and the agent to which that policy belongs.
3.2 Focus
The parts of the input matched by the policy condition. Focus is represented using the character indexes of the input. (Characters in the input are indexed from 0). For example, focus [5 . . . 8] represents the word ‘book’ in the input ‘Sell book’. The characters of the input that correspond to the token separators (for example, white space) are never considered to be part of the focus. Therefore, a policy condition that matched ‘Sell’ and ‘book’ would have focus [0 . . . 3,5 . . . 8]. However, when there is no chance of confusion, for convenience this focus would be written as [0 . . . 8].
3.3 Priority
The precedence of the claim. (For details on assigning priorities to claims, see the Policy Components section.) Priorities are local to an agent. When an agent sends a claim to an up chain agent, the priority is reset to 0. The exception is priorities that are assigned for adding dialoging focus. These priorities are passed up-chain with the claim.
A vector is kept of all different priorities that were associated to sub-claims building up a claim. The focus size of the sub-claims with the same priority will be added up and would be kept in the vector.
The priority vector of claim on ‘aaa bb’ made by policy P3.
The priority criterion of two claims will be compared in the following manner:
A claim is said to be ambiguous if it contains two or more sub-claims with overlapping focuses. The ambiguity of the claim is equal to the number of ambiguous sub-claims that are found in the claim, including the claim itself.
3.5 Connection Weight
The total sum of connection weights assigned to operators making the claim. Each operator and operand has a predefined grammatical weight. The operators and operands in descending order of grammatical weight are:
1. Combo (,) and Recursive (+). Weight=∞. (loose connection)
2. Inexact matches. Weight=10000.
3. And (&). Weight=100.
4. Ordered (<). Weight=1.
5. Adjacent (and all other operators and operands). Weight=0.
3.6 Loose Connections Count
The number of Combo (,) or Recursive (+) operators used to make a claim.
3.7 Unknown
Used to identify the number of items missing in the user input (deprecated). See Section 3-3-4 on <unknown if missing> condition.
3.8 Adjacency Score
Indicates the relative closeness of the claimed parts of the input. Adjacency score is calculated by adding up the number of tokens between claimed parts. If a claim has marked ‘Siamak’ and ‘Hodjat’ on the input “Siamak is a Hodjat”, its adjacency score is 2. A claim marking ‘Sia’ and ‘Hodjat’ on input “Siamak is a Hodjat”, will also have adjacency score of 2, because ‘Sia’ is part of the ‘Siamak’ token, but the same claim will have an adjacency threshold of 5 on the input “Siamak's family name is Hodjat” (Assuming the default USTokenizer is used). The following table shows the how adjacency score is calculated for different inputs claimed by the policy: ‘aaaaa’ & ‘bbbbb’.
Computing Adjacency Score
Note that adjacency is handled slightly differently in the case of the combo operator. See the section on the combo operator for details.
3.9 Variable
Variables mark parts of the input that is not claimed by other conditions in a policy. Variables are adjustable and the part they mark may vary as the claim is manipulated (see variable condition).
4 Claim List
All claims made by policy conditions are added to an ordered list. The default criteria used to order the claims is as follows, listed in the order in which they are considered when comparing two claims. Each criterion is checked only if none of the criteria above it would apply. If two claims are equivalent with respect to all of the criteria, the claim that was made by the policy listed later in the Agent will win.
4.1 Coverage
A claim whose focus includes another claim's focus wins. If the focuses are equivalent, neither is considered to cover the other. For example, a claim made on ‘Being John Malkovich’ with focus [0 . . . 4] [6 . . . 9] [11 . . . 19] will win over a claim with focus [6 . . . 9] [11 . . . 19]. However, if two claims both had focus [0 . . . 4], the claims would be equivalent in terms of the coverage criterion.
4.2 Priority
A claim with higher priority wins. If the priorities are the same, the claim with the higher priority score will win. (See the Policy Components section on Priority for details on how priority and priority score are assigned.)
4.3 Ambiguity
A claim with more ambiguity wins. This criterion is checked only if the current claim can be merged with the claim it's compared to. (See Claim Manipulation in Appendix 3 for further information.) If two claims have equivalent ambiguity, the ambiguity due only to the current claim is compared. If this differs, the claim with the smaller local ambiguity will win (regardless of whether the two claims can be merged).
4.4 Connection Weight
A claim made by more grammatical operators and exactly matched operands wins (that is with smaller connection weight). If the connection weights of two claims are equal then the claim with fewer loose connections wins.
4.5 Adjacent
A claim with smaller adjacency score wins.
4.6 Focus Size
A claim with a larger focus wins. For example, a claim made on ‘Sell Book and Buy Toy’ with focus [0 . . . 3] [5 . . . 8], will win over a claim with focus [9 . . . 11] [13 . . . 15]).
4.7 Match Restrictiveness
A claim using a more restrictive token matcher wins. The most restrictive token matcher is the exact token matcher, which has a restrictiveness of 100. The substring token matcher has a restrictiveness of 60.
4.8 Variable
When comparing two claims the claims with no variables is better than a claim with variables. If both claims have variables then the one with more variables but smaller ones is preferred to the one with less but wider variables (see variable condition).
4.9 Unknown (Deprecated)
A claim with unknown element(s) will win over a claim with no unknown elements. If both claims have unknown elements the one with less unknown elements wins.
4.10 Default criterion:
A claim, which its focus is closer to the beginning of the input wins.
5 Policy Components
5.1 Name
Used to refer to the policy in the OPAL language. A policy name is a series of capital letters (‘A’ to ‘Z’), digits (‘0’ to ‘9’) or under score (‘_’) that begins with a capital letter. Policies names should be unique (in the scope of the agent they are declared in).
5.2 Title
Used to refer to the policy in interactions and menus. Spaces/symbols can be used in the title and it does not need to be in capital letters. The title is a literal and is automatically enclosed in quotes.
5.3 XML Tags (Not Available in Backward Compatibility Mode)
The interpretation network will support the generation of output that contains XML tags. This section will discuss the types of tags that will be used and how they are generated. It will use the AV Network as an example. See
An XML tag is made up of three components
A basic XML tag has the form:
<<name> [<parameter>=“<value>”]> </<name>>
For example, a tag having two parameters would have the form:
<name parameter1=“value1” parameter2=“value2”> </name>
The interpretation network supports two parameters, type and ID. These are discussed in more detail later. For now, just note that the general form of an XML tag generated by the network is:
<name type=“value1” ID=“value2”> </name>
The XML tags that are supported by the interpretation network can be divided into four groups (two of which consist of a single tag):
1. The Interpretation Tag
2. The Ambiguity Tag
3. The Logical Tags
4. Domain Specific Tags
The first three groups are common to all applications. The domain specific tags vary from application to application.
The tags are generated in two ways. The interpretation tag and the ambiguity tag are generated automatically by the interpretation network. The logical tags and domain specific tags are generated by setting the xml-tag and xml-type fields in the policy of a network agent.
As mentioned above, the system supports two parameters: type and ID. The type parameter is optional. For logical and domain specific tags, it can be specified by setting the xml-type field of a policy. The ID parameter is generated automatically by the system. Its value is equal to the ID of the claim that is being actuated by the policy.
Simple Command
Simple Command: Attribute with Values
Compound Attributes
Compound Commands
Ambiguity
5.3.1 Generating XML Tags
Syntax: {XML tag: tag-name}
XML tag goes after the policy condition.
Generating XML tags
5.3.2 Generating XML Type Tags
Syntax: {XML tag: tag-name}
XML type tag goes after the XML tag. XML type is valid only if XML tag is provided for the policy.
Generating XML Type Tags
5.3.3 Ambiguity Tags
Ambiguity tags are generated automatically.
Generating XHL Type Tags
5.3.4 Backward Compatibility
The priority assigned to a policy. A policy's priority is assigned to all claims made by that policy.
Of the criteria used to order the claim list, priority is the only one that can be set explicitly in the policy. Priority is the second criterion used when comparing two claims; coverage is compared first. If two claims are equal in terms of coverage, then the one with a higher priority will win. Therefore, priority provides the policy writer with a good amount of control over which policy should produce the winning claims.
The default priority is 0. Priority can explicitly be set to any integer between −1000 and +1000, inclusive. A positive integer will give the claims made by the policy higher priority; a negative integer will give them lower priority.
A list is kept of all different priorities that were associated to sub-claims building up a claim. The focus of the sub-claims with the same priority will be added up and would be kept in the list.
The Priority List of Claims
The priority criterion of two claims will be compared in the following manner:
Priority is used only for ordering the claim list of the agent containing the policy. When an agent passes a claim up chain, the priority of the claim is removed.
5.5 Continuation (Not Available in Backward Compatibility Mode)
The continuation field provides support for recognizing continuation in the interpretation network.
For example consider the following dialog:
01 User: “Movies starring Tom Hanks”
02 User: “And Meg Ryan”
Current input is a continuation:
Whenever a policy is a join continuation then any claims made by that policy will be tagged as continued. Lets say the claim made by a policy with a {continuation: join} field would be part of the winning claim. If this is true then the input is going to be reinterpreted based on the claims made on the previous input. So in the above example the “And Meg Ryan” input will be claimed with dependency to the previous input (“Movies starring Tom Hanks”) and therefore “And Meg Ryan” will be reinterpreted again but this time the claims made on the previous input (“Movies starring Tom Hanks”) would be used.
5.6 Condition
Used to make claims from the input. Each condition will return a claim list of all claims it produces. There are four types of conditions: terminal, reference, unary and binary.
5.6.1 Terminal Condition
There are four types of terminal conditions:
Token Terminal Predefined patterns retrieved from a string, a file or a database.
Number Terminal Refers to claims made by other policies within the same agent.
Symbol Terminal Refers to claims made by other agents.
Type Terminal Refers to a part of the input not claimed.
5.6.1.1 Token
Tokens are identified based on the following parameters:
The above parameters are defined in properties/ParserParameters.xml. Whatever is not included as an alphabet, numeral or symbol is considered a delimiter by the tokenizer.
Defining alphabet in ParserParameters.xml
Defining numerals in ParserParameters.xml
Defining symbols in ParserParameters.xml
Note that based on example 11, the symbol $ will be recognized as a symbol because it is in the range between “!” and “/”. But the symbol £ will not be recognized because it is not in any of the defined ranges. For it to be recognized as a symbol a new range would have to be added to the symbol definition (“£” is the Unicode for £).
Recognizing the £ Sign
Other than the above-mentioned parameters, customized tokenizer classes may introduce application or language dependent types. The custom tokenizer class should replace USTextTokenizer in ParserParameters.xml.
A token is any stream of characters of the same type (e.g. alphabet, number, symbol) separated by delimiters or other tokens. Symbols are exception to this rule because symbols are broken up character by character.
Tokenizing
To see details on number tokens, see the section on number terminals.
5.6.1.2 Token Terminals
There are three types of token terminals:
Strings
Files (/F)
Databases (/DB)
5.6.1.2.1 Strings
The condition applies if part of the input matches the string. The string is broken into tokens. The tokens are implicitly joined using the adjacent operator. Each token is matched using the default <exact, substring> match. See Section 5.3.3 on how each token is matched using <exact> and <substring>; see Section 5.4.4 on how the ADJACENT operator works.
String Condition
The ‘, “, and/are special characters that should be referred to using %SINGLE_QUOTE %, %DOUBLE_QUOTE% and %BACK_SLASH% sequences.
Using Special Characters In String Condition
The /F Condition
A claim will be made on only those input tokens that are in order.
The /F Condition
The condition will apply and will make the claim: ‘john malkovich’
The /F Condition
The default behavior will change if token matchers (see Section 5.3.3, e.g. <exact>, <substring> . . . ) are applied to the /F condition. If token matchers are used then all tokens in the file entry must appear in the input adjacent and in order.
The /F Condition
The condition will not apply as ‘sixth’ does not appear in the input.
The /F condition
The condition will not apply as ‘sixth sense’ does not appear in the input in the same order as the file.
The /F Condition
The condition will not apply as ‘sixth sense’ is not adjacent in the input.
5.6.1.2.3 Common Files
A common file may be provided for an agent network to modify the behavior of file conditions (/F). To prevent unwanted claims made by file conditions create a common file. The common file should contain a list of common words (e.g. the, as, is).
The Problem (Why We Need Common File)
‘the’.
How Common File Will Help
The file condition will ignore the common words only if they are not adjacent to a non-common word.
Common Files
The condition applies if part of input matches one of the columns in a database. A database spec file (in text format) should be provided for the /DB condition. This spec file should contain the following information:
1. JDBC driver
2. JDBC server location
3. Database name (or ODBC data source name)
4. Table Name
5. Column Name
6. Login
7. Password
Defining Spec File for JDBC Connection to Pointbase Using /DB
Defining spec file for JDBC connection to Microsoft Access using /DB
The token matchers (e.g. <exact>, <substring>, . . . ) is not applicable to the /DB.
5.6.1.3 Number Terminal (/NUMBER)
The condition applies if a number token is found in the input (numbers are identified by the tokenizer).
You may also define a range for the /NUMBER condition.
Numbers are tokenized using the following rule:
<DIGIT>+[(COMMA|PERIOD)<DIGIT>+]+
Valid numbers:
3.4.5
23,3434,43
3.4,5
The condition claims a single symbol in the input (numbers are identified by the tokenizer, refer to Section 5.4.1.1).
Symbol Terminal
Symbol Terminal
(Not Available in Backward Compatibility Mode)
The condition claims a delimiter in the input (delimiters are identified by the tokenizer, refer to Section 5.4.1.1).
Delimiter Terminal
Delimiters are most useful when used in conjunction with variables. Note that Blanks are added to the beginning and the end of all text inputs automatically and therefore the beginning and the end of input is always a delimiter.
Delimiter terminal at the beginning of the input
(Not Available in Backward Compatibility Mode)
The condition claims the first character of the input that is always a blank space (blanks are added to the beginning and the end of all text inputs automatically).
BOI terminal
(Not Available in Backward Compatibility Mode)
The condition claims the last character of the input that is always a blank space (blanks are added to the beginning and the end of all text inputs automatically).
EOI terminal
The condition applies if a user defined token type is found in the input. New token types could be defined in the tokenizer.
5.6.1.9 Check Condition (<check (agent, property, key; value)>):
Makes a claim only if an agent's property is equal to a specific value. This condition is especially useful for the AAOSA agents to know about the state of the application or device. For example the TV-agent in a TV/AV interface could use the <check> condition to know if the TV is on. If the TV is on and the user says ‘power on’ then the TV agent could generate the proper response. There are two types of properties that may be accessed through messaging:
a. Data property (basic objects)
b. Data store property (collection objects: hash tables, vectors, . . . )
Each agent must allow access to its data property by declaring it as a valid data property. The methods that should be sub-classed for this purpose are summarized in the following table:
All AAOSA agents have a STATE property that could be checked (STATE is a basic property).
The parameters of a check message, <check (agent, property, key; value)>, are:
Agent: The agent address that its property is to be checked. This parameter is optional. If omitted then an agent will “check” its own property.
Property: The name of the property to be checked.
Key: The key to the data store property (as a string). This parameter is optional. If omitted then an agent will “check” a basic property.
Value: The value that the property will be compared to (as a string).
Check Condition
See section 6.2.6 and 6.2.7 for more information on set and get.
5.6.2 Reference Conditions
5.6.2.1 Policy Reference
The condition applies if another policy has claims. A policy name is a series of capital letters (‘A’ to ‘Z’), digits (‘0’ to ‘9’) or under score (‘_’) that begins with a capital letter. A policy can only refer to policies that are declared before it.
5.6.2.2 Agent Reference
The condition applies if the referenced agent has claims. The referenced agent must be a listener to the agent that owns the policy.
An agent is referred to using its address. An agent address has the following format:
agent-instance-name . agent-class @ domain
An agent could be referred to only if it's agent-instant-name would be a series of capital letters (‘A’ to ‘Z’), digits (‘0’ to ‘9’) or under score (‘_’) that begins with a capital letter.
Agent Reference
Variables behave and generate claims according to the following rules:
Variable Condition Bound from Both Sides
Variable Condition Bound from One Side
Merging Variable Claims with Claims with No Variable Part.
No Claims are Made When the Input Contains No Variable Parts.
Claims With No Variables Win Over Claims with Variables.
Claims with greater number of variables win.
Claims with Smaller Variable Length Wins
Named Variables
Cascading Variables
Unbound Variables
Unary condition is an operation on one operand. There are six basic unary conditions:
This condition will always make a claim. The claim made depends on the operand:
Optional Condition
Policies should not be written in a way that they could make a null claim. For example, the following policies are not supported (although the SDK would not prevent them from being written):
Policy Conditions that Should be Avoided
Each of the above policies makes a null claim regardless of the input. An example of the bizarre behavior that would result is:
Avoiding Null Claims
Checks to see if the operand has claims. If this is true, then the <exists>condition will make a null claim (an empty claim). If this is false, then the <exists> condition will not make a claim.
Exists Condition
If binary conditions such as adjacent, and (&), ordered (<) and combo (,) appear in the same policy as the <exists> condition, then they behave as if <exists> condition is making claims on the input. For example:
Exists Condition
Note that the scope of <exists> condition is only the policy in which it appears.
Exists Condition
Policies should not be written in a way that they could claim null. That is the following policies are not supported (although the SDK would not prevent them from being written):
Policies that Should be Avoided
Each of the above policies makes a null claim regardless of the input. An example of the bizarre behavior that would result is:
Policy Conditions that Should be Avoided
When using <exists>, an agent is checking against a part of the input that it is not going to claim. Therefore the agent must be aware of parts of the input that are possibly another agent's responsibility. This is against the agent oriented programming style where an agent should only care about its own domain and should not worry about other domains. Therefore <exists> should always be avoided if possible. There is usually a better way to write the policies or configure the agent network to avoid the usage of <exists>.
5.6.3.3 Token Matching Condition
This unary operator defines the type of token matching applied to token terminals and file terminals. There are 6 types of token matching:
<exact>
<substring>
<accent>
<accent-substring>
<accent-edit-difference>
For details on using these condition with combination to file terminal (/F) please refer to the section on file terminals.
5.6.3.3.1 <exact>
An input token matches a terminal token only if they are the same length and all their characters are exactly the same.
<Exact> Condition
Two tokens match only if there is an exact match or:
If the size of input token getting matched is less than the size of pattern, the input token will be claimed otherwise only the matched part of the input token will get claimed.
Substring Matching
Tokens are matched using a rule-based collator.
5.6.3.3.4 <accent-substring>
Similar to a substring matcher but <accent-substring> matches the characters using a collator.
5.6.3.3.5 <accent-edit-difference>
Matches two tokens using a rule based collator. The match allows missing or extra characters (less than a certain threshold currently defined in ParserParameters.xml). Tokens are matched only if they are larger than a certain length (currently defined in ParserParameter.xml).
5.6.3.3.6 Using Multiple Matchers
More than one token matching might be used to match terminal tokens. The matching will then be applied to the tokens one by one. If the first matching does not make a claim, the next matching in the list will be used.
Using Multiple Matches
The default matching used are: <exact, substring>.
Default Matches (<Exact, Substring>)
Token matching types could be also applied to file terminals (changing their default matchings)
Matching Types Applied to File Terminals
Each token matching type has a value, which shows how restrictive it is. The restrictive-ness values is a constant, predefined heuristically:
Exact (100)
Substring (60)
Accent (50)
Accent-Substring (85)
Accent-Edit-Difference (50)
5.6.3.3.7 Fast Matchers (<exact>, <substring>)
The matchers are categorized into fast and flexible matchers. The fast matchers are: <exact> and <substring>.
5.6.3.3.8 Flexible Matchers(<exact>, <substring>,<accent>, <accent-substring>, <accent-edit-difference>)
The flexible matchers include all fast matchers and the accent>, <accent-substring> and <accent-edit-difference> matchers. These matchers are not included into the development platform by default unless the parserParameter.xml would be changed to include them by replacing the following line:
<Policy:TokenMatchers value=“fast”/>
With:
<Policy:TokenMatchers value=“flexible”/>
Note: It is not recommended to use the flexible matchers as they have a very poor performance.
5.6.3.4 Unknown Condition (<unknown if missing> operand)—deprecated:
Checks if the operand has claims. If this is true it will make the claim(s). If this is false, it will change the state of the claim to unknown (i.e. the operand is unknown). If a claim with unknown is actuated the system can prompt the user for clarification. How this prompting works and the attributes of the policies involved are discussed in section 4 (Actions).
Unknown Condition
Unknown Condition
The <unknown if missing> operator is deprecated and it is recommended to use other approaches for dialoging (refer to section 6 for more information).
5.6.3.5 Recursive Condition (operand+):
The recursive condition makes new claims by merging subsets of the claims made by the operand. Specifically, each claim made by the recursive condition is the result of merging claims that form a maximal disjoint subset of the set of claims made by the operand. Two claims are said to be disjoint if their focuses do not overlap (that is, the intersection of their focuses is null). A set of claims is disjoint if every claim in the set is disjoint to every other claim in the set. A set is maximal if it is not a subset of any other set.
+Condition
+Condition
A policy condition should not reference a recursive condition.
Policies Containing Recursive Conditions Should not in General be Referenced by Other Policies. The Recursive Condition Does not Generate all Possible Inner-Products.
An Example of Referencing Recursive Conditions in a Policy that Might go Unnoticed.
Be careful of the common mistake illustrated in the following example, in which A agent is downchain of Top agent:
Common Mistake in +Operand Usage
It might be expected that the TOP agent in the above example should claim the whole input ([0 . . . 0] [2 . . . 2] [4 . . . 4]). The reason it does not is that Agent A passes only its best claim up to the TOP agent. In other words, the recursive condition (like all other conditions) does not affect how a down chain agent makes claims on the input. If multiple claims on character ‘a’ are required, then Agent A should have a recursive condition of its own:
Correct Usage of +Operands
In the latter example it is not necessary to have the recursive condition in the TOP agent. However, a good practice is to use a “catch all” policy, which applies the recursive condition to all of an agent's policies and down chain agents.
When two claims are merged using the recursive condition (and similarly the combo condition) then the resulting claim will have a loose connection. Claims with loose connections will fail to merge to other claims using the grammatical operators (such as &,<and adjacent).
Incorrect Usage of +Operands
Timing Out in Recursive Condition
Recommended usage of the recursive operator is only in the catch policy (described later in the reference).
5.6.3.6 Repeat Condition (^)
The repeat condition is used to repeat the application of the AND (&), ORDERED (<) or adjacent operators. The following table illustrates the behavior of each repeat operator:
{circumflex over (+)} Operand
&^ Operand
<^ Operand
^ Operand
Note that repeat condition cannot be applied to OR and COMBO conditions conceptually.
5.6.4 Tag Condition (<tag: >operand):
Tags claim(s) made by an operand. The tags may be accessed later by the check tag condition. Tag is used to classify claims. Classifying claims allows a policy to know if the claim belongs to it or not.
Tag Condition
Using tags and check tags means that an agent has to be aware of policies of another agent (which could be a policy of an agent which is not an immediate down chain). This is against the agent oriented programming style where an agent should not care about the policies of another agent and should not be aware of any agent other than its immediate down chains. Therefore tags and check tags should be avoided if possible. There is usually a better way to write the policies or configure the agent network to avoid the usage of tags.
0.5.6.4.1 Check Tag Condition (<check tag:> operand):
Filters out all claims made by an operand that does not have a specific tag.
Check Tag Condition
Now that the claim is tagged the CINEMA agent knows which policy in MOVIE agent made the claims.
Using tags and check tags means that an agent has to be aware of policies of another agent (which could be a policy of an agent which is not an immediate down chain). This is against the agent oriented programming style where an agent should not care about the policies of another agent and should not be aware of any agent other than its immediate down chains. Therefore tags and check tags should be avoided if possible. There is usually a better way to write the policies or configure the agent network to avoid the usage of tags.
5.6.5 Binary Conditions
Binary condition merges claims made by two operands at the left and the right of a binary operator.
5.6.5.1 OR Condition (operand1|operand2):
Will apply only if at least one of the left or right operands has claims.
| condition
AND Condition
The AND condition will apply only to those claims that have no loose connections.
AND Condition on Claims with Loose Connections
Will apply only if both left and right operands have claims and the part of the input claimed by the left operand should come before the part of input claimed by right operand.
ORDERED Condition
The ORDERED condition will apply only to those claims that have no loose connections.
5.6.5.4 ADJACENT Condition (operand1 operand2):
Will apply only if both left and right operands have claims, and the left operand claim appears just before (adjacent to) the right operands claim.
The claims made by left and right operands are merged, the resulting claim will be accepted only if the adjacency score of the merged claim is 0.
ADJACENT Condition
The ADJACENT condition will apply only to those claims that have no loose connections.
5.6.5.5 COMBO Condition (operand1, operand2):
Will try to join the left and right operands to make all combinations of ambiguous or non-ambiguous claims.
COMBO Condition
Claims may not be merged together using a combo condition if the merge would cause ambiguity and one claim has a higher priority or a better connection.
When Priority Prevents Ambiguity
A better connection is defined to be based on the weight of the worst operator or operand used in a claim. The operators in order of weight are: adjacent, <,&. All operands in a claim have the same weight as the adjacent operator except for operands coming from the inexact matches of a database agent or a variable condition which have a weight worse than & and better than the combo (that weight is shown in the claim view as an INEXACT or INEXACT or ˜).
When Connection Prevents Ambiguity
Note that the number of operators will not make any difference here:
When Connection Does not Prevent Ambiguity
When two claims are merged using the combo condition (and similarly the recursive, +, condition) then the resulting claim will have a loose connection. Claims with loose connections will fail to merg to other claims using the grammatical operators (such as &, <and adjacent).
Incorrect Usage of Combo Condition
The adjacency score of a claim made by a combo condition is not calculated directly from the focus of the claim (see adjacency score in Claim section). Instead it is calculated to be the sum of the adjacency scores of the sub-claims. For example, if P1 claims ‘cat’ and ‘mouse’ on the input ‘cat dog mouse’ and P2 claims ‘dog’, the adjacency score of (P1, P2) will be 1, whereas the adjacency score of (P1 & P2) will be 0. If P1 claims ‘cat’ on the input ‘cat and dog’ and P2 claims ‘dog’, the adjacency score of (P1,P2) will be 0, whereas the adjacency score of (P1 & P2) will be 1.
Recommended usage of combo operator is only in the catch policy (described later in the reference).
6 Actions
Actions transfers a claim to a standard format (e.g. an object containing XML)
6.1 Action types:
6.1.1 Action:
The action that can be carried out unambiguously. The fields are: Delegate To; Execute; Explain; and Ask.
Ations
The action that will be carried out when there is an ambiguity in the claim. This action item is only used to delegate actuation to the overlapping sub claims that have caused the ambiguity. The sub claims, which caused the ambiguity, would be actuated normally and their actuations would be put together to make the ambiguity choices.
For example lets say the TV and VCR policies would have an overlapping claim that has been put together by HOME_ENTERTAINMENT policy:
Ambiguity
When the system receives the input: ‘on’. The HOME_ENTERTAINMENT claim will then be ambiguous (as the claims made by TV and VCR would overlap). So the actuation made by the HOME_ENTERTAINMENT would be based on actuations made by TV and VCR policies. The actuation would be a multi choice menu. The menu prompt would be the made by putting together the explain actions of the TV and VCR actuations, and the menu items would be the titles of TV and VCR policies.
The explain field is now being deprecated. Instead the execute field will replace the explain field (when it is not provided):
Ambiguity using Execute Field
The idea is that a scripting language would then take the interaction and make the proper prompt.
There are situations where there could be more than one questions asked for an ambiguity. For example the input bass in the network of
More than One Ambiguity
Known Issue:
There are network patterns that might lead to a too ambiguous situation. The following example demonstrates this situation. (See
Too Ambiguous Error
6.1.3 Unknown Action (Deprecated):
The action that will be carried out if the claim has unknown (there are missing information in the input). The same four fields are available.
Each field in the action forms (e.g. execute, explain, ask and choice) is created using variety of building blocks. When actuated each building block generates an output. These outputs would be put together to make the final action. Building blocks could be:
6.2.1 Strings
Outputs any information entered in quotes.
String Action Block
6.2.2 Star (*)
Outputs which part of the input was claimed by a policy.
Star Action Block
6.2.3 Variable (?)
Shows which part of the input was marked as a variable in a claim. The variable action corresponds to the variable condition in the policy with the same name.
Variable Action Block
It is recommended to always use names with variables. However this is how multiple unnamed variables are handled:
Not Recommended Usage
Note that variable trims the leading and trailing delimiters, but other delimiters are considered to be part of the variable. Multiple variables are trimmed after they are combined.
Variable Trimmings
6.2.4 Policy Reference
Used as a reference to an action part of another policy.
Policy Reference Action Block
6.2.5 Agent Reference
Used when the action part of another agent should be used to build this element.
Agent Reference Action Block
6.2.6 Set Message (Set (Agent, Property, Key; Value))
The condition, set (agent, property, key; value), will cause the agent to sends a message to set a property in another agent. There are two types of properties that may be accessed through messaging:
c. Data property (basic objects)
d. Data store property (collection objects: hash tables, vectors, . . . )
Each agent must allow access to its data property by declaring it as a valid data property. The methods that should be sub-classed for this purpose are summarized in the following table:
All AAOSA agents have a STATE property that could be set (STATE is a basic property).
The parameters of a set message, set (agent, property, key; value), are:
Agent: The agent address that its property is to be set. This parameter is optional. If omitted then an agent will “get” its own property.
Property: The name of the property to be set.
Key: The key to the data store property (as a string). This parameter is optional. If omitted then an agent will “get” a basic property.
Value: The value that the property should be set to (as a string).
Set Action Block.
Sends a get message to an agent, and shows the value replied by that agent. There are two types of properties that may be accessed through messaging:
e. Data property (basic objects)
f. Data store property (collection objects: hash tables, vectors, . . . )
Each agent must allow access to its data property by declaring it as a valid data property. The methods that should be sub-classed for this purpose are summarized in the following table:
All AAOSA agents have a STATE property (STATE is a basic property).
The parameters of a get message, set (agent, property, key; value), are:
Agent: The agent address that it's property is to be set. This parameter is optional. If omitted then an agent will “get” its own property.
Property: The name of the property to be set.
Key: The key to the data store property (as a string). This parameter is optional. If omitted then an agent will “get” a basic property.
Get Action Block.
Whenever the action part of a policy is left empty a default delegation would be used. By default actions are delegated to policies responsible for making the sub claims. That is the policy:
The default delegation could be overridden by filling the action part. For example the following policy:
Each policy can make an actuation by applying the action part to the claim it made. Actuation may be built by putting together other actuations (just like claims). Each actuation will have four arms: execute, explain, ask, and choice. Each arm will contain a list of strings or pointers to other actuations.
There is a difference when an actuation is converted to a string if the building blocks of the actuation are listed in one field or different fields. When building blocks are listed together there would be no space between each block that is converted to a string.
Actuation Example
When building blocks are listed in different fields there would be a space inserted between each block that is converted to a string.
Actuation.
7 Putting it all Together
The agents are normally composed of 3 types of policies:
7.1 Tokens:
The condition of these policies has no reference to any other agent. The policies are made using binary and unary operators on token conditions, file terminals or database terminals.
7.2 Grammars
The condition of these policies makes grammatical relationship between the policies in this agent and its down chain agents. These grammatical relationships are made by using &, |, <, optional and adjacent operators. All that can be part of one command should be combined using the &, <or adjacent operators.
7.3 Catch Policy
The catch policy of an agent is used to make the claims that no policies were written to deal with. That includes different combination of commands and ambiguities that may occur. The catchall policy includes a combo of references to all other policies and down chain agents of that agent followed by a + operator. A | (or) condition should be used instead of a combo between any two policies or down chain agents which should never make ambiguities. For example, assume agents A, B and C are all downchain of Top agent.
TOP agent policies:
P1: . . .
P2: . . .
. . .
CATCH_ALL: (P1, P2, . . . , A, B, C)+
The following is an example of how a user interface could be built for a store where books and toy in different colors could be bought.
8. Best Practices Guidelines for Agent Network Design
1) Always include comments in your policies briefly describing why they are there and what they do. In general an observer should be able to understand the logic of why you have coded your agent the way you have. If it is too complex to understand, it is very likely that it needs some cleaning up.
2) If there are more than 6 policies in an agent rethink using a single agent for all these policies. It may also be that the agent has too big a fan-out.
3) Avoid too many agents reporting to a single agent (larger than 6 fan-out). Add agents to group down-chains into sub networks. Make sure the groupings correlate with the semantics of the application domain. Just as in menu structures, a big fan out is untidy and in our case they can also result in inefficient processing of policies that include operators like ^ or *.
Categorization is possible and quite natural. After all, this is how our minds work to enhance our memory. It is much harder to memorize 16 down chains for one agent than it is 4, each of which lead to another.
We should use a domain expert in this case to identify the categorization.
The merits of limiting the fan out can be summarized as:
As for the fan out, if there are many agents down-chain to one, it is very likely that there does exist a categorization for these concepts in the domain expert's lingo that we are missing and we should probably cover. If this is the case, then recategorizing and decreasing the fan out based on the domain classifications and the resulting modularity will make those categories more readily reusable, and the interactions with the application more manageable for the end users. It will also make the policies in the top agent more readable and tidy. This added modularity may also help the efficiency of the application where operators such as “&” or other firm operators are used between all down-chains. This is because it reduces the number of claims the up-chain agent to the top node will be receiving when a policy containing operators such as the “&” of the down chains fires.
4) Avoid creating agents that do not represent the semantics of the application.
5) Start each agents list of policies with policies that pick the tokens associated with this agent. Then follow with policies that describe the relationships. At the end, include catch-all policies.
TOKENS: The condition of these policies has no reference to any other agent. The policies are made using binary and unary operators on token conditions, file terminals or database terminals.
RELATIONS: The condition of these policies describe the relationships between the policies in this agent and its down chain agents. These grammatical relationships are made by using operators such as &, |, <, optional and adjacent. All that can be part of one command should be combined using these operators.
CATCHALLS: The catchall policy of an agent is used to make the claims that no policies were written to deal with. That includes different combination of commands and ambiguities that may occur. The catchall policy includes a combo of references to all other policies and down chain agents of that agent followed by a + operator. A | (or) condition should be used instead of a combo between any two policies or down chain agents which should never make ambiguities.
6) Avoid using catch-alls extensively and try to cover them in Relations policies. For example try using the repeat operator (^) more often.
7) Try not to repeat all of the contents of another policy in the following policies. It is inefficient and untidy:
8) Any policy on its own may make a claim. Do not have policies that may claim lone words that are not relevant to the agent:
DUMMY_TOKEN: ‘the’
In this case an agent, THE, should be created which claims ‘the’ but is never delegated to or referred to without constraining conditions around it.
9) Avoid using tags. Using “tags” and “check tags” mean that an agent has to be aware of policies of another agent (which could be a policy of an agent that is not an immediate down chain). This is against the agent oriented design principle where an agent should not care about the policies of another agent and should not be aware of any agent other than its immediate down chains. Therefore “tags” and “check tags” should be avoided if possible. There is usually a better way to write the policies or configure the agent network to avoid the usage of tags.
10) Avoid using <exists>
RELATIONS: <exists> ‘token’
When using <exists>, an agent is checking against a part of the input that it is not going to claim. Therefore the agent must be aware of parts of the input that are possibly another agent's responsibility. This is against the agent oriented design principle where an agent should only care about its own domain and not worry about other domains. Therefore <exists> should always be avoided if possible. There is usually a better way to write the policies or configure the agent network to avoid the usage of <exists>.
There are cases where using <exists> is appropriate as in the example below:
In this example, we have a top level FIND agent. Below FIND there is a FILETYPE agent and a FOLDER agent. FILETYPE has down-chain agents that recognize specifications for different kinds of files; FOLDER uses down-chain agents to identify specs for starting directories.
Now imagine a request like “java in web”. Both “java” and “web” are valid file types; both are valid directory nanes. What we wanted to do in FILETYPE is say that if we see a file spec followed by the word ‘in’, to see that as a stronger claim than one without it. Similarly, we want FOLDER to use ‘in’ to indicate that what follows may be a directory spec.
Clearly, we can't have both agents claiming ‘in’. But ‘in’ is important for both. So we use <exists> to give the policy with ‘in’ a higher priority.
11) Avoid policies that may make a null claim:
TOKENS: [‘a’ ]
NULLTOKENS: [‘a’ ] I [‘b’ ]
INTERESTING_TOKENS: [‘a’ & ‘b’ ]
NOTOKENS: <exists>% ‘a’
WOWTOKENS: [‘a’] & <exists> ‘b’
OWTOKENS: <exists> (‘a’ & ‘b’)
9 Precedence table
The OPAL language guarantees that the operands of operators appear to be evaluated in a specific evaluation order, namely, from left to right.
10 Learning
A followup answer will be learned only if:
There would be a variable terminal (?) in the condition of the policy.
The agent asking the question would make a claim on the followup.
11 Claim Manipulation
The recursive operator (+) and most binary operators (adjacent, &, <,+ and combo) make their claims by merging other claims.
Merging claims:
Two claims C1 and C2 will merge if and only if one of the following conditions would hold:
The following is the BNF notation used to describe the Policy's syntax:
::=Is interpreted as ‘consists of’ or ‘is defined as’.
( )+ Parenthesis followed by a plus sign indicate that the sequence in the parenthesis may be repeated more than one time.
( )* Parenthesis followed by a plus sign indicate that the sequence in the parenthesis may be repeated zero or more times.
˜( ) Parenthesis preceeded by a not sign indicate that all sequences except those in the parenthesis are legal.
[ ] Square Brackets State that the Sequence in the Brackets is Optional.
< > Names embedded in angle brackets are syntactic elements such as <integers>, <names> etc. All syntactic names will be defined i.e. they will appear on the left side of the ‘::=’ symbol in a grammar rule.
“ ” Characters embedded in double quotes are keywords or characters.
- A dash between two characters defines a range of characters.
For example “0”- “3” is “0” |“1” |“2” |“3”.
| A vertical bar is read ‘or’ and is used to separate alternatives.
Whenever a BNF notation is used as a keyword in the grammar it is preceded by an escape character: ‘\’.
12.2 Policy's BNF notation
Here is a BNF notation of the policy's grammar.
This application claims the benefit of U.S. Provisional Application No. 60/342,231, filed 20 Dec. 2001, which is incorporated herein by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5500920 | Kupiec | Mar 1996 | A |
| 6144989 | Hodjat et al. | Nov 2000 | A |
| 6785651 | Wang | Aug 2004 | B1 |
| 6859451 | Pasternack et al. | Feb 2005 | B1 |
| 7027975 | Pazandak et al. | Apr 2006 | B1 |
| 7137126 | Coffman et al. | Nov 2006 | B1 |
| Number | Date | Country | |
|---|---|---|---|
| 60342231 | Dec 2001 | US |
