WO2014071330A2 - Natural language processing system and method - Google Patents

Abstract

A natural language processing system is disclosed herein. Embodiments of die NLP system perform hand-written rule-based operations thai do not rely on a trained corpus. Rules can be added or modified at any time to improve accuracy of the system, and to allow the same system to operate on unstructured plain text from many disparate contexts (e.g. articles as well as twitter contexts as wei! as medical articles) without harming accuracy for any one context. Embodiments also include a language decoder (LD) that generates information which is stored in a three-level framework {word, clause, phrase). The LD output is easily leveraged by various software applications to analyze large quantities of text from any source in a mote sophisticated and flexible manner than previously possible. A query language (LDQL) for information extraction from NLP parsers' output is disclosed, with emphasis on on its embodiment, implemented for LD. it is also presented, how to use LDQL for knowledge extraction on the example of application named Knowledge Browser.

Description

U.S. Patent Application for

NATURAL LANGU AGE FROCESSiNG SYSTEM AND METHOD

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application No. 61/72! ,792, filed November 2, 2012, which is incorporated by reference herein in its entirely.

FIELD OF THE INVENTION nventions disclosed and claimed herein are in the field of natural language processing (NLP).

BACKGROUND

Natural language processing (NLP) systems are computer-implemented methods for taking natural language input (fo example, computer-readable text), and operating on the input so as to generate output that is useful for computers to derive meaning. Examples of NLP systems applications include spell checkers/grammar checkers, machine translation systems, and speech-to-text systems. Increasingly, there is interest in developing methods for machines to more intelligently interpret human language input data (such as text) for the purpose of directing the computer as if it were another person who could understand speech. One application for such methods is search engines that receive a typed query from a person and perform web searches to attempt to generate a set of meaningful answers to the query. An important subclass of NLP systems is NLP parsers, especially grammatical parsers such as Part-Of-Speech tagger, constituency parsers, dependency parsers, and shallow semantic parsers such as S L (Semantic Role Labeling). Their role is to preprocess text and add additional information to words to prepare it for further usage. Current NLP systems are mostly built on top of NLP parsers and they features and accuracy strongly relies on the information produced by these parsers. Qualify of the information deli vered by these parsers is strongly correlated with the efficiency of NLP systems.

Figure I i a block diagram of prior art NLP parsers 100. The input is a text, which is processed by NLP parser ( 102) consisting of machine learning techniques ( 104) trained on manuall annotated corpus (105). The parser (102) produces the output (103) which is then used by other systems/applications ( 106),

All current parsers are dependent on corpora and therefore on the context in which they were written. Typically corpora are in a context of correctly written, grammatically correct sentences and common syntactic structures which are manually annotated by humans. The system is then trained using this corpus.

This is one reason that traditional NLP parsers are most accurate on the same type of content they were trained on (the same corpus). That is why always-changing language, such as user generated content (e.g. reviews, tips, comments, tweets, social media content) presents a challenge for NLP parsers built with machine learning techniques. Such conten often includes grammatically incorrect sentences and non-standard usage of language, as well as emottcons, acronyms, strings of non-letter characters and so on. This content, is constantl changing and expanding with different words or syntactic structures. A ll of this content has meaningful information and it is easy to understand by humans but it is still difficult for NLP applications to extract meaning out of it.

One way in which current NLP parsers cm be updated or improved (for better accuracy or extracting additional information) is to modify the existing corpus, or create a new corpus or re-annotate existing one and retrain the system with it to understand new content. However, this is a tedious, cosily and iime-consuming process. For example all current NLP parsers are using corpus as a framing data annotated by linguists with predefined tags (e.g. Perm Treefaank) - especially use machine-learning algorithms.

If there was a need to distinct pronominal or adjectival aspect of "that" (giving them different POS tags in different context), one would need to maaualiy re-annotate by linguists all the sentences in the whole corpus that contain word ^"that" -regarding the context of each usage of "that" and retrain the parser.

Building a particular application on top of and NLP parser requires building a module to transform the NLP parser output into usable data. The application using the parser's output could be coded in a programming language, use a rule based systems or be trained with machine learning techniques - or created with combination of any of the above methods.

Using NLP parsers can be challenging due to the need to understand the structure of the output and parameters (requires expert knowledge). One of the challenges in NLP parsers is to provide constant consistent structure of information. Also, the output of the NLP parsers rely on the qualit of the input tex t data.

For example.

Let's consider these sentences J. John likes math. 2. John likes to learn. 3 John likes learning math in the evening. By using grammar parsers in each ease you will get different notations for the object what John likes. la constituency parsers the number of levels (depth) in parse tree depends of the length and the grammatical structure of the processed sentences. In a given example the first sentence has 3 levels, the second sentence lias 5 levels and the third example has 6 levels in a tree representation.

In state-of-the-art dependency parsers fee stroctore of the output aod number of levels in the dependency tree representation also vary. Adding even one word in the sentence can alter the grammatical information of all the other words.

The given example about John would produce different structure for eac sentence. The first sentence require extracting dependents of "dobj" relation connected to the word "likes", in second all dependents of "xcomp" relation connected to the word "likes" and in third example there is a need of analyzing all governors connected to dependents of "xcomp" related to the word "likes".

All of the above is the reason why it is difficult for people and especially non-linguists (developers, analysts) to use the parser output and write rules to adjust it to their current needs. E.g. to write information extraction engine to extract information about product features from reviews you cooid use constituency or dependency parser but you need to write complex algorithms to search through the parse tree. To move to another domain (e.g. extracting information from twitter) the algorithms must be redesigned, and part of the code rewritten.

To deal with these problems NLP systems use machine learning techni ues. This approach has some limitations in terms of accuracy and amount of extracted information.

There are query languages to process structured data (e.g. SQL fo relational databases, Cyphe for graph databases, SPARQL - RDF tagged texts (resource description framework)) but there are no languages designed directly to query structure of the natural language (output of the NLP parser).

It would be desirable to have an efficient framework of storing information decoded from text, it should provide invariant and consistent way of storing information which would be insensitive to different types of input. Having such a framework, would be possible for nonexperts to write efficient rules on top of NLP parser's output

It would be desirable to have a parser for natural language processing that is built fully algorithmicaSly so it allows for constantly improvement in accuracy, and the addition of new features, without building or re-annotating any corpus. It would desirable to have an. NLP system that is more capable than current NLP parsers of dealing with non-typical grammatical input, deals well with constantly-changing language on the web, and produces accurate output which can be stored into art efficient framework of information. it would also be desirable to have a query language that can be used on the logical layer across different input contexts allowing humans to write efficient rules tor extracting information and is capable of effecti vely leveraging many NLP systems.

BRIEF .DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram of a prior art natural language processing system.

Figure 2 is a block diagram of a natural language processing environment according to an embodiment.

Figure 3 is a block diagram of a natural language processing sy stem according to an embodiment. Figure 4 is a block diagram of a natural language processing sy stem according to an embodiment.

Figure 5 is a block diagram of word tagger according to an embodiment.

Figure 6 is a flow diagram of a word tagger updating or exception handling method according to an embodiment.

Figure 7 is a block diagram of clause divider elemen ts aad processes according to an embodiment.

Figure 8 is a flow diagram, of a clause divider updating or exception handling method according to an embodiment.

Figures 9-14 are diagrams of a clause di vider process according to an embodiment.

