Method for representation of knowledge in a computer as a network database system

Abstract

A system for knowledge representation in a computer, together with the ability to recognize, store and use patterns in the knowledge representation, together with the ability for Natural Language Interaction with the knowledge representation system, together with means to automatically transform information in the knowledge representation into a multitude of documents or other human interpretable displays in a plurality of different formats or views. User interaction with the knowledge representation through the view documents is achievable through a multitude of various possible formats. The Knowledge Representation system defines a novel database engine constituting a method for modeling knowledge as a network of concepts and a plurality of relationships between the concepts comprising the network. Each concept is represented as a record in the database which is identified by a unique record reference number. The unique record reference numbers are stored within the records comprising the database to record the plurality of relationships between concepts.

Claims

What is claimed is:

1. A method for representing information in a computer system, comprising the steps of:

providing in said computer system a knowledge representation database made up of individual records, wherein each record is associated with a unique reference number (URN) by which each record is identified;

storing in each of a plurality of records of said knowledge representation database the URN of at least one other record of said knowledge representation database; and

automatically deriving in said computer system a human understandable format for displaying information contained in said records through reading and evaluation of said stored URNs;

wherein at least one record is associated with stored context information.

2. The method for representing information in a computer system according to claim 1, wherein each record of said database stores a plurality of relationships, said relationships being comprised of a characterization and a value,

the characterization of said relationship being a URN of a second record which defines the nature of the relationship, and

the value of said relationship being a complex data type comprised of internal, external and mixed values which define the object of a relationship,

internal values storing only URNs of other records and,

external values storing values other than the URNs of other records such as character strings, integers, real numbers, etc., and

mixed values storing a combination of values typical of internal and external values;

and further comprising the step of storing in at least one record at least one relationship that is associated with context information.

Description

BACKGROUND OF THE INVENTION

This invention relates to a system for knowledge representation in a computer system together with Natural Language Interface, together with the ability to recognize, store and use patterns in the knowledge representation, together with computerized means for automatically transforming information in the knowledge representation into a multitude of documents or other human interpretable displays in a plurality of different formats or views, together with means for user interaction with the knowledge representation through the documents or displays.

The Knowledge Representation system defines a novel database engine constituting a method for modeling knowledge as a network of concepts and the relationships of each concept to other concepts. Each concept is represented as a record in the database which is identified by a unique record reference number. Relationships are represented by storing the unique record reference numbers of relevant records within the records comprising the knowledge representation database.

The records are organized into strata or levels of abstraction by means of storing relationships to other records within a given stratum. These relationships organize each level into hierarchies and a plurality of other relational networks which represent generally accepted ways of thinking about various fields of knowledge.

The concepts in lower levels of abstraction are related to those in higher levels by storing the unique record reference numbers of records of simple (more abstract) concepts within the structure of records representing more complex (more specific) concepts. Thus, more complex concepts are defined by the records whose reference numbers are stored within their record structure.

This invention further relates to a novel system for a Natural Language Interface (NLI) including a new method of parsing and evaluating input expressions in conjunction with the information in the Knowledge Representation Database.

The system includes a method for dynamically updating the Knowledge Representation database to "learn" through interaction with system users. This is accomplished by programmed means which automatically recognize, store, and utilize patterns in the knowledge representation database.

The system further includes a novel method for automatically transforming knowledge embodied in the Database into a plurality of human-perceivable documents expressing the knowledge.

User interaction with the Knowledge Representation through the Documents enables user interactions typical of Graphical User Interfaces (GUI), Hypertext, Object Linking Embedding (OLE), and context sensitive operation in a single unified user interface.

The present invention can be evaluated by referring to five major constituents which are illustrated in FIG. 1.

A) The data-base engine referred to herein as a "knowledge representation" system is most closely related to hierarchical and network databases. It differs from previously disclosed databases in that this invention employs a record system which embeds the database record numbers of a plurality of other records within a list stored in a particular record in a network of interrelated records. Each record is allowed to maintain an unbounded list of relationships to other records within the Knowledge Representation database.

System concepts are defined which allow the creation of levels of abstraction within the knowledge representation.

Fundamental relationships are the minimum set of relationships which each record is required to have in order to assure that the concept is related to the other concepts of the knowledge representation database. Each record is required to store the reference number of at least one record in a higher level of abstraction than that record, and every record on each level of abstraction is required to store at least one record reference number of another record on the same level in a relationship which is characterized by an attribute typical of the level.

The Knowledge Representation system further requires a separate, non-permanent database in which to assemble descriptions of particular records from the network of records in the primary Knowledge Representation database.

The retrieval system of an individual record and the records whose reference numbers are embedded in its substructure provides means for relationship inheritance and is without precedent.

B) The means for pattern recognition, storage and utilization employed in the invention are unique and provide novel means for machine "learning" by recognizing patterns in the relationships comprising the records, storing the patterns as relationships and utilizing the patterns in creating additional concepts and relationships in the Knowledge Representation Database.

C) The Natural Language Interface (NLI) is a novel system for enabling human interaction with the Knowledge Representation Database by using human language. The NLI system employs novel means for parsing input expressions in that it employs a sequential combination of a transitional network parser (related to an Augmented Transition Network) and a pattern matching parser (related to Parsing by differences lists methods). Both parsers are further unique in that they are based on the level of abstraction and fundamental relationships of a concept in the knowledge representation database instead of the human language grammatical function of the concept.

D) The method for automatically deriving a multitude of documents is based on abstracting standard documents or displays of knowledge into Views, Classes, and Types, wherein the Types define the vocabulary, the Class defines the grammar, and the View defines the connectivity and interaction, and is without precedent.

E) The user interface integrates the principal characteristics of GUI, Hypertext, OLE, and context sensitive programming in a single integrated user environment. This integration is without precedent, and is implemented in the invention by novel means which are significant improvements over the means currently known to the art for these technologies.

In this invention, the hypertext-like behavior is a consequence of the relationships stored at each record so that the view document has the feel of having hypertext implemented on a massive scale; every icon is a portal to all other view documents containing the concept and is also a portal to all related concepts. This contrasts with the Hypertext idiom which typically employs user defined locational links between documents which operate as an adjunct to static document representation.

The Knowledge Representation system further utilizes external relationships which enable the linking of records in the database to file or programs external to the Knowledge Representation Database.

Notes on Implementation

A suitable computer platform and programming environment for the implementation of the invention must be selected by the system developer. The programming environment should easily accommodate the kinds of structures that are required for the knowledge representation.

The Knowledge Representation Database can be implemented on a wide variety of computer systems and hardware. Generally the Knowledge Representation Database will be stored on nonvolatile memory media such as a hard disk, tape, optical disk, etc.

The minimum requirements of a programming environment with database capabilities suitable for implementation of the knowledge representation are summarized in FIG. 2. The database capabilities can either be native to the programming environment or developed by the system developer. Unique reference numbers (2a) must be available in the system for each record. A reference number is any unique tag or label (of any data type) for the record. The reference numbers must be permanently associated with the records (2b). The database must be able to store reference numbers in the database records and associated index(es) (2c). The reference number is typically a standard data type in the development environment.

The reference numbers must be uniquely and permanently associated with each record because the reference numbers are used to cross reference the records by recording reference numbers within the records themselves. The system must store these reference numbers in the database records, as the references to other records contained in a record define the relationship of record to the network of records in the knowledge representation database. The environment should include a database indexing scheme or enable the designer to be able to implement an index to the records in the database (2d). The provision for indexing the records in the database enables rapid identification and retrieval of desired records. The indexing scheme should accommodate indexing key word(s) associated with a record and also indexing selected reference numbers indicating relationships to other records.

Various standard schemes for indexing (B-Trees, hashing, etc.) are currently available. An appropriate scheme will be apparent to the developer once the principles of the invention are understood. Therefore no specific disclosure of an indexing scheme or details of implementation of the indexing scheme are provided in this disclosure. The embodiment in the appendix used a B-tree indexing scheme.

The environment should not restrict the record data type which may be declared for the database since the record data types of the invention include complex data types as disclosed subsequently (2e). The relationships maintained by a record are represented in substructures of complex data types accommodating a wide variety of standard data types. The environment should not restrict the record length (2f). Variable length records are desirable to enable the dynamic addition of relationships to the records. Each record may maintain an unbounded number of relationships: the number and type of relationships differ with each record.

The lack of restriction on the record data typing and record length will provide the widest possible latitude to the system designer in selecting and implementing data types appropriate to the knowledge domain. If restrictions on data type and record length do exist, it may be possible to implement "work arounds". Such work arounds may include record chaining and data type conversion algorithms. Such algorithms, if required, will be known to a skilled practitioner and are not discussed further herein. It is best to avoid systems which will restrict the data typing and record length of the records.

The structures of the records for the Knowledge Representation Database are typically established as data typing (domain) declarations in the programming language in which the structures are implemented. Suitable mechanisms for declaring such structures are provided by the various programming languages or tools which are suitable for implementation of the invention. Since such mechanisms are a property of the specific system in which the invention is implemented, they are considered to be standard and are not discussed in detail in this disclosure.

The invention can be implemented in a wide variety of standard computer systems. The preferred embodiment of the invention included in the appendix was on DOS.RTM. PCs using the programming language PDC Prolog.RTM. with Pharlap.RTM. Extenders. The preferred embodiment illustrates the adaptability of this invention to standard programming environments.

Prolog.RTM. is a declarative language. Declarative languages are distinct from procedural languages in that Declarative languages are not easily represented as procedural flow diagrams. In the following discussions, flow diagrams are used to illustrate the essential procedures and processes embodied in the invention. However, these flow diagrams, while illustrating the essential procedures, must be understood as embodying a procedural equivalent of the declarative code found in the Prolog program.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of a system for representing knowledge in a computer database according to the present invention;

FIG. 2 is a chart of Minimum Requirements for a Development Environment Suitable for Implementation of the Knowledge Representation Database;

FIG. 3 is a Schematic Summary of the Means for Knowledge Representation;

FIG. 4 is a Schematic Diagram of Knowledge Representation Implemented in Multiple Files;

FIG. 5 is a diagram of References in Values of Conjugate Relationships Must Correlate;

FIG. 6 is an illustration of the Organization of Records in Knowledge Representation;

FIG. 7 is an illustration of Library Structure Used in Knowledge Representation;

FIG. 8 is a chart of Summary of Strata Characteristics;

FIG. 9 is an illustration of System Concepts in the Library Structure used in Knowledge Representation;

FIG. 10 is a chart of Summary of Typical Useful Attribute Properties;

FIG. 11 is a chart of Summary of Typical Useful Attribute Classes;

FIG. 12 is a chart example of Domain Declaration for Knowledge Representation Database;

FIG. 13 is a Flow Diagram of Programmed Means for Recognition of System Concepts;

FIG. 14 is a Flow Diagram of Programmed Means for Assuring that System Concepts are Inviolate;

FIG. 15 is a Flow Diagram of Programmed Means for Assembling Ancestor Lists as an Example of Network Traversal;

FIG. 16 is a Flow Diagram of Programmed Means for Saving Information Stored in the Descriptive Database by Storing it in the Knowledge Representation Database;

FIG. 17 is a chart Summary of the types of Relationship Inheritance Based on the Descriptive Networks;

FIG. 18 is a logic diagram illustration of concepts in the descriptive network of an attribute record;

FIG. 19 is a logic diagram illustration of concepts in the descriptive network of a component record;

FIG. 20 is a logic diagram illustration of concepts in the descriptive network of a project record;

FIG. 21 is a Flow Diagram of Programmed Means for Implementing Relationship Inheritance;

FIG. 22 is a Flow Diagram of Programmed Means for Implementing Characterization Inheritance;

FIG. 23 is a chart of Domain Declaration for Descriptive Database;

FIG. 24 is a Flow Diagram of Programmed Means for Adding a Node to the Knowledge Representation Database;

FIG. 25 is a Flow Diagram of Programmed Means for Adding a Relationship to the Relationship.sub.-- List of a Record;

FIG. 26 is a Flow Diagram of Programmed Means for Instituting the Value of an Internal Relationship;

FIG. 27 is a Flow Diagram of Programmed Means for Instituting the Value of an External Relationship;

FIG. 28 is a Tree Diagram of the Taxonomy of Rules System Concepts;

FIG. 29 is a chart Summary and Description of Specific Rules Implemented as System Concepts in the Preferred Embodiment;

FIG. 30 is a chart Summary and Description of Specific Rule Properties Implemented as System Concepts in the Preferred Embodiment;

FIG. 31 is a Flow Diagram of Programmed Means for Pattern Recognition and Storage in the Knowledge Representation;

FIG. 32 is a Flow Diagram of Programmed Means for Natural Language Processing;

FIG. 33 is a Flow Diagram of Programmed Means for Augmented Transition Network Parse;

FIG. 34 is a Database Declaration for NLI Functional Identification Used in Augmented Transition Network Parse;

FIG. 35 is a chart Summary of Suggestions for System Concepts and Associated User Concepts to add to the Knowledge Representation Database for NLI;

FIG. 36 is a Flow Diagram of Programmed Means for Parse by Differences;

FIG. 37 is a chart showing Examples of Views, Classes, and Types Comprising a Plurality of Views of the Knowledge Representation;

FIG. 38 is a Flow Diagram of Programmed Means for View Management;

FIG. 39 is a chart Domain Declaration for Tracking Active;

FIG. 40 is a Flow Diagram of Programmed Means for Deriving a Plurality of Documents of the Knowledge Representation;

FIG. 41 is a chart Summary of Correlation Between View Derivation Step and Level of View Document Abstraction;

FIG. 42 is a Flow Diagram of Programmed Means For Deriving A Plurality of Views of the Knowledge Representation;

FIG. 43 is a Flow Diagram of Programmed Means For Deriving a Plurality of Schematic Classes of the Knowledge Representation;

FIG. 44 is a Flow Diagram of Programmed Means For Deriving a Plurality of Types of Schematic Cluster Diagrams of the knowledge Representation;

FIG. 45 is a Flow Diagram of Programmed Means For Reading Descriptive Sets;

FIG. 46 is a chart showing Examples of Defining and Auxiliary Relationships for Various Types of Documents;

FIG. 47 is a Flow Diagram of Programmed Means For Reading Defining Relationships;

FIG. 48 is a Flow Diagram of Programmed Means For Reading Auxiliary Relationships;

FIG. 49 is a Flow Diagram of Programmed Means For Assigning Icons to a Descriptive Set;

FIG. 50 is a Flow Diagram of Programmed Means For User Interaction with the Knowledge Representation Through the View Documents;

FIG. 51 is a chart Summary of Icon Symbology;

FIG. 52 is a chart Summary of Symbol Interpretation;

FIG. 53 is a Standard Decision tree for Event Processing;

FIG. 54 is a Recommended Decision Tree for Icon Symbol Interpretation;

FIG. 55 is a Flow diagram of Programmed Means for Updating Active Based on User Event Location;

FIG. 56 is a Flow Diagram of Programmed Means For Highlighting Entities;

FIG. 57 is a Flow Diagram of Programmed Means For Interpreting Icon as System Concept Associated with Icon Entities;

FIG. 58 is a Flow Diagram of Programmed Means For Interpreting Icon as Abstraction Associated with Icon Entities;

FIG. 59 is a Flow Diagram of Programmed Means For Interpreting Icon as Entity Editing Procedure;

FIG. 60 is a Flow Diagram of Programmed Means For Interpreting Icon as Procedure for Transferring View Derivation to Active;

FIG. 61 is a Flow Diagram of Programmed Means For Changing View of Active;

FIG. 62 is a Flow Diagram of Programmed Means For Interpreting Icon as Procedure for Identifying Library System Concept of Active;

FIG. 63 is a Flow Diagram of Programmed Means For Interpreting Icon as Abstraction Associated with Active;

FIG. 64 is a Flow Diagram of Programmed Means For Interpreting Icon as Procedure for Concept and Relationship Editing;

FIG. 65 is a Flow Diagram of Programmed Means For Interpreting Icon as External Procedure;

FIG. 66 is a Flow Diagram of Programmed Means For Interpreting Icon as Ancestry Context;

FIG. 67 is a Flow Diagram of Programmed Means For Interpreting Icon as Descendants Context;

FIG. 68 is a Flow Diagram of Programmed Means For Interpreting Icon as Type Context;

FIG. 69 is a Flow Diagram of Programmed Means For Identifying Attribute Class Concepts for Active Attribute User Concept;

FIG. 70 is a Flow Diagram of Programmed Means For Interpreting Icon as User Connection Context;

FIG. 71 is a diagram showing the types of knowledge concepts used in the knowledge representation according to the present invention and identifying the relationships therebetween according to another embodiment of the invention;

FIG. 72 is a diagram showing specific examples of knowledge types as shown in FIG. 71;

FIG. 73 is a diagram illustrating a data structure for storing potential value relationships according to the embodiment of FIG. 71;

FIG. 74 is a flow diagram of programmed means for editing the relationships in the computer database according to the second embodiment;

FIG. 75 is a flow diagram of the detailed steps for storing relationships in the computer database according to FIG. 74;

FIG. 76 is a flow diagram of programmed means for creating specific instances of projects as project records which use potential value relationships stored in Attribute or Component records;

FIG. 77 is a flow diagram of the detailed steps for user selection of specific values in the computer database according to FIG. 76;

FIG. 78 is a chart example showing the storage of context information as a substructure of a record; and

FIG. 79 is a further example in chart form of the storage of context information as a substructure of a record.

DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1 is a schematic diagram which highlights the primary constituents of the invention. A detailed discussion of each of the constituents is provided in subsequent sections following this introductory overview.

The Knowledge Representation Database (1a) is a new type of database system which represents knowledge as a network of a plurality of cross-referenced records comprising a computer database. The representation of knowledge is based on the insight that knowledge is a network of concepts and relationships between concepts (i.e. the meaning of a concept is defined by its relationship to other concepts). Concepts are embodied as individual database records. Relationships between concepts are embodied as substructures within the records which store database reference numbers of other records. "Knowledge" is thus embodied in the resulting network of records and cross references between records.

An effect of this system for Knowledge Representation is the creation of a massively cross-referenced database wherein the cross-referencing is the essence of the database instead of an adjunct or supplement thereto. All of the cross referencing is transparent to the user. An advantage of this system is thus that it achieves the implementation of "knowledge" representation in a computer instead of just data storage, and thus may be contemplated as a "thought" processing system as opposed to a conventional "data" processing system.

The pattern recognition, storage, and use module (1b) enables the representation of abstractions of the patterns of relationships in the knowledge representation. These abstractions of the patterns of relationships are stored as relationships within the Knowledge Representation. When these stored patterns are used in conjunction with means for editing the network of the knowledge representation, the result is intelligent behavior reminiscent of some types of expert systems. The results are, however, achieved by means novel to this invention.

If, for example, in the creation of a chemical processing plant five different kinds of instruments have been used in subassemblies of a tank, upon creation of another tank, the system will suggest the five instruments as likely subassemblies to the system user. Because this is a "learn by use" system instead of an a priori declaration-of-rules type system, the system "gets smarter" the more it is used.

The Knowledge Representation system enables the implementation of a Natural Language Interface (1c) with the Knowledge Representation Database. The Natural Language Interface enables human language interaction with the Knowledge Representation. This is accomplished by recognizing possible patterns (or schemas) of relationship between the concepts in the database. Human language queries or statements are then evaluated by matching patterns in the expression to the patterns of relationship in the knowledge representation database by means of serial parsing a primary characteristic of which is the use of the location of a recognized expression in the Knowledge Representation Database instead of the grammatical function.

This means, for example, that a system user can ask for `all devices connected to FCV100 and not in cabinet M4F` directly, without resorting to any special commands for structured query languages.

A major consequence of the Knowledge Representation system of this invention is enabling the Knowledge Representation to be "viewed" or perceived through a multitude of documents, through the (1d) means for automatically deriving a plurality of documents of the Knowledge Representation. The Knowledge Representation is not oriented to representation of data in any one particular document or view format: rather, it is enabling of all possible documents. Given the view, the computer can automatically derive any specific document embodying portions of the information in the Knowledge Representation Database.

Both traditional and non-traditional documents which illustrate or describe portions of the concepts and relationships in the knowledge representation can be implemented in the system. Examples of traditional documents include schematic diagrams, dimensioned drawings, standard database forms, text based documents, spreadsheet and financial summaries, etc.

For example, a valve may appear in as many as sixteen different documents in the documentation for a process plant, represented by four or five different icons.

The knowledge representation supporting the needed relationships can be accessed by the program defining the view to create the appropriate descriptive database of concepts pertaining to the document. The program defining the view will then select the appropriate icons and morphology sequentially and can develop all sixteen documents with the valve appearing in its different icon forms and in the different document formats.

Each view is comprised of a plurality of classes. Each class is comprised of a plurality of document types. All specific documents are instances of a view, class, and type. Views, classes and types are implemented as programmed means.

Views embody procedures for defining relationship icons and coordination with the means for user interaction.

Classes embody the definition format and icon placement (i.e. grammar).

Types embody procedures for identifying the concepts relevant to the document by means of reading concepts in networks of defining and auxiliary relationships and embody procedures for icon assignment (i.e. vocabulary).

The view documents are comprised of icons representing the concepts and relationships pertinent to the document. These icons are created by the view program. The icon definitions contain the reference numbers of the concepts or relationships in the knowledge representation which the icon represents. Each icon is thus associated with a plurality of distinct items in the Knowledge and Descriptive (discussed below) databases, each of which is potentially symbolized by the icon.

The (1e) means for user interface with the Knowledge Representation through the documents enables a plurality of behaviors for each icon based on interpretation implied by the context. A document is comprised of icons representing a small subset of the concepts and relationships present in the Knowledge Representation Database. An icon can be interpreted as representing the plurality of implied relationships in the network. Utilizing these implied meanings allows the invention to develop extraordinarily context sensitive interaction with the Knowledge Representation. This is achieved by means of decision trees of system responses designed for each view where the substance of the decision tree is the evaluation of the interpretation implied by the context of the interaction. This evaluation of context is without precedent in the art and enables the novel features of the means for user interaction of the invention.

