JP5014584B2 - Semantic programming language and language object model - Google Patents

Description

  The present invention relates to a system and method for modeling the semantics (meaning) of natural language. More specifically, the present invention relates to a lexical semantic structure for modeling the content of natural language input.

  A natural language is a language as produced by people (as opposed to a computer language or other artificial language) that contains all idioms, assumptions, and implications of speech or text. In the context of natural language processing, the command and control system processes natural language utterances or sentences, and also recognizes and interprets the utterances or sentences and attempts to derive an interpretation that can be used.

  Traditionally, one approach to realizing natural language commands and control involves static recognition of pre-encoded commands. For example, a user can invoke a pre-encoded operation using a simple command such as “save file” by utilizing a commercially available speech to text conversion program. However, such programs usually cannot process such commands unless the correct command is used. In other words, a “store file” may not be properly understood by an application that is coded to recognize the command “save file”.

  Similarly, question / answer applications typically include pre-encoded phrases or terms to facilitate the use of search and retrieval functions. However, traditional implementations require the use of specific search terms in utterances or sentences to succeed, and as a result, the rich content of human spoken words is not fully handled.

  Programming natural language applications is extremely difficult. Typically, a programmer knows how to code in a computer language, but has little experience in diagramming the structure of a sentence and / or performing linguistic analysis. This lack of experience makes it difficult to program natural language applications. Furthermore, extending a natural language software application coded for English to work with other languages requires not only recoding of the software application but also recoding of the associated language analysis engine. This makes programming of natural language applications extremely difficult and very expensive.

  In one aspect, a software development tool for programming a natural language software application is implemented. Software development tools include programming languages and compilers. A programming language comprises a set of programming syntax that aids natural language programming. The compiler is adapted to receive a software program that includes multiple instances of a set of programming syntax and generate a software application.

  In another aspect, a method for creating a natural language compatible software application is implemented. Programs are created from a set of programming constructs that help natural language programming. This program describes features in the software application that depend on natural language input. The program is compiled into one software application.

  In other aspects, the language object model is adapted to model the semantic elements of natural language. A language object model includes a set of types and classes of linguistic expressions, which are designed to model those linguistic expressions. In one embodiment, each type in the set of types corresponds to a semantically meaningful element of utterance.

  In another aspect, a computer readable medium stores a computer readable data structure that is utilized to model a natural language. A set of types is adapted to represent a class as an abstract object. A class represents a categorized language expression that can correspond to a semantically meaningful part of a natural language utterance.

  In another aspect, a framework for generating a semantic interpretation of natural language input includes an interpreter and a set of types. The interpreter is interposed between the client application and one or more analysis engines and is adapted to output multiple interpretations of natural language input that are valid for the client application. A set of types is adapted to define the interaction between the interpreter and one or more analysis engines.

  In another aspect, a framework for instantiating the interpretation of natural language input to the natural language function of the client application is implemented. The interpreter is initialized with a declarative schema associated with the client application. The interpreter is adapted to receive natural language input, communicate with one or more natural language analysis engines, and output an interpretation of the natural language input. The interpreter is adapted to instantiate one or more of the interpretations in the client application.

  In another aspect, a lexical semantic structure that models the meaning of natural language input on a computer is implemented. A set of lexical semantic categories is selected to model the content of the natural language input. A methodology associates the contents of a natural language input with one or more categories of a set of lexical semantic categories. In another embodiment, a plurality of lexical semantic structures adapted to output multiple types of syntactic categories across multiple languages, across multiple language categories, across multiple applications, and Normalize natural language input across multiple systems.

  In another aspect, a method for creating a natural language compatible software application is implemented. Programs are created from a set of programming constructs that help natural language programming. This program describes features in the software application that depend on natural language input. The program is compiled into one software application.

  In another aspect, a system for developing a natural language compatible software application is implemented. A resolvable type defines an abstract representation of language elements and the interrelationships between language elements of natural language input. Resolution semantics define procedural rules that determine whether an instance of a type that can be resolved by a natural language software application is valid.

  In another aspect, a method for determining whether instantiation of a resolvable type in a natural language enabled software program is enabled is implemented. Proposal interpretation list of natural language input Proposal interpretation is summarized. Each proposed interpretation has one or more commands mapped to resolvable types and optional non-command elements. Whether the instantiation associated with each proposed interpretation is valid is determined by the natural language-enabled software application.

A. Overview The present invention is a language object model (LOM), a semantic framework, and a semantic programming language (SPL) for creating natural language applications. LOM models semantic utterances regardless of the natural language or application area involved. The semantic framework defines a set of types that define the nature of the interaction between the runtime component (interpreter) between the natural language analysis engine (s) and the client application, and all the components of the system. Including. SPL provides a programming framework for interfacing with LOMs and natural language analysis engines that are adapted to work with LOMs. SPL can also be used when interfacing with other language object models.

  The present invention includes the entire process and architecture in addition to a number of sub-processes and data structures. In order to provide a better understanding of the present invention, one example environment that can be used with the present invention is introduced. However, it will be appreciated that the present invention may be used with a wide variety of other systems and environments.

B. Illustrated Operating Environment FIG. 1 is a diagram of one embodiment of a suitable computing system environment 100 on which the invention may be implemented. The computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment 100 be interpreted as having any dependency or requirement relating to the one component illustrated in the example operating environment 100 or a combination thereof.

  The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with the present invention include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiple Processor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, telephone systems, distributed computing environments including such systems or devices, and the like.

  The present invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote computer storage media such as memory storage devices.

  With reference to FIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 110. Components included in the computer 110 include a processing unit 120, a system memory 130, and a system bus 121 that couples various system components including the system memory to the processing unit 120. The system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral device bus, and a local bus using any of a variety of bus architectures. For example, such architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards AS, and the Electronic Electronics Standards AS bus, There is a Peripheral Component Interconnect (PCI) bus also called.

  Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. For example, computer readable media can include, but is not limited to, computer storage media and communication media. The phrase “computer storage medium” refers to volatile and non-volatile, removable and non-removable media implemented in a method or technique for storing information such as computer readable instructions, data structures, program modules, or other data. Is intended to include Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital multipurpose disc (DVD) or other optical disc storage device, magnetic cassette, magnetic tape, magnetic disc There are storage devices or other magnetic storage devices or other media that can be used to store desired information and that can be accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. For example (but not limited to), communication media includes wired media such as wired networks or direct wired connections, and wireless media such as acoustic, RF, infrared, and other wireless media. Any combination of the above must fall within the scope of computer-readable media.

  The system memory 130 includes computer storage media in the form of volatile and / or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input / output system 133 (BIOS) including basic routines that help information transfer between elements in the computer 110 at startup or the like is usually stored in the ROM 131. Typically, RAM 132 stores data and / or program modules that are directly accessible to and / or currently operated on by processing unit 120. For example (but not limited to), FIG. 1 illustrates operating system 134, application program 135, other program modules 136, and program data 137.

  The computer 110 may further comprise other removable / non-removable volatile / nonvolatile computer storage media. For example, FIG. 1 illustrates a hard disk drive 141 that reads and writes a non-removable non-volatile magnetic medium, a magnetic disk drive 151 that reads and writes a non-removable non-volatile magnetic disk 152, and a CD-ROM or other optical medium. An optical disk drive 155 that reads from and writes to a removable nonvolatile optical disk 156 is illustrated. Other removable / non-removable volatile / nonvolatile computer storage media that can be used in embodiments of the operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital multipurpose discs, digital video tapes, solids There are state RAM, solid state ROM, and the like. The hard disk drive 141 is usually connected to the system bus 121 via a non-removable memory interface such as the interface 140, and the magnetic disk drive 151 and the optical disk drive 155 are usually connected to the system by a removable memory interface such as the interface 150. Connected to the bus 121.

  The above-described drives and associated computer storage media illustrated in FIG. 1 have the ability to store computer-readable instructions, data structures, program modules, and other data for computer 110. For example, in FIG. 1, the hard disk drive 141 is illustrated as storing an operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Different numbers are assigned to the operating system 144, application program 145, other program modules 146, and program data 147 to indicate that they are at least different copies.

  A user may enter commands and information into the computer 110 through input devices such as a keyboard 162 and a microphone 163 and pointing devices 161 such as a mouse, trackball or touch pad. Other input devices (not shown) include joysticks, game pads, satellite dish, scanners, and the like. These and other input devices are often connected to the processing unit 120 via a user input interface 160 coupled to the system bus, but may be a parallel port, a game port, or a universal serial bus (USB). Other interfaces and bus structures can also be connected. A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, the computer can further include other peripheral output devices such as speakers 197 and printer 196, which can be connected via an output peripheral interface 190.

  Computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as remote computer 180. Remote computer 180 can be a personal computer, handheld device, server, router, network PC, peer device, or other common network node, and typically includes many or all of the elements described with respect to computer 110. . The logical connections shown in FIG. 1 include a local area network (LAN) 171 and a wide area network (WAN) 173, but can also include other networks. Such networking environments are common in offices, enterprise-wide computer networks, intranets, and the Internet.

  When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over a WAN 173 such as the Internet. The modem 172 may be internal or external, but may be connected to the system bus 121 via the user input interface 160 or other suitable mechanism. In a networked environment, program modules illustrated for computer 110 or a portion thereof may be stored on a remote memory storage device. For example (but not limited to), FIG. 1 illustrates the remote application program 185 resident on the remote computer 180. It will be appreciated that the network connections shown are examples and other means can be used to establish a communications link between the computers.

C. SPL Framework Overview The SPL framework consists of a runtime component (interpreter) and a set of types. The runtime component intervenes between the client application and one or more natural language analysis engines. This set of types defines the interaction between all elements in the system. In an application that uses the SPL framework, an interpreter instance is created at runtime and is initialized with a declarative schema that describes a semantic model of the functionality in the client application that relies on natural language input. This declarative schema is created by the developer along with the application code and describes the relationship between a number of semantic modeling types created by the developer and derived from the types in the LOM. These semantic modeling types are not referenced in the declarative schema and, when instantiated by the interpreter, impose runtime-context-drive constraints on the instantiation of those types. Procedure code can be included.

  FIG. 2 is a block diagram of a semantic framework according to one embodiment of the present invention. The semantic framework 200 comprises an SPL client application 202, an SPL interpreter application 204, and a plurality of analysis engines 206. In general, the SPL client application 202 accepts text input, which can be entered directly by the user (such as through a keyboard or other input device) or received from the speech recognition system 208 or the text recognition system 210. be able to.

  The speech recognition system 208 is a system that receives audio input and generates a text output that represents the audio input. Text recognition system 210 is a system that receives handwritten or scanned input and generates a text output that represents the handwritten or scanned input. In one embodiment, the speech recognition system 208 and handwritten character recognition system 210 are incorporated into the client application 202.

  In the framework 200, the text input 212 character string is input to the SPL client application 202. The text input 212A refers to the text output from the speech recognition system 208. The text input 212B refers to the text output from the handwritten character recognition system 210. Text input 212C represents other text input, such as from a keyboard, memory buffer, or other input source. From now on, the reference number 212 applies to the received text input regardless of the source.

  The SPL client application 202 passes the SPL client application text input 212 and application schema 214 to the SPL interpreter application 204. SPL interpreter application 204 passes text input 212 and application schema 214 to a plurality of natural language analysis engines 206 (shown as boxes “Analysis Engine 1” to “Analysis Engine N”), each of which speaks a language object. Designed to map to model (LOM) 216. Any number of parsing engines 206 can be employed, and each engine 206 can use its own parsing strategy to map text input 212 to LOM 216 and application schema 214.

  In general, each parsing engine 206 applies that paradigm to the text input 212, maps the text input 212 to the LOM 216, and outputs a plurality of potential interpretations 218 that are returned to the SPL interpreter application 204. SPL interpreter application 204 is capable of identifying one or more actual interpretations 220 and then operating those actual interpretations 220 based on the one or more actual interpretations 220. Return to 202.

  In one embodiment, analysis engine 206 derives only one possible interpretation 218, but for most semantic utterances, multiple interpretations are possible, which may be interpreted by interpreter 204 or client application in terms of utterance context. 202 can solve the problem. In this case, the context is the area of the SPL client application 202 and the objects it supports. After receiving the declaration schema 214 from the SPL client application 202, the SPL interpreter 204 attempts to resolve the potential interpretation 218 against the declaration schema 214. The SPL interpreter application 204 can discard potential interpretations 218 that cannot be resolved against the declaration schema 214. The remaining interpretation (interpretation that can be resolved against the declaration schema 214) is the actual interpretation 220. The SPL interpreter 204 attempts to instantiate each of the plurality of actual interpretations 220 according to the declaration schema 214 of the SPL client application 202 by calling the actual interpretation object 220 in the client application 202.

  Depending on the implementation and configuration of the framework 200, control 222 may be passed from the SPL client application 202 to the SPL interpreter application 204 to instruct the SPL interpreter application 204 to perform further processing. Similarly, interpreter application 204 can pass control 224 to the analysis engine for further processing of text input 212 with respect to LOM 216. Thus, the semantic framework 200 can iteratively process text input to arrive at an actual interpretation corresponding to the type defined in the domain of the SPL client application 202.

  In general, the SPL client application 202, interpreter 204, and analysis engine 206 can be located within a single computer. In other embodiments, the application 202, interpreter 204, and engine 206 can be located on different systems, such as another server on the network.

  The SPL interpreter 204 is used as a function interposed between the client application 202 and the analysis engine 206. The SPL programming language is intended to be intuitive for developers. In one embodiment, the syntax will be familiar to developers because the language is built on top of C #. However, SPL is adapted to express LOM semantic structures and perform linguistic analysis, and can be implemented directly in C # or in other object-oriented programming languages.

  As already mentioned, the SPL framework is a runtime intervening between the natural language analysis engine (s) 206 and a set of types derived from the types created by the developer and defined in the LOM. The component (SPL interpreter 204) is included. This set of types defines the nature of the interaction between all components of the framework.

  The SPL framework uses a natural language analysis engine, but does not include a natural language analysis engine. This is designed so that multiple analysis engines can be used simultaneously if necessary. For example, for certain types of natural language input, one engine may be more convenient than the other, so it may be desirable to employ multiple analysis engines. Combining multiple outputs of multiple engines may improve overall performance and operation.

  For a given natural language input 212, parsing engine 206 is expected to provide interpreter 204 with a linguistically possible interpretation 218 expressed in a system of the type described in declarative schema 214. The parsing engine 206 typically has access to the semantic type description by the declarative schema 214 rather than the actual type. Rather than outputting an actual object, a potential interpretation (218), which is a collection of instructions that build the actual interpretation 220, is output. The potential interpretation 218 output by the parsing engine 206 is the actual interpretation 220 only if the interpreter 204 succeeds in creating an instance of the interpretation, in which case it will execute the associated type of procedural code. Including. The interpreter 204 attempts to resolve a possible interpretation 218 against the declaration schema 214, instantiates an interpretation that was successfully resolved by the client application 202, and performs further processing, depending on the particular implementation.

  By going back and forth between the client application 202, interpreter 204, and analysis engine 206 (including text input 212, declaration schema 214, potential interpretation 218, actual interpretation 220, and control flows 222 and 224), Conflicts and / or ambiguities are separated. The collaboration between the framework and the LOM allows programmers to be free to be interested in application areas rather than language analysis.

  In general, the declarative schema is XML code, Microsoft. NET attribute, or Microsoft. It can be a NET attribute and a resolvable type itself. Alternatively, a resolvable type can be coded such that “reflection” is used to infer schema information from the type. Reflection is a function that determines what methods, fields, constructors, etc. are defined for a class or object. Reflection makes it possible to create a dynamic program.

  Since a framework has been introduced, it is important for developers to understand the underlying language object model from which a set of types specific to their application can be derived. The language object model is not only useful for natural language application development purposes, but can also be used to directly operate the natural language semantic analysis system for any purpose.