Figure 1.6 is a block diagram of ccomodator according: to an embodiment

Figure 17 is a flow diagram of the "it" test according to an embodiment

Figures 18-23 are diagrams illustrating the operation of the accomodator according to an embodiment.

Figure 24 is a flow diagram of Language Decoder updating or exception handling method according to an embodiment.

Figure 25 is a diagram of a three-level output structure for LD 203 according to an embodiment

Figure 26 is a diagram illustrating the operation of a language decoder (LD) according to an embodiment

Figure 27 is a diagram illustrating an overview of an information extraction methodology according to an embodiment. Figures 28-34 illustrate a user interface of a knowledge browser application according to an embodiment.

DETAILED DESCRIPTION

Embodiments of inventions disclosed herein include improvements on current LP systems and methods that are especially relevant to processing input that consists of plain text from different types of context. As such, the embodiments disclosed herein provide a highly accessible platform for natural language processing. The output of the disclosed ^"NLP system is easily leveraged by various software applications to analyze large quantities of text from any source in a more sophisticated and flexible manner than previously possible.

The Language Decoder is a novel fully algorithmic NLP parser that is decoding iaformation out of text and store it into three-level framework which is capable of handling various type of texts from different domain like reviews, news, formal documents, tweets, comments etc..

The algorithmic nature of the system allows to achieve high accuracy ort user generated content.

Embodiments of the NLP system can thus work property on different kinds of domains at the same time.

This three-level hierarchical framework of processed text is leveraged b embodiments of a language decoder query language LDQ.L as further described herein. The LDQL is particularly easy to use for developers, without requiring specific linguistics training. However, other rule-based query languages could conceivably be developed for extraction

(by query) of information from text processed by the LD.

Figure 2 is a block diagram of a natural language processing environment 200 according to an embodiment. A natural language processing (NLP) system 200 accepts text as input. Text can include electronic data from many sources, such as the Internet, physical media (e.g. hard disc), a network connected data base, etc. The NLP system 200 includes multiple databases 202A and multiple processors 202B, Databases 202A and processors 202B can be located anywhere that is accessible to a connected network 208, which is typically the Internet, Databases 202A and processors 202B can also be distributed geographically in the ^'known manner. Data sources 210 include: 1) any source of electronic data that could serve as a source of text input to NLP system 202, and 2) any source of electronic data that could, be searched using the output of NLP system, 202 as described further below.

Other systems and applications 106 are systems, including commercial systems and associated software applications that have the capability to access arid use the output of the NLP system 202 through one or more application programming interface (APIs) as further described below. For example, other systems/applications 106 can include an online application, offering its users a search engine for answering specific queries. End users 212 includes indiv iduals who might use applications 106 through one or more of end user devices 12.1 A. User devices 212A include without limitations personal computers, smart phones, tablet computers, and so on. In some embodiments, end users 121 access NLP system 202 directly through one or more APIs presented by NLP system 202.

Figure 3 is a block diagram illustrating NLP 202 i more detail of according to an embodiment, input text is received by Language Decoder (LD) 203. LD 203 parses and tags (among other things) the input text as further described below. The output of the LD 203 is referred to here as LD output API 205, and ca be operated on by a variety of downstream software applications or systems as described in this document. The format of LD output 205 is described in further detail below, but it is easily accessible to various machine learning system 104, which can process it to provide input to yet other systems/applications 106. Other systems/applications 106 can also directly use LD output 205. Once the format of LD output 205 is understood, anyone can access desired information from the original input text.

The LD output 205 can also be operated on by embodiments of an LD query language (LDQL) 204. LDQL 204 is described according to various embodiments below as an improved query language designed to take advantage of LD output 205. However LDQL 204 can also operate on the output of any prior NLP system. Also provided in various embodiments is a higher level of APIs (as compared to LD output 205) for providing machine learning systems 104 and other systems/applications 1 6 more intuitive access to LD output 205. Oilier systems/applications 106 can include semantic databases, Free ase™, Wordtiet™, etc.

In general, LD APIs 206 arc relatively easy to use to for other systems seeking to manipulate LD output 205. However, machine learning systems 104 and other systems/applications 106 can also directly write queries using LDQL 204.

Figure 4 is block diagram showing more detail of an NLP system 202 according to an embodiment. The LD 203 includes a word tagger 203A which is further described below. The word tagger 203 includes a tokenizer 203 A 1 , and a sentence divider 203 A2. The word tagger 203A communicates its output to a predicate finder 203 B. The LD 203 also includes a clause divider 203C and an accommodator 203D,

Figure 26 is a diagram summarizing the operation of the LD 203 is an example according to an embodiment. In this example, the text input is the sentence "John is a nice guy and Susanne likes him." Tokenizer and sentence divider (203 A 1 and 203A2) divide the input text into separate words grouped into sentences (a single sentence is shown here as an example). A corrector module 2604 cooperates with the tokenizer 203 A 1 , the sentence divider 203 A2 and the word tagger 203A and applies rules to improve the text input, for example by fixing typos in the input. A named entity recognition module 2602 locates and classifies elements such as names of persons, names of organizations, names of locations, etc.

The word tagger 203 A labels each word with a tag from the proprietary tagset previously described. The predicate finder 203B builds predicates from verb components. ^'Then the clause divider 203C joins words into scraps, groups them into separate clauses, and determines relationships and types of those clauses. Next the accommodator 203D converts scraps within clauses into phrases and determines relationships and types of those phrases. At the end of the process, the accommodator determines types and relationships of each word within each phrase. The output 205 of the accommodator as shown is in a human readable form in contrast to tree-style output of various prior systems. The original sequence of die input: words is preserved and the relationships, types, tags, etc. are simple to view.

Word Tagger Methodology

Contrary to ail prior-art word taggers, present word tagger does not use any of machine learning techttiques and contains only human-written disambiguation rules.

Word taggers rules are described by a language resembling well-known regular expressions, which is comprehensible artd easy to change for human operators. Hence, the process of changes is relatively fast, especially in comparison to the prior-art machine learning based algorithms.

A set of rules is divided into two groups (referred to herein as "exact group" and "inexact group") along with different usages within the tagging algorithm.