The user interface modules integrate the principle characteristics of GUI, Hypertext, OLE, and context sensitive programming in a single integrated user environment. The icons may behave like Graphical User Interface (GUI) icons in that they can trigger the procedures appropriate to the manipulation of the icon. The icons may also behave like Hypertext links in that they are linked to procedures that can automatically derive all view documents of the concept and all concepts and relationships associated with the concept. The icons may also behave like Object Linking Embedding (OLE) systems in that the icon can be the launch point for an external program or file represented by the icon.

(1a) Means for Knowledge Representation

FIG. 3 provides a schematic summary of the means for knowledge representation which is an expansion and annotation of the FIG. 1 (1a) Means for Knowledge Representation. Knowledge representation embodies knowledge as information stored in a plurality of records in a computer database. Each record is comprised of substructures (herein called relationships) which contain reference numbers to other records. Relationships are comprised of two constituents: a characterization of the relationship; and a value for the relationship. These relationships define the network of knowledge among the plurality of records. On a micro level, the network is comprised of the records and relationships stored in the computer database. On a macro level, the essence of the invention is the totality of the network comprised of the plurality of records and relationships. The Knowledge Representation Database stores information in a plurality of records in a computer, and represents relationships between the records by storing record reference numbers within the records.

Record Operations (3b) are programmed basic operations for editing and interacting with the records comprising the Knowledge Representation Database. Both Input operations (3c) which store information in the records, and Output operations (3d) which retrieve stored information from the records are provided.

Network Operations (3e) are programmed basic operations for interacting with the network of concepts and relationships in the Knowledge Representation Database. The Network Operations transfer information between the Knowledge Representation Database and the Descriptive Database (3h). The Network Operations thus interpret and translate the structure of both databases. The "Save" operation (3f) saves information from the (3h) Descriptive Database in the Knowledge Representation Database, using the Input Record operation (3c). The Save operations are useful in situations where modification to the Knowledge Representation Database is to be buffered by allowing user modification first to the Descriptive Database. If the Descriptive Database (3h) is used to buffer the changes, then the Save operations are used to transfer the modified data from the Descriptive Database to the Knowledge Representation Database upon user invocation of the save operation.

The "Read" operation (3g) reads information from the Knowledge Representation Database by using the unit operations of the Output Record operation (3d). The Read operation is able to retrieve information in the Knowledge Representation Database network through rules of Relationship inheritance (further discussed below) by which records are retrieved according to reference numbers found within other records. The Read operation further provides the means for limiting the network traversal and deriving descriptions for "Active" concepts (further discussed below) in the Knowledge Representation Database, and for storing the descriptions in the Descriptive Database. The Read operations are described in further detail subsequently. The Read operations assemble a specific Descriptive Database from the general concepts and attributes in the Knowledge Representation Database.

The Descriptive Database (3h) is a database which stores the information relevant to the description of a specific concept or concepts that is distinct from the general concepts of the Knowledge Representation Database, while maintaining identification of the corresponding reference numbers in the Knowledge Representation Database of all components and relationships constituting the specific concept description.

The data structures of the Descriptive Database associate various record reference numbers of the relevant records in the Knowledge Representation Database with the information contained in the records to provide a plurality of associations for the information in a specific environment or perspective.

The Descriptive Database is a "working" non-permanent database. The transfer of information to the Descriptive Database from the Knowledge Representation Database is made to consolidate the relationships in the concept records of the Knowledge Representation Database which are expressed as references to other concepts into descriptions of the concepts themselves. The description of the concepts facilitate the human-perceivable views, and consequently user interaction with the Knowledge Representation Database.

The Descriptive Database is called "descriptive" because it is an assembly of a set of relationships which describe a particular concept in the Knowledge Representation Database; and it serves as an intermediary between the Knowledge Representation Database and the (1d) Document module and (1e) View User Interface (FIG. 1) where the "views" provide the human understandable depictions of the knowledge in the Knowledge Representation Database in the form of documents such as tree diagrams, schematic diagrams, and text forms.

The Concept and Relationship Editor (3i) performs operations relevant to editing the concepts and relationships comprising the records of the Knowledge Representation Database. The Concept Editor may add and delete concepts to the Knowledge Representation Database, including establishing fundamental relationships required to assure that all added concepts are linked to appropriate system concepts. The Relationship Editor performs operations relevant to editing relationships in the Knowledge Representation Database. The Relationship Editor is used to edit both the fundamental relationships and the relationship list of each concept record, including editing both the characterization of the relationships and the Values of the relationships.

(3a) Knowledge Representation Database

The Knowledge Representation Database will generally be implemented in a plurality of database files as illustrated in FIG. 10. The Knowledge Representation Database will always consist of at least one Environment Database (4a) and associated index(es) containing both the Attribute Property, Attribute and Component libraries common to all Projects. This database is referred to as the Environment Database, in that it provides the environment for the creation of specific projects. The Environment Database may be comprised of a plurality of databases with associated index(es). In such case, the plurality of databases will be comprised of databases containing the same information as identified above, wherein the information is divided and arranged within the plurality of files.

The Knowledge Representation Database will also generally consist of a plurality of Project libraries (4b). The projects are typically implemented as separate databases with associated index(es). These databases are referred to as "Project Databases", in that each project database contains the project library for a project. If the system is being implemented for a knowledge domain characterized by single project maintenance, then combining the Environment and Project libraries in a single database file may be preferable.

Most real world knowledge domain applications have an environment comprised of a set of Attributes and Components which are used to construct a variety of specific Projects. An organization working in such a knowledge domain will create Projects which are networks of specific instances of the components. The Projects embody the specific knowledge required to achieve an objective of the organization.

For the purposes of the following disclosure, and the preferred embodiment, a multi-project scheme as illustrated in FIG. 4 will be presented, wherein each project is contained in a separate file with all projects referencing a common Environment Database. The single database case is a simplification and easy adaptation of the multi-project scheme and therefor will not be discussed or presented further. The Values of the relationships are comprised of a plurality of domains which accommodate various data types which may be stored. Each of these domains potentially require distinct modes of editing and initiating values of that domain.

The relationship value editor is typically comprised of a plurality of editors, each of which is designed to facilitate the editing of a particular value domain.

Each of the constituent components mentioned above will now be discussed in detail. Each record in the knowledge representation database corresponds to a concept. Concepts are named points in the network of relationships comprising the Knowledge Representation. Each record stores a plurality of relationships. Concepts can be visualized as points or nodes in a network. A large number of relationships radiate from each concept to other concepts within the knowledge representation.

Each record has a unique record reference number. This reference number is permanently assigned to the record. The reference number is used by the computer system to refer to the concept instead of the name of the concept because the reference number is unique whereas the name is often not unique. The reference numbers are always used in defining relationships.

In the simplest conceptualization, a record representing a concept in a computerized system is comprised of a list of data structures for storing relationships: the record is comprised of a list of relationships to other concepts. In its simplest form, knowledge is represented by a plurality of records, each of which stores a plurality of relationships to the other records.

Relationships provide the means for storing the cross references in the plurality of records comprising the network. A plurality of relationships are stored within each record in the Knowledge Representation. The relationships are the operating system reference numbers defining the connections between concepts in knowledge representation. Relationships are comprised of: 1) a Characterization or Attribute that is a reference number of a concept record that identifies the properties of the relationship; and 2) a value (or values) that is the object of the relationship.

The Characterization is the identification of the nature of the relationship between two concepts. For example, assume `Lynn` is a concept and `Wendy` is a concept. If it is true that `Lynn` and `Wendy` love each other, then a Characterization of a relationship between `Lynn` and `Wendy` is `love`. The Attribute or Characterization of their relationship is thus `love`. Values are the object of the relationship. The Values may be either internal or external. For example, if `Lynn` has the Attribute of `love` and `Lynn` loves `Wendy`, then `Wendy` is the Value of the relationship characterized by the Attribute of `love`.

This relationship is formed in a record where the concept is `Lynn`; where the Characterization portion of the relationship contains the reference number of the record representing `love` and the Value portion of the relationship either contains `Wendy` or a reference to the record storing `Wendy` as a concept.

Internal Values will typically be comprised of: 1) a reference number of the concept that is the object of the relationship; and 2) a reciprocal Characterization that is the reference number of the concept that characterizes the relationship from the point of view of the object concept.

External Values will typically be comprised of data types other than reference numbers. In some applications, a mixture of internal and external Values may be desired. These mixed values also may be accommodated under the provisions this invention.

In all real embodiments, some concepts will be external to the knowledge representation. Such concepts will be known by name only. The name of the external concept will be meaningful to a human user, but the relationships maintained by name concept will be unknown to the knowledge representation. External values will be stored as some standard data type. For example if `color` is the Characterization and the Value is of external concept `blue` then the ASCII characters `blue` would be stored as the value.

Internal relationships are, in general, reciprocal, meaning that if A is related to B then B is also related to A. It is typically useful to record this reciprocal Characterization within the reciprocal relationships because in many cases the characterizations are different. The reciprocal relationship is the characterization within the object concept which is the characterization of the relationship whose object is the source concept.

For example, if `Lynn` and `Wendy` are both internal concepts and, if `Lynn's` relationship with `Wendy` is characterized by `wife` and `Wendy's` relationship with `Lynn` is characterized by `husband`, then `husband` is the reciprocal characterization for `Lynn's` relationship with `Wendy`. Storing `husband` as the reciprocal characterization within the relationship characterized by `wife` will provide important information concerning the relationship between `Lynn` and `Wendy`. Similarly, `wife` is a reciprocal characterization for `Wendy's` relationship with `Lynn`. Note that the record reference numbers of `wife` and `husband` would be stored in the `Wendy` and `Lynn` records.

FIG. 5 illustrates that references in values of reciprocal relationships must correlate. (5a) and (5b) represent Attribute concepts used in characterizing the relationships between (5c) and (5d) which represent related concepts. The dots illustrate the record. Below each dot a name for the concept and the record reference number (the reference numbers are always preceded by.about.(tilde) in the illustrations) are shown. Arrows between the dots illustrate the references between the records. Items (5e) and (5f) illustrate the relationships which would be stored in the records representing (5c) and (5d) respectively. Item (5e) is comprised of a (5g) characterization of the relationship which stores the reference number of (5a), and the internal (5h) value structure which is comprised of the reference number of the attribute of (5b) and the reference number of the concept (5d) which it is connected to. Item (5f) has the reciprocal structure with a val referencing (5a) and (5c).

FIG. 6 illustrates the organization of the Knowledge Representation Database. The system concepts of (6a) Properties, (6b) Strata, and (6c) Attribute Classes, fundamental relationships of Intrastratum, (6g) Taxonomy, (6h) Composition and (6i) Interstrata, and (6f) relationship characterizations provide the essential large scale structures for the knowledge representation. A result of the system concepts and the fundamental relationships is that the knowledge representation has a structure that may be visualized as a tree structured hierarchy.

This is clear if the attribute characterizations and the type relationships are suppressed and examples of (6e) User Concepts are provided in FIG. 7. Note that the interstrata relationships in the tree structured hierarchies of FIG. 7 have specific meanings: the organizing principle of the Attribute and Component strata can be thought of as (7a) taxonomy (i.e. Class and Subclass); while the organizing principle of the Project stratum can be thought of as (7b) composition (i.e. structure and substructure).

