CA2079285A1 - Information access apparatus and methods - Google Patents
Information access apparatus and methodsInfo
- Publication number
- CA2079285A1 CA2079285A1 CA002079285A CA2079285A CA2079285A1 CA 2079285 A1 CA2079285 A1 CA 2079285A1 CA 002079285 A CA002079285 A CA 002079285A CA 2079285 A CA2079285 A CA 2079285A CA 2079285 A1 CA2079285 A1 CA 2079285A1
- Authority
- CA
- Canada
- Prior art keywords
- knowledge base
- entities
- query
- description
- compositional
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24564—Applying rules; Deductive queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/289—Object oriented databases
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99934—Query formulation, input preparation, or translation
Abstract
Information Access Apparatus and Methods Abstract Apparatus and methods for integrating a knowledge base management system with a data base system. The knowledge base management system employs compositional descriptions which describe information in terms of concepts. A translation component of the apparatus translates compositional descriptions into data base queries, so that information matching a compositional description may be retrieved from the data base. The translation component further permits display of the retrieved data in terms of the compositional description. The returned information can be automatically integrated into the knowledge base, either item by item or on the basis of the compositional description which was used to return the information.
Description
., 20~8~
Information Access Apparatus ~nd Methods Background of the Invention Field of the Invenffon The invention relates to information systems in which data is stored and accessed by 5 means of query language statements. Examples of such informa~ion systems include conventional database management systems of various sorts, including relational databases, "object-oriented" databases, computer file systems in which data is stored and retrieved, and artificial intelligence systems with explicitly stored knowledge bases that hold information for use by a human user, expert system, or other artificial 10 intelligence algorithms.
Description oî the Prior Art Information systems that store large amounts of patterned data are widespread invirtually all areas of business. These range from simple file systems to complexdatabase management systems that store data as "records," usually in secondary 15 memory, such as magnetic tape, magnetic disks, or optical disks. A general introduction to modern database management systems can be found in Ramez Elmasri and Shamkant B. Navathe, Fundamentals of Database Sys~ems. Redwood City, CA: The Benjamin Cummings Publishing Company, Inc., 1989. Such systems usually have--at least implicitly--a fixed pattern for each type of entry. Records, for 20 example, would have fixed sets of fields, and each individual record would have the same set of fields as all others in its category. Each field in a record may contain particular bits representing data. The data is usually either numbers or strings.
Standard data management systems require a relatively small set of record forrnats to be specified in advance; these together are called the "schema." In general, the2s schema, once chosen, cannot be easily modified.
Another important aspect of information systems of the above sort is that there is usually some way to retrieve data out of the information system. While some are crude or stylized or strictly form-based, and some are very complex formal languages, we refer to instances of the set of querying and retrieval mechanisms as ..
. , ~
- ,,, ~ I, :
. .
. , 2 2 ~ r3 "query languages". Users (or sometimes computer programs) form 4ueries in these query languages, "evaluate" thern on the information base, and have returned to them answers to their queries. We refer to the form of these answers as "tables", since that is representative of a large class of data management systems (e,g., relational s database management systems), although not every information system returns its answer in the literal form of tables.
A typical interaction with information systems has a human user constructing a query in the query language, evaluating it against the information base, and having a table or set of tables returned in textual form on a screen, on a 10 hard copy, or in a computer file. The user may look at the tables and then construct a new query that may possibly incorporate parts or all of the prior query (or several prior queries). Database management systems have been constructed to optimize certain types of retrievals, and relational databases have generally been designed to respond to queries in a language called "SQL", which has become a de facto standard 1S in the industry. While providing basic query-answering competence, this language has certain important limitations in the way in which it allows the user to conceptualize the information in the database. It forces the user to interact with the data in a very rigid pattern (see below).
Another problem with most conventional information systems is that 20 they do not store queries in a conceptual ("intensional," as opposed to "extensional") form, so that they can be compared, explored, or reused without complete re-evaluation. Once a query on a very large database has been evaluated, it could be very convenient and time-saving to save the results of the query and the query itself in a form that can be reused without computing it again. Even the notion of "views", 2s which are a mechanisms that allow a user to conceptualize a database in some other form than that given in the schema, is restrictive. Views must themselves be in the same strict tabular form as standard database tables, and the operations which may be perforrned on them are limited:
. Views cannot be compared to one another;
30 . The only way in which an inference can be done on a view is by doing it on all rows of the underlying tables;
. Views cannot be directly updated. Instead, any new tuples for a view must be inserted into the tables upon which the view is based;
Information Access Apparatus ~nd Methods Background of the Invention Field of the Invenffon The invention relates to information systems in which data is stored and accessed by 5 means of query language statements. Examples of such informa~ion systems include conventional database management systems of various sorts, including relational databases, "object-oriented" databases, computer file systems in which data is stored and retrieved, and artificial intelligence systems with explicitly stored knowledge bases that hold information for use by a human user, expert system, or other artificial 10 intelligence algorithms.
Description oî the Prior Art Information systems that store large amounts of patterned data are widespread invirtually all areas of business. These range from simple file systems to complexdatabase management systems that store data as "records," usually in secondary 15 memory, such as magnetic tape, magnetic disks, or optical disks. A general introduction to modern database management systems can be found in Ramez Elmasri and Shamkant B. Navathe, Fundamentals of Database Sys~ems. Redwood City, CA: The Benjamin Cummings Publishing Company, Inc., 1989. Such systems usually have--at least implicitly--a fixed pattern for each type of entry. Records, for 20 example, would have fixed sets of fields, and each individual record would have the same set of fields as all others in its category. Each field in a record may contain particular bits representing data. The data is usually either numbers or strings.
Standard data management systems require a relatively small set of record forrnats to be specified in advance; these together are called the "schema." In general, the2s schema, once chosen, cannot be easily modified.
Another important aspect of information systems of the above sort is that there is usually some way to retrieve data out of the information system. While some are crude or stylized or strictly form-based, and some are very complex formal languages, we refer to instances of the set of querying and retrieval mechanisms as ..
. , ~
- ,,, ~ I, :
. .
. , 2 2 ~ r3 "query languages". Users (or sometimes computer programs) form 4ueries in these query languages, "evaluate" thern on the information base, and have returned to them answers to their queries. We refer to the form of these answers as "tables", since that is representative of a large class of data management systems (e,g., relational s database management systems), although not every information system returns its answer in the literal form of tables.
A typical interaction with information systems has a human user constructing a query in the query language, evaluating it against the information base, and having a table or set of tables returned in textual form on a screen, on a 10 hard copy, or in a computer file. The user may look at the tables and then construct a new query that may possibly incorporate parts or all of the prior query (or several prior queries). Database management systems have been constructed to optimize certain types of retrievals, and relational databases have generally been designed to respond to queries in a language called "SQL", which has become a de facto standard 1S in the industry. While providing basic query-answering competence, this language has certain important limitations in the way in which it allows the user to conceptualize the information in the database. It forces the user to interact with the data in a very rigid pattern (see below).
Another problem with most conventional information systems is that 20 they do not store queries in a conceptual ("intensional," as opposed to "extensional") form, so that they can be compared, explored, or reused without complete re-evaluation. Once a query on a very large database has been evaluated, it could be very convenient and time-saving to save the results of the query and the query itself in a form that can be reused without computing it again. Even the notion of "views", 2s which are a mechanisms that allow a user to conceptualize a database in some other form than that given in the schema, is restrictive. Views must themselves be in the same strict tabular form as standard database tables, and the operations which may be perforrned on them are limited:
. Views cannot be compared to one another;
30 . The only way in which an inference can be done on a view is by doing it on all rows of the underlying tables;
. Views cannot be directly updated. Instead, any new tuples for a view must be inserted into the tables upon which the view is based;
-3- ~7~
. Views (and the relational algebra on which they are based) do a poor job of handling partial or incomplete information.
Further, while adding homogeneous information to a standard database is easy, it is difficult or impossible to add new heterogeneous pieces of information s (i.e., descriptions of objects that are exceptional or unorthodox in some way).
There have been recent attempts to solve the above problems of data bases by integrating the knowledge bases employed by some types of artificial intelligence with data bases. For a general introduction to knowledge bases and their structure, see Ronald J. Brachman, "The Basics of Knowledge Representation and 10 Reasoning", AT&T Technical Journal, Vol. 67, Mo. 1, pp. 7-24. Prior attempts to use knowledge-base processing systems as interfaces to information managemen~
systerns include IntelliCorp's KEEConnection system ("Bridging the Information Gap", in A Review of Products, Serv~ces, and Research, AAAI-87), which allows a user to bring data from a database into a KEE knowledge base. SDM (M. M.
15 Hammer and D. J. McLeod, "Database Description with SDM: A Semantic Database Model", ACM Transactions on Database Systems 6, No. 3, Sept. 1981) uses a hierarchical "semantic data model" to allow more object-oriented viewing of a relational database. Neither of these systems uses a formal compositional description language~ which is central to the success of the present invention, nor do 20 they perform the classification inference that allows ~he present invention to generate correct queries automatically for composite descriptions. "Natural language access to database" systems attempt to allow the user to express queries in natural languages like English. These systems further do not allow the results of queries to be automatically stored and organized in the knowledge base. The CODE-BASE
2s system, described in Peter G. Selfridge, "Knowledge Representation Support for a Soft~vare Information System", Proceedings of the Seventh ~EEE Conference on Al Applications, Miami Beach, FL, February, 1991, pp. 134-140, is based on the samedescription logic as the present invention's preferred embodiment, but does not take advantage of the classification inference to allow automatic generation of queries 30 from composite descriptions. In sum, all prior systems that attempt to connect databases and knowledge base processing systems either rely on the user exclusively to form all queries (or mappings to the database for all forms in the knowledge base) by hand, or do not take advantage of a compositional description language to allow the storing, organizing, and automatic generation of database queries. It is thus an 3s object of the apparatus and methods disclosed herein is to overcome these problems of the prior systems.
. Views (and the relational algebra on which they are based) do a poor job of handling partial or incomplete information.
Further, while adding homogeneous information to a standard database is easy, it is difficult or impossible to add new heterogeneous pieces of information s (i.e., descriptions of objects that are exceptional or unorthodox in some way).
There have been recent attempts to solve the above problems of data bases by integrating the knowledge bases employed by some types of artificial intelligence with data bases. For a general introduction to knowledge bases and their structure, see Ronald J. Brachman, "The Basics of Knowledge Representation and 10 Reasoning", AT&T Technical Journal, Vol. 67, Mo. 1, pp. 7-24. Prior attempts to use knowledge-base processing systems as interfaces to information managemen~
systerns include IntelliCorp's KEEConnection system ("Bridging the Information Gap", in A Review of Products, Serv~ces, and Research, AAAI-87), which allows a user to bring data from a database into a KEE knowledge base. SDM (M. M.
15 Hammer and D. J. McLeod, "Database Description with SDM: A Semantic Database Model", ACM Transactions on Database Systems 6, No. 3, Sept. 1981) uses a hierarchical "semantic data model" to allow more object-oriented viewing of a relational database. Neither of these systems uses a formal compositional description language~ which is central to the success of the present invention, nor do 20 they perform the classification inference that allows ~he present invention to generate correct queries automatically for composite descriptions. "Natural language access to database" systems attempt to allow the user to express queries in natural languages like English. These systems further do not allow the results of queries to be automatically stored and organized in the knowledge base. The CODE-BASE
2s system, described in Peter G. Selfridge, "Knowledge Representation Support for a Soft~vare Information System", Proceedings of the Seventh ~EEE Conference on Al Applications, Miami Beach, FL, February, 1991, pp. 134-140, is based on the samedescription logic as the present invention's preferred embodiment, but does not take advantage of the classification inference to allow automatic generation of queries 30 from composite descriptions. In sum, all prior systems that attempt to connect databases and knowledge base processing systems either rely on the user exclusively to form all queries (or mappings to the database for all forms in the knowledge base) by hand, or do not take advantage of a compositional description language to allow the storing, organizing, and automatic generation of database queries. It is thus an 3s object of the apparatus and methods disclosed herein is to overcome these problems of the prior systems.
4- 2 ~
Summary o~ the Invention The above object is achieved by apparatus for accessing a data base of entities accessible by a query language. The apparatus includes . means for making a class description that defines a class to which one or more of S the entities potentially belong;
rneans for translating the class description into one or more statements in the query language which locate entities belonging to the class defined by the classdescription; and o means for employing these statements to locate in the data base the entities lo belonging to the class.
In other aspects, the means for translating provides class descriptions which include the entities located in the data base, the means for making a class description includes means for storing the located entities and means for incorporating the entities into an organization of classes, and the means for making 15 a class description includes means for adding a new class description to the organization of classes.
It is thus an object of the invention to provide improved access to information.
It is a further object of the invention to provide data base systems in 20 which queries can be made in conceptual terms.
It is an additional object of the invention to provide data base systems in which information provided by the data base system may be dealt with in conceptual terms.
These and other objects and advantages of the invention will be apparent 2s to those of ordinary skill in the art after perusing the Detailed Description and Drawing, wherein:
Brief Desc~ption of the Drawin~
Figure 1 illustrates the overall structure of the invention; it includes the principal components of each of the mechanisms in the embodiment;
Figure 2 illustrates the substructures of the two information-storing components of the system (the description system knowledge base and the information system database) in the preferred embodiment;
- . . .
- .
; .-": :
, .
s. 2 ~
Figure 3 illustrates a concrete example of the language forms used within the description system as well the form of statements of information in the information system schema and database;
Figure 4 shows the processing necessary to take composite descriptions 5 in the description language and produce queries in the query language; this illustrates one of the primary mechanisms of the present invention (Algorithm 1);
Figure S gives examples of the inputs and outputs of the various components in Figure 4;
Figures 6 and 7 present the pseudo-code for Algorithm 1;
lo Figure 8 shows the processing to be applied to tables returned from the information system and converted into the descriptions of individual objects in the description language (Algorithm 2);
Figure 9 gives pseudo-code and an example of the operation of Algorithm 2; and ls Figure 10 shows Algorithm 3, which takes the individual descriptions provided by Algorithm 2 and installs them in the description system's knowledge base, and also gives the pseudo-code for Algorithm 3.
Detailed Description The following Detailed Description begins with an overview of the invention and 20 then proceeds to a detailed description of a preferred embodiment thereof.
O~er~iew of the Invention: FIG 1 Figure 1 shows an artificial intelligence system 101, which involves a database of facts and which is implemented using the present invention. The major components are the following:
2s o Description Language (DL) 103 is the set of syntactic rules for forrning descriptions that the user will use to describe classes of interest in the data;
. Knowledge Base Management System (KBMS) 105 accepts descriptions in Language 103 and organiæs those descriptions and stores them in an organized structure in a knowledge base, 107; KBMS 105 also answers the user's queries 30 when posed in DL 101;
' ~
. : ' ' , . ~
' ;~ , 2 ~ ~
Summary o~ the Invention The above object is achieved by apparatus for accessing a data base of entities accessible by a query language. The apparatus includes . means for making a class description that defines a class to which one or more of S the entities potentially belong;
rneans for translating the class description into one or more statements in the query language which locate entities belonging to the class defined by the classdescription; and o means for employing these statements to locate in the data base the entities lo belonging to the class.
In other aspects, the means for translating provides class descriptions which include the entities located in the data base, the means for making a class description includes means for storing the located entities and means for incorporating the entities into an organization of classes, and the means for making 15 a class description includes means for adding a new class description to the organization of classes.
It is thus an object of the invention to provide improved access to information.
It is a further object of the invention to provide data base systems in 20 which queries can be made in conceptual terms.
It is an additional object of the invention to provide data base systems in which information provided by the data base system may be dealt with in conceptual terms.
These and other objects and advantages of the invention will be apparent 2s to those of ordinary skill in the art after perusing the Detailed Description and Drawing, wherein:
Brief Desc~ption of the Drawin~
Figure 1 illustrates the overall structure of the invention; it includes the principal components of each of the mechanisms in the embodiment;
Figure 2 illustrates the substructures of the two information-storing components of the system (the description system knowledge base and the information system database) in the preferred embodiment;
- . . .
- .
; .-": :
, .
s. 2 ~
Figure 3 illustrates a concrete example of the language forms used within the description system as well the form of statements of information in the information system schema and database;
Figure 4 shows the processing necessary to take composite descriptions 5 in the description language and produce queries in the query language; this illustrates one of the primary mechanisms of the present invention (Algorithm 1);
Figure S gives examples of the inputs and outputs of the various components in Figure 4;
Figures 6 and 7 present the pseudo-code for Algorithm 1;
lo Figure 8 shows the processing to be applied to tables returned from the information system and converted into the descriptions of individual objects in the description language (Algorithm 2);
Figure 9 gives pseudo-code and an example of the operation of Algorithm 2; and ls Figure 10 shows Algorithm 3, which takes the individual descriptions provided by Algorithm 2 and installs them in the description system's knowledge base, and also gives the pseudo-code for Algorithm 3.
Detailed Description The following Detailed Description begins with an overview of the invention and 20 then proceeds to a detailed description of a preferred embodiment thereof.
O~er~iew of the Invention: FIG 1 Figure 1 shows an artificial intelligence system 101, which involves a database of facts and which is implemented using the present invention. The major components are the following:
2s o Description Language (DL) 103 is the set of syntactic rules for forrning descriptions that the user will use to describe classes of interest in the data;
. Knowledge Base Management System (KBMS) 105 accepts descriptions in Language 103 and organiæs those descriptions and stores them in an organized structure in a knowledge base, 107; KBMS 105 also answers the user's queries 30 when posed in DL 101;
' ~
. : ' ' , . ~
' ;~ , 2 ~ ~
Database Management System (DBMS) 109 allows a user access to data stored in a potentially large databa~se 111;
Query translator 113 translates a user's description in DL 101 into the query language (QL) 115, accepted by DBMS 109; and s . Data translator 117 translates data returned from DBMS 109 into DL 101, and presents that transforrned data either to the user or to KBMS 105.
The operation of system 101 is as follows: The user presents a query to be answered 119. This query is created by means of description language 101, which specifies the syntactic conventions by which the query should be constructed.
10 The query forrnulated in DL 101 (121) is passed to query translator 113, which translates it into QL 115, which is accepted by the database management system 109.
DBMS 109 processes the query with respect to the data in its stored database 111, and returns the answer in the form of tables 123 to the user.
It is also possible for the user to receiYe the result of the query expressed 15 in DL 101, by having the result of the query passed through data translator 117. This yields DL 101 descriptions of the appropriate individuals in the database (125/126).
The results 126 of the query in the forrn produced by translator 117 can also be passed directly to the KBMS 105 and stored for future reference (using KBMS integration process 127). Finally, the user can add a new description 129 20 expressed in DL 101 directly to the knowledge base 107. Once expressed in DL 101, this new description 129 can be added to the organized descriptions resident in knowledge base 107 by means of incremental description integration process 131.
The added effect of this integration is that all individual objects previously introduced into knowledge base 107 are automatically tested to see if they satisfy the 25 new description, and any that succeed are classified as belonging to that new description 129.
At any point, KBMS 105 can accept a user description (131) as a query to be answered directly by the KBMS, based on the inforrnation that has been stored in knowledge base 107. The answer to such a query 133 thus takes into account any 30 previous descriptions entered into the KB 107 as well as all data entered there from the database 111 via translator 117.
.
,. ..
: , . , ,~ .
:. ~ , ; .
" :
Query translator 113 translates a user's description in DL 101 into the query language (QL) 115, accepted by DBMS 109; and s . Data translator 117 translates data returned from DBMS 109 into DL 101, and presents that transforrned data either to the user or to KBMS 105.
The operation of system 101 is as follows: The user presents a query to be answered 119. This query is created by means of description language 101, which specifies the syntactic conventions by which the query should be constructed.
10 The query forrnulated in DL 101 (121) is passed to query translator 113, which translates it into QL 115, which is accepted by the database management system 109.
DBMS 109 processes the query with respect to the data in its stored database 111, and returns the answer in the form of tables 123 to the user.
It is also possible for the user to receiYe the result of the query expressed 15 in DL 101, by having the result of the query passed through data translator 117. This yields DL 101 descriptions of the appropriate individuals in the database (125/126).
The results 126 of the query in the forrn produced by translator 117 can also be passed directly to the KBMS 105 and stored for future reference (using KBMS integration process 127). Finally, the user can add a new description 129 20 expressed in DL 101 directly to the knowledge base 107. Once expressed in DL 101, this new description 129 can be added to the organized descriptions resident in knowledge base 107 by means of incremental description integration process 131.
The added effect of this integration is that all individual objects previously introduced into knowledge base 107 are automatically tested to see if they satisfy the 25 new description, and any that succeed are classified as belonging to that new description 129.
At any point, KBMS 105 can accept a user description (131) as a query to be answered directly by the KBMS, based on the inforrnation that has been stored in knowledge base 107. The answer to such a query 133 thus takes into account any 30 previous descriptions entered into the KB 107 as well as all data entered there from the database 111 via translator 117.
.
,. ..
: , . , ,~ .
:. ~ , ; .
" :
- 7 ~
Detailed Description of the Structure and Operation of th~ Invention In a preferred embodiment, the initial "raw" data is held in a conventional database (111), managed by a con~tentional database management system (109). This embodiment uses a relational database manager, which, as s exemplified in Figure 2, contains at least a database schema 201 and the data 203 in the form of relational tables. Relational DB managers of this sort are widespread and well-known (for an introduction to database technology, see Navathe, supra. The tables are simply sets of records or "rows", each row in a given table having the sarne structure as all other rows in the table (this is specified by the schema for that 10 table). In Figure 3, for example, we see a sample record from the table "PEOPLE"
303. The schema for this table 301 dictates the form of the rows, in particular stating that each row in the PEOPLE table must have a name field, and age, sex, mother, and father fields (the "domains", or set of permissible values, can also be specified in the schema; e.g., age might be restricted to an integer, whereas sex must be a member of 15 the set ~M,F}). Ln the example, a person whose name is 'Chuck' is described as having years=41, sex='M', mother='Liz' and father='Phil'.
In a preferred embodiment, data 203 in the database 111 is accessed via a query language 115. The most common example is SQL, which allows the user to select various columns (technically a projection) from sets of tables, where the20 selection of rows is constrained by various clauses, including those that "join"
together two tables based on the value of an attribute (e.g., joining two tables based on social security number would yield a row with combined inforrnation about thesame individual). The form of SQL queries is relatively simple:
select ~field names>
2s from ctable names~
where <constraints that rows must satisfy>.
Such a select statement can also be followed by a "group by" clause that allows the aggregation of properties by collecting together all rows that have the same field values, as dicta~ed by the group by clause. For example, if a table CHILD TABLE
30 was capturing the set of relationships between a person and his/her children by having one row per parent/child pair, the number of children for each person could be obtained by this query:
select parent,count(*) , . , .
~' '' .' : .
Detailed Description of the Structure and Operation of th~ Invention In a preferred embodiment, the initial "raw" data is held in a conventional database (111), managed by a con~tentional database management system (109). This embodiment uses a relational database manager, which, as s exemplified in Figure 2, contains at least a database schema 201 and the data 203 in the form of relational tables. Relational DB managers of this sort are widespread and well-known (for an introduction to database technology, see Navathe, supra. The tables are simply sets of records or "rows", each row in a given table having the sarne structure as all other rows in the table (this is specified by the schema for that 10 table). In Figure 3, for example, we see a sample record from the table "PEOPLE"
303. The schema for this table 301 dictates the form of the rows, in particular stating that each row in the PEOPLE table must have a name field, and age, sex, mother, and father fields (the "domains", or set of permissible values, can also be specified in the schema; e.g., age might be restricted to an integer, whereas sex must be a member of 15 the set ~M,F}). Ln the example, a person whose name is 'Chuck' is described as having years=41, sex='M', mother='Liz' and father='Phil'.
In a preferred embodiment, data 203 in the database 111 is accessed via a query language 115. The most common example is SQL, which allows the user to select various columns (technically a projection) from sets of tables, where the20 selection of rows is constrained by various clauses, including those that "join"
together two tables based on the value of an attribute (e.g., joining two tables based on social security number would yield a row with combined inforrnation about thesame individual). The form of SQL queries is relatively simple:
select ~field names>
2s from ctable names~
where <constraints that rows must satisfy>.
Such a select statement can also be followed by a "group by" clause that allows the aggregation of properties by collecting together all rows that have the same field values, as dicta~ed by the group by clause. For example, if a table CHILD TABLE
30 was capturing the set of relationships between a person and his/her children by having one row per parent/child pair, the number of children for each person could be obtained by this query:
select parent,count(*) , . , .
~' '' .' : .
from CHILD_TABLE
group by parent.
In the preferred embodiment, the knowledge base management sys~em 1~)5 is based on a class of formalisms called "description logics" (often referred to as s "terminological logics"). These are a well-known class of artificial intelligence representation languages that owe their origin in large part to a well-known system called KL-One (R. J. Brachman & J. G. Schmolze, "An Overview of the KL-One Knowledge Representation System", Cognitive Science, Vol. 9, No. 2, April-June, 1985, pp. 171-216). The key ingredient of such description logics is a description 10 language (DL 103) that allows the user to express complex descriptions (the rough equivalent of English noun phrases) in a compositional way; that is, the language allows ~he expression of fully defined concepts that are built in a compositional manner from previously defined concepts. A concept like "CAT" would not be fullydefined in a DL, since it is virtually impossible to find a full necessary and sufficient 5 specification of the properties of cats. This would make the formal description CAT
be what is called a "primitive" description or concept. However, the concept of a "CAT with blue eyes" could be built compositionally from the concept CAT and theattribute EYE-C~LOR. Thus, CAT-WITH-BLUF.-EYES (the formal description or concept) would be considered a compositional or "defined" description or concept.
DL-based KBMS systems take the user's description of terms like CAT-WITH-BLUE-EYES and "classify" them -- find their relationships to all previously specified terrns. This classification procedure relies on the ability to find a generalization (or "subsumption") relationship between any pair of terms e~cpressed in the DL. The classification process finds all previously-specified descriptions that 2s are more general (i.e., that subsume) the new one, and all previously-specified descriptions that are more specific (i.e., that are subsumed by) the new one. They can find which of the more general ones are most specific, and which of the morespecific ones that are most general, and place the new one in between those. This yields a generalization ordering arnongst the concepts -- a partial ordering based on 30 the subsumption relationship. This is usually drawn as a hierarchy of some sort, although most DL's permit any description to have multiple parent (more general)descriptions, ar~d thus do not yield a strictly hierarchical ordering.
In a preferred embodiment, the DL of choice is the language, CLASSIC
(L. A. Resnick, "The CLASSIC User's Manual", AT~T Bell Laborafories Technical 35 Report, 1991; R. J. Brachman, A. Borgida, D. L. McGuinness, P. ~. Patel-. ' ~ ~,.
group by parent.
In the preferred embodiment, the knowledge base management sys~em 1~)5 is based on a class of formalisms called "description logics" (often referred to as s "terminological logics"). These are a well-known class of artificial intelligence representation languages that owe their origin in large part to a well-known system called KL-One (R. J. Brachman & J. G. Schmolze, "An Overview of the KL-One Knowledge Representation System", Cognitive Science, Vol. 9, No. 2, April-June, 1985, pp. 171-216). The key ingredient of such description logics is a description 10 language (DL 103) that allows the user to express complex descriptions (the rough equivalent of English noun phrases) in a compositional way; that is, the language allows ~he expression of fully defined concepts that are built in a compositional manner from previously defined concepts. A concept like "CAT" would not be fullydefined in a DL, since it is virtually impossible to find a full necessary and sufficient 5 specification of the properties of cats. This would make the formal description CAT
be what is called a "primitive" description or concept. However, the concept of a "CAT with blue eyes" could be built compositionally from the concept CAT and theattribute EYE-C~LOR. Thus, CAT-WITH-BLUF.-EYES (the formal description or concept) would be considered a compositional or "defined" description or concept.
DL-based KBMS systems take the user's description of terms like CAT-WITH-BLUE-EYES and "classify" them -- find their relationships to all previously specified terrns. This classification procedure relies on the ability to find a generalization (or "subsumption") relationship between any pair of terms e~cpressed in the DL. The classification process finds all previously-specified descriptions that 2s are more general (i.e., that subsume) the new one, and all previously-specified descriptions that are more specific (i.e., that are subsumed by) the new one. They can find which of the more general ones are most specific, and which of the morespecific ones that are most general, and place the new one in between those. This yields a generalization ordering arnongst the concepts -- a partial ordering based on 30 the subsumption relationship. This is usually drawn as a hierarchy of some sort, although most DL's permit any description to have multiple parent (more general)descriptions, ar~d thus do not yield a strictly hierarchical ordering.
In a preferred embodiment, the DL of choice is the language, CLASSIC
(L. A. Resnick, "The CLASSIC User's Manual", AT~T Bell Laborafories Technical 35 Report, 1991; R. J. Brachman, A. Borgida, D. L. McGuinness, P. ~. Patel-. ' ~ ~,.
9 ~ 3 2 ~3 3 Schneider, an(i L. A. Resnick, "Living with Classic: How and When to Use a KL-One-like Language", in J. Sowa, ed., Princlples of Semantic Networks: Explorations in the Representation of Know~e~lge, Morgan Kaufmann, lg91, pp. 401-456).
CLASSIC has a number of description-forming constructs representative of the s family of description languages mentioned above. A CLASSIC knowledge base 107 has three main parts (see Figure 2): (1) a set of concept definitions 205; these are the named descriptions that are stored and organized by the CLASSIC KBMS. As mentioned above, they can be either primitive (207) or compositional ("defined" --209); (2) a set of binary relation definitions 211; in CLASSIC these can be "roles"
CLASSIC has a number of description-forming constructs representative of the s family of description languages mentioned above. A CLASSIC knowledge base 107 has three main parts (see Figure 2): (1) a set of concept definitions 205; these are the named descriptions that are stored and organized by the CLASSIC KBMS. As mentioned above, they can be either primitive (207) or compositional ("defined" --209); (2) a set of binary relation definitions 211; in CLASSIC these can be "roles"
10 213, which can have more than one value (e.g., child), or "attributes" 215, which can hàve only a single filler (e.g., age, mother); and (3) a set of individual object descriptions 217, which characterize individual objects in the world in terms of the concept definitions 205 and which are related together by means of the role definitions 211.
Examples of the DL 103 constructs are given in Figure 3. The PERSON
primitive concept definition 305 says that a person is, among other things (the qualification is the meaning of the "PRIMITIVE" construct), something with at most two parents, exactly 1 gender and exactly 1 age. The MOTHER compositional concept definition 307 equates the term MOTHER with the phrase "a person whose 20 gender is exactly 'female' and who has at least one child". In the object portion of the knowledge base we have assertions that individuals satisfy named concepts 309, i.e., LIZ satisfies the previously defined concept, MOTHER; and we also have assertions of the relationships between individuals 311 in terms of roles such as age (not shown, since they have no structure in this embodiment), such as LIZ has 25 age=65.
Algorithms supported by the KBMS 105 include (1) the classification of descriptions 135, as discussed above; this provides the ability to take class orindividual descriptions 129 from the user and to add them to the knowledge base 107 in the correct place in the generalization ordering; (2) an algorithm 137 that directly 30 answers users' ~ueries 131 from the knowledge base 107; (3) an incremental classification algorithm for new descriptions 131 that takes a new description 129 and adds them to the generalization ordering as well as classifies all individuals currently in the object base 217 with respect to the new description; this algorithm can be a variant or algorithm 135; (4) a special set of KBMS integrator functions 127 3s that allow the integration of individuals coming from the database without invoking the classification functions 135. This is a "back-door" way to create individual lo 2 ~
objects in the knowledge base 107 without invoking very complex, lime-conswming classification machinery. The individuals must be integrated in a way that preserves consistency and integrity in the knowledge base Such integration is one of the key aspects of the present system. The assurance that the integration is properly done is s given by the proper construction of queries to the database man~ger 109 by the translator 113.
The Query Translator As related above, a user forms descriptions and/or queries in the description language 103. These are presented to the system and an appropriate lo place in a generalization ordering of other descriptions is found by algorithm 135.
The user-generated description may possibly be named and stored permanently in the generalization ordering in knowledge base 107. In the case where the user's description is fully compositional and uses only terms already known to the system, a query in the query language 115 of the database is algorithmically generated by ls query translator 113 and issued to the database. If the database query processing has been optimized, this query is composed to take ad~antage of that optimization. In any case, the query is strl~ctured so that when a result is returned to the description language system, the basic classification algorithm for individual objects does not have to be run. This is one key advantage of the present invention: since databases 20 like 111 tend to be huge compared to the typical use of KBMS systems like 105, and SQL query processors are highly optimized and the databases are highly indexed, the amount of time it takes a DB query processor ~109) to compute an answer and theninstall it in the knowledge base without classification is normally be significantly less than the time it takes to add one individual object at a time from the database 2s and use the normal classification algorithm 135 to find the right parent descriptions for all (potentially tens of thousands) of the new individuals.
Classification algorithm 135 is normal machinery for DL-based systems like CLASSIC and many others, see William A. Woods and James G. Schmolze, "The KL-ONE Family,'' to appear in Computers and Mathematics with 30 Applications, Special Issue on Semantic Networks in Arti;ficial Intelligence, but query translator 113 is not. Figure 4 shows more detail on the present invention with respect to the translator. 111e heart of the translator is Algorithm 1, which takes as input a compositional concept description 401 expressed in DL 103, and two sets of view definitions, 403 and 405. The view definitions are ~uely language 115 (SQL)35 expressions for the primitive concepts and roles defined in the knowledge base 107.
.
: ~ "
.: ~ , .
- . , .
2 0 l ~
~ iew definitions 403 are for primitive concepts; they are constructedsuch that when executed by the query language interpreter 109 they return tableswith one row each for each object that satisfies the prinlitive concept description.
For example, as shown in Figure 5, a primitive concept like PERSON can be defined - s by a view 503 (PERSON_VIEW), which retrieves one row per person in the database; this view derives such a table from the database table PEOPLE. Note that the rows returned must also have filled in values from the database for each attribute;
in this example, the PERSON view 503 derives the value of the gender attribute from the sex field of the database record, and derives the value of its age attribute lo from the years field of the database record. Note also that each row produced must have a key, so that each individual can be given a unique name in the knowledge base based on the key. In example 503, the key is taken from the name field of the PEOPLE table. This is a particularly simple view, since it maps a single database field onto a single knowledge base attribute, but the mappings can be and typically 15 are substantially more complex.
View definitions 405 are similar. They correspond to roles in the knowledge base 107. A role view definition must return a table from the databasethat has two fields in each row, one for the individual from whom the role will emarlate in the knowledge base 107, and one for the value of that role. View 20 definition ~05 gives an example. It defines the view for determining fillers of the child role from the database. Note that CHILDREN VIEW will return a table with rows with two fields, the first calculated by fetching either the father or mother field of tlhe PEOPLE relation, the second calculated by fetching the name of the person.
Thus, our example above will return this table given view definition 505 (the 25 UNION operator in SQL produces a table that is the union of two tables):
coll col2 Phil Chuck Liz Chuck 30 The intent here is that when passed appropriately back to the knowledge base, Phil and Liz will each be given Chuck as a filler of their children roles. In other words, each will independently be asserted to have Chuck as a child. Note that this transformation from the database is not as obvious as the prior one -- we are translating from a single table with separate fields for mother and father to separate ' . , " ' .
-12- ~7~2,~
assertions of the child relation for Liz an~J Phil. In a sense this inverts the direction of the relationship in the translation.
Views such as 503 and 505 are taken as input by Algorithm 1, and used to translate input concept descriptions 401 to the databa~se sluery langwage. For s example, if the user inputs the description S01, which means "a person whose children include Chuck"7 Algorithm 1 will utilize the view definitions 503 for PERSON and 505 for children (which are both used in description 501), and createthe SQL query 507. Query 507 joins the PERSON ~IEW and children_VIEW
tables, asking to return any rows from the PERSON_VEW table whose name is the 10 sarne as the "from" field in the children_VEW table (this is the join; to make sure that both tables are taLtcing about the same individual, the key field generated by view 503 is used here), and where the person in question is in the "from" field of a row in the children_VIEW table where the database name (DBName) of Chuck is in the "to" field of the same row. In the case mentioned above, this will return the rows 5 for Liz and Phil that presumably exist in the PEOPLE table (not shown).
Algorithm l for constructing such queries 407/507 is depicted in Figure 6. The preprocessing step 601 transforms the query 401 to a form more convenientfor processing. Preprocessing involves at least, for every description in the stored generalization ordering, (l) separation of restrictions involving attributes from those 20 involving roles; (2) separation of restrictions of the form (ALL p (ONE-OF ...)) and (ALL p (TEST-H ...)) from general ALL restrictions of the form (ALL p C); (3) combination of (AT-MOST n p) restrictions with (AT-LEAST m p) restrictions into single restrictions, (NUM-BDS p m n). This phase makes mapping into effective SQL queries easier (e.g., attributes can be gathered with individuals, as illustrated in 2s Figure 5, but roles must be expressed in separate rows in a role-view table).Function GetSQL 603 actually computes the query. It uses subsidiary function Translate 605, which is descAbed in Figure 7. Basically, GetSQL first creates an empty SQL query Q 607. Assuming that the DL description C (401 ) is the conjunction of a narned concept NamedC and set of constructors D 1, D2, etc., 30 GetSQL then calls Translate on the Dl, and passes it a reference to the key of the view defined for NarnedC. Translate 605 returns two sets of clauses, which are then concatenated to the from clause of Q 607 and the where clause of Q 607. This in essence produces the query corresponding to the conjunction of NamedC and D 1.
The process is repeated for D2, etc., until all construclors are translated. The result 3s is the final query to be passed to the DBMS 109.
!,~
' ' ' ' ~, .
-13~ 2~
Note that if the initial description 401 has more than one named concept in it, one table for each additional named concept is added to the from clause, a new variable is assigned to that table, and a join specification is cr~ated in the where clause, e.g., if the two concepts NamedC and NamedC2 are conjoined, the resulting s query would be:
select x.key from NamedC_VEW x, NamedC2 VIEW y where x.key = y.key GetSQL 603 ~en proceeds as before.
Details of Translate 605 are illustrated in Figure 7. The variables fm and wh are initialized to be null strings. The constructor type (FILLS, ONE-OF, etc.) of D is matched against the patterns 701, and whichever pattern is matchedtriggers the assignment of fm and wh, which are then returned.
The Data Translator: FIG. 8 Figure 8 illustrates Algorithm 2, which is the heart of data translator 117. This algorithm takes as input tables resulting from a database query, and translates the rows of the tables into descriptions of individual objects (125tl26) in the description language 103. It assumes that one row of a table generated by a concept query (either 801 or ~03) will correspond to one individual object to be20 created; one row of a role table 805 (a table created by a role query 405/505) will result iri the assertion of a single relationship be~ween two objects. Algorithm 2 also takes as input a set of narne mappings 807 and a set of role closure specifications 809. I'he mappings 807 allow for the fact that the same individual can be indicated one way in a database and a completely different way in a knowledge base (for 2s example, the DB may use social security numbers to identify individuals, and the knowledge base may use first and last name pairs). The closure specifications 809 indicate whether or not the data in the database is considered complete for a given role (see below).
Figure 9 provides some pseudo-code for Algorithm 2, and an example of 30 its output, generated by a query for PERSONs and their children (this would be issued, for example, when trying to initially populate the knowledge base 107 with .. , , . . ~
.
- 14 - ~ 2 ~3 ~
complete descriptions of all people described in the database 111). An individual object that is indicated by a row of a concept table from the database has threerelevant parts: (l) the parent concept in the knowledge base 107 that was used to find the individuail; in the ex~mple 90l, this would be PERSO~; (2) values for the s attributes in the knowledge base for the object; in the example 901, these would be the values for gender and age; (3) values for any relevant roles in the knowledge base; in the example, the values for children would be computed by the role viewdefinition 505. In order to convert these rows to descriptions in DL l03, the three simple steps in Algorithm 2 are used. Note that attributes of objects appear in the lo rows of the tables returned from concept queries (along with the key to the individual object). An individual is created for each row in the concept table; its name is generated from the key specified in that row. That name can be just the key (e.g., Liz), a combination of the concept narne and the key (e.g., Person#Liz), or some mapping from the key to an identifier, as specified by the user (e.g., ls ElizabethJones). Each value of each attribute is described in DL 103 based on a mapping (807) specified by the user (e.g., the number (65) for the age is just mapped into a number in DL 103; it could just has well have been mapped into a discretevalue like "SeniorCitizen"). In Step 2 of Algorithm 2, the role values (children in the example) are added to the description. In the CLASSIC language, the user has the20 option to state whether the role should be "closed" when the data from the database is filled in (in the preferred embodiment, this is done with role closure specifications 809). This would mean that the data in the database is complete, and no further fillers of the role can be claimed. If the dataibase has complete information about people's children, then we would have Algorithm 2 close the children role. In the 2s event that the database is incomplete, and Liz might have other, unspecified children, we would not close the role. The example 90l sho~vs no role closure operations.
Fina~ly, when completely populating the knowledge base 107 from the database I l l (but not when simply asking a query), the complete list of parent concepts that describe the individual object can be determined. In the example, Liz would not 30 only be found by the PERSON view definition, but also by one for MOTHER, since she is Female and has at least one child. The parent concepts can be consolidated in a list, as in the exarnple 90l.
.. . . . . . .
, ~ i , ,:
- 15 - ~ ~ r~ ~ 7 ~3 ~
Inte~ration witll the Knowled~e Base The final piece of the preferred embodiment is the mechanism for taking the output of the data translator 117 and integrate the descriplions of individuals into the knowledge base 107. The integration mechanism 127 is s illustrated in Figure 10. The first step is to take descriptions 126 issued from the data translator 117 and enter these into the database 107 without invoking the normal individual classification functions 135. These result in direct assertions of concept membership for the individuals, direct assertions of the attributes for the individuals, and direct asscrtion of role relationships, all without integrity checking, inheritance 10 of properties, or classification. Once the initial assertions are made (which will typically be substantially faster than if the norrnal classification functions had been used), it is important to check directly for inconsistencies (in case the data in the database does not match the schema requirements of the knowledge base). This is done in Step 2 of Algorithm 3, which issues queries to the database with the 15 negations of any necessar~v properties of the relevant primitive concepts in the knowledge base, and with checking of disjoint primitive views for overlaps. For example, if it were required in the knowledge base that every PERSON must also be an EMPLOYEE, this step would issue a query looking for persons who were not employees; if any were found, the user would be warned of such a violation. Under 20 normal use of a KBMS like CLASSIC, these requirements would be checked as soon as an update is made; since integrator 127 does not invoke the normal classification apparatus, it must make these checks for consistency, even if it avoids classification.
Additionally, description languages like CLASSIC may have facilities for computing inferences that are not duplicable with SQL queries; these include (1) 2s forward-chaining rules; (2) "test-functions" that invoke user code written using CLASSIC objects and functions, rather than functions over base (or "host") values;
the latter (but not the forrner) would allow their invocation directly as part of the SQL quer~Y execution (e.g., as C programs); and (3) forms of inferential propagation that depend on the state of the knowledge base and not just on the schema for a 30 concept or role. Once again, since the normal data entr~ mechanism has been circumvented for efficiency reasons in the present invention, these inferences must specifically be invoked after the direct assertions are made to the knowledge base.
The substeps of Step 3 of Algorithm 3 indicate what must be done in the case of a CLASSIC knowledge base 107. In~erential propagatioDs that need additional queries 3s are invoked, and ~he normal KBMS 105 inference mechaDisms are invoked when the original SQL is insufficient. Rules indicate further descriptions to be added to , - IG ~ 2 ~ ~
individuals when they are found to satisfy certain descriptions; rule invocation must be facilitated l~y issuing queries that find all objects to which a rule is applicable but for which the consequent of the rule does not hold; these would be found by the means already described, which determines the instances satisfying named 5 descriptions. The normal CLASSIC mechanisms could then be used to apply the rules that need application. Further, in CLASSIC, rules can be "filtered", meaning that only members of a subset of the instances of a named concept should have the rule applied to them. Queries must be formed and evaluated that correspond to the filters. Finally, while test functions that apply to "host values" -- values such as 0 numbers and strings, which are represented directly in the implementation language -- can be evaluated directly against the database in the view definitions, test functions that apply to knowledge base objects ("CLASSIC individ~lals") mus~ be applied in this post-processing phase. These may eliminate some candidates from some descriptions that they otherwise appear to satisfy, given only the view 1S definitions.
1: onclusion The foregoing Detailed Description has disclosed to those skilled in the arts to which the invention pertains how one may make and use a system for evaluating queries expressed in a formal description language against a database20 with a conventional query language interface. Other techniques than those disclosed herein for practicing the invention and other areas in which the invention may be applied will be apparent to those skilled in the arts concerned after reading the foregoing disclosure. For example, the invention applies to any database or inforrnation system mechanism, including all those that honor SQL queries, or others 2~ (e.g., object-oriented databases) that do not, as long as they have a formal query interface. This could even include a knowledge base management system in place of the database system in the presented embodiment. In place of the CLASSIC system in this embodiment, any system that supports a description language with compositional descriptions can be used. This would include all systems considered 30 to be "terminological logics" such as LOOM, BACK, etc., as well as others that support compound descriptions, such as OMEGA. While the CLASSIC system performs its inference in what is known as a "forward-chaining" manner -- that is, all inferences are performed in a forward direction as soon as updates are made -- the ^
present invention applies equally well to systems that use different regimes for 17 ~ 3 ~
infcrence, including backward-chaining and hybrid reasoning strategies.
Because of the wealth of possible embodiments of the invention, the foregoing Detailed Description is to be understood as being in every respect illustrative and exemplary, but not restrictive, and the scope of the invention 5 disclosed herein is not to be determined from the Detailed Specification, but rather from the claims as interpreted in light of the Detailed Description and in accordance with the doctrine of equivalences.
What is claimed is:
.
. .
Examples of the DL 103 constructs are given in Figure 3. The PERSON
primitive concept definition 305 says that a person is, among other things (the qualification is the meaning of the "PRIMITIVE" construct), something with at most two parents, exactly 1 gender and exactly 1 age. The MOTHER compositional concept definition 307 equates the term MOTHER with the phrase "a person whose 20 gender is exactly 'female' and who has at least one child". In the object portion of the knowledge base we have assertions that individuals satisfy named concepts 309, i.e., LIZ satisfies the previously defined concept, MOTHER; and we also have assertions of the relationships between individuals 311 in terms of roles such as age (not shown, since they have no structure in this embodiment), such as LIZ has 25 age=65.
Algorithms supported by the KBMS 105 include (1) the classification of descriptions 135, as discussed above; this provides the ability to take class orindividual descriptions 129 from the user and to add them to the knowledge base 107 in the correct place in the generalization ordering; (2) an algorithm 137 that directly 30 answers users' ~ueries 131 from the knowledge base 107; (3) an incremental classification algorithm for new descriptions 131 that takes a new description 129 and adds them to the generalization ordering as well as classifies all individuals currently in the object base 217 with respect to the new description; this algorithm can be a variant or algorithm 135; (4) a special set of KBMS integrator functions 127 3s that allow the integration of individuals coming from the database without invoking the classification functions 135. This is a "back-door" way to create individual lo 2 ~
objects in the knowledge base 107 without invoking very complex, lime-conswming classification machinery. The individuals must be integrated in a way that preserves consistency and integrity in the knowledge base Such integration is one of the key aspects of the present system. The assurance that the integration is properly done is s given by the proper construction of queries to the database man~ger 109 by the translator 113.
The Query Translator As related above, a user forms descriptions and/or queries in the description language 103. These are presented to the system and an appropriate lo place in a generalization ordering of other descriptions is found by algorithm 135.
The user-generated description may possibly be named and stored permanently in the generalization ordering in knowledge base 107. In the case where the user's description is fully compositional and uses only terms already known to the system, a query in the query language 115 of the database is algorithmically generated by ls query translator 113 and issued to the database. If the database query processing has been optimized, this query is composed to take ad~antage of that optimization. In any case, the query is strl~ctured so that when a result is returned to the description language system, the basic classification algorithm for individual objects does not have to be run. This is one key advantage of the present invention: since databases 20 like 111 tend to be huge compared to the typical use of KBMS systems like 105, and SQL query processors are highly optimized and the databases are highly indexed, the amount of time it takes a DB query processor ~109) to compute an answer and theninstall it in the knowledge base without classification is normally be significantly less than the time it takes to add one individual object at a time from the database 2s and use the normal classification algorithm 135 to find the right parent descriptions for all (potentially tens of thousands) of the new individuals.
Classification algorithm 135 is normal machinery for DL-based systems like CLASSIC and many others, see William A. Woods and James G. Schmolze, "The KL-ONE Family,'' to appear in Computers and Mathematics with 30 Applications, Special Issue on Semantic Networks in Arti;ficial Intelligence, but query translator 113 is not. Figure 4 shows more detail on the present invention with respect to the translator. 111e heart of the translator is Algorithm 1, which takes as input a compositional concept description 401 expressed in DL 103, and two sets of view definitions, 403 and 405. The view definitions are ~uely language 115 (SQL)35 expressions for the primitive concepts and roles defined in the knowledge base 107.
.
: ~ "
.: ~ , .
- . , .
2 0 l ~
~ iew definitions 403 are for primitive concepts; they are constructedsuch that when executed by the query language interpreter 109 they return tableswith one row each for each object that satisfies the prinlitive concept description.
For example, as shown in Figure 5, a primitive concept like PERSON can be defined - s by a view 503 (PERSON_VIEW), which retrieves one row per person in the database; this view derives such a table from the database table PEOPLE. Note that the rows returned must also have filled in values from the database for each attribute;
in this example, the PERSON view 503 derives the value of the gender attribute from the sex field of the database record, and derives the value of its age attribute lo from the years field of the database record. Note also that each row produced must have a key, so that each individual can be given a unique name in the knowledge base based on the key. In example 503, the key is taken from the name field of the PEOPLE table. This is a particularly simple view, since it maps a single database field onto a single knowledge base attribute, but the mappings can be and typically 15 are substantially more complex.
View definitions 405 are similar. They correspond to roles in the knowledge base 107. A role view definition must return a table from the databasethat has two fields in each row, one for the individual from whom the role will emarlate in the knowledge base 107, and one for the value of that role. View 20 definition ~05 gives an example. It defines the view for determining fillers of the child role from the database. Note that CHILDREN VIEW will return a table with rows with two fields, the first calculated by fetching either the father or mother field of tlhe PEOPLE relation, the second calculated by fetching the name of the person.
Thus, our example above will return this table given view definition 505 (the 25 UNION operator in SQL produces a table that is the union of two tables):
coll col2 Phil Chuck Liz Chuck 30 The intent here is that when passed appropriately back to the knowledge base, Phil and Liz will each be given Chuck as a filler of their children roles. In other words, each will independently be asserted to have Chuck as a child. Note that this transformation from the database is not as obvious as the prior one -- we are translating from a single table with separate fields for mother and father to separate ' . , " ' .
-12- ~7~2,~
assertions of the child relation for Liz an~J Phil. In a sense this inverts the direction of the relationship in the translation.
Views such as 503 and 505 are taken as input by Algorithm 1, and used to translate input concept descriptions 401 to the databa~se sluery langwage. For s example, if the user inputs the description S01, which means "a person whose children include Chuck"7 Algorithm 1 will utilize the view definitions 503 for PERSON and 505 for children (which are both used in description 501), and createthe SQL query 507. Query 507 joins the PERSON ~IEW and children_VIEW
tables, asking to return any rows from the PERSON_VEW table whose name is the 10 sarne as the "from" field in the children_VEW table (this is the join; to make sure that both tables are taLtcing about the same individual, the key field generated by view 503 is used here), and where the person in question is in the "from" field of a row in the children_VIEW table where the database name (DBName) of Chuck is in the "to" field of the same row. In the case mentioned above, this will return the rows 5 for Liz and Phil that presumably exist in the PEOPLE table (not shown).
Algorithm l for constructing such queries 407/507 is depicted in Figure 6. The preprocessing step 601 transforms the query 401 to a form more convenientfor processing. Preprocessing involves at least, for every description in the stored generalization ordering, (l) separation of restrictions involving attributes from those 20 involving roles; (2) separation of restrictions of the form (ALL p (ONE-OF ...)) and (ALL p (TEST-H ...)) from general ALL restrictions of the form (ALL p C); (3) combination of (AT-MOST n p) restrictions with (AT-LEAST m p) restrictions into single restrictions, (NUM-BDS p m n). This phase makes mapping into effective SQL queries easier (e.g., attributes can be gathered with individuals, as illustrated in 2s Figure 5, but roles must be expressed in separate rows in a role-view table).Function GetSQL 603 actually computes the query. It uses subsidiary function Translate 605, which is descAbed in Figure 7. Basically, GetSQL first creates an empty SQL query Q 607. Assuming that the DL description C (401 ) is the conjunction of a narned concept NamedC and set of constructors D 1, D2, etc., 30 GetSQL then calls Translate on the Dl, and passes it a reference to the key of the view defined for NarnedC. Translate 605 returns two sets of clauses, which are then concatenated to the from clause of Q 607 and the where clause of Q 607. This in essence produces the query corresponding to the conjunction of NamedC and D 1.
The process is repeated for D2, etc., until all construclors are translated. The result 3s is the final query to be passed to the DBMS 109.
!,~
' ' ' ' ~, .
-13~ 2~
Note that if the initial description 401 has more than one named concept in it, one table for each additional named concept is added to the from clause, a new variable is assigned to that table, and a join specification is cr~ated in the where clause, e.g., if the two concepts NamedC and NamedC2 are conjoined, the resulting s query would be:
select x.key from NamedC_VEW x, NamedC2 VIEW y where x.key = y.key GetSQL 603 ~en proceeds as before.
Details of Translate 605 are illustrated in Figure 7. The variables fm and wh are initialized to be null strings. The constructor type (FILLS, ONE-OF, etc.) of D is matched against the patterns 701, and whichever pattern is matchedtriggers the assignment of fm and wh, which are then returned.
The Data Translator: FIG. 8 Figure 8 illustrates Algorithm 2, which is the heart of data translator 117. This algorithm takes as input tables resulting from a database query, and translates the rows of the tables into descriptions of individual objects (125tl26) in the description language 103. It assumes that one row of a table generated by a concept query (either 801 or ~03) will correspond to one individual object to be20 created; one row of a role table 805 (a table created by a role query 405/505) will result iri the assertion of a single relationship be~ween two objects. Algorithm 2 also takes as input a set of narne mappings 807 and a set of role closure specifications 809. I'he mappings 807 allow for the fact that the same individual can be indicated one way in a database and a completely different way in a knowledge base (for 2s example, the DB may use social security numbers to identify individuals, and the knowledge base may use first and last name pairs). The closure specifications 809 indicate whether or not the data in the database is considered complete for a given role (see below).
Figure 9 provides some pseudo-code for Algorithm 2, and an example of 30 its output, generated by a query for PERSONs and their children (this would be issued, for example, when trying to initially populate the knowledge base 107 with .. , , . . ~
.
- 14 - ~ 2 ~3 ~
complete descriptions of all people described in the database 111). An individual object that is indicated by a row of a concept table from the database has threerelevant parts: (l) the parent concept in the knowledge base 107 that was used to find the individuail; in the ex~mple 90l, this would be PERSO~; (2) values for the s attributes in the knowledge base for the object; in the example 901, these would be the values for gender and age; (3) values for any relevant roles in the knowledge base; in the example, the values for children would be computed by the role viewdefinition 505. In order to convert these rows to descriptions in DL l03, the three simple steps in Algorithm 2 are used. Note that attributes of objects appear in the lo rows of the tables returned from concept queries (along with the key to the individual object). An individual is created for each row in the concept table; its name is generated from the key specified in that row. That name can be just the key (e.g., Liz), a combination of the concept narne and the key (e.g., Person#Liz), or some mapping from the key to an identifier, as specified by the user (e.g., ls ElizabethJones). Each value of each attribute is described in DL 103 based on a mapping (807) specified by the user (e.g., the number (65) for the age is just mapped into a number in DL 103; it could just has well have been mapped into a discretevalue like "SeniorCitizen"). In Step 2 of Algorithm 2, the role values (children in the example) are added to the description. In the CLASSIC language, the user has the20 option to state whether the role should be "closed" when the data from the database is filled in (in the preferred embodiment, this is done with role closure specifications 809). This would mean that the data in the database is complete, and no further fillers of the role can be claimed. If the dataibase has complete information about people's children, then we would have Algorithm 2 close the children role. In the 2s event that the database is incomplete, and Liz might have other, unspecified children, we would not close the role. The example 90l sho~vs no role closure operations.
Fina~ly, when completely populating the knowledge base 107 from the database I l l (but not when simply asking a query), the complete list of parent concepts that describe the individual object can be determined. In the example, Liz would not 30 only be found by the PERSON view definition, but also by one for MOTHER, since she is Female and has at least one child. The parent concepts can be consolidated in a list, as in the exarnple 90l.
.. . . . . . .
, ~ i , ,:
- 15 - ~ ~ r~ ~ 7 ~3 ~
Inte~ration witll the Knowled~e Base The final piece of the preferred embodiment is the mechanism for taking the output of the data translator 117 and integrate the descriplions of individuals into the knowledge base 107. The integration mechanism 127 is s illustrated in Figure 10. The first step is to take descriptions 126 issued from the data translator 117 and enter these into the database 107 without invoking the normal individual classification functions 135. These result in direct assertions of concept membership for the individuals, direct assertions of the attributes for the individuals, and direct asscrtion of role relationships, all without integrity checking, inheritance 10 of properties, or classification. Once the initial assertions are made (which will typically be substantially faster than if the norrnal classification functions had been used), it is important to check directly for inconsistencies (in case the data in the database does not match the schema requirements of the knowledge base). This is done in Step 2 of Algorithm 3, which issues queries to the database with the 15 negations of any necessar~v properties of the relevant primitive concepts in the knowledge base, and with checking of disjoint primitive views for overlaps. For example, if it were required in the knowledge base that every PERSON must also be an EMPLOYEE, this step would issue a query looking for persons who were not employees; if any were found, the user would be warned of such a violation. Under 20 normal use of a KBMS like CLASSIC, these requirements would be checked as soon as an update is made; since integrator 127 does not invoke the normal classification apparatus, it must make these checks for consistency, even if it avoids classification.
Additionally, description languages like CLASSIC may have facilities for computing inferences that are not duplicable with SQL queries; these include (1) 2s forward-chaining rules; (2) "test-functions" that invoke user code written using CLASSIC objects and functions, rather than functions over base (or "host") values;
the latter (but not the forrner) would allow their invocation directly as part of the SQL quer~Y execution (e.g., as C programs); and (3) forms of inferential propagation that depend on the state of the knowledge base and not just on the schema for a 30 concept or role. Once again, since the normal data entr~ mechanism has been circumvented for efficiency reasons in the present invention, these inferences must specifically be invoked after the direct assertions are made to the knowledge base.
The substeps of Step 3 of Algorithm 3 indicate what must be done in the case of a CLASSIC knowledge base 107. In~erential propagatioDs that need additional queries 3s are invoked, and ~he normal KBMS 105 inference mechaDisms are invoked when the original SQL is insufficient. Rules indicate further descriptions to be added to , - IG ~ 2 ~ ~
individuals when they are found to satisfy certain descriptions; rule invocation must be facilitated l~y issuing queries that find all objects to which a rule is applicable but for which the consequent of the rule does not hold; these would be found by the means already described, which determines the instances satisfying named 5 descriptions. The normal CLASSIC mechanisms could then be used to apply the rules that need application. Further, in CLASSIC, rules can be "filtered", meaning that only members of a subset of the instances of a named concept should have the rule applied to them. Queries must be formed and evaluated that correspond to the filters. Finally, while test functions that apply to "host values" -- values such as 0 numbers and strings, which are represented directly in the implementation language -- can be evaluated directly against the database in the view definitions, test functions that apply to knowledge base objects ("CLASSIC individ~lals") mus~ be applied in this post-processing phase. These may eliminate some candidates from some descriptions that they otherwise appear to satisfy, given only the view 1S definitions.
1: onclusion The foregoing Detailed Description has disclosed to those skilled in the arts to which the invention pertains how one may make and use a system for evaluating queries expressed in a formal description language against a database20 with a conventional query language interface. Other techniques than those disclosed herein for practicing the invention and other areas in which the invention may be applied will be apparent to those skilled in the arts concerned after reading the foregoing disclosure. For example, the invention applies to any database or inforrnation system mechanism, including all those that honor SQL queries, or others 2~ (e.g., object-oriented databases) that do not, as long as they have a formal query interface. This could even include a knowledge base management system in place of the database system in the presented embodiment. In place of the CLASSIC system in this embodiment, any system that supports a description language with compositional descriptions can be used. This would include all systems considered 30 to be "terminological logics" such as LOOM, BACK, etc., as well as others that support compound descriptions, such as OMEGA. While the CLASSIC system performs its inference in what is known as a "forward-chaining" manner -- that is, all inferences are performed in a forward direction as soon as updates are made -- the ^
present invention applies equally well to systems that use different regimes for 17 ~ 3 ~
infcrence, including backward-chaining and hybrid reasoning strategies.
Because of the wealth of possible embodiments of the invention, the foregoing Detailed Description is to be understood as being in every respect illustrative and exemplary, but not restrictive, and the scope of the invention 5 disclosed herein is not to be determined from the Detailed Specification, but rather from the claims as interpreted in light of the Detailed Description and in accordance with the doctrine of equivalences.
What is claimed is:
.
. .
Claims (10)
1. Apparatus for locating entities comprising:
means for making a compositional description which defines a collection to which one or more of the entities potentially belongs;
means for translating the compositional description into a query;
a data base for storing the entities; and a data base management system for responding to the query by locating the entities belonging to the collection in the data base.
means for making a compositional description which defines a collection to which one or more of the entities potentially belongs;
means for translating the compositional description into a query;
a data base for storing the entities; and a data base management system for responding to the query by locating the entities belonging to the collection in the data base.
2. The apparatus set forth in claim 1 further comprising:
a knowledge base; and a knowledge base management system; and the means for translating further receives the located entities and produces a compositional description defining the located entities and the knowledge base management system responds to the compositional description defining the located entities by adding the located entities to the knowledge base.
a knowledge base; and a knowledge base management system; and the means for translating further receives the located entities and produces a compositional description defining the located entities and the knowledge base management system responds to the compositional description defining the located entities by adding the located entities to the knowledge base.
3. The apparatus set forth in claim 2 wherein:
the knowledge base management system responds to the compositional description defining the located entities by adding the located entities as a collection to the knowledge base.
the knowledge base management system responds to the compositional description defining the located entities by adding the located entities as a collection to the knowledge base.
4. The apparatus set forth in claim 3 wherein:
the knowledge base management system includes means for providing a compositional description which checks for a first possible inconsistency between one or more of the located entities in the collection and the knowledge base;
the translating means receives the compositional description which checks for the possible inconsistency, translates the received compositional description into a query, and returns the results of the query to the knowledge base management system; and the knowledge base management system responds to results which indicate a possible inconsistency by issuing a warning concerning the collection.
the knowledge base management system includes means for providing a compositional description which checks for a first possible inconsistency between one or more of the located entities in the collection and the knowledge base;
the translating means receives the compositional description which checks for the possible inconsistency, translates the received compositional description into a query, and returns the results of the query to the knowledge base management system; and the knowledge base management system responds to results which indicate a possible inconsistency by issuing a warning concerning the collection.
5. The apparatus set forth in claim 4 wherein:
the means for providing a compositional description provides another compositional description which checks for a second possible inconsistency between the located entities and the knowledge base to the knowledge base; and the knowledge base management system responds to results from the knowledge base which indicate the second possible inconsistency by issuing the warning.
the means for providing a compositional description provides another compositional description which checks for a second possible inconsistency between the located entities and the knowledge base to the knowledge base; and the knowledge base management system responds to results from the knowledge base which indicate the second possible inconsistency by issuing the warning.
6. The apparatus set forth in claim 2 wherein:
the knowledge base management system further responds to the compositional description defining the collection by adding the compositional description to the knowledge base.
the knowledge base management system further responds to the compositional description defining the collection by adding the compositional description to the knowledge base.
7. A method of obtaining a collection of entities from a data base system comprising the steps of:
making a first compositional description which defines the collection of entities;
automatically translating the first compositional description into a first query for the data base system; and employing the first query to locate the collection of entities in the data base system.
making a first compositional description which defines the collection of entities;
automatically translating the first compositional description into a first query for the data base system; and employing the first query to locate the collection of entities in the data base system.
8. The method set forth in claim 7 further comprising the steps of:
automatically providing a second compositional description which describes the entities in the located collection; and using the second compositional description in a knowledge system to add the entities in the located collection to a knowledge base.
automatically providing a second compositional description which describes the entities in the located collection; and using the second compositional description in a knowledge system to add the entities in the located collection to a knowledge base.
9. I he method set forth in claim 8 further comprising the steps of:
automatically deriving a third compositional description from the second compositional description;
automatically translating the third compositional description into a second query for the data base system; and employing the second query to obtain a result from which an inconsistency between an entity in the located collection and the knowledge basemay be determined.
automatically deriving a third compositional description from the second compositional description;
automatically translating the third compositional description into a second query for the data base system; and employing the second query to obtain a result from which an inconsistency between an entity in the located collection and the knowledge basemay be determined.
10. The method set forth in claim 9 wherein:
the steps added in claim 9 are performed before the entities in the located collection are added to the knowledge base.
the steps added in claim 9 are performed before the entities in the located collection are added to the knowledge base.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US781,464 | 1991-10-23 | ||
| US07/781,464 US5418943A (en) | 1991-10-23 | 1991-10-23 | Information system with knowledge base and data base |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2079285A1 true CA2079285A1 (en) | 1993-04-24 |
Family
ID=25122836
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002079285A Abandoned CA2079285A1 (en) | 1991-10-23 | 1992-09-28 | Information access apparatus and methods |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5418943A (en) |
| EP (1) | EP0542430A3 (en) |
| JP (1) | JPH06290102A (en) |
| CA (1) | CA2079285A1 (en) |
Families Citing this family (102)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6578027B2 (en) * | 1996-08-20 | 2003-06-10 | Business Objects, Sa | Relational database access system using semantically dynamic objects |
| US5659724A (en) * | 1992-11-06 | 1997-08-19 | Ncr | Interactive data analysis apparatus employing a knowledge base |
| US5615112A (en) * | 1993-01-29 | 1997-03-25 | Arizona Board Of Regents | Synthesized object-oriented entity-relationship (SOOER) model for coupled knowledge-base/database of image retrieval expert system (IRES) |
| EP0667587A3 (en) * | 1994-02-15 | 1996-01-31 | Motorola Inc | Method for generically describing measured results. |
| US5600831A (en) * | 1994-02-28 | 1997-02-04 | Lucent Technologies Inc. | Apparatus and methods for retrieving information by modifying query plan based on description of information sources |
| CA2148028A1 (en) * | 1994-05-25 | 1995-11-26 | Deborah L. Mcguinness | Knowledge base management system with dependency information for procedural tests |
| JP3310116B2 (en) * | 1994-08-31 | 2002-07-29 | 株式会社東芝 | Knowledge base system |
| US5764974A (en) * | 1995-08-30 | 1998-06-09 | Unisys Corporation | System with user specified pattern definitions for matching input messages and associated decisions for conditionally responding to the input messages |
| US5809493A (en) * | 1995-12-14 | 1998-09-15 | Lucent Technologies Inc. | Knowledge processing system employing confidence levels |
| US5989835A (en) | 1997-02-27 | 1999-11-23 | Cellomics, Inc. | System for cell-based screening |
| US5715371A (en) * | 1996-05-31 | 1998-02-03 | Lucent Technologies Inc. | Personal computer-based intelligent networks |
| US6272481B1 (en) | 1996-05-31 | 2001-08-07 | Lucent Technologies Inc. | Hospital-based integrated medical computer system for processing medical and patient information using specialized functional modules |
| US5778157A (en) * | 1996-06-17 | 1998-07-07 | Yy Software Corporation | System and method for expert system analysis using quiescent and parallel reasoning and set structured knowledge representation |
| US5745889A (en) * | 1996-08-09 | 1998-04-28 | Digital Equipment Corporation | Method for parsing information of databases records using word-location pairs and metaword-location pairs |
| US5987450A (en) * | 1996-08-22 | 1999-11-16 | At&T | System and method for obtaining complete and correct answers from incomplete and/or incorrect databases |
| US5884304A (en) * | 1996-09-20 | 1999-03-16 | Novell, Inc. | Alternate key index query apparatus and method |
| US5873079A (en) * | 1996-09-20 | 1999-02-16 | Novell, Inc. | Filtered index apparatus and method |
| US5870739A (en) * | 1996-09-20 | 1999-02-09 | Novell, Inc. | Hybrid query apparatus and method |
| US6415319B1 (en) | 1997-02-07 | 2002-07-02 | Sun Microsystems, Inc. | Intelligent network browser using incremental conceptual indexer |
| US6385600B1 (en) | 1997-04-03 | 2002-05-07 | At&T Corp. | System and method for searching on a computer using an evidence set |
| US6317871B1 (en) * | 1997-07-18 | 2001-11-13 | Compaq Computer Corporation | System for ensuring the accuracy of file structures in a source-to-source computer program translator |
| US6425118B1 (en) | 1997-07-18 | 2002-07-23 | Compaq Computer Corporation | System for automatically generating tests to ensure binary compatibility between software components produced by a source-to-source computer language translator |
| US6236994B1 (en) * | 1997-10-21 | 2001-05-22 | Xerox Corporation | Method and apparatus for the integration of information and knowledge |
| US6327587B1 (en) * | 1998-10-05 | 2001-12-04 | Digital Archaeology, Inc. | Caching optimization with disk and/or memory cache management |
| US6601058B2 (en) * | 1998-10-05 | 2003-07-29 | Michael Forster | Data exploration system and method |
| ATE292822T1 (en) | 1998-11-13 | 2005-04-15 | Cellomics Inc | METHOD AND SYSTEM FOR EFFICIENTLY OBTAINING AND STORING EXPERIMENTAL DATA |
| US6411936B1 (en) | 1999-02-05 | 2002-06-25 | Nval Solutions, Inc. | Enterprise value enhancement system and method |
| US6438541B1 (en) * | 1999-02-09 | 2002-08-20 | Oracle Corp. | Method and article for processing queries that define outer joined views |
| US6408302B1 (en) * | 1999-06-28 | 2002-06-18 | Davox Corporation | System and method of mapping database fields to a knowledge base using a graphical user interface |
| US6421658B1 (en) * | 1999-07-30 | 2002-07-16 | International Business Machines Corporation | Efficient implementation of typed view hierarchies for ORDBMS |
| US20070219995A1 (en) * | 1999-10-08 | 2007-09-20 | Knowledge Filter | Knowledge filter |
| US7031952B1 (en) * | 1999-10-08 | 2006-04-18 | Knowledge Filter, Inc. | Knowledge filter |
| JP2001216333A (en) * | 1999-11-29 | 2001-08-10 | Xerox Corp | Data retrieval system with computer-readable medium |
| US7403920B2 (en) * | 2000-01-14 | 2008-07-22 | Fujitsu Limited | Information mediating apparatus and method and storage medium storing information mediating program therein |
| CA2396495A1 (en) | 2000-01-25 | 2001-08-02 | Cellomics, Inc. | Method and system for automated inference creation of physico-chemical interaction knowledge from databases of co-occurrence data |
| US6647382B1 (en) | 2000-01-28 | 2003-11-11 | International Business Machines Corporation | Technique for detecting a subsuming temporal relationship of valid time data in a relational database management system |
| US6691097B1 (en) | 2000-01-28 | 2004-02-10 | International Business Machines Corporation | Technique for detecting a shared temporal relationship of valid time data in a relational database management system |
| AU2001265006A1 (en) * | 2000-05-24 | 2001-12-03 | The Haley Enterprises, Inc. | A system for enterprise knowledge management and automation |
| US20020123920A1 (en) * | 2000-06-06 | 2002-09-05 | Du Preez Nicolaas Deetlef | Integrated enterprise and product design and transformation system |
| US7043457B1 (en) | 2000-06-28 | 2006-05-09 | Probuild, Inc. | System and method for managing and evaluating network commodities purchasing |
| US6813615B1 (en) | 2000-09-06 | 2004-11-02 | Cellomics, Inc. | Method and system for interpreting and validating experimental data with automated reasoning |
| US6640231B1 (en) * | 2000-10-06 | 2003-10-28 | Ontology Works, Inc. | Ontology for database design and application development |
| US6473367B2 (en) * | 2000-12-15 | 2002-10-29 | Koung-Chung Peng | Positioning mechanism for a radio clock |
| US7415438B1 (en) | 2001-06-12 | 2008-08-19 | Microstrategy, Incorporated | System and method for obtaining feedback from delivery of informational and transactional data |
| US7574376B1 (en) | 2001-06-12 | 2009-08-11 | Microstrategy Incorporated | System and method for generating and using a transaction enable report |
| US7356758B1 (en) | 2001-06-19 | 2008-04-08 | Microstrategy Incorporated | System and method for run-time report resolution of reports that include prompt objects |
| US7302639B1 (en) | 2001-06-19 | 2007-11-27 | Microstrategy, Inc. | Report system and method using prompt in prompt objects |
| US7430562B1 (en) | 2001-06-19 | 2008-09-30 | Microstrategy, Incorporated | System and method for efficient date retrieval and processing |
| US8005870B1 (en) | 2001-06-19 | 2011-08-23 | Microstrategy Incorporated | System and method for syntax abstraction in query language generation |
| US7801967B1 (en) | 2001-06-19 | 2010-09-21 | Microstrategy, Incorporated | Method and system for implementing database connection mapping for reporting systems |
| US7559048B1 (en) | 2001-06-19 | 2009-07-07 | Microstrategy Incorporated | System and method for managing objects between projects |
| US6801910B1 (en) | 2001-06-19 | 2004-10-05 | Microstrategy, Incorporated | Method and system for guiding drilling in a report generated by a reporting system |
| US8051168B1 (en) | 2001-06-19 | 2011-11-01 | Microstrategy, Incorporated | Method and system for security and user account integration by reporting systems with remote repositories |
| US7725811B1 (en) | 2001-06-19 | 2010-05-25 | Microstrategy, Inc. | Report system and method using prompt object abstraction |
| US7861161B1 (en) | 2001-06-19 | 2010-12-28 | Microstrategy, Inc. | Report system and method using prompt objects |
| US7356840B1 (en) | 2001-06-19 | 2008-04-08 | Microstrategy Incorporated | Method and system for implementing security filters for reporting systems |
| US7925616B2 (en) | 2001-06-19 | 2011-04-12 | Microstrategy, Incorporated | Report system and method using context-sensitive prompt objects |
| US6697808B1 (en) | 2001-06-19 | 2004-02-24 | Microstrategy, Inc. | Method and system for performing advanced object searching of a metadata repository used by a decision support system |
| US8522192B1 (en) | 2001-06-20 | 2013-08-27 | Microstrategy Incorporated | Systems and methods for performing operations in a reporting system |
| US6859798B1 (en) | 2001-06-20 | 2005-02-22 | Microstrategy, Inc. | Intelligence server system |
| US7010518B1 (en) | 2001-06-20 | 2006-03-07 | Microstrategy, Inc. | System and method for user defined data object hierarchy |
| US6691100B1 (en) | 2001-06-20 | 2004-02-10 | Microstrategy, Incorporated | HTML/DHTML web interface system and method |
| US9183317B1 (en) | 2001-06-20 | 2015-11-10 | Microstrategy Incorporated | System and method for exporting report results from a reporting system |
| US7509671B1 (en) | 2001-06-20 | 2009-03-24 | Microstrategy Incorporated | Systems and methods for assigning priority to jobs in a reporting system |
| US7228303B1 (en) | 2001-06-20 | 2007-06-05 | Microstrategy Inc. | System and method for remote manipulation of analytic reports |
| US6820073B1 (en) | 2001-06-20 | 2004-11-16 | Microstrategy Inc. | System and method for multiple pass cooperative processing |
| US8606813B1 (en) | 2001-06-20 | 2013-12-10 | Microstrategy Incorporated | System and method for function selection in analytic processing |
| US6996569B1 (en) | 2001-06-20 | 2006-02-07 | Microstrategy Incorporated | Systems and methods for custom grouping of data |
| US6704723B1 (en) | 2001-06-20 | 2004-03-09 | Microstrategy, Incorporated | Method and system for providing business intelligence information over a computer network via extensible markup language |
| US7836178B1 (en) | 2001-06-20 | 2010-11-16 | Microstrategy Incorporated | Technique for limiting access to the resources of a system |
| US6772137B1 (en) | 2001-06-20 | 2004-08-03 | Microstrategy, Inc. | Centralized maintenance and management of objects in a reporting system |
| US7113993B1 (en) | 2001-06-20 | 2006-09-26 | Microstrategy, Inc. | Technique for handling server session requests in a system having a plurality of servers |
| US7003512B1 (en) * | 2001-06-20 | 2006-02-21 | Microstrategy, Inc. | System and method for multiple pass cooperative processing |
| US6658432B1 (en) | 2001-06-20 | 2003-12-02 | Microstrategy, Inc. | Method and system for providing business intelligence web content with reduced client-side processing |
| US7617201B1 (en) | 2001-06-20 | 2009-11-10 | Microstrategy, Incorporated | System and method for analyzing statistics in a reporting system |
| US6996568B1 (en) | 2001-06-20 | 2006-02-07 | Microstrategy Incorporated | System and method for extension of data schema |
| US20030105673A1 (en) * | 2001-11-30 | 2003-06-05 | Dunbaugh Bradley Jay | Method for materials distribution |
| US7970782B1 (en) | 2002-01-14 | 2011-06-28 | Microstrategy Incorporated | Systems and methods for set filtering of data |
| US7421476B2 (en) * | 2002-10-29 | 2008-09-02 | Weaver Eric R | Method for converting internet messages for publishing |
| US7836031B2 (en) * | 2003-03-28 | 2010-11-16 | Microsoft Corporation | Systems and methods for employing a trigger-based mechanism to detect a database table change and registering to receive notification of the change |
| US20050144177A1 (en) * | 2003-11-26 | 2005-06-30 | Hodes Alan S. | Patent analysis and formulation using ontologies |
| US20050234738A1 (en) * | 2003-11-26 | 2005-10-20 | Hodes Alan S | Competitive product intelligence system and method, including patent analysis and formulation using one or more ontologies |
| US20050262489A1 (en) * | 2004-05-12 | 2005-11-24 | Streeter Gordon S | Knowledge representation language and knowledge processing environment |
| US7861253B1 (en) | 2004-11-12 | 2010-12-28 | Microstrategy, Inc. | Systems and methods for accessing a business intelligence system through a business productivity client |
| EP1820091A4 (en) | 2004-11-12 | 2010-07-21 | Haley Ltd North America | A system for enterprise knowledge management and automation |
| US7516181B1 (en) | 2005-02-08 | 2009-04-07 | Microstrategy, Inc. | Technique for project partitioning in a cluster of servers |
| US8761659B1 (en) | 2005-02-11 | 2014-06-24 | Microstrategy, Inc. | Integration of e-learning with business intelligence system |
| US8095386B2 (en) * | 2005-05-03 | 2012-01-10 | Medicity, Inc. | System and method for using and maintaining a master matching index |
| US8645313B1 (en) | 2005-05-27 | 2014-02-04 | Microstrategy, Inc. | Systems and methods for enhanced SQL indices for duplicate row entries |
| US7865533B2 (en) * | 2007-02-05 | 2011-01-04 | Microsoft Corporation | Compositional query comprehensions |
| US7805456B2 (en) * | 2007-02-05 | 2010-09-28 | Microsoft Corporation | Query pattern to enable type flow of element types |
| US7792838B2 (en) * | 2007-03-29 | 2010-09-07 | International Business Machines Corporation | Information-theory based measure of similarity between instances in ontology |
| JP5171962B2 (en) * | 2007-10-11 | 2013-03-27 | 本田技研工業株式会社 | Text classification with knowledge transfer from heterogeneous datasets |
| JP5503737B2 (en) * | 2010-05-14 | 2014-05-28 | 株式会社日立製作所 | Time-series data management device, system, method, and program |
| US8964549B2 (en) | 2010-06-22 | 2015-02-24 | Sierra Wireless, Inc. | Method and apparatus for managing wireless communication based on network traffic level |
| US9189566B2 (en) | 2010-12-07 | 2015-11-17 | Sap Se | Facilitating extraction and discovery of enterprise services |
| US9069844B2 (en) | 2011-11-02 | 2015-06-30 | Sap Se | Facilitating extraction and discovery of enterprise services |
| US9177289B2 (en) | 2012-05-03 | 2015-11-03 | Sap Se | Enhancing enterprise service design knowledge using ontology-based clustering |
| US9720972B2 (en) * | 2013-06-17 | 2017-08-01 | Microsoft Technology Licensing, Llc | Cross-model filtering |
| US9532086B2 (en) * | 2013-11-20 | 2016-12-27 | At&T Intellectual Property I, L.P. | System and method for product placement amplification |
| US10372689B1 (en) * | 2014-08-04 | 2019-08-06 | Intuit, Inc. | Consumer-defined service endpoints |
| US11514070B2 (en) * | 2018-10-06 | 2022-11-29 | Teradata Us, Inc. | Seamless integration between object-based environments and database environments |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4841441A (en) * | 1984-08-01 | 1989-06-20 | Adata Software Limited | Method of creating a computer system |
| JPS62251849A (en) * | 1986-04-25 | 1987-11-02 | Hitachi Ltd | Access optimizing system for data base |
| JP2565310B2 (en) * | 1986-08-28 | 1996-12-18 | 株式会社日立製作所 | Knowledge base to database converter |
| US4884218A (en) * | 1987-10-01 | 1989-11-28 | International Business Machines Corporation | Knowledge system with improved request processing |
| US5282265A (en) * | 1988-10-04 | 1994-01-25 | Canon Kabushiki Kaisha | Knowledge information processing system |
| JPH02109149A (en) * | 1988-10-19 | 1990-04-20 | Hitachi Ltd | Automatic knowledge extraction type data base control system |
| US5197005A (en) * | 1989-05-01 | 1993-03-23 | Intelligent Business Systems | Database retrieval system having a natural language interface |
| US5159667A (en) * | 1989-05-31 | 1992-10-27 | Borrey Roland G | Document identification by characteristics matching |
| EP0473864A1 (en) * | 1990-09-04 | 1992-03-11 | International Business Machines Corporation | Method and apparatus for paraphrasing information contained in logical forms |
| US5278980A (en) * | 1991-08-16 | 1994-01-11 | Xerox Corporation | Iterative technique for phrase query formation and an information retrieval system employing same |
-
1991
- 1991-10-23 US US07/781,464 patent/US5418943A/en not_active Expired - Lifetime
-
1992
- 1992-09-28 CA CA002079285A patent/CA2079285A1/en not_active Abandoned
- 1992-10-16 EP EP19920309447 patent/EP0542430A3/en not_active Withdrawn
- 1992-10-22 JP JP4308072A patent/JPH06290102A/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| EP0542430A3 (en) | 1993-08-25 |
| JPH06290102A (en) | 1994-10-18 |
| EP0542430A2 (en) | 1993-05-19 |
| US5418943A (en) | 1995-05-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5418943A (en) | Information system with knowledge base and data base | |
| Calvanese et al. | Data integration in data warehousing | |
| Borgida et al. | Loading data into description reasoners | |
| Goh et al. | Context interchange: New features and formalisms for the intelligent integration of information | |
| Teorey et al. | A logical design methodology for relational databases using the extended entity-relationship model | |
| Goh | Representing and reasoning about semantic conflicts in heterogeneous information systems | |
| US8595231B2 (en) | Ruleset generation for multiple entities with multiple data values per attribute | |
| Yazici et al. | Handling complex and uncertain information in the ExIFO and NF/sup 2/data models | |
| Cheung et al. | The model-assisted global query system for multiple databases in distributed enterprises | |
| Albert et al. | Automatic importation of relational schemas in Pegasus | |
| Koubarakis et al. | A retrospective on Telos as a metamodeling language for requirements engineering | |
| Shepherd et al. | PRISM: A knowledge based system for semantic integrity specification and enforcement in database systems | |
| Sedigh et al. | Semantic query in a relational database using a local ontology construction | |
| Lawley et al. | A Query Language for EER Schemas. | |
| Alzahrani et al. | Integrity merging in an object-oriented federated database environment | |
| Berger et al. | Analysing multi-dimensional data across autonomous data warehouses | |
| Harrison | Condition monitoring in an active deductive database | |
| Fonkam et al. | Employing integrity constraints for query modification and intensional answer generation in multi-database systems | |
| Bergamaschi et al. | Momis: An intelligent system for the integration of semistructured and structured data | |
| Sen et al. | Deductive data modeling: A new trend in database management for decision support systems | |
| McLeod | Perspective on object databases | |
| Storey et al. | Semantic integrity constraints in knowledge-based database design systems | |
| Abdalla | A new approach for the integration of heterogeneous databases and information systems | |
| Whang et al. | Heterogeneous Databases: Inferring Relationships for Merging Component Schemas, and Query Language | |
| Abdelguerfi et al. | Knowledge Engineering |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |