Abstract:
Inferring a natural language grammar is based on providing natural language understanding (NLU) data with concept annotations according to an application ontology characterizing a relationship structure between application-related concepts for a given NLU application. An application grammar is then inferred from the concept annotations and the application ontology.

Description:
TECHNICAL FIELD 
       [0001]    The present invention relates to natural language understanding (NLU), and in particular, to automatic generation of NLU grammars from application ontologies. 
       BACKGROUND ART 
       [0002]    Natural Language Processing (NLP) and Natural Language Understanding (NLU) involve using computer processing to extract meaningful information from natural language inputs such as human generated speech and text. One recent application of such technology is processing speech and/or text queries in mobile devices such as smartphones. 
         [0003]    U.S. Patent Publication 20110054899 describes a hybrid client-server NLU arrangement for a mobile device. Various example screen shots of the application interface  100  from one such mobile device NLU application, Dragon Mobile Assistant for Android, are shown in  FIGS. 1A-C . Dragon Mobile Assistant processes speech query inputs and obtains simultaneous search results from a variety of top websites and content sources. Such applications require adding an NLU component to an existing web search algorithm and an automatic speech recognition (ASR) arrangement in order to extracting semantic meaning from the input queries. 
         [0004]    An NLU application based on ASR utilizes a statistical language model to initially recognize the words or likely words that were uttered based on probabilities such as the probability that an utterance is a given word based on one or more previously recognized words. Some language models are topic domain-specific such as medical radiology or aircraft control. A language model is often built by analyzing a large set of representative sentences, phrases or the like, to obtain statistics about word occurrence frequency, which words tend to occur after other words or phrases, etc. 
         [0005]    The recognition grammars acts to interpret the semantic meanings of the recognized words. In this context, a recognition grammar is a set of phrases that a system is prepared to recognize. Conceptually, the phrases in a grammar represent all legitimate utterances a user may make. If a user utterance is included in the grammar, the system recognizes words of the utterance. If the user utters something that is not in the grammar, the utterance may be considered ungrammatical (“out-of-grammar”), and the system may not recognize the utterance correctly. 
         [0006]    However, typically there are many ways a human can express a particular idea or command. For example, a user may order “two large pizzas, one with olives and the other with anchovies,” or the user may say she wants “one olive pizza and one anchovy pizza, both large.” Both utterances have the same meaning. Thus, a grammar writer&#39;s task involves predicting a set of phrases and encoding the phrases in the grammar. However, due to the variety of ways ideas and commands can be expressed, a grammar that accommodates a reasonable range of expressions can be quite large and difficult to design. Furthermore, the complexity of a grammar greatly affects speed and accuracy of an ASR system. Thus, complex grammars should be constructed with as much care as complex software programs. Grammar writing, however, is an unfamiliar task for most software developers, and creating a high-quality, error-free grammar requires somewhat different skills than programming in a language, such as Java or C++. For example, grammars are inherently non-procedural. Thus, many typical software development approaches are not applicable to grammar development. 
         [0007]    In a speech-enabled NLU application, recognition slots are sometimes used to hold individual pieces of information from a recognized utterance. For example, in an automated banking system, slots may be defined for: (1) command-type (examples of which may include deposit, withdrawal, bill-payment and the like); (2) source-account (checking, savings or money-market); and (3) amount. An NLU application fills these slots with logical representations of recognized words and then passes the slots to application code for processing. For example, the phrases “the first of March” and “March the first” may cause a slot labeled date to be filled with “Mar01” or some other unambiguous date representation. 
         [0008]    Developing NLU grammars is a time-consuming expensive process that requires considerable time and effort from human experts using large databases. 
       SUMMARY 
       [0009]    Embodiments of the present invention are directed to inferring a natural language grammar based on providing natural language understanding (NLU) data with concept annotations according to an application ontology characterizing a relationship structure between application-related concepts for a given NLU application. An application grammar is then inferred from the concept annotations and the application ontology. 
         [0010]    The concept annotations may then be revised based on parsing the NLU data and the concept annotations with the application grammar. New NLU data can be parsed with the application grammar to develop concept annotations for the new NLU data; for example, using a structure tree of the concept annotations reflecting the application ontology. Inferring an application grammar may include inferring a back-off grammar from the annotations. Inferring an application grammar also may include incorporating one or more existing grammars for one or more of the application-related concepts. The inferred application grammar can be employed in an initial semantic interpreter for an NLU arrangement. The inferred grammar rules can be used to parse an input query to extract features for semantic processing by a statistical learning machine arrangement. 
         [0011]    Embodiments of the present invention also include a computer program product in a non-tangible computer readable storage medium for execution on at least one processor of a method of inferring a natural language grammar, wherein the computer program product has instructions for execution on the at least one processor comprising program code for performing the method according to any of the above. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0012]      FIG. 1A-C  shows examples screens from an NLU application for a mobile device. 
           [0013]      FIG. 2  shows various functional blocks and relationships in an NLU system for inferring grammars according to an embodiment of the present invention. 
           [0014]      FIG. 3  shows various logical steps in developing an inferred grammar according to an embodiment of the present invention. 
           [0015]      FIG. 4  shows an example of an ontology for airline travel. 
           [0016]      FIG. 5  shows an example of annotated data. 
           [0017]      FIG. 6  shows an example of a tree structure display for hierarchical annotation of data. 
           [0018]      FIG. 7  shows an example of a statistical learning machine arrangement using inferred grammar rule output to add to the input feature set of the machine. 
       
    
    
     DETAILED DESCRIPTION 
       [0019]    Embodiments of the present invention are based on developing NLU grammars for a new application or new vertical domain from an application/domain ontology and a hierarchy of concept annotations. Existing grammars for common concepts are reused instead of relying on costly experts and time-consuming wholly manual process. An annotation user provides concept annotations from high-level concept (e.g., intentions) down to low-level concepts based on the concept relationships described by the ontology. That then allows grammar rules to be directly inferred. 
         [0020]      FIG. 2  shows various functional blocks and relationships in an NLU system for inferring grammars, and  FIG. 3  shows various logical steps in developing an inferred grammar. First, a new application ontology 204 is defined, step 301 that describes the various concepts that need to be extracted by the NLU system and a hierarchy of their relationships. This is described at some length in U.S. patent application Ser. No. 13/852,165, filed Mar. 28, 2013, which is incorporated herein by reference. 
         [0021]    For example,  FIG. 4  shows an ontology  204  for an airline ticket reservation application based on relationships such as isA and hasA and universal common concepts with existing grammars (e.g. list of cities). The design of such a new NLU application uses an itemization of possible “intentions,” including, for example, the “user intent to travel,” intent_fly  401 . Such an “intention” comes with a number of possible sub-pieces of information such as departure_location  402 , departure_date  406 , departure_time  405 , and arrival location  404 . These mid-level intentions in turn are related in the ontology  204  to more basic low-level concepts. Both departure_location  402  and arrival_location  404  derive from the lower mid-level concept location  403 , which in turn can be represented by low-level concepts such as city  408 , country  407  and/or airport  409 , each of which can point to an already existing grammar  202 . Similarly, mid-level concepts departure_time  405  and departure_date  406  derive from low-concepts time  410  and date  411  that have existing grammars  202 . Those grammars can come from heavily-tuned phase structure grammars (e.g., for date and time) or from database look-up (e.g., for cities). 
         [0022]    Low-level concepts such as location, date, time, etc. are common to many pre-existing applications and can be present in a common ontology with corresponding grammar links. An annotation user  210  then only needs to add new domain-specific concepts to the ontology  204 . In the example shown in  FIG. 4 , the annotation user  210  will only have to declare the new concept intent_fly  401 . 
         [0023]    Once the ontology  204  has been defined, step  301 , an annotation user  210  uses an annotation module  203  to annotate input training data  201  for the new application, step  302 . The user  210  tags each available sentence in the training data  201  with the appropriate multi-level concept annotations from the defined ontology  202 . The first level is the intent, if there is one is present. Then in lower concept levels come the specific parts of the intent that are linked to low-level concepts. 
         [0024]    For example, the sentence I would like to fly from Montreal to New-York next Monday would be tagged as: 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                  First level: &lt;intent_fly&gt; I would like to fly from Montreal to 
               
               
                 New-York next Monday &lt;/intent_fly&gt; 
               
               
                 Second level: &lt;intent_fly&gt; I would like to fly from 
               
               
                 &lt;departure_location&gt; Montreal &lt;/departure_location&gt; to 
               
               
                 &lt;arrival_location&gt; New-York &lt;/arrival_location&gt; &lt;departure_date&gt; 
               
               
                 next Monday &lt;/departure_date&gt; &lt;/intent_fly&gt; 
               
               
                 Third level: &lt;intent_ fly&gt; I would like to fly from &lt;departure_location&gt; 
               
               
                 &lt;location&gt; Montreal &lt;/location&gt; &lt;/departure_location&gt; to 
               
               
                 &lt;arrival_location&gt; &lt;location&gt; New-York &lt;/location&gt; 
               
               
                 &lt;/arrival_location&gt; &lt;departure_date&gt; &lt;date&gt; next Monday &lt;/date&gt; 
               
               
                 &lt;/departure_date&gt;&lt;/intent_fly&gt; 
               
               
                 Fourth level: &lt;intent_fly&gt; I would like to fly from 
               
               
                 &lt;departure_location&gt; &lt;location&gt;&lt;city&gt; Montreal&lt;/city&gt; &lt;/location&gt; 
               
               
                 &lt;/departure_location&gt; to &lt;arrival_location&gt; &lt;location&gt; &lt;city&gt; New-York 
               
               
                 &lt;/city&gt; &lt;/location&gt; &lt;/arrival_location&gt; &lt;departure_date&gt; &lt;date&gt; 
               
               
                 &lt;order&gt;next &lt;/order&gt; &lt;day_of_week&gt; Monday 
               
               
                 &lt;/day_of_week&gt; &lt;/date&gt; 
               
               
                 &lt;/departure_date&gt; &lt;/intent_fly&gt; 
               
               
                   
               
             
          
         
       
     
         [0025]      FIG. 5  shows an example of how that final level of annotation might be presented via API  208  and UI Layer  209  to the user  210 . It may be useful for an annotation classifier  206  to provide the annotation user with accurate annotation suggestions  207  at all levels. For example,  FIG. 6  shows a tree-like annotation structure that just specifies the information added at each level so that the display is much less complicated than the string shown in  FIG. 5 . 
         [0026]    Given multiple levels of annotation from defining the application ontology, step  301 , and annotating the training data  201  via annotation module  203 , step  302 , a grammar inference module  205  can infer grammar rules for an NLU grammar  212  for the new application, step  303 . Once there is multi-level annotation data  213 , the grammar inference module  205  can create a grammar rule that refers to lower-level concept grammars and promotes those to the correct higher-level concepts. This can be done for each level of the annotation hierarchy. The new application grammar  212  is not inferred directly using the ontology  204 , but rather indirectly because the annotation module  203  is driven by the ontology  204  and the annotation user  210  can only select concepts that are linked in the ontology  204 . During the annotation module  203 , the UI Layer  209  may only let the annotation user  210  select concepts that are linked together in the ontology  204 . 
         [0027]    The previous example sentence, I would like to fly from Montreal to New-York leaving next Monday, provides the inference of the grammar path: 
         [0000]                                &lt;item&gt;         I would like to fly from         &lt;ruleref uri=“#LOCATION”/&gt; &lt;tag&gt;departure_location=         LOCATION.location&lt;/tag&gt;         to         &lt;ruleref uri=“#LOCATION”/&gt; &lt;tag&gt;arrival_location=         LOCATION.location&lt;/tag&gt;         leaving         &lt;ruleref uri=“#DATE”/&gt; &lt;tag&gt;departure_date= DATE .date&lt;/tag&gt;         &lt;tag&gt; intent = “intent_fly”&lt;/tag&gt;       &lt;/item&gt;                    