FIG. 8 summarizes the occurrence of the fundamental relationships in the records of each of the four typical levels of abstraction. The level of abstraction system concepts characterize which of the relationships are present in the records of each library. There are two types of cross references between levels of abstraction: reciprocal relationships between concepts of different levels of abstraction (interstrata relationships); and the relationship characterization reference numbers always belong to a level of abstraction higher than the level of the concept storing the relationship. This means that the characterizations of Attribute relationships reference only Attribute Properties, and the characterization of relationships of components and propagations reference Attributes.

The use of reciprocal relationships in the fundamental relationships enables traversal through the network in either direction. This enables queries based on an objects Class or Subclass, Structure, or Substructure, Type, or Instances. In some implementations of the invention, the reciprocal relationships will not be expressed (e.g. a concept may have a class but it is not referred to as a subclass). However, this will seriously reduce the effectiveness of the Knowledge Representation Database and eliminate some important properties of the Natural Language Interface and the Plurality of views which may be implemented for the Knowledge Representation.

The intrastratum and interstrata relationships are called fundamental relationships herein. The intrastratum relationship is required for all strata. The interstrata relationship is required for all propagations.

System concepts are those concepts which the programmed (code) portion of the system recognizes and requires in order to interpret the knowledge network. System concepts represent code defined interpretation in the knowledge network. All other concepts are user concepts. References to system concepts in the network are, in effect references to code interpretation. The code embodying the meaning of system concepts is distributed throughout the program portion of the system since these concepts have system wide implications.

FIG. 9 is an adaptation of FIG. 7 designed to highlight the system concepts included in FIG. 7. These are examples of system concept included in the referred embodiment. FIG. 9 also indicates the intrastratum organization of these concepts as a tree structured diagram and associates examples of typical user concepts. There are three classes of system concepts which are recommended for any embodiment of the Knowledge Representation (see FIG. 3): Attribute Properties, Strata of Abstraction, and Attribute Classes. Each of these classes of system concepts are comprised of a plurality of individual concepts which are recognized by the programmed code in order to interpret the meaning of the knowledge network. All Attribute property concepts are system concepts in that they comprise the highest level of abstraction and are the basis for the definition of all lower strata. The Attribute Properties must be implemented as system concepts in any embodiment of the invention. The levels of abstraction system concepts define which of characteristic types of fundamental relationships apply to the concepts on each level of abstraction. System concepts embody the notion of the inter and intra strata relationships appropriate to each strata. There are four strata which will always be present: Attribute Properties, Attribute, Component, and Project (or equivalent propagation of components.)

The Attribute Class system concepts define which attribute properties will characterize the relationships of the descendants thereof. The descendants of the Attribute Classes are user defined attributes which characterize user defined relationships. Attribute classes could be defined by means of a plurality of relationships characterized by Attribute Properties. It is simpler and more convenient to explicitly identify the Attribute class concept as system concepts and embody system definition of the class behavior.

There are four characteristic levels of abstraction which are typical of knowledge and which are included as examples in the preferred embodiment and comprise the basis for the subsequent discussion. The concept of the invention comprises extension to additional strata and to pluralities of related strata within each type. Subsequent discussion will focus on the four examples in order to achieve an economy of exposition. The four strata are summarized in FIG. 8 as being comprised of 1) properties; 2) attributes; 3) components; and 4) propagations (or projects). FIG. 8 summarizes the strata characteristics. Column A identifies each of the four strata. Column B provides a brief description of the strata in terms of the function of concepts in each strata within the knowledge representation. Column C identifies the intrastratum connectivity in terms of the significance of relationship used to connect all of concepts on a particular stratum. Column D of FIG. 8 shows the stratum used in the characterization of relationship for each of the stratum. And Column E shows the interstrata relationships maintained at each stratum.

The Attribute Properties are the most abstract level of knowledge represented in a knowledge representation. Properties are the concepts characterizing relationships required to define attributes. They can be thought of as the attributes of attributes in that they are the only class of concepts used as characterizations within the relationships of concepts comprising the attribute strata.

FIG. 10 summarizes some typical useful Attribute The Attribute Properties comprise an unbounded set, which can be augmented as desired. Many useful Attribute Properties can be defined to achieve specific design objectives.

Attributes are the class of concepts most commonly thought of as attributes of characterization of relationships. For example, love, husband, wife, height, date, time, would all be attribute concepts. Attributes are the second highest level of abstraction in that they are comprised of a multiplicity of relationships the characterization of each of the relationships is always an incomplete property.

FIG. 9 illustrates an example set of Attribute Class System concepts in the dashed box. The number of Attribute Classes can be reduced or augmented within the spirit of the invention. The Attribute Class System Concepts are organized under the Attribute Library System Concept. Useful embodiments of the invention can be implemented using only one or two classes.

FIG. 11 summarizes typical Attribute Classes which have been found useful and most of which are included in the code set forth in the appendix. These Attribute Classes are provided as a suggestion to a system designer implementing the invention. The Attribute Classes comprise an unbounded set which may be augmented as desired. Many useful Attribute Classes can be defined to achieve specific design objectives in modeling knowledge domains.

The Attribute Classes define which characterizations of relationships apply to the user concepts of the class and limit the values that said relationships may assume. The Attribute Classes define or constrain any behaviors, properties, or values which apply to a class of user concepts. The Attribute Classes may be seen as the enabling means for user definition of concepts which can be used in the characterization of relationships maintained by Component and Project concepts.

1) Database Data Type Domains Declaration

FIG. 12 illustrates an example of a data type domain statement that enables the creation of a plurality of records and relationships therebetween for storage of the information comprising the network of information in the Knowledge Representation Database. The record structures and substructures are used by the program to interpret the information stored in the records and substructures.

The domain statement is generally common to all records comprising the Knowledge Representation Database. However, derivative embodiments may include different record structures, depending on the library or class. The domain statement of FIG. 12 is based on PROLOG language conventions, and can easily be adapted to the programming environment of choice.

The data domain statement for the records is preferred for storing information in the Knowledge Representation Database. The specific characteristics of the domain statements disclosed herein are unique to the invention and constitute a significant contribution to the state of the art. FIG. 12 illustrates optimizations for representing the fundamental relationships and for representing attribute properties in the database records. Both of these optimizations will be discussed in following subsections.

The discussion of the optimizations provides a convenient forum for discussing the principles of concept representation which are employed in the invention. In database domain declaration, the constituents must be declared prior to declaring the whole. In FIG. 12, the whole is the concept declaration (12r), which is the statement of the record structure.

A "Concept" is represented as a complex record structure comprised of a Name (12a), Parents (12a), Children (12a), Interstrata (12q), and a Relationship List (12n). The Name is the name of the represented concept. The fundamental relationships are embodied in the list of parents, children, and interstrata. The Relationship List stores the relationships maintained by the record. The order of these constituents within the record structure is arbitrary.

The data type declaration (or equivalent implementations) illustrated in the example of FIG. 12 will assure functional implementation of the invention. There are numerous acceptable variants for the declarations which can be implemented to optimize system performance (several of which are implemented in the embodiment included in the appendix). However, the key features of the domains declaration of FIG. 12 will persist in derivative works.

The Name is the designator for the Concept, and is usually a data string although other data types may be included as appropriate. Note that the segregation of the name is for convenience only. The name is also stored as an external value in the relationship list without appearing as a separate item in the declaration of the Concept.

The Characterization (12b) is a reference number of a related Concept represented in the Knowledge Representation Database. The Characterization always references either a Concept in the Attribute Library or a Concept in the Properties of Attributes Library. Properties of attributes characterize only the relationships of Attribute concepts. Attribute concepts characterize all other relationships.

The Value (12g) is a qualitative indicia related to a relationship. Value is always either a reference number to a concept or concepts in the Knowledge Representation Database, to concepts external to the knowledge representation, or to a combination of both internal and external concepts. Internal Values (20c) are a class of Values containing only reference numbers of records in the Knowledge Representation Database. The form of Internal Values illustrated is comprised of two reference numbers. One of the reference numbers identifies the Concept record related to, while the second reference number identifies the characterization of the reciprocal relationship. The statement of Internal Values shown is the most common and characteristic type of Internal Value used in the Knowledge Representation Database, however, numerous additional structures derivative of the principles disclosed herein may be implemented at the system designer's discretion.

External Values (12d) are a class of values which contain no reference numbers since they reference external concepts not represented as records in the Knowledge Representation Database. External values typically consist of standard data types of information. Since the domain declaration for values is complex in this invention, the standard domains must be embedded in a complex declaration which will provide structural cues to the data type of the external concept.

A Val (12e) is either an Internal or External Value. It is an intermediate structure used to define Mixed Values (12f). Mixed Values are a class of values containing both reference numbers and standard data types. The Mixed Values can most easily be represented as a list of (12e) Vals. The notation "Val*" is a PROLOG notation signifying a list of Vals. The "*" indicates a list. This notation is similar to notation in many other languages and is used subsequently herein.

(12h) through (12k) are declarations of the standard data type for the attribute properties of Prompt, Data.sub.-- type, Field.sub.-- Length, and Location. This is an optimization of the implementation of Attribute Properties that will be subsequently discussed. Properties (12l) declares the properties structure to consist of: (12h) Prompt, (12i) Data.sub.-- type, (12j) Field.sub.-- length, and (12k) Location. The order of these elements within the structure is arbitrary. Relationship (12m) allows (12l) Properties as an acceptable relationship. (12m) Relationships are a complex data type associating a (12b) characterization, which is a reference number of an attribute or property characterizing the relationship, with a (12g) Value. The reason for this structure is that each relationship has a characterization or attribute and a value or qualitative measure of the relationship. The (12b) characterization in the relationship is the source of the relationship characterization (d) illustrated in go FIG. 8.

All concepts may have an unlimited number of relationships; therefore a (12n) Relationship List provides a structure for enumerating the relationships maintained by a record, as a list of relationships. The (12n) Relationship List structure must allow for the dynamic inclusion of relationships. This dynamic inclusion is a property of the development system and one of the reasons that the development environment should not restrict the record length.

The (12o) parents, (12p) children, and (12q) interstrata, are lists of reference numbers used to store the fundamental relationships of the Concept record. The (12o) Parents are used to store the reference numbers indicating the hierarchical progenitor within the abstraction stratum. The (12p) children are used to store the reference numbers indicating the hierarchical descendants within the abstraction stratum. The (12q) Interstrata is used to store either the Type classification or the Type instances of a concept.

FIG. 12 indicates only (12o) Parents, (12p) Children, and (12q) Interstrata, each of which is a reference list, instead of six relationships of the form of (12m). This variation is the optimization of the Representation of Fundamental Relationships the reasons for which are hereafter presented. The reason that the declarations are implemented as a reference list with no characterization is explained in detail in the following discussion.

Optimization of Means for Representing Fundamental Relationships

There are two classes of fundamental relationships which are used to assure network connectivity: intrastratum (intralevel) and interstrata (interlevel), as discussed previously. Each class of fundamental relationships is comprised of reciprocal relationships, so there should be four relationships of the type represented in the form of (12m) relationships, which should be part of the (12n) Relationships List.

The optimization included in FIG. 12 enhances the operating speed of the system by: 1) segregating the fundamental relationships from the (12n) Relationship List; 2) eliminating the direct characterization in the fundamental relationships; and 3) explicitly allowing for a list of record reference numbers by declaring the domain as ref* (i.e. reference number list).