Contrary to machine leaning approaches, present word tagger uses its own dictionary to recognize words and assign ail possible l gs to them, it i proves that word taggers using machine learning techniques achieves higher accuracy for tagging known tokens (words) than unknown. The term "known token" means that token appeared in training corpus at least once. Differential in accuracy for known and unknown tokens is about 7-8% for good parsers (see for example http:/ njp.stanford.edu/pnbs/CiCLing20l l -manning-tagging.pdfj. Embodiments of the presented word tagger allow new words to be added directly to the referenced dictionary with all possible tags. For example, "google" can be added with tags related to noun as well as verb. The present word tagger contains rules responsible for resolving that kind of ambiguity, so it can automatically handle that problem.

Word Tagger output

Present word tagger provides unique tagset.

M t important differences between present tagset and prior-art tagsets: - The present: tagset does not exclude particles as a separate tag. The definition of particle is very inconsistent. Therefore, a distinction for adverbs and prepositions is preferred,

- The present tagset provides distinction for prepositions and subordinating conjunctions.

- For determiners, the present tagset provides distinction for adjectival and pronominal function.

- For pronouns, the present tagsei provides distinction for relative and interrogative function.

The process of the wor d tagger

The rapist to the word tagger 203 consists of plain text Tire text can come from any source such as article, documen user generated content and any other source. Referring to Figure 5, a word tagging process according to an embodiment is illustrated. In an embodiment, the input to the word tagger element 103 A is text that is tokenized into sentences and words by preceding elements tokenizer 203 A I and sentence divider 203 A2. A dictionary 502 is accessed to find words with possible tags. All possible tags are assigned to each word (504), The words assigned with ail possible tags are input to a dehomonymizer 506 which resolves ambiguities (i.e. situations in which for one word there is more than one possible matching tag). The dehomonymizer 506 operates using exact rules 508 and inexact rules 510 as further described below. After ambiguities (if any) are resolved, tagged text 512 is output by the word tagger 203. The word tagger output consists of text tokenized into sentences and words, each of which has assigned exactly one tag.

Exact rules 508 and inexact rules 510 are two groups of rules. Each rule examines the context of a word with an ambiguous tag (that is, more than one possible tag). Such context is not limited or restricted; it can address any element of the text, in both directions at the same time. This is a range aspect of the claimed invention describing the facility to acecss or examine any element of the text before or after an ambiguous element, withou t limit

Another aspect of the word tagger 203A is the maimer of expression employed, in order to examine the context of a word, rules permit the creation of patterns and sub-patterns which address words and/or their tags and which can be subject to following operations: eonditiouality (for single element or subpattem) (corresponding to„?" regular expression operator),

* alternatives(for single element or subpattem) (corresponding to J" regular expression operator),

• repetition (for single element or subpattem) (corresponding to and„*" regular expression operator),

^» negation (for single element or sub-pattern} (corresponding to regular expression operator).

This form of rides expands their expressi veness in comparison to prior static look-ups and ranges („next word is ...".„the.re is a ... word in range of 3 words before" etc.) This in effect allows better description of situations in which a given rule should apply.

In an embodiment, the rules are applied separately for each sentence according to following algorithm;

1. Stop algorithm at any point when there is no ambiguity left in current sentence.

2. For all ambiguous words try to apply all exact rules in proper order.

3. Apply inexact rules until any is met. Go to step 2. Methodology of improving the word tagger and resolving exceptions Figure 6 is a flo diagram illustrating a method 600 of improving the word tagger or modifying the word tagger as exceptions occur according to an embodiment. Exceptions include failure of the word tagger to tag at) element of input te t.

At 602 an exception indication is received within the system 202. it is determined which word caused the exception (604). The indicated word is searched for in the dictionary 502 (606). If the word is not in the dictionary, it is added to the dictionary at 608, then check if there is an existing set of tags for the word 612 - if so check if the problem is sol ved 618, if not - create a new set of titles for the new set of tags 6.14 and then check if the problem is solved 618.

If, after checking 606, the word is in th dictionary, it is determined which .rule is responsible for the exception, and the responsible rule is edited or a new rule is added 610. In an embodiment, the editing is performed by a person, in another embodiment, the editing is performed by a machine according to a separate rule-making algorithm.

If the exception is resolved (at 618), the process ends, if the exception is not resolved, the process returns to 604 to examine which word caused the exception.

The above methodology of resolving exceptions to the system may becoine an automated proces.

Clause divider methodology

Referring to Figure 4, the LD 203 includes a predicate finder 203.8 and a clause divider 203C. The output of the word tagger 203 A is received by the predicate finder 203B. Predicate is understood here as a function over arguments, i.e. it consists of a main verb grouped with other verb components like modais, auxiliaries, negations and particles, contrary to traditional approach, where predicate also contains other sentence elements like objects, predicative expressions and adjuncts. Predicate finders 203B cart include any of the known predicate finder methods. The output: of the predicate finder 203B is received by the clause divider 203 C which performs a clause divider methodology according to embodiments.

Embodiments of the clause di v ider 2 3C comprises an algorithm emulating human reasoning behind dividing text into clauses. To this end, a sequential approach is employed rather than applying patterns to an entire sentence. In effect, collections of one or more words (scraps) are sequentially considered (which is similar to what a human actually does while hearing or reading a sentence) and an attempt is .made to assign each scrap to build a clause„on the fly" constantly trying and rejecting different alternatives. This approac simplifies aspects of language decoding, such as handling of nested relative clauses and facilitates the creation of simpler and more accurate rules than those based on patterns.

Output of the clause divider

According to embodiments, the clause divider provides division for clauses. Clauses can possess at the most one predicate (either finite or non-finite like infinitives, participies and gerunds) and all of its arguments. LD provides connections between clauses based on criteria concerning their function towards their superiors. Clauses can be connected directly or through the nodes. Nodes are sentence elements provided to connecting clauses, e.g.. coordinating or subordinating conjunctions. LD provides unique classifications of clauses which correspond to the LD system 202 classification of phrases. Main clauses are distinguished. Other clauses can function as subjects,, objects, complements and attributes, and therefore those can be labeled with proper function name (e.g. attribute clause).

In an embodiment, the clause divider includes at least, the following characteristics:

With reference to one of the current, typical dependency parsers:

1. Embodiments provide implicit division into clauses. In referenced parser, derivation from the relations structure is required. 2. Coordinating nodes (dements connecting two coordinated clauses (e.g. "and", "but:", "or") are distinguished by embodiments. Referenced parser does not provide a distinction between a relation connecting two coordinated clauses and a relation connecting two eoordtnaied phrases or words. In addition, elements connecting a subordinated clause to its superior clause (e.g. "which^'", "after", "when") are distinguished by embodiments. In typical dependency parser the main connection holds between two verbs representing the clauses; hence the equivalent of a subordinate node has to be connected, with a proper verb.

3. hi the clause divider 203C, classification is based on different criteria ( than in the typical dependency parser) and in consequence not every type ^"from one classification is equivalent to a subset of the types of the other classification (although in a number of situations it is),

4. Types of clauses in the LD 202 are equivalent to types of phrases, making the LD system 202 more coherent in comparison to the typical parser. For example, some of referenced parser's relations corresponding to ciause types are common with those for phrases and/or words.

With reference to one of the current, typical constituency parsers:

1. Typical constituency parser provides classification that is based on criteri concerning grammatical construction. This is in sharp contrast to the clause divider 203C, whose criteria is based on a clause's function towards its superior, in effect: every type from one classification can match almost any type from the other, depending on the particular situation.

2. The LD 202 treats nodes connecting clauses (e.g. "and", "but", "which", "after") as separate elements on a ciause level, whereas the referenced parser includes them into the following ciause.

The process of the clause divider

Figure 7 is a diagram showing elements of a clause divider 203C and various tasks performed by the clause divider 203C. Generally, the ciause divider input is text divided into sentences and tokenizcd into words, along with their tags as assigned by word tagger 203 A. Grammatical orraation for each sentence is provided by predicate finder 203B. The tagged word input is received by a scrapper element or module 702. The scrapper 702 groups the tagged word into scraps, which are groups of one or more words that are strictly connected, but do not necessarily from a phrase.

More precisely, a scrap is a maxima! set of words that will certainly form a phrase either by itself or along with some other sentp(s). That is, if two elements are able to form two separate phrases, but this is not evident at the point of creating scraps, they become separate scraps. There is an exception to the foregoing. Specifically, prepositions are joined in scraps with following noun phrases in principle, despite the fact thai they will later be divided into two separate phrases.

At 804, the clause divider 203C makes a preliminary estimate of which scraps are the strongest candidates to introduce a new clause (mat is, which scraps are responsible for dividing the sentence into clauses. The output of the preliminary estimate process 704 is received by a main divider engine 706, which includes a scrap dispatcher and a correctness evaiuator. The scrap dispatcher assigns scraps to appropriate clauses, in an embodiment, mis assignment is based on constant interaction between the scrap dispatcher and the correctness evaiuator. The correctness evaiuator evaluates the decision made by the scrap dispatcher by determining whether the decision generated a correct clause or not. The output of the main divider engine 706 is received by a nodes extraction proces 708. This process extracts nodes as separate elements on a clause level. Relationships between clauses are established by a clause connection detection process 710, Clause types are detected (e.g. subject, object, complement) by a clause type classification process 71.2. The output 714 of the clause divider is text divided into sentences and clauses, which contain words (along with their tags from the word tagger) grouped into scraps. The grouping serves only as an aid in prior and subsequent processes and is not itself a crucial element of the output. The words can also be considered as assigned directly to clauses. Moreover each clause has its proper grammatical information assigned, along with type and connection to its superior clause. Figures 9-14 are diagrams illustrating a process of the clause divider 203C module according to an embodiment Referring to Figure 9, the input to the ciause divider module 203C is the sentence "The man I saw last night became my friend. " with all words tokenized and tagged by the Word Tagger 203 A module and with predicates grouped and distinguished by the Predicate Finder 203B module. Scrapper 702 groups words into scraps. For example, determiners are joined with nouns, hence "the man'^* becomes one scrap (analogous with "my friend"). Referring to Figure 10, the preliminary estimation of dividing scraps 704 begins from the last word of a sentence. Predicate "became" is found and added to the predicate stack. Analogous with next predicate "saw". The introduction of dependent clause is detected and therefore predicate "saw^"" is removed from the top of predicate stack. The first word is reached and the preliminary estimation ends. Referring to Figure 1 1 the main divider engine 706 sequentially tries to assign scraps to clauses. First scrap "the man" is assigned to the first clause of temporary stack by default. Second scrap "1" is assigned to the second clause of temporary stack, because the introduction of dependent ciause was detected between the first two scraps. Scrap "saw" is assigned to the second clause of temporary stack. Referring to Figure 1 the main di vider engine 706 assigns the scrap "last night" to the second clause of temporary stack. Once the scrap "became^"" is reached, the clause from the top of the temporary stack is considered as closed, because "became" is a predicate scrap and the clause already possess a predicate scrap "saw". Hence the ciause is moved to the final stack and "became" is added to the top clause of the temporary stack. The scrap "ray friend'^'' is added to the top clause of the temporary stack. Because all of the scraps were processed, all clauses from temporary stack are moved, to the final stack and the process of assigning scraps ends. Referring to the Figure .13 nodes are extracted. In the considered example there are no scraps that function as nodes, hence the process leaves the clause unaltered. Afterwards the connections of clauses are defected. Because the clause "I saw- last night'^' is interjected right after NP scrap, we consider it dependent ciause and hence determine connection from it to "The man became my friend" clause. Moreover in this situation connection between clause "I saw last night" and phrase "The man" is established. The clause connection detection ends. Referring to Figure 14 the clause "The man became my friend" has no connection to superior clause hence it obtains "main" type. The clause "1 saw last night" i connected to superior clause and to superior phrase as well, thus it obtains "complement" type. The process of the Clause Divider 203C ends and returns output composed of sentence "The man 1 saw last night became my friend" which contains two clauses: 'The man became my Mead" and "I saw last night" along with their types, connections and respective scraps.

Methodology of improving the clause divider 203C and resolving exceptions

By analyzing cases of wrong divisions, connections and types if clauses or adjusting the clause divider 203C into different type of content one can decide whether to:

- add or modify new divider candidates.

- add or modify rules in choosing possible alternative divisions.

- add or modify rules in correctness evaluation.

This provides flexibility and continuous improvement for different types of input context.

Figure S is a flow diagram illustrating method 800 of improving the clause divider or modifying the clause divider as exceptions occur according to an embodiment Exceptions include failure of the clause divider to divide clauses or determine the proper type or connection of the clauses.

At 802 an exception indication is received within the system 202. It is determined if die clause is correctly divided (804). If not, ii is determined if clause dividing scraps were chosen correctly (806). if not, a new candidate is added or the rules responsible for choice are changed (808).

After the changes (808) or in case if it was determined, that the dividing scraps were chosen correctly (806), it is determined if scraps were correctly distributed to clauses (810). If not, scrap dispatcher or correctness evaluator rules are adjusted (814).

After the changes in rules of scrap dispatcher or correctness e valuator (814), or in case if it was earlier determined that either scraps were correctly distributed to clauses (810) or clause is correctly divided (808), it is determined if connections between clauses arc correct (812). If not, the rules governing correction detenmnation are adjusted ( 16).

After adjusting the determination riiies (816) or if the connections between clauses were determined as correct (812), it is determmed if the clause cSassifiaction ts correct (818). if yes, the process ends. Otherwise the clause classification rules are adjusted (820).

The above methodology of resolving exceptions to the system may become an automated proees.

Accomodator methodology

Referring briefly to ^"Figure 4, the output of clause divider 203C is received by an accomodator module 203D. Figure 16 is a block diagram of as accomodator module 2 3D architecture according to an embodiment. In art embodiment,, the accomodator 203.D uses a set of types of phrases (corresponding to simple grammatical types such as predicate, subject, object, complement etc.). The accomodator employs a sequential algorithm, which in one embodiment is based on hand-written rules, but embodiments are not so limited. Maintaining control over rules and having the ability to modify and add rules to the system at will enables the LD 203 to work properly on different kinds of domains (or language contexts) at the same time. This tight control over rides and the adaptability of the rules also provides the ability to handle new domains while avoiding any distortion in the original or prior domain(s). A separate semantic database is referenced to resolve ambiguities with connections (e.g., a semantic n-gram database 1603), in addition, the accomodator 203 D module uses a method for determining connections between phrases (the "it" test described below with reference to Figure 17).

The accomodator 203 D receives words grouped into scraps and further into clauses (along with connections and types), in othe embodiments the accomodator is based on words grouped directly into clauses. A phrase creator module 1602 detects boundaries of every phrase. Then a phrase cooiicction detection module 1604 detects connections bctweco phrases relying on a semantic n-gram database 1603. A phrase type classification module 1606 denotes types for each phrase in every clause in a sentence. Then a word component classification module 1608 assigns components to each word within ail of the phrases. Finally, a word connection detection module 1610 detects connections between each word within a phrase.

The aecomodator 203D output 1612 consists of words grouped into phrases, which are further grouped into clauses. The phrases and words have proper connections and types assigned. In an embodiment the aecomodator 203D output is the final output of the ID system 203, or LD output API 205 as shown in Figure 4, As further described in other parts of this document, the output is useable by many other systems via APIs or other programming tools or interfaces. In an embodiment, types of the phrases are determined after the connections; they are evaluated on the basis of the contained words (along with their tags), types of the scraps from which a phrase comes, and types of scraps from which connected phrases come. Although it has proved efficient and accurate to first connect the phrases and classify them afterward, it is just as viable to do it the other way around.

An. advantage of the aecomodator over prior modules that perform analogous tasks is that the aecomodator 203D method determines connections between phrases and their grammatical functions in way thai is similar to the way in which a human processes language. The aecomodator 203D sequentiall considers separate scraps, and chooses, for a set of syntactic possibilities, the one that semantical!}' makes most sense. In an embodiment this is achieved in part though using a database 1603 containing n-grams (representing these syntactic possibilities) along with the quantity of their occurrence in a large corpus. Ambiguities in interpretation are always reduced to a set of syntactic possibilities consisting of a few elements and are then solved on a semantic basis. The result is simple and intuitive for a human to understand. Thus, a human can readily see and understand the decisions the LD 203 makes and, when appropriate, correct its mistakes by modifying rules so that the system is continually improved. The accomodate? employs an unambiguous criterion for determining connections between phrases, which causes its performance to be reliable and its output to be easily understood by humans. This allows trie output of the LD 203 to be more readily incorporated into other existing language applications and their respective rules. As an example, to determine the connection between certain prepositional phrases, the accomodator employs the so-called "it" test, which is illustrated in Figure 17, An "it" algorithm according to an embodiment is based on an implementation of the "it" test aided by the semantic n-gram database 1603. Referring to the example of Figure 17, consider the sentence (consisting of one clause) "Ϊ recommend coffee with sweetener for your father." To determine if a given clause element is superior, it is -replaced with "if. If the original meaning of the sentence is not preserved, the replaced element is indeed the superior element. Otherwise,, the replaced element is not the superior element. As shown, for this clause, it is determined that "coffee" is a superior phrase to prepositional phrase " with sweetener".

Figures 18-23 are diagrams illustrating a process of the accomodator 2030 module according to an embodiment Referring to Figure 18, the input to the accomodator module 203 D is the sentence "Construction worker bought coffee with milk and cigarettes." Phrases are created by minor manipulation of scraps, such as merging, dividing and changing the type of scraps. Then phrases are connected, in this instance, "construction worker' is first connected to a predicate because of its position. The "construction worker" phrase is added to a stack of phrases. In an embodiment, only NP and P phrases can be added to the stack. Referring to Figure 19, and continuing phrase connection, the predicate "bought" is by default connected to the root. The "construction worker" phrase is removed from the stack because of the appearance of the predicate. Then "coffee" is connected to the predicate because of noun- verbal proximity, and this phrase is put on the stack. In the following operation, two situations are considered. Either ' im" connects the phrase on the right with one from the top of the stack, or "with" connects the phrase on the ight with the predicate. The first solution is better semantically, therefore this one is selected. Next, "milk" is connected to the "with" because it stands immediately after a preposition, and "with milk" is added to the stack. Referring to Figure 20 and continuing with phrase detection, two further situations are considered. "And" links the phrase on the right with one of the phrases from the stack: either "^"coffee and cigarettes^'' or "with railk and cigarettes^''. These two pairs force the following semantic relationships: "bought cigarettes" and "coffee with cigarettes" respectively. The first makes more sense semantieally, therefore it is diosen, and it takes o ver the connection to "bought" from ""coffee" and links it to itself. "Cigarettes" is then connected to the "and" phrase because it stands immediately after a CN (connector) phrase.

Referring to Figure 21 , the phrases are then classified. The "Construction worker" phrase gets SUBJECT for its type because of its position and connection to the predicate. The predicaie phrase type was assigned earlier by the clause divider module 2 3C. The "coffee" phrase gets OBJECT for its type because of its position and relationship to the predicate. The "with" scra type is changed to a PREPOSITION phrase type. Referring to Figure 22, the classification of phrases continues. The "milk" phrase gets ATTRIBUTE for its type because of its relationship to a preposition phrase. "And" gets CONNECTOR for its type because it links oilier phrases. "Cigarettes" gets OBJECT for its type because of its relationship to a particular connector.

The next operation is word categorization. The word "construction" gets a specifier component because it is a noun specifying a phrase core. Referring to Figure 23, word categorization continues. The rest of the words in the sentence are classified as core components because the are single within, corresponding phrases and are not modifying any other phrases. ext, words are connected within phrases. AO specifying words are connected to the core of the respective phrase. Other words in the sentence are not considered here because they are single within their corresponding phrases.

Methodology of improving accomodator and resolving exceptions

Figure 15 is a flow diagram illustrating method 1500 of improving the accomodator or modifying the accomodator as exceptions occur according to an embodiment, Exceptions include wrong detection of phrase boundaries or failure of determining type of phrase or its connection. At: 1502 an exception indication is received within the system 202. It is determined if the phrase is buiii correctly (1504). If not it is dete.OBi.aed if the probiem results from phrase creator (1506). if so, the rules of creating phrases are adjusted ( 1.508). If it was determined that the problem of wrongly built phrase does not result from phrase creator ( 1506), determine if the problem results from scraps (1510). If so, repair scrapper engine ( 1514). If the scrapper engine was repaired (1514), the rules of creating phrases were adjusted ( 1508) or if it was determined that the problem does not result from scraps (1510) or that the phrase was built correctly (1504), it is determined if the connections of the phrases are correct ( 15.12). If no, the connection rules are changed or the semantic n-grara database is edited (1518). After these changes ( 1518) or if the connection between phrases is determined as correct (1512), it is determined if the type of the phrase is correct ( 1520). if so, the process ends. Otherwise the rules for determining type of phrase are adjusted (1522).

^'The above methodology of resol ving exceptions to the system may become an automated proces.

Methodology far improving Language Deco e and receivi g exceptions figure 24 is a flow diagram illustrating method 2400 of improving the Language Decoder or modifying the Language Decoder as exceptions occur according to an embodiment. Exceptions include failure of the Language Decoder on any level: tokenization, sentence division, word tagging, predicate finder, clause divider or aceomodator.

At 2402 an exception indication is received within the system XX. it is determined if the input text is correctly tofcenized (2404). if not, adding or changing existing rules in tokenizer is performed (2408).

After the changes (2408) or in case if it is determined, that text is correctly divided into sentences (2406). If not, adding or changing existing ru s in sentence divider is performed (2412).

After the changes (2412.) or in ease if it is determined, that word tagger worked correctl (2410), if not, word tagger exception resolving process is started (6(H)).

After roe changes (600) or in case if it is determined, that predicate tinder worked correctly (2 14). If not, adding or changing existing rules in predicate finder is performed (2420).

After die changes (2420) or in case if it is determined, that clause divider worked correctly (2418). If not, clause divider exception resolving process is started (800).

After the changes (800) or in case if it is deteraiined, that accornmodator worked correctly (2422). if not, accornmodator exception resolving process is started (1500).

The above methodology of resolving exceptions to the system may become an automated process.

I D output as a three-level framework ofhifhrm tkm interface

The output of the LD module 203 is a three-level framework of storing information (words, phrases and clauses). The three-level structure enables efficient organization of information. Embodiments of a three-level LD output framework capture a maximum amount of the information coded into text while maintaining the simplest possible structure for easy access. The first step was to design efficient framework for storing information and then using only algorithms written by humans (no machine learning techniques and corpus) to decode the information from any given text. The output of the LD thus conveys the logical structure of information stored in text, along with the grammatical structure. The three-level L output structure is compositional and predictable and consist of a relatively small number of elements on each level. Having a minimal set of components and relations speeds up the learning process, simplifies writing extraction rules, and can reduce chances of miscategorization. The output of the LD is effectively an easy-to-access interface standardizing the information coded into natural language.

Description of the three-level framework

A three-level structure consisting of word-level, phrase-level and clause-level stores the information coded in text. The LD 203 is a three-level structure, invariant of the text processed through the system. The text could be short, simple sentences written in proper grammar, short non-proper grammar twitter content or long non-proper grammar reviews. This contrasts with prior systems, in which the parameters are responsibl for attributes and the structure at the same time, which can produce varying results depending on the context of some fragment of text.

I an example from BACKGROUND section: . John likes math.

2. John likes to learn.

3. John likes learning math in the evening.

When using LD parser in each case one gets consistent notation for the object which John likes, in the first example„mafh^<5 is an object, in the second example„to learn" is object clause (its role is the same, but on different level) and in the third example ^""learning math in the evening" is also an object clause. This approach allows to separate grammatical layer from logical layer, so that a single rule can cover many different syntactic structures of the sentence. As a result information extraction rules written on top of the LD are efficient. Fewer rules need to be written to capture more information, and the information is less ambiguous.

Figure 25 is a diagram, of a three-level output structure for LD 203 according to an embodiment, in an embodiment a word is a minimal unit of information. Combinations of words (possibly also one-element) form a reference to some entity, concept, action etc. The word's meaning can only be understood in context of the phrase to which i t belongs and this is described in the LD b a word component. The connection further indicates which other word inside the phrase is directly concerned by the role of the former. 1» an embodiment, a phrase is a group of words which acts as a single unit referring to some entity, action etc. A combination of phrases in a clause can produce a minimal statement that can be part of a more elaborate message. The internal meaning of a clause (neglecting its contest, which is managed by clause level) is determined fay contained phrases and their relations. The role of given phrase in the clause is represented in the LD by the phrase type and the connection indicates to which other phrase this type relates. in an embodiment, a clause is a group of phrases that form a single minimal statement. Its interna! meaning can be analyzed separately (and this is done by the LD on a phrase level), but only its context in combination with other clauses can lead to understanding the text and its meaning. This is caused by the fact that the original, literal meaning of the clause is often significantly altered by its relation towards some other clauses. The LD provides such information about relations between clauses a well as their function in the whole utterance.

The three-level f amework consists of elements on each level and allows for the addition of layers storing new kinds of information. This 3-ie vel structure allows to integrate the decoded information with semantic databases (e.g. fteebase™, wordnet™), ontologies, taxonomies in order to add additional semantic information into existing components on the phrase and/or word level.

The clause level has additional layer of information about the tense (e.g. present simple, past simple) and construction (e.g. positive, negative, question), in embodiment, different layers of information are kepi separate for several reasons. Layers of abstraction can be easily formed by combining only the relevant types of information and ignoring the other (e.g. if one needs only information about phrases division and not their types), it is possible to add other, new layers (e.g. coreference) in addition to the existing ones without distorting the already present information thanks to the separation of layers.

The three level framework can be seen and treated as an interface for information extraction from text. The information can be coded into different layers of the text. For example, in "He owns that red ear" the information about the car is described as "red" on the word level. In "The boy threw that ball" the information about which object was thrown is coded on a phrase level. In "it started to rain after we got home" the circumstances are stored on the clause level. It is also possible to include higher levels on which the information can be stored, e.g. the causation can be seen as pattern of clauses connected with certain nodes ("i^'ifj you eat too much chocolate [then] your stomach will hurt"), therefore the information is coded into higher level than clause. Likewise it is possible to include yet higher levels, building patterns on top of other patterns. The three-level framework of the LD output reflects that natural division of information into separate levels and provide fundaments for creating higher level patterns to capture information store in multiple sentences.

Language Decoder Query I tmg ige I . General description and purpose

LDQL 204 is a declarative, domain-specific querying language for text-structuring NLP systems outputs' information extraction. It is based on first-order predicate calculus and enables users to predefine their own formulas (including recursive definitions).

LDQL 204 queries can express a wide range of actions - from simple listing all subjects to actions as complicated as e.g. finding opinions about people. LDQL 204 queries have SQL-like syntax, which is relatively easy to write and read for human operator, and does not require linguistic knowledge from them. The queries can be also created automatically, which is described below.

Our implementation of LDQL 204 is optimized for Language Decoder, however LDQL 204 can also be implemented for other te t-structuring NLP systems, e.g. Stanford Parser or Illinois SRL.

It is possible (e.g. with the use of LD 2.03 and LDQL 204) to formulate queries in natural language, and then translate them to [.high-level] LDQL 204 queries,

2. LDQL in. comparison to other query languages

There are some prior-art query languages which were used for LP (e.g.. Prolog, SPARQL, IQL). As compared with them, LDQL 204 lias some unique features:

- it was designed for querying NLP parsers' output: it's types and relations reflect 3-levei information structure, regardless of particular parser's output structure,

- it is based on foil first-order predicate calculus,

- users can define their own formulas (including recursive ones) within the language, and use them in queries, or other definitions.

LDQL 204 queries have SQL-like syntax: a SELECT section containing goals of extraction, i optional FROM section for fixing the search range (search by clauses, sentences, or whole text at once), and an optional WHERE section, containing restrictions on extracted objects in the form of (syntactically sugared) first-order formulas, where the variable's range over 3- levei structure of words, phrases and clauses (regardless of particular parser's output structure). E.g. to extract pairs of subject-predicate phrases from given text we could use the following LDQL 204 query;

SELECT P: su AS Actor,

P:prd AS Action FROM clauses

WHERE ¾»b.phrasejype^;;:'sti iect' AND prd. phrase type='predic;ite' AND sub->prd

LDQL's orientation towards formula composition encourages users to building new formulas out of previously defined ones, which we consider crucial in deal ing with natural language's complexity; for example instead of the following pair of queries:

SELECT P:xi>:y WHERE x.phrase Jype- st!bject' A 0 y ,p f ase jype- object' AND x.phrase _...core base- crocodile' AND EXISTS P:z (z,plvase ype- redicate' AND \· v.

AND y- z);

SELECT P:q,P:w WHERE q.phrase Jype- subject' AND w .phrase J pe^~'obj ect'

AND EXISTS P:z

AND q-v.

AND ->2)

We would ratiier abstract the common pattern, for finding "subject->predicate<-objc!ct" connection:

DEFINE subobj con«ectioa(P:s,P;o) AS s.phrasejypc-subjecf

AND EXISTS P.p (p.phrase jype-predicaic'

AND s- p

AND o- ^: !>) SELECT P:x.P;y

WHERE x.phrase core base^~'e:rocodi!e' AND subobj coaneciionC^_^ ) SELECT P:x,P:y