where the grammar rule LOCATION includes a grammar of city names:
 
         [0000]                                        &lt;rule id=“LOCATION” scope=“private”&gt;            &lt;one-of&gt;               &lt;item&gt; &lt;ruleref uri=“City.grxml ”/&gt;               &lt;tag&gt;location=City.city&lt;/tag&gt;               &lt;/item&gt;             &lt;/one-of&gt;           &lt;/rule&gt;                    
The grammar rule DATE includes absolute and relative date-defining phrases. Note that the grammar rules inferred from the first two levels represent full sentence covering rules in the new application grammar  212 . Those full sentence rules come directly from the annotated data  213 .
 
         [0028]    Another example sentence might be: When does flight one two three arrive. The annotation would be: 
         [0000]                                        &lt;request_arrival_time&gt; When does flight           &lt;flight_number&gt; &lt;cardinal_number&gt; one two three           &lt;/cardinal_number&gt; &lt;/flight_number&gt; arrive           &lt;/request_arrival_time&gt;                    
And the resulting full inferred sentence rule is:
 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 &lt;item&gt; 
               
               
                   When does flight 
               
               
                   &lt;ruleref uri=”CARDINAL_NUMBER”/&gt; 
               
               
                     &lt;tag&gt;flight_number = CARDINAL_NUMBER.number &lt;/tag&gt; 
               
               
                   arrive 
               
               
                   &lt;tag&gt;itent = “request_arrival_time”&lt;/tag&gt; 
               
               
                 &lt;/item&gt; 
               
               
                   
               
             
          
         
       
     
         [0029]    In the first inferred grammar example above, the words Montreal, New York, next, and Monday are handled by the respective low level concepts cities, cities, order and day_of_week. And so it is enough for the grammar inference module  205  to just infer grammar rules that promote those low-level concepts, and there is no need to create new rules that catch words and set values (like a rule that returns city:montreal for the word Montreal). But some concept words may not be covered by the low-level concepts rules. Take for example the sentence:
   I would like to fly from Montreal to the Big Apple next Monday.
 