The segregation of these fundamental relationships allows the programming functions requiring these relationships to "grab" a relationship from a record based on the structural cue of the segregation instead of extracting the relationship from the (12n) Relationship List. The reduction from four relationships to three is accomplished by recognizing that the interstrata relationship is not expressed as a reciprocal in any single record because it is a relationship between a project and component record (i.e. the component has an instance relationship with the project record and the project record has a classification (or Type) relationship with the component record) therefore a specific record never has both Type and instance so only one structure for the interstrata relationship need be present in any record.

These segregated relationships could be represented with the structure indicated for (12m) relationships in FIG. 12. However, this would provide redundant information since both the characterization reference to an Attribute Library system concept and the structure imposed by the segregation would provide cues for the meaning of the relationships. Such redundancy takes more space in the database and requires more record reading in that each (12b) characterization would need to be read.

By relying only upon the structural cues provided by the segregation we eliminate the characterization, and the relationships can be simplified to a reference list (ref*) as indicated in FIG. 12 for (12o) Parents, (12p) Children, and (12q) interstrata. The use of the reference list instead of just a reference number enables the possibility of multiple relations of the segregated types. A consequence of this optimization is that the system concepts for the characterization of fundamental relationships do not need to be present in the Knowledge Representation since the structure of the record now cues the characterization of the relationship. The programmed code will use the structure for the characterization instead. In a particular embodiment the designer is free to provide additional segregation to distinguish particularly significant relationships; the presence or absence of such segregation is merely an adaptation of the invention. In a specific embodiment, the designer is free to use structural cues to eliminate representing some system concepts as records in the (3a) Knowledge Representation Database.

Optimization of Means for Representing Attribute Properties

The domains declaration illustrated FIG. 12 includes an optimization that allows structural representation of the basic attribute properties. The optimization has been implemented whereby standard Attribute Property system concepts are consolidated into a unique structure thereby eliminating the need for explicit representation of said Attribute Properties as records in the Knowledge Representation Database. This optimization is similar to that illustrated previously wherein the need for explicit representation of the characterization of the fundamental relationships as attribute records in the Knowledge Representation Database was eliminated by segregating the relationships to uniquely defined structures. This optimization is possible because so few attribute properties are essential (in this illustration only four) to successful systems. This optimization is suitable for many implementations of the system, in that useful knowledge representations can be constructed with very few Attribute Properties present as system concepts. Note that even if additional Attribute Property system concepts are added, this optimization would still be applicable and would merely be supplemented by suitable modification to the (12l) properties declaration or representing the additional attribute properties as system concepts for use as (12b) characterizations in (12m) relationships.

Notes on Additional Optimizations for Domains Declaration

Some of the additional optimizations include implementing: security; history logging (date and time stamping of last modification to record); explicit library identification within the record instead of implicitly through the network; and segregated identification of the characterization of the name of the record. Most of these optimizations are included in the preferred embodiment. They are not considered essential to the invention and therefor no claims are made with respect to these optimizations. They are representative of optimizations and extensions that will be present in any derivative embodiment of the principles of the invention.

Programmed Code Recognition of System Concepts

The programmed code of the invention uses the System Concepts and Fundamental Relationships in order to interpret the significance of the network. The System Concepts and Fundamental Relationships provide the cues for the interpretation of the network as a whole. The programmed code recognition of System Concepts is comprised of two procedures: steps for designating system concepts; and steps for recognizing a system concept. Both of these must be implemented by the system designer. The essence of the code for designating system concepts is to create a distinction for system concepts (as opposed to external or extrinsic concepts) whereby either the name or the reference number of all system concepts can be readily identified. Such code will readily be implementable by a skilled practitioner.

The preferred embodiment uses three procedures for designating system concepts. These three procedures are redundant, and illustrate the range of possible implementations. Any one of the procedures would be sufficient. The three procedures are: 1) to designate system concepts by means of a supplementary index of reference numbers and names of system concepts; 2) to use an internal database to designate system concepts wherein the system concept reference numbers and names are provided to the internal database at system start-up; and 3) to include a supplementary structure in the record statements whereby system concepts are designated.

FIG. 13 illustrates a Flow Diagram For Recognition of System Concepts. Two procedures are illustrated: 1) (13a) through (13d) illustrate steps for recognizing a concept as a system concept; 2) (13e) through (13h) illustrate steps for recognizing a concept as a specific system concept. Each of these procedures are used within the program to utilize system concepts in interpreting the network. Steps (13a) through (13d) illustrate programmed procedures for recognizing a concept as a system concept. The result of these steps will either be an outcome of (13c) No or (13d) Yes. The essence of this procedure is to test whether either the (13a) Name is distinguished for a system concept or the (13b) Reference Number is distinguished for a system concept. The input to step (13a) is either the name, the reference number, or both the name and the reference number of a concept record to be tested. Step (13a) then compares the name with all names of predesignated system concepts to determine if the name is that of a system concept. The program determines that the concept record is a system concept if either the name or the reference number has been designated as identifying a system concept. Note that the name of a concept is often ambiguous in that it is possible for several concepts to have the same name. The only unambiguous test is based on the reference number of the record, which is always unique. If the reference number is furnished at step (13a) then the test at step (13a) should fail (NO) so that the reference number can be tested instead of the name in Step (13b). This will eliminate the ambiguity inherent in testing only the name. If the name is recognized as a system concept in step (13a), then the (13d) outcome is "YES". If the name is not recognized as a system concept in step (13a) or a reference number was furnished to step (13a), then the (25a) outcome is "NO".

Step (13b) compares the reference number with all reference numbers of designated system concepts to determine if the reference number is that of a system concept. If the reference number is recognized as a system concept in step (13b) then the (13d) outcome is "YES". If the reference number is not recognized as a system concept in step (13b) then the (13c) outcome is "NO".

The second procedure shown in FIG. 13 determines whether a particular concept is a specific system concept. This procedure comprises steps (13e) through (13h). The input to step (13e) must be the reference number of the current concept to be identified. Step (13e) gets the reference number of the specific system concept record to be identified. The specific system concept to be identified must be programmed into the section of code either as the name or the reference number of a system concept. The reference number is obtained from the procedure for designating system concepts as explained above. Step (13f) then compares the current concept reference number with the system concept reference number. If the reference numbers are the same then the (13h) outcome is "YES". If the reference numbers are different then the (13g) outcome is "NO".

Assuring that System Concepts are Inviolate

The system concepts must be protected from the effects of inappropriate Record Operations. The Input Operations protect the system concepts by prohibiting any modification to the information in the structure of records designated as representing system concepts.

System concepts can be designated as such through many possible methods. The essential requirement is only that system concepts be distinguished from user concepts in a readily determinable fashion. Suitable methods for distinguishing system concepts from user concepts include: prefacing the name with an extended ASCII sequence; adding a designator within the record structure; adding a designator within the index files; and maintaining a separate file containing an index or list of system concepts. In the preferred embodiment, system concepts are designated within the record structure.

FIG. 14 illustrates program steps for assuring that all system concepts are maintained as inviolate in the system. The steps must be implemented as a preface to each operation which potentially could improperly modify a system concept.

Operations which modify a record that are unacceptable for system concepts records are functions which will either: delete the record; change the name of the record; change the Parents reference; change the Type; and change the Relationship List. Whenever a call to these input operations is made (step 14a) the steps of FIG. 14 must be invoked. Each call to a modifying operation must immediately test to see if the target record of the input operation is a system concept (step 14b). This can be accomplished by steps (13a) through (13d) in FIG. 13. If the target record is not a system concept, then the inputted modifying operation proceeds (step 14d). If the target record is a system concept a message is displayed to the user explaining that the requested operation can not be performed on a system concept (step 14c), followed by an exit of the called operation (step 14e).

A variation of this procedure that may be useful in some situations is to apply the test to a procedure that assembles a list of input operations which are applicable to a particular record so that the unacceptable operations are never presented as options to the user.

In the preferred embodiment both the steps illustrated in FIG. 14 and the above-described variation are used to provide redundancy for protecting the system concepts as inviolate.

Use of System Concepts to Characterize Relationships

According to another embodiment of the invention, relationship-defining system concepts are provided to define relationships between concept records in the various libraries. These system concepts can particularly be used to characterize relationships between concept records in the Attribute and Component libraries or, between concept records within the Component library. The use of such system concepts also enables relationships to be formed between Project concept records and Component library concepts where the Value of the relationship is the Component concept.

More generally, the use of such relationship-defining system concepts allows additional types of relationships to be defined between levels of abstraction in the knowledge representation database. An important consequence of the above is that it eliminates the need to store relationships with values that contain any data other than unique record reference numbers. This increases the language independence of the means for knowledge representation, in that the records comprising the knowledge representation should contain no data other than unique record reference numbers.

By following the principles disclosed herein and extending the disclosed methods to additional knowledge domains, it is possible to eliminate the storage of all data types except unique reference numbers in all records of the knowledge representation, excepting only those records representing knowledge of language.

This principle can readily be extended to accommodate relationships between attributes, other classes of knowledge, and project records as the knowledge representation database is expanded to accommodate these additional classes of knowledge. Other classes of knowledge could include knowledge domains such as Spatial, Temporal, Goals, Procedures, etc. These additional types of knowledge would be used in a manner analogous to the use of component concepts as disclosed herein. These additional types of knowledge are analogous in that each instance of the knowledge will have a class, very similar to the class/subclass relationship typical of the primary relationship of the Component library.

For the illustrative purpose of explaining this embodiment, the relationships between the Attribute, Component, and Project records will be used as specific examples. However, generalization to other classes of knowledge is a straightforward extension of the invention that will readily occur to the skilled practitioner.

Note that all attributes have, in principle, potential values. The potential values can be project concepts, component concepts, or other concepts such as Spatial, Temporal, Goals, etc. The extent to which the principles of this invention are applied to all attributes is a design decision that is up to the skilled practitioner.

FIG. 71 illustrates the enhancements to the structure of knowledge representation according to this embodiment and identifies the typical relationships wherein Component concepts are used as Values in the relationship designation. According to the first embodiment discussed above, the knowledge representation was defined by representing (73a) System concepts, (73b) Attributes, (73c) Components, (73d) Project instances, and (73h) Languages, together with the fundamental relationships and the intrastrata relationships comprising the knowledge network, as individual records in the knowledge representation database, each having its own unique reference number.

The present embodiment provides means for representing new types of interstrata relationships between (73b) Attributes and (73c) Components, and between (73c) Components and (73d) Project instances. According to this embodiment, a new system concept known as "potential value" is defined and provided as a record having a unique record reference number in the knowledge representation database. The potential value system concept characterizes a relationship of one concept record as constituting a "potential value" of another concept record in which the unique record reference number of the potential value concept is stored. Referring to FIG. 71, the (73e) potential value relationship between (73b) Attributes and (73c) Components provides a mechanism to store potentially suitable component values for project instantiations characterized by the Attribute for which the (73e) potential value relationship is defined. The (73g) relationship between the (73c) Components and (73d) Project instances is stored in the project instance record.

This invention also provides means for representing a new type of relationship within the (73c) Components that result in significant extensions to the (1b) Means for Pattern Recognition, Storage, and Utilization. The (73f) potential value relationship, when stored in a Component node, enables other potentially suitable Component values to be stored for Project instantiations characterized by the Attribute that is specific to the Component node in which the (73f) potential value relationship is stored.