WHERE y.p «se_co«;_basc~1amb' AND su o^c nnection^x. ) which snakes the queries more "granular", and thus easy to maintain (in analogy with subroutines in imperative programming languages).

As far as we're concerned, this is the first use of full first-order query language for unstructured text information extraction. The presence of EXISTS quantifier (in addition to the Boolean connecti ves AND, OR and MOT present in e.g. SQL, Prolog or - in some flavor - SPARQL) with the ability to write recursive formula definitions makes LDQL 204 expressively stronger formalism than e.g. pore SQL, Prolog or even SPARQL (which seems to have some quantification constructs, but no recursive formula definitions). An example benefit of having such an expressive power (also present in e.g. Godel, or - indirectly - Cypher, or any imperative language like Java) is the ability to describe closures of relations: suppose we would like to know whether two phrases are linked by a sequence of one or more "-->" connections. In LDQL 204 we could simply write recursi ve formula:

DEFINE Sinked(P:x,P:y) AS x'™y

AND (x-:

OR EXISTS P:z <?.!=¾ AND z y AND x->z AND NOT z->x AND lirikedfey))}

Which literally reads "x etndy are linked tfx~>y or x~>z for some z, such ih tz is linked wiih y"— notice the circularity (recursion). Because o LDQL's expressive strength, some measures need to be taken to avoid infinite evaluations (the "x~>z AND NOT z->x" and "z!-x AND z!~y" restrictions). 3, Merging LDQL with external systems