The annotation user  210  would tag this sentence as before except that when tagging “the Big Apple” as a city, the grammar inference module  205  knows that city is a terminal low-level concept in the ontology  204  with an existing grammar  202 . And the grammar inference module  205  will also know that “the Big Apple” is not covered by the city grammar, and will ask the annotation user  210  for a value for the slot return by that grammar. In this example, the annotation user  210  might respond by entering the value “New York” and then the grammar would be modified to now cover the Big Apple.
   
 
         [0031]    The inferred new application grammar  212  as initially created covers full sentences. For robust NLU operation, the grammar inference module  205  also creates smaller back-off grammar rules, step  304 . By using the top-level annotation of all the verified sentences in the annotated data  213 , the grammar inference module  205  can extract part of an annotation that appears in the same context. For example:
   I want to fly from DEPARTURE_LOCATION to ARRIVAL_LOCATION.   I would like to go from DEPARTURE_LOCATION to ARRIVAL_LOCATION.   I&#39;m leaving from DEPARTURE_LOCATION going to ARRIVAL_LOCATION next month.
 
In these examples, the grammar inference module  205  extracts “from DEPATURE_LOCATION” and “to ARRIVAL_LOCATION” as unambiguous rules that are added as back-off rules to the inferred application grammar  212 . In general, these are derived from contextual existing grammars  202  labeled above as:
   “&lt;intention&gt;_&lt;X&gt;_DEPARTURE LOCATION” and   “&lt;intention&gt;_&lt;X&gt;_ARRIVAL LOCATION”.   
 
         [0037]    Output slot format. The inferred grammar needs to generate an output that will be understood by the component using the NLU engine  214 . That can be done using a meaning representation in JSON format as the output of the inferred grammar based on the annotation and the ontology. This meaning representation is the information extracted by the NLU engine  214  that will be sent to the next component, for example, Application Developer Kit (ADK)  215 . 
         [0038]    Suppose the intention intent_travel is associated with the following sentence: 
         [0000]                                        I would like to fly from &lt;departure_location&gt; &lt;location&gt; &lt;city&gt;           Montreal&lt;/city&gt; &lt;/location&gt; &lt;/departure_location&gt; to           &lt;arrival_location&gt; &lt;location&gt; &lt;city&gt; New-York &lt;/city&gt; &lt;/location&gt;           &lt;/arrival_location&gt;.                    