The distinction between the (73e) and (73f) potential value relationships is that (73e) is stored in the Attribute record and may or may not include the attribute reference number in the stored relationship (since this can be inferred from the storage location), while the (73f) potential value relationship is stored in the Component record and always stores the (73b) Attribute reference number to which it pertains. The significance of the (73e) potential value relationship is that its existence in a particular Attribute record defines the (73c) Components embedded with it in that Attribute record as generally pertaining to that Attribute. In other words, the presence of the potential value unique reference number in an Attribute record indicates that the components identified by their reference numbers in the Attribute record are all "potential values" of that Attribute. The significance of the (73f) potential value relationship in a Component record is that it is defining other (73c) Components that pertain to a specific Attribute of which the specific Component in which the (73f) potential value relationship is stored also pertains. The (73h) Language concepts are not directly affected by this embodiment and will not be referred to further.

A specific example of an Attribute, various Components, and a Project instance will now be described with reference to FIG. 72 to provide a clear understanding of the functioning of the potential value relationship. In FIG. 74, specific names for each concept are each associated with a unique record reference number. The unique record reference number is preceded by a 'tilde (.about.)

The (74a) Potential Value, .about.3A, is defined as the (73a) system concept used in this example. (74b) Color, .about.3B, is defined as a (73b) Attribute. (74c) Color, .about.3C, is defined as a (73c) Component with subclasses (74i) Green, .about.3I, (74j) Black, .about.3J, (74k) Blue, .about.3K, (74l) Red, .about.3L, and (74m) Yellow, .about.3M. It is very common in human languages for two distinct concepts to have the same name as in (74b) Color, .about.3B, as an Attribute and (74c) Color, .about.3C, as a Component. One of the advantages of the means for knowledge representation is that the concepts are identified within the knowledge representation database by the unique record reference numbers, so that each concept is uniquely and distinctly identified. (74h) Apple, .about.3H, is a Component.

(74d) My Apple, .about.3D, is a specific instance of a (74h) Apple, .about.3H, defined as a component in the Component library, and its (74c) color, .about.3C, is (74m) Yellow, .about.3M. The reference number .about.3H would thus be stored in the .about.3D record. The reference number .about.3A of the system concept (74a) "Potential Value," is used to characterize the relationship between the attribute (74b) Color, .about.3B, and the component (74c) Color, .about.3C as being that the subcomponents of the component Color, .about.3C, are all "potential values" of the attribute color, .about.3B. In other words, green, black, blue, red and yellow are all possible values for the attribute of Color. The (73e) potential value relationship is stored in the element list of the attribute record (74b) Color, .about.3B. Thus, the data structure V(.about.3A, ›.about.3C!) stored within the attribute record .about.3B, signifies that the subcomponents of the record .about.3C are all potential or possible values of the attribute color, by virtue of the presence of the reference number .about.3A, denoting the system concept of "potential value."

While the system concept (74a) potential value, .about.3A, is used to characterize the (74e) and (74f) relationships in the preferred embodiment, it should be noted that the attribute (74b) Color, .about.3B, also could be used as the Characterization in either or both the (74e) and (74f) relationships, with the (74a) potential value reference number .about.3A then being stored elsewhere in the relationship data structure.

The relationship (74f) between the component (74h) Apple, .about.3H, and the specific subcomponent colors (74i) Green, .about.3I, (74l) Red, .about.3L, and (74m) Yellow, .about.3M, is also characterized by the (74a) Potential Value, .about.3A, system concept. This relationship data structure would be stored in the .about.3H component record. Note that it also includes the attribute (74b) Color reference number, .about.3B, to indicate that the relationship is colors that pertain to apples.

The (74g) relationship between the specific instance of (74d) My Apple, .about.3D, and (74m) Yellow, .about.3M, is also stored in the .about.3D project record. This stored relationship indicates that the component value of the (74b) attribute Color, .about.3B, of (74d) My Apple, .about.3D, is (74m) Yellow, .about.3M. Note that these relationships have not been indicated as reciprocal relationships in order to simplify the presentation. In general it is preferred to make the relationships reciprocal. Having reciprocal relationships would, for example, enable quick identification of all project instances that are Yellow, .about.3M, or all components that have color, .about.3B, as an Attribute. Reciprocal relationships are disclosed elsewhere in this specification and their application to the current discussion will be obvious to a skilled practitioner.

The relationship between the component (74c) Color, .about.3C, and the specific colors (i.e., (74i) Green, .about.3I, (74j) Black, .about.3J, (74k) Blue, .about.3K, (74l) Red, .about.3L, and (74m) Yellow, .about.3M) can be the fundamental relationship of class and subclass that defines the taxonomical hierarchy of the Component library, or it can be a relationship characterized by some other system concept. The specific relationship is not at issue in this disclosure, as long as the relationship can be uniquely identified and used in the manner set forth herein.

As new domains of knowledge are added to the knowledge representation database, additional system concepts can be defined to identify the occurrence of concepts in these domains as values of relationships. Examples of new knowledge domains include Spatial, Temporal, and Procedural knowledge. The new system concepts thus can readily be implemented to extend the methods disclosed herein to the new domains. Note that an unbounded set of system concepts can be defined and used through means similar to those disclosed herein. The meaning and behavior of a system concept can be arbitrarily complex. The system concepts can be defined explicitly as in the current example, or structurally as disclosed in the earlier embodiment.

Relationship Data Structures

The relationship listings wherein component concepts occur as values can be stored in the same relationship data structures as were presented in the previous embodiment. Numerous appropriate refinements and variations will occur to the skilled practitioner.

The following discussion identifies those structures employed in the preferred embodiment.

FIG. 73 illustrates a relationship data structure suitable for storing the (73e) and (73f) potential value relationships within the attribute and component records, respectively. The (74f) relationship data structure of FIG. 71 is used as an example. The (75a) Characterization of the relationship may be the reference number of the (73a) system concept (i.e., the "potential value," .about.3A). The (75b) Value of the relationship will be comprised of the reference numbers of the (73b) Attribute (color, .about.3B) and the (75d) reference number(s) of the (73c) component concepts (green, .about.3I, red, .about.3L, and yellow, .about.3M).

In this example, the (75c) reference number and the (75d) reference numbers have been combined in a list structure. The defining feature is the presence of the (75a) system concept characterization, the (75c) attribute reference, and the (75d) component reference(s); specific data structures will be derivative embodiments of these essential features. Note that either the Attribute or the System Concept can be considered to be the characterization of the relationship. The important feature is that both must be present or inferred in the relationship listing. The preferred embodiment, and discussion of this disclosure, consider the system concept to be the characterization.

Remember that the (73e) potential value relationship is stored in an Attribute record and the (73f) potential value relationship is stored in a Component record. This means that the (75c) attribute reference number is identical to the reference number of the attribute record within which it is stored. Note that in (74e) the (75c) attribute is not included. In this case, the programmed means for establishing and using the potential value relationship will need to infer the (75c) attribute from the record in which the relationship is located. Means for accomplishing this will readily occur to a skilled practitioner. All subsequent discussion will be based on the structure as illustrated in FIG. 73 since this provides the most general case and all variations will be derivative and functionally equivalent embodiments.

Means for Editing Relationships with Component Values

There are two essential edit operations for all relationships: add and remove. The relationships that refer to Component concepts in the Value of the relationship, are relationships in all senses previously disclosed and are subject to the same principles in editing. The following discussion provides a quick overview of the edit operations to aid in the understanding of this embodiment of the invention and as a guide to program development.

FIG. 74 illustrates a suitable flow diagram for editing relationships with Component concept records as values. Adding values is comprised of steps (76a), (76d), and (76f). Removing values is comprised of steps (76b), (76e), and (76f). Step (76c) allows for a plurality of additional editing options that the developer can design and include to meet specific objectives. Steps (76a) and (76b) are tests to determine which edit operation is desired. Similar tests will be included for each of the plurality of (76c) additional edit options. Often, the naming of the operation will comprise the test such that the option will be called by name. Other means of determining the desired edit operation will readily occur to the skilled practitioner.

Step (76d) asks the user to specify which class or classes are to be added to the relationship value. This selection will typically occur from a set of choices displayed in a menu or other appropriate view. The choice set will be comprised of the members of the Component library or some subset thereof. The user interface can be accomplished by displaying the classes in an appropriate user interface, such as a CRT, in a format that facilitates user selection such as a menu, pallet, tree, table, or other suitable display. The user interface is to include means for enabling the user to identify a subset of the choice set as the selection set and return the selection set for further processing.

Step (76e) is similar to step (76d) except that the choice set is the set of values currently comprising the value of the relationship. The choice set would be similar to the (4c) values where the names of the referenced records or other suitable icon for the referenced records would be used for the user interface as the choice set. The selection set that is passed forward for further processing is then the subset of the options not identified for removal by the user.

Step (76f) stores the relationship by creating a relationship data structure as discussed in connection with the illustrated means of FIG. 73 and storing that relationship in the appropriate record. FIG. 75 provides an expansion of the means comprising this step.

Means for Storing Relationships

FIG. 75 illustrates a suitable flow diagram for the steps comprising storing the relationships. Variations on this flow diagram will readily occur to a skilled practitioner upon review of the preferred embodiment and the particular requirements of the application.

Step (77a) checks to see if the (75b) attribute already has a relationship defined for it that is stored at the attribute. Step (77b) verifies that the proposed (75c) class list for the value is a subset of the values stored at the Attribute. If either Steps (77a) or (77b) fail, then the implication is that the values in the list to be stored may be more general than the existing set for the Attribute. Since the attribute is to store the most general set of relevant classes, Steps (77g) through (77i) are designed to infer additional class values to describe the most general case and store the inferred set at the attribute after user confirmation.

Step (77c) gets the relationship source record reference number. This will always be the Attribute unless a relationship has been stored at the component record. The source is subsequently used for deciding where to store the new relationship. Step (77d) gets the current active record reference number. The active is subsequently used for deciding where to store the new relationship. Step (77e) tests that the active is the Attribute. If this is the case, the relationship replaces the existing relationship in the element list of the Attribute record. The relationship is thus (77f) stored in the Attribute record.

Step (77j) stores the relationship in the component record. Storing the relationship replaces any existing relationship in the element list of the Component record that has the same characterization as the new relationship, with the new relationship. Step (77g) infers higher level class values from the values in the relationship. This can be accomplished by considering the list to be comprised of subclasses. The inference is simply the process of finding the implied common class. For example, if the relationship of (74f) was being saved, the implied class is (74c) color, .about.3C, which would be inferred as the class value, that upon user confirmation in step (77h), would be (77i) stored at the attribute record as the (74e) relationship.

Step (77h) allows user confirmation by telling the user the inferred class and asking to verify. If the user does not like the inference, then the original value of the relationship is passed forward to be (77i) stored at the attribute. Note that steps (77g) and (77h) provide for powerful behavior and, though part of the preferred embodiment, are optional. These steps are included for completeness and to illustrate the types of enhancements that can readily be incorporated in the invention. Additional similar enhancements will readily occur to a skilled practitioner based on this example and associated disclosed means.

