Abstract:
The invention relates to a method of querying technical domains that recognises the concepts represented by strings of characters, rather than merely comparing strings. It can be used to compute conceptual similarity between terms. The method employs string distance metrics and a cyclic progression of lexical processing to recognise constituent term concepts that are then combined to form full-term concepts by means of a grammar. Terms can be extracted and identified as being conceptually similar (or dissimilar) to other terms even if they have never previously been encountered. 
     A key advantage is the ability to extract terms from documents based on the combination of a limited number of sub-concepts. This avoids the need for the prior identification of all possible terms that current methods require. A second key advantage is the ability to introduce or remove concepts and synonyms individually without the need to alter terms which the concept or synonym constitutes.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is based upon and claims the benefit of priority from British Patent Application Number 1010545.0 filed 23 Jun. 2010, the entire contents of which are incorporated by reference. 
       BACKGROUND OF THE INVENTION 
       [0002]    1. Field of the Invention 
         [0003]    The invention is concerned with identifying and extracting information from character strings and documents, such as technical or scientific documents, and in particular documents in a specific field or domain. 
         [0004]    2. Description of the Related Art 
         [0005]    There are currently two main techniques of named-entity recognition (a more general problem of Terminology Recognition): rule-based methods and heuristic methods. Each technique has its own set of strengths and weaknesses. 
         [0006]    Rule-based methods extract entities based on linguistic rules constructed by domain experts. Heuristic methods extract entities based on measurable features. Various properties could be used as features, for example where the entity is in relation to near-by words, or where the entity is within a table or document. 
         [0007]    The linguistic rules required by rule-based methods are costly to produce and require input from both domain experts and linguists. Results from rule-based methods tend to be precise, but the inflexible nature of the rules mean that entities which differ slightly from the established rule are either mishandled or ignored. The second approach (which is more widely used) is based on machine learning and heuristics. In order to extract and recognise the semantic type of any entity, most machine-learning techniques require training, performed by providing examples of correctly extracted entities. The learning algorithm uses the training data to select features on which classification decisions are based. In the case of text documents, features such as the words immediately preceding or following an entity can be used to classify the entity—for example, a system can be trained to identify the token after the feature “engine serial number:” to be the serial number for that given engine. 
         [0008]    One method of named-entity recognition (the extraction and identification of people, places, object, etc from text) in service documents is achieved by using gazetteer lists; these are lists of the terms expected within the domain of interest. 
         [0009]    Lists of terms for different semantic types are produced, synonyms are added and any inflected forms are generated. Examples of entries in a parts gazetteer include:
       “PYLON INTERFACE I/O 1 (D71423P) CONNECTR”   “PYLON INTERFACE, I/O 2 (D71419P) CONNECTOR”   “tr opening actuator”   “valve-anti ice pressur”   “RB211 524H-T36/11”       
 
         [0015]    These terms are sought within documents, and if they are found the corresponding text is annotated with the semantic type given by the semantic class of the gazetteer list. 
         [0016]    A study of the terms used to refer to components with a particular part number showed that, as the popularity of the part number increases, the number of terms increases in a fairly linear and proportional manner. This is shown in  FIG. 1 . The increase is due to term variation, spelling differences, lexical, morphological and orthographic differences, word order changes, abbreviations and acronyms. This implies that for any given concept it is unlikely that all the terms can be identified in advance. 
         [0017]    Gazetteer lists include lists of precompiled terms with some synonyms, variations and inflections. Unless a term exists in one of the gazetteer lists, it will not be recognised. Because technical domain terms are typified by long strings of nouns where each noun represents an individual concept which itself possesses a long list of synonyms, the combinational and order differences rife in real-world documents mean that an effective gazetteer capable of recognising a fair set of terms is not only very costly to search, but costly to produce and maintain. 
         [0018]    Although examples of the second main type, machine learning (heuristic) approaches, do not require rules and gazetteers, they do require examples of correctly extracted entities. This is often provided by domain experts spending time annotating documents. The laborious and costly nature of this process has given rise to the term ‘annotation bottleneck’ which describes the lack of quality training data. 
         [0019]    When using heuristic methods, the assumption has to be made that the training data are representative of the corpus at large. If this is not the case, performance is drastically reduced. As examples of the prior art, the following can be considered. 
         [0020]    US 2003/177000 (Mao et al./Verity) shows a method and system for naming a cluster of words and phrases. The system uses a lexical database which already links terms to other semantically similar terms (Similar to WordNet). 
         [0021]    US 2009/259459 (Ceusters et al.) describes a Conceptual World Representation Natural Language Understanding System and Method that uses an ontology to represent the relations between concepts (terms), e.g. PARIS is_a FRENCHCITY. This relies on the string of characters ‘paris’ being recognised as the entry “paris” in its lexicon/dictionary/database. 
         [0022]    US 2005/119873 (Chaney et al./Udico) is concerned with a method and apparatus for generating a language-independent document abstract, and relates to a method of document summarisation with a language-agnostic methodology. The method does not make use of any external resources; instead, it uses statistics based on the length of words as an indication of term importance. 
       OBJECTS AND SUMMARY OF THE INVENTION 
       [0023]    The invention is based on a method and a system for Terminology Recognition that operates by recognising a term&#39;s constituent concepts rather than merely its string of characters. The reasoning behind the strategy is that in technical domains it is often the case that two terms can be semantically similar and have a low string distance (i.e. low number of character substitutions, deletions and/or insertions) whereas two other terms can be semantically distant yet have a high string distance. 
         [0024]    An example of this can be seen when considering the term “Bicycle Pump”, where term variations on the theme might include ‘bicycle pumps’, ‘bicycle pmps’[sic], ‘bike pump’. String distance techniques can be successfully employed to relate these terms (as they share large strings of characters in comparatively similar orders); however, the term “Tyre Inflator” (which is semantically similar) and its variations such as ‘tire infltr’[sic], ‘wheel inflator’ are too distant in terms of string distance from ‘bicycle pump’ to register a match. Conversely, the terms “LPT Stage 4 blade” and “HPC Stage 4 blade” have a very low string distance yet refer to two components that are located on opposite ends of a jet engine, operate under very different environmental conditions and are therefore designed and manufactured to fulfil different purposes. 
         [0025]    Series of individual sub-concepts combine to form a main concept. For example, the term “lpc blade leading edge” comprises the sub-concepts [LOW PRESSURE], [COMPRESSOR], [BLADE], [LEADING] and [EDGE]. Together, these sub-concepts refer to the concept [LP C BLADE LEADING EDGE]. Each of the sub-concepts points to a position, an object, a feature or a system and can have numerous synonyms, abbreviations, spelling differences, etc. For a gazetteer to match all terms for the concept [LP C BLADE LEADING EDGE] one would have to duplicate the terms substituting for every synonym of each sub-concept and in each possible order, e.g. ‘low press comp blade leading edge’, ‘low press compressor blade leading edge’, ‘blade, leading edge—lpc’ . . . etc. 
         [0026]    According to one aspect of the invention, therefore, there is provided a method of identifying terms and concepts in documents, as defined in claim  1 . A method for analysing a string of characters is provided. The string of characters may comprise canonical and non-canonical terms relating to a specific domain. The method may be used to identify concepts in that domain. The method may comprise comparing the terms in the string with a lexicon containing canonical terms for sub-concepts in the domain, canonical groups of such terms, synonyms and lexical categories, so as to produce a sequence of annotations comprising terms from the lexicon. The method may also comprise identifying entities by chunking sequences of annotations according to a grammar. The method may extract terms from a string of characters, for example from a document. 
         [0027]    In embodiments of the invention, a matching process is first carried out to convert a list of query terms into a list of sub-concepts, the sub-concepts are grouped into concepts, and the document is searched using these concepts. 
         [0028]    The invention, referred to loosely as TR or Terminology Recognition, relates to a method of querying technical domains that recognises the concepts represented by strings of characters. It can be used to compute conceptual similarity between terms that might differ considerably in form but have the same meaning. TR preferably employs string-distance metrics and a cyclic progression of lexical processing to recognise constituent term concepts that are then combined to form full-term concepts by means of a grammar. Terms can be extracted and identified as being conceptually similar (or dissimilar) to other terms even if they have never previously been encountered. 
         [0029]    A key advantage of the invention is the ability to identify entities and hence extract terms from documents on the basis of the combination of a limited number of sub-concepts. This avoids the need for the prior identification of all terms that current methods require. A second key advantage is the ability to introduce or remove concepts and synonyms individually without the need to alter terms which the concept or synonym constitutes. For instance, if one added ‘book’ as a synonym of ‘combustor’, ‘rear inner book case’ can, without any further action, be recognised as identifying the same concept as ‘cric’ or ‘combustor rear inner case’. The combinational effect of the matching methodology reduces the acquisition overhead, resulting in savings in time and costs. 
         [0030]    A graphical representation of the terms can be used to index the documents. The documents can be queried using a graph formed by a query term, and the distance between terms can be computed on a conceptual level rather than more traditional string-distance methods—strings of characters that refer to the same thing can be linked, even though they share limited (or no) common characters. This means that legacy documents can be effectively queried for entities using terms that may or may not have been used to refer to the entities in the text. 
         [0031]    In embodiments of the invention, the lexicon may contain just a list of (sub-)concepts (e.g. nuts, bolts, blades, cases, for an application to turbine engines) and several synonyms, along with the “parts of term” (similar to Verb/Noun/Adjective) that these concepts may be used as. These parts of term are also denoted “lexical categories”. The most important of these synonyms are then used to name clusters of words, so that further intervention (as in US 2003/177000) to form links is not needed. 
         [0032]    In embodiments of the invention, an ontology is used to represent the relationships within the terms, as opposed to between them. For instance, the structure of the concept “combustor inner case” is represented by “CASE has position INNER”. An important facet of Terminology Recognition is the matching algorithm. For instance, if ‘combustion innr casing’ [sic] does not exist in the lexicon as-is, the matching algorithm will attempt to match it to a close enough entity (i.e. ‘combustor inner case’). 
         [0033]    Embodiments may be performed using a computer program. The computer program may be stored on a computer readable medium. When executed by a computer, the computer program may instruct the computer to perform the methods described herein. 
         [0034]    Further, Terminology Recognition does not account for term importance, as in US 2005/119873; rather, it essentially extracts terms that are made up of words similar to those found in a predefined lexicon before deriving and allowing access to the relationships between the words. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0035]    For a better understanding of the invention, embodiments of it will now be described, by way of example, with reference to the accompanying drawings, in which: 
           [0036]      FIG. 1  shows the linearly proportional increase in the number of terms assigned to a concept with the popularity of that concept; 
           [0037]      FIG. 2  shows a graphical representation of the term “Low-Pressure Compressor Blade Leading Edge”; 
           [0038]      FIGS. 3   a  and  3   b  show the four-stage cyclic matching process used in a preferred embodiment; 
           [0039]      FIG. 4  shows typical results from the matching process at various stages; and 
           [0040]      FIG. 5  shows the process of entity extraction, following the matching process. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0041]    The Terminology Recognition scheme uses a set of lexicons (a separate lexicon for each semantic type involved within a domain—e.g. a lexicon of positional terms, a lexicon of agents, a lexicon of features, a lexicon of mechanisms, etc.) which contain all domain-specific concepts, lists of their distinct synonyms, and the concept&#39;s “part-of-term”, a property similar to a part of speech in that, while part-of-speech denotes whether a word can be a noun, verb, etc., “part-of-term” denotes whether the term is a system/object/type etc. The system compares text to the distinct synonyms using a series of matchers involving string similarity metrics. The matchers are operated in such a way that an exact match to these distinct synonyms is not required—and in practice hardly ever occurs—as minor spelling differences and affixes are considered using string-distance metrics and stemming algorithms. 
         [0042]    Once terms have been tagged (annotated) with sub-concepts, a grammar is employed to group congruent sub-concepts into an entity which describes a concept—for instance, a date, a part, an engine, a mechanism, etc. Different entities can possess various properties; for example, a date can have a year, a month and a day, an engine serial number can have an engine family and a run number, a component can have a system, an object and a position. The Terminology Recognition scheme analyses the constituent entity sub-concepts to determine the type of entity and then attempts to extract the relevant property values. 
         [0043]    The Terminology Recognition method then outputs a graphical representation of the term, within which the concept is represented as a series of nodes and edges corresponding to property values and types. This breaking down of the terms into combinational units can be implemented using Resource Description Framework (RDF—see www.w3.org/RDF), as shown in  FIG. 2 . 
         [0044]    A specific term requires several parts of term: for example, in the case of a part term, an object (a type of thing such as sensor), a type (the type of object, e.g. speed), and an application (where the object is applied, e.g. HP Compressor) are required. Two advantages of representing the term as a graph are:
       1) The graph representation can be used to federate terms by type or system (e.g. list all components related to the HPC, or list all sensors within the engine).   2) The graph representation can be used by a similarity metric which uses the values of the properties to compute similarity (or, inversely, distance) based on sub-concepts.       
 
         [0047]    The input to the Terminology Recognition system is a string of characters, which could be an entire text document or a simple term representing a mechanism or part, for example “leading edge abrasion”, or “combustor rear inner case”. This string of characters will be referred to as the query string. 
         [0048]    The initial operation is to split the query string into all possible n-grams less than a limit. For instance, the three-word term ‘w1 w2 w3’ is split into:
       w1, w2, w3, w1w2, w2w3, w1w2w3       
 
         [0050]    To improve performance for large queries, n-grams up to the limit L are considered. For instance, for the term ‘w1 w2 w3 w4 w5’ with L=3, the following n-grams are produced:
       w1, w2, w3, w4, w5, w1w2, w2w3, w4w5, w1w2w3, w2w3w4, w3w4w5       
 
         [0052]    The limit L is domain-specific and should be set by examining the lexicon. For instance, in the aero-engine domain, the longest compound term was five words long, so L should be set to 5 for this domain. 
         [0053]    The n-grams are then matched to concepts defined in the lexicon by a series of four matchers, as will now be explained. 
         [0054]    Stage 0 Matcher 
         [0055]    Stage 0 matches terms that are represented by regular patterns, such as engine marks (Trent 800, T-800, RB211-T-892), stage ranges (LPT Stage 2, LP2 T, LP Stg.2), engine serial numbers (51123, 71123), ATA codes (72-00-00), and service bulletins (SB72-C927), to name but a few. These are matched, for example using regular expressions, i.e. formally constructed textual search patterns (see www.regular-expressions.info) 
         [0056]    If an n-gram matches, an annotation is created. The annotation includes information such as the start and end offsets (the positions within the term where the match begins and ends), the semantic type of annotation (whether the entity is a part, position, number, feature, etc.—this information comes from the title of the lexicon the match was found in), the part of term (whether the term in the lexicon is an object, system, application, date etc.), the order number (how preferred this annotation is over annotations which include it in a combined term) and the canonical representation (standard form) of the term as listed in the lexicon. 
         [0057]    These annotations are added to a list. 
         [0058]    Stage 1 Matcher 
         [0059]    Stage 1 matches N-Grams as they appear in the lexicon. A normalised string-distance metric, e.g. Levenshtein, is used to compute a similarity score bounded between 0 (totally dissimilar) and 1 (identical). See Levenshtein VI (1966), “Binary codes capable of correcting deletions, insertions, and reversals”, Soviet Physics Doklady 10: 707-10. This string distance score is then normalised by the difference in length between the two terms (but only if there is a difference); this is done in such a way as to penalise heavily term pairs that have similar runs of characters but are of different lengths. This reduces incorrect matching, something that could lead to a missed annotation later on. A threshold ‘Th’ is set, so that, if a term in the lexicon scores a similarity above this threshold, the n-gram is annotated with this matching term. In the case of an engine, Th may set to 0.85, but various values could be used to achieve different results. Because the chance of misspelling a term increases as the length of the term increases, terms that are longer than a certain threshold number of characters, e.g. 12, are not normalised by the difference in term length if the difference in term length is less than or equal to, say, 3 characters: 
         [0060]    If the term is 12 characters or fewer: 
         [0000]    
       
         
           
             Similarity 
             = 
             
               
                 Levenshtein 
                  
                 
                   ( 
                   
                     
                       t 
                        
                       
                           
                       
                        
                       1 
                     
                     , 
                     
                       t 
                        
                       
                           
                       
                        
                       2 
                     
                   
                   ) 
                 
               
               
                 
                    
                   
                     
                       Length_t 
                        
                       
                           
                       
                        
                       1 
                     
                     - 
                     
                       Length_t 
                        
                       
                           
                       
                        
                       2 
                     
                   
                    
                 
                 + 
                 1 
               
             
           
         
       
     
         [0061]    If the term is longer than 12 characters: 
         [0000]      Similarity=Levenshtein( t 1, t 2) 
         [0062]    Of course, thresholds other than 12 may be suitable, depending on the application. To avoid many unnecessary computations (solely to improve performance), the query gram is only compared to the lexicon term if the two terms have a length difference less than a certain number of characters. For instance, it is impossible for the term ‘oil’ to score above 0.85 with the term ‘high-speed gear box’. For the engine query, the character difference threshold is set to 3 characters. 
         [0063]    Once all n-grams have been passed through the matcher, they, or rather their annotations, are combined with those from stage 0. There may be annotations that overlap; for example, ‘LP’ and ‘LP COMPRESSOR’ are both valid annotations for the term ‘LP COMPRESSOR’. Both annotations are correct; however, the annotation ‘LP COMPRESSOR’ contains more information and should be favoured over separate annotations. If two annotations are found to overlap, the annotation with the lower order number is chosen. If two annotations of the same order overlap, the annotation that covers the longer portion of text is chosen. 
         [0064]    Stage 2 Matcher 
         [0065]    The stage 2 matcher accepts the list of annotations made so far and replaces the region matched to the annotations with the canonical form of the term; then a stage 1 matcher is run again. The purpose of this is to recognise variations in compound terms that have not been listed in the lexicon. ‘High Press Comp’ is not listed as a variation of ‘HP C’, but ‘High Pressure Compressor’ is. The annotations ‘High’, ‘Press’ and ‘Comp’ are replaced with their canonical or standard representations ‘high’, ‘pressure’ and ‘compressor’. This expression then matches the variation of ‘HP C’ listed in the lexicon, so the annotation is made. This annotation overlaps with the previous annotations, but because the order of ‘HP C’ is lower than ‘High’, ‘Pressure’ and ‘Compressor’ separately, the former annotation is chosen (the total set of annotations is passed through an annotation resolver). 
         [0066]    Stage 3 Matcher 
         [0067]    Analysing the annotations made after stage 2 may reveal n-grams that have not been annotated. The stage 3 matcher performs further processing on these strings (in a number of discrete steps) in an attempt to match them to terms in the lexicon. 
         [0068]    Stage 3 extracts tokens of the query that are unannotated. These tokens are split on white space and are assumed to be single words (if they form part of a compound term, this is caught later when a stage 2 matcher is run on the resulting stage 3 annotations). The first step of stage 3 involves the removal of suffixes: the unannotated grams are stemmed and compared to stemmed versions of terms in the lexicon, in exactly the same manner as the stage 1 matcher. The second step of stage 3 attempts to correct misspelled words: if the word is not found in a standard word list, such as a standard English dictionary, a list of spelling suggestions is then computed and then each checked against terms in the lexicon in a similar manner to the stage 1 matcher. The third step of stage 3 accounts for the practice of removing vowels and concatenating terms in technical domains, by comparing the unannotated term against the concatenated pairs of terms in the lexicon with vowels removed (a blocking technique is used here to cut down on many unnecessary computations: only term pairs that when their vowels have been removed and have been concatenated are a similar length to the unannotated term are considered). 
         [0069]    These annotations are then passed to the stage 2 matcher, where the terms are replaced by their canonical representations and subsequently passed to the stage 1 matcher that matches the terms to those in the lexicon. 
         [0070]    The annotations are then resolved so that no annotations overlap. The four stages are shown in  FIG. 3 . 
         [0071]    Example of Matching 
         [0072]    A simple lexicon contains the following concepts and synonyms:
       [COMBUSTOR], with synonyms &lt;combustor&gt; and &lt;comb&gt;   [REAR], with synonyms &lt;rear&gt;   [INNER], with synonyms &lt;inner&gt;, &lt;inn&gt;   [CASE], with synonyms &lt;case&gt;, &lt;housing&gt;   [COMBUSTOR REAR INNER CASE], with synonyms &lt;combustor rear inner case&gt; and &lt;rear inner combustor case&gt;       
 
         [0078]    The query term “rear inner combustor case” would be matched with the concept [COMBUSTOR REAR INNER CASE] with the stage 1 matcher. The term is therefore annotated with the [COMBUSTOR REAR INNER CASE] concept. (The stage 0 matcher would not have produced any match). 
         [0079]    The query term “rear inner comb case” would be matched with the concepts [REAR] [INNER] [COMBUSTOR] [CASE] with the stage 1 matcher. These annotations are passed to the stage 2 matcher which then compares the canonical forms. The canonical forms match a synonym for the concept [COMBUSTOR REAR INNER CASE] so the term “rear inner comb case” is annotated with the concept [COMBUSTOR REAR INNER CASE]. 
         [0080]    The query term “rear inner combusting case” would be matched with the concepts [REAR] [INNER] [CASE] by the stage 1 matcher. These annotations are passed to the stage 2 matcher which then compares the canonical forms; the canonical forms do not match any synonym. There is a portion of the original term that has not been annotated; this portion is passed to the stage 3 matcher where it is stemmed to produce the term “combust”. The synonyms in the lexicon are stemmed and compared, the stemmed form of &lt;combustor&gt; is also “combust” and, because there is a match, the term “combusting” is annotated with the concept [COMBUSTOR]. When the term is compared with the stage 2 matcher, the term “rear inner combusting case” is annotated with the concept [COMBUSTOR REAR INNER CASE] because the canonical forms of the individual concepts [REAR] [INNER] [COMBUSTOR] [CASE] match a synonym of the [COMBUSTOR REAR INNER CASE] concept. 
         [0081]    One could at any stage alter the lexicon so that the term “book” was also a synonym of the [COMBUSTOR] concept:
       i.e. [COMBUSTOR], with synonyms &lt;combustor&gt;, &lt;comb&gt; and &lt;book&gt;       
 
         [0083]    The term “rear inner book case” would then also be annotated with the concept [COMBUSTOR REAR INNER CASE], because the canonical forms of “rear”, “inner”, “book” and “case” match a synonym of [COMBUSTOR REAR INNER CASE]. Notice that the synonym &lt;rear inner book case&gt; did not have to be added to the [COMBUSTOR REAR INNER CASE] concept. 
         [0084]    The progress of a typical process is shown by reference to the emerging annotations in  FIG. 4 . 
         [0085]    Entity Recognition 
         [0086]    Once annotations have been made, the annotations are chunked, i.e. formed into small grammatical groups, in accordance with a chunking grammar; that is, annotations of types that are specified in the grammar to be chunkable and that are within a certain number of characters of each other are considered to relate to the same entity. 
         [0087]    The resulting string of annotations is then analysed to determine their type; for example, a string of annotations from the parts lexicon mixed with annotations from the position lexicon are assumed to reference a component. A string of annotations from the marker list is assumed to reference some kind of marker (engine serial number, TV (technical variance) number, service bulletin number, etc.). These strings of annotations create an entity object, which includes the inferable information about the concept referenced, for example, the ATA number 72-34-00 has the description ‘LP C Transportation Parts’. 
         [0088]    Component terms&#39; parts of term are analysed using a grammar, the sub-concept&#39;s part of term is selected from those listed in the lexicon in accordance with a grammar, and a parse tree is generated. For example: ‘lpc blade leading edge’ has two system references ‘low pressure’ and ‘compressor’, the object is ‘blade’, and the blade has feature ‘edge’ which has position ‘leading’. This information is added to the term graph and is exported using RDF. This is shown in  FIG. 5 . 
         [0089]    The system can be used, for instance, for indexing of existing documents and databases using widely varying terminology, so as to identify domain-specific entities, for searching an indexed database by reducing an arbitrary query to standard terminology (canonical terms), or as a “terminology checker” akin to a spelling checker. 
         [0090]    One alternative method of reducing terminology variation is to employ a Controlled Vocabulary, A Controlled Vocabulary forces the use of specific terms when referring to particular concepts (one concept per term). This would allow an effective search of documents written in the controlled vocabulary but would not be as effective when searching legacy documents. 
         [0091]    In a further development of the invention, the methodology employed by the Terminology Recognition concept may be abstracted a level. The system currently constructs representations of terms based on the semantic type of their sub-concepts and associated grammar; terminology recognition can be abstracted so that any process or thing can be constructed by any number of contiguous entities, for instance:
       A mechanism comprises a driver, the mechanism itself, and a type.   An impact comprises a customer and a recovery.   A document context comprises a date, a customer and a flight regime.       
 
         [0095]    The methodology used by the Terminology Recognition invention is domain-independent, so a domain-dependent lexicon must be supplied. This lexicon is a specification of the common concepts found in the domain. A lexicon describing office furniture may define ‘desks’, ‘legs’, and ‘drawers’; these three concepts mix and match to form the concepts ‘desk’, ‘desk legs’ and ‘desk drawers’. In an aerospace-engine lexicon one may define ‘fan’, ‘blade’ and ‘shaft’, which can be combined to form ‘fan blade’, ‘fan shaft’ etc. 
         [0096]    Terminology Recognition Context 
         [0097]    An example application of TR is a search application for documents in the form of aerospace engine summary reports, where engine component terms are used with a high degree of term variation (e.g. orthographic differences, spelling errors, term variation, abbreviations, acronyms and lexical differences). Given a query term, the conceptual similarity between all the terms in the index can be computed resulting in a results set comprising terms (and documents) which reference the same concept as the query, but using different terms. 
         [0098]    Once a term has been annotated (tagged as representing a particular concept), the concept can be analysed to uncover additional information. The Engine serial number 51123 signifies a Trent 800 engine that is currently in service that was the 123 rd  off the production line. The sub-concepts can be used to better classify ATA Spec 100 or JASC codes—an internationally used numbering scheme for aircraft parts and processes (See: http://av-info.faa.gov/sdrx/documents/JASC_Code.pdf). 
         [0099]    Terminology Recognition can be used to support multiple processes in different situations. Terminology Recognition has already been used (in tests) to identify single and multi-word domain-specific terms such as component names, features, faults, dates, etc, in documents and normalise them to a standard form which can then be saved (along with the original form) to an index. For example, given the sentence fragment:
       “ . . . on Jun. 8, 2007, the IP2 T Blade on ESN51123 was found to be cracked . . . .”       
 
         [0101]    Terminology Recognition would identify four entities: a date, a component, an engine and a deterioration mechanism. Associated with these entities will be: the original term, a standard version of the term, and additional information. This can be shown in the XML fragment: 
         [0000]    
       
         
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 &lt;sentence&gt; 
               
             
          
           
               
                   
                 &lt;entity type=“date”&gt; 
               
               
                   
                 &lt;originalText&gt;June 8th, 2007&lt;/originalText&gt; 
               
               
                   
                 &lt;standardForm&gt;08-06-2007&lt;/standardForm&gt; 
               
               
                   
                 &lt;year&gt;2007&lt;/year&gt; 
               
               
                   
                 &lt;month&gt;June&lt;/month&gt; 
               
               
                   
                 &lt;day&gt;08&lt;/day&gt; 
               
               
                   
                 &lt;/entity&gt; 
               
               
                   
                 &lt;entity type=“component”&gt; 
               
               
                   
                 &lt;originalText&gt;IP2 T Blade&lt;/originalText&gt; 
               
               
                   
                 &lt;standardForm&gt;Intermediate Pressure Compressor Stage 2 
               
             
          
           
               
                   
                 Blade&lt;/standardForm&gt; 
               
             
          
           
               
                   
                 &lt;hasSystem&gt;IPC&lt;/hasSystem&gt; 
               
               
                   
                 &lt;hasObject&gt; 
               
             
          
           
               
                   
                 Blade 
               
               
                   
                 &lt;hasPosition&gt;Stage 2&lt;/hasPosition&gt; 
               
             
          
           
               
                   
                 &lt;/hasObject&gt; 
               
             
          
           
               
                   
                 &lt;/entity&gt; 
               
               
                   
                 &lt;entity type=“Engine”&gt; 
               
               
                   
                 &lt;originalText&gt;ESN51123&lt;/originalText&gt; 
               
               
                   
                 &lt;standardForm&gt;ESN51123&lt;/standardForm&gt; 
               
               
                   
                 &lt;engineType&gt;Trent 800&lt;/engineType&gt; 
               
               
                   
                 &lt;inService&gt;True&lt;/inService&gt; 
               
               
                   
                 &lt;runNumber&gt;123&lt;/runNumber 
               
               
                   
                 &lt;/entity&gt; 
               
               
                   
                 &lt;entity type=“mechanism”&gt; 
               
               
                   
                 &lt;originalText&gt;cracked&lt;/originalText&gt; 
               
               
                   
                 &lt;standardForm&gt;crack&lt;/standardForm&gt; 
               
               
                   
                 &lt;/entity&gt; 
               
             
          
           
               
                   
                 &lt;/sentence&gt; 
               
               
                   
                   
               
             
          
         
       
     
         [0102]    Within this XML fragment (of course, XML is only an example of TR output data), it can be seen that Terminology Recognition has inferred information such as the engine type and run number, and derived the structure of the component term (the component comprises a system and an object, and the object has the position); these have been extracted and stored from the Engine Serial Number entity. 
         [0103]    The application of Terminology Recognition is separate to the methodology: TR can in particular be used as an application programming interface or API. Now that the ability exists to extract the entities along with their standard form, the entities can be used to improve search. Here the Terminology Recognition system stores the standard form of terms along with the form found in the document; a user will search using a term of their choice, and documents that use different terms to refer to the same concept will be returned. Search engines are currently not capable of doing this unless a list of synonyms already exists. 
         [0104]    Terminology Recognition can also be used in a ‘spell-checker’ scenario, when an Engineer writes a report, Terminology Recognition (which can be run as a VisualBasic macro) analyses the text and detects entities on the fly. For instance, as the user types ‘IP NGV Ring’ the macro underlines the term because Terminology Recognition has recognized the term as being ambiguous; by referencing the Engine Parts Catalogue, which is machine-readable, it can be seen that there are two rings in the IP system with an application of NGV—the Split ring, and the Stand-Off ring. This ambiguity may cause major issues and can even be dangerous, so in a similar manner as correcting a spelling error, the user right-clicks the term and the two possible terms (IP NGV Split Ring &amp; IP NGV Stand-Off Ring) are presented. The Engineer clicks the term they mean and continues typing the report. The term is now fully unambiguous and uses correct, standard terminology. 
         [0105]    The invention therefore has application to many fields. For instance, continuing studies into the use of the Terminology Recognition invention in biomedical and botanical domains show promising results.