ADT is a set of utilities for guiding a programmer through the steps required for defining and adding new agents to SRI's Open Agent Architecture (OAA). Currently, the ADT contains three separate utilities:
In this user's manual, we shall provide descriptions of each of these tools, along with information about systems accessed by ADT (Figure 1).
Figure 1: The Main ADT Screen
2. PROACT: Programmer's Agent Construction ToolPROACT is a general-purpose tool for adding new agents into the OAA. New agents can be written using one of several programming languages supported by the OAA agent libraries.
PROACT is used to construct high-level definitions and documentation, in standard formats, that are required by every agent in the OAA. Each agent needs to have:
PROACT helps the programmer define each of the above elements for a new agent in three steps:
After performing these steps, the programmer is next responsible for agent knowledge coding. Once an agent has been constructed, natural language vocabulary may be added for the agent using LEAP, and the agent can be included into agent-based applications using PROJECT.
When a client agent connects to a Facilitator, it must inform the Facilitator of the services and data that it provides; this information is expressed using the Interagent Communication Language (ICL). When a request for information or for a service is made by the user or by an agent, the Facilitator that each request into subtasks and parcels them out to agents that can solve them. The Facilitator maintains the flow of communication and coordinates distributed computation among its client agents.
The ICL Definition Editor (also called the Goal Editor) is used to create descriptions of an agent's capabilities in ICL; these descriptions are called ICL expressions, goals, or solvables. Each ICL expression is composed of a functional identifier and a number of argument terms. Each of these argument terms, in the style of Prolog terms, may include nested subterms, and also may be either fully or partially instantiated. The Facilitator uses Prolog-style unification with the ICL description when selecting an agent (or agents) to handle a request.
The ICL Definition Editor is made up of a listbox enumerating existing ICL expressions, an input field where the user may enter a new expression, and command buttons to perform the actions: ``Add New Expression'', ``Delete Expression'', ``Replace Expression'', and ``Document ICL Expression''.
The so-called Goals List enumerates all ICL expressions for the currently selected agent, along with a picture (icon) indicating the documentation state for each expression:
This icon indicates that the ICL expression has not yet been
documented. This provides a reminder to provide documentation so that
other agent developers will be able to have access to the agent(s)
being created.
This icon indicates that (at least some) documentation has been
entered for the ICL expression.
To add a new ICL expression, enter it in ICL syntax (see below) in the input field labeled ICL Expression, and then click on the Add button. The expression will be added to the Goals List.
To delete an ICL expression for an agent, select the expression in the Goals List and click on the Delete button.
To modify an existing ICL expression, double click on it in the Goal List: this will place a copy of the expression in the Input Field labeled "ICL Expression." You may now make modifications to the goal. To record your changes, click on the Replace button.
To document an existing ICL expression, choose the expression to document in the ICL List and click on the Document button. This will call the ICL Documentation Editor for the expression.
ICL expressions should be written using Prolog syntax: The general form for an ICL expression is
icl_id(<arg1>, <arg2>, ... <argn>),where arguments may be any valid Prolog expression.
Person.
[item1,item2,item3].
'Gowang Lo Lee'.
Definitions of agent capabilities are shared across modules in the ADT; for instance, LEAP, the linguistic acquisition module, allows an agent programmer to link linguistic information to a given ICL expression.
Once agent capabilities have been defined by the user, PROACT encourages the author (agent programmer) to create documentation describing the agent. PROACT enforces a consistent documentation style among agents and, at the same time, makes the documentation available to potential users at remote sites. PROACT generates and maintains documentation in hypertext markup language (HTML) form, accessible via browsers across the World Wide Web (WWW).
For each agent, documentation should be recorded concerning the following attributes :
After documentation has been entered for an agent, the Agent Documentation Editor can automatically generate an HTML version of the documentation, thus making it readable from remote locations.
The Generate HTML button will automatically create an HTML version of the documentation entered in Agent Documentation Editors. This text can be edited in HTML form by your favorite HTML Editor, defined in the Executables Options window, by clicking on the Edit HTML button. The HTML documentation can also be viewed in a local web browser through the View HTML button. Finally, Harvest gatherers (see Section 7.5) can be instructed to update their indexes with the new information by using the Publish button.
The ICL Documentation Editor is used to enter documentation for a single ICL expression. An agent programmer should enter a description of the ICL expression, choose one of the possible return conditions (unused, failure/success, or nondeterministic multiple solutions), and then document each of the arguments used by the ICL expression. The list of parameters are displayed in a list box, along with a picture (icon) indicating the documentation state for each parameter:
This icon indicates that the parameter has not yet been documented.
This icon indicates that (at least some) documentation has
been entered for an ICL parameter.
Given the agent's name, target programming language, and list of agent capabilities, PROACT can automatically generate the application code template for the agent. While this feature is of particular use to novice agent programmers who may not be aware of all code declarations required to create a new agent, it is also a time-saver for experienced agent programmers. Code generation is also useful when porting an existing agent to another programming language.
Currently, code template generation is provided for four programming languages: Prolog, C, Visual Basic and Delphi. For the selected language, PROACT creates a source code file containing an agent documentation header, include statements for required agent libraries, empty stubs for all user-definable entry points, (such as init_app() and idle()), code to register any DCG-NL vocabulary with the Facilitator, and do_event templates for each of the agent's capabilities. In addition, for a Visual Basic agent, PROACT will create a package directory, a project definition file containing references to shared library files, and all necessary basic and form definition files.
3. LEAP: Linguistic Expertise Acquisition ProgramLEAP, the Linguistic Expertise Acquisition Program, is a program that facilitates the use of natural language by various agents in the OAA. It obtains information from the OAA developer about the capabilities of agents, and about the words and phrases that might be used in commands to those agents. This information is then used to update the linguistic knowledge base of one or more natural language processing agents.
To date, LEAP has been used to update the linguistic knowledge bases for two natural language processing agents and one speech recognition agent: Agent Gemini, the DCG-NL natural language parser, and the Corona Speech Recognition system.
Because of its power and flexibility, and because of the sophistication of its knowledge base, Agent Gemini was selected as the primary model from which LEAP's capabilities, user interface, and representational requirements were derived. (The requirements for supporting the DCG-NL natural language parser and the Speech Recognition system have been relatively modest by comparison.) For this reason, LEAP's structure and interface reflect, in many ways, the approach to natural language processing that is embodied in Agent Gemini. However, because this approach is representative of an important class of natural language processing programs, it is anticipated that LEAP will be useful as a framework for building knowledge acquisition tools for use with other natural language processing agents.
LEAP's major goals are:
LEAP can be run by itself or as an agent in OAA. However, the standalone version provides only a very primitive text-based user interface. The agent version provides a graphical user interface, which runs on a PC.
Nearly all Gemini rules refer to classes defined in the class hierarchy. The class hierarchy is a tree that contains what Gemini recognizes as the primitive conceptual categories to which entities may belong, and expresses the superclass and subclass relationships between them. Higher levels of the hierarchy contain the more domain-independent classes, whereas lower levels tend to be more domain-specific.
For example, the class agent, a class likely to be near the root of the hierarchy, may have subclasses human-agent and software-agent. Further down in the hierarchy, under human-agent, there could be a class employee which is broken into subclasses manager, salesperson, researcher, and programmer, reflecting the personnel structure of a particular organization.
The class hierarchy editor displays the tree structure in a list box window, using different levels of indentation to indicate the class/subclass relationships, in the same way that directory hierarchies are commonly displayed by file manager applications. In the class hierarchy window, class names appear under the name of their superclass, and indented with respect to the superclass. For each class name displayed, a toggle icon is available to control whether or not its subclasses appear.
Several commands are provided, which operate on the class hierarchy:
The ICL-NL Linker (also called the Goal Linker) acquires the knowledge needed to be able to include a new ICL expression (goal, or solvable) in the logical query forms that Gemini generates. Introducing a goal to LEAP generally involves three steps:
Step 3 can be done using drag-and-drop operations. First, use the mouse to select a goal argument or functor to be linked, in the ICL-NL Linker window. Then go to the Class Editor, select the desired class, and drag it to the box just under the selected argument or functor.
Once you have entered class selections for the parameters of an ICL expression, record these selections by clicking on the Add button. The link icon in the Goal List will update accordingly.
Indicates that the ICL expression is not documented and has not yet
been linked to natural language class definitions. It is recommended
that all ICL expressions be documented, and that ICL-NL links be
created for all predicates to be referenced by natural language
statements.
Both documentation and an ICL-NL link have been entered
for the ICL expression.
Once an agent has been created using PROACT and connected to the agent system, the Extract Values button can be used to add natural language vocabulary for domain values produced by an ICL expression. For instance, for an ICL expression representing an employee database entity, you might want to extract the name of each employee in the database and add it as a word in the natural language vocabulary. This would allow queries such as
"What is Cheyer's telephone number?"
To extract words from an ICL expression, select the expression in the ICL list and click on the Extract Values button. LEAP will ask which field values to extract: enter the field values in the form of a Prolog list. For instance, to extract first and last names from the following ICL expression, enter "[2, 3]" (representing the second and third parameter fields in the ICL expression) when prompted:
employee(ID, Last, First, PhoneNum, Title, Office).
The classification of a goal into entity, relationship, or action helps LEAP create the most useful linguistic rules for mapping expressions to calls to that goal. The concepts of entity and relationship are essentially the same as are used in database design methods; action has been added to describe goals whose principal purpose is accomplishing some activity.
The following descriptions should provide enough guidance to allow for the optimal classification of most goals.
An entity goal is one whose primary purpose is retrieving information about objects of some class that is known to Gemini. For example, if "employee" is a class in Gemini's class hierarchy, a goal that provides information about employees, such as
employee(id_number, first_name, last_name, office_number, extension)
would be an entity goal. The class "employee" is known as the subject of the goal. In order to introduce a goal as an entity goal, it is necessary to have a class in the class hierarchy that corresponds to the functor of the goal.
Entity goals generally do not have any effect on their environment; they merely retrieve information.
A relationship goal is one whose central meaning is the expression of a relationship between two classes of objects. For example, given classes "employee_number" and "project_number", the goal
project_member(project_number, employee_number)
expresses the relationship between projects and the employees that work on those projects. Like entity goals, relationship goals have no effect on their environment; they merely retrieve information. Unlike entity goals, however, it is not necessary to find a class in the class hierarchy that corresponds to the functor of a relationship goal.
Relationship goals can have additional arguments that can make them look like entity goals. For example, the goal
project_member(project_number, employee_number, date_of_joining, tasks)
provides additional information as to when the employee joined the project, and what his or her project tasks are. Thus, this goal provides more than just the bare relationship between employees and projects. However, the essential characteristics of a relationship goal are still present: it expresses a relationship, and the functor does not correspond to any class of objects or actions. (The added information in this case is considered as attributes of the relationship, rather than attributes of any particular class, making it appropriate that it be included as part of the relationship goal.)
An action goal is one whose primary purpose is to cause some action or event to occur. Some examples are:
Note that some action goals, such as add_employee, may have the effect of updating a database. These should be seen as action goals rather than entity goals. A goal that both retrieves information and has some effect on the environment should thus be classified as an action goal.
Action goals, like entity goals, must have a class in the class hierarchy that corresponds to their functor. Such classes are thought of as classes of events or actions, and are sometimes a little less intuitive than are classes of objects. These classes will normally appear in the class hierarchy under the class "domain_event," and their class names usually end in "ing". So, for example, the class for functor send_mail might be "sending" or "mailing," that for notify might be "notifying," and that for make_appointment and add_employee could be "updating" (because make_appointment updates a calendar and add_employee updates a database). "Sending" is thought of as the class of all sending events, "notifying" as the class of all notification events, and so forth.
Any goal whose primary purpose is to achieve some action or event, or accomplish some change in the environment, should be classified as an action goal, and an appropriate action class should be created for it.
Goals whose primary purpose is to retrieve information should be evaluated as to whether the information is primarily about some class of objects, or primarily about the relationship between two or more classes. In the first case, it should be possible to identify a class of objects that corresponds to the functor, and the goal should be categorized as an entity goal. In the case of relationships, it is not necessary to identify a class that corresponds to the functor.
Word Wizard acquires the knowledge that Gemini needs to understand sentences containing a particular word or phrase. It acquires new knowledge by asking a series of simple questions that do not require any expert knowledge about Gemini. From the answers to these questions, each wizard is able to produce the detailed data structures needed by Gemini.
The Word Wizard operates by obtaining a categorization of a new word and gradually refining the categorization through a series of questions. Each refinement of category, in turn, determines the subsequent questions to be asked. Each question asked is used either to
Once the final categorization is determined, LEAP then has all the information it needs to update Gemini's rules files. Addition of a new word or goal typically results in a large number of changes (perhaps 10 to 25 detailed updates) to anywhere from three to nine files of different rules. These updates are transparent to the user (except for tracing messages, if they're enabled); he or she sees only the command structure provided by the user interface and the common-sense questions asked by LEAP.
To add a new word in the Word Wizard Editor, type the new word in the appropriate field, choose the word category (verb, noun, adjective, or adverb) and then click on the Add button. LEAP will ask a number of common-sense questions and then add the new vocabulary word to the word list for the agent. A word can also be deleted or searched for in the Word Wizard Editor.
The ADT can currently interface with three linguistic systems:
For DCG-NL, vocabulary definitions can either be produced during the code generation phase of PROACT or be extracted from the Natural Language Generation dialog box in LEAP. If you are creating a new agent, producing definitions is probably the best solution. To add DCG-NL vocabulary for an existing agent, you must use the second option: in this case, a source code file containing only DCG-NL definitions will be created for inclusion into the existing agent code.
For Gemini, all changes are recorded locally during interaction with LEAP's Class Editor, ICL-NL Linker, and Word Wizard. If Gemini is selected from the Natural Language Generation window, the local changes will be saved to disk in the requested directory, and the data files produced can be used by Agent Gemini.
To generate data files for use with the Corona system, a project must be selected. The Generate command will create a grammar file containing vocabulary from all agents in the currently selected project. The resulting file will be displayed in the Speech Recognition Editor, where the user can enter pronunciations for all words unknown to Corona's dictionary.
The Speech Recognition Editor is divided into two parts:
In the first part, the user can scroll through the most recently generated grammar file in a read-only display area.
The second part of the form is focused on allowing the user to enter pronunciations for words that don't yet exist in the Corona dictionary. The user is presented with a list of words that require pronunciations, an area for entering the pronunciation for a given word, and an input area that lets the user call up pronunciations for similar sounding words, which can be cut and pasted to construct the new pronunciation. For instance, to add a new pronunciation for the word "widget," the pronunciation for "fidget" can be retrieved from the dictionary, and modified to start with a "w" instead of an "f." Pronunciations for words not defined in Corona's built-in dictionary will be added to a file "AgentName.MISSING", which can be included with the generated grammar file to build a Corona system.
Pronunciations must be defined using the Corona Phone Set.
4. PROJECT: Managing Agent ConfigurationsThe PROJECT tool is used to define particular configuration of agents for a given application domain.
The programmer can construct an agent project by adding members to the conference table using the Project Editor, selecting participants from repositories of available agents, and then tailoring agent parameters to the task at hand. Once a configuration has been defined, the PROJECT tool can generate definition files to interface with the Start-It tool, a process-monitoring application whose aim is to assure users that required agents are loaded and available when needed.
The main screen of the Project provides the following commands:
The Project Editor (Figure 2) is used to create configurations of agents for an application domain, and to edit parameters for the participating agent.
Figure 2: Screen Showing Project Parameters
Add agents by dragging them from the agent repository toolbar to an empty (green) slot at the conference table.
This command allows a user to define a new agent, add it to the currently loaded agent repository, and then select it as the current working agent.
When defining a new agent, the user must give at least an agent name and its filename. The user can also select a picture to represent the agent in the visual icon list of the agent repository toolbar, and can enter information about the agent's author and version number.
This command removes the currently selected agent from the currently selected agent repository. ADT will also prompt the user, asking whether they would like to remove all of the agent's files from the disk as well.
The Load Agent Repository command allows the user to choose a repository definition file (<filename.tem>) to be loaded into the agent repository toolbar. From here, an agent can be selected as the current working agent, or agents can be added through drag and drop to the project.
This command will save the currently loaded agent repository displayed by the agent repository toolbar into a repository definition file (<filename.tem>).
Agents not created by the ADT can be imported into the ADT for documentation management, for porting to another programming language, for adding linguistic definitions, or for inclusion into agent projects. In order to create an ADT representation of an existing agent, first use the New Agent command to define agent information and picture, and then use the Import ICL command to load the existing agent's ICL definitions into the ADT agent definition.
ICL expressions can be imported either from Prolog source code or from an agent currently connected to the local Facilitator. The facilitator option is often more useful, as the technique will work for an agent written in any programming language.
To import all ICL expression from Prolog source code, choose this command from the File|Import menu and specify the path for the agent file. To import expressions from the Facilitator, connect the target agent to the Facilitator, select the File|Import|ICL from running agent command, and then enter the agent's name when prompted.
The ADT uses a model where only one agent is currently being edited at a time. A visual icon representing the currently selected agent (e-mail in Figure 2) is displayed at all times in the lower left corner of the main ADT window. By double clicking on the icon, a user can edit definition variables (agent name, author, version, and so on) for the agent.
To set an agent as the current agent, choose the agent from the list of icons displayed by the agent repository toolbar, then drag and drop it onto the panel indicating the currently selected agent:
All commands in PROACT and LEAP work on the currently selected agent.
The Agent Repository Toolbar (Figure 3) contains visual representations of all agents in the currently loaded Agent Repository. The icons displayed, using drag and drop action, can be used to set the current working agent or to add agents to the currently loaded agent project. Clicking on the "Msg History" box below the scroll button will show at least the last 100 messages to appear in the Status Bar of the toolbar.
Figure 3: Example of an Agent Repository Tool Bar
The Executables dialog box allows the user to specify full path names to auxiliary executables called from the Agent Development Tools. These include:
Information about the user's name, e-mail address, and URL are recorded in the User Information dialog box. This information is used during HTML generation.
The Directories dialog box allows the user to specify full path names for directories used by ADT. These include:
The Preferences dialog box allows the user to configure various parameters used by ADT:
Based loosely on Schwartz's FLiPSiDE system, the OAA is a blackboard-style framework allowing individual software client agents to communicate by means of goals posted on a blackboard controlled by a server process called the Facilitator. The Facilitator stores data that is global to the agents, identifies agents that can achieve various goals, and schedules and maintains the flow of communication during distributed computation. All communication between client agents must pass through the Facilitator. We have chosen an extension of Prolog as the interagent communication language (ICL) to take advantage of unification and backtracking when queries are posted. The primary job of the Facilitator is to decompose the ICL expressions and route them to agents that have indicated a capability of resolving them. In this manner, agents can communicate in an undirected fashion, with the Facilitator acting as a broker. Communication can also take place in a directed mode if the originating agent specifies the identity of a target agent.
An agent consists of an ICL metalayer above a knowledge layer written in Prolog, C, or Visual Basic. The knowledge layer, in turn, may lie on top of existing standalone applications (e.g., mailers, calendar programs, databases, natural language systems). The knowledge layer can access the functionality of the underlying application through the manipulation of data files, such as mail spool, or calendar files, through calls to an application programming interface (API). Useful APIs include MAPI, TAPI, and ODBC in Microsoft Windows. The API calls are made through scripting languages, or through interpretation of an operating system's message events (Apple Events or Microsoft Windows Messages).
Individual agents can respond to requests for information, can perform actions for the user or another agent, and can install triggers to monitor whether a condition is satisfied. Triggers may make reference to blackboard messages; for example:
"when <remote computation> is completed, <perform action>"temporal events:
"every Thursday at five o'clock, <perform action>"data values:
"if the status of flight UA123 changes, <perform action>"or agent-specific test conditions:
"when mail arrives from Bob, <perform action>".
The creation of new agents is facilitated by a client library that furnishes common functionalities used by all agents. This library provides methods for defining an agent's capabilities, natural language vocabulary, agent-specific public data, and polling status. It also allows an agent to read and write information in a global information storage area and to post requests to the Facilitator, to a specific agent, or to an entire population of agents. When attempting to resolve a goal, an agent may find itself lacking certain necessary information. If so, the agent can either post a subrequest to a specific agent or, as is generally recommended, request the information from the Facilitator. In the latter case, all agents who can contribute to the search will send solutions to the Facilitator for routing to the originator of the request. The agent initiating the search may choose to wait until all answers have been returned before continuing processing, or the agent may set a trigger so that when the remote computation is finished, a notification message will be sent that will interrupt local work in progress. Using this undirected approach to information retrieval permits a plug-and-play style of interaction: if a smarter agent is later added to the network, performance of the overall system improves without modification of individual pieces.
The Corona System is a large-vocabulary, speaker-independent, continuous speech recognition system that employs advanced digital signal processing and statistical pattern-recognition technology to provide high accuracy and fast response. The Corona system has been designed to maintain this accuracy in spite of variations in dialect, microphones, telephones, and background noise.
An application developer's toolkit permits a user to define a finite-state grammar to guide recognition. The grammar can be given any number of start categories, thereby allowing for dynamic choosing of a subgrammar as a function of the context in which the user is speaking. The Corona system has a vocabulary of (more than 160,000 English words that the user can extend by defining phonetic pronunciation information.
The Corona system has already been integrated into the OAA and provides speech-recognition technology for all prototype applications based on the OAA. However, one objective of the ADT is to simplify the process of adding speech definitions for new agents. The LEAP tool helps the user to incorporate new vocabulary words into the finite-state grammar controlling recognition and to specify phonetic encoding for words outside of the Corona system's standard dictionary.
Most demonstrations currently implemented in OAA use DCG-NL as the natural language component. DCG-NL is a simple natural language parser written in Prolog, using the Definite Clause Grammar (DCG) methodology. DCG-NL, although simple, possesses several desirable qualities:
Although DCG-NL is very easy to use, it does not handle ambiguous or syntactically inaccurate sentences robustly . To overcome this and other difficulties, the Gemini natural language system has been integrated into the OAA.
Gemini, an ongoing effort under the auspices of ARPA's Spoken Language Systems program, is a natural language understanding system developed for creating spoken-language interfaces to databases. Gemini features
Gemini also includes novel components for recognizing and correcting grammatical disfluencies, and for handling parse preferences.
Agent Gemini is the adaptation of Gemini to operate as an agent within the OAA. Prior to the creation of Agent Gemini, Gemini has most often been used as a standalone application which retrieves information from relational databases, in response to a wide range of natural language questions. In the context of the OAA, however, Gemini is used to make calls to agent capabilities, or agent solvables, rather than to relational predicates.
The services of Agent Gemini may be used by any other agent in the OAA environment; this is accomplished through two steps. First, a natural language string is passed to the Gemini solvable convert_to_LF, which returns a logical form. This logical form contains one or more calls to agent-specific functionality, which is made available by the Facilitator agent to which Agent Gemini is connected. To have these solvables executed, the logical form is passed back to Gemini in a call to the Gemini solvable satisfy_LF which interprets the logical form, calling the agent capabilities in the process, and combines the return values into a single value that becomes the return value from satisfy_LF. This two-step style of integration allows an agent to inspect or modify the logical form before requesting its interpretation, or to delay its interpretation altogether. It also allows multiple natural language agents to be deployed in the same OAA environment.
Gemini incorporates a large quantity of domain and linguistic knowledge which is captured in Prolog files. Gemini's knowledge base is roughly divided into two parts: core knowledge and application knowledge. Core knowledge is application-independent information which is fixed as part of Gemini's core language processing engine, whereas application knowledge is modifiable for specific applications and domains. This modifiable knowledge must be updated whenever a new domain is introduced to Gemini, or new words or solvables are added to an existing domain.
Gemini's application knowledge falls into four categories:
These four types of knowledge can be maintained using LEAP.
HARVEST is a set of tools for indexing and searching information stored on the Internet. The Harvest system is based on the notion of Brokers and Gatherers:
Gatherers are processes that start from known locations and follow World Wide Web links and paths, opening and reading all interesting files, and creating an index of the pertinent information contained therein. Gatherers can be set up to make incremental updates of the indexed information on a regular basis.
Brokers use the indexes collected by numerous gatherers and provide a search mechanism for finding information contained on the Internet.
The architecture of Brokers and Gatherers is highly flexible, with many distributed configurations possible.
Start-It is a process-monitoring application developed at SRI International. It is used by ADT to assure that required agents are loaded and available when needed by a particular agent project. Start-It allows a programmer to start or kill processes quickly, to change the host or other parameters for a process, and to monitor whether or not the process is alive and accepting command input.
Start-It is documented in detail in the
OAA Developer's Guide.
One of the goals of LEAP is to acquire the linguistic attributes of newly define words through a question-answer dialog with the user. By asking the user questions presented in an intuitive way, the system can acquire the needed data without calling on an expert linguist.
The current list of questions asked by LEAP is:
Question: Root Name is a request for the root form of a new word. This should be the infinitive form for verbs (the form that follows "to",such as "employ") and the singular form for nouns ("employee"). A root form can be multiple words (for example, a proper name such as Open Agent Architecture). The answer returned to LEAP should always be a single atom.
Question: Word Category is a request for the category of a new word, such as noun, verb, adjective. The user is asked to choose from the categories that are currently supported.
Question: Plural is a request for the plural form of a noun. For example, 'employees' is the plural of 'employee'.
Question: 3rd Person Singular is a request for the 3rd person singular form of the given verb; that is, the present tense form used with proper names or with the pronouns he, she, and it. For example, the 3rd person singular of "fly" is "flies."
Question: Past is a request for the past tense form of the given verb. This is the form used, without any auxiliary verbs, to state that some event occurred in the past. For example, the past tense of "fly" is "flew," as in "He flew to New York last Saturday."
Question: Past Participle is a request for the past participle form of the given verb. This form can easily be determined by using the verb in a sentence with the auxiliary verb "has" or "had," in reference to some past event. For example, the past participle of "fly" is "flown," as in "She has flown to New York."
Question: Present Participle is a request for the present participle form of the given verb. This form can easily be determined by using the verb in a sentence with the auxiliary verb "is," in reference to some ongoing event. For example, the present participle of "work" is "working," as in "She is working on the problem right now."
Question: Noun Subcategory is a request to classify the given noun into one of two types: class_denoting or instance_denoting. A class_denoting noun is one that names a class, whereas an instance_denoting noun is one that names a member of a class. For example, assuming the presence of the class "employee" in the class hierarchy, "worker" and "employee" are class_denoting nouns that might be entered to name that class. An instance_denoting noun would be one that names one particular employee, such as "Cheyer" or "Gowang-Lo Lee." Instance_denoting nouns are nearly always proper names.
Question: Noun Class is a request for the class which a noun denotes, or denotes an instance of. The class must be one that already exists in the class hierarchy. So, if one is entering the new word "worker," and it's a class_denoting noun, the correct class to enter might be "employee". "Employee" would also be correct for the instance_denoting nouns "Adam Cheyer" and "Gowang-Lo Lee."
Question: Verb Subcategory is a request to indicate a subcategory for a verb, that is, a pattern of words that the verb may be used in. The user is asked to choose one pattern from a list of patterns. It is possible that several of the patterns are valid uses for the verb. In that case, the user should select the pattern he or she is most interested in using in natural language input. It is only possible to indicate one pattern at a time; however, a separate New Word command may be used to select a different pattern for the same verb.
Blanks are used in these patterns to stand for nouns that may be used with the verb. Blanks are used because LEAP does not yet know what the appropriate nouns would be (that information will be requested subsequently). In this question, you are asked only to select a pattern; not to fill in the blanks.
The easiest way to answer this question is to examine each of the listed patterns to see if you could fill in some class_denoting noun(s) in the blank(s) so as to construct a valid phrase that you're interested in using. For example, if you are entering the verb "work," you may be presented with the following patterns:
By trying out each pattern, you would probably conclude that 1, 2, and 4 allow for valid phrases:
If a pattern you are interested in using is not presented, LEAP does not now support its use.
Question: Verb Subcategory Classes asks you to fill in the blanks that appear in a verb subcategory pattern you've selected (see Verb Subcategory question, above). Each blank is to be filled in with the name of a class, to indicate the kind of thing that can be used in a phrase with that verb.
For example, if you've just selected
A(n) ________ works for a(n) ________you will want to fill in the classes "employee" and "company."
This assumes that those classes already appear in your class hierarchy. If they don't, create them, using the New Class command, and then fill in the blanks. There's no need to dismiss the question dialog while you create the new classes.
It is important to note that each pattern, once its blanks have been filled in (by the user answering a subsequent question), represents a canonical form, which may actually allow for a variety of different phrases to be used with Gemini. For example, the pattern
An employee works for a companywould allow Gemini to make sense of a simple statement of fact:
Bill Simpson works for IBM.as well as a question:
What company does Gowang-Lo Lee work for?
Question: Position of Prepositional Phrase asks you to judge which of two sentences (both involving a verb and a two prepositional phrases) sounds more natural. The answer is used to help determine the proper classification of the verb.
For example, if you are entering the verb "work," you may be presented with these two sentences:
If you are like most users of English, you will probably feel that (1) is more natural, so you should answer (1). However, different speakers of English may have different intuitions, and there is no right answer. If you are unsure, the best thing to do is to select the default answer.
Question: Passive Form asks you to judge whether the passive use of a verb is acceptable. For example, if you are entering the verb "work" and have selected the pattern
An employee works for a companyin your answers to previous questions, you may be asked whether it is OK to say
A company is worked for by an employee
Most people would find this is to be an unnatural construction,
and so should answer No. Again, however, there is no right answer.
A Corona grammar file uses the GSL format as follows:
LeftHandSide RightHandSide
The LeftHandSide must indicate a nonterminal, which begins with
a capital letter or with "." (indicating a toplevel entry point).
The RightHandSide may contain nonterminals and terminals, as follows:
abc A literal (terminal), a word.
A A nonterminal
( A B C...) A followed by B followed by C
[ A B C...] A or B or C
?A Optionally A
*A Zero or more occurrences of A
+A One or more occurrences of A
Only regular expressions are permitted. To enforce this, the compiler
allows references only to nonterminals that have been declared
previously (higher) in the grammar file.
Corona pronunciation definitions must be made up out of phonemes from the following Table 1.
Vowels aa father ae cat
ah cut ao caught
aw couch ax the
ay side eh bet
er bird ey date
ih dimple iy fleet
ow show oy toy
uh book uw blue
Stop b ball p put
d dice t try
g gate k catch
dx butter
Nasals m mile ng running
n nap
Fricatives v voice f friend
z zebra s sit
dh them th path
ch church jh judge
zh vision sh shield
hh have
Approximants r row l lame
y yes w win, which
Table 1: Corona Pronunciation Definitions