Step (77i) stores the relationship in the attribute record. Storing replaces any existing relationship in the element list of the attribute record having the same characterization as the new relationship, with the new relationship. Note that steps (77f), (77i), and (77j) all store the relationship list in a record; in fact step (77i) and (77f) are the same process. In the preferred embodiment, these three steps are coded as the same routine where the record reference number of the record to store the relationship in is passed to the routine with the relationship.

Using Relationships with Component concepts as Values

A potential value relationship is established by means of a relationship stored in an Attribute or Component record wherein the value of the relationship is comprised of at least one reference number of a component record. The meaning of the relationship is, typically, that the subcomponents of the component are potential values of the attribute.

Attributes are used to characterize relationships stored in records other than attribute records. The type of concept suitable for the value of the relationship will be characteristic of the attribute (for example, some attributes characterize relationships between project concepts while others characterize relationships between project and component nodes.) The type of concept suitable for the value of a relationship characterized by a specific attribute can be designated as a property of the attribute or of an attribute class, by storing a system concept designating the type in the attribute or attribute class records. Since the attribute class is a system concept, the designation can be implemented as part of the system definition of the attribute class.

If the designation is implemented as a system concept stored in the attribute record, then the system concept can be used as the characterization of the relationship storing the record reference number(s) of the specific relevant values. If the designation is implemented as a property of the attribute class(es), then the means for storing the reference number(s) of the relevant values must be implemented either by structural characterization in the structural declaration of the attribute records, or by means of a separate system concept to provide the characterization for a relationship. Note that any system concept can be embodied by structural cues as well as explicit definition. The preferred embodiment uses a system concept stored at the attribute record as the characterization of the relationship storing the record reference number(s) of the specific relevant values, as shown in FIG. 75.

The use of a system concept stored at the attribute record is preferred because the system concept can serve both as the identification that component values are applicable to the attribute, and as the characterization of the relationship. The same system concept can also be used to in the relationships that may be stored in specific component records.

FIG. 76 illustrates the use of relationships with component concepts as values in creating instances of a value in a project record. In this case, said relationships are stored in Attribute or Component records. This is one of many uses of this type of relationship that will readily occur to a skilled practitioner, and illustrates the essential functions that will enable numerous derivative embodiments.

Step (78a) provides means for editing the value of a relationship for a project concept. This step includes determining that a relationship identifying component concepts as potential values is stored in the component record that is the type of the project instance, or in the attribute record for the attribute characterizing the relationship to be edited. FIG. 77 illustrates a flow chart that provides additional detail of suitable means for Step (78a).

Step (78b) provides means for user interaction so that the user can select a relevant option. The options are those stored in the potential values relationship applicable to the current attribute of the active project node. In the example of FIG. 3, when creating the project instance of (74h) Apple, .about.3H, that is (74d) My Apple, .about.3D, the display would offer options of (74i) Green, .about.3I, (74l) Red, .about.3L, and (74m) Yellow, .about.3M. The user interface can be whatever the designer believes is relevant to the values such as menus, pallets, buttons, and so forth. In the example, appropriately colored buttons might be a good choice. Such solutions will readily occur to a skilled practitioner.

Step (78c) provides means for creating the relationship data structure. The relationship data structure will be similar to that illustrated in FIG. 72 item (74g). There are a wide variety of data structures that can be embodied to incorporate the means of the invention. The essential features are that the reference number of the attribute is associated with the reference number(s) of the component node(s) that are the value of the relationship.

Step (78d) provides means for storing the relationship in the active project record. The new relationship includes the replacement of any existing relationships unless the Attribute has been associated with a system concept that indicates that it is allowed to have multiple values in project instances. These means are familiar from previous disclosure and are amply illustrated in the preferred embodiment. Step (78e) indicates the completion of the editing process for the editing of the value. Upon completion the program returns to the calling function or other control function for continuation.

Note that Step (78c) can be implemented to create the reciprocal relationship to be stored in the component record(s) referred to in the value of the created relationship to be saved at the project node. If this is desired, then Step (78d) will include the step of saving the reciprocal relationships at said component records as well as saving the created relationship at the project node. Note that Step (78b) may include edit options for user selection as part of the menu of value options. This will allow the user to dynamically edit the options. FIG. 77 illustrates an expansion of Step (78b) that allows for this option.

Step (79a) tests for the existence of a potential value relationship for the current Attribute of the active project node. If none has been defined then (79e) the program can call the (76a) Add Value edit option so that the user can select an appropriate value and store the selected value as a future option by means as illustrated in FIG. 75. The combined effect of these steps is that the system automatically learns the potential values for an attribute using the current instance as an example of applicable values. After completing the (76a) Add Value, the program (79f) resumes at Step (79b).

Step (79b) gets the value from the potential value relationship applicable to the current Attribute, and converts the reference numbers to appropriate icons for display for user selection. Icons indicating edit options can be appended to the list of options so that the user can dynamically alter the option list. Note that the icon may be as simple as the text name of the options (e.g. Green, Red, Yellow) or more sophisticated as discussed previously. Step (79c) provides means for the user to select from the displayed value and edit options. The selected option is then passed forward to step (79d) for further processing. Note that the user may select more than one option if multiple values are allowed for the Attribute for which the options are presented. This is a minor variation, the implementation of which will readily occur to the skilled practitioner.

Step (79d) tests to verify that a value option was selected. If not, then an edit option was selected, and the (79g) appropriate edit option can be called. When the edit option is completed, the program can return to Step (79f) as previously identified. Note that the user may decide that no option is wanted, in which case an escape option must be defined; handling this case will readily occur to a skilled practitioner.

Value Clustering

One of the consequences of this embodiment that will readily occur to a skilled practitioner is value clustering. Value clustering is achieved as potential value relationships are implemented for a variety of attributes and components, and is in effect the cumulative interaction of multiple potential value relationships. Value clustering can be implemented by means similar to the inheritance schemes previously disclosed.

Value Clustering is the global effect of this embodiment resulting from linking potential values wherein one value implies others. This, in effect, allows the selection of one value to modify the selection set applicable to others. In some cases the selection set can be reduced to a single member which can automatically be instantiated as the default value of the relationship. For example, Country Code, Area Code, Prefix Number, Cities, States, Country, and Zip Codes are all related based on political entities. Knowing any one of these implies at least a small subset of possible relevance in the others, and often fully constrains the others.

More specifically, if Washington is the value of State then the Country is United States of America, the country code is always 01, and the Area Code is either 206 or 509. In addition, the Cities in Washington are a small subset of all cities, and the Prefix Numbers associated with the telephone interchanges are a very small subset of all Prefix Numbers. Value Clustering enables behaviors that exploit the interrelationship of values, so that data input time is minimized, and so that deeper knowledge of interrelationships is maintained. Note that in a practical system, the system implementor may choose to predefine significant value linking as a feature of the basic knowledge network. This a priori implementation is within the spirit of the invention and may readily occur through translation of structured digital resources into the knowledge network, or by manual entry of the relevant concepts and relationships.

Notions such as the structure of telephone numbers (e.g. Country Code, Area Code, Prefix, Number) and the values associated with this structure, color, political entities (country, states, county, city, etc), are typical of the types of values definable a priori.

(3b) Record Operations

The Record Operations (FIG. 3b) are basic operations for interaction with the records of the Knowledge Representation Database. Record operations are comprised of: Input operations (3c) whereby records or record declarations within records are created or replaced in the Knowledge Representation Database; and Output operations (3d) whereby records or record declarations within records in the Knowledge Representation Database are read out and reported to the user.

The Record Operations are implemented to handle the information contained within the structures of individual records in the Knowledge Representation Database. As such the significance of the structure of the records (name, relationships, etc.) must be programmed into the Record Operations.

The significance of the network structure of the Knowledge Representation Database is contained in the higher level functions of the Network Operations (3e), the Concept Editor and the Relationship Editor (3i), each of which uses the Record Operations as basic functions for the implementation of network-related functions.

(3e) Network Operations

The Network Operations (3e) comprise a plurality of steps for interaction with the network structure of the Knowledge Representation Database as embedded within the individual records constituting the Database. Network Operations are comprised of a plurality of functions which are programmed with an understanding of the network, together with two major classes of functions comprised of Save operations (3f) whereby information stored in the Descriptive Database is saved in the network of records of the Knowledge Representation Database, and Read operations (3g) whereby a portion of the network of the Knowledge Representation Database is translated into the Descriptive Database. The Network Operations do not understand the record structure of the database in that all interactions with the records of the Knowledge Representation Database are conducted through the Record Operations. The Network operation procedures coordinate sequences of Record Operations, which sequences comprise network operations. The network resides in the relationships between a plurality of related records in the Database as found from the cross-reference record numbers embedded therein. The programmed sequence of Record Operations which defines Network Operations embodies the understanding of the network structure.

Many of the programmed functions for interpretation of the network have a characteristic of traversing some class or classes of relationships between concepts and assembling information about the concepts in the traverse path.

FIG. 15 illustrates a flow diagram of programmed means for assembling an ancestors list of records constituting progenitors of an individual record as an example of network traversal. Step (15a) sets the next reference number equal to the active reference number. The "Active" is the current record reference number for which the ancestor list is to be derived. Step (15b) reads the Parent and Child record names from the active record. The read operation of step (15b) is one of the functions of the Record Operations. Step (15c) tests to see whether the Parent list is nil. The only record in the network for which the parent list is nil is the root record. Thus, the presence of a nil Parent list means that the ancestry of the individual record has been traced clear to the root record. Step (15d) adds the name read from the record to a name list. This name list is an output of the ancestry of the individual record. The resulting output of the ancestry tracing process will be the name list and also an ancestor list, wherein the ancestor list is comprised of the list of reference numbers of the records corresponding to the names in the name list.

Step (15e) adds the parent record reference number to the ancestor list in the case where, in step (15c), the Parent list is not nil. Step (15f) adds the name of the record being read to the name list, followed by Step (15g) which sets the next reference number equal to the parent reference number from the parent list.

The process then cycles back to step (15b), with the next reference number equal to the parent record found in the previous record's parent list. Note that the name added to the list in steps (15d) and (15f) is the name of the record being read, whereas the parent added in step (15e) is the reference number of the parent record of the record being read. Thus, although the parent reference number is added in step (15e) and the name is added in step (15f), the final parent for the root name ultimately must be added in step (15d), when there are no more parents.

(3f) Save Functions

The Save functions (3f) consists of programmed operation steps for assembling and structuring information stored in the Descriptive Database and storing the information in the appropriate records of the Knowledge Representation Database. Save is only required if the Descriptive Database is used to buffer editing operations so that these operations do not directly affect the Knowledge Representation Database, but rather are modifications to the Descriptive Database. If the Descriptive Database is used to buffer the Knowledge Representation from the editing operations, then save functions are required in order to transfer the changes made to the Descriptive Database into the Knowledge Representation Database. The transfer between databases occurs upon a user event requesting an update to the Knowledge Representation Database.

The Save operations are implemented as programmed code. Save translates the information in the Descriptive Database by applying a sequence of Record Operations required to input that information into the Knowledge Representation Database. The Save operation uses the record reference numbers of the Knowledge Representation Database which are associated with the information in the Descriptive Database to identify the record and record substructure where the updated information should be inputted.