The NLU engine  214  parses the sentence: “I would like to fly from montreal to new york,” with the application grammar  212  and the output JSON format will be:
 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 {“INTENT_TRAVEL” : { 
               
               
                 “DEPARTURE_LOCATION” : { “LOCATION” : {“CITY” : 
               
               
                 “montreal” } } }, 
               
               
                 “ARRIVAL_LOCATION”:{ “LOCATION” : {“CITY” : “new york” } } 
               
               
                 } 
               
               
                   
               
             
          
         
       
     
         [0039]    The application grammar  212  can also be applied to the annotated data  213 , step  305 , to evaluate the consistency of the annotation module  203 . Sentences in the annotated data  213  which are covered by the application grammar  212  parse fully. This can be done regularly in the user annotation session and permits significant annotation time savings since as the annotation user  210  progresses, more and more sentences in the annotated data  213  are already covered by the development of the application grammar  212  coming from previous annotations. The annotation user  210  also can reimport and re-annotate data that is not yet covered by the inferred application grammar  212 , step  306 , and this can be iteratively repeated as many times as needed. 
         [0040]    Such inferred grammars can be used in a front-end initial semantic interpreter for an NLU arrangement such as statistical semantic model (SSM) system. A user input query can be parsed by the inferred grammars to develop a semantic interpretation. If the grammar parsing of the input query is unsuccessful (no meaning returned), then the query can be passed to a statistical learning machine for an interpretation. For example,  FIG. 7  shows an arrangement where the user input query  701  is parsed by the inferred grammar rules to extract additional query features  703  (e.g., one feature for each firing rule) which are added to any existing query features  703  for further downstream processing by the statistical learning machine arrangement  704 . Such a statistical learning machine arrangement  704 , may be, for example, a statistical semantic model (SSM) arrangement such as the Nuance SSM or any similar learning machine. 
         [0041]    Embodiments of the invention may be implemented in whole or in part in any conventional computer programming language. For example, preferred embodiments may be implemented in a procedural programming language (e.g., “C”) or an object oriented programming language (e.g., “C++”, Python). Alternative embodiments of the invention may be implemented as pre-programmed hardware elements, other related components, or as a combination of hardware and software components. 
         [0042]    Embodiments can be implemented in whole or in part as a computer program product for use with a computer system. Such implementation may include a series of computer instructions fixed either on a tangible medium, such as a computer readable medium (e.g., a diskette, CD-ROM, ROM, or fixed disk) or transmittable to a computer system, via a modem or other interface device, such as a communications adapter connected to a network over a medium. The medium may be either a tangible medium (e.g., optical or analog communications lines) or a medium implemented with wireless techniques (e.g., microwave, infrared or other transmission techniques). The series of computer instructions embodies all or part of the functionality previously described herein with respect to the system. Those skilled in the art should appreciate that such computer instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Furthermore, such instructions may be stored in any memory device, such as semiconductor, magnetic, optical or other memory devices, and may be transmitted using any communications technology, such as optical, infrared, microwave, or other transmission technologies. It is expected that such a computer program product may be distributed as a removable medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the network (e.g., the Internet or World Wide Web). Of course, some embodiments of the invention may be implemented as a combination of both software (e.g., a computer program product) and hardware. Still other embodiments of the invention are implemented as entirely hardware, or entirely software (e.g., a computer program product). 
         [0043]    Although various exemplary embodiments of the invention have been disclosed, it should be apparent to those skilled in the art that various changes and modifications can be made which will achieve some of the advantages of the invention without departing from the true scope of the invention.