Single graphical approach for representing and merging...

Details Single graphical approach for representing and merging... Single graphical approach for representing and merging...

1999-09-20

2003-12-02

Vu, Kim (Department: 2172)

Data processing: database and file management or data structures

Database design

Data structure types

C345S215000, C345S215000

Reexamination Certificate

active

06658404

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a method and system for graphically representing and merging Boolean logic and mathematical relationship operators. More specifically, for generating search queries.
2. Description of the Prior Art
Whether on paper, CD-ROM, or the Internet, information has been organized into collections known as databases. On paper these databases, though organized into collections, are flowing text and therefore non-structured. In electronic media databases are either structured, non-structured, or hybrid form, where the hybrid form is a database having both structured and non-structured components.
Structured databases are organized into records, each record having discrete fields of information, e.g., an employee data record containing fields such as employee name, address, and salary. In a non-structured database, each item may correspond to an article or legal opinion, which is in free form text. Hybrid format databases include records that contain free form text as well as explicit fields. For example, a database designed to store journal information would include fields such as the date of the article, the name of the authors, and the free flowing article text stored in a memo field.
With the advent of collections of paper based non-structured data, tools were developed to find information because it was too hard to search for something by scanning the information by eye. Similarly, in an electronic collection, it takes too long to scan the information from the beginning to the end of the database. The table of contents and index within books are familiar tools for quickly locating information. The Dewey Decimal System is also a familiar tool for locating information across vast collections of paper within libraries. With the advent of electronic information, it was natural to extend the concepts of a table of contents to electronic outlines or trees with links for non-structured databases or a “TOC” field within a structured database. A book's index was extended to ‘indexing’ the words of both structured and non-structured databases wherein a table of words was created electronically by scanning the words in the collection. Within this table was the location of the word. In other words, it contained not only the word found but, within what electronic document and the count of where it was with respect to the beginning of the document. Similarly, “indexing” words contained within the fields of structured databases lead to high speed searches of information because the index contained the record number where the word was found. Of course as is the case with a paper collection of information, scanning the information can be electronically modeled by bruit force “matching” searches of databases without the use of an index.
The index of a book however was not limited to single word locations but combinations of words that constituted a concept. For example, a book on birds could contain an index entry on the “Long Necked Geese” and “Canadian Geese”. With a simple single word electronic search, searching for “Geese” alone would yield both entries when the user desires only one.
With structured databases the need existed to retrieve records based on counts and amounts. For example, the searcher would desire to see all patrons who owed more then $10.00 and items that had been purchased in quantities less than or equal to 10.
As a result, electronic search engines borrowed from mathematics and Boolean logic to yield syntactical representations for complex searches. The original syntax included left and right parenthesis, and, or, not, quotations, greater than, less than, equals and not equals. In addition, the arrangements of these equational elements dictate the meanings and consequently effect the results. For example, (“Long” AND “Necked” AND “Geese”) satisfied the non-structured example above while (OwedField>$10.00 or QuantityField<=10) satisfies the structured database example. Please note that the “OR” in this equational expression is opposite of the “AND” used in the sentence. This syntax is too complicated for the general untrained user. Even the proper placement of parenthesis had significant impact on the result. For example, (“Dog” AND “Cat”) OR “Mouse” had a much different result than “Dog” AND (“Cat” OR “Mouse”). Just the concept of ‘OR’ vs. ‘AND’ is complex for the general software user to understand. The widespread use of computers to access information by all levels of users and the sheer volume of information that is accessible has placed the burden of simplicity on the technology instead of on the level of sophistication of the user.
In an effort to minimize the complexity in forming particularized queries, different syntactical representations of queries have been developed. The Structured Query Language (SQL) was developed as a standard syntax for searches, for example. The theory is that standardization limits what the user has to learn as they move from software application to application. In addition, it moved the syntax closer to sentence structure and hid the use of indexes from the user. For example, “Select LastName from Clients Where (OwedField>$10.00 OR QuantityField<=10);” performs the same search (i.e. query) as the above example. Please note that though the syntax is different the Boolean and mathematical elements in the expression section of the SQL statement are still present. Obviously, even in this simplest of expressions, it is well beyond the masses.
As a consequence query expression builders have been developed. These expression builders act as a user interface that generates the Boolean and mathematical expressions that in turn defines the search. One example of an expression builder is a natural language query engine, U.S. Pat. No. 5,175,814 to Anick et al, which is incorporated by reference for its teachings. To generate a natural language query, a user forms a basic sentence that describes what they are looking for. A natural language query of the prior example would be something like, “Show me all of the client last names where what they owe is greater than $10 and the quantity of items purchased is less than or equal to 10.” This sentence is then translated into a mathematical syntax query, SQL Syntax, or any other search/query syntax. The resultant syntactical output from natural language query generator is then used to locate records in the database meeting the desired criteria. The user may not even see the actual Boolean and evaluation query expression that is used to search the database or, if shown, understand it. As a consequence, the sentence they type for the natural language query may be returning results that the user did not intend to find. The user has limited mechanisms to corroborate that the sentence they typed is providing an expression syntax that matches. This sentence based representation, though rich in “grammar” lacks underlying structure that adds meaning to the interpretation.
To resolve this problem Anick et al supplied a secondary “tile” based interface between the natural language query and the search expression syntax. At the user's request, “tiles” are presented to the user representing each of the Boolean terms in the expression query syntax generated from the natural language query. The user may then manipulate the tiles to modify their initial Natural Language query and in turn the output query expression. While graphic in nature, it is a “flow charting” approach to representing the logic as is evidenced by the need to include logical relationships such as greater than, less than, equal, not equal, and partial matches in text form within the “tile” or flow chart block. This flow diagram representation, though possessing “structure”, lacks underlying “grammar” that adds “meaning” to the interpretation. It provides little or no intuitive aid to understanding the underlying Boolean or evaluative relationships between the items used to formulate the search query.
Strong structure and lack of grammar

Affiliated with

Also associated with

Rating

Single graphical approach for representing and merging... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Single graphical approach for representing and merging..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Single graphical approach for representing and merging... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3125150