LDQL 204 could be implemented to operate on the output of any NLP tcxt-sttiseturrag system (e.g. Stanford Parser), provided that the implementation will contain accessor to attributes that given system offers.

LDQL 204 can be connected to external semantic bases (e.g. Freebase, Wordnet), lexical data bases (e.g. Wordnct), domahi-specifie data bases, ontologies, word banks, taxonomies, etc, in order to support it with more semantic content.

LDQL 204 rules can e hand-written, generated automatically or semi-automatically by either connecting LDQL 204 to sources of semantic content (as above), or by machine learning means fin case of LD's output it is possibie to extract common structures out of annotated text corpora by means of unification heuristics or e.g. Koza's genetic

programming), or both, or generated seroi-autoniatieaiiy by merging any of the methods mentioned.

4. LDQL implementation

The LDQL 204 implementation for LD 203 consists of three modules: parser, optimizer and compiler, as shown on fig, 35.

The parser module 3508 processes text of LDQL script 3502 ( i.e. list of definitions 3504 and queries 3506) in order to produce it's abstract representation.

The optimizer module 3510 takes the parser's output and performs additional annotations to guide compiler.

The compiler module 3512 takes annotated abstract representation and generates a plp/c/sonie-imperative-lang«age output program 3514 which, given valid NLP parser output 1 3 returns the query's results 3516 for that output. Figure 27 is a diagram illustrating a process of information extraction from pi am text according to aa embodiment. This is an example of what is achieved by a software application, (generally an example of a software application 106) written to apply LDQL 204 rules for a specific purpose of extracting information from multiple plain text online reviews. The input text "Tiie chicken in this restaurant is very delicious and the music is awful! 1 want to say the sea view is awesome!" is operated on by LD 203, which outputs (2702) tiie sentences in the form of naked API 205, which as previously described maintains the original word sequence. Previously chosen LDQL rules are applied (2704) to the output of the LD process, and the result is a wo-coiumn table (subject and com lement) 2706 that lists the sea view is awesome, the chicken is very delicious, and the music is awful This tabulated output is easily accessed for further operations.