The Descriptive Database contains information from a plurality of records of the Knowledge Representation Database, together with view document-specific icon and locational data which is not part of the Knowledge Representation Database. The Save operation saves only the relevant information in the Descriptive Database at the appropriate location in the Knowledge Representation Database.

FIG. 16 illustrates a Flow Diagram of programmed means for Saving Information Stored in the Descriptive Database by storing it in the Knowledge Representation Database. The overall structure of the procedure illustrated in FIG. 16 is to process all active concepts in the Descriptive Database by getting the next active reference number in the database and cycling through the procedure for each active concept until all active concepts have been processed.

The Descriptive Database may include a plurality of Active concepts. The "Active" will be indicated in one of the fields of each of the plurality of records in the Descriptive Database comprising the description of the Active concept.

Step (16a) identifies a reference number of an active concept record in the Descriptive Database. Step (16b) assembles all of the relationships pertaining to the Active which are stored at the active record into a Relationship.sub.-- list (see FIG. 12n). The relationships pertaining to the Active which are stored at the Active record are identified by means of the Source field (23b) in the records of the Descriptive Database.

A consequence of the procedure for Relationship Inheritance is that the only Source for relationships in the description of the Active concept (for which all relationships in the relationships list are present as corresponding records in the Descriptive Database) is the record of the Active concept. This is the reason that Save applies only to the Active record.

Step (16c) replaces the relationship list in the Active record with the relationship list assembled in Step (16b) from the Descriptive Database.

Step (16d) tests to see if any other Active concepts are in the Descriptive Database which have not yet been saved. If "YES" (16e) then cycle back to Step (16a) to get the next active record reference number. If "NO" (16f) then the save is done.

(3g) Read Functions

The Read functions (3g) reads information stored in the Knowledge Representation Database, appropriately formats the read information, and stores the formatted information in the Descriptive Database. The Descriptive Database is a working non-permanent database. The transfer of information to the Descriptive Database from the Knowledge Representation Database is made to transform the relationships in the concept records of the Knowledge Representation Database from reference numbers into descriptions of the concepts. The descriptions of the concepts facilitate the human-perceivable views, and consequent user interaction with the Knowledge Representation Database through the views.

The Read operations apply a sequence of Record Operations to output the information in a network of records of the Knowledge Representation Database, translate the information into the structures required for storage in the Descriptive Database, and store the information in the Descriptive Database. The Read operations utilize the ancestor inheritance characteristics of the network (embodied in the cross-reference record reference numbers). The Descriptive Database then stores information from a plurality of network of records of the (3a) Knowledge Representation Database. The Descriptive Database is discussed in more detail below.

Relationship inheritance is discussed subsequently as part of the disclosure of the descriptive significance of fundamental relationships. Characterization inheritance is the process of assembling the descriptive inheritance for each of the characterizations in a set of relationships.

Record Inheritance

The transformation of knowledge from the Knowledge Representation Database of the present invention to user interpretable format is based on two types of "inheritance" of record concepts by individual records, Relationship Inheritance and Characterization Inheritance.

Relationship inheritance is the processes for combining the relationship lists of the records in the descriptive network of a given concept. The resulting relationship list provide a description of said record.

Characterization Inheritance is the process for assembling the relationship inheritance for all attribute concepts.

Both types of inheritance are implemented as programmed code in the computer system comprised of a plurality of interrelated modules and subroutines. In general the code embodying Relationship Inheritance is distinct from the code embodying the Characterization inheritance.

In a specific real world embodiment of the system there will typically be a plurality of functions combining and coordinating the Relationship and Characterization inheritance procedures. This is a system design choice as specific implementations will readily occur to the skilled system designer once the principal methods of each type of inheritance are understood as hereinafter set forth.

Relationship Inheritance

The Relationship inheritance procedures code combine the Relationship Lists of a plurality of records to create a descriptive relationship list pertinent to an active concept (record). The relationship inheritance procedures embody rules for determining which relationships in the plurality are relevant and which values of the relationships have precedence over other values.

Relationship inheritance assembles the user relationships describing a specific concept from the network of concepts in the Knowledge Representation Database into the Descriptive Database. The user relationships are stored in the Relationship List of the records. The relationships are the vehicle for storing information defining the concepts in the Knowledge Representation Database. Relationship inheritance can be thought of as rules for combining the Relationship Lists in the records into a descriptive network of a specific "Active" concept. As such, the rules must define Attribute and Value inheritance.

The relationships defining the Descriptive networks for a Project concept are the fundamental relationships of Taxonomy (Class), Type (Classifcation), and Composition (Structure). Relationship inheritance applies to the reference numbers stored in the Parent (intrastratum and interstrata) references only. The Children references are irrelevant to inheritance. Useful inheritance may also occur through any of the reference numbers in the user defined internal relationships.

Taxonomy, Type and Composition are simply schemes for tying each record to all other records in a useful manner. The only essential requirement for the invention is to tie the records to each other with at least two, always-present, relationships: to a parent, and to a type definition. The result of the preferred embodiment described herein is that Taxonomy, Type and Composition tie all records to the network with relatively few relationship statements, all in a manner easily interpreted by the program.

In some senses the meaning of a concept is conveyed by the totality of the network in which it is embedded. This totality can rapidly become incomprehensibly complex, and thus the totality must be represented by a comprehensible summary description. A comprehensible description of a concept can be derived from the network by limiting the fundamental relationships which are traced out in deriving the description. In limiting the fundamental relationships, the connectedness of the network is limited so that only a small subset of the concepts can be reached from a given concept by following the paths in the specific fundamental relationships.

The reason the descriptive network is a small subset of the entire network is because the train of interstrata Parent(s) references must necessarily lead to the root record. The interstrata parent(s) only references a finite number of component records, each of which must be a classification of the active record.

FIG. 23 summarizes the types of inheritance based on the descriptive networks. Each path in the descriptive network is used to characterize a type of inheritance. In subsequent discussion, relationship inheritance based on Taxonomy (Class) will be referred to as Taxonomy inheritance, and similarly inheritance based on Type (Classification) will be referred to as Type inheritance, Composition (Structure) will be referred to as Composition inheritance, and User (Relationship) inheritance will be referred to as User inheritance.

User inheritance is based on user defined relationships instead of the fundamental relationships. User inheritance has been found particularly useful in the description of Project concepts (and in fact, tends to be limited thereto). All inheritance deals with the combination of the relationships in the Relationship List of all the records in the inheritance path defined by the cross-reference record numbers. Each relationship is comprised of a characterization and a value each of which can be inherited. The Characterization relationship and the Value relationship inherits differently for each category of inheritance. The columns of FIG. 17 summarize the inheritance of Characterization and Value for each type of inheritance on the corresponding row: "Yes" means it is inherited and "No" means it is not inherited.

The summary of applicability of the types of inheritance to the libraries indicated in columns (17d) through (17f) is self-explanatory in that if the relationship defining the inheritance path applies then the inheritance applies.

The Type inheritance for a Project record (17f) is the descriptive Relationship List of the referenced record (i.e., one record only). This is distinct in that all other categories of inheritance are for the Relationship List of all the individual records in the inheritance path.

Column (17g) identifies the inheritance path length for each category of inheritance. Both the Taxonomy and Composition paths extend to the root. The Type inheritance is always only one step deep, because of the nature of the Classification relationship. The User Relationship path length must be specified by the designer. In practice two steps is often a useful length for user inheritance.

Taxonomy inheritance is based on the logical premise that all of the relationships of a class apply to a subclass. This is true in that Classes are necessarily the genus of all of the species of subclasses belonging thereto.

Type inheritance is based on the premise that all Projects are comprised of specific occurrences of certain components. The component is the classification of the specific elements comprising the Project. The classification of an element is the generic description of the common features of all specific elements.

Composition inheritance is based on the principle that many of the values of the relationships of specific objects are properties related to the structures of which the concept is part. For example, all customers in a particular city have the same zip code, area code, county, state, congressional representative, senator, etc. because these are properties of higher level structures. Such values can be inherited by virtue of the compositional hierarchy in the Project. This embodiment of the invention uses only one fundamental relationship, the parent, in concepts that are Attributes or Components. Two fundamental relationships, parent and type, are used only the Project concepts.

FIG. 18 illustrates the concept of a descriptive network for an active Attribute record. Here, "5L" (upper left hand side of FIG. 18) is the active concept for explanation. FIG. 19 illustrates the concept of a descriptive network for an active Component record. Here, "FCV" (upper right hand side of FIG. 19) is the active concept. FIG. 20 illustrates the concept of a the descriptive network for an active Project record. Here, "FCV105" (upper right hand side of FIG. 20) is the active concept.

There are two properties of the descriptive networks illustrated in FIGS. 18 through 20 which are universal properties of all descriptive networks according to the present invention: First, the number of concepts in the network is very small; second, the paths associated with the descriptive networks lead "up the tree" and terminate at the root record (here, the root record is the record for the IMAGINE.TM. processing system of the present invention).

The types of inheritance must (summarized in FIG. 17) be applied in a specific order to assure that the correct meaning of the record is inherited. FIG. 23 provides a flow diagram of the programmed procedures for assuring that the inheritance is correctly implemented in sequence. The sequence for applying the inheritance is illustrated on the left side of FIG. 21. Each type of inheritance has a common underlying procedure which is illustrated (21b). An expansion of the procedure for inheritance is illustrated on the right side of FIG. 21 (21c). Note that the procedures are the same for each type of inheritance: the only differences lie in the tests as described below and the responses to the tests summarized in FIG. 17.

The sequence (21a) for applying the types of inheritance is recommended; however, other sequences could be implemented. Whether or not a particular category of inheritance applies to a given record is a function of the Library (i.e., attribute, component or project) to which the record belongs, as summarized in FIG. 17 items (17d), (17e), and (17f).

Note that relationship inheritance does not apply to attribute properties because they are all system (i.e. internal) concepts with nil relationship lists.

The (21b) procedure for inheritance is to read a record for which inheritance is to be assembled using the Output Record Operations. The information from the Output operation is temporarily stored in internal memory. The information includes cues to the Library to which the record pertains, to the parents, to the type, and to the relationship list of the record. Each of these are used in subsequent tests and steps in the Inheritance procedures which evaluate and apply the Relationship and Value inheritance that may be applicable to the items in the relationship list.

Inheritance is most easily implemented as a recursive process, wherein the inheritance of a record is obtained by retrieving the inheritance of its parent record. The only condition is that the record for which the inheritance is being assembled (called the "Active" record) must be passed forward or otherwise indicated in the system so that the active reference number can be recorded, since the inherited information is provided to the Descriptive Database.

The Expansion of the Procedure for inheritance provides details of the procedures for Relationship inheritance and of the procedures for Value inheritance.

At step (21d) the next record is read if the relationship list of the current record is empty. If the relationship list of the current record is not empty, the first relationship is read from the list and sent forward for relationship value inheritance.

At step (21e) it is determined whether characterization relationship inheritance is applicable to the record. The applicability of relationship inheritance is determined by evaluating the type of inheritance being evaluated as summarized in FIG. 17.

If (21e) was Yes, then check to see if a characterization relationship with the same characterization is already in the (3h) Descriptive Database for the Active node (step 21f). If not, then the relationship is added to the Descriptive Database (step 21g). If (21f) was Yes, then bypass