D. Language object model (LOM)
D1. Overview The language object model (LOM) of the present invention is composed of a set of types that are independent of the application domain or even the language. The present invention includes a set of types and classes of linguistic expressions, which are designed to model those linguistic expressions. These types are LOM declaration elements.

  It will be appreciated that there are a number of ways in which the application of the present invention can be implemented, and that specific implementation details may differ from the examples discussed herein. However, the examples described below are for purposes of illustration and should in no way be construed as limiting. Where appropriate, other method or framework variations may be presented to further illustrate the breadth and robustness of the present invention.

  In general, LOM models the semantics of an utterance (the content of a story or written content) in a region-independent manner. The term “region” as used herein refers to an SPL client application that has issued a natural language processing request. As used herein, the term “meaning” refers to the meaning or significance of a spoken or written word. The term “speech” refers to finite sounds or strings and / or written words or phrases detected by the software engine that the language engine attempts to parse semantically. The term “syntax” as used herein is a grammar or structure rule that defines how to combine symbols in a language to form words, phrases, expressions, and other recognizable syntax elements. Point to.

  The LOM type is accessible by software applications to map utterance elements to linguistic expression classes. For the sake of clarity, in the following description, the mapping from the LOM type to the language expression class is mainly taken up. However, it will be understood that the mapping is a full-duplex (bidirectional) mapping from the LOM type to the class of language representation and vice versa. Both directions of this mapping are important for various tasks. It will further be appreciated that the LOM itself is language independent and that no code changes need be made to the LOM when modeling different languages. Instead, such language-specific code changes are made in the analysis engine, not in the client application.

  In general, LOM abstractly defines a language as a set of assembly blocks. SPL applications use this building block frame to access the lexical semantic structure and analysis engine in a domain-dependent manner. Finally, it will also be appreciated that LOM does not require an application schema for operation. LOM can be used to model utterances and the analysis engine can implement LOM mapping independent of application schema. Thus, the LOM can be regarded as being inside the analysis engine, and the LOM is a means for semantically expressing natural language. The analysis engine determines what the correct LOM representation is for a given utterance and effectively maps the utterance to the LOM.

  FIG. 3 is a simplified block diagram of the analysis component 300 of the system of FIG. 2 according to one embodiment of the invention. Analysis engine 302 receives flow control 304, application schema 306, and text input 308. Using the LOM 310, the parsing engine 302 maps the text input 308 to the application schema 306 and outputs one or more potential interpretations 312, which are sent to the SPL interpreter or application schema 306. It can be solved by the original client application.

  In general, the possible interpretations 312 are merely specific types of objects, represented as LOM objects. The parsing engine 302 further maps the LOM object to a corresponding object in the application schema and then returns possible interpretations to the interpreter or client application, depending on the implementation.

  Before describing the structure of the LOM in detail, it is convenient to at least roughly describe the basic types used by the semantic programming language. In general, semantic programming languages operate on a variety of semantic object models, but are specifically optimized to work with LOM structures. At this time, LOM is the best between programming comprehension (from the application developer's perspective) and language scope (ie, model elements required for application scenarios such as command and control, question answering). A specific semantic object model that achieves compromise.

D2. Types of Semantic Programming Languages Semantic programming languages (hereinafter referred to as “SPL”) are intended to help software application developers implement natural language programs. Since most developers are not semantic analysis or linguistics specialists, SPL has a framework and programming language to allow non-linguistic developers to handle natural language semantics in a very intuitive way. .

  SPL and accompanying compilers facilitate the programming of natural language client applications for LOM. SPL hides much of the basic content of the language framework, allowing developers to easily create code that interacts with the framework appropriately.

  SPL can be a standard front end for developers using the framework, but SPL is not required. Developers target the framework directly by creating types that implement various framework interfaces, inheriting from types that implement various framework interfaces, and supplying the application schema to the interpreter be able to. Alternatively, this can be done indirectly, such as by other means of authoring framework compatible code, as if it were a visual form-based design tool.

  In general, the LOM is implemented as an SPL class library. This is a standard library of Microsoft (R) Visual C ++ (R) created by Microsoft Corporation of Redmond, Washington, for example, by C Runtime Library and Standard Template Library (STL) to assist in software development. It is a similar method to form. The terms “Microsoft®” and “Visual C ++ ®” are trademarks owned by Microsoft Corporation of Redmond, Washington.

  A semantically meaningful type in SPL is a type involved in the modeling of the semantics of the incoming utterance and the application command to which the incoming utterance corresponds. A semantically meaningful type is a type that an SPL author can derive from and specialize in that application area. The semantically meaningful types of SPL are Entities, Frames, Restrictions, Commands, and Denometer Objects. The function types of SPL are Phrases and Slots. Each of these types is described separately below.

  In general, the type of SPL framework defines all aspects of the interaction between the client application, the SPL interpreter, and one or more natural language analysis engines. The phrase “all aspects of interaction” refers to the interfaces that various components must implement, the base classes that various components inherit, and the types of data passed between the components of the system. In one embodiment, the framework type is implemented as a NET Framework type, which is a framework created by Microsoft® Corporation of Redmond, Washington. SPL types can be arranged in multiple namespaces. In one embodiment, the SPL types are arranged in multiple namespaces, all of which are described, for example, in System. Natural Language Services or System. This is a partial namespace of the Natural Language namespace. As used herein, a “name space” is a context in which a name (identifier) is defined. Within a given namespace, all names must be unique.

  For clarity, the following description introduces SPL types, introduces LOM in detail, and returns to the detailed description of SPL. Throughout the text, examples are used to illustrate the invention accordingly. For the most part, the examples are derived from a single natural language utterance “Send mail to Bob”. Given this utterance, according to LOM, an application written using SPL can generate an interpretation based on the text input. The generated interpretation is then resolved against the natural language application so that the actual interpretation of the instruction can be identified and executed.

  Entity is an object of type Entity, meaning that an entity can contain data members, properties, and methods. SPL Entity is an object with a type derived from class Entity and is mainly used to model the semantics of noun phrases and adjective phrases. SPL Entity can host frames or constraints (both described below) using the “with” syntax. In addition, the SPL Entity can include an optional “Denoted By” clause that introduces a privileged data member of type “Denoter” (described below). Privileged data members, introduced by the “Denoted By” clause, can be used by the SPL interpreter to map entities to actual natural language words.

  Frame is a class that models the semantics of a semantic event, and can express the semantic event as a verb or noun. The SPL frame is a class derived from Frame. In general, Frames can be applied to Entities, so that Frame can have not only a “Denoted By” clause but also a list of “slots” (described later) including frame terms. In addition, Frames can host constraints via a “with” syntax. In one embodiment, a headword for a Frame can be defined by the developer to create a new Frame type. In other embodiments, the developer inherits the existing frame and derives the desired headword from the inheritance. In other embodiments, the developer can define headwords in a manner similar to the manner of defining denoters.

  Restrictions generally model obligatory arguments, modifiers, and other semantic elements. An SPL constraint is a class derived from the class Restriction. A constraint has a list of slots containing terms, like frames. In addition, SPL Restrictions can host other Restrictions via the “with” syntax.

  The SPL command is a class derived from the class Command. Commands are purely domain dependent, meaning they depend on the specific natural language application with which they are associated. In general, domain-dependent commands play no role in modeling the input semantics, and thus the command has no role in the LOM. Instead, the commands model actions within the application.

  In addition, the command has an optional “uses” clause, which introduces a privileged data member of type Frame. The “uses” phrase is an indispensable link between region independent input and the desired region dependent action.

  A Denometer object is a structure of type Denota. In fact, since a vocabulary is created that maps each word used as a notation in the SPL program to a corresponding list in Denometers, the Dennoter object need not store a string list. There is one Denometer object (ENGLISH field, JAPANESE field, etc.) for each natural language. The Denometer object acts as a localization table for entities. Like commands, notation objects are purely domain dependent. However, Entity has a field of type Denota, which exists solely for the purpose of allowing the Entity to be examined to determine why the Entity has been proposed by the analysis engine.

  The function type of SPL is a type used for some modeling purpose, but cannot be specialized. In addition, other classes and types cannot be derived from function types.

  The function type “Phrase” encapsulates information about a part of the text string input that is the basis of some semantic object. By using the type Phrase, software developers can perform ad hoc operations and surveys on the input string from the internally structured representation of the semantics of the original input string.

  In one embodiment, the functional type “Slots” is an object of type “Slot” that holds entities, frames, constraints, or notation objects, possibly with some auxiliary information. For example, a slot corresponding to a gap in a relative phrase includes an entity that is marked “backreferences”. In other embodiments, an Entity, Frame, or other reference is placed where the slot is expected. In still other embodiments, the Slot object is omitted with the auxiliary information, and Entity, Frame, or other references are used directly.

D3. LOM type Since the type that defines the SPL semantic model structure was examined, it became possible to explain LOM in detail. In general, the LOM types and the classes of linguistic expressions modeled by those types include Entities, Frames, and Restrictions.

a. LOM Entities From a LOM perspective, most of the work of SPL programmers, perhaps the majority is centered on the design of arrays of domain entity types and the collection of correct localization information for each of those types, but the entities are straightforward . In many cases, the phrase “headword” is an entity headword. The headword usually corresponds to the dictionary headword of the syntactic head of the phrase “entity model”. Dictionary headwords represent canonical representations for different forms of words. For example, the terms “walks”, “walked”, and “walking” share the dictionary entry “walk”.

  Regardless of the spoken language used, the general rule for all languages is that the NP becomes a LOM entity. The entity headword is a dictionary headword of the main part noun of the NP.

  In general, entity coordination is expressed in LOM via a “Coordinated Entity” type. A code snippet describing the instantiation of the type CoordinatedEntity is shown in Table 1.

  Table 1: CoordinatedEntity

The goal of LOM for reconciliation is to minimize parenthesis ambiguities that are not semantically relevant. Thus, for example, a text input of “X and Y and Z” is represented as a flat list of “X AND Y AND Z”, with a right join “X AND [Y AND Z]” and a left join “[X AND Y]”. There is no ambiguity with "AND Z". However, if there is a true parenthesis ambiguity, the LOM retains the ambiguity. For example, in the case of the phrase “show cars with 4WD and ABS or AWD”, there is a possibility of both “4WD AND [ABS OR AND]” and “[4WD AND ABS] OR AWD”. Of course, in this particular case, only the second representation can be meaningful, but it is not the LOM but the application decides.

  Pronouns are modeled in LOM as objects of type “PronounEntity”. An example of pronoun entity instantiations according to one embodiment of the invention is shown in Table 2.

  Table 2: PronounEntity

LOM provides an interface for forward anaphora resolution through the “potentialAntecedents” field in PronounEntity. The term “forward anaphor” refers to a relationship between multiple words or phrases that refer to the same Entity. The potentialAntecedents field is optionally filled with a list of already resolved Entity objects that are linguistically possible antecedents. This list is ranked in descending order of likelihood. Linguistic responsive information is the most important factor in forward anaphoric resolution, and is accessible by application developers through objects of type “AgreementInfo” attached to all Entity. An example of struct AgreementInfo is shown in Table 3.

  Table 3: STRUCT AgreementInfo

Only the ElementInfo field that is unambiguously true for a given entity is associated with that entityInfo object for that entity. In other words, LOM does not attempt to represent the disjunctive response feature. For example, in the term “cat”, “thirdPerson” and “singular” would be associated with the AssetInfo object. The phrase “she is” is associated with “thirdPerson”, “singular”, and “feminine” in the AssetInfo object. In French, the term “vous” is associated with the word “secondPerson”. In Spanish, the term “perro” is “thirdperson,” “singular,” and “masculin”, each of which is unambiguously true with respect to a given entity perro, and thus is the entity's responsive object. Associated.

  Directives such as “this” and “that” that can be used as independent NPs become objects of type DemonstrativeEntity. An example of the entity DemonstrativeEntity is shown in Table 4.

  Table 4: DemonstrativeEntity

Since an object of type “DemonstrativeEntity” is derived from Entity, it inherits the AssetInfo object and can therefore distinguish words such as “this” and “that”. In general, this inheritance allows the system to have the ability to correctly distinguish between such elements in English, French, German, Japanese, Spanish, and many other languages.

  Another related type is the NamedEntity type. The syntax for NamedEntity is:

namedentity OlapNamedEntity uses ExcelAddin.FuzzyOlapCubeRecognizer;
In general, the NamedEntity type is based on a separately defined class that inherits from the NamedEntityRecognizer class. Since NamedEntityRecognizer types are passed along with the schema, the parsing engine can use them to call back into the client code and dynamically identify application object references in the utterance.

b. LOM Frame In one implementation, for all languages, the phrase is LOM Frames, but this is not necessarily correct for all implementations. Conceptually, Frame comes out of a phrase, but in practice it doesn't have to be present in the input. The frame entry is the dictionary entry for the verb at the beginning of the phrase. For example, when parsing the phrase “Send mail to Bob”, “send mail” is associated with the LOM Frame, where “Send” is the dictionary heading of the first verb of the phrase and thus the heading of the frame.

  It will be appreciated that the Restrictions can be conceptualized as defining a default behavior. However, such an operation is not necessarily forced. The function depends on the implementation.

  Slots can be filled with entities or frames, so the default slot can be a noun phrase or clause. Furthermore, NPs can have an empty pronoun (PRO) as the main word. If the PRO points to a referent in another section, the main word of that section is interpreted as the main word of the NP entity. If the PRO has no indication target, it is interpreted as some entity (someone or something).

  In one embodiment, assuming that there is a subject included in the clause, the subject of the clause fills the “Doer” constraint. If there is no subject, there is no “Doer” constraint. “Doer” represents the first part involved in the event, and the semantics are roughly described as the cause of the event or condition specified by the actor, actor, subject, instigator, or verb. An example of a verb clause where a portion of the clause is mapped to the “Doer” constraint of the frame is shown in Table 5 below.

Table 5: Verb clauses with subject
Instant message opens.
Robin is on my buddies list.
Amazon offers wish list capabilities.
[PRO] open the file
Having a program associated with a file ensures easy opening.
The underlined word or phrase is the word or phrase that is mapped to the Doer slot. This is true for both transitive and intransitive frames and corresponds to transitive and intransitive verbs.

  If there is an object in the phrase, that object is mapped to a second slot in the frame called the “DoneTo” constraint that represents the second syntactic part of the event. The semantics can be roughly understood when referring to objects that are affected by the event or state specified by the verb. The underlined phrases in Table 6 are mapped to the “DoneTo” constraint.

Table 6: “DoneTo” constraints
Outlook has my buddies list .
Amazon offers wish list capabilities .
[PRO] open the file .
Preferences include having a program associated with a file .
In one implementation, the indirect object can be considered to be a beneficiary of the action. In one embodiment, the indirect object can be mapped to a Beneficial constraint. Beneficial constraints generally model verbal arguments that represent the person whose event was performed by the surrogate. The beneficiary slots are briefly described by the underlined pronouns included in Table 7.

Table 7: Beneficiary slots
Open me a new file.
Play her some tunes
A Beneficial constraint (or “slot” in other embodiments) can be set on an entity that models a noun phrase that is interpreted as a beneficiary. Table 8 illustrates a beneficiary constraint code block.

  Table 8: Beneficial constraints

  The beneficiary constraint, sometimes referred to as the “beneficiary case”, specifically overlaps the assignment in English for the singular object of the “for” prepositional phrase. Some overlap may occur in other languages. When applied to a frame, the beneficiary constraint is clear from the following sentence.

I baked a cake for my mother.
PP [for]
In general, beneficiary constraints model verb terms in most languages. Table 9 illustrates beneficiary constraints in some language examples.

  Table 9: Beneficial constraints

  In general, a constraint can be a subject, a direct object, an indirect object, a graded term, a modifier, and the like. In SPL, a frame can have arbitrary constraints (with the following exceptions). However, LOM uses a grammar to prioritize constraints in two ways. First of all, it can be a constraint type associated with a lexical semantic structure class of which a verb is a member (this is described in detail below). Secondly, tones are sometimes associated in unusual ways with individual verbs, that is, the terms have no constraint relationship with their clause heads. These terms are assigned to predefined constraints (described below) and are identified by their lexical principals.

  Frame adjustment is performed in two ways depending on the context. The “highest level” adjustment frame (ie, derived from the mother verb) is represented as an object of type CoordinatedFrame in parallel with CoordinatedEntity (described above). Reference examples are shown in Table 10 below.

  Table 10: Coordinated Frame

In general, frames that appear on entities (via the “with” syntax) behave as constraints. As described below, this means that a conjunction is expressed by triggering multiple constraints, while a disjunctive conjunction is expressed by expanding a host entity to CoordinatedEntity.

  As already explained, in one embodiment, Frames can be used as constraints on entities to model natural language relative clauses. If a frame is attached to an entity via the “with” keyword, this frame imposes a constraint on the entity, which is called a “frame-based constraint”. In most cases, one slot in the frame corresponds to a natural language gap bound by a main noun. In LOM, this translates into a frame-based constraint that accepts a reference to one host entity in the slot. Including a reference to the host entity in the slot of a frame-based constraint can be referred to as “backward adaptation”. In such “back-reading”, re-entry into the tree-like LOM representation is possible by other means, so that the isBackreference flag is set to true in the slot corresponding to the gap. (This flag is provided only as a convenience for the process of following the LOM representation). For example, in Table 11 below, the frame-based constraint is resolved against the phrase “files that Billy opened yesterday”.

  Table 11: Frame-based constraints

In Table 12, frame-based constraints are resolved against the phrase “people who work at Company”.

  Table 12: Frame-based constraints

In Table 13, the frame-based constraint is resolved against the phrase “people I have sent mail to”.

  Table 13: Frame-based constraints

It is important to note that the re-entry introduced by frame-based constraints creates difficulties in the SPL resolution process. In particular, an entity is not fully resolved until all constraints have been fully processed (and thus technically “not present” in SPL). However, one of the entity constraints can be a frame that receives the entity itself in one of its slots. Thus, a situation arises where the entity object needs to be examined by the code that defines the frame, but the entity still remains undefined until some point after resolution of the frame is finished. This issue is discussed in Section E. below. 4 will be described in detail.

  In other embodiments, Frames does not have slots, but instead uses “Doer” and “DoneTo” constraints as described above. In such a case, a new constraint can be defined based on the frame, and the “Doer” and “DoneTo” constraint clauses are applicable to the new constraint. Thus, constraints present an alternative means of handling frame terms. In the following description, only one such implementation will be referred to for simplicity, but any implementation is applicable.

c. LOM Constraints Unlike entities and frames, constraint adjustments are not represented using “composite” types such as CoordinatedEntity and CoordinatedFrame. Instead, SPL semantics are used to represent constrained conjunctions, but constrained disjunctive conjunctions result in entity or frame disjunctive conjunctions.

  SPL assigns conjunctions or intersection semantics to two constraint clauses that succeed in triggering sequentially on the same host, so there are only two linguistic conjunctions of the material modeled with constraints. The above constraints are handled by triggering sequentially. On the other hand, linguistic disjunctive conjunctions of materials modeled by constraints do not have a convenient fragment in SPL semantics. Thus, such disjunctive conjunctions "bubble up" to the next entity or frame on the constraint (usually the host), causing a CoordinatedEntity or CoordinatedFrame object at that level.

  For example, in the case of the phrase “mail from Kim or to Robin”, there is one entity host “Entity (mail)” and two constraints “Source (Entity (Kim))” and “Goal (Entity (Robin))”. . Since these two constraints are coordinated by the disjunctive conjunction “or”, the disjunctive conjunction bubbles up to the host “Entity (mail)”, resulting in the mapping illustrated in Table 14 .

  Table 14: Constraint adjustment

This code outputs two copies of Entity (mail).

Accompaniment constraints model one or more additional members in some group. In many cases, an accompaniment can be paraphrased by a conjunction. For example, the phrase “customers along with the birthdates” can be restated as “customers and theirirth birthdates”. In the case of a reciprocal-event-denoting entity, an adjoint constraint models an additional participant in the event. Such noun phrases often have a corresponding frame (eg, “correspond”, “meet”, “chat”, etc.). The adjoint constraints are also prefixed in noun phrases such as “correspondence with my manager ”, “an appointment with Kim ”, “meeting with Time ” (emphasis added), and “a chat with Sue ”. To do. An example of an Accompaniment constraint syntax according to one embodiment of the present invention is illustrated in Table 15.

  Table 15: Accompaniment

  Accompaniment constraints can also model additional who or what participants in the context of Frame. For example, the phrase “chat with Robin” invokes a “Chat” frame with the phrase “with Robin” as an adjoint constraint.

  Adjoint constraints can also be assigned to slots in entities that model noun phrases that are interpreted as accompanying the host. Instead, an adjoint constraint can be set on a “who” or “what” slot.

  In some cases, it may be desirable to compile a list of “with” cases that are semantically equivalent to a conjunction as an entity list. As long as there are equivalent companion representations in other languages, it may be useful to compile entity lists for those representations as needed.

  For those possessions that can be modeled as companions, it may also be desirable to include them in the entity list. For example, “email with attachments” is owned by the companion style, whereas “email's attachments” is owned by the owner style. In some cases, these can be treated as linguistic complementary expressions. Furthermore, phrases such as “an email that has attachments” can also be modeled as adjoint constraints.

  Subject reciprocals can also be convolved with adjoint constraints. An example of the subject interrelationship is “John chatted with Mary” for “John and Mary chatted”. In lexical terms, these two expressions are easily distinguishable. Similarly, object reciprocals such as “Merge File A and File B” for “Merge File A with File B” can be easily identified. It would be desirable to incorporate such subject and object correlations into adjoint normalization in LOM.

  Adjoint constraints are extended to many languages, especially with respect to prepositional phrases such as “along with” or “together with”. Similar adjoint constraints can be employed in French, German, Japanese, Spanish, and other languages. Table 16 illustrates such an entailment.

  Table 16: Adjoint constraints

  Allocation constraints, such as those illustrated in Table 17, generally model the entity to which the host entity is distributed, or the entity that exists or is created instead of the host entity.

  Table 17: Allocation constraints

When modeling an entity to which a host entity is distributed with an allocation restriction, one example of such a constraint is “online profile for search funds ”, “stools for linguistics” , or “application for aj obj ”. It will be. The underlined part indicates the allocation constraint. If an assignment constraint models an entity that exists or is created instead of a host entity, the semantic utterance may be "a cake for my mother " or "party for my manager ". In both cases, the assignment constraint adds specificity to the entity. Table 16 illustrates one embodiment of allocation constraints. Assignment constraints can be set on entities that model noun phrases that are interpreted as being assigned to hosts that use the slot.

In general, assignment constraints can be applied to assignments to plural entities as well as singular. The allocation constraint has a complementary distribution with English Beneficity. Only one entity is the host of assignments. Only the frame is the beneficiary's host, especially the singular object for the “for” prepositional phrase. In English, this preposition can be used in various ways. For example, in “packets for a specific destination ”, this indicates the purpose, but in “application for which you are enabling authorization checking ”, it is the type of assignment. Similarly, “tabs for taskpad views ”, “checkbox for the type of service ”, and “area code for Madison, WI ” all represent allocation constraints. In German, among others, “fur” represents an assignment. In Spanish, the corresponding preposition is para, and the phrase “una escoba para la cocina ” indicates an assignment constraint.

  The “AsBeing” constraint on Frame models the property or capacity assigned to the object slot of the frame. Only modifiers that model adjective phrases are mapped to constraint versions. Table 18 shows two code samples for AsBeing constraints.

  Table 18: AsBeing constraints

In general, LOM models the semantic relationship between utterance dictionary entries. The “AsBeing” constraint attempts to model the preposition phrase “as”. For example, the phrase “Save the file as a text file” is similar to the phrase “Save the file to a text file”. “Set my status as busy” is similar to “Set my status to busy”. The “AsBeing” constraint models the property or capacity assigned to the object slot of the frame. Here, the AsBeing constraint models the constraint “as” to “text file”, which is a property assigned to the object slot of the frame. Instead, it could be possible to apply this functionality to Denoter instead of Entity. Table 19 shows examples of AsBeing objects in English, German, Japanese, and Spanish.

  Table 19: Examples of AsBeing

  A radix constraint is a constraint that models a radix as represented by a quantifier. Slots and fields can be set to quantifier floating point values. Indefinite articles such as “an” and “a” are sometimes modeled as “1”. Table 20 illustrates cardinality constraints.

  Table 20: Cardinal constraints

Furthermore, in some cases it may be desirable to block the radix in units of time (eg, “3 hours”). Introducing the amount of time, especially in terms of time units, usually requires a prepositional phrase such as “in 3 hours” or “for 3 minutes”, so even if the radix constraint is blocked, it conflicts with the Time type object. There will be nothing (at least in English). Table 21 illustrates some examples of expressions that can be mapped to radix constraints.

  Table 22: Expression examples showing cardinality constraints

  Another type of constraint “Comparison” models a comparison of an entity with other explicitly indicated entities. The syntax of the Comparison constraint is illustrated in Table 23.

  Table 23: Comparison constraints

Comparison constraints are not used for implicit comparisons, such as when one of the comparing entities is not explicitly referenced. For example, “a bigger file” suggests an implicit comparison and does not invoke a comparison constraint.

  A comparison constraint can be applied to a dimension slot, where the dimension is set to a modifier phrase that models an adjective phrase. This modifier phrase constraint typically has a “degree” constraint, and the degree field is set to, for example, “more”, “less”, or “same”. The “refpoint” field is set to the entity to be compared with the host entity.

  Depending on the specific implementation, the superlative who explicitly specifies the comparison class may require special attention. For example, in the phrase “the tallest girl in the class”, “class” may be referred to as a refpoint of a comparison, or alternatively, “class” may be referred to as a place for “girl”. Various other superlative expressions may also require special attention. For example, the phrase “my daugter is tall for herage” and the Spanish equivalent “mi hija es alta para su edad” also cause similar problems from a LOM perspective.

  Table 24 illustrates some examples of representations that can be modeled by comparison constraints.

  Table 24: Expression examples modeled by comparison constraints

  Conditional constraints model the conditions expressed in the utterance. Table 25 illustrates the conditional clause constraint syntax.

  Table 25: Conditional constraints

As in the previous example, conditional constraints can be modeled in most languages including (among other things) English, French, German, Japanese, and Spanish.

  The default constraints do not model the syntax of a particular class, but merely provide an interface to some of the basic language analysis that has not yet been claimed by other LOM objects. Table 26 shows an example of a default constraint syntax for one possible implementation of the present invention.

  Table 26: Default constraints

  Another possible variation of the Default constraint receives a single Entity as its slot. This modification of the Default constraint allows a relationship between this single Entity and the object that hosts the constraint.

  It is important to note that in general a constraint can have a pattern associated with it. Such pattern association allows the LOM consumer to communicate with the LOM producer (analysis engine) as to which language syntax to identify. A simple example would be a string-based pattern. For example, in the use of a Source constraint, the pattern has ["due to" + X], which may cause the analysis engine (LOM producer) to map the pattern to the Source constraint. By applying pattern association to linguistic analysis, programmers can choose to perform low-level inferences on user input. Unlike other LOM types, there is no cross-linguistic normalization that is implied by the Default constraint.

  Depending on the implementation, it may be necessary to define a single interface (e.g., "ILinguistic Analysis") that can expose anything from a fully parsed result to a simple string. In general, a pattern may correspond to a number of different ways in which part of the utterance can be published through ILlinguistic Analysis. In a preferred embodiment, there is a range of predefined constraints, one for each type of analysis engine.

  A Degree constraint only attaches to a modifier constraint that models an adjective phrase. Table 27 illustrates the degree constraints and the syntax of the DegreeType enumeration type.

  Table 27: Degree constraints

Next, the value of the DegreeType enumeration represents various possible modifications to the meaning of the adjective phrase. The degree field is set to an appropriate value.

  In some cases, it may be desirable to recognize a low value of DegreeType by simultaneously taking out both clause negation and high-type adverb. For example, the expression “not very big” refers to a low value of DegreeType expressed via negation and adverb. If negation is neglected, the utterance will be misinterpreted. Table 28 illustrates some examples of representations that can be modeled using degree constraints.

  Table 28: Examples of phrases that imply degree constraints

One skilled in the art will appreciate that other Degree constraint types exist in English and German, and such constraint types also exist in most languages. Degree constraints can be accessed in almost any language.

  The Direction constraint models the direction of motion or the direction of spatial position. Table 29 shows an example of Direction constraints and their associated enumeration types.

  Table 29: Direction constraints and associated enumerations

  The direction type ("DirType") field of the slot can be set to an appropriate enumeration value. In some cases, other enumerated values may be desirable. For example, the command “turn” has an unspecified direction, but “turn” appears to expect to take the direction as an argument. Therefore, depending on the implementation, it may be desirable to specify an enumerated value for “Unspecified” so that such an expression can be distinguished from other expressions. The value synthesized with the verb can be stored as a new object representation in the vocabulary entry. It is also important to understand that Direction constraints include directional objects (prepositional phrases) and directional adverbs, regardless of where they are attached. Table 30 shows some examples of representations that can be modeled by Direction constraints.

  Table 30: Examples of phrases modeled by Direction constraints

One skilled in the art will appreciate that other Direction constraint types exist in English and German, and such constraint types also exist in most languages.

  An Example constraint models a sample entity type, frame, or constraint. Table 31 illustrates the syntax for each such Example constraint type.

  Table 31: Example constraints

In some implementations, it may be desirable to provide a SimilarTo constraint to provide the following structure.

I want to find vendors, for example Volt .
I want to find vendors, Volt, for example .
In other embodiments, it may be desirable to provide an additional slot for what is a sample. For example, the phrase “This program exemplifies solid coding techniques” may require an additional slot to model the phrase “solid coding techniques”. In general, the Example constraint can be understood as modeling a simile. Table 32 shows some terms that can be modeled by the Example constraint.

  Table 32: Examples of phrases modeled by Example constraints

One skilled in the art will appreciate that other example constraint types exist in English, German, and Spanish, and that such constraint types also exist in other languages. You can access the Example constraint in almost any language.

  Extent constraints model entities that are involved in measuring some concept of a range in space. Table 33 illustrates the extent constraint syntax.

  Table 33: Extent constraints

In general, the slot range field is set to an Entity that models the range measurement. In one embodiment, the object of the range preposition phrase is independent of the place in the utterance. Table 34 shows an example of English and Spanish words that can be modeled by Extent constraints.

  Table 34: Examples of phrases modeled by extent constraints

  Goal constraints model the goal of a (metaphoric or physical) movement or the final state of a state change on an Entity or Frame. Table 35 illustrates the syntax of a Goal constraint according to one embodiment of the present invention.

  Table 35: Goal constraints

A Goal constraint can be associated with one or more enumerated values. The field “DirType” (defined in Table 29 above) can be, for example, a Goal enumerated value that can be set to an appropriate enumerated value. Table 36 shows some words that can be modeled by the Goal constraint.

  Table 36: Examples of phrases modeled with Goal constraints

  One skilled in the art will appreciate that other Goal constraint types exist in most languages. Goal constraints are accessible in most languages.

  The Iteration constraint models an iteration of action. Table 37 illustrates the syntax of the iteration constraint.

  Table 37: Iteration constraints

In one embodiment, the Iteration constraint can be incorporated into the Recurrence field of the time constraint. In general, a field of type Count indicates that the action is repeated a certain number of times (eg, do [something] 5 times ). If the type has this value, the field “times” holds the number of iterations. If the type has other values, the type models a modifier that does not represent a specific number of iterations. Thus, if the type is not set to count, this holds the number of iterations, otherwise the type is ignored. Table 38 shows some words and phrases that can be modeled by Iteration constraints.

  Table 38: Examples of phrases modeled by Iteration constraints

  One skilled in the art will appreciate that other Iteration constraint types exist in most languages. Iteration constraints are accessible in most languages.

  Location constraints model physical or metaphorical locations. Table 39 illustrates the location constraint syntax.

  Table 39: Location constraints

  Table 40 shows some words and / or phrases that can be modeled by Location constraints.

  Table 40: Examples of words / phrases modeled by Location constraints

  One skilled in the art will appreciate that other Location constraint types exist in most languages. Location constraints are accessible in most languages.

  The Means constraint models a means or device for performing something about an Entity or Frame. The syntax of the Means constraint is illustrated in Table 41.

  Table 41: Means constraints

  One skilled in the art will appreciate that other Means constraint types exist in most languages. The Means constraint is accessible in most languages. Examples of words / phrases that can be modeled using Means constraints are shown in Table 42.

  Table 42: Examples of words / phrases modeled by Means constraint

  A Measurement constraint models the weight or measure of an object relative to a Frame or Entity. Table 43 illustrates the syntax of the Measurement constraint according to one embodiment of the present invention.

  Table 43: Measurement constraints

  One skilled in the art will appreciate that other Measurement constraint types exist in various languages. Measurement constraints are accessible in most languages. Table 44 shows some words / phrases that can be modeled by a Measurement constraint.

  Table 44: Examples of words / phrases modeled by Measurement constraints

  A Modifier constraint can be considered a “catchall” (“trash dump”) constraint in that it does not model semantically consistent classes of linguistic expressions. Instead, it captures the “adjuncthood” integration concept. In general, a Modifier constraint can model an adjective phrase, noun phrase, or adverb phrase with respect to Entity, Frame, or Restriction. In one embodiment, the modifier slot is simply set to a syntax notation object consisting of the headwords of the integrated phrase being modeled. However, this embodiment is not absolutely necessary to use LOM. Table 45 illustrates the syntax of the Modifier constraint according to one embodiment of the present invention.

  Table 45: Modifier constraints

  In general, a Modifier constraint models a class with language modifiers in an arbitrary context. Although any language modifier can be a modifier, the Modifier constraint is intended to be a main LOM expression that shows only a subset of language modifiers. The subset includes most or all adjective phrases, most or all noun phrase modifiers, and several adverb phrases. In many adverb phrases, for example, as one large example, the temporal representation finds the main LOM representation in other more specific constraints.

  The Modifier constraint is usually different in that a slot contains a notation object rather than an Entity, Frame or Restriction. The Denometer object character string is a headword of the modifier. The reason for this arrangement is that the linguistic modifier works semantically in one place on its host (the component being modified) and thus resembles a frame, but in practice, almost exclusively as a constraint Is to be used. Moreover, linguistic modifiers rarely appear in other contexts where a frame may appear. Specify only the Denometer object for a modifier class, without the need for a cumbersome frame-based constraint syntax (something like with MyMyFrameFrame <this>) and a frame type definition for each desired modifier class, It is sufficient to consider implicit constraint grammar terms (such as host objects with constraints) as semantic grammar terms.

A narrative adjective within a relative clause is expressed in the same way as the corresponding restricted usage of that same adjective. Therefore, both “a large file ” and “a file that is large ” become Modifier <large>.

  The handling of such adjectives may not be appropriate for some languages such as Japanese with adjectives that behave syntactically indistinguishable from verbs. Nouns are very common across languages, but nouns are mapped to SPL entities. Verbs are also similar across languages, but verbs are mapped to SPL frames. Then, an adjective is in the middle of a noun and a verb, and adjectives are not similar in common languages.

  Language can be considered to exist on a continuum. At one end of the continuum, adjectives are not actually a separate vocabulary category from verbs, as in Korean. In this case, the adjective is only a state intransitive verb. Japanese is similar to Korean in this respect, and adjectives behave syntactically like verbs (although they differ morphologically). In English and Latin languages (European languages), adjectives are treated as a different category from verbs. In other languages, such as Arabic, adjectives are treated as a class of nouns. In Arabic, nouns that mean something like “a red one” are used instead of words for “red”, and “the book is red” becomes “the book is a-red-one”.

  In some embodiments, there can be a representation of narrative adjectives within the matrix clauses. For example, the phrase “this file is personal” may be treated differently than “this file is text”.

  Moreover, those skilled in the art will appreciate that other modifier constraint types exist in various languages. Modifier constraints are accessible in most languages.

  The Named constraint can be used to access the host entity's denotor object. This allows, for example, MyAlias and DL_MyAlias to be normalized to a single DLEntity, and the author does not have to code for two different constraints. Table 46 illustrates the syntax of Named constraints according to one embodiment of the present invention.

  Table 46: Named constraints

Generally, Named constraints are set on noun phrase names or host entity notation objects. In some embodiments, Named constraints can be used to provide some access to named entity attributes. In other embodiments, Named constraints are merged with Modifier constraints. In general, Named constraints can present information that already exists (such as host entity notation objects) as needed.

  One skilled in the art will appreciate that other Named constraint types exist in various languages. Named constraints are accessible in most languages.

  The Negation constraint models semantic negation or logical NOT. Table 47 shows an example of the syntax for Negation constraints according to one embodiment of the present invention.

  Table 47: Negation constraints

In some embodiments, the Negation constraint can be presented as another constraint. In other embodiments, a Negation constraint can be consumed by either a “with Negation” clause or a “!” (Not operator).

  The Ordinal constraint models an ordinal and other modifiers (such as “previous”) that in turn represent some concept of position. Table 48 illustrates the Ordinal constraint and its enumerated syntax according to one embodiment of the present invention.

  Table 48: Ordinal constraints and enumerations

In general, the distance field can be set to a signed integer distance from the reference point. Instead, a reference point field called refPoint (refPoint) must indicate a non-negative distance. A distance value of 0 models first, a value of 1 models second, and so on. The last reference point field must be a non-positive distance. A distance value of 0 models last, a value of -1 models next-to-last, and so on. The current reference point distance can hold an integer value. A distance value of 0 models "current" status, a value of 1 models "next", a value of -1 models "previous", and so on.

  Table 49 shows some terms that can be modeled by the Ordinal constraint.

  Table 49: Phrases modeled by the Ordinal constraint

  One skilled in the art will appreciate that other Ordinal constraint types exist in various languages. The Ordinal constraint is accessible in most languages.

  In a posted constraint, a property, attribute, or ownership is modeled and used as a supplement to a posted constraint (described later). Table 50 illustrates the syntax associated with a Posted constraint according to one embodiment of the present invention.

  Table 50: Possible constraints

In general, a Posted constraint models a property, attribute, or ownership. For example, phrases such as “email with headers , schools with linguistics programs ” can be modeled by a posted constraint. In some cases, a Posted constraint can be referred to as “having” an attribute, property, or ownership. Table 51 shows some words and phrases that can be modeled using the Posessed constraint.

  Table 51: Examples of words / phrases modeled by Posessed constraints

  Those skilled in the art will appreciate that other posted constraint types exist in various languages. The posted constraints are accessible in most languages.

  The Posessor constraint complements the Posessed constraint. In general, the Posessor constraint models the owner of an entity, whether expressed by a vocabulary noun phrase or by an owned pronoun. Table 52 illustrates the syntax of a possessor constraint according to one embodiment of the present invention.

  Table 52: Posessor constraints

Table 53 shows some words / phrases that can be modeled by the Posessor constraint.

  Table 53: Examples of words / phrases modeled by possessor constraints

One skilled in the art will appreciate that other possessor constraint types exist in various languages. Postessor constraints are accessible in most languages.

  Another constraint that is modeled by LOM is a Purpose constraint. A Purpose constraint models the expected result associated with a Frame. Table 54 illustrates some examples of phrases / words that can be modeled by Purpose constraints.

  Table 54: Words / phrases modeled by Purpose constraints

  Reason constraints model a rational motivation for beliefs or actions associated with a frame or entity. In one embodiment, Reason and Purpose constraints may overlap in scope. Table 55 shows some words / phrases that can be modeled by Reason constraints.

  Table 55: Words / phrases modeled by Reason constraints

There are a number of languages that can model both Reason and Purchase constraints. The above word / phrase examples are not intended to be used as an exhaustive list, but rather to illustrate words that may be modeled by constraints.

  A SortOrder constraint models a modifier that describes the style and / or method of data ordering. Table 56 illustrates the SortOrder constraint and the associated OrderType enumeration syntax.

  Table 56: SortOrder constraints

In general, the field type can be Default, Reverse, Alphabetic, Numeric, Incresing, Decreating, and the like. Default types are modeled in a default order, arbitrary order, etc. The Reverse type is modeled in reverse order (backward). The Alphabetic type is modeled in ABC order (in alphabetical order). The Numeric type is modeled numerically (in numerical order). The increasing type is modeled in ascending order. The Decreating type is modeled in descending order.

  In some embodiments, a SortOrder constraint may be imposed on a physical entity such as an “alphabetical list”. In addition, verbs such as “alphabetize”, “categorize”, “group”, “classify”, and “index” can also be modeled by SortOrder constraints. In some cases, it may be desirable to have two fields to model a phrase such as “reverse alphabetical order”, “decreating alphabetic order”, and the like. In addition, there can be different sort orders common to two different languages. The enumerated types shown in Table 56 are common in English, but Japanese can have an additional sort order typical of that language. Table 57 shows some example phrases / words that can be modeled by SortOrder constraints.

  Table 57: Words / phrases modeled by SortOrder constraint

  Source constraints model the source or origin of an object. The syntax for the Source constraint is shown in Table 58.

  Table 58: Source constraints

In general, those skilled in the art will appreciate that various Source constraint types can exist for multiple languages.

  The StructureCriteria constraint models the concept of Frames that operates on a set of objects in a structured way. StructureCriteria constraints model one or more criteria for advancing an action. The syntax for StructureCriteria constraints is shown in Table 59.

  Table 59: StructureCriteria constraints

In some implementations of LOM, it may be desirable to include a constraint called “increment” to model phrases such as “in pairs”, “5 at a time”, and the like. These types of phrases include well-normalizable numerical criteria that may be important enough to provide some dedicated means of modeling, depending on the implementation. Table 60 illustrates a number of words and phrases that can be modeled by StructureCriteria constraints.

  Table 60: Words / phrases modeled by structural criteria constraints

  The “Substation” constraint models the part involved in a semantic event where one word replaces the other. In French, “a” can be used as an addendum instead of “pour”. An adjunct is a kind of adverb that indicates the state of action. Similarly, in Spanish, “po” can be used as an addendum, and “para” can be used with the selected verb.

Time can be treated as a constraint. In general, a Time constraint models a time modifier with a reference to a specific time unit or time that can be expressed as an entity. For example, “after July 23 ^rd ” and “after Thanksgiving” can be modeled by Time constraints. However, in some embodiments, phrases such as “after my computer boots up” are not modeled by a Time constraint. Similarly, time ranges such as “from 3:00 to 6:00” and “between morning and evening” can be modeled by Time constraints. However, “while the defragability is running” cannot be modeled by Time constraints. Temporal expressions with embedded clause content are handled with Conditional constraints. Table 61 illustrates the time syntax and implementation as constraints within the LOM.

  Table 61: Time constraints

  The Time constraint uses one or more fields and a number of auxiliary data types as needed. The fields can include start time, end time, “point or span”, duration, and repetition. The start time field is set to a reference time derived object that represents the start point of a time span such as “from 5:00” or “after tomorrow”. If the start time field is null, the modeled time modifier does not contain an explicit representation of the starting point.

  The end time field is set to a reference time derived object that represents the end point of the time span, such as “to 6:00” or “until Friday”. If the end time field is null, the modeled time modifier does not contain an explicit representation of the end point.

  The point or span field is set to a reference time derived object that represents a single point in time or time span represented by a single phrase, as opposed to a time span represented by explicitly specifying the start and end points. For example, with respect to “tomorrow”, the idea is that whether “tomorrow” is a single point on a simultaneous line or a 24-hour time span depends on the context and the viewing viewpoint. LOM does not attempt to eliminate word ambiguity. If the point or span field is null, the modeled time modifier does not contain an unambiguous representation of a single point in time or span.

  The duration field can be set to a duration object that represents the length of the time span without representing a specific start and end point. For example, the phrase “for two hours” can be modeled by a duration field. If null, the modeled time modifier does not contain an explicit representation of duration. A duration inherent in a time span such as “from 4 pm to 6 pm” is not represented as a duration object. In this case, there will be no non-null value for the start time and end time, but the duration will be null.

  The repetitive field is set to a time length object representing a time interval from the appearance of a repetitive event to the appearance. For example, in the case of phrases such as “daily”, “weekly”, “monthly”, and the first Monday of every month, they can be expressed as time length objects. If null, the modeled time modifier is not interpreted as an iteration.

  In general, Time constraints use a number of auxiliary data types. For example, a BaseTime chain is an object derived from BaseTime that consists of zero or more objects derived from RelativeTime and exactly one “root” object originating from AbsoluteTime. These are called “chains” because each RelativeTime derived object holds a reference to the next object in the chain, but the root AbsoluteTime derived object does not hold such a reference.

  AbsoluteTime derived types, such as NowAbsoluteTime, do not hold references to other objects in the chain. For example, the NowAbsoluteTime derived type represents “now” that cannot be analyzed at the time of utterance. LOM does not attempt to resolve “now”, for example, on October 24, 2002 at 3:42:27 pm.

  AnalyzedAbsoluteTime is an AbsoluteTime derived type and represents a point in time or time span that can be analyzed for seconds, hours, days, years, etc. For example, AnalyzedAbsoluteTime can be used to represent the time “now” as 3:45 am, Wednesday, May 10, 2003, 9:30 am.

  Unanalyzed AbsoluteTime is an AbsoluteTime derived type that represents an expression that is known to be a point in time but cannot be analyzed in atomic time units. For example, holidays, spring, summer, autumn and winter, and abstract time concepts tend to fall into this category. For example, “Thanksgiving”, “Electration Day”, “my birthday”, “summer”, and “this evening” are all phrases that are modeled as UnalsizedAbsoluteTime.

  There are two relative Time derived types, OffsetRelativeTime and SubsetRelativeTime. OffsetRelativeTime represents a positive or negative offset of a specific length of time from the referenced BaseTime derived object. For example, the phrase “two days ago” is modeled as “[2 days back] OFFSET FROM [now]”.

  A SubsetRelateTime is a RelativeTime derived type that represents a point in time or time span that is interpreted as being a subset of the surrounding time span represented by the reference BaseTime derived object. For example, a time dimension expression such as “at 5:00 on my birthday” can be modeled as an expression corresponding to “[hour: 5 min: 0] SUBSET OF [“ my birthday ”]”. Note that a temporal reference such as “5:00 on Wednesday” can be captured by a single Analyzed AbsoluteTime object because the phrase can be decomposed into time units.

  In some embodiments, it may be desirable to have multiple pairs of StartTime and EndTime fields. For example, in order to capture an expression such as “from Monday to Friday from 4:00 to 5:00” it may be desirable to have two pairs of start and end time fields to capture both ranges. is there. In fact, for the above representation, it would be desirable to have a Time entity. In addition, the parallel relationship between the following expressions suggests that a Time entity may be desirable.

Move the meeting [from 4:00 to 5:00].
Move the file [from Folder1] _Source [to Folder2] _Goal .
In addition, EndTime should be distinguished from regular Goals because not all structures that take Sources and Goals allow StartTime and EndTime to have such functionality. For example, in a structure that is adapted to model the expression “Run a meeting [from 4:00 to 5:00]”, StartTime and EndTime may not function properly.

  Another constraint is a Topic constraint. With respect to Entity objects, Topic constraints model terms or modifiers that represent what an entity is about, what an entity is involved in, or related to. Topic constraints associated with Frame model verb terms that express the subject or topic of the event. In general, a Topic constraint has a Slot set to Entity or Frame that models a topic or subject. Alternatively, Slot can take a string. Table 62 illustrates the Topic constraint syntax according to one embodiment of the invention.

  Table 62: Topic constraints

  In some cases, it may be desirable to label Topic constraints with different names. It may be desirable to use other labels for this constraint, especially if a severe overload of “topic” is given (at least in the Linguistics field). For example, some other labels may include “Concerning”, “Regarding”, “About”, “Subject”, “Theme”, and the like. Table 63 shows some examples of words / phrases that can be modeled by Topic constraints according to one embodiment of the invention.

  Table 63: Examples of words / phrases modeled by Topic constraints

  The Quantifier constraint models a noun phrase quantifier such as “two-thirds of” and a partial expression. In general, a Quantifier constraint can include a type or percentage field. The type field can be a percentage, usually (although not necessarily) ranging from 0 to 1, stored as a floating point number. For example, in the percentage type, “one half of”, “75% of”, “200% increase”, and the like are modeled. The type field can also model quantifiers that do not correspond to exact percentages. “All” and “none” are listed as different “privileged” values that do not fall into this “other” type. The percentage field holds the percentage corresponding to the meaning of the quantifier when the type has a value of Percentage. Otherwise, the percentage field is ignored. Table 64 illustrates the enumeration syntax associated with the Quantifier constraint.

  Table 64: Quantifier constraints

In some implementations it may be desirable to change the way that negation is handled. Rather than listing words such as “none”, it may be desirable to treat negation as a noun phrase. Table 65 illustrates some examples of words / phrases that can be modeled by a Quantifier constraint.

  Table 65: Words / phrases modeled by Quantifier constraints

One skilled in the art will understand that the above description of word and phrase examples is not intended to describe specific limitations on linguistic modeling, but rather to explain domain and language independence. I will. In general, LOM can model any number of languages.

D4. Frame Class: Lexical Semantic Structure The following description relates to one aspect of a possible implementation of a LOM object producer (analysis engine), called the lexical semantic structure (LSS). This particular aspect has been developed in conjunction with LOM, but many other implementations can be used to output a LOM object. LSS was also used in the design process for LOM types.

  Lexical Semantic Structure (LSS) is based on common language behavior and child language acquisition generalization for natural language input normalization across multiple languages and across multiple language categories. LSS provides a method for mapping natural language elements to lexical semantic classes. One such application can also include mapping lexical semantic structures that represent natural language input (linguistic utterances) to a language object model (LOM).

  The LSS includes a set of lexical semantic categories and a method for assigning natural language input to one or more of the set of lexical semantic categories. Each category in the set of lexical semantic categories implies mapping natural language input elements to syntactic categories and semantic role inventory. More specifically, each category implies mapping one or more syntactic categories to one or more semantic roles. As used herein, the term “syntactic category” refers to a structural element of a sentence (eg, subject, object, prepositional phrase, clause complement, modifier, etc.). The phrase “semantic role” refers to the identification of a function of a particular syntactic category within a particular utterance—for example, the subject generally refers to the role “who” (such as an actor, subject, actor, or cause of action). Assigned and direct object is “what” (such as patient, affected, done-to, or effect of action), and modifiers are various roles (source, goal, time, etc.) . It will be appreciated that the embodiments shown above are provided for purposes of illustration and are not intended to be exhaustive. Finally, as used herein, the term “normalize” or “normalize” refers to the process of extracting semantic roles from a particular syntactic representation.

  Inventory and semantics are derived from common language behavior and child language acquisition, and are based on the generalization that natural language lexical semantic features share some properties. With respect to linguistic anchoring and semantic details, the LSS is more intelligent than modeling artificial intelligence systems that transition from language to semantic reasoning based on world knowledge and apparent synonyms. Placed between a detailed lexical analysis framework. In other words, all languages have a language structure that can be mapped as default. In addition, each natural language has a number of non-default mappings from syntactic categories to semantic roles. Non-default classes with semantic roles that are farther in the causal relationship than the subject and object are rare.

  In the default vocabulary semantic structure, as described above, a transitive sentence such as “John broke the glass” is modeled by classifying a sentence subject as “Who” and an object as “What”. The modifiers are identified in an order (or morphological indication) that represents the temporal evolution of the causal chain. That is, modifiers are derived from the semantic roles played by adverb modifiers such as additional case markings (indirect objects) and prepositional phrases. In the phrase “John broke the glass for me”, “John” is the subject, “glass” is the object, and the phrase “for me” is labeled as an indirect object closer to the object of the sentence.

  The default intransitive sentence usually includes an agent or “Who”. For example, the phrase “John ran” includes the actor “John”. Although less common, the single term is “Patient”. For example, the phrase “the glass block” is affected by the phrase “the glass” and the sentence can be modeled as if the original sentence was “[Something] block the glass”. .

  If a semantic role is included in the LSS inventory, it must appear as a syntactic category in some languages and is applied as a term or modifier across a range of nouns and verb classes. These roles therefore have both linguistic mooring and semantic generality. For example, the phrase “the office” is Source in each of the following examples.

1. John left the office .
2. The office emitted smoke.
3. John went out of the office .
4). The man from the office called.
In each case, the source is identified based on the verb class and its behavior in the semantic / integrated test. Referring to Example 1, the source is the verb object in this class. The verb “left” and the transitive verb “to leave” (and, inter alia, “to exit”) cannot take additional sources. For example, “John left the house out of the Yard” does not mean “John Went out of the House and out of the Yard”. In Example 2, “the office” is the subject of a sentence based on the behavior of the verb class illustrated by “emit” for a similar semantic / syntactic test. In examples 3 and 4 above, the semantics of the prepositions “out of” and “from” generally assign source roles to their objects.

  LSS is a method of associating a set of lexical semantic categories and natural language input with one or more categories of the set of lexical semantic categories. The method includes a set of procedures that associates natural language content with a set of lexical semantic categories and rules and applies the set of procedures to the natural language input. As used herein, the term “method” means a collection of procedures that associates the contents of a natural language input with a set of lexical semantic categories. Each lexical semantic category is associated with one or more syntactic categories, one or more roles, and one or more syntactic categories. Includes mappings between roles. Furthermore, “method” refers to a rule for applying a collection of procedures to natural language input. In some cases, a “method” may include a heuristic that determines when the different stages of mapping the content of a natural language input are complete. The term “method” is a collection of techniques, rules, and procedures that are adapted to associate and / or normalize the content of a natural language input to one or more language categories of a set of language categories. including.

  The LSS helps identify semantic roles across syntactic categories (verb subject / object, prepositional phrase object modifiers, etc.) as normalization structures. Furthermore, in LSS, syntactic categories can be associated with semantic roles across multiple languages. This normalization is accomplished by identifying not only the syntactic category class but also its semantic class term and associating the identified term with the appropriate lexical semantic category. A lexical semantic structure can then be extracted from the specific syntactic representation.

  When used in conjunction with a language object model and a semantic programming language (and associated user schema), semantic ambiguities in many linguistic categories are reduced. For example, the preposition “for” can be expressed in terms of beneficiary of action (I bout a dress for my daughter), purpose (I go to California for the beaches), time range (I went to school for 20 y, (daughter) etc. are identified. However, within a given application, only a limited set of possibilities is relevant to the context. Therefore, much of the semantic ambiguity is excluded by context.

  FIG. 11 is a simplified conceptual block diagram illustrating a lexical semantic structure (LSS) 1100 according to one embodiment of the invention. LSS 1100 includes a set of lexical semantic categories 1102 and methods (procedures and rules) 1104 that map elements of natural language input 1106 to lexical semantic categories 1102. In the illustrated embodiment, the mapped elements representing the natural language input 1106 are then provided to the analysis engine 1108 for mapping to the language object model (LOM) 1110 and the LOM representing the natural language input 1106. An object 1112 can be output. One skilled in the art will understand that this method applies not only to runtime, but also to the approach in developing LSS classes at design time. More specifically, the LSS can be applied to natural language processing at runtime to map natural language input in various languages, various language categories, various analysis engines, etc. Further, the LSS class is notified to the program code at the time of design.

  In general, the LSS identifies a group of frames and entities that share syntactic and semantic frames that differ from the default pattern in one of the supported languages. In general, lexical semantics is a field of language that mainly deals with the meaning of words. Lexical Semantic Structure (LSS) theory relates to the relationship between the meaning of words and the meaning and syntax of sentences. Furthermore, LSS theory deals with differences and similarities in lexical semantic structures between different languages.

  Generally, Frames has two default patterns, a transitive verb default pattern and an intransitive default pattern. The transitive default pattern links Who slots to subject positions and Link What slots to object positions. In contrast, the intransitive default pattern lacks What slots and object positions. In the following examples, both are prefixed with a verb type.

[User] _Who types [email address] _What .
[User] _Who types.
Frames may differ from the default in both linking (the way in which frame slots are arranged by grammar) and term structure (number of slots). For example, in the non-default linking type, the non-verbal case, which is a verb class, has a different linking pattern with respect to the intransitive pattern as seen in the following frame, preceded by the verb “increase”.

[Users] _Who generally increase [the font size] _What .of headers.
[The font size] _What generally increases in headers.
In this case, the subject of the intransitive verb is the same as the object of the transitive verb and is linked to the What slot. In linguistics, these non-versus-case non-default linking types are sometimes referred to as “nobility” verbs after the case marking pattern of certain languages. Such verbs generate an additional non-default linking pattern of intransitive verbs in addition to the default linking pattern.

  In another non-default linking type, the verb class AsDefault default expresses Who or What terms as italic terms. For example, the interrelationship in English represents the added Who or What part as an object of Accompaniment constraint.

Added Who: I chatted with John to John and I chatted.
What: I merged file A with File B ~ I merged File A and B.
Other languages represent terms that express interrelationships as additional pronoun terms and that are related to pronouns or that identify or define an object without describing the object. These are also handled under Accompaniment constraints.

  Many verbs have syntactically explicit arguments (indicated by idiosyncratic prepositions) that appear to be semantically related to What slots. That is, if the verb is an intransitive verb, the prepositional phrase is not semantically classified into one of multiple constraint categories, and the phrase can be rephrased directly with the object (or translated into another language) It can be handled as linking to What slots. Table 66 provides several examples that illustrate the phrase that triggers Oblique as the default slot.

  Table 66: ObliquiresDefault

These are associated with semantically coherent classes (hope for, watch for, wait for) or individually for a set of verbs that take a specific preposition in this way as a sort case Can be labeled (eg, find and look for ).

  Verb classes may differ from the default by having slots in addition to (or instead of) Who and What in the frame. In addition, some classes of verbs link syntactic subjects or objects to LOM constraints rather than to Who or What slots. That is, either or both of the default slots are replaced by constraints.

  The SubjectAsRestriction pattern links the subject to constraints, not to What slots. For example, the verb “receive” takes “Goal” as the subject.

[The website] _Goal received the data.
[The garden] swarmed with bees. ~ Bees swarmed in the garden.
Similarly, the ObjectAsRestriction pattern presents a frame whose syntactic object is Goal instead of What. For example, the verb “enter” maps to a frame in which the syntactic object is Goal or Location instead of What.

Enter [the chat room] _Goal (compare "Enter in (to) the chat room", "Go in the chat room")
The frame may also differ from the default in that it is semantically skewed with one or more additional constraints. The AdditionalRestriction pattern links an additional constraint to a proposition or clause complement in addition to the default slot. For example, for a state verb change, take an additional Goal (as in the case of the verb “reset”), or take both a Source and a Goal (as in the case of the verb “change”), as shown below: Can do.

Reset [the default font] _what [to Times New Roman] _Goal .
Change [the font] _what [from Arial] _Source [to Times New Roman] _Goal .
In addition, Frames can be made different from the default in various ways, such as combining one or more of the non-default linking types (Unaccumulative, SlotAsRestriction [subject or object], and AdditionalRestriction) described above. In addition, verbs can present multiple frames that can be interpreted to take different meanings. The default frame persists in one sense of “enter” and SlotAsRestriction persists in the other sense. The verb “enter” may be context dependent.

Enter [the data] _What (into the form).
Enter [the chat room] _Goal
The keyword “keep” takes a default frame and three non-default frames with different meanings. For example:

Default : Keep [the file] _What
AdditionalRestriction (Location): Keep [the file] _What [on the desktop] _Location .
AdditionalRestriction (Goal): Keep [Bill Gates] _What [from emailing me] _Source
Unaccusative : The data won't keep.
In general, it is desirable to have a lexical semantic structure frame across all supported languages for verbs that are different from the default in at least one language. For the purposes of this disclosure, it is assumed that this is correct for both transitive verbs and intransitive verbs.

  For some verbs (such as “expand”, “increase”, etc.), only unconformal patterns are valid for intransitive verbs. For other verbs, non-matching pattern linking is an optional option.

  Table 67 illustrates some examples of phrases / words that can be modeled by LSS Frames with additional constraints. In each example, the constraint either replaces the default term or adds a term to the frame. In principle, each constraint may appear at the subject position, at the object position, or as an additional proposition. A few constraints add participants to the Who and What slots as described below. Related noun phrase (NP) frames are also given.

Table 67: Accompaniments modeled by LSS Frames with additional constraints
Meet: My daughter and I met
Chat: My friend and I chatted.
At the object position
Accompany: My daughter accompanied me to Minneapolis.
In English, additional constraints are usually preceded by the pronoun “with” or perhaps “against”. Choose pronouns or pronoun phrases for related meanings in various verb subclasses. Samples are shown in Table 68 below.

Table 68: LSS Frames with additional constraints
Abscond: The Enron executives absconded with the money .
Accommodate: indulge
Accredit: accredit, credit
Ache: ache, burn, itch
Arrange
In English, Accompaniment constraints can also add participants to Who and What slots. This is especially true for frames where this constraint is a modifier, but is especially common with “mutual” verbs. Table 69 shows some examples of Oblique as default slots.

Table 69: Skew as default slot
Who
Subject interaction
Chat: I IMed with Mary-Mary and I IMed; chat, discuss, talk, visit
Agree
Alternate
Unaccusatives: The file merged (together) with the data ~ The file and the data merged (together).
What
Object mutual relationship:
Merge: I merged the files with the data, I merged the data and the files
Acquaint: I familiarized them with the topic; acquaint
In English, additional constraints are prefixed with PP “for” for “Allocation”. Various verb subclasses take this PP for their associated meaning. Samples are shown below.

Adapt: Adapt the movie for the stage.
Allocate: Allocate funds for linguistics; allocate, appropriate,
Appropriate: Appropriate funds for increased wages
Assign: Assign a day for the performance
Nominate: Nominate candidates for congress
Transcribe: Transcribe the music for trumpet
Train: Train for a marathon
Secondary predicates on AsBeing constraints can be used as additional constraints. Some examples of phrases are shown in Table 70 below.

Table 70: AsBeing constraints secondary predicates noun phrases
Make me administrator
Additional phrases
mark messages low-priority
judge the data correct
mark that completed
mark low priority
judge the data correct
Pronoun phrase (as) variant
mark task one as done
Mark messages as follow-up
mark that as completed
mark as low priority
judge the data as correct
Additional constraints
Show my status as busy
use as text file
save as file.doc
Log in as Administrator
put this message as message number two
Additional constraints on the Beneficiary constraint are shown in Table 71 below.

Table 71: Beneficary with additional constraints
At the object position
Benefit: Relaxed stock option laws benefited Enron; benefit, gain, profit
Unaccusative: Enron benefited from relaxed stock option laws
In indirect object position
Benefit: Relaxed stock option laws benefited Enron; benefit, gain, profit
Unaccusative: Enron benefited from relaxed stock option laws
Additional constraints PP-for and indirect objects
Build: arrange, assemble, bake Create: design, dig, mint
Prepare: bake, blend, boil, clean, clear, cook, fix, fry ...
Performance: dance, draw, ding, play, recite ...
Get: book, buy, call, cash, catch
Some of the constraint types may not be applicable for verb frames. However, additional constraints can still be invoked, such as when a prepositional phrase introduces a comparison set.

Direction constraints may require additional constraints as in the case of the phrase “move the cursor up (the page)”. Furthermore, additional constraints may be required if the directional element is synthesized within the verb itself (such as “the stocks rose / fell / advanced / retrated ” or “ rotate the picture”).

  An LSS with additional constraints can be understood from the following words and phrases along with examples of constraints included in the subject position.

This document exemplifies table construction
Sample code illustrates possible applications.
Range constraints typically fall within object locations or additional constraint locations. All forms of motor verbs can take an Extent object (eg, “walk the mall”, “crawl the web”, “run the marathon”, etc.). Examples of phrases that can be modeled using extent constraints are shown in Table 72.

Table 72: Examples of phrases modeled by Extent constraints
The crawler traverses the web .
The data in this spreadsheet spans several builds .
Additional constraints
I want a border around this text .
Maintain a uniform appearance throughout the web site .
Run through the spec before the review.
Goal constraints may require additional constraints, especially with respect to class or state changes. The scope of prepositional phrases that behave individually as Goals with some verbs may vary from implementation to implementation. Examples of prepositional phrases that behave personally as Goal include “save as file.txt” (“save to file.txt”) and “reschedule for 5:00” (“reschedule to 5:00”).

  Some verbs may need to take a personal goal in either Bitrecs (if Goal behavior is by a single verb) or LSS class (if the item's class takes a personal goal) is there. Additional goals are simply added and patterns can be drawn from the vocabulary into the class and processed as discovered.

  Additional constraints associated with the location can be modeled as illustrated in Table 73 below.

Table 73: Location
Keep, Stand, CausedGoalOfMotion
Place change in subject position (Levin 2.3): The garden swarmed with bees (cf. Bees swarmed in the garden)
At the object position
Search: Canvass the neighborhood , Search the web
Additional constraints
Keep: Keep the file on the desktop (hold, keep, locate, store)
Get: Find a book on Amazon.com
Intransitive
Stay: Stand here, Stay home
Means constraints can also be modeled with additional constraints as shown in Table 74.

Table 74: Means Tool subject: The knife cut the cake
Additional constraints
Adorn: adorn, festoon, decorate
Adulterate: adulterate, alloy, pollute
Anoint
Afflict
Aid: aid, assist, help
Analogize
Anoint
Answer
Arm
Assail: attack,
SortOrder constraints can also be modeled with additional constraints as shown in Table 75.

  Table 75: SortOrder

  Similarly, structural criteria constraints can also be modeled with additional constraints as shown in Table 76.

  Table 76: StructureCriteria

  In general, classes that take a Time term can be processed as classes that take a Measurement constraint of type Time, but they can implement a complete time representation. For example, the phrase “I spent at least an hour from 9 to 5 every day for weeks looking for a piano.” Can be modeled as a class that takes measurement constraints on time terms or type Time.

  Table 77 illustrates some example Topic phrases that can be modeled using additional constraints.

Table 77: Topic
Spact: talk about X, talk X, remind X that Y, book on Martin Luther
In subject position
Her finances don't concern you; concern
At the object position
Discuss: The article addresses adolescents in the 20 ^* t ^* h century ; address, cover, discuss
Additional constraints
PP [(about, concerning, on, regarding)] takes either NP objects (about cats) or clausal eobjects (about John coming to Seattle)
PRPRTCL
The object of the address can be the recipient, not the topic.

D5. Entity Classes This section describes where data is collected based on the types of entities supported as SPL libraries, such as Person Entities, Place Entities, and LSS Entities. Furthermore, the SPL library may include classes of noun phrases (LSS entities) corresponding to each LSS frame class, particularly classes that take additional constraints. :
The SPL library can further include a Restriction class. For each constraint, there is a (small) set of noun phrases that can be used to specify the constraint. In SPL, these are identified in a small set of structures and can signal the presence of constrained slot fillers. For example, if “topic” is the subject, object or connective, the Topic constraint slot filler (bold part) is in the complement position.

Find discussions where the economy is the topic.
Find discussions where the topic is the economy.
Similarly, if “topic” fills the AsBeing slot, the entity it attaches fills the Topic slot.

Find discussions that have the economy as a topic.
These structures should be normalized with the structures shown as Topic constraints.

Find discussions about / on / concerning / regarding the economy.
Synonyms such as “theme”, “meter”, “subject”, “issue”, “focus”, and “area” may also be TopicEntity. Furthermore, the developer can add topic words that are strongly limited by the developer scenario, such as “subject in an email application”, to the entity class.

E. Semantic Programming Language (SPL)
E1. Architecture SPL is a dedicated programming language that allows application developers to build rich natural language (NL) compliant command and control (C & C) functions for applications by using the accompanying runtime platform. it can. (See Appendix I for details on commands and control scenarios that can be enabled in SPL, and for example, the types of commands that support Outlook.)
SPL is an authoring solution for facilitating the work of extracting meaning from an utterance and facilitating actions based on the meaning. SPL is designed so that it can be scaled to complex utterances without burdening the scalability on the developer side. The goal of SPL is to facilitate authorship for both speech and text without putting a heavy burden on the developer. In particular, it would be desirable to provide an NL authoring tool that allows developers with little or no knowledge of language / semantic analysis to develop NL applications. In general, SPL is designed to minimize the difference between authoring for speech input and authoring for text input. However, there are problems with speech recognition, so it may be necessary to show the developer some differences.

  NL applications can be created to interface with the analysis engine via LOM without SPL, but such programming is difficult, requires more knowledge on the linguistics required by the developer, and relates to vocabulary structure. Increased housekeeping effort. Eventually, SPL can facilitate development by extracting specific elements so that developers can concentrate on application functions rather than analysis components.

  This is the core behind a dedicated programming language, which allows developers to avoid housekeeping and piping connections and concentrate on the task at hand (in this case, its NL-enabled application). Developers can use SPL to represent the basics of programming space in a natural and intuitive way.

  In general, natural language semantics are complex and inherently ambiguous. Humans use a great deal of world knowledge and context to understand and clarify meaning. In fact, humans are not so conscious of this process because they naturally make this understanding and clarification.

  If the application can act on the meaning of the utterance, not only must it determine what the utterance semantics mean to the application, but also the authority to clarify the meaning according to their knowledge and context Must also have. Thus, SPL provides developers with the ability to make inferences about application areas and to make that inference deeply and meaningfully affect semantic analysis. Deep integration with application specific reasoning is inherently built into SPL.

  In one embodiment, at a high level, it is the SPL approach that allows developers to author only for utterance semantics, not for syntax. In some embodiments, a back-door means of accessing the syntax may be provided. This is achieved through LOM (described in Section D above). Simply put, LOM models the semantics of utterances (story content) in a region-independent manner. In the SPL programming model, the semantic model is realized by various methods.

  Through utterance resolution for SPL programs, SPL builds a strongly typed, region-dependent model of the content of the story bound to entities in the application. It is also worth pointing out that multilingual support is fairly easy to implement because semantics are separated from syntax.

  The SPL consists of two main parts. The first is strongly typed, procedural, event driven, and object oriented languages. In one embodiment, SPL is based on C # (an object-oriented type safe programming language for building enterprise-scale applications) that is very familiar to mainstream developers today. In other embodiments, the SPL is written entirely in C # using attributes. When designing SPL, it was important that SPL was not a new programming approach. This is because the existing knowledge and experience of the developer are utilized and not wasted. The second part is a runtime that builds a domain-dependent model of the story content according to the language semantics of SPL.

  SPL allows developers to bind the semantic meaning of speech to an existing application interface or object model without affecting the existing application. Using SPL, developers can write code that infers knowledge about a domain at an appropriate location. Since it is compiled into Net Common Language Runtime, developers can use Microsoft (registered trademark). The code can be freely written in any programming language including the NET (registered trademark) programming language.

  The basic syntax of SPL is entity (noun), frame (verb), constraint (relationship between entities), command (application task entry point), NamedEntityes, and Denoters. These are the primary first type of SPL. The language is command-centric in design because the natural language support of the application is designed for command and control (C & C) functions.

  Before describing the SPL framework in detail, a simple example of SPL will be described so that you can imagine the image and understand the rest of the disclosure in the text. Table 78 illustrates SPL code that processes a “send email to Bob” command scenario. This command scenario will be referenced many times in the rest of the disclosure.

  It will be appreciated that starting from the highest level in “command”, the SPL code is written into the LOM model already installed (see section D). The command is authored against the frame. A frame is usually an object that represents a verb. A basic frame is a frame that represents one verb and is supplied by the analysis system. Developers can also define their own verb frames, which are features described in more detail in the section describing Frames.

  Table 78: “Send Mail To Bob” SPL Code

  SendMailCommand defines the entry point of an application task that uses MySendFrame when the object being sent (“DoneTo.what” slot) is MailEntity. This command encapsulates the task, allows the developer to perform specific initialization and cleanup, and sets an entry point to the application on the platform.

  Table 79 illustrates the MySendFrame SPL code.

  Table 79: MySendFrame

The MySendFrame code block defines MySend, which is an application-specific frame that inherits from a region-independent basic “send” frame (provided by the platform) and subtypes “DoneTo.what” into MailEntity. “DoneTo.what” is an object to be sent.

  The semantics of sending to “to Bob” are captured by a Goal constraint (supplied by a platform, eg, SPL based on LOM), which is linked to “send” via a “with restriction” clause. In addition to this linking, the entity sent to “Bob” is also grounded to the RecipientEntity.

As already explained, Restrictions is a typed semantic relationship, usually between entities. The SPL platform has a basic set of predetermined relationships. Developers can subtype the basic set of constraints to create their own relationships. Some examples of predefined constraints are Location (“mail in Inbox ”), Time (“delete after 3 days ”), Postessor (“ Bob's book”), and Topic (“mail about cats ”).

  One important constraint is that syntactic variants are normalized by the semantic platform. For example, Topic can be semantically expressed in various ways such as “mail about cats”, “mail with cats as the subject”, “mail reporting cats”, “mail with subject cats”. Different languages express Topic semantics in different ways. Since these variants are normalized by the semantic platform, the developer need only program against the Topic constraints rather than match each possible semantic variant.

  Table 80 illustrates the syntax of a MailEntity constraint according to one embodiment of the present invention.

  Table 80: MailEntity

In this example, MailEntity is defined and represented by a list of words. Representing words are usually defined separately and are usually defined in their own files (such as localization files).

  Like frames, entities can also have constraints that apply to them. Table 81 illustrates the syntax of an entity with constraints.

  Table 81: Entities with constraints

  From the developer's perspective, this syntax declares that the mail item can have properties (constraints) that are in MailFolder. From an entity-relationship perspective, MailEntity and MailFolder are related through a Location relationship. At runtime, an instance of MailEntity with a Location constraint represents a set of mail items that are constrained to be in a particular MailFolder.

  For the utterance “send mail to Bob” or “send Bob mail”, the SPL runtime platform matches and resolves the SendMailCommand command. FIG. 4 is a flow diagram for tracing a solution through SendMailCommand code according to one embodiment of the invention. One skilled in the art will appreciate that command resolution will vary from implementation to implementation. For example, referring to Table 78, the Begin, Success, and Failure clauses are each optional. The OnResolve clause includes any one of these clauses, any combination of clauses, or none of the clauses, depending on the particular implementation.

  It will be appreciated that for purposes of the flow diagram of FIG. 4, the parsing engine has already mapped the utterance to a type defined in the declaration schema and derived from LOM. For example, the Denometer object has already been considered by the analysis engine. Furthermore, it is assumed that the code includes a Begin clause, a Success clause, and a Failure clause for each element. It is also important that some details are omitted from the flow chart, because, in part, such details are specific to the implementation and can be tricky to explain. is there.

  Referring now to FIG. 4, after receiving the utterance, the sendResolution command's begin resolution clause is invoked (block 400). If the begin resolution clause is unsuccessful, a different command is invoked, or (optionally) the interpreter simply fails to resolve, depending on the particular implementation and other commands that may be available in the application. (Block 402).

  If the call of the sendResolution command's begin resolution clause is successful, the SPL interpreter calls the begin resolution clause for the MySend Frame used by the SendMail Command (block 404). If the mySend Frame's begin resolution clause fails, the SendMail Command failure clause is called (block 406), and the SPL interpreter may optionally call a different command or fail to resolve (block 402).

  If the myResolution Frame's begin resolution clause is successful, the MailEntity Begin Resolution clause is called (block 408). If a MailEntity's begin resolution clause call fails, what happens next depends mostly on the implementation. As shown in the figure, the MailEntity begin resolution clause implies a general failure (Option 1), is ignored (Option 2), or performs other operations, depending on the specific implementation. And clarification of the utterance is performed (block 410). These “other operations” may involve attempts to use different constraint clauses for the portion of the input that is being resolved. Constraint clauses can even be clauses for completely different constraints due to ambiguity.

  If the failure is understood to imply a general failure (option 1), the SPL interpreter may call a different command or fail to resolve depending on the option (block 402). If the failure is ignored (option 2), the SPL interpreter simply calls the success clause of the MySend frame (block 420), calls the sendMail command success clause (block 422), and sends Sendmail Command Object "actual interpolation". It can only be added to the list (block 424). If other operations are required by the development code, the SPL interpreter may further perform processing such as callbacks to client applications that attempt to clarify the communication and / or utterance with the natural language analysis engine. it can.

  If the call of the MailEntity begin resolution clause is successful, the MailEntity success clause is called (block 412). Next, the Restriction begin resolution clause is invoked (block 414). If the Restriction begin resolution clause fails, flow proceeds to block 410 (described above). If the restriction's begin resolution clause is successful, the Restriction success clause is called (block 416). The Restriction clause is called on the MySend Frame with the MailEntity slot (block 418). If this call fails, flow proceeds to block 410 (described above). If the call is successful, the MySend Frame success clause is called (block 420), the SendMail Command success clause is called (block 422), and the SendMail Command object is added to the "actual interpolation" list (block 424).

  It will be understood by some applications and developers that code blocks cause a virtually unlimited number of permutations. In one embodiment, the default for failed resolution may be to call a failure clause to stop execution. In other embodiments, the developer may want the application to instantiate a partial object to take advantage of the domain context to resolve ambiguity and perform partial execution of the utterance. In each section, there are various possibilities for developers to freely write code that performs application-specific functions.

  In a preferred embodiment, the RecipientEntity can also author with a Named constraint clause that takes a RecipientName as a slot. RecipientName will be a NamedEntity that is defined such that an instance of the recipient name is placed in the entire user input before the semantic processing is performed. As a result, it is possible to reliably recognize the RecipientEntity instance.

  Assuming that “Bob” is a valid Recipient Entity, as already mentioned, Recipient Entity is defined somewhere in the program. In this instance, “with restriction” is in the MySendFrame used by SendMailCommand. The code inside the “with restriction” clause is called. Using the code inside the “with restriction” gives developers some freedom to reject this constraint. If this clause is successful, the constraint is accepted. Otherwise, the other “with restriction” clauses are called consecutively until one of them succeeds, or the constraint is ignored if none of them execute. In other embodiments, failure resolution is invoked when the resolution clause fails. Finally, the success sections of MySendFrame and SendMailCommand are called in that order (blocks 420 and 422).

  In general, one skilled in the art can configure constraints and other objects implemented by SPL in a LOM to invoke any number of functions or processes upon either success or failure. You will understand what you can do. The flow diagram is a simple diagram showing how the flow example proceeds. However, many other variations are anticipated and there are as many client application candidates to which the present invention is applicable.

  In this solution process, a connected graph is generated. Each entity is a node of the connected graph, and the relationship between the entities is defined by LOM and validated against the application area. One skilled in the art will understand that nodes and relationships are strongly typed. A connected graph represents what is said in the language of the domain.

  Note that the presence of SPL objects (commands, entities, frames, and constraints) is determined by the authored code in conjunction with semantic analysis. In general, a solution that matches against a frame, entity, command, or constraint involves determining the existence / validity of those objects with respect to the application area. These objects do not actually exist (not valid) until the constraints are met. Similarities can be said for the C # object syntax. In C #, an object can provide a constructor for writing code that allows a developer to throw an exception. An exception prevents the object from being present if some constraints are not met.

  The "system" calls these constructors when trying to create an object. Thus, the authored code in the constructor can determine the existence of the class. Conceptually, the core SPL solution takes this concept one step further, formalizes it, makes it richer, and makes it an inherent part of the system. The constraint that must be met is a combination of domain-authored knowledge and semantic analysis of the utterance.

D3. Inheritance Concept encapsulation and composition are realized by conventional object-oriented techniques (object reuse, inheritance, polymorphism, etc.). For example, to model “send mail to Bob” and “send instant message to Bob”, declare MySendFrame to be a supertype of MailEntity and InstantMessage. Table 82 illustrates MySendFrame according to one embodiment of the invention.

  Table 82: MySendFrame

Thus, individual commands for “send mail” and “send instant message” can be defined as follows.

command SendIMCommand uses MySend <DoneTo.what: = InstantMessage>;
command SendMailCommand uses MySend <DoneTo.what: = MailEntity>;
The concept of “sending item to recipient” can be encapsulated by MySendFrame and reused by SendIMCommand and SendMailCommand. It is also possible to reuse MySendFrame synthetically. An example of this is shown in Table 83.

  Table 83: MySendFrame

In a broad sense, the above description captures the meaning of “mail sent to Bob”.

  In general, using SPL, a developer can infer application areas and make the inference deeply and meaningfully affect semantic analysis. In SPL, this inference can be done declaratively and procedurally. Referring back to the MailEntity syntax, this syntax establishes a declarative constraint that, for example, MailEntity is an entity represented by a list of words as specified in MailWords, and that this syntax is in the location of MailFolder Can be constrained. Table 84 shows MailEntity.

  Table 84: MailEntity

Utterances such as “mail in Foo” and “mail located in folder Foo” are successful for MailEntity because the Named constraint clause on MailFolder accepts all strings.

  In some cases, it may be desirable to create code that determines whether “Foo” is really a currently valid folder in the current user's mailbox. The only way to do this is to write procedural code that checks the validity of "Foo" at runtime. Table 85 shows the syntax of the MailFolder entity that checks the validity of the Folder name at runtime.

  Table 85: MailFolder using procedure check code

If “Foo” is not the currently valid folder, MailFolder resolution fails. Depending on the details of a particular implementation, failure may mean a general failure. Apart from that, if a constraint fails, the constraint may be ignored. In one embodiment, if MailFolder resolution fails, MailEntity also fails, and so on, following the resolution chain (eg, implying a general failure). In a preferred embodiment, the MailFolder constraint is simply ignored if MailFolder resolution fails. One skilled in the art will appreciate that this is a simplified example. Depending on the implementation, fairly complex validity checks can be used.

  Another way to achieve this effect is to create a NamedEntity FolderName and use it as a slot for a Named constraint.

  A good side effect (start, success, failure, and constrained) of calling a clause is that the developer can write code that binds the semantic object to the application object. For example, in the Named constraint clause, a developer can create code that obtains a reference to a folder application object when the name is valid. Table 86 illustrates the syntax for such a reference.

  Table 86: Code to bind semantic objects to application objects

This syntax effectively binds an application specific object, MAPIFfolder, to a semantic object, MailFolder.

  In general, developers can easily create code that infers about the context and state of the application at the key points of analysis. This inference can affect the final solution analysis. For example, when determining whether “Bob” is a valid recipient, the developer can create code to access the database of the current user of the system. If it is not a valid recipient, the developer can write code to handle the failure. For example, the developer can display a pop-up window or dialog to reveal the user and generate a refresh immediately upon failure. By returning immediate feedback to the user at the time of failure, the system facilitates the emergence of crisp and well-developed applications.

  Alternatively, developers can create code that prevents resolution for commands at the highest level SendMailCommand when the application is not in the proper state. This deep integration between semantic analysis and reasoning about domain knowledge is very important in understanding and clarifying natural language.

  In SPL, the developer can easily refuse unauthorized analysis by allowing the developer to write code that rejects the solution in the clause. In general, authors can claim a lot of control over successful and unsuccessful interpretations. In some cases, it may be desirable for the author to reject some interpretations early in the process. In general, the sooner the creator clarifies (remove ambiguity), the easier it is to manage the ambiguity in the application. The less ambiguity, the less interpretation. An application authored for a natural language must have some mechanism for managing multiple interpretations. The author creates code that evaluates the soundness of the interpretation while the interpreter is making decisions, or performs semantic analysis to clarify and select from a collection of interpretations. Create code to be executed (post-processing). It's not difficult to see the former being easy to manage and code.

  Furthermore, the earlier the interpretation is rejected, the faster the best interpretation will be found and the more accurate it will be.

  In some cases, the author may wish to reject the interpretation later in the process. Rejecting the interpretation at an early stage significantly increases the frequency of making callbacks to the client application to examine the state and / or context and infer about the application's object model. If callbacks are made across the network, frequent callbacks can slow system operation. For example, transmission delays can make the system unusable. Using SPL, the creator has full control over what callbacks are executed when. Thus, developers can independently determine the correct balance between callback and post-analysis clarification logic depending on the nature of the client application.

  Instead, in some implementations, the developer may want to infer the entire solution before deciding whether to reject the solution. It may not be possible to determine success or failure due to isolated fragments, and global reasoning for the resolved tree is required.

  In SPL, depending on the needs of the developer and the needs of the client application, the developer is left with the choice of how to balance early rejection and later rejection.

  As already explained, the resolution of frames, constraints, and entities by the SPL runtime is essentially building a domain-dependent model of speech. Details are assured in this way.

  In natural language, syntactic syntax can be used to express multiple meanings. As a very simple example, consider the preposition “on” followed by a noun. For example, consider the phrase “on Foo”. The phrase “on Foo” may refer to a Location (such as “book on table”) or may mean Topic (such as “book on Seattle”). In order to determine which words are correct, the words must be clarified. This clarification can only be made by the application. For example, Table 87 shows Amazon. The syntax for validating com is shown.

  Table 87: Bookstore syntax

When “book on Foo” is resolved, BookEntity does not recognize Topic, and therefore does not output a Location object in semantic analysis. The resolved model of what is said does not include Location. This “orientation” is even more apparent in adjustment (and / or), negation, and clause modeling.

  For coordination purposes, the SPL code defines how entities and their modifiers are distributed to conjunctions and disjunctive conjunctions. For the utterance “find mail and notes created yesterday”, the possible modeling options are:

1. Find (mail created yesterday) and (notes created yesterday).
2. Find (mail) and (notes created yesterday).
3. Find (mail created yesterday) and find (notes created yesterday).
4). Find (mail) and find (notes created yesterday).
The method of distributing “created yesterday” and “find” along with its entities “mail” and “notes” is determined by the authored code. The possible readings are even greater for utterances that contain both conjunctions and disjunctive conjunctions. The creator does not have to know all the possibilities. The creator only thinks about the semantics of the application. For example, as an SPL creator, it is possible to code FindMailCommand so that its own FindMailCommand only recognizes entities of type MailEntity, and its own FindNotesCommand only recognizes entities of type NotesEntity. Furthermore, MailEntity does not have the concept of creation time (this is merely for illustrative purposes), but NotesEntity has it. Therefore, for the utterance “find mail and notes created yesterday”, the semantic analysis only outputs the read value 4 from the above list.

  For negation, the authored code determines how to model the ambiguity of the negation scope. For example, take the utterance “Do n’t allow mail from Joe”. This phrase can be interpreted as follows.

    1. Don't allow mail from Joe (block it instead): Denial relates to “allow”.

    2. Don't allow mail from Joe (but allow messages from him): Denial relates to “mail”.

3. Don't allow mail from Joe (but allow mail from someone else): Denial is related to “Joe”.
The authored SPL program determines the extent of negation and how to model. The semantic analysis engine supplies all possible readings.

  For clauses, the authored code determines whether the clause is modeled as a frame-based constraint (a constraint preceded by a verb) or as one of the predefined constraints. For example, in “book that discussions Foo”, the section “that discusses Foo” can be modeled as a Topic constraint or can be modeled as a frame-based constraint on “book”. Table 88 shows an example of BookEntity syntax.

  Table 88: BookEntity

  In general, from an SPL perspective, the role of an SPL program is to define a natural language semantic model of the application domain. The role of semantic analysis is to map utterances to the SPL program definition model according to the language understanding of the analysis engine.

  From a platform perspective, the role of the semantic platform is to define a highly abstract domain-independent object model of the story content. From this point of view, the role of the SPL code is to select from a plurality of possibilities provided by the platform.

  In general, the solution of an SPL program can be understood as building a domain-dependent semantic model of the story content. In the process of building this region-dependent model, region-independent objects are strongly typed and can be moored (mapped) to application objects.

E2. Type System In general, the core SPL type is command, frame, entity, and constraint. These are called resolvable types because they require resolution semantics to determine their existence.

Everything in the “on resolve” section has an association with the semantics of the solution. The begin, success, and fail clauses are all optional. There can be at most one per node in “on resolve”.

  The begin clause is called at the beginning of resolvable type resolution. By default, the clause returns "true". The developer instructs the SPL interpreter to stop resolving for this type by returning “false”. This means a resolution failure and the fail clause is called. The begin clause is a convenient place for the developer to perform initialization and check if the application is in the proper context / state to handle the type.

  The success clause is called when the type is successfully resolved. This is where developers can write code that cleans up resources and summarizes resolution results. Developers can still refuse resolution by returning false.

  The fail clause is called when the type resolution is not successful. Like the begin and success clauses, the fail clause returns “false” and in fact makes the type's failed resolution successful.

  In one embodiment, all resolvable types except commands can have any number of constraint clauses. This is explained in more detail with respect to Slots and “with restriction / Frame classes”. In other embodiments, all resolvable types, including command types, can have any number of constraint clauses. Each solveable type (Commands, Frames, Entities, and Restrictions) is described in detail below.

  Commands is a natural language (NL) compatible task supported by the client application. When developing a client application, the creator creates a command that describes the action to be processed. Commands provides task entry points to the application for semantic analysis. SPL resolution starts with a command and goes down the tree recursively. Commands is called as a response to a user command. This is similar to how Windows® events such as mouse clicks that are made in response to a user clicking the mouse are invoked. Table 89 shows the syntax of the command declaration according to one embodiment of the present invention.

  Table 89: Command declarations

For example, “Command SendMail Command uses MySendFrame” defines a SendMailCommand object that uses a MySendFrame object. The command essentially wraps around the frame object. Only one frame object can be defined with one command.

  The begin clause in a command is the location used to check if the application is in the proper context and / or state to process the command. As a result, the command can be rejected at a very early stage based on the knowledge about the application.

  In the success section, the developer can execute the command directly or package the data necessary to execute the command. This packaged data can take the form of a URL, an XML description of the task, a delegate to a function that can execute the command, and the like. The creator can simply perform additional inference in the success clause and reject the interpretation by returning the value “false”. This is useful because it allows the creator to reason globally about the entire utterance. That is, the creator can observe a fully resolved semantic tree to see if the solution as a whole is consistent. Fragments are consistent independently or in a limited context, but together they may not make sense.

  The “Unknown” command processes utterances that are not mapped to the authored command. In one embodiment, SPL forces this command to be present.

  Frames generally refer to verbs. There are two types of frames: basic frames and composite frames. A basic frame references one verb. For example, the frame find refers to the verb “find”. A compound frame is a group of a plurality of verbs that generally have the same meaning. The compound frame and its multiple verbs can be thought of as a synonym list. In general, semantic platforms provide a predetermined set of basic frames, one for each verb. In order to maintain consistency, the name of the basic frame is set to a lower case letter, and a rule that the same name as the corresponding vocabulary word is provided. In contrast, compound frame names begin with a capital letter. A semantic platform comprises a set of common composite frames. For example, the platform may comprise a Search composite frame that groups “find”, “search”, “look”, and “rumage”.

  Table 90 illustrates the syntax for defining a basic frame.

  Table 90: Basic frame

For example, the syntax of the find frame is shown in Table 91.

  Table 91: Find frame

In this syntax, the vocabulary word “find” is defined, and the basic frame that operates in the DefaultVerbClass is defined. The term “find” is referred to as a notation representing the frame find. The semantic platform defines a set of verb class behaviors that cover all verbs. Most of the verbs have a behavior that is part of the DefaultVerbClass.

  Vocabulary words do not have to appear inline. In fact, to support multiple languages, it is recommended that multiple words not appear inline. These must be defined in the own object. Table 92 illustrates the syntax of the predefined notation object.

  Table 92: Notation objects

By listing the notation words separately in this way rather than inline with the frame definition, language-dependent elements are neatly separated from language-independent elements.

  All basic frames provided by the semantic platform are defined in this way by SPL code. Developers can also define their verbs in this way. For example, in one embodiment, a developer can define a flop base class as follows.

frame fop denoted by "fop" behaves as DefaultVerbClass;
Alternatively, in a preferred embodiment, a developer can define a fop base class as follows.

frame fop denoted by "fop;
Most of the verbs (about 95%) will have linguistic realizations as vocabulary words themselves. In most cases, it is translated relatively directly into other languages. For verbs that do not behave in this way across languages, a mechanism is provided in the notation class that specifies the linguistic realization of those verbs.

  As mentioned above, a composite frame is a group of verbs. They are essentially synonym lists. When creating a composite frame, only the notation of the frame used in the plurality of groups is “inherited” by the composite frame.

  Using SPL, developers can create their own groups from basic frames and composite frames. An example is shown in Table 94.

  Table 94: Composite frame

In essence, this declaration establishes the union of all notations of the frame specified in the groups clause, removes duplicates, and then removes the notation of the frame specified in the exception clause. The exception clause is optional. For example, Table 95 illustrates a composite frame that includes an exception clause in the definition.

  Table 95: Composite frame with an exception clause

This defines a MySearchFrame that groups Search and fop notations except for the notation of find frames.

  Derived frames can be created that inherit from other frames, either basic frames or composite frames. Table 96 illustrates the syntax of the derived frame.

  Table 96: Derived frames

The issue of inheritance is detailed in section E.3 below.

  An entity is an object that can be referenced by name or by description in an application. Entities can be concrete things, such as file items and email items, but they can also represent abstract concepts such as color, texture, etc. Entities are usually represented by vocabulary words. Table 97 shows the syntax for declaring Entity.

  Table 97: Entity declaration

In order to support multiple languages, such as frames, it is recommended that notation not be specified inline. Table 98 shows an example of such a notation.

  Table 98: Notation

An author can specify a list of natural language words representing an entity using a deleted by clause. The deleted by clause is a means by which a developer makes an entity based on a vocabulary word. An entity need not be represented by a single word or a group of words. Entities can be described by their constraints. Because the processing of word forms is handled by the semantic platform, developers do not have to define various forms of words (such as “file” and “files”). Furthermore, the notation need not be specified in the utterance for the entity to succeed. However, if a notation is included in the utterance, the notation must match one of the notations in the list of entities.

  In some embodiments, it may be desirable for the notation to be optional at the time of declaration. In addition, in some implementations it may be desirable to add a mandatory notation (a word that must be included in the utterance for the entity to succeed). The presence of the “mandatory” notation can be enforced through code included in the success clause. Table 99 shows an example of mandatory notation enforced through the success clause.

  Table 99: Mandatory notation enforced through success clause

  In general, a constraint is a typed semantic relationship. The platform has a basic set of predetermined relationships. Most important in terms of constraints is the normalization of syntax variants within a language and across multiple languages. Constraints are semantic and not syntactic. Thus, using constraints allows developers to code for meaning rather than language syntax. Restrictions greatly reduce the burden of authoring and support for other languages.

  There are some restrictions on system-defined slots that have a specific meaning. In the description of LOM in section D above, code examples are shown and some of the slots are also described. Some common constraints are shown in Table 100 below.

  Table 100: List of common constraints

  There is a special constraint called the Default constraint. The Default constraint is fired by the SPL runtime when there are unresolved or unrecognized constraints on the resolvable type.

  Developers create their own constraints by inheriting from one of a predefined set of constraints, creating frame-based constraints, or defining patterns.

  In general, constraints can be applied not only to entities and frames, but also to other constraints. In general, SPL does not enforce whether to give semantic meaning by applying certain constraints. SPL allows for some exceptions to simplify semantic modeling and reduce ambiguity. Some exceptions are shown in Table 101 below.

Table 101: SPL exceptions 1. Degree constraints are only allowed in constraints.

    2. Doer and DoneTo constraints are only allowed on frames.

3. Denial is not allowed for an entity.
Constraints are applied to types using the following syntax:

with restriction RestrictionName <slot ₁ : = type, ..., slot _n : = type>;
The terms in parentheses are called slots. A “with restriction” statement is called a constraint clause. The label “restriction” was chosen to avoid some problems. For example, constraints can be labeled “properties”, but properties do not necessarily function as descriptors. For example, “mail in Inbox” can be considered as “mail with the property of being in the Inbox folder”. However, this same relationship does not coexist with quantifiers such as radix and ordinal. The phrase "three files" and "files with the property of three" are not equivalent. Furthermore, the word “property” is already used in a conventional programming paradigm (eg, “properties of a list box”). In general, it is desirable not to overload the word “properties”, and the same is true for the word “attribute”.

Instead, Entity is intended to convey the concept of set. In the SPL “entity” declaration, in practice, a set of entities is defined, and applying a constraint restricts the set. For example, the syntax for declaring a MailEntity represented by Mail
entity MailEntity denoted by "mail"
Is a declaration of an object that represents a collection of all mail items. Table 102 illustrates the syntax of constraints that apply to entities.

  Table 102: Constraints applied to entities

Here, the collection of mail items is constrained by the MailFolder location.

  Applying a constraint to a frame should be considered as constraining its action (Frames typically model verbs or actions). Table 103 illustrates frames with constraints.

  Table 103: Frame constraints

Here, the Means constraint is applied to the MyOpen frame, thereby constraining the operation of the open file to the use of Notepad.

  The same applies to constraints on constraints. For example, the Cardinal constraint represents an entity cardinality. The phrase “3 files” means any three files. However, the radix can be constrained by Ordinal, like “first 3 files”. Table 104 illustrates the constraints that apply to the constraints.

  Table 104: Constraints for constraints

Here, the restriction clause constrains the radix by applying an ordinal number.

  In general, resolvable types can apply any number of constraints to them, except for commands. Each constraint type can be applied many times as long as the signature is unique. Table 105 shows a Frame with multiple constraints along with a unique signature.

  Table 105: Frame with multiple constraints

The order in which constraint clauses fire is dependent on semantic analysis. In general, the order is based on a combination of linguistic evidence, statistical ranking, and domain-dependent learning. Some implementations can add mechanisms to enforce deterministic order. The SPL runtime fires constraint clauses through SPL language semantics and semantic analysis.

  As described above, a slot is a term that appears in square brackets (<>). Slot syntax is used to subtype slots when used. The SPL has a plurality of predefined slots of constraints. For example, in the semantic system, the Goal constraint is defined as follows.

Goal <goal: = Entity>
The goal slot has a basic Entity type and can be called area independent designation. If the developer applies this domain independent goal to a resolvable type, the developer can subtype the goal slot when applied. Table 106 shows the syntax of the Frame including subtyped goal slots.

  Table 106: Frame with subtyped goal slots

Here, the developer subtypes the goal slot into ContactItem (ContactItem must be an entity type).

  Within the constraint clause code, constraints are accessible as objects. Table 107 shows the syntax for accessing constraints as objects.

  Table 107: Access as constraints object

  In general, resolvable types can be conceptualized using an analogy with C ++ templates. The Goal constraint can be considered as a template Goal class having a general-purpose goal data member, for example. Then, the pseudo C ++ code of the above Goal constraint clause is as follows.

bool OnGoalClause (GoalTemplateClass <ContactItem>Goal);
The SPL compiler enforces proper subtyping of goal slots.

  A resolvable type consumer may want to subtype a type constraint clause. For example, the send frame consumer may want to subtype the goal slot of the Goal constraint clause using the slot syntax as follows:

command MySendCommand uses send <Goal.goal: = MyCont act Item>;
Since there can be many Goal constraint clauses applied to the send frame, it must be possible to define clauses referenced by the developer.

  Another type of constraint is an AsProperty constraint. By using the asperity attribute, resolvable consumer can subtype the slot of the constraint clause using slot syntax. This attribute is defined in the constraint clause as shown in Table 108.

  Table 108: AsProperty attributes

Here, the send frame developer has declared that the Goal constraint clause of the send frame can be subtyped by the consumer using the slot syntax as follows.

command MySendCommand uses send <Goal.goal: = MyContactItem>;
With this declaration, MySendCommand uses the send frame, subtypes the Send frame's Goal constraint clause, and makes it MyContactItem.

  In general, using the asperity attribute, code in the send frame can also access this Goal object by using property syntax. All resolvable types have a RestrictionCollection property that allows access to the currently resolved collection of constraints in code. The aspproperty attribute can be used to access the constraints that are labeled using the property syntax as shown in Table 109. For example, it is as follows.

  Table 109: Accessing labeled constraints using property syntax

  Furthermore, only one constraint of each type can indicate the asperity attribute regardless of the type of the constraint slot as shown in Table 110 below.

  Table 110: AsProperty constraint restrictions

However, this syntax can be changed on the developer side as follows, so that multiple constraints of one type indicate the attribute attribute.

restriction Goal2: Goal <goal: = UserItem>;
This eliminates the problem and the frame can be resolved as shown in Table 112 below.

  Table 112: Constraint syntax

  It is important to understand that with respect to slot ordering within a constraint clause, some constraints are defined with the system slot. For example, a Goal constraint is defined with a goal slot. When subtyping a Goal constraint in use (ie, in a constraint clause), the system slot must first be defined as shown in Table 113.

  Table 113: Slot ordering

  Entities with constraint clauses labeled as property can have constraint clauses that are subtyped when used. For example, in the ContactItem, as shown in Table 114, it is assumed that the location constraint clause is labeled as aproperty.

  Table 114: Location constraints labeled AsProperty

  The constraint clause can also indicate an obligatory, which means that the clause must be executed and succeed, or else its type resolution will fail. In order for a clause to succeed, the following criteria must be met:

    1. The constraint must be in the utterance.

    The declaration constraints (slot type) in section 2 must be satisfied.

    3. The procedure constraints (codes) in section 3 must be truly evaluated.

  Examples are shown in Table 115 below.

  Table 115: Obligatory constraints

The frame syntax in Table 115 requires that ContactItem be the goal of “send” in the utterance in order for the send frame to be resolved successfully. Therefore, “send mail” is not resolved, but “send to Bob” is resolved if it is a ContactItem in which “Bob” is resolved.

E3. SPL Inheritance Inheritance is allowed on entities, frames, and constraints. Currently, commands do not support inheritance. In general, there seems to be no need for inheritance support in commands (at this point). Commands are task entry points that do not require inheritance.

  All “inheritable” code is in the frame used by the command. As already explained, except for the resolution semantics in the on resolve clause, resolvable types are just ordinary objects. Outside the on resolve clause, SPL employs C # inheritance semantics, well known in the art. For the purposes of this description, this disclosure focuses on inheritance semantics in on resolve clauses that do not follow conventional (C #) inheritance semantics. However, in some implementations it may be desirable to deviate from traditional C # inheritance semantics in order to enable certain features of actual applications that use inheritance. For simplicity, the explanation does not go into all such possibilities and tries to simplify the explanation, which may be wrong according to the rules.

  First, it is important to understand the scoping in functions, constraint clauses, and variables of on resolve clauses. Table 116 shows the Mail Entity syntax to simplify the scope description.

  Table 116: Mail entity

Variables defined in the on resolve scope are accessible from the constraint clause in the on resolve scope, but are not accessible from outside the on resolve clause. In the above example, the integer y is accessible in the Goal constraint clause and in the function foo (), but not in the function bar ().

  A function declared in an on resolve clause is private to that clause, that is, such a function cannot be accessed from outside the on resolve clause. Therefore, foo () cannot be accessed from within bar (). The constraint clause is also private to the on resolve clause and therefore cannot be accessed from outside.

  Variables declared within the scope of a type are accessible from clauses and functions in the on resolve clause by using the outer keyword. For example, the integer x is the outer constraint in the Goal constraint and function foo (). x is accessible. Functions declared within the scope of a type are accessible from the on resolve clause. Therefore, the function bar () is assigned to outer. It can be accessed as bar ().

  The on resolve clause can be conceptualized as an extended constructor so that everything related to the constructor is private to the constructor. This means that a derived class cannot call any constraint clauses in the base class.

  An entity can inherit from one other entity. Multiple inheritance of entities is not allowed. The base entity representation is merged with the derived entity representation. As shown in Table 117, there is no hierarchy in the merged notation list (notation is flattened).

  Table 117: Merged notation list

The notation list of MyMailEntity consists of “mail”, “email”, and “electronic mail”.

  At definition time, the derived entity can also subtype the constraint clause of the base entity labeled as asperity. For example, if MailEntity has a Location constraint clause labeled as asperity, the MyMailEntity definition can be as follows:

This code block indicates that MyMailEntity inherits the recognition of MailEntity's Location, but adds more properties for the actual location.

  Like an entity, a frame can only be inherited from one other frame. Multiple inheritance is not allowed. By definition, a derived frame cannot specify a group of frames. Compound frames and frame inheritance are separated. It is possible to handle the inheritance of Frames in the same way as for entities. For example, in a composite frame, notation lists are grouped together. In some cases, it may be desirable to enforce the requirement that all frames belong to the same behavior class during frame grouping. Multiple frames and entities can be processed in the same way if the frames in the group need not belong to the same LSS class.

  Like frames and entities, derived constraints can only be inherited from one other constraint. Subtyping of constraint clauses of basic constraints can also occur when defining derived constraints.

  A constraint clause for a particular constraint type is tried on the derived type before proceeding to the base type. This further applies to the Default constraint as shown in Table 118 below.

  Table 118: Default constraints

When resolving Location constraints on MyMailEntity, the order in which the constraint clauses are fired is as follows.

1. MyMailEntity.Location
2. MailEntity.Location
3. MyMailEntity.Default
4). MailEntity.Default
At present, there is no concept of public / private constraint clauses and no constraint clause override concept. In part, this is because there is little point in overriding the constraint clauses if constraint clauses are used to resolve the class and those clauses are private to the on resolve clause. is there. However, in some implementations it may be desirable to be able to override the constraint clause.

  Depending on the implementation, derived classes (at resolution time) need to be able to access members (methods and variables) in the base class. This can be a problem because the base class is not yet resolved. If a derived class is not allowed to access members of the base class until the base class is resolved, the derived class must not be able to be polymorphic to the base class at resolution time. In either case, the derived class may not be allowed to call the constraint clause directly on the base class before the base class is resolved.

  Inheritance can be used to increase awareness of existing entities. Referring again to the MailEntity code in Table 118 above, it should be noted that MailEntity recognizes only Location constraints. It is possible to create an entity that adds Topic recognition using the authored Location logic in MyMailEntity. In addition, constraint clauses of the same type as the base class can be added as shown in Table 119 below.

  Table 119: MyMailEntity

  If a constraint clause is invoked and rejected by the authored code in the clause, the interpreter invokes the constraint clause of either the current type or a polymorphically equivalent supertype. To be considered polymorphic equivalent, both the constraint type and its slot type must be polymorphic as shown in Table 120 below.

  Table 120: Polymorphism

  These are not exactly equivalent, but it is possible to use inheritance instead of subtyping in slots as shown in Table 121.

  Table 121: Inheritance

When resolving “mail in Inbox” by matching with MailEntity3, MailEntity3. The Location section is MailEntity. Takes precedence over the Location section. In this case, there are two Location constraint clauses for MailEntity3. However, for MailEntity2, there is only one Location clause. Sub-typing at the slot can be interpreted as indicating that the location for MailEntity2 must be evaluated by the Location constraint clause of MailEntity, but using the MyMailFolder type.

  Note that care must be taken when declaring a constraint clause with an obligatory attribute. Mandatory clauses must fire and succeed in the order in which the type resolution succeeds. If a base type declares a clause as obligatory, the derived class must not handle decisions that should enter the base class. A derived type cannot call a constraint clause of its base type. Instead, the derived type relies on normal solution semantics to invoke the primitive type's obligatory constraint clause.

E4. Solution Semantics The SPL solution semantics are implemented by the SPL runtime. The runtime builds a domain-dependent model of utterances with SPL language semantics. This runtime resolves natural language commands against the authored SPL type according to language and SPL language rules.

  In one embodiment, the type resolution is performed in a top-down manner. FIG. 5 is a simplified flowchart of a top-down type solution according to an embodiment of the present invention. First, the runtime finds possible commands that can be resolved for the utterance (step 500). If there are multiple possible commands, one command is selected for resolution (step 502). If no command is found, the Unknown command is called (step 504). If one or more commands are found, the runtime attempts to resolve the found commands (step 506). If command resolution fails, the runtime proceeds to the next command in the list and repeats steps 502-510 until there are no more possible commands. If the command resolution is successful, the command is added to the interpretation list (step 510). Finally, the runtime repeats the steps (steps 502-510) (step 512) until there are no possible commands included in the utterance or until the required number of interpretations is reached.

  One skilled in the art will appreciate that many variations of the solution process are possible. For example, in some cases, a resolution failure may be a general failure, which causes the program to terminate the resolution. In other cases, a failure may call a type failure clause, but this may or may not resolve. Furthermore, within the failure, success, and begin clauses, program developers are free to insert application-specific code, which allows the framework to be adapted in a myriad of ways. For example, a developer can insert code that returns a “success” flag in the failure clause to prevent failure if the resolution fails. The failed resolution may be ignored, or other program code may cause the process to call back to the client application to clarify the specific resolution or the like. Note that the diagram is intended as an example, but is not intended to cover possible implementations.

  As shown in FIG. 6, one possible embodiment of command resolution proceeds as follows. The begin clause of the command is called (step 600). If the begin clause fails, the runtime terminates the command (step 601). If the begin clause is successful, the runtime attempts to resolve the frame (step 604). If frame resolution fails, the frame failure clause is called and the runtime can terminate the command or perform other operations, depending on the implementation (step 602). Otherwise, the runtime calls the success clause (step 606).

  As already explained, the semantic programming language of the present invention allows the program developer to control the operation of various elements. Thus, the solution semantics of the present invention can be modified in a myriad of ways to implement the desired operations for a particular application. Therefore, if the resolution fails, it may be desirable to proceed by ignoring the failure in some cases. In other cases, it may be desirable to clarify the resolution in a few steps (such as by making a callback to the client application) so that the resolution is successful. In still other cases, it may be desirable to simply terminate the solution if the solution fails.

  As shown in FIG. 7, in one embodiment, frame resolution proceeds as follows. The begin clause of the frame is called (step 700). If frame resolution fails, the failure clause is invoked (block 702) and the runtime optionally resolves other commands (block 704).

  If the frame resolution is successful, the runtime calls the Restriction clause (block 706) (corresponding to block 408 and order in FIG. 4). If the Restriction clause fails to resolve, the runtime considers the derived type for resolution (block 708). For example, given an entity type Item of derived type Mail and Notes, clauses on other types SendItem that take an Item can be resolved by an instance of Mail or Notes.

  If the runtime does not succeed in calling the derived type, depending on the implementation, the failure clause of the frame may be invoked (block 709) and then the failure clause of the command may be invoked (block 702).

  Alternatively, the Restriction clause can simply be ignored. If the Restriction clause is ignored, the runtime invokes the frame and command success clause (book 712). The runtime then adds the command object to the “actual interpretations” list (block 714) and attempts to resolve other commands (block 704).

  If the runtime succeeds in calling the Restriction clause (block 706) or successfully detects the Delivered type for resolution (block 708), the runtime calls the Restriction success clause (block 710). The runtime then invokes the frame and command success clause (block 712) and adds the command object to the "actual interpretations" list (block 714). After this, the runtime attempts to resolve the commands one after another until a resolution is attempted for all possible commands (block 704).

  As already mentioned, the process flow is intended for illustrative purposes only and never covers the large number of possible implementations. In practice, the resolution process, if not the majority, is determined at least in part by the particular implementation. Thus, as shown, constraint resolution failure causes a general resolution failure (as indicated by blocks 709 and 702) or constraint resolution is simply ignored and command resolution Progresses. In other embodiments, due to a failed constraint (eg, when Restriction is mandatory), the runtime calls back to the client application or sends flow control information to the analysis engine to attempt to clarify the command. It is possible that Such decisions are often implementation-specific, so using the programming syntax of a semantic programming language makes natural language programming easier and optimizes natural language processing for a particular implementation. Can do.

  As shown in FIG. 8, one possible embodiment of constraint clause resolution proceeds as follows. For each proposed constraint, if there is a constraint slot for the constraint, the runtime resolves each slot by calling the ResolveSlot function (block 800). If the ResolveSlot function fails, the runtime selects the next proposed constraint (Block 802) and attempts to resolve the slot by calling the ResolveSlot function (Block 800) again. If the ResolveSlot function is successful (at the first time or at one of the next proposed constraints), the runtime calls the constraint clause (block 804).

  If the constraint clause fails, the runtime looks for a polymorphic equivalent clause in the current class (block 806). If a polymorphic equivalent clause is not found in the current class, the runtime searches for one in the inheritance chain (block 808). If a polymorphic equivalent clause is found, the runtime calls the equivalent clause (block 810). The runtime repeats until no equivalent clause is found or until an equivalent clause is successful (block 808).

  If necessary, the runtime invokes the Default constraint (block 812). If resolution of all constraint clauses is successful, the runtime invokes the success constraint (block 814). If unsuccessful, the runtime ignores the Restriction (block 816) and invokes the success clause of the frame (block 818).

  In other embodiments, if the default constraint clause fails, the constraint is simply ignored. As mentioned above, unless this is a Named or Negation constraint, the constraint will still succeed.

  Note that a constraint clause can fire multiple times for the same resolvable type. For example, the command “show files in c: in temp folder” has two Location constraints for the “file” entity (“inc:” and “in temp folder”). Currently, the only mandatory order of constraint clause resolution is to resolve the Doer and DoneTo constraints on the frame first (in that order) and the Default constraint last. However, it may be desirable to enforce ordering on other types, such as Negation and Named.

  As shown in FIG. 9, in one embodiment, Named Entity resolution proceeds as follows. The runtime invokes the entity's begin clause (block 900). If this fails, the runtime ends Entity resolution (block 902). If the entity's begin resolution clause is successful, the runtime attempts to call the specified Restriction if a NamedEntity is found and corresponds to the Entity (block 904). It is important to note that block 904 includes multiple resolution steps, which are omitted here for simplicity.

  If the specified constraint call fails, the failure clause of the Entity is called and the runtime ends (block 906). If the call is successful, the runtime calls the entity success clause (block 908).

  It will be appreciated that there are an infinite number of ways to change the resolution steps using the programming language of the present invention. For example, the success resolution clause can be modified to return “false” or “failure” under certain circumstances. Similarly, the failure resolution clause can be programmed to return “true” or “success”, depending on the particular implementation. Accordingly, the examples presented herein are not intended to be limiting, but rather are provided to illustrate one possible implementation of solution semantics. Numerous variations are anticipated and programmers are expected to apply the solution to the needs of specific natural language applications.

  Default constraints are used to resolve constraints that are not handled by the authored code and / or constraints that are not recognized by the runtime. The Default constraint is called once for each resolvable type and is always called last. There can be at most one Default constraint per solveable type.

The default object model may vary depending on the implementation. In one embodiment, the Default object model comprises a lattice (element, item, or span) of text tokens with proposed constraints. Tokens do not have to be contiguous in the lattice. For example, assume that there are token ₁ token ₂ and token ₃ in the utterance. Under Default, the runtime can output the lattice shown in Table 122.

  Table 122: Lattice output under Default

Raw text is always available. Using SPL, the author can obtain information about whether tokens in the text are expected or not in a successful resolution.

  Statistical semantic modeling and learning can play a role in SPL. The order in which the constraint clauses are called may depend on some evidence based on language evidence, statistical ranking (eg, SGM), and auto-learning. As shown in FIG. 10, the system 1000 includes a runtime 1002 and a database 1004. In general, the runtime 1002 can manage a database 1004, which is a repository of speech and resolution results. The data in this repository can be mined or analyzed (offline) by the analysis tool 1006 (for example) after reaching a resolution threshold. Information in the database 1004 can be analyzed by the analysis tool 1006 and the results can then be fed back to the runtime 1002 to improve the selection and order of commands to resolve and the order in which the constraint clauses are invoked. As a result, when many utterances are resolved, they can be resolved and improved and speeded up without changes to the authored code. In a broad sense, the system 1000 is an intelligent system that can improve performance without recoding.

  In one embodiment, senior authors can manage and program against a repository. In other embodiments, the senior creator can return a probability that represents a confidence level from a clause rather than just a true / false value. This can complicate the programming model, but authors can be statistically involved in semantic analysis if a confidence level can be derived instead of a logical value.

  In general, the ambiguity is visible to the creator who handles the ambiguity with the SPL client application. In the case of ambiguity not handled by the code, multiple interpretations will appear. The runtime ranks those interpretations and returns up to the maximum number of interpretations specified by the application to the application. In one embodiment, the list of interpretations is returned synchronously (as part of the API call). In other embodiments, multiple interpretations are returned asynchronously using events.

  The runtime reaps a semantically equivalent interpretation from the list. In addition, the runtime provides a default implementation that determines the semantic equivalence of the two interpretations. The default implementation can also be overridden by the author.

  In one embodiment, semantic equivalence is determined relative to a string generated by paraphrasing semantic interpretation. However, other techniques can be used to determine equivalence.

  In general, developers do not need to write code to handle all possible constraints that can occur within an utterance. The author simply creates the code for the constraints he wants to understand and process. Unauthorized / unprocessed constraints are deleted. In other words, the unauthored / unprocessed constraint is that they are ignored as if they did not occur in the utterance. The only exceptions are Negation and Named constraints, which must be handled.

  Semantics are implemented using inheritance. All resolvable types inherit from the base class. Therefore, there is a basic Entity class, a basic Frame class, and a basic Restriction class. The basic resolvable type has one constraint clause Default as shown in Table 123.

  Table 123: Basic solveable types

The default resolvable type Default constraint succeeds for all constraints except Negotiation and Named. Table 124 shows the syntax of Mail Entity.

  Table 124

For utterances such as “mail received yesterday”, the SPL runtime tries to resolve “received yesterday” against the MailEntity authored constraint clause. Since “received yesterday” is not mapped to a Location constraint and MailEntity does not have a Default constraint clause, the SPL runtime tries to resolve “received yesterday” by matching it with the basic type of MailEntity. The Default constraint clause in Entity returns true, so MailEntity resolution is successful. The solution succeeds as if only “mail” was recognized in the utterance “mail received yesterday”.

  If this is not the desired behavior, developers can easily create code that rejects unrecognized / unprocessed constraints as shown in Table 125.

  Table 125: MailEntity containing code to handle unrecognized constraints

  Here, the Default constraint clause in MailEntity is tested before the basic Entity is called. Therefore, “mail received yesterday” does not succeed even when trying to resolve it against MailEntity.

  In general, anything outside the scope of on resolve is processed according to conventional C # rules. The code in the solution section is also a C # code. Therefore, the resolvable type can be regarded as a dedicated C # class containing special code for determining the configuration.

E5. Programming the LOM Programming a LOM requires the use of constraints provided by the LOM to achieve the intended result. This is best understood by looking at some examples. Therefore, the following description will take a number of examples, examine more complex semantics (such as adjustment, comparison, negation) that model constraints and clauses, and describe some “best” implementations. Details on what kind of utterances produce which constraints and the information they contain are already described in Section D.

  Not all LOM constraint types are exposed to SPL. In SPL, emphasis is placed on constraint types for commands and control scenarios. In contrast, LOM has a fairly broad application. As new releases become available, exposing exposed semantic relationships as new constraint types will attempt to narrow down or modify the constraint types published in later releases for backward compatibility. It is easier. In the following description, the method of using constraints for modeling in the SPL code will be mainly described. In general, the constraints are for developers of Microsoft®. It appears as a class library similar to the Network Framework Class Library (FCL).

Accompaniment constraints model the entities that accompany the host. Accompaniment can be used on entities and frames. Some examples are meeting with my manager , chat with Bob , email with attachments , and merge File A with File B. Accompaniment constraints include one system slot accomp of type Entity that represents the entity that accompanies the host. The creator can constrain the types of entities that can accompany the host as shown in Table 126.

  Table 126: “email with attachments”

In the AsBeing constraint, the Tone. Select some property of what entity. AsBeing constraints can be used on Frames. Some examples are “show status as busy”, “save as text file”, and “make the front large”. The AsBeing constraint has one system slot restr that represents the selected constraint. Rather than letting the constraint type enter the slot, constrain the constraint type to a specific constraint type. The constraints are limited to specific types by providing overloaded AsBeing constraints that take on various supported types within the system slot. The following constraints are supported (example):
AsBeing <restr: = Modifier>: "mark message as low priority"
AsBeing <restr: = Possessor>: "make this file mine"
AsBeing <restr: = Ordinal>: "put this message first"
In some embodiments, phrases such as “log in as my manager” can be resolved successfully. However, this would require that entities be allowed as a slot type.

  The AsBeing constraint is a verb, its DoneTo. Define a three-location relationship between the what entity and the constraints on this entity. SPL does not enforce this strong binding, but the best way would be to enforce the relationship as shown in Table 127.

  Table 127: “show m status as busy”

  A Cardinal constraint models a radix as represented by a quantifier (eg, “3 files”). Cardinal constraints can be used on entities. The Cardinal object includes Cardinal. There is a member called number, which gives the actual radix values as shown in Table 128.

  Table 128: “3 email”

  A Comparison constraint models a comparison of an entity with other explicitly identified entities. This is not used for expressions such as “a bigger file” where one or more entities to compare are left implicit. There are two system slots defined for Comparison: dimension, which is the dimension at which the comparison is performed, and compareTo, which is the comparison target entity. For example, in “bigger file tan mydoc.txt”, “bigger” is a comparison dimension and “mydoc.txt” is a compareTo entity. The dimension is a restriction type. In general, a Comparison constraint can compare two entities for some property of multiple entities.

  Some examples of comparisons include “a book more about cats tan dogs”, “mail large tan than 10KB”, and “make font small tan 12 pts”. In some embodiments, it may be desirable to enforce the requirement that a dimension constraint is accompanied by a Degree modifier. For example, the phrase “file big tan mydoc.txt” should not be resolved because the dimension constraint is not a constraint type.

  Degree constraints model the degree of constraints and can be used on constraints. This groups words such as very, extremely, lightly, almost, more, less, most, and least. Some examples include “almost in the box”, “extremely red”, “very large”, and “more to the left”. The grouped words are classified into a set expressing “degree”. The type of degree is as follows.

More: bigg er , more relevant
Most: bigg est , most relevant
Less: less relevant
Least: least relevant
Same: as big
High: very big, extremely popular
Low: not very big
Note that “smaller” is modeled as “more small” and not as “less big”.

  For utterances such as “10 KB large file”, this is modeled as a combined “10 KB more” concept that modifies “10 KB” (Modifier) that modifies “more” (Degree) and “large”. In contrast, the utterance “10 KB large file” is modeled as two modifier constraints “10 KB” and “large” on the “file” entity (equivalent to “large, 10 KB file”). Table 129 shows the notation syntax of the notation list of vocabulary words representing “large” and the syntax of File Entity to which these restrictions apply.

  Table 129: “LARGE” representing “large”. // Vocabulary words

  In general, it is not necessary to create separate constraint types for “more large” and “10 KB large”. All of these may be placed under the LargeModifier. Thereafter, a consumer such as FileEntity can simply check the LargeModifier's RestrictionCollection property and check if "10KB more" and "more" are present in the utterance, if necessary, as shown in Table 130. is there.

  Table 130: Large modifiers

  A Doer constraint represents an entity that performs an action and can be used on Frames. For example, “Bob opened the file” or “the file was opened by Bob” both trigger a Doer constraint. The Doer constraint includes one system slot “who” of type Entity representing the actual actor.

  Typically, Doer is a computer when a frame is used by a command. However, if the frame is used as a frame-based constraint (eg, “file opened by Bob”), actor identification will be relevant. An author can use a Doer constraint to constrain the actor's type.

  All basic frames have Doer constraints defined in asperity, so that they are easy to subtype on the consumer side as shown in Table 131.

  Table 131: Basic frame (open)

  The DoneTo constraint represents the entity on which the action is performed. For example, “open the file” and “the file was opened” call DoneTo constraints. This includes a system slot what of type Entity representing the target of action.

  All basic frames have a DoneTo constraint defined in asperity, which makes it easy to subtype on the consumer side as shown in Table 132.

  Table 132: Basic frame Open

  A Goal constraint models the end point of an action or modification. Goal constraints can be used on Frames. Some examples include “send mail to Bob”, “change password to XXX”, and the like. This includes a system slot goal of type Entity that represents the end point as shown in Table 133.

    Table 133: “send mail to Bob”

  Iteration constraints model repetition of actions and can also be used on Frames. For example, “print 3 times” triggers the Iteration constraint shown in Table 134.

  Table 134: Iteration constraints

  Model the semantics that Location constraints are located somewhere. Location constraints can be used on frames and entities. For example, “mail in Inbox”, “file located on the desktop”, and “search the web” all trigger Location constraints. This includes a system slot loc of type Entity representing the actual location as shown in Table 135.

  Table 135: Location constraints

  The Means constraint can be used on a frame, but the details are described in Section D LOM. Modifier constraints can be used on Frames, Entities, and Restrictions. Modifier constraints represent adjective modifiers such as “large file”, “school bus”, “front that is red”, and “print slowly”. It has one system slot mod of type Denoter that represents an adjective. A noun-noun compound word such as “MSN consumer application” can be modeled as follows.

Modifier ("MSN") and Modifier ("consumer") on Entity ("application");
Modifier ("MSN consumer") on Entity ("application");
Modifier ("MSN") and Entity ("consumer application"); and / or
Entity ("MSN consumer application")
The Named constraint represents the name of the entity. Some examples are “Inbox folder”, “file named foo.txt”, “file with the name foo.txt”, “open foo.txt”, and “the file foo.txt”. The system slot name is an actual name as shown in Table 136.

  Table 136: “file named foo.txt”

  A Negation constraint on a host means that the host is denied, not that its constraint clause is denied. Some examples are “don't allow mail from Joe” and “mail not from Joe”. Table 137 illustrates the frame syntax with negation.

  Table 137: Frame with negation

  If the utterance includes negation but the SPL code does not have a Negation constraint clause, the utterance fails to resolve. This is different from other constraints that are simply deleted if not authored.

  Negation constraints cannot be used on entities. For SPL, the “universe” in which an entity appears depends on how the entity is being used, so no denial of the entity is necessary. For example, in an utterance such as “Display evening but the mail”, the universal is everything that the application can display and not necessarily all the entities that the application models. In the utterance “don't allow mail from Bob”, the universe of the content that can be allowed or forbidden can be very well constrained only to email, so email denial is not meaningful in this context Let's go. Thus, entity negation is handled by the entity's consumer using the “!” Syntax.

  Negative scope clarification is determined by the SPL code. For example, “do n’t look on the table” may have the following negative scope ambiguity:

Don't look on the table (but sit on it instead)
Don't look on the table (but look under it)
Don't look on the table (but look on the chair): Negation is Location. Which semantic interpretation of the loc entity is resolved depends on how the code is authored. In fact, depending on the authored code, all these reading resolutions are successful and therefore multiple interpretations may be obtained. The runtime usually has a preference for scope ambiguity, and multiple interpretations are ranked. Table 138 shows the negative modeling.

  Table 138: Negation

Also, as shown in Table 139, the “!” (NOT) syntax can be applied to frames and constraints as a simple notation.

  Table 139

  The Ordinal constraint models ordinal verbs that represent some concept of position in turn and other modifiers such as previous. Some examples are “first file”, “third book”, and “last email”. The Ordinal constraint also applies to other constraints such as “first 3 books” modeled as an Ordinal (“first”) constraint that modifies the Cardinal (“3”) constraint as shown in Table 140, for example. Is possible.

  Table 140: Ordinal constraints

  Posessor constraints model the owner of an entity and are applied to the entity. Some examples are “my book” and “Bob's book”. A system slot owner of type Entity represents the owner of the entity. If the owner is explicitly indicated, such as “Bob's book”, then “Bob” is resolved against the owner slot. If the owner is a pronoun, such as “her file”, the runtime attempts to resolve the pronoun by forward anaphora resolution. If this forward anaphora resolution fails to find the owner entity, the owner slot will be null. Table 141 shows the syntax of the possessor constraint.

  Table 141: Posessor constraints

  Quantifier constraints are allowed on Entities and model quantity representations. Some examples are “all files”, “a five books”, and “one third of the page”. The quantifier type is shown below.

All: all ((of) the), every, each (of the)
None: no, none (of the)
Some: some (of the)
Most: most (of the), the majority of
Many: many (of the)
Few: few (of the), not many (of the)
Percentage: a half of, 1/3 of, 40% of
In some embodiments, there may be a hierarchical relationship between the Quantifier and the Cardinal.

  The SortOrder constraint models the style of sorting. For example, “sort in alphabetical order” and “display in reverse order by name”. This constraint is described in detail above with respect to Table 56.

  The Time constraint models an actual time representation, that is, a time representation that can be converted to a point in time and / or a time span. Examples are “delete after 3 days”, “mail from yesterday”, and “schedule for tomorrow from 1-3 pm”. The Time constraint has already been explained in detail in section D above.

  Topic constraints model the subject. Some examples are “book about dogs”, “book reporting dogs”, and “book with the subject documents”. It has one system slot topic of type string representing the topic character string. This constraint has already been explained in detail in section D above. Table 142 shows a BookEntity code block with Topic.

  Table 142: BookEntity

  Conjunctions (“and”) and disjunctive conjunctions (“or”) can appear for commands, entities, and constraints. Conjunctions and disjunctive conjunctions fall under the Coordination heading. In general, coordination ambiguity brackets ambiguities in utterances, including how to distribute entities and modifiers into conjunctions and disjunctive conjunctions, and multiple "and" and "or" operators Arise from. Like Negation, this clarification is determined by the authored code. For example, for the utterance “find mail and notes created yesterday”, the SPL author can model this as follows:

a. (Find (mail created yesterday) AND (notes created yesterday)).
b. (Find (mail) AND (notes created yesterday)).
c. (Find (mail created yesterday)) AND (Find (notes created yesterday)).
d. (Find (mail)) AND (Find (notes created yesterday)).
The method of distributing “created yesterday” and “find” along with its entities “mail” and “notes” is determined by the authored SPL code. For purposes of explanation, assume that an author codes a FindMailCommand that only recognizes entities of type MailEntity and a FindNotesCommand that only recognizes entities of type NotesEntity. Further, the authored code stipulates that MailEntity does not have the concept of creation time, and NotesEntity has as shown in Table 143.

  Table 143: Adjustment

In this authored code, the semantic analysis for the utterance “find mail and notes created yesterday” only reads (d) from the list (“Find (mail) and find (notes created yesterday)”). SPL authors do not need to understand all the possibilities. The creator only needs to think about the semantics of the application (for example, MailEntity does not recognize the creation time, but NotesEntity recognizes it).

  Coordinated entities are represented as a list of entities that are linked with an adjustment type of either “and” or “or”. All entities in this list must be linked with the same coordination type. Furthermore, all entities in this list must be the same programming type (eg, all MailEntity elements).

  In general, the runtime does not model the output of multiple interpretations and bracketing ambiguities that result from the same type of adjustment. Rather, entities that are coordinated with the same type of coordination (ie, all contain “and” or all contain “or”) are modeled as a flat list, and proper parenthesis decisions can be made even if there is a problem. It is left to. For example, take the utterance “find mail and books and files”. This may mean “find mail and (books and files)” or “find (mail and books) and files”. This ambiguity bracketing is not modeled, meaning that only one possible reading is output, assuming all entities are of the same SPL type. This utterance is modeled as a flat list where the order of the elements reflects the order within the utterance.

  However, if “and” and “or” are mixed, the runtime outputs multiple readings to model ambiguity bracketing. Depending on the authored code, these multiple readings may or may not result in multiple resolved interpretations. For the utterance “find mail or books and files”, the list of elements must be adjusted with the same adjustment type, so the following runtime outputs the following possible reads (“mail”, “books”, and “ “files” resolves to the same SPL type, and the Find command receives a list of entities).

(Find (mail OR books)) AND (Find (files))
(Find (mail)) OR (Find (books AND files))
“Find” is distributed to “and” and “or”.

  In general, mixing “and” and “or” operators is not common in utterances, so it is less cumbersome to output multiple interpretations to model ambiguity parentheses Not sure.

  In some configurations, it may be used to implement an Entity list that can be defined by an entity consumer using the [] syntax as shown in Table 144.

  Table 144: Entity list

  Interpretation represents the interpretation of the utterance resolved against the SPL program. Each resolved interpretation includes at least one resolved command. When there is an utterance, multiple commands can occur for interpretation. For example, in “find file foo.txt and print it”, two commands are included in this utterance. Commands in one interpretation are linked together with some condition. Currently they are linked together by either the AND or OR adjustment type (other modeling conditionals are possible). The commands in the interpretation need not be of the same resolved type.

  In the following discussion, various adjustment examples are examined to see how elements are distributed into conjunctions and disjunctive conjunctions, and how authored code models adjustments. This discussion also examines command, entity, and constraint adjustments. Possible readings are shown to illustrate ambiguity and distribution for a given utterance.

  To reiterate, the SPL author thinks about the semantics of the application (for example, his Find command can act on a MailEntity list). The runtime attempts to map utterances to authored content in response to a language understanding of the rules for distributing elements to conjunctions and disjunctive conjunctions. The code samples in Table 145 are used for the examples shown below.

  Table 145: Code examples

  The above code resolves the command “Find mail from Bob and delete them” as follows:

  The command “Find and / or delete mail from Bob” is resolved to have four interpretations as follows.

  Interpretation 1: “mail from Bob” is distributed to “and” / “or”.

  Interpretation 2: “mail from Bob” is not distributed to “and” / “or”.

  Interpretation 3: “mail from Bob” is not distributed to “and” / “or”. This interpretation arises from the authored code, not from coordination ambiguities. Since there are three “find” commands and the “empty” entity is a valid entity, a bare “find” can be resolved to any of these commands.

  Interpretation 4: Same as Interpretation 3.

All of the interpretations listed are possible for the authored code above.

  The command “Find mail from Bob and / or delete” is resolved against the authored code above, resulting in two possible interpretations:

  Interpretation 1: “mail from Bob” is distributed to “and” / “or”.

  Interpretation 2: “mail from Bob” is not distributed to “and” / “or”.

The only difference between the phrase in this example and the phrase in the previous example is the command “delete” with an empty MailEntity. Both interpretations are possible in the authored code above.

  The command “Open file and reply or create mail” is resolved to this code, resulting in the following possible interpretations:

  Interpretation 1: “mail” is distributed to “or” and attached to “reply”.

  Interpretation 2: No entity distribution

  Interpretation 3: “file” is distributed to “and” and attached to “reply”. This reading is not resolved for the above authored code because there is no “reply” command to receive FileEntity.

  The command “Open file or reply and create mail” gives three possible interpretations:

  Interpretation 1: “file” is distributed to “or” and attached to “reply”. This reading does not resolve for the above authored code because there is no “reply” command to receive “FileEntity”.

  Interpretation 2: “mail” is distributed to “and” and attached to “reply”.

  Interpretation 3: No entity distribution

  In general, “and” for constraints is implied by SPL semantics. For example, the command “find mail from Bob and in Inbox” fires two constraints on MailEntity: Source constraint and Location constraint. Therefore, in the following explanation, the disjunctive conjunction of constraints is examined.

  In addition to the code above, we will add a FindMailListCommand that recognizes the MailEntity list using the following line of code:

  The command “find mail from Bob or created yesday” resolves to the following interpretation.

  Interpretation 1: “mail” is distributed over “or”. As a result, a list of MailEntity is obtained.

  If FindMailListCommand does not exist, or if the resolution is not successful, “find” is distributed to the entities, creating two FindMailCommands.

  The command “find mail from Bob or created yesterday and in Inbox” is interpreted as follows.

  Interpretation 1: “in Inbox” is parenthesized, ie, “from from Bob or created yesterday”.

  Again, if the FindMailListCommand does not exist or if the resolution is not successful, the “find” is distributed to the entities, generating two FindMailCommands.

  Interpretation 2: Parentheses for (mail created yesterday and in Inbox). Since “mail from Bob” is connected with a disjunctive connective, there is no distribution to parentheses.

  Again, if the FindMailListCommand does not exist or if the resolution is not successful, the “find” is distributed to the entities, generating two FindMailCommands.

  Interpretation 3: The modifier and “mail” parentheses are not distributed across all modifiers.

  Again, if the FindMailListCommand does not exist or if the resolution is not successful, the “find” is distributed to the entities, generating two FindMailCommands.

  In addition to the above commands, a general FindCommand has been added, which allows searching of lists of mail, notes, and journal items. FindCommand is shown in Table 146.

  Table 146: Find command

As this command is added, the number of interpretations increases, as you can see in the example below.

  As a result of the command “Findmail and / notes created yesterday”, the following interpretation is obtained.

  Interpretation 1: “created yesterday” is distributed over “and” / “or”.

  Interpretation 2: There is no distribution of “created yesterday”.

  If FindCommand does not exist, or if the resolution is not successful, “find” is distributed to the conjunction, resulting in two further interpretations:

  Interpretation 3: Same as 1 except that “find” is distributed to entities.

  Interpretation 4: Same as 2, except that “find” is distributed to entities.

  The command “Find mail from Bob and / or notes created yesterday” results in the following potential interpretations:

  Interpretation 1: Unlike Example 1, there is no distribution of modifiers.

  Interpretation 2: If FindCommand does not resolve, a distribution of “find” to entities is obtained.

  The command “Find mail, notes, or journal items created yesterday” results in the following potential interpretations:

  Interpretation 1: “created yesterday” is distributed to “mail”, “notes”, and “journal items”.

  Interpretation 2: There is no distribution of modifiers

If FindCommand does not exist, or if the resolution is not successful, “find” is distributed to the conjunction, resulting in two further interpretations:

  Interpretation 3: Same as 1 except that “find” is distributed to entities.

  Interpretation 4: Same as 2, except that “find” is distributed to entities.

  The command "Find mail and notes or journal items created yesterday" results in parenthesis problems. A “find” command that receives both a conjunctive type (ie, both “and” and “or” appear in the utterance), and receives both a list of entities and singleton entities There are many possible interpretations due to the existence of. It is therefore a good idea not to have a command that receives a list of entities as well as a singleton entity. The code is authored to get as many interpretations as possible.

  Interpretation set 1: There is no distribution of “created yesterday”.

In this case, it may be necessary to output the interpretation with a FindCommand that receives only one element instead of the FindJournalCommand.

  Interpretation set 2: “created yesterday” is distributed to “or” and attached to “notes”.

  Interpretation set 3: “created yesterday” is distributed to all entities.

  In some cases, it may be desirable to allow developers to specify their own mapping of various language phenomena to constraints. It may be desirable to have "pre-analysis" programming where the pattern affects the fired constraints, as opposed to the default "post-analysis" programming. In general, it is desirable to allow a range of patterns from string-based patterns to language-based patterns.

  In one embodiment, a general mechanism is provided that defines patterns that are used internally by LOM developers and used externally by SPL developers. External developers should be able to use a variety of patterns, from simple patterns to complex patterns.

  In one embodiment, pattern application is similar to using the C # attribute as shown in Table 147.

  Table 147: Pattern application

  In general, the present invention is intended to be as open as possible, which allows developers to create their own patterns that are probably independent of the predefined set. Thus, developers can bypass formalized semantic relationships (ie, constraint types) and form their own relationships as needed.

  With respect to modeling condition clauses, in some embodiments, modeling condition clause commands can be very useful. Simple examples include: “if Bob sends me mail, delete it”, “page me when mail comes from Bob”, “move the file to c: \ doc after copy ent, and er me and so on. In general, the mechanism for modeling this should be similar to the coordinated command mechanism. In other embodiments, the conditional clause can be revealed through a special constraint type.

  In some embodiments, the author may wish to infer multiple constraints within a constraint clause to narrow down the interpretation. An author can imitate AND inference, though not elegant, by storing data in a constraint clause and inferring it in the success clause. Authors can mimic the inference of OR properties through callouts to common functions.

  In a preferred embodiment, the author is allowed to define a list of notations using an operation code (eg, calling a database). The notation for this may vary depending on the particular implementation and the associated database.

  In general, from the Named constraint, the creator can obtain the name as a string. In one embodiment, an author can create a name class that can be queried by the runtime for a list of names recognized in a given utterance. For example, given the phrase “find Gone with The Wind movie”, an author can create a name class that can recognize “Gone with the wind” as the name of a movie. As shown, you can provide an overload of Named constraints that accept name class types.

  Table 148: Overloaded Name constraints

  In a preferred embodiment, the NamedEntity type is associated with the NamedEntityRecognizer class as follows:

    NamedEntity MovieName uses MoveNameRecognizer;

  In a preferred embodiment, the developer can specify how to handle unknown / unauthored commands (eg, noun phrases). The author can either code the application to handle it properly, or can request the runtime to invoke a specific command (or set of commands) for a specific entity, or provide a default command handler can do.

  In one embodiment, a derived class may invoke a base class constraint clause, as shown in Table 149.

  Table 149: Derived class calls base class constraint clause

  Direct calls may be undesirable because clause resolution is largely controlled by the runtime. Introducing public / private / protected / and other constraint clauses and investigating what each means for the solution semantics adds unnecessary complexity. Alternatively, you can add a constraint that tells the interpreter to call the basic constraint clause before calling the self clause if the basic clause succeeds (eg, declarative constraints). The compiler can force the existence of a clause with an exact slot type in the base class, as shown in Table 150.

  Table 150

  The semantics of invokebase is that the basic constraint clause (both declarative and imperative constraints) must be successful before the clause decorated with invokebase is called. If it was desired to change the semantics (ie call the derived clause before the base clause), another syntax must be used. The syntax of the “with” clause means that the constraints specified by that clause must be met before the code attached to that clause is executed.

  For some verbs, swap Goal and Location. For example, “print to my printer” means the same as “print on my printer”. Depending on how the location is understood syntactically (ie, “to” vs. “on”), the author may not code against two different constraints. Both constraints can be revealed for those verbs depending on the content of the authoring. However, in some cases, explaining to the author that "to" is always understood as Goal, and trying to explain that some verbs can be Goals and Location, and some are not. Sometimes it is easier to forget.

  While it is important to understand that abstract types cannot be instantiated (ie, cannot be resolved directly), they are useful for preserving polymorphism and common functionality. If the creator creates a command for “send mail to Bob”, “send to Bob” should be resolved against that command even if there is no “mail” in the utterance. However, with this default, many interpretations can occur. In some embodiments, such functionality may be desirable. By default, if an empty entity is allowed and treated as valid, the author can create code in the entity's success clause that rejects the empty entity. If an empty entity is not allowed by default (that is, it does not resolve if there is no evidence of the entity in the utterance), it is possible to introduce a slot modifier that allows the command to accept a null entity (" optional "). In a preferred embodiment, there may be no constraints that include MailEntity, and if the author wants to check this case, the frame or command explicitly fails to resolve.

  Although the invention has been described with reference to particular embodiments, those skilled in the art will recognize that changes can be made in form and detail without departing from the spirit and scope of the invention. I will.

Appendix I Scenario: Microsoft Outlook (R) Prototype In this embodiment, Microsoft Outlook (R) supports text speech input using SPL and LOM. Most of this response was performed by summer trainees who had no knowledge of linguistics or were not trained in linguistics. The SPL code is Microsoft. Designed to be compiled and executed on the Net platform, the code interacts with Microsoft Outlook through the Outlook 2002 object model and CDO (Collaboration Data Objects) to execute bindings and commands.

  Several advanced search features are enabled, which infer different data sources. Some examples include the following scenarios:

“Search for mail that was sent by people on Conference Group”-infer distribution list “show mail from my contacts”-infer people in contacts folder “find mail from my direct reports”-infer organizational chart The system also performs forward anaphoric resolution. For example, when “show me David's manager” is followed by “send mail to him”, this means that “him” indicates “David's manager” and is clear to the developer.

  In addition, the system performs advanced inference and modeling as follows.

"Send mail to everyone on nlgcore except David Bradlee"-inferring denial "schedule a meeting every Tuesday with my manager at 2:00 for 1 hour"-modeling and programming against a complex time expression.

Appendix II: Microsoft Outlook® Code Walkthrough In the following description, commands are analyzed from the developer's perspective. This description mimics the developer's investigation when debugging code. The command is “send mail about package to Seattle group”. This sentence has two possible meanings:

    1. “Send mail about package to seattle group” —The subject of the email is “package to seat group”.

2. “ Send mail about package to seattle group ” —The subject of the email is “package” and the target of “send” (ie, the destination of the email) is “seat group”.

  Depending on the domain knowledge, one or both of these interpretations remain in the final interpretation list.

  The entire code is shown below. SPL keywords or reserved words are shown in bold. Code snippets will be omitted as the analysis steps progress.

Interpretation 1
Referring to the command again, the first interpretation is that the subject of the mail is “package to seat group” as follows.

"send mail about package to seattle group"
The first object called is the “on begin” clause of the “on resolve” clause of SendMailCommand.

  The command constructor is called and the code in the clause is executed. If the clause returns "false", further parsing for this command stops. In this case, if SendMailContext () returns false (that is, the application is not currently in the context of email transmission), the analysis stops.

  Assuming that the application can send mail, the SPL interpreter continues its analysis. Since SendMailCommands informs that it uses SendMailFrame, the next object to be called is SendMailFrame. The interpreter knows that the word “send” in the phrase is mapped to SendMailFrame.

Since there is no constructor for SendMailFrame, the default constructor is called. The default constructor always succeeds. The interpreter continues to resolve the constraint on “send”. The first constraint to be solved is a “DoneTo” constraint that represents the object of “send”, in this case “mail”.

According to the code, the DoneTo slot (indicating a region-specific type) is MailEntity. In other words, the object of “send” needs to be MailEntity. Therefore, the interpreter tries to solve MailEntity.

  Like other objects, the interpreter calls a constructor. Since there is no constructor, the default constructor is called and succeeds.

  Entities have the concept of being represented by a list of words. In this case, the interpreter checks whether MailEntityWords is in the English list, and checks whether “mail” is a notation of MailEntity.

This is where language specific details are coded. The interpreter verifies that “mail” is in the list.

  The interpreter then tries to resolve the constraint on “mail” against the content coded in MailEntity. In this case, “about package to seat group” is a Topic constraint whose actual topic is “package to seat group”.

  The interpreter tries to solve the actual topic by matching the slot of the Topic constraint. The “topic” slot is a string and therefore does not require resolution. The code in the Topic section is executed.

  The code stores the topic text in the member variable MailSubject. The actual text of the topic is retrieved via a language object model (LOM). The interpreter is currently executed by the MailEntity object. Since it is not coded, it calls the default success destructor for MailEntity.

  Control flow is returned to SendMailFrame, where the code is executed within the DoneTo clause.

  This code only stores the MailEntity object in a member variable. {NOTE: This is where the second interpretation (described below) begins} The interpreter has finished resolving the SendMailFrame object and calls the default success destructor because no success destructor is provided.

  Control flow returns to SendMailCommand. At this point, the interpreter has completed resolution of the complete command. The SendMailCommand success destructor is called.

The code is executed and a SendMailCommand object is returned to the application.

Interpretation 2
Reference will now be made to a second possible interpretation.

" send mail about package to seattle group"
The resolution steps for “send mail about package” are exactly the same as up to the top labeled site, except that the topic is “package” rather than “package to seat group”.

  The interpreter recognizes that “to seat group” is a Goal constraint on “send”.

This code indicates that the actual goal needs to be DLEntity so that the interpreter will try to resolve it by matching the “seat group” with the DLEntity.

The interpreter recognizes that “group” must be in the notation of DLEntity. This checks the notation list DLEntityWords.

A match is found. Next, the interpreter attempts to resolve “settle” against the Named constraint clause. Since the slot of the Named constraint is a character string, “seatle” is resolved by matching it. The Named constraint clause succeeds and the code in that clause is executed.

The code returns “true” only if “seattle” is a valid distribution group. If it is not a recognized distribution group, this section returns “false”. This shows how domain specific knowledge affects the interpretation returned by the SPL interpreter. If "seatle" is not a distribution group, resolution of this interpretation fails and only the first interpretation is returned.

  The interpreter completes command resolution. Depending on whether "seatle" is a recognized distribution group, either the success destructor or the failed destructor is called.

  Control flow returns to SendMailFrame. If the resolution of DLEntity fails, the code in the Goal clause is not executed and SendMailFrame fails to resolve. Otherwise, the code is executed and the resolution is successful.

The control flow returns to SendMailCommand and either the success destructor is called or the failed destructor is called depending on whether SendMailFrame was successful.

1 is a schematic diagram of a computing system environment in which an embodiment of the invention may be implemented. 1 is a simplified block diagram of a natural language system according to an embodiment of the present invention. FIG. 3 is a simplified block diagram of the analysis engine of FIG. 2 where the language object model is shown in dotted lines. 6 is a simplified flow diagram of a process for executing a send mail command according to an embodiment of the invention. 6 is a simplified flow diagram of mold resolution according to an embodiment of the present invention. 6 is a simplified flowchart of command resolution according to an embodiment of the present invention. 6 is a simplified flow diagram of frame resolution according to an embodiment of the present invention. 6 is a simplified flowchart of constraint phrase resolution according to an embodiment of the present invention. 6 is a simplified flow diagram of an entity resolution process according to an embodiment of the invention. 1 is a simplified block diagram of an intelligent system according to an embodiment of the present invention. FIG. FIG. 4 is a simplified conceptual block diagram of a lexical semantic structure according to one embodiment of the present invention.

Explanation of symbols

130 system memory 134 operating system 135 application program 136 other program module 137 program data 144 operating system 145 application program 146 other program module 147 program data 120 processing unit 190 video interface 195 output peripheral interface 140 non-removable nonvolatile memory interface 150 removable nonvolatile memory interface 160 user input interface 170 network interface 191 monitor 196 printer 197 speaker 171 local area network 173 wide area network 172 modem 162 keyboard 161 pointing Vice 163 microphone 180 remote computer 185 remote application programs

Claims (26)

A program for causing a computer interposed between a client application and a plurality of analysis engines to generate a natural language input interpretation effective for the client application,
Receiving the natural language input from the client application;
Passing a declaration schema describing the natural language input and a semantic model of a natural language feature of the client application to the plurality of analysis engines;
Receiving a plurality of potential interpretations from the plurality of analysis engines, wherein the plurality of potential interpretations are generated by mapping the natural language input to a language object model; uses its own analysis strategies for the language object model was adapted to model the semantic elements of natural language, not related to a particular natural language, comprising a set of modeling type, The modeled type includes procedural rules adapted to impose context-based constraints on the validity of one or more types of instances of the set of modeled types when instantiated. When,
For each of the plurality of potential interpretations , when attempting to instantiate a modeled type defined in the declaration schema and mapped with the natural language input, and succeeding in creating an instance by satisfying the constraints, identifying the potential interpreted as the actual interpretation,
A program for causing the computer to execute the step of instantiating one or more of the actual interpretations in the client application. By the context-based constraints, the program according to claim 1, wherein the instance to be destroyed if it is dead. The modeled type is further a constraint adapted to describe a relationship between a plurality of types of a set of types adapted to define an interaction between the program and the client application. Contains clauses,
The program according to claim 1 , wherein the set of types includes a plurality of semantic types partially created by a developer. 4. The program according to claim 3 , wherein the constraint clause is adapted so that acceptance of the relationship can be determined at the time of execution by a procedure rule. The program according to claim 1 , wherein the set of language object model types includes an Entity type for modeling the semantics of a noun phrase. The program according to claim 1 , wherein the set of language object model types includes an Entity type for modeling the semantics of an adjective phrase. The set of language object model types further includes a Restriction type for modeling the properties of semantic elements,
6. The program according to claim 5 , wherein the Entity serves as a host for the restriction. The program according to claim 1 , wherein the set of language object model types includes a Frame type for modeling the semantics of an event that can be expressed as either a verb or a noun. 2. The program according to claim 1 , wherein the set of language object model types includes a Denometer type for modeling a user-defined category of an input character string. The program according to claim 8 , wherein the Frame type includes one or a plurality of headwords corresponding to a syntactic main part of a phrase modeled by the Frame type. The set of language object model types further includes a Restriction type for modeling the properties of semantic elements,
The program according to claim 8 , wherein the Frame type is a host of the Restriction type. The set of language object model types is
Entities applied to model semantic objects;
Frames adapted to model events and related relationships between one or more objects;
The program of claim 1 , comprising: Restrictions adapted to model properties and relationships of other entities, Frames, or constraints. The set of language object model types is
The program of claim 1 , including a Named Entity type adapted to model specified Entities and derived from a separately defined class. The computer comprises a memory for storing a set of vocabulary semantic categories selected to model the content of the natural language input;
The program is
Associating the content of the natural language input with one or more categories of the set of lexical semantic categories to generate mapped elements;
The program according to claim 1, wherein the mapped element is passed to the analysis engine. The step of generating the mapped elements applies to the natural language input a collection of semantic rules for associating the content of the natural language input with the set of lexical semantic categories. Item 15. The program according to Item 14 . The step of generating the mapped elements is a collection of semantic rules for normalizing natural language input in the set of lexical semantic categories to the natural language input, wherein the term is a syntactic class term. And applying a collection of semantic rules adapted to identify a modifier and its semantics and to associate the identified term with one or more categories of the set of lexical semantic categories The program according to claim 14 . 15. The program product of claim 14 , wherein generating the mapped element normalizes the natural language input across syntactic categories. The set of lexical semantic categories is
One or more syntactic categories representing a portion of the natural language input;
One or more semantic roles representing the portion of the function in the natural language input;
15. The program of claim 14 , comprising a mapping between the one or more syntactic categories and the one or more semantic roles. The language object model is a set of resolvable types adapted to model natural language semantics for natural language programming,
A command type adapted to model commands in natural language input;
A constrained host type adapted to represent a non-command element of the natural language input, the command type selected or other verbally related to the selected command type based on the natural language input A constraint host type adapted to associate a constraint host type adapted to be the host of the selected command type constraint at runtime, The program according to claim 1, comprising a set of types. 20. The program according to claim 19 , wherein the instantiation of the type mapped to the natural language input is inherited from the command type or the restricted host type. The program according to claim 19 , wherein the non-command element includes a plurality of interrelationships between a language element and a plurality of language elements of the natural language input. The resolvable type further includes solution semantics that define procedural rules for resolving the validity of an instance of a selected type of the set of resolvable types at runtime. Item 20. The program according to Item 19 . The restricted host type is
A Frame type for modeling semantic events that can be expressed as either verbs or nouns;
An Entity type adapted to model the semantics of noun phrases and adjective phrases;
20. The program of claim 19 , comprising: a restriction type adapted to model the properties of a semantic element. The resolvable type further comprises:
A procedural code associated with a selected type of the set of resolvable types adapted to affect the resolution of the object;
20. The program of claim 19 , comprising: a constraint adapted to be imposed on the selected plurality of types of objects. The program of claim 19 , wherein the potential interpretation includes a Command type optionally associated with one or more Restriction host types or one or more unresolvable types. The resolution of the potential interpretation comprises calling the Command type and the one or more Restriction host types in an order determined by the interrelationship between the Restriction host type and the solution semantics. The program according to claim 25 .

Images