With using output of Language Decoder it is possible to build language uJklerstandmg applications or language understanding engines, it can be done by applying on top of LD one or more of the following: LDQL rules, raw code (e.g. PHP, Java, C#, .NET, C-H-), machine learning algorithms (supervised or unsupervised).

Usage of Language .Decoder

Language Decoder is the component technology for building application in many areas including (but not limited to);

- Information Extraction

- Sentiment Analysis and Extraction

- ^'Event and Relationship Extraction

- Opinion Mining

- Text Mining

- Document index ing - Text S iiauarizalion curation of information

- Speech processing

- Questioti& Answering

- Text proofing

- Translations

- Natural Language Search/Structured Search

- Query expansion

- Automated scoring (essay scoring)

Language Decoder may be used to process any type of texts incl uding (but not limited to):

- User generated content,

- Social media content, inierob logging (e.g. twitter)

- Reviews (e.g. review sites content, websites, wikipedia, etc.)

- Formal language documents

- Articles and news

- Biomedical free text

~ Research, papers

System built on top of language decoder can represent many domains including (but not limited to);

- Big data

- Customer feedback analytics

- Social listening / sentiment analytics

- Email analysis

~ Text Analytics

~ Search

- Voice Search - Advertising

- Predictive Analytics

- Google Glasses and oilier augmented reality devices

- Voice interface

information extraction exttmpie: Knowledge Browser

Bubble visualization is a concept of showing multi-level structure of knowledge representation (LDQL extracted) in a form of clickable bubbles.

This representation can v ' in size, color and position of bubbles representing frequency and additional properties (tor example, color palette can represent polarity of detected object sentiments).

This multilevel approach allows to browse (e.g. zoom in or zoom out) through summarized knowledge encoded in analysed text, which can help to understand wide context along with more exact properties of extracted data.

This concept does not restrict data to be in specific format or order, pairs (object - opinion), triplets, quadruples (suggestion, aim, suggestion modifier, aim modifier) and man more are suitable here. Also additional categorization can be applied on top of extracted data to improve knowledge integrity and understanding, it can be achieved is multiple ways, starting from applying external lexicons or semantic databases (e.g. Freebase, FrameNet), through human made categorization to even logical correlations.

Bubble visualization concept is used in the information extraction example application described below.

Figures 28-34 illustrate a user interface of a knowledge browser application, in this example, the knowledge browser is for San Francisco restaurants, but any other subject matter is possible. The knowledge browser is an embodiment of an application 106 that can help people to make quickly ieaiii, what they want to know about San Francisco restaurants. By summarizing some reviews about eateries to a very user-friendly form of so-called bubbles, users can browse through multiple food-orie»ted categories and find exactly what people said about particular aspects of their experiences in restaurants. The knowledge browser application illustrates some of the possibilities for applying LDQL 204 rules to user-written reviews processed by the LD 204. The rules used in this example are built to extract pairs of entities (object and related opinion) from user-generated reviews.

With reference to Figure 28, after choosing a particular restaurant {by search input or by clicking on one from a list of popular restaurants), the application displays a set of bubbles grouped into five clusters. The central bubble of each cluster represents a different roeta- eategory. Each meta-eategory has different sets of category bubbles attached to it . This set depends on what people wrote in re views about chosen restaurant.

With reference to Figure 29, after clicking on category bubble, the application displays a set of extracted objects attached to the chosen category {FOOD in this example). Bubbles can differ in i^e and color to visually convey information. In this example, the size of a bubble represents object frequency in processed user reviews. More frequent objects appear on bigger bubbles. The present example shows that people wrote more about meal and dish than course or amount. The color of a bubble can vary from green through orange to red to represent the sum of positi ve and negative opinions about the particular object. In the present example object portion has relatively more negative opinions than object brunch so it is closer to being red in color.

With reference to Figure 30, after clicking on an object bubble, the application shows the set of opinions about the chosen object (portion in thi example). Bubbles can differ in size and color here as well. Here, the size of a bubble or radius represents opinion about the particular object frequency in processed user reviews. In this example mall portion appeared more frequently in reviews than good portion. The color of the opinion bubble is constrained to three values: red, green and grey. Red opinions are meant to be negative, green positive and grey are treated as neutral. In this example opinions about size of a portion are rather negative (small, tiny, extremely small) but opinions about general quality of portion are certainly positive (good, perfect, healthy).

Referring to Figare 31, doubie clicking on an opimoa bubble shows a general vie of every object, which was connected to the chosen opinion. This view gives a better insight into what generally, despite categorization, was related to the chosen opinion (good in this example). For example, the user can look up what was good in the selected restaurant. Bubbles showed in this screen have the same properties (color and size) a in previous steps.

Referring to Figure 32, a similar view can be obtained by clicking on a central category bubble on the screen, of Figure 28, This displays a graphic of a set of opinions about an entire category (FOOD in this example), which .means that ail of those opinion bubbles are related to some objects categorized as FOOD.

Referring to Figures 33 and 34_» the application provides an option for comparing two restaurants. By placing two instances of bubbles next to each other, the user can browse through categories and objects in one instance (representing one restaurant) and simultaneously choices are transferred to the second instance showing differences.

Bubble size and bubble color are just examples of visual properties that can be used to convey the desired information. Any other visual characteristic that can be varied in a similar manner would be just as appropriate.

The various functions or processes disclosed herein may be described as data and or instructions embodied in various computer-readable media, in terms of their behavioral, register transfer, iogie component, transistor, layout geometries, and/or other characteristics. Computer-readable media in which such formatted data and/or instructions may be embodied include, but are not. limited to, non-volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media) and carrier waves that may be used to transfer such formatted data and/or instructions through wireless, optical, or wired signaling media or any combination thereof. Examples of transfers of such formatted data and/or instructions by carrier waves include, but are not limited to, transfers (uploads, downloads, e-mail, etc.) over the internet and/or other computer networks via one or more data transfer protocols (e.g., HTTP, FTP, SMTP, etc.). When received within a computer system via one or more computer-readable media, such data and/or instruction-based expressions of components and/or processes under the system described may be processed by a processing entity (e.g., one or more processors) within the computer system in conjunction with execution of one or more other computer programs.

Aspects of the systems and methods described herein may be implemented as functionality programmed into any of a variety of circuitry, including programmable logic devices (PLDs), such as field programmable gate arrays (FPGAs), programmable awa logic (PAL) devices, electrically programmable logic and memory devices and standard cell-based devices, as well as application specific integrated circuits (ASICs). Some other possibilities for implementing aspects of the system include: microcontrollers with memory (such as electronically erasable programmable read only memory (EEPROM)), embedded microprocessors, firmware, software, etc. Furthermore, aspects of the system may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types. Of course the underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor (MOSFE^'f) technologies like complementary metal-oxide semiconductor (CMOS), bipolar technologies like emitter-coupled logic (B L), polymer technologies (e.g., silicon-conjugated polymer and metal-conjugated polymer-metal structures), mixed analog and digital, etc.

Unless the context clearly requires otherwise, throughout the description and the claims, the words "comprise," "comprising;' and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of 'including, but not limited to." Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words "herein,^'' "hereunder," ^'"above," "below," and words of similar import refer to this application as a whole and not to any particular portions of this application. When, the word "or" is used in reference to a list of two or more items, that word covers ail of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the hst.

Tile above description of illustrated embodirrients of the systems and methods is not intended to be exhaustive or to limit the systems and methods to the precise forms disclosed. While specific embodiments of, and examples for, the systems components and methods are described herein for illustrative purposes, various equivalent modifications are possibSe within the scope of the systems, components and methods, as those skilled in the relevant art will recognize. The teachings of the systems and methods provided herein can be applied to other processing systems and methods, not only for the systems and methods described above.

The elements and acts of the various embodiments described above can be combined to provide further embodiments. These and other changes can be made to the systems and methods in light of the above detailed description.

In general, in the following claims, the terms used should not be construed to limit the systems and methods to the specific embodiments disclosed in the specification and the claims, but should be construed to include all processing systems that operate under the claims. Accordingly, the systems and methods are not limited b the disclosure, but instead the scope of the systems and methods is to be determined entirely by the claims.

While certain aspects of the systems and methods are presented below in certain claim forms, the in ventors contemplate the various aspects of the sy stems and methods in any number of claim forms. For example, while only one aspect of the systems and methods may be recited as embodied in machine-readable medium, other aspects may likewise be embodied in machine-readable medium. Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the systems and methods.

Claims

What is claimed is:

1. A system for natural language processing comprising:

a processor configured to receive input comprising unstructured text;

the processor further configured to execute a word tagger module that receives tokenized words and assigns tags to the tokemzed words using a reference dictionary of words with possible tags;

applying rules to resolve any ambiguities in the tags;

if an exception is generated the word tagger module, determining a rule responsible for the exception;

editing the responsible rule; and

executing the word tagger module using the edited rule,

2. The system of claim 1 , wherein d e processor is further configured to:

execute a clause divider module that divides output of the word tagger module into clauses; determine if a clause is incorrectly divided; and

determine a rule responsible for the incorrect division;

edit the responsible rule; and

execute the clause divider using the edited rule.

3. The system of claim 2, wherein the output of the clause di vider comprises clauses with classification, relation and grammatical information.

4. The system of claim 2, wherein the processor is further configured to:

execute an accommodator process that recei es output, of the clause divider module and, creates phrases front the input;

detects connections between the phrases;

classifies words; and

detects connections between words.

5. The system of claim 4, wherein the accommodator module output comprises a multilevel structure comprising at least one of a word level, a clause level and a phrase level.

6. The system of claim 5, further comprising a server hosting an application

programming interface comprising a rules-based query language (QL) that is applicable to form queries to extract information from the outpu of the accommodator module.

7. The system of claim 6, wherein the QL employs first order formulas for querying the output of the accommodator module.

8, The system of claim 5, wherein the accommodator performs an "it" test to determine connections between phrases.

The system of claim 1 , wherein the rules comprise exact rules and inexact rules.

10. The system of claim 5, whe rein the accommodator module process input sequentially.

11 . The system of claim 3, wherein the clause divider processes input from different contexts differently.

12. The system, of cl aim 3, wherein the clause divider comprises a correctness evaiuator that continually assesses the correctness of the clause divider process.

13. The system of claim 3, further comprising assigning types of clauses, and wherein types of clauses are equivalent to types of phrases.

14. The system of claim 1 , wherein resolving ambiguities involves semantic n-gram database.

1.5. The system of claim 4, wherein the accommodator module sequentially considers scraps and chooses scraps that make sense semantical!}¹.

16. A. computer-implemented method for processing text, the method comprising:

receiving unstructured text;

decoding the unstructured text, comprising,

tagging words using exact and inexact rules;

dividing the tagged words into clauses using a sequential algorithm

performing an accommodator operation;

monitoring the rest processing for error, and if errors arc found modifying one or more of rules for tagging, rules for dividing, and rules for performing the accommodator operation; and

immediately proceeding with the text processing using the modified rules.

17. The method of claim 16, further comprising generating an output of the

accottuttodator operation comprising a multi-level structure comprising at least one of a word level, a clause level and a phrase level.

The method of claim 17, wherein the word level comprises connections between

19. The method of claim ! 7, wherein the clause level comprises connection between clauses, connections between clauses and phrases, and connections between clauses and words.

20. The method of claim .17, wherein the phrase level comprises collecti ns between phrases, and connections between phrases and. words.

21. The method of claim 20, further comprising presenting the output of the

aecottunodator operation graphically with the received text in its original order and marked show any connections on the word level, the clause level, and the phrase level.

22, The method of claim 21 further querying the output of the accororaodator operation to extract predetermined information.

23. The method of claim 22, wherein querying the output comprises selecting the predetermined information and selecting a manner of displaying a response to the quer ¹ including the predetermined information.