CA 02202867 1999-11-26
KNOWLEDGE REl?RESENTATION IN A NETWORK DATABASE SYSTEM
CROSS REFERENCE TO RELATED APPLICATION
This is a continuation-in-part of application Serial
No. 08/011,355 filed January 29, 1993, now U.S. Patent No.
5,379,366.
BACKGROUND OF THE INVENTION
This inveni~ion relates to a system for knowledge
representation :in a computer system together with Natural
Language Interface, together with the ability to
recognize, stores and use patterns in the knowledge
representation, together with computerized means for
automatically t:ransf_orming information in the knowledge
representation :into a multitude of documents or other
human interpretable displays in a plurality of different
formats or view;, 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 record; are organized into strata or levels of
abstraction by means of storing relationships to other
records within a given stratum. These relationships
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
2
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,
_0 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
_5 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
,0 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
;5 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 Interf aces (GUI). Hypertext, Object Linking
30 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 Figure
1.
A) The data-base engine referred to herein as a
"knowledge representation" system is most closely related
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
3
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 nei=work of interrelated
records. Each record is allowed to maintain an unbounded
list of relationships to other record, within the
Knowledge Representation database.
System concepts are defir_ed 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
crder 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 _evel 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
-?5 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 fcr 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
CA 02202867 1997-04-16
WO 96/12236 PCTIUS95/10077
4
patterns _n creating additional concepts and relationships
in the Knowledge Representation Database.
C) ~he Natural Language Interface (NLI) is a novel
system fcr 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
transiticnai network parser (related to an Augmented
Transitic~ 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) =he method for automatically deriving a multitude
of docume_n=s is-based on abstracting standard documents or
displays cf 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) "~he user interface integrates the principal
character_stics of GUI, Hypertext, OLE, and context
sensitive programming in a single integrated user
environme__~.t. This integration is without precedent, and
Z5 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 =ypertext idiom which typically employs user
defined lccational links between documents which operate
L~s an adji.nct to static document representation.
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
The Knowledge Representation system further utilizes
external relationships which enable t:he linking of records
in the database to file or programs external to the
Knowledge Representation Database.
5 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 Figure 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 indexes) (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
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
6
records contained in a record define the relationship of
a
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 words) 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
1
types appropriate to the knowledge domain. If
restrictions on data type and record length do exist, it
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
7
may be possible to implement "work arounds". Such work
arounds may include record chaining wind 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° PCs using
the programming language PDC Prolog° with Pharlap°
Extenders. The preferred embodiment illustrates the
adaptabi~ity of this invention to standard programming
environments.
Prolog 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 t:he essential
procedures and processes embodied in t:he invention.
However, these flow diagrams, while i7.lustrating the
~ essential procedures, must be understood as embodying a
procedural equivalent of the declarative code found in the
Prolog program.
CA 02202867 1997-04-16
WO 96/12236 PG"TIUS95110077
8
BRIEF DESCRIPTION OF TFiE 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 At~ribute
Properties;
FIG. 11 is a chart of Summary of Typical Useful At~ribute
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;
CA 02202867 1997-04-16
CVO 96/12236 PCT/US95/10077
0
FIG. 16 is a Flow Diagram o~ Programmed Means for Saving
Information Stored in the Descriptive Database by Storing
it in the Knowledge Represer_~ation Database;
FIG. 17 is a chart Summary cf the types of Relationship
Inheritance Based on the Descriptive Networks;
FIG. 16 is a logic diagram _llustration of concepts in the
descriptive network of an attribute record;
FIG. 19 is a logic diagram ~_lustration of concepts in the
descriptive network of a cocrponent record;
FIG. 20 is a logic diagram _=lustration of concepts in the
descriptive network of a prcject record;
FIG. 21 is a Flow Diagram of Programmed Means for
Implementing Relationship Ire eritance;
FIG. 22 is a Flow Diagram of Programmed Means for
IS Implementing Characterizaticn 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 List of a Record;
FIG. 26 is a Flow Diagram of Programmed Means for
Instituting the Value of an =eternal 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 i.n 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 t'_:e Knowled.ge Representation;
rFIG. 32 is not used;
CA 02202867 1997-04-16
WO 96/12236 PGTIUS95I10077
FIG. 33 is not used;
FIG. 34 is a Flow Diagram of Programmed Means for Natural
Language Processing;
FIG. 35 is a Flow Diagram of Programmed Means for
5 Augmented Transition Network Parse;
FIG. 36 is a Database Declaration for NLI Functional
Identi=ication Used in Augmented Transition Network Parse;
FIG. 37 is a chart Summary of Suggestions for System
Concepts and Associated User Concepts to add to the
10 Knowlenge Representation Database for NLI;
FIG. 38 is a Flow Diagram of Programmed Means for Parse by
Differences;
FIG. 39 is a chart showing Examples of Views, Classes, and
Types Comprising a Plurality of Views of the Knowledge
Representation;
FIG. 40 is a Flow Diagram of Programmed Means for View
Management;
FIG. 41 is a chart Domain Declaration for Tracking Active;
FIG. 42 is a Flow Diagram of Programmed Means for Deriving
a Plurality of Documents of the Knowledge Representation;
FIG. 43 is a chart Summary of Correlation Between View
Derivation Step and Level of View Document Abstraction;
FIG. ,44 is a Flow Diagram of Programmed Means For Deriving
A Plurality of Views of the Knowledge Representation;
FIG. 45 is a Flow Diagram of Programmed Means For Deriving
a Plurality of Schematic Classes of the Knowledge
Representation;
FI3. 46 is a Flow Diagram of Programmed Means For Deriving
. a Plurality of Types of Schematic Cluster Diagrams of the
knowledge Representation;
FIG. 47 is a Flow Diagram of Programmed Means For Reading
Descriptive Sets;
FIG. 48 is a chart showing Examples of Defining and
Auxiliary Relationships for Various Types of Documents;
FIG. 49 is a Flow Diagram of Programmed Means For Reading
Defining Relationships;
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
11
. FIG. 50 is a Flow Diagram of Programmed Means For Reading
Auxiliary Relationships;
FIG. 51 is a Flow Diagram of Programmed Means For
Assigning Icons to a Descriptive Set;
FIG. 52 is a Flow Diagram of Programmed Means For User
Interaction with the Knowledge Representation Through the
View Documents;
FIG. 53 is a chart Summary of Icon Symbology;
FIG. 54 is a chart Summary of Symbol =nterpretation;
FIG. 55 is a Standard Decision tree for Event Processing;
FIG. 56 is a Recommended Decision Tree for Icon Symbol
Interpretation;
FIG. 57 is a Flow diagram of Programmed Means for Updating
Active Based on User Event Location;
FIG. 58 is a Flow Diagram of Programmed Means For
Highlighting Entities;
FI3. 59 is a Flow Diagram of Programmed Means For
Interpreting Icon as System Concept Associated with Icon
Entities;
FIG. 60 is a Flow Diagram of ProgrammE:d Means For
Interpreting Icon as Abstraction Associated with Icon
Entities;
FIG. 61 is a Flow Diagram of Programmed Means For
Interpreting Icon as Entity Editing Procedure;
FIG. 62 is a Flow Diagram of Programmed Means For
Interpreting Icon as Procedure for Transferring View
Derivation to Active;
FIG. 63 is a Flow Diagram of Programmed Means For Changing
View of Active;
FIG. 64 is a Flow Diagram of Programmed Means For
Interpreting Icon as Procedure for Identifying Library
System Concept of Active;
FIG. 65 is a Flow Diagram of Programmed Means For
Interpreting Icon as Abstraction Assoc:Lated with Active;
CA 02202867 1997-04-16
WO 96/12236 PC'T/US95110077
I2
FIG. 66 is a Flow Diagram of Programmed Means For .
Interpreting Icon as Procedure for Concept and
Relationship Editing;
FIG. 67 is a Flow Diagram cf Programmed Means For
Interpreting Icon as External Procedure;
FT_3. 68 is a Flow Diagram of Programmed Means For
Interpreting Icon as Ancestry Context;
FIG. 69 is a Flow Diagram of Programmed Means For
Interpreting Icon as Descendants Context;
FIG. 70 is a Flow Diagram of Programmed Means For
Interpreting Icon as Type Ccntext;
FIG. 71 is a Flow Diagram of Programmed Means For
Identifying Attribute Class Concepts for Active Attribute
User Concept; FIG. 72 is a Flow Diagram of Programmed
Means For Interpreting Icon as User Connection Context;
FIG. 73 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. 74 is a diagram showing specific examples of
knowledge types as shown in FIG. 73;
FIG. 75 is a diagram illustrating a data structure for
storing potential value relationships according to the
embodiment of FIG. 73;
FIG. 76 is a flow diagram of programmed means for editing
the relationships in the computer database according to
the second embodiment;
FIG. 77 is a flow diagram of the detailed steps for
storing relationships in the computer database according
to FIG. 76;
FIG. 78 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; and
CA 02202867 1997-04-16
WO 96112236 PGT/US95/10077
13
FIG. 79 is a flow diagram of the detailed steps for user
A
selection of specific values in the computer database
according to FIG. 78.
a
DESCRIPTION OF THE PREFERRED SI~ODIMENT
Figure 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 (la) 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
'30 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 (lb)
enables the representation of abstractions of the patterns
of relationships in the knowledge representation. These
abstractions of the patterns of relationships are stored
CA 02202867 1997-04-16
WO 96/12236 PGTIUS95110077
14
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 ~cf a Natural Language ~nterface (lc) 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 '_ocation of a recogr_ized 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 auery languages. '
A major consequence of the Knowledge Representation
system of this invention is enabling the Knowledge
Representation to be "viewed" or perceived through a
~
(ld) means for
multitude of documents, through the
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
is
~ 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 ;reformation in the Knowledge
Representation Database.
Hoth 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 develap 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 ~ypes 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).
CA 02202867 1997-04-16
WO 96112236 PGT/US95110077
16
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,
eac'.~.~. of which is potentially symbolized by the icon.
The (le) means for user interface with the Knowledge
Representation through the documents enables a plurality
of behaviors for each icon based on _nterpretation 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
develcp extraordinarily context sensitive interaction with
the SCnowledge Representation. This .s 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.
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
17
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 cr file represented by the icon.
(la) MEANS FOR KNOWLEDGE REF~RESENTATION
Figure 3 provides a schematic summary of the means
for knowledge representation which is an expansion and
annotation of the Figure 1 (la) 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 relation:ahips) 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.
CA 02202867 1997-04-16
WO 96112236 PCTIUS95110077
18
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 Da~abase 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
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
19
specific concept or concepts that is distinct from the
general concepts of the Knowledge Representation Database,
while maintaining identification of she 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
'10 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
15 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
20 of the concepts facilitate the human-perceivable views,
and consequently user interaction with the Knowledge
Representation Database.
The Descriptive Database is call~:d descriptive~~
because it is an assembly of a set o~ relationships which
=5 describe a particular concept in the R:nowledge
Representation Database; and it serves as an intermediary
between the Knowledge Representation Database and the (ld)
Document module and (1e) View User Interface (Fig. 1)
where the ~wiews provide the human understandable
30 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
35 relationships comprising the records of the Knowledge
Representation Database. The Concept Editor may add and
CA 02202867 1997-04-16
WO 96/12236 PCTIUS95/10077
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
5 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
10 relationships and the Values of the relationships.
(3a) 1CNOWLFDGB R$PRBSENTATION DATABASE
The Knowledge Representation Database will generally
be implemented in a plurality of database files as
illustrated in Figure 10. The Knowledge Representation
15 Database will always consist of at least one Environment
Database (4a) and associated indexes) 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
:0 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,
:5 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
~0 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
35 combining the Environment and Project libraries in a
single database file may be preferable.
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
21 1
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 embod'_-ent, a multi-project scheme as
illustrated in Figure 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 asasigned to the
record. The reference number is used by the computer
system to refer to the concept instead of the name of the
CA 02202867 1997-04-16
WO 96/12236 -- PCTlL1S95~10077
22
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 reccrds comprising the
network. A plurality of relationships are stored within
i5 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 i3entification 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
CA 02202867 1999-11-26
23
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 of 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 Characte:rizat=ion and the Value is of external
concept 'blue' then the ASCII characters 'blue' would be
stored as the value.
Internal rf=_lationships 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, ii. 'Lynn' and 'Wendy' are both internal
concepts and, i:E 'Lynn's' relationship with 'Wendy' is
characterized b=,~ 'wife' and 'Wendy's' relationship with
'Lynn' is characaerized by 'husband', then 'husband' is
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
24
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.
Figure 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
i5 each dot a name for the concept and the record reference
number (the reference numbers are always preceded by -
(tilde) in the illustrations) are shown. Arrows between
the dots illustrate the references between the records.
Items (5e) and (5f) illustrate the relationships which
?0 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
:5 the attribute of (5b) and the reference number of the
concept (5d) which it is connected to. Item (5f) has tze
reciprocal structure with a val referencing (5a) and (5c).
Figure 6 illustrates the organization of the
Knowledge Representation Database. The system concepts of
:0 (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
?5 result of the system concepts and the fundamental
relationships is that the knowledge representation has a
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
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)
5 User Concepts are provided in Figure 7. Note that the
interstrata relationships in the tree structured
hierarchies of Figure 7 have specific meanings: the
organizing principle of the Attribute and Component strata
can be thought of as (7a) taxonomy (i.e. Class and
10 Subclass); while the organizing pr'_nciple of the Project
stratum can be thought of as (7b) composition (i.e.
structure and substructure).
Figure 8 summarizes the occurrence of the fundamental
relationships in the records of each of the four typical
15 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
20 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
25 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. ~n some implementations
of the invention, the reciprocal relationships.will not be
r expressed (e.g. a concept may have a class but it is not
Lreferred to as a subclass). However, this will seriously
reduce the effectiveness of the Knowledge Representation
CA 02202867 1997-04-16
WO 96/12236 PGTlUS95/10077
26
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.
Figure 9 is an adaptation of Figure 7 designed to
highlight the system concepts included in Figure 7. These
are examples of system concept included in the referred
embodiment. Figure 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
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
27
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 i:.
order to achieve an economy of exposition. The four
strata are summarized in Fig. 8 as being comprised of i)
properties; 2) attributes; 3) components; and 4)
propagations (or projects). Figure 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 identi=ies
the intrastratum connectivity in terms of the significance
of relationship used to connect all of concepts on a
particular stratum. Column D of Figure a shows the
stratum used in the characterization of relationship for
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
28
each of the stratum. And Column E shows the interstrata
relationships maintained at eacz 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 compr'_sing the attribute strata.
Figure 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 3efined to ac'.~_ieve specific design
objectives.
Attributes are the class c~ concepts most commonly
thought of as attributes of characterization of
relationships. For example, lore, 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.
Figure 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.
Figure 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 -nay be augmented as
desired. Many useful Attribute Classes can be defined to
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
29
- achieve specific design objectives in modeling knowledge
domains.
The Attribute Classes define which characterizations
- of relatio:ahips 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 Domaint~ D~claration
Figure i2 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 ~:e information stored in the records and
substructures. The domain statement is generally common
to all records comprising the Knowledge Representation
Database. 3owever, derivative embodiments may include
different =ecord structures, depending on the library or
class. The domain statement of Figure 12 .s 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 .or 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 t'.-_e art. Figure 12 illustrat:es optimizations
for
representing the fundamental relationships and for
represents.~_g attribute properties in t:he database records.
Both of these optimizations will be discussed in following
subsections.
CA 02202867 1997-04-16
WO 96/I2236 PGT/US95110077
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 -
5 declared prior to declaring the whole. In Figure 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 (120),
10 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
IS order cf these constituents within the record structure is
arbitrary.
The data type declaration (or equivalent
implementations) illustrated in the example of Figure 12
will assure functional implementation of the invention.
20 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 Figure 12 will
'
25 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
30 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
CA 02202867 1997-04-16
WO 96/12236 PCTIUS95/10077
31
Concept in the Properties of At~ributes 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 ~o 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 ref erence 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
CA 02202867 1997-04-16
WO 96/12236 PGTIUS95/10077
32
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 type, Field_Length, and Location. This is an
optimization of the implementation of Attribute Properties
that will be subsequently discussed. Properties (121)
declares the properties structure to consist of: (12h)
Prompt, (12i) Data type, (12j) Field_length, and (12k)
Location. The order of these elements within the
structure is arbitrary. Relationship (12m) allows (121)
Properties as an acceptable relationship. (12m)
Relationships are a complex data type associating a (12b)
character'_zation, 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
Figure 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 ~he record length.
The (120) parents, (12p) children, and (12q)
interstrata, are lists of reference numbers used to store
the fundamental relationships of the Concept record. The
(120) Parents are used to store the reference numbers
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
33
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.
Figure 12 indicates only (120) 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 Moans for Rapreseatiag
Fundamental Rslationsk~ipe
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 Figure 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
CA 02202867 1997-04-16
WO 96112236 PGT/L1S95110077
34
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
Figure 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 Figure 12 for (120) 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
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
particularly significant relationships; the presence or
absence of such segregation is merely an adaptation of the
inventicn. 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
Attribut~ Properties
The domains declaration illustrated Figure 12
10 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 reed for explicit
15 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
20 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
ZS 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
30 applicable and would merely be supplemented by suitable
modification to the (121) properties declaration or
- representig the additional attribute properties as system
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
36
concepts for use as (12b) characterizations in (12m)
relationships.
Notes on Additional Optimizations for
Domaias Declaratioa
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 Coda Recogaitioa 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
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
37
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.
Figure 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-utslige-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
ZS 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
CA 02202867 1997-04-16
WO 96!12236 r PGT/US95110077
38
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
.
then the (13c) outcome is
system concept in step (13b)
"NO".
The second procedure shown in Figure 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 referer_ce number of the
ZO 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".
Assuriag that Sy~tem Concepts ara Iava.olat~
The system concepts must be protected ~rom the
effects of inappropriate Record Operations. The Input
Operations protect the system concepts by prohibiting any
CA 02202867 1997-04-16 ,
WO 96J12236 PGT/US95/10077
39
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
ir.. 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 w?thin 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 strucLUre.
Figure 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; charge 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
Figure 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 perforcned on a system
concept (step 14c), followed by an exit of the called
operation (step 14e).
CA 02202867 1997-04-16
WO 96/12236 PC"T/ITS95I10077
4
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 '
5 are never presented as options to the user.
In the preferred embodiment both the steps
illustrated in Figure 14 and the above-described variation
are used to provide redundancy for protecting the system
concepts as inviolate.
10 USE OF SYSTEM CONCEPTS TO CHARACTERIZ$ R$LATIONSHIPS
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
15 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
20 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
25 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
30 knowledge representation, in that the records comprising
the knowledge representation should contain no data other
than unique record reference numbers.
Hy following the principles disclosed herein and
extending the disclosed methods to additional knowledge
35 domains, it is possible to eliminate the storage of all
data types except unique reference-numbers in all records
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
41
of the knowledge representation, exce~~ing only those
records representing knowledge of lanc~sage.
This principle can readily be ex,~ended 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 doma ins 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 she 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, i~ 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. 73 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)
CA 02202867 1997-04-16
WO 96/12236 PCT/US95I10077
42
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) Componen~s 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. 73,
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 (lb) 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) potentia1
value relationships is that (73e) is stored in the
CA 02202867 1997-04-16
WO 96!12236 PCTYUS95I10077
43
Attribute record and may cr 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
ZO 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
=5 with reference to Fig. 74 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 (-.).
30 The (74a) Potential Value, -3A, is defined as the
(73a) system concept used in this example. (74b) Color,
_ -3B, is defined as a (73b) Attribute. (74c) Color, ..3C,
is defined as a (73c) Component With s~,ibclasses (74i)
Green, -.3I, (74j) Black, -3J, ('74k) Blue, -3K, (741) Red,
135 -.3L, and (74m) Yellow, .-3M. It is very common in human
languages far two distinct concepts to have the same name
CA 02202867 1997-04-16
WO 96!12236 PGT/US95/10077
44
as in (74b) Color, -3B, as an Attribute and (74c) Color,
-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, -3H,
is a Component.
(74d) My Apple, -3D, is a specific instance of a
(74h) Apple, -3H, defined as a component in the Component
library, and its (74c) color, -3C, is (74m) Yellow, -3M.
The reference number -3H would thus be stored in the -3D
record. The reference number -3A of the system concept
(74a) "Potential Value," is used to characterize the
relationship between the attribute (74b) Color, -3B, and
the component (74c) Color, 3C as being that the
subcomponents of the component Color, --3C, are all
"potential values" of the attribute color, 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, -3H. Thus, the data
structure V(-.3A, [-3C]) stored within the attribute record
-.3B, signifies that the subcomponents of the record -3C
are all potential or possible values of the attribute
color, by virtue of the presence of the reference number
-.3A, denoting the system concept of "potential value."
While the system concept (74a) potential value, -3A,
used to characterize the (74e) and (74f) relationships
i
s
in the preferred embodiment, it should be noted that the
attribute (74b) Color, -3B, also could be used as the
Characterization in either or both the (74e) and (74f)
relationships, with the (74a) potential value reference .
number -.3A then being stored elsewhere in the relationship
data structure. r
The relationship (74f) between the component (74h)
3g Apple, --3H, and the specific subcomponent colors (74i)
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
Green, -.3I, (741) Red, --3L, and (74m) Yellow, -.3M, is also
characterized by the (74a) Potential Value, -.3A, system
concept. This relationship data structure would be stored
- in the -3H component record. Note that it also includes
5 the attribute (~4b) Color reference number, 3B, to
indicate that the relationship is colors that pertain to
apples.
The (74g) relationship between the specific instance
of (74d) My Apple, -.3D, and (74m) Yellow, -3M, is also
10 stored in the --3D project record. This stored
relationship indicates that the component value of the
(74b) attribute Color, -.3B, of (74d) tdy Apple, -.3D, is
(74m) Yellow, -3M. Note that these ra~lationships have not
been indicated as reciprocal relationships in order to
15 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,
~3M, or all components that have color., -.3B, as an
20 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 componnent (74c) Color,
25 -.3C, and the specific colors (i.e., (74i) Green, -.3I,
(74j ) Black, -.3J, (74k) Blue, -3K, (741) Red, -.3L, and
(74m) Yellow, -.~M) can be the fundamental relationship of
class and subclass that defines the ta.xonomical hierarchy
of the Component library, or it can be a relationship
30 characterized by some other system concept. The specific
relationship is nat 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
~
35 knowledge representation database, additional system
concepts can be defined to identify the occurrence of
CA 02202867 1997-04-16
WO 96112236 PCTIUS95/10077
46
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. 75 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. 73 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," -3A).
The (75b) Value of the relationship will be comprised of
the reference numbers of the (73b) Attribute (color, -3B)
and the (75d) reference numbers) of the (73c) component
concepts (green, -3I, red, -3L, and yellow, -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
CA 02202867 1997-04-16
WO 96/12236 PG"F/US95/10077
47
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. 75 since this
provides the most general case and a17. variations will be
derivative and functionally equivalent embodiments.
M~ans for $diting R~latioaships ~rith 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 th.e invention and as
a
guide to program development.
-35 Fig. 76 illustrates a suitable flow diagram for
editing relationships with Component concept records as
CA 02202867 1997-04-16
WO 96/12236 PCT/U595/10077
48
values. Addi__~.g 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 cperation 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 :.ypically 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
ac;.omplished 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
Z5 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 ror removal by the user.
Step (76f) stores the relationship by creating a -
relationship data structure as discussed in connection
CA 02202867 1999-11-26
49
with the illustrated means of Figure 75 and storing that
relationship in the appropriate record. Figure 77
provides an expansion. of the means comprising this step.
Means for Storing Relationships
Figure 77 illustrate=_s 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 lis~~ for the value is a subset of the values
stored at the A?~tribute. If either Steps (77a) or (77b)
fail, then the :implication is that the values in the list
to be stored ma~~ 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 genera:L case and store the inferred set at the
attribute after user confirmation.
Step (77c) get~~ 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 record
is subsequently used for deciding where to store the new
relationship. Step ('77e) tests that the active record 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) store; the relationship in the component
record. Storing the :relationship replaces any existing
CA 02202867 1997-04-16
WO 96!12236 PGT/US95/10077
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 -
5 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, -3C, which would be
10 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 conf_rmation by telling the
user the inferred class and asking to verify. If the user
15 does not like the _nference, 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
20 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.
Z5 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
30 store the relationship list in a record; in fact step
(77i) and (77f) are the same process. In the preferred
embodiment, these 'hree 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
35 the relationship.
CA 02202867 1997-04-16
WU 96/12236 PCT/US95/10077
51
Uaiag Relationships with Compoaent coacepts as valu~~
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 Uthers 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 t:he system concept
can be used as the characterization oi: the relationship
storing the record reference numbers) 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 numbers) 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
y
explicit definition. The preferred embodiment uses a
system concept stored at~the attribute record as the
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
52
characterization of the relationship storing the record
reference numbers) 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. 78 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 ~n the
attribute record for the attribute characterizing the
relationship to be edited. Figure 79 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 Figure 3, when creating the
project instance of (74h) Apple, -3H, that is (74d) My
Apple, -3D, the display would offer options of (74i)
Green, -3I, (741) Red, -3L, and (74m) Yellow, --3M. The
user interface can be whatever the designer believes a
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
5~
relevant to the values such as menus, pallets, buttons,
and so forth. T_n 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. 74
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
numbers) of the component nodes) thaat are the value of
the relationship.
Step (78d) Frovides means for storing the
relationship in to 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 val;:es 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 fr:.ction or other control function for
Z5 continuation.
Note that Step (78c) can be implemented to create the
reciprocal relatianship to be stored in the component
records) 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 t::e created relationship at the project
node. Note that Step (78b) may include edit options for
userselection as part of the menu of value options. This
r 35 will allow the user to dynamically edit the options.
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
54
Figure 79 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 Figure 77. 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).
Steer t79b) 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 '
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
option must be defined; handling this case will readily
occur to a skilled practitioner.
_ Value Clustering
5 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
10 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
15 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.
20 ' 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.
25 More specifically, if Washington is the value of
State then the Country is United States of America, the
country code is always OZ, 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
30 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
35 practical system, the system implement:or may choose to
predefine significant value linking afa a feature of the
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
56
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 O~~rations
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 pperations (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) Net~oork Operat~.oas
The Network Operations (3e) comprise a plurality of '
steps for interaction with the network structure of the
CA 02202867 1997-04-16
WU 96/12236 PCT/US95/10077
57
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 z~ot 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.
Figure 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
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
58
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 r_ame
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 Functioas
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
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
~9
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
LO 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
.5 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
:0 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
:5 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.
30 Figure 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 Figure 16 is to process all active concepts
y
35 . in the Descriptive Database by getting the next active
reference number in the database and cycling through the
CA 02202867 1997-04-16
WO 96112236 PCTIUS95/10077
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
5 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)
10 assembles all of the relationships pertaining to the
Active which are stored at the active record into a
Relationship_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)
15 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
20 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
25 (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"
30 (16f) then the save is done.
~n.~.) Raad Functioag
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
35 Database is a working non-permanent database. The
CA 02202867 1997-04-16
WO 96/12236 PGTlUS95/10077
61
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 reauired for
storage in the Descriptive Database, and store the
information in the Descriptive Database. The Read
Z5 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 Iaheritaace
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
CA 02202867 1997-04-16
WO 96/12236 PCTIUS95/10077
62
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.
_Relationehip 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
CA 02202867 1997-04-16
R'O 96/12236 PCT/US95/10077
63
"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 inheri~ance 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 a.re 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
Parents) references must necessarily lead to the root
CA 02202867 1997-04-16
WO 96112236 PCT/US95I10077
64
record. The interstrata parents) only references a
finite number of component records, each of which must be
a classification of the active record.
Figure 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, anc~ 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 relaticnships.
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.~., one record only). This is distinct in that all
CA 02202867 1997-04-16
WO 96/12236 PG"T/US95/10077
other categories of inher_tance are for the Relationship
List of all the individua_ records in the inheritance
path.
Column (17g) identif_es the inheritance path length
5 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
10 designer. In practice two steps is often a useful length
for user inheritance.
Taxonomy inheritance a based on the logical premise
that all of the relationships of a class apply to a
subclass. This is true i: that Classes are necessarily
15 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
20 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 o~ the relationships of specific
25 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
30 values can be inherited by virtue of the compositional
hierarchy in the Project. This embodiment of the
invention uses only one f;:ndamental relationship, the
parent, in concepts that are Attributes or Components.
Two fundamental relationships, parent and type, are used
y35 only the Project concepts.
CA 02202867 1997-04-16
WO 96/12236 PGT/US95I10077
66
Fig. 18 illustrates the concept of a descriptive
necwork for an active Attribute record. Here, "SL" (upper
left hand side of Fig. 18) is the active concept for
explanation. Figure 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. Figure 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 Figures 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' processing system of the present
invention).
The types of inheritance must (summarized in Figure
17) be applied in a specific order to assure that the
correct meaning of the record is inherited. Figure 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 Figure 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 Figure 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
CA 02202867 1997-04-16 ,
WO 96/12236 PCT/US95110077
67
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 Figure 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.
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
68
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 the relationship
inheritance.
With the relationship inheritance complete, check to
see if Value inheritance applies (step 21h). In general
Value inheritance does apply however, a specific
attribute characterizing a user relationship may have a
property or rule attached to it which prohibits
inheritance.
If step (Zlh) does not apply the value inheritance
procedure is bypassed. If (21h) does apply then it is
determined if there is a relationship with a value
reference the same as the current value reference (step
21i). If (21i) is Yes, then determine if the
characterization attribute allows for multiple values as
one of the properties of the attribute or attribute class
(step 21k). If (21k) is yes then go to (21j) and add the
relationship to the Descriptive Database. If (21k) is No,
get the source record of the relationship from the
information in the Descriptive Database and remove the
relationship from the source record if appropriate (step
211). Then remove the relationship from the Descriptive
Database (step 21m). Then add the relationship to the .
Descriptive Database with the current record as the
source. (Note that the deletion from and addition to the
Descriptive Database is equivalent to substituting the "
CA 02202867 1997-04-16
WO 96/12236 PGTlUS95/10077
69
current record reference for the existing source reference
of the relationship in the Descriptive Database).
If the inheritance is for a fundamental relationship,
check to see if done with read by versifying that the
current record is a system concept and the remaining
relationship list in temporary memory is nil (21n). If
the inheritance is for a user concept, then check to see
if the reading has progressed a defined number of levels
away from the Active record. The number of levels for
t0 user inheritance will tend to be a property of the
Attribute Classes, as in the preferred embodiment.
Usually one or two levels are adequate for user
inheritance.
If (21n) is No, go to (21d) Read Next Record. If
(21n) is Yes proceed to next process.
Note that the described flow process was based on
resolving inheritance from the active record through the
path to the system concepts (or levels of traversal) which
terminate the path. This process can be reversed so that
ZO the resolution is from the system concept to the Active
Record. If this is done step (211) remove from Source
Record should be changed to Remove from Current Record,
and (21m) is not required. The implementation of
relationship inheritance is very powei:ful and results in
.5 tremendous economies in data entry: a relationship or
value must only be entered so that it is stored in a
specific record (one time, one place), and it will
automatically appear in the description of all concepts
which include that record in their descriptive networks.
30 Characterization iah~ritana~
Characterization inheritance assembles the
descriptive inheritance list for the attributes
characterizing relationships in the Descriptive Database.
Characterization inheritance essentially assembles the
r
35 descriptive meaning of each of the attributes referenced
in the characterization of relationships in the
CA 02202867 1997-04-16
WO 96112236 PGT/US95110077
Descriptive Database. The process disclosed below
sequentially applies the procedure for relationship
inheritance to the characterization of each relationship
in the Descriptive Database.
5 The Characterization of each relationship is stored
in the structure of the relationship. The procedures for
Characterization inheritance are fairly simple compared to
those for Relationship inheritance. This is largely due
to the fact that the Characterization inheritance calls on
10 the Relationship inheritance procedures and therefore does
not need to repeat the methods programmed in the
Relationship inheritance.
Figure 22 illustrates a Flow Diagram for Implementing
characterization Inheritance. Characterization
15 Inheritance is a simple two step process. First find a
characterization in the Descriptive Database for which the
characterization inheritance is not assembled in the
database (step 22a). Then assemble the description for
the characterization by means of Relationship Inheritance
20 'or said characterization (step 22b). This two step
process is applied until all characterizations are
described in the Descriptive Database, and then the cycle
terminates. Numerous variations of this basic process for
Characterization inheritance can be implemented as part of
25 a family of functions for Characterization inheritance in
any real world application of the invention. Typical
variations can include: assembling the Characterization
inheritance for only a particular class of attributes; and
assembling the characterization inheritance for only those
30 attributes required for a particular view.
S3h) Descriptive Database
The Descriptive Database is a means for storing _
information in a plurality of records in a computer
database. The descriptive database is a 'working' non-
35 permanent database. The transfer of information to it
from the Knowledge Representation Database is made to
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
71
consolidate the relationships in the concept/records from
references to other concepts into descriptions of the
concepts. The description of the concepts facilitate the
views, and user interaction with the lcnowledge
representation database.
The information stored in the computer database is
structured by means of suitable database data type
declarations wherein the structure of each record in the
database includes substructures designed to store
individual relationships from the Knowledge Representation
Database together with structures designed to store the
reference number of the "Active" record to which said
individual relationship applies and the source of said
relationship in the Knowledge Representation Database.
1 C, Tie Tle~r~r~~,t~s~rm Tl~f-~i,~oe c.nlwr7~ c rwrHs ~ ~F i-L,s
.r ,iaac ucw.is.y..~vc uw.caarcmc cuurvuic~~ a rvw.ivii vw.aic
network of the Knowledge Representation Database, by means
of suitable record structures in a computer database. The
records embody each of the relationships in the
relationships list of the records of t:he Knowledge
Representation Database. The Descriptive Database
embodies a description of the information stored in a
plurality of records comprising a portion of the records
in the network of the Knowledge Representation Database by
associating the record reference numbers of the records
(Active and Source) with the information from the
relationship lists of the records. This is required if
relationship inheritance is implemented because otherwise
there is no way to assemble all of the relevant
relationships for a record and know the source of those
relationships.
The structures of the records for the Descriptive
- Database are established as database data-type
declarations in the programming language in which the
structures are implemented. Suitable provisions for
declaring such structures are provided by the various
CA 02202867 1997-04-16
WO 96112236 PCT/US95/10077
72
programming languages and tools which are suitable for
implementation of the present invention.
The translation from the Knowledge Representation
Database and to the Descriptive Database is provided by
means of the Network Operations. Other functions in the
system such as the Concept Editor and the Relationship
Editor use the Descriptive Database by means of native
calls to the database. Native calls are not discussed
further herein because they are well known standard
techniques.
Figure 23 illustrates a suitable Domain Declaration
for the Descriptive Database. The Source of each
relationship is recorded together With the Active for
which it was assembled.
The Database (23a) identifies the database of the
Source as either a project database (prj) or an
environment database (env). If additional databases are
used, they can be added to the list. In Knowledge
Representation Databases which include the environment and
projects in a single file the Database (23c) is not
required to define the Source.
The Active (23b) identifies the reference number of
the record and the database in Which the record occurs for
which the description is assembled in the Descriptive
Database; the order is arbitrary.
The Source (23c) identifies the reference number of
the record and the database in which the record occurs;
the order is arbitrary.
The structure (23d) of the Descriptive Database
record includes a Relationship together with items (23a)
through (23c). The order of the items in the structure is
arbitrary.
The illustration of Fig. 23 identifies the essential
elements comprising the records of the Descriptive
h
Database. The structure of the Descriptive Database
record can easily be supplemented With additional
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
73
structures tc store additional information which
facilitate the views.
The Descriptive Database can be augmented to also
associate document defined icons and icon locations
appropriate to the record and relationships, by declaring
a plurality of supplemental records suitable to the
storage of the document related information. The icons
and the icon locations associated with the information and
the record reference numbers in the Descriptive Database
LO are derived and placed in the Descriptive Database by
means of one of the plurality of views. The views may add
supplementary data structures to the Descriptive Database
as required to support the view.
. A plurality of data structures are used in the
Descriptive Database to facilitate storing the icons and
icon locations required to support the documents in the
plurality of views implemented for the system. There is
considerable latitude available to the system designer in
declaring suitable data structures; however all
ZO declarations will have common characteristics which are
set forth in the subsequent discussion.
(3i) Concept and R~latioashia Editor
The Concept and Relationship Editor is a code module
for editing the concepts (records) and relationships
(cross-references within records) comprising the Knowledge
Representation database. This module is comprised of a
plurality of programmed operations which make use of the
Record Operations, the Network Operations, and the
Descriptive Database. The following subsections will
highlight specific aspects of the Concept and Relationship
Editor which are particularly unique to the invention.
_ Coaoe~pt Editor
The Concept Editor is comprised of a plurality of
programmed procedures. The Concept Editor embodies means
~35 for editing t'~e concept records of the Knowledge
CA 02202867 1997-04-16
WO 96/1236 PCTIUS95/10077
74
Representation Database and assuring that all records
maintain appropriate fundamental relationships. -
The Concept Editor coordinates the Record Operations
t~ create new records and to store the appropriate
information in the substructures of the records. The
coordination of these operations assures that all records
are connected to the network through appropriate
fundamental relationships. The Concept Editor also
coordinates user interface to enable user interaction in
identifying the values for the fundamental relationships.
The Concept Editor is invoked by the Natural Language
Interface with Knowledge Representation and the User View
Interaction interface as required to edit concept records
in the Knowledge Representation Database. Fig. 24
illustrates a Flow Diagram for Adding a Node (record) to
the Knowledge Representation Database. It illustrates the
principle steps in creating a record and assuring that the
fundamental relationships are correctly formed. Each new
record must have the correct fundamental relationships in
order to assure interpretability in the network.
User interaction to add a node can be implemented in
a variety of ways through the Natural Language Interface
and through the User View Interaction interface.
Each new record will be added in relationship to some
existing concept record. Getting the Parent record
reference number (step 24a) can be accomplished through
user interaction. For example the Natural Language
Interface or the Tree View can be used to ask the user to
identify an appropriate Parent for the concept record
which is to be added to the database.
Often the request to add a new record is invoked by
identifying the parent and requesting the addition of a
child (this is especially typical of Tree View
interaction). In such Case step (24a) is merely the
of determining which record is highlighted or '
process
screen of the computer when the
di
la
sp
y
active on the
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
request to add a record was made. The record can be made
immediately without any information stored in the
substructures (step 24b). If the record is made as
' illustrated, the additional information for the record,
5 which is subsequently derived, can be added to the record.
The record can be made as a final step if all of the
additional information is temporarily stored for addition
to the record as soon as it is made.
In general the procedure illustrated in Fig. 24,
10 wherein the record is made first and the subsequent
information added to the record as the information is
derived, will result in multiple disk accesses during the
creation of and addition of the information to the record.
This does not present a problem for single user systems.
15 In networked systems, however, moving step (24b) to last
may be preferable as it will minimize disk accesses.
The next step is to Update Parent and Children
Lists(24c). The Parent reference number field of the new
record must contain the reference number of the Parent
20 record. Reciprocally, the Children reference number list
of the Parent record must include the reference number of
the new record as a descendant of the Parent.
Project Library records require Type references,
therefore step (24d) determines if the new record is a
25 Project record. If the outcome of (2~1d) is YES, then the
Type reference is retrieved and stored in the interstrata
Reference List of the New Record (step 24e). If (24d) is
NO, then the flow proceeds to step (24f) to read the New
Record.
30 The Type reference can be determined by querying the
user for the type of the record. This is done by
- displaying the Component library in a Tree View, and
allowing the user to select the component which
corresponds to the Type of the new Project record. The
35 process of selecting a component for the Type can be
supplemented through the addition of routines which will
CA 02202867 1997-04-16
WO 96/12236 PGTIUS95I10077
76
provide best guesses on what type of component the Project
record is, based on the context of the parent of the new
record. The context of the parent record may provide
guidance in selecting the Type by one of two means which
can be implemented by the system designer as supplementary
procedures to assist the user in identification of the
type of a new Project record.
First, the parent record may include an abstraction
defining the type of the objects which exist in its
compositional hierarchy as children. This abstraction may
furnish a list of likely types from which the user can
select the Type of the new record.
The second method is to infer a likely Type based on
examination of the existing children of the parent record..
It is likely that a new record will be of the same Type as
the record's siblings. The addition of these
supplementary procedures for determining the Type is at
the discretion of the system designer.
If the Type does not already exist, the user should
be allowed to create a new component of the Type desired,
and then select that new component as the Type of the new
Project record. This is merely a modification and
enhancement of the selection of the type, and therefore is
not discussed in further detail.
The new Record is read at step (24f~ by using the
Read Network Operations (16e? to assemble the Descriptive
Database for the new record. This will assemble the
relationship inheritance for the new record. This is
required because the record Name will be the value of an
external relationship of the new record.
In order to Make and Store the Name in the New Record
(24g}, an external relationship for the name must be
formed and added to the Relationship List of the new
record. The name and the attribute characterizing the
obtained either by user interaction wherein
b
e
name must
d characterization of the
the user specifies the name an
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
77
name for the new record, or by deriving the name and
characterization from the inherited relationships of the
new record. The procedures consist of prompting the user
to provide a name, and prompting the user to specify which
of the external relationships of the new record contain
the Attribute characterizing the name.
The procedure for deriving the name from the
inherited relationships of the new record is by means for
Pattern Recognition and Storage wherein a pattern
specifying some portion of the name relationship for the
new record has been previously identified and stored.
Note that in some cases the attribute characterizing
the relationship for the name will not be part of the
relationship inheritance of the new record. In this case
a relationship with the correct characterization must be
added by means of the Relationship Editor and then
selected by the user.
The name must be stored in the appropriate structures
of the record. In the preferred embodiment this includes
ZO storing the name in the Name location of the concept
record structure, and storing the characterization in a
substructure of the record.
With the completion of step (24g) the process of
adding a new record is complete and al.l that remains is
housekeeping including clearing the Descriptive Database
and any internal variables or data structures used in the
process (24h) .
The following paragraphs provide notes on the
preferred embodiment of the invention to provide guidance
to the system designer in implementation.
In practice it has been found advantageous to keep a
- list of reference numbers of all deleted records, and to
use a deleted record reference number whenever possible in
creating a new record.
The preferred embodiment allows for the definition of
synonyms for each of the concepts. This is enabled by
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
78
providing a single name for each concept in the Name field
of the record, but indexing al. synonyms as part of the
index associated with the datayase. This means that a
plurality of names will be associated with each reference .
number in the index. This is particularly convenient in
connection with the Natural Language Interface wherein
synonyms for the concepts will regularly be defined.
Another optimization that is present in the preferred
embodiment is that conjugate types of relationships are
ot stored in the corresponding component record. Rather,
n
the conjugate relationships between the component record
and the Project record are sto=ed by indexing the
reference number of the component record in the index of
the Project database. This is particularly convenient in
multi-project databases, in that it allows for
distinguishing the presence of the component in a
particular database.
Relationship $ditor
The Relationship Editor is comprised of functions for
editing the relationships desc=ibing a concept record of
the Knowledge Representation Database. These functions
include editing 1) the relationship list of a record: 2)
the characterizations of relat'_onships; and 3) the values
of relationships.
The Relationship Editor coordinates the unit
operations of the Descriptive Database, the Network
Operations, and the Record Operations to edit the
relationships in the Relationship List in the records of
the Knowledge Representation Database. The Relationship
Editor also coordinates user interface to enable user
interaction in identifying the characterizations of and
values for the relationships. -
The Relationship Editor is invoked by the Natural Language
Interface with Knowledge Representation and the View User
'
Interaction interface as requi=ed to edit relationships in
the Knowledge Representation Database.
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
79
Each oy the domains declared for the Values (internal
or external) will in general require a separate class of
editor. T!:is is because the domains of the Values are
distinct f=om each other. External values are those that
are not further conceptualized (no record embodying the
concept ex'_sts) in the network and are represented in the
value field by a character string such as 'red' or
'positive'. Internal values are those that are further
defined by other concept records and the value field holds
the refereTce numbers of those concept records.
In specific implementations where additional classes
of externs' values are implemented, specific editors
suitable f ~r those classes of values may be required. For
example, '_~ the preferred embodiment, there is a domain
devlared f.~:~ ~eprej~litiilg grail hl cal lcollb Gj t he
'vCliuer~7 of
external relationships. Such icon definitions require a
separate editor suitable to editing the entities
comprising said definition.
In the preferred embodiment the editor for the
external values is implemented in a manner very similar to
standard word processing type environments, wherein the
editor inc_udes the full range of event processing
characteristic of word processors. In general, editors
implemented .or the Values include event driven processing
of user actions in control of the editor. These editors,
in many ways, resemble standard word processing programs
designed to create a particular type of document. The
specifics of the development of these types of editors is
not disclosed herein, as it is considered standard
technology :which will readily occur to any skilled
practitioner given the value domain upon which the editor
must operate.
~c~dina a Relationship
The f ~ilowing discussion identifies the procedures
for adding a relationship to the Relationship List of a
specific record. The process of adding a relationship is
CA 02202867 1997-04-16
WO 96/12236 PG"TIUS95/10077
essentially to identify a characterization for the
relationship and adding it to the Relationship List with
an unbound value.
Each relationship has a reference number of an -
or an attribute property, which defines the
attribute
5 ,
characterization of the relationship. The Value of a
relationship is constrained by the characterization in
that the characterization specifies the properties of an
acceptable Value (e. g. data type, field length, range,
etc . ) .
In any specific relationship the value can be
undefined: such values are said to be "free" or
"unbound". A relationship is always initially added to
the Relationship List of a record (or equivalently to a
description in the descriptive database) with the value
15 unbound. The value is subsequently bound through various
means for specifying the value.
Figure 25 illustrates a Flow Diagram for Adding a
Relationship to the Relationship list of a Record in the
Knowledge Representation Database. Each of the steps of
the process are briefly discussed in the following
paragraphs.
In step (25a) the selected attribute should not be
the same as any characterization in the current
description of the Active record. The selection may be
;5 supplemented by a variety of means to,assist the user by
making a "best guess" or likely choice based on the view
context in which the query occurs.
t identify the target for the addition of
The user mus
new attribute relationship at 25b. The user is
th
30 e
prompted for the specification of the Target. It is
helpful to present a menu of possible targets for the ,
The target will be one of the Component
lection
'
.
s se
user
the descriptive network of the Active
i
n
Library concepts
35 record.-
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
81
At step (25c), the Target Relationship list is read
using the Output Record Operations to read the
Relationship list stored in the target record of~the
Knowledge Representation Database. The Relationship list
is passed forward to step (25d) where the new relationship
is added to the Relationship list. The new relationship
is formed using the new characterization and a nil value.
Finally, at step (25e) the target Relationship list
is replaced with the new Relationship list using the Input
Record Operations to store the new Relationship list in
the target record of the Knowledge Representation
Database.
Inatantiatina a yalue
The following discussion identifies the procedure for
instantiating a Value for a relationship and adding the
relationship with said Value to the Relationship List of a
specific record.
The process of instantiating a Value is essentially
to use the characterization for the relationship as a
basis for guiding the user in editing the current Value to
specify an acceptable Value. All relationships always
have a value in that an unbound value can be considered to
be nil. Thus the process of instantiating a Value is
equivalent to the process of editing a value.
The Value domain is comprised of two domains:
Internal and external. The following discussion refers to
flow diagrams and descriptions of procedures for
instantiating both types of values. 'The procedure for
instantiating a value assures that all relationships are
stored at the correct locations in the networks and that
reciprocal relationships for internal values are
coordinated.
The Relationship Editor is invoked by the Natural
Language Interface with Knowledge Representation and the
View User Interaction interface, as required to edit
concepts in the Knowledge Representation Database.
CA 02202867 1997-04-16
WO 96/12236 PGT/US95110077
82
Instantiatina an Internal Value
Fig. 26 illustrates a flow diagram f or establishing a
reciprocal relationship between two records. The calling
functions will typically track both the current Active
record and the current relationship of the Active record.
Typically, the Active record will be in the Descriptive
Database, as is assumed in the following discussion.
These items must be present prior to proceeding with
establishing a reciprocal relationship.
The first step (26a) is to determine the
characterization reference number of the current Active
relationship. The characterization reference number is
required because the reciprocal relationship will be based
on a compatible relationship in the target record (the
record to be connected to). At step (26b) the target
record is selected as described above.
First, it must be determined if the Active record has
an abstraction which identifies a pattern for the target
of the Characterization reference number (see subsequent
discussion of Means for Pattern Recognition and Storage).
A second procedure for selecting the target record is
to prompt the user and transfer control of the selection
to an appropriate View for user selection of a target
record. This can be optimized by making a best guess by
looking at other instantiated relationships for the Active
record of the same attribute class as the Active
characterization and prompting the user to an appropriate
view document of the local network. Once the target
record has been selected, the Target record is read at
step (26c) by using the Read functions of the Network
operations. This will assemble the relationship
inheritance of the Target in the Descriptive Database.
The relationships of the Target in the Descriptive
Database are checked to determine if a suitable .
~ relationship is available for the reciprocal of the Active
Characterization at step (26d). The suitability of the
CA 02202867 1997-04-16
WO 96!12236 PCT/US95/10077
83
relationship is governed by two things: 1) the attributes
must be of the same Attribute Class (i..e. the same
Attribute Class system concept must be a common parent of
r both the Active and the Target characterizations); and 2)
the Attribute Class of the characterizations must not
exclude the available Target characterizations.
If. a suitable relationship is available the flow
proceeds to step (26i) to select the characterization of
the reciprocal relationship from the target record.
..0 If a suitable relationship is not available then the user
is notified that the Target contains n.o suitable
relationships and the user is prompted. to add a
Relationship to the Target record at step (26e).
If the user declines, the procedure is aborted. A
.5 modification would be to return to step (26b) Select a
different Target Record, instead of aborting. This could
be augmented by asking the user whether to abort. or select
new target.
If the user wants to add a Relationship to the Target
ZO record, then an Attribute is selected to characterize the
relationship to add from the descendants of the Attribute
Class system concept of the Active relationship
characterization at step (26f). Tree View is a convenient
view for enabling this selection. The selection could
25 also conveniently occur through a menu pick wherein the
appropriate candidate attributes are presented for user
selection.
The selected characterization must be added to one of
the records in the Target Type taxonomy. The user
30 typically must, at step (26g) select where to add the new
relationship in the Target Type taxonomy. This can be
accomplished by means of presenting the names of the
Taxonomical ancestry of the Type record together with the
name of the Type record in a menu for the user to identify
~35 which record (Source) should store the uninstantiated
relationship.
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
84
The new uninstantiated relationship should then be
added to the source record at step (26h) by means of the '
Input function of the Record operations. At step (26i) a
Reciprocal Relationship for the Target is selected from ,
the available relationships. If only one relationship is
present take it. If more than one relationship is present
the names of the attributes characterizing the
relationship can be presented to the user for user
selection of the desired relationship. Note that this
selection process may be modified by (lb) Means for
pattern recognition and storage if previous patterns of
connections have been identified (see subsequent
discussion of the (lb) means) .
The program can then complete and save Relationships
in the Active and Target records at step (26j). The
relationships are completed in a form similar to that
illustrated in Figure 5 where (5c) and (5d) are typical of
the instantiation of the relationships which will be
stored at the Active and Target records respectively.
Instantiatinc an 8xteraal Valu~
Fig. 27 illustrates a Flow Diagram for Instantiating
the Value of an External Relationship. Each step is
described in the following paragraphs.
At step (27a), the user a prompted for the value.
Z5 External values must be entered by the user. It is
possible to assist the user with likely defaults,
particularly if the means for pattern recognition and
storage have been implemented and a pattern has been
stored for the characterization of the value. Such
assistance is an optional enhancement of the embodiment
presented here.
definition of the value, test (27b) the -
Upon user
alue is approved by comparing it with any restrictions on
v
or specifications of data type which may be part of the
description of characterization of the relationship. Step
rised o~ a plurality of tests to
com
b
p
e
(27b) may
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
determine if the value is ok. For example, the test might
include data type, field length, and value range. If the
value is not satisfactory to all tests, then step (27c)
' prompts the user of the error (failed test) and allows the
5 user to edit the value. If the value is satisfactory to
all tests, then step (27d) replaces that value in the
Descriptive Database. The user will need to invoke the
Save operations in order to place the new value in the
(3a) Knowledge Representation Database.
10 Some useful variations include: allowing the user to
set a flag which will automatically save all new values to
the Knowledge Representation database; or to always
automatically save the new values to the knowledge
representation database.
I5 (lb) PATT$RN R$COGNITION, STORAG$,
AND UTILIZATION MOD1TL$
The pattern recognition, storage, and utilization
module (lb) recognizes patterns in the relationships
stored in the Knowledge Representation Database, stores
20 the recognized patterns as relationships in the relevant
records of the Knowledge Representation Database, and
utilizes the stored patterns in the editing of concepts
and relationships comprising the Knowledge Representation
Database.
25 Recognizing, abstracting, and storing patterns
provides for the embodiment of significant knowledge
which, when utilized, results in intelligent behavior of
the system. -
Relationships in the Knowledge Representation
30 Database are established~by the Concept and Relationship
Editor (3i). Patterns in relationships can be abstracted
and learned by adapting procedures to monitor and record
the operation of the Concept and Relationship Editor.
Such procedures are implemented in the invention so that
35 the recognition, utilization, abstraction, and storage of
CA 02202867 1997-04-16
WO 96/12236 PGTIUS95l10077
86
the patterns occurs as part of the operation of the
Concept and Relationship Editor.
The abstraction of the patterns are stored by means
f a class of Attributes which will be known herein as
o
Rules. All Rules are implemented as system concepts and
re used to characterize a relationship wherein the Value
a
stores the abstraction of the relationship pattern. All
rules are declared as system concepts in that the
interpretation of each Rule must be embodied in specific
code associated with the relevant editor. The values in
relationships characterized by rules can be edited to
provide a priori definitions and to modify stored
patterns. The principles by which such a Value editor can
be implemented was briefly described in connection with
the means for editing relationships.
Relationships characterized by rules are added to a
Relationship List of an appropriate record by use of the
same editing procedures that are used to add any
relationship to the Relationship List of a specific
record.
The patterns are, in essence, a record of the
patterns in relationship at the next higher level of
abstraction, than the level upon which the instantiation
of the value occurs. This means, for example, that when a
substructure is being added to a project concept record,
what is recorded is the reference number of the
classification or type of the specific substructure rather
than the reference number of the specif is record embodying
that substructure. The rule embodying the abstraction is
stored within the Type record of said project concept
record.
Similarly, patterns of relationship between external
values, tfor example as occurs in the concatenation of
First Name, Middle Name, and Last Name to derive the value
'
of the Full Name) would store the reference numbers of the
characterization of the values in the concatenation,
CA 02202867 1997-04-16
WO 96112236 PGT/US95/10077
87
independent of their values (e.g. the attribute record for
the concept of "Full Name" would include a rule for
concatenation, the value of which would be comprised of
the reference numbers of the attribute concepts for First
Name, Middle Name, Last Name.)
The unique means for pattern recognition, storage,
and utilization are discussed under the following
subheadings: implementing Attributes characterizing Rules
as system concepts; implementing Attribute Properties of
Rules as system concepts; and implementing programmed code
for pattern recognition, storage and utilization in
conjunction with the means for editing relationships and
values.
Implemeatiag Rules as System Coacepts
The Rules of this invention is the class name for
characterizations of the relationships wherein recognized
patterns are stored in the (3a) Knowledge Representation
database. All recognized patterns are stored in
relationships as values with an associated
characterization that must be a Rule. This provides
compatible means for storing the abstracted patterns as
properties of the concepts in the Knowledge Representation
database. The specific characterizations implemented as
system concepts will typically be implemented as a
subclass of the Attribute Library. The rule system
concepts are implemented as per the methods for including
system concepts typical of the Knowledge Representation
database.
Figure 28 provides a tree diagram of a taxonomy of
rules system concepts and illustrates the principles for
deriving rules and implementing said rules as System
- Concepts. Figure 29 provides a summary and description of
specific rules which are illustrated in column (28d) of
Figure 28 and included in the preferred embodiment.
Column A of Figure 28 merely represents that we are
CA 02202867 1997-04-16 .
WU 96!12236 PCTIUS95/10077
88
talking about the Rules. This corresponds to the suggested
implementation of a Rules system concept.
The predicate classes illustrated in Figure 28 Item
(28b) are typical of the editor predicate (procedure)
classes responsible for establishing and editing
relationships in the preferred embodiment. Said classes
include: define concept, which provides a plurality of
program means for creating and editing a concept
definition; and instantiate values, which provides the
programmed means for instantiating the values embodying
the user relationships in the Knowledge Representation
database.
The attribute classes in Column (28c) identify
typical classes of rules implemented in the preferred
embodiment. Each of these classes are associated with the
operations or the predicate classes relevant to the
instantiated values within said classes. Having
identified the predicate classes for establishing and
editing relationships, and having identified the classes
of characterizations of those relationships, the final
step is to identify specific Rules characteristic of the
programmed operations for each of the attribute classes.
The specific Rules in Column (28d) illustrate
specific rules which have been found useful and are
implemented in the preferred embodiment. Broadly
conceived, they represent a plurality of system concepts
which may be defined by the system designer to meet the
objectives of the specific implementation. The specific
function and purpose of the rules identified in Column
(28d) will not be discussed in detail as they will be
obvious from the description and preferred embodiment
thereof . -
Figure 29 is provided as a summary and With a brief
description of the specific Rules implemented as system
concepts in the preferred embodiment. This will assist
_
L-the system 3esigner in understanding the specifics of the
CA 02202867 1997-04-16
WO 96/12236 PG"T/US95/10077
89
preferred embodiment. It also provides some sense of the
function of the Rules.
Impl~m~atiag Rula Properti~s as System Coacepts
' The values of Rules are typically complex structures
of (12f) Mixed Type. There are a variety of attribute
properties which are useful in constraining the behavior
of mixed values. The attributes characterizing the
behavior of a specific Rule's value are most easily
implemented as attribute properties system concepts. As
such, they may only be stored in the relationship list of
records in the attribute library. More specifically, the
attribute properties of rules (or rule properties) may be
stored only in the relationships lists of rules system
concepts. This restriction on where said rules properties
may be stored must be embodied by the system designer
within the program definition of rules properties systems
concepts.
Figure 30 provides a summary and description of
specific rule properties implemented as system concepts in
the preferred embodiment. In general, the rules
properties will be implemented as part of the attribute
properties library. They may however, be implemented in
any of several other taxonomies, as their function as
system concepts can define their meaning independent of
the taxonomy of said concept. In the preferred
embodiment, the rules properties system concepts were
implemented within the attribute library. This illustrates
the flexibility of the system in specific location of
system concepts.
The specific properties identified and described in
Figure 30 and implemented in the preferred embodiment
- should be viewed as merely specific embodiments of the
principle disclosed~herein and most broadly conceived. A
a wide variety of specific rules properties system concepts
~ will occur to the system's designer in the course of
implementing a specific embodiment, given understanding of
CA 02202867 1997-04-16
WO 96/12236 PGT/U595/10077
the principles of the invention and the example of the
preferred embodiment. Each of the plurality of programmed
means comprising the (3i) Concept and Relationship Editor
___.. .. ..,i.,e,. .,~ t-hA r"l ps system
will utilize Lne rez~r~~~~~ .i~~~~ .-~ ...... ----- -j--- -
5 concepts as means for identifying said rules which pertain
to each of the specific programmed means for editing.
Programmed Pattern Recognition,
- Storage and Utilization
The programmed pattern recognition, storage and
10 utilization functions are implemented within the
procedures of the (3i) Concept and Relationship Editor.
The functions are implemented within the editing
procedures so that the editing procedures both utilize and
modify the patterns in order to enable the intelligent
15 operation of the editing function. The functions
implemented in the editing procedures include the ability
to recognize and abstract user variance from the stored
patterns, and to update said stored patterns based on the
observed user variance.
20 Figure 31 provides a Flow Diagram of programmed means
for Pattern Recognition and Storage in the Knowledge
Representation. Upon entering each of the plurality of
programmed editing procedures, Step (31a) is to get any
relevant patterns for the active record, current
25 relationship, and editing procedure to be performed. Step
(31b) checks to see if any relevant patterns) were
obtained.
If no relevant pattern is present, then execute Step
(31d)~ the edit procedure without a pattern. This
30 rocedure may simply be no action at all (the null case.)
p
If a relevant patterns) is present, Step (31c)
indicates use of the patterns) in a suitable procedural _
variant of the editor. The patterns) are used to
constrain the operation of the procedural variant. The
b
re used during the procedural operation.
l
35 ues a
va
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
91
A primary means by which the system concepts are
defined in the programmed code is the embodiment of the
procedural variant that uses the pattern stored in the
relationships characterized by one o= the system concepts.
In some ways, the definition of the system concepts can be
thought of as being embodied in ;:he procedural variant for
the editing operation for which the system concept was
declared.
Step (31e) tests to see if the rule or procedural
variant worked. If it did not, then the failure case
should take it to Step (31d) to exec,ate the procedure with
out a pattern.
.f user selected options occur curing the course of
the editor operation in either Steps (31c) or (31d), which
are ~~vt pa.rt of a patteiii, aia abstraction iS-vTiade, t
heir
the pattern could change to accommodate the new options.
Step (31f) checks to see if the pattern of the rule
changed during the course of the execration of the
procedure. If the pattern did not change, then the
procedure has been successful, and is (31h) done. If the
value did change then the new value needs to be stored.
Step (31g) stores the changed pattern in the source
record for that rule. This is accomplished by storing the
pattern in the appropriate relationship in the record
which a indicated as the source of the relationship. The
means for identifying the source recoxd and the meaning of
source have been defined in previous discussion. In
short, the source record is the record within the primary
Knowledge Representation within which the relationship
storing the pattern is stored as a member of a
relationship list of said source record.
- Step (31h) indicates the completion of the editing
procedure.
CA 02202867 1997-04-16
WO 96/12236 PCTIUS95I10077
92
lc? NATURAL hANGUAG$ INTSRFACS YdITH
THE KNO~PLEDG$ REPRESENTATION
The Natural Language Interface module for interaction
with the Knowledge Representation database (NLI) processes
Natural Language expressions in conjunction with stored
language related concepts for use in the Natural Language
processing system. The NLI is particularly suited for
implementation in conjunction with the Knowledge
Representation database in that the network of
relationships present in the Knowledge Representation is
similar to the network of relationships present in
linguistic expressions.
The Natural Language processing utilizes specific
adaptations of standard Natural Language processing
techniques. The Natural Language Interface module
includes: 1) The sequential use of a functional parse and
a functional pattern match parse which combines the
features of both transitional network analysis and parsing
by differences; 2) The use of a functional identification
of the Word in the Knowledge Representation instead of a
grammatical identification as the basis for the functional
parse; and 3) parsing by differences list based on
function and value instead of value only wherein the
function is identified by means of the system concepts in
the descriptive network of the identified concept.
The Natural Language processing module interprets
human language input expressions and responds
appropriately thereto. The module includes the ability to
and learn new words and concepts contained in
i
ze
recogn
the input expression through interaction with the user
concerning the definition of the new concept. .
The program relies on the information stored in the
Knowledge Representation database, and uses the patterns
the network of the Knowledge Representation to
i
n
CA 02202867 1997-04-16
WO 96/12236 PG'T/US95/10077
93
understand and respond to the linguistic patterns in the
input expression.
In essence, the NLI matches the patterns inherent in
human languages to the patterns embodied in the networks
of the Knowledge Representation. This pattern matching
enables human interaction with the computer in ways
characteristic of human interaction with other people.
This is a result which has heretofore not been achieved on
this scale, and which is a major advance in the state of
the art.
The preferred embodiment uses a natural language
dialogue window, with suitable means for displaying the
dialogue as it occurs. Such means are standard and will
be obvious to the skilled practitioner, therefore they are
not disclosed in detail.
Fig. 34 illustrates a flow diagram for Natural
Language Interface with the Knowledge Representation.
Figure 34 is an expansion and annotation of the Natural
Language Interface of Figure 1. Step (34a) Get Input
Statement From User indicates the process of getting an
input expression from the user. Such processes may
include speech recognition or keyboard input or other
appropriate means. In any case the result will be the
presence of an ASCII string in an input buffer. The ASCI:
string is the expression that is processed by the
subsequent steps of the NLI.
Step (34b) Scans the Input Expression to Token List.
Scanning is a well known process which consists of
converting the input expression into a list comprised of
the words and punctuation present in the input expression.
The token list is passed to the next step.
- Step (34c) represents the Augmented Transition
Network Parsing of the token list. The (34c) Augmented
Transition Network Parsing of the token list results in
the identification of the function of each token in the
token list. The Functional identification is in terms of
CA 02202867 1997-04-16
WO 96/12236 PCTIUS95/10077
94
the system concept (e. g. library) in the descriptive
network of the concept represented by the token in the
Knowledge Representation database.
In standard Augmented Transition Network Parsing, the
identification of the function of each token is in terms
of the standard part of speech (e. g. noun, verb,
ad-iective, etc.) It is this difference in the
identification of the token which is a significant
contribution of the invention to the state of the art.
Another significant feature in the (34c) Augmented
Transition Network Parsing of the Token list, is that
words or expression that are unknown to the Knowledge
Representation are learned through interaction with the
user to ascertain the definition of the expression.
Upon completion of the Augmented Transition Network
Parsing of the Token list, each token has been associated
with a functional indicator, and the overall functional
pattern of the input expression has been identified. The
patterns in the functional definition are then matched to
knawn patterns within the Knowledge Representation. This
matching of functional pattern to the network patterns of
the Knowledge Representation database is accomplished
through a pattern matching algorithm, known generically as
parsing by differences.
Step (34d) Parsing by Differences is the procedure
which matches the functional patterns to the network
patterns of the Knowledge Representation database. The
pattern matching during parsing by differences generally
includes rearranging portions of the pattern to optimize
the search paths required to respond to the input
expression. Such optimization is recommended but is not
required for the operation of the system. The
optimizations will not be discussed in detail here. In
step (34d),-the parsing is based upon parsing of the
tterns and functians identified in the Augmented
pa
Transition Network:
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
Step (34e) Evaluate Structure evaluates the
expression as structured by the parsers. The evaluation
is the action taken by the computer in response to the
input expression. The evaluator must be programmed to
5 evaluate the input structures recognized by the parsers.
Step (34f) Response may combined with step (34e) in
many implementations. The response in general is an
acknowledgement to the user that the input expression has
been satisfied. The response may take the form of a
10 report of action completed based on t:he expression, or may
take the form of display of the answer to a query based on
the action taken. The response can often be integrated
with the program for evaluating the structure, however, in
most cases, some type of a response will occur subsequent
15 to the evaluation to indicate the completion of the
evaluation. Step (34f) Response typically consists of
derivation of a document of one of the plurality of views
of the Knowledge Representation in order to show the user
the results of a requested process, or the answer to a
20 query. As such, Step (34f) often constitutes a transfer
of control from the NLI module to related modules in the
overall system. Step (34f) Response may include returning
to the Natural Language Interface Step (34a). This return
to Step (34a) is indicated in Figure 34.
25 Figure 35 illustrates a flow diagram of program means
for the Augmented Transition Network Parse. The Augmented
Transition Network Parse is comprised of a plurality of
program means, whereby the token list resulting from the
scan of the input structure is associated with the
30 function of that token in the Knowledge Representation
(e.g. Attribute, Component, Project, etc.) This is
distinct from standard methods of Augmented Transition
Network Parsing in that Augmented Transition Network
Parses traditionally associate the input token with the
35 , part of speech represented by that token (e. g. nouns,
adjectives, adverbs, noun phrases, etc.)
CA 02202867 1997-04-16
WO 96/12236 PGTIUS95/10077
96
In order to accomplish the association of the
function of the token with the token, it is necessary that '
the tokens be recognized as concepts within the Knowledce
Representation and that the token be associated with the ,
function of the concept in the Knowledge Representation.
The concepts may be identified be creating supplemental
libraries of concepts in the Knowledge Representation or,
equivalently, through supplementary external files or
indexes identifying the function.
The association is most easily achieved by means of
suitably declared database domains wherein the function of
the token, the token, and its corresponding record
reference number (if it is a concept in the Knowledge
Representation) may be stored. Figure 36 illustrates a
suitable database declaration for storing the associations
it used in the Augmented Transition Network Parse.
Figure 35 Step (35a) indicates the initialization of
the ATN Parse. This is merely the implementation of
various housekeeping functions in making sure that the
database and relevant registers are initialized. Step
(35b) checks to see if the input token list is empty. ~f
the input token list is not empty, then Step (35c) calls
for removing the first token from the token list. This ~s
a simple list operation, that separates the token to be
identified from the list. The reduced list is saved for
d the token is passed forward. Step
i
ng, an
further process
(35d) Identify the Token and Assert the Token with its
Functional Identification in the NLI Function Database.
The tokens are identified by programmed means for
identifying the tokens in the indexes) of the Knowledge
Representation database. Alternatively, the tokens may be
identified by means of code containing the tokens or by
plementary files containing the tokens and/or
of su
p
means
synonyms thereof.
Figure 37 provides a summary of suggestions for
system concepts and associated user concepts to add to the
CA 02202867 1997-04-16
WO 96/12236 PG"T/US95/10077
9'~
Knowledge Representation database. These concepts will
need to be added in order to assure that the variety of
tokens present in a Natural Language expression are in
fact recognized. In column A of Figure 37, there is an
indication of various categories of wards that need to be
accounted for in order to implement a functional system.
This list is not intended to be exhaustive, but
illustrates the type of supplement appropriate to the
Knowledge Representation database in order to insure that
a wide variety of input expressions can be interpreted.
Column B of Figure 37 provides examples of each of the
libraries of concepts. Column C provides notes on how
these concepts were implemented in the preferred
embodiment.
I5 All of the supplementary concepts can be implemented
within a framework of appropriate library system concepts
with associated classes of user concepts within the
Knowledge Representation database. Many of the
supplementary concepts can equivalently be implemented as
specific identification of the words within the ATN Parse
(as is the case with logical operators) or by means of
supplementary files containing lists of words of that
class (as is the case with words to ignore.) Any of these
classes could be implemented by any of the three means.
In the preferred embodiment, various classes have been
implemented in each of the three ways to illustrate the
flexibility of the invention, and the principles whereby
such supplements to the Knowledge Representation may
occur.
In Figure 35 Step (35d) identifies the token and
assert the token with its functional identification into
- the Natural Language Interface functional database.
Unknown tokens will regularly be encountered in the
process of evaluating an input expression. The meaning of
such unknown concepts can generally be derived by the
CA 02202867 1997-04-16
WO 96/12236 PGT/US95110077
98
context of the tokens which have previously been ,
identified.
Step (35e) Define Unknown Token allows for
identification of an unknown token by means of the context
provided by the input expression together with
supplementary user dialogue as required to identify the
token. Said means for defining the unknown token should
include means for adding the concept designated by the
token to the Knowledge Representation database (or
supplementary file) so that the token is recognized in
future transactions with the user.
In general, it is best to implement most of the
libraries indicated in Figure 37 within the Knowledge
Representation database so unknown concepts may easily be
5 categorized and added to the knowledge representation.
1 Note that it is difficult to add system concepts to code,
therefore only those concepts which are categorically
knowable a priori should be implemented as system concepts
(for example, the logical operators.) This means of
identifying unknown tokens and dynamically adding them to
the Knowledge Representation database are unique to this
invention.
System operators provide means for linking programmed
operational concepts to the Knowledge Representation.
This makes these concepts easily available to support view
definition.
There are two classes of system operators which are
particularly useful to the invention: Logical Operators,
and Relational Operators. These may be implemented in
programmed code and may be represented by system concepts
the Knowledge Representation database. These System
i
n
be supplemented by additional operators
ma
y
operators
in a particular knowledge domain.
i
gner
useful to the des
Logical Operators provide the means for implementing
logical queries on the Knowledge Representation. Logical
the standard logic functions (i.e. AND, OR,
Operators are
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
99
NOT, NOR, NAND, etc.) as implemented for list processing.
They are implemented to perform the logical operations on
lists of reference numbers. This provides the basis for
logical statements used in subletting nodes and
relationships in developing particular views of the data.
Relational Operators represent relational concepts in
the Knowledge Representation. Relational Operators
represent concepts typical of prepositions (i.e. in,
through, containing, before, beyond, etc.).
Step (35f) provides for the Transition to the Next
State. The transition is typical of standard
state-transition procedures used in standard transition
network analysis. The formulation of the state-transition
rules is based upon the functional constructs of the
Knowledge Representation, rather than the grammatical
constructs of the NLI. This is the only significant
difference in Step (35f) as required for this invention
and standard techniques. The Step (35f) Transition to the
Next State moves to Step (35b) to see if any tokens remain
in the token list and, if so, the process is repeated for
the next token.
Note that in Step (35d) in Identifying the Token and
asserting the token in the NLI function database that many
known expressions in the Knowledge Representation database
will be comprised of a plurality of tokens. Upon
recognition of a token as being the front token of an
expression comprised of said plurality, additional tokens
should be taken from the input token list to match the
concept name in the Knowledge Representation database.
Figure 38 illustrates a flow diagram for Parsing by
Differences. The Parse by Differences is illustrated in
- simple form since the essence of Parse by Differences is
well understood.
Step (38a) looks to see if the inputted list from the
Augmented Transition Network is nil. If it is nil, then
the process is complete,~and we are done at Step (35d).
CA 02202867 1997-04-16
WO 96112236 PCT/US95110077
100
If the list is not nil, then the list is evaluated in the
y
parse by differences procedure.
The patterns used to match the ATN list indicated in
Step (38b) are comprised of a plurality of program
functions embodying the mapping of the structure of the
ATN into structures that will readily be executed in an
evaluator. This plurality of program means embodying the
patterns is typical and is the essence of a parsing by
differences scheme. In effect, the parse by differences
constitutes a transformation of the structure received
from the ATN. This transformation should be designed to
make the evaluation of the input expression as optimum as
possible.
The patterns in the parse by differences correspond
to patterns in the evaluator; thus, if a successful match
is achieved in Step (38b) the eventual outcome of the
se would be assured to be interpretable. Step (38c)
par
tests to see if a successful match was achieved in Step
(38b). If a successful match Was achieved, the process
returns to Step (38a) to process the balance of the ATN
list. If there was no successful match for the pattern
matching of the ATN list, then Step (38e) the procedure
fails and returns to the NLI for a new query.
Note that in Step (38b), that the pattern match
proceeds by matching substructures within the ATN list.
As these substructures are successfully matched to
patterns defined in the differences parser, the elements
of the ATN list which have been successfully matched are
removed from the ATN list to form a new list. This new
list is then passed forward for further evaluation.
ld ~14N8 FOR AZTTOMATICALLY DBRIVING A PL'QRALITY OF
DOCO~NTS OF T88 l~NOIdI'$DG$ R$PRSSSNTAT10N _
The (ld) module for Automatically Deriving a
Plurality of documents of the Knowledge Representation _
provides the means for view management and derives a
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
101
plurality of view documents from the information network
in the Knowledge Representation database.
The automatic derivation of a document is
~ accomplished by programmed means which embody three levels
of abstraction of document characteristics.
A View is the highest level of abstraction which
embodies identification of relevant classes,
representation of connectivity, and ranges of meaning of
icons in documents.
A Class abstracts the organization of icons within a
document. The procedures embodying organization can be
thought of as embodying a grammar for the document class.
A Type abstracts the icons used to represent concepts
in a document and the principles whereby the concepts are
QGl~flt0~ ~I1Y YOTY~L.~T1~'~f'1I1T TI1~C~ Y1Y/1/1~/~11YGL.
W T/1Y
W iW\rl,.c\i 1V1 iGi.JiGr7G111..a1..iV1l. 111G.7G ~./1WG~A~iiGr7
iVL
selecting and representing icons can be thought of an
embodying a vocabulary for the document type.
Figure 39 summarizes some examples of various views,
classes, and types of documents which can be derived for
the Knowledge Representation. Figure 39 is intended to be
illustrative only, and should not be interpreted as a
restriction of the claims of the invention. Column (39a)
summarizes some examples of views, Column (39b) summarizes
examples of view classes, and Column (39c) summarizes
examples of document types for each class. Each of the
columns in principle comprise an unbounded set of possible
views, classes, and types.
A specific document derived from the Knowledge
Representation database is sent to the desired output
device (display screen, printer, disk, etc.).
Visa Managamaat
- The view management enables the selection of the
view, class, and type of document desired. It generally
enables the coordination and selection of a document from
the information available in the Knowledge Representation
database.
CA 02202867 1997-04-16
WO 96/12236 PG"T/US95/10077
102
Figure 40 illustrates a flow diagram of programmed
means for view management.. The major features are,that it
shows the coordination of Step (40b) the means for
deriving plurality of view documents with Step (40d) the
means for enabling user interaction with the Knowledge
Representation through view documents.
This coordination is facilitated by a system flag
herein called 'Active' which, in the preferred embodiment,
is established by means of a database declaration similar'
to that shown in Figure 41. The declaration of the Active
is comprised of at least four key features.
Item (41a), stores a statement of the view which is
to be derived. This can be accomplished by means of
establishing system concepts corresponding to each view
and recording the reference number as the view in the
Active, or by directly using the names of the various
views. The view will indicate the view, view class, and
the specific type of document desired.
Item (41b), stores the record reference number of a
specific concept for which the view document is to be
developed. All view documents are developed or derived
from the Knowledge Representation with respect to a single
active concept.
Item (41c) stores the database of the active concept.
This is required in systems where multiple databases are
used in that it is not possible to distinguish the
refezence number of the active without designating which
database it came from. The database may be a symbol or
may be a string containing the database file name, or it
may be a system reference number wherein system concepts
blished for each of the database files in every
t
a
are es
database file comprising the system. ..
Item (41d) stores the reference number of the
characterization. This is used in later processing within
the view to indicate which of the relationships are
current in the display, wherein current means which of the
CA 02202867 1997-04-16
WO 96!12236 PCT/US95/10077
103
relationships are currently highlighted or are near the
current cursor position.
The specific order of the items comprising the
declaration of the active as indicated in Figure 41 is
arbitrary. Note also that the system flags comprising the
declaration of active can be implemented in a variety of
means other than database declaration, however, the system
flags identifying these four items must be present in
order to manage the views.
=0 In Step (40a) we indicate the system start-up. In
general, the view management function will be the initial
entry point at start-up of the system. This start-up
should include the assertion of an initial active. Which
view and which active is initially asserted is up to the
i5 ~C.."~lc~. filer . Ill t he preferred C:IILLJUdl~IleRt, tile
System is
started up using a text based tree diagram of the
taxonomical relationships using the root library concept
as the active, in the environment database, with a nil
characterization. Other appropriate selections can be
.0 made. However, an active must be asserted in order for
the process to proceed. Step (40b) indicates the means
for defining a plurality of documents. These means
include the means for using the active to determine which
view, class, and type of document is requested, and for
Z5 deriving the requested class of document relative to the
active concept. The explanation of this Step is expanded
and detailed in subsequent discussion.
If, in Step (40c), no user interaction is required,
then the Step (40d) means for user interaction are
30 bypassed. If user interaction is requested, then Step
(40d) the means for user interaction are invoked.
- The means for user interaction correspond to (le) and
are discussed in detail subsequently. The means for user
interaction include means for retracting the active upon
35 completion of the interaction. Some of the means for
interaction will include the ability to select additional
CA 02202867 1997-04-16
WO 96/12236 PGTIUS95/10077
104
views. Such additional selection will result in the
assertion of an additional active onto the stack. Upon
completion of either Steps (40c) or (40d) the program
proceeds to evaluate whether there are any remaining
actives available on the stack.
Step (40e) indicates the test of whether additional
actives have been set for the system. If so, the process
cycles back to Step (40b) to derive a view document by
means embodied in the plurality of views. If there is no
active left in the stack, then Step (40f) indicates a
system exit. The system exit typically will include an
interaction with the user to verify that exit is desired,
and to allow options for backing-up files or re-entering
the system. A variety of system exit procedures will
readily cccur to the skilled practitioner.
(40b) Dafiniag a Plurality of Documents
Figure 42 illustrates a flow diagram for deriving a
plurality of documents from the Knowledge Representation.
This flow diagram is a generalized abstraction that
applies to all views. Subsequent discussion will
illustrate specific application of these general
principles in developing the plurality of views. The flow
diagrams and the principles disclosed in the following
paragraphs will enable a skilled practitioner to derive a
plurality of views, and extend the principles herein
illustrated to encompass any class of document that is
traditionally used within the knowledge professions, such
as engineering, law, business, etc.
Step (42a) is a test to determine which views are
~p supported by the program. This typically takes the form
3 f a series of tests wherein the program checks to see if
o
if not, it looks to view 2, and so -
w 1 is wanted
i
,
v
e
forth. Step (42b) indicates that an unbounded set of
additional views may be defined by the system implementer.
Within each view, there are a plurality of classes. Step
(42c) checks to see which class is desired. Step (42d)
CA 02202867 1997-04-16 .
WO 96/12236 PCT/US95110077
105
transfers the test to the unbounded sea of class
definitions comprisi.~.g the view.
Each class is comprised of a plurality of types.
Step (42e) checks to see which type of document is to be
developed, and Step (42f) indicates that the plurality of
type is comprised of an unbounded set for each class.
Subsequent discussicn will show typical expansions of
Steps (42b), (42d), and (42f) together with typical means
for testing as indicated in Steps (42a), (42c), and (42e.)
All documents c the Knowledge Representation are
derived with respect to an active concept. The active
concept must be one cf the concepts within the network of
the descriptive relationships that are the basis of the
view. This property makes it fairly easy to implement
programmed means for determining which views may be
applicable to a given concept. This enables the system
designer to implement code which will prompt the user of
the available views for any desired concept. This
provides much easier user interaction in that Steps (42a),
(42c), and (42e) may be reduced to user selection of a
valid view, class, and type for said Active concept. The
preferred embodiment in the appendix includes specifics
adapted to this type of intelligent behavior.
Having successfully identified the view, class, and
type of document that is to be derived for the Knowledge
Representation, the subsequent typical steps occur in
deriving the view. Steps (42g) through (421) are typical
of specific means which must be established for view,
class, and type of document.
Step (42g) is a process of reading a descriptive set
for the type. The descriptive set is comprised of a
plurality of concepts read into the descriptive database.
The concepts are read into the descriptive database by
means of the read functions of the Knowledge
Representation. Subsequent discussion of procedures for
reading a descriptive set will occur hereafter. The
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
106
descriptive set a read by reading the Defining and
Auxiliary relationships for the active concept. Each type '
of document will have specific defining and auxiliary
relationships. '
Step (42h) assigns appropriate icons to the
descriptive set. The type of document being derived
defines which icons are appropriate. The icons are the
symbols for the concepts in the descriptive set. These
symbols can be thought of as the vocabulary of the
language in which the view will be expressed, wherein
'vocabulary' is considered in its broadest sense,
including, but not limited to texts, graphics, sound,
mathematical equations.
The association of an icon with a concept occurs
either in the Descriptive database, or in a supplementary
database. If the association occurs in the Descriptive
database, then suitable domains must be declared to
contain the information required for the definition of the
appropriate icons. Such supplemental structures are
included in the domains declaration of the Descriptive
database in the preferred embodiment of the appendix.
These will serve as examples and illustrations which can
be adapted to accommodate the plurality of views which may
be desired by the system designer.
The implementation of the association of the icons
with the concepts as a separate database requires the
declaration of suitable domains in that database. In
effect, said implementation merely isolates the domains
augmentation required for the descriptive database into a
separate database.
The Descriptive database typically includes the
association of every concept with all of the relationships
within the descriptive network which apply to said
concept. In general, a particular view document will not
all of the relationships of the actives in the
express
working set of the descriptive database. Typically, a
CA 02202867 1997-04-16
WO 96/I223G PGT/US95/10077
107
view document will include a single icon nor the concept
With one or more icons developed to illustrate specific
relationships between the working concepts. Since this is
the case, the icon is generally stored in a separate
structure in the descriptive database frcm the structures
which store the relationships. This icon is then
associated with the active by including the reference
number and the database of the concept illustrated by the
icon.
In some views every relationship is .n fact expressed
within the view. In such cases, the icon may be
associated with each relationship or embodied within the
relationship record in the descriptive database. The
association of the relationship with the icon will need to
include the active reference number, the database, and the
reference number of the characterization Lor which the
icon is developed. In these cases, the icon is typically
some expression of the value. Both means of associating
icons with the descriptive database are ~:~cluded in the
preferred embodiment of the invention.
Step (42i) provides programmed means to locate the
icons within the document according to the class grammar.
The location of the icons is per the standards and
placement typical of the class. The grammar governing the
placement and the relationship of icons in a document is
comprised of the rules whereby the locat;on of the icons
within the display space are established and the rules or
procedures whereby relationships between concepts are
illustrated within the display space.
The procedures for location are a function of the
class, whereas Step (42j) the Development of the
- Relationship Iccns, is a function of the view. In Step
(42j) the relationship icons are developed to illustrate
w the connection and interrelationship of the concepts
~ described in the derived document. Upon completion of
CA 02202867 1997-04-16
WO 96!12236 PCT/US95/10077
108
Steps (42g)-(42j), the resulting information can be output
to an appropriate device.
In Step (42k) we indicate the output of the document
to an appropriate device. Devices may include external
files, monitors, plotters, printers, or any suitable
device for output. It is often desirable to output a
particular view into a file format adapted to the
requirements of some other program. For example, a
drawing could be output as a DXF file for use in various
CARD programs. Such output is easily accomplished by
writing the suitable translator for the output.
Certain output devices facilitate user interaction.
Output to a CI:T or other type of video display terminal
can facilitate human interaction with the Knowledge
Representation through the view document.
Step (421)' tests to see if user interaction was
requested. If so, the process continues with Step (42n),
which is the programmed means for user interaction,
discussed subsequently. If no user interaction is
requested, then Step (42m) the process of deriving the
view document is complete.
Step (42n) indicates the retraction of the active.
This removes the active that was the basis for the
derivation and subsequent output of a document in
preparation of the next activity.
Step (420) provides for the cleanup of the
Descriptive database. This is essentially a system reset,
to clear the descriptive database and view associated
databases in order to initialize all relevant databases,
counters, and associated system parameters in preparation
of the next view document.
Step (42p) indicates the completion of programmed ,
for deriving a plurality of views of the Knowledge
means
Representation. ,
Steps (42a)-(42f) comprise the means for determining
the specific type of document to be developed. Steps
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
109
(42g)-(42j) can be seen as the steps for view derivation
which must be embodied for each view, class, and type of
document. Steps (42k)-(42p) can be seen as the output and
view control procedures. Note that particularly Steps
(42n)-(42p) are an embodiment of view management steps
corresponding to Step (40f). These view management steps
are typically embodied immediately following Step (42k)
the output to the device.
Docum~at Type Selection
The view derivation, Steps (42g)-(42j), must be
developed to accommodate the plurality of views that will
be developed for the Knowledge Representation. The
development of each of these steps is a function of the
view, the class, or the type of document. Figure 43
summarizes the correlation between the view derivation
step and the level of abstraction. Column (43a) summarizes
the view derivation steps for Steps (42g)-(42j) of Figure
42, while Column (43b) summarizes the level of abstraction
in terms of the view, the class, and the type.
Note that Steps (42g) Read Descriptive Set for Type
and (42h) Assign Type Icons to Descriptive Set are a
function of the type of document. Step (42i) Locate Icons
According to Class Grammar is a function of the class of
the document. Step (42j) Develop the Relationship Icons
is a function of the view of the document.
Figure 44 illustrates a flow diagram of programmed
means for deriving a plurality of views in the Knowledge
Representation wherein Steps (44a) through (44e)
constitute testing to determine which view is required.
Figure 44 is an expansion of Figure 42 wherein Step (42b)
is expanded to include three of the specific views
identified in Figure 39 and an indication of the unbounded
extension that is possible to said views.
l 35 -- Step (44d) the Schematic View is a view comprised of
classes of schematic illustrations. Several classes of
CA 02202867 1997-04-16
WO 96!12236 PCT/US95/10077
110
the schematic view are implemented in the preferred
embodiment in the appendix, and are used as the basis for
the illustration of implementing the plurality of classes
for each view and of implementing the plurality of types <
for each class. Fig. 45 contains an illustration of the
program flow for implementing the plurality of classes for
the schematic view.
Step (44a) the Tree View, in some senses, is not a
distinct view, in that a tree view is essentially a
L0 schematic view of the tree class of a type that shows
either a taxonomical or the hierarchical relationships.
However, for the purposes of this discussion and the
preferred embodiment, Tree View is considered to be a
separate view in that it is used only for the fundamental
relationships of taxonomy and hierarchy, and thus enables
user interaction with the Knowledge Representation.
Because Tree view is particularly useful to the operation
- of the system and is used extensively in any user
interaction with the Knowledge Representation, many
optimizations to the basic flow outlined in Figure 42 have
been accomplished within Tree View. For example Step
(44f) Getting the Tree has combined Steps (42g) and (42h)
into a single operation wherein the children lists in the
concept records of the Knowledge Representation database
are used to assemble the tree description. The names of
the concepts in the Knowledge Representation database
constitute the icons expressed in the view.
Steps (44a) through (44e) illustrate some of the
views that are given as examples in Figure 39 Column
(39a) .
The flow for Step (44a) Schematic View indicates that
Step (44i) Developing the Relationship Icons and Step r
(44j) Output to Device and Step (441) Test for User
Interaction are common to all classes of Schematic view:
This is a way in which that commonality may be
implemented,-by having all class derivations return to the
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
111
standard procedures as indicated in Steps (44i), (44j),
and (441).
These steps correspond to Steps (40j), (40k), and
' (401) of Figure 40. These steps must be implemented with
respect to each view. Step (44f) refers to Figure 45
which is an elaboration of the means whereby the classes
of the schematic view are implemented and corresponds to
Steps (42c) and (42i). In principle, an unbounded set of
classes may be implemented for each view. Steps (45a)
through (45d) illustrate some of the classes of the
schematic diagram view that are given as examples in Fig.
39 Column (39b). Again, as indicated in Step (45e), the
classes comprise an unbounded set which may be implemented
to meet the system developer's objectives for the system.
Steps (45j) through (45m) indicate that the location of
the icons is acccrding to the grammar of the view. This
principle was discussed earlier. This illustrates that
the plurality of types that may be developed for each
class will all return for the location of the icons
according to the standard grammar for that class. Each of
Steps (45f) through (45i) indicate that an unbounded set
of types may be implemented for each class.
Step (45f) refers to Figure 46 which is a flow
diagram of programmed means for deriving a plurality of
schematic cluster diagram types of the Knowledge
Representation and corresponds to Steps (42e), (42g), and
(42h). Again Step (46e) indicates that an unbounded set
of additional types may be developed for each class of
drawings. The types of documents illustrated in Steps
(46a) through (46d) correspond to those in the examples of
Figure 39, Column (39c), for the schematic cluster
- diagram. The figure emphasizes that i.n Steps (46f) and
(46g), we have the correspondence of development of Steps
_ (42g) and (42h) for the specific type of document being
developed. Similarly, Step (46h) and (46i) for the
Process Flow Diagrams (PFD), Steps (46j) and (46k) for the
CA 02202867 1997-04-16
WO 96/12236 PCTIUS95/10077
112
Wiring diagram, and Steps (461) and (46m) for the Circuit
diagram correspond to Steps (42g) and (42h).
(42g) Read Descriptive Sat for Typ~
Figure 47 illustrates a flow diagram for reading ,
descriptive sets. This is an expansion of Step (42g) and
illustrates that reading the descriptive set is comprised
of two main processes: reading the defining
relationships, and reading the auxiliary relationships.
Defining relationships are the relationships which the
document is designed to illustrate. The defining
relationships will form a network of concepts essential to
the document. There are a variety of auxiliary
relationships which are expressed for each of said
concepts. These auxiliary relationships are relationships
of the concepts in the network of the defining
relationships to concepts not comprising said network.
Such auxiliary relationships are typically read to only
one or two levels removed from the concept in the network
of the defining relationship.
Step (47a) reads the defining relationships for the
type of document being developed. Step (47b) reads the
auxiliary relationships for the type of document being
developed. Upon completion of reading both the defining
relationships and the auxiliary relationships, the process
of reading a descriptive set is complete. In each case
the reading makes use of the network operations of the
primary Knowledge Representation in order to read a
description of particular concepts into the descriptive
database.
The principle of reading is that documents are
fundamentally based on the display of relationships in a
set of related concepts. One of the reasons that a -
3g plurality of documents has been developed to embody
knowledge is that the human mind and the available means
of knowledge conveyance are inadequate to the
representation of many relationships between the concepts.
CA 02202867 1997-04-16
WO 96/12236 PG"T/US95/10077
113
Because of this, each document has a small characteristic
set of relationships that the document: is developed to
explicate. The relationships explicated in the document
are herein called the defining relationships of that
document type.
In order to facilitate clarity, most documents are
based on a single defining relationship. More complex
documents may be based on a plurality of defining
relationships. In our experience, there are very few
types of documents in which more than a single defining
relationship is expressed.
Figure 48 provides examples of defining and auxiliary
relationships for various types of documents. The
examples of Figure 48 are based on a selection of the
documents identified as examples in Figure 39.
Column (48a) identifies the type, Column (48b) identifies
the defining relationships characteristic of the
corresponding type, Column (48c) identifies the depth to
which the defining relationships are read, Column (48d)
identifies the auxiliary relationships characteristic of
the corresponding type, and Column (48e) identifies the
depth to which the auxiliary relationships are read.
The idea of depth as identified in Columns (48c) and
(48e) is that of chaining through the relationships. For
example, if concept A refers to concept B in a
relationship, you would read concept A., identify the
relationship, and read concept B. Reading concept B
would constitute one step. If concept B, in turn, has a
relationship with concept C, and concept C is read, that
constitutes two steps. If concept C has a relationship
with concept D, and concept D is read, that constitutes
- three steps, and so forth. In each case, the relationship
must have characterizations of the same attribute class.
_ Noted in Fig. 48, that most defining relationships
are characterized by a single attribute class. This
however, is not necessary, in that a plurality of classes
CA 02202867 1997-04-16
WO 96/12236 PG"TIUS95/10077
114
may constitute the set of defining relationships. Fig.
49 and Fig. 50 illustrate a specific implementation '
suitable for Steps (47a) and (47b), respectively. Figure
49 illustrates a flow diagram for reading defining ,
relationships. Step (49a) gets the defining relationships
in terms of the reference numbers of the system concepts
identifying the attribute classes that will characterize
the relationships. This means for example, that if the
defining relationship in a wiring diagram is a wire
connection, then under the connections class of
attributes, there should be a concept of wire as a system
concept. The reference number of wire would be the
defining relationship system concept. Attribute class
concepts, such as wires, are not used as characterizations
of relationship. They are, however, the class concept of
a plurality of user concepts. These user concepts are in
fact used in the characterization of relationship.
Step (49b) checks to see if the set of defining
relationship system concepts is nil. If it is, then Step
(49d) the process of reading the defining relationships is
complete. If Step (49b) is not nil, then Step (49c) we
get the next defining relationship system concept (or
attribute class system concept) and identify all user
concepts constituting said attribute class.
Step (49e) checks the Descriptive database to
determine if there are any relationships characterized by
one of the user concepts for the attribute class that we
are currently testing for which there is a relationship
t which is not a member of the descriptive
with a concep
database. If there is a concept referred to in a
relationship characterized as one of the defining
relationship. then we need to read the value, by reading -
the concept indicated in that value, into the descriptive
database, at which point we recycle and continue with Step
(49e) until all values for the descriptive relationships '
onding concept in the descriptive database.
have a corresp
CA 02202867 1997-04-16
WO 96112236 PCT/L1S95/10077
.15
Upon completion of Step (49e), we return to Step
A
(49b) to determine if there any additional defining
relationships defined for ~:~is type of document. If there
are no more relationships .n the list.of references for
the attribute classes characterizing the defining
relationships, then the process is complete.
Note that Step (49f) :gay instantiate controls to
assure that the defining relationships are only read to a
specified depth. Note fur~her that i.f additional values
are read in Step (49f) then the relationships maintained
by the concept read in Step (49f) should also be read for
each of the def'_ning relationships.
Fig. 50 illustrates a flow diagZ-am for the programmed
means for reading the auxiliary relationships. Step (50a)
gets the auxiliary relatic~ship system concepts in much
the same manner as was explained in Step (a) of Figure 49.
Step (50b) checks to see if the list of auxiliary
relationships is nil. If .t is, then Step (50c) the
process of reading the aux_liary relationships is
completed. If it is not r.:.l, then Step (50d) gets the
next relationship, which is an attribute class concept and
nets all of the user conceits of that class which will
characterize the auxiliary relationships.
Step (50e) checks the descriptive database to
determine if there is a defining member which has an
auxiliary relationship or relationship characterized by
one of the attributes of the auxiliary relationship, which '
is connected to a concept ~ahich is nat yet present in the
descriptive database. If so Step (50f) gets that defining
member and Step (50g) reads the auxi7.iary relationships
for that defining member to the depths specified for the
- auxiliary relationship. This process is repeated until
all defining members have ad all auxiliary relationships
read to the specified dept'_~., at which point the process
resumes with Step (50b).
CA 02202867 1997-04-16
WO 96/12236 PCT/US95110077
116
Step (50b) then chec:~s to see if there are any
additional auxiliary relationships, and if so performs
Steps 'S0d)-(50g) as apprcpriate for said additional
auxiliary relationships. The cycle terminates when the ,
list of auxiliary relationships has been exhausted, at
which point Step (50c) the process is complete.
(42h) Assign Type Icoas to Descriptive Set
Step (42h) assigns an icon to descriptive set based
on the type of document being developed. The means for
assigning the icon expanded and illustrated in Fig. 51.
Fig. 51 illustrates a flow diagram for assigning
icons to a descriptive set. Such procedures must be
implemented for each type of document supported by the
system. There are two primary methods whereby an icon may
be associated with the concept: stored icons, and
programmed procedures. Most implementations of the
programmed procedures for assigning .cons to a descriptive
database will have a combination of stored icons and
programmed procedures.
An icon may be explicitly defined and stored as a
concept in the Knowledge Representat:.cn. This storing
icons typically requires the declarat=on of additional
specialized database domains within the relationship list
to accommodate the data types required for icon
definition. A variety of such supplementary data types
are declared in the preferred embodiment in the appendix.
A second method whereby an icon may be defined is by
programmed procedures for developing the icons. Many
types of views have characteristic icons whereby they
represent the concepts displayed withi:. the document.
Such characteristics may be embodied in programmed
procedures whereby the icon may be developed. ,_
In Figure 51, Step (51a) is to identify the type of
document which is being developed for the class. Step
(Slb) '_ndicates that a plurality of types may be defined
for each class. Step (51c) identifies a concept in the
CA 02202867 1997-04-16
WO 96112236 PCT/US95/10077
117
descriptive data~ase without an icon. If there are no
concepts in the cescriptive database without associated
icons, then Step (51d) the procedure is completed. If
there are concepts without icons associated, then Step
(51e) would get the concept reference number with which no
icon has yet bee_~_ associated.
Step (51f) rests to see if an icon has been stored
for the concept without an icon. If an icon has been
stored, it will ~e indicated as the value in a
relationship. System concepts should be implemented for
each type of document to characterize the relationship of
the concept with its icon. This system concept
identifying the czaracterizing of the relationship with
the stored icon will identify~the icon. If in Step (51f),
an icon is ident_ried as being stored, then Step (51g)
reads the icon ar_3 initializes the values of the icon with
the values of the concept.
Step (51h) ~est to see if the icon is defined as a
procedure. This test is generally comprised of an
examination of tie types of relationships maintained by
the icon to deter-,nine if the types of relationships fit
any of the predetermined patterns, whereby concepts
suitable for procedural development of an icon may be
identified. If an icon procedure is available for the
concept, then Step (51i) will create the icon for the
concept according to the programmed means of said
procedure. If no icon procedure is available for the
concept, then Step (51j) will bypass the concept.
Bypassing the concept means that the concept will not
appear in the docsment. Since no appropriate vocabulary
is available for the concept to be expressed in the
document, it simply will not appear. In general, the
bypassing includes reforming the relationships of the
concept so that =emporary relationships are established in
the descriptive catabase which makes it appear as if
CA 02202867 1997-04-16
WO 96112236 PCT/US95/10077
118
concepts related to each other via the bypassed concept
were directly related to each other.
The outcome of Steps (Slg), (51i), and (51j) is that
the concepts without an icon will now have an icon in the ,
Descriptive database, or will be bypassed. Each of these
steps returns to Step (Slc) to determine if any additional
concepts are present in the descriptive database for which
no icon is yet present.
Notes on Implementation
Three types of documents are included in the appendix
which are particularly useful in concept editing and in
establishing the fundamer_tal relationships and user
relationships of the Knowledge Representation Database.
They are called "TREEVIEW", "FORMVIEW", and "DRAFTVIEW".
Note that these views are not views in the formal sense of
'view' as defined herein.
Tree View displays the fundamental relationships
between the concepts in the Knowledge Representation.
Together with the user interaction with the Knowledge
Representation through the tree view, the Tree View
enables a user to create new concepts in the Knowledge
Representation database and establish and edit fundamental
relationships between the concepts in the Knowledge
Representation database. Tree view provides a basic tool
whereby the user may manipulate the fundamental
relationships of the Knowledge Representation.
Form View provides the essential tool whereby the
user may interact with the user relationships of the
concepts in the Knowledge Representation database.
Draft View enables a user to create and define a
graphics icon for concepts in the Knowledge Representation
database.
The icon editor represents the embodiment of the
relationship editor so that it can be immediately accessed
to edit the class of values typical of graphical icons.
No derivation of the descriptive set is required, no
CA 02202867 1997-04-16
WO 96/12236 PCTIUS95/10077
119
assignment of icon is required as the icon is what
comprises the relationship, and no location or connection
of the relationships based on the view grammar is required
. as these are irrelevant to discrete icons.
It may be desirable to treat additional classes of
editors as if they were views in order to facilitate the
user interaction with values of the data types supported
by the system. This is strictly a system designer's
choice, and could be implemented through other routes of
editing.
These three views, or their equivalent, are required
for successful operation of any embodiment of the
invention in that all embodiments must provide: means for
manipulating fundamental relationships; means for
m~n~nyl atinrr i4gcr r°~ ~~; ..,.,~1,; . .7 F...,. .~..ct
t. y:~w.ivu~amp~, aim vTiccWS ivi ucii3Ying
icons, if graphical representations of the Knowledge
Representation are desired.
(le) MODULE FOR USER INTERACTION WITH THE KNOWLEDGE
REPRESENTATION THROUGH THE VIEWS
The (le) Module for User Interaction with the
Knowledge Representation through the views is comprised of
a plurality of programmed procedures to accommodate the
types of interaction appropriate to each view.
In practice, the programmed procedures for interaction are
implemented in conjunction with a specific view. Such
view actions often contain variants based on the specific
classes and types of documents comprising the view.'
However, in general, the majority of the functions for the
program which enables user interaction will be common to
all classes of documents comprising the view. The
plurality of programmed procedures for (3b) Record
operations and (3e) Network operations and the (3i)
Concept and Relationship editor, are employed and
_35 coordinated by the programmed procedures for user
interaction. The structure of the means for enabling
user interaction with the Knowledge Representation through
CA 02202867 1997-04-16
R'O 96/12236 PCT/US95/10077
120
the view documents is illustrated in Figure 52. The
illustrated are typical of event driven means, in common
practice within the state of the art.
Figure 52 illustrates a flow diagram for user
interaction with the Knowledge Representation through the
view documents. Step (52a) indicates an event logger. An
event logger consists of programmed means for scanning the
input devices to the computer to detect a user event,
together with the means for storing said detected event in
a register from which said logged event can be used to
select the appropriate action.
Step (52b) indicates a plurality of programmed means
for acting on the event. The events which will be acted
upon must be specifically identified and enabled by the
system designer, and correlated with programmed means
defining the action which the system is to perform in
response to the event. It is with respect to the types of
actions and the means for determining which action can
occur in response to a user event, that the invention
makes novel contributions which are subsequently
disclosed.
Some of the user events will signal that the user is
done with the current view document. Such signalling can
be indicated by asserting a flag indicating '3one' in an
appropriate register. Step (52c) tests the register to
see if the 'done' flag has been asserted. If not, then
the program returns to the means of the (52a) event
logging. If 'done' has been asserted, then Steps (52d)
and (52e) provide means for cleaning up the data
associated with the view, resetting relevant registers,
and proceeding to the next operation in the program. Step
(52d) provides the means for clearing the view active.
The view active is the means for specifying the initial
concept around which the view document is to be derived.
The function meaning of active was discussed in connection
with the means for deriving a plurality of view documents.
CA 02202867 1997-04-16
WO 96112236 PGT/US95l10077
121
Essentially, the active _s an assertion to a register of
the type of document to be derived, the concept with
respect to which to document is to be derived, the
database of said concept, and the current attribute of
said concept.
Step (52e) provides the means for clearing all view
related registers and databases in order to reset them in
preparation for the derivation of the next view.
Several embodiments of steps 52(a), (c), (d) and (e)
are provided in the appendix.
The nature of the triggering events to be (52b)
processed are totally at the discretion of the system
designer. The triggering event may be a user action with
a function key, a mouse button, a mouse motion, a keyboard
entry, vocal--input t~rouah-a speech-recognition-system,
etc. Both the specific event, and the programmed response
thereto are implemented at the discretion of the system
designer. While both the events and t:he programmed
response are essentially arbitrary, there are reasonable
events and responses to enable. The preferred embodiment
in the appendix includes suggested events and responses
that would be suitable for any implementation of the
invention.
The actions based on the events of Step (52b)
comprise a plurality of programmed procedures for actions
in response to the speci~ied user event. Many of these
actions will employ standard programming techniques~to
enable view manipulation (e. g, scrolling, panning,
zooming, etc.) and editing (e. g. changing values, etc.)
Because of the nature of the invention, several unique
abilities are enabled which can be called upon by a user
- - specified triggering event.
The invention includes two novel features in this
respect which are (1) determining which of programmed
responses are appropriate by evaluation of the contextual
meaning of the icons comprising the view document; and (2)
CA 02202867 1997-04-16
WO 96112236 PCT/US95110077
122
interacting with the networks of the Knowledge
'
Representation. The means for deriving a plurality of
views identified the assignment of an icon to each of the
concepts and relationships represented in the view
document as one of the essential defining characteristics
of the invention. Because each concept is represented in
a network of relationship to other concepts, it is
possible to consider the icon as representing not only the
concept, but a plurality of the implied relationships and
ZO associations of that icon and because the plurality of
meanings are associated with the icon in the descriptive
database, the invention enables a variety of novel
interpretations of each icon., These implied meanings of
the icon are used as the basis for developing context-
sensitive interaction with the Knowledge Representation.
This is accomplished by means of decision trees designed
for each view wherein the substance of the decision trees
is the evaluation of the implied context. Such decision
trees are not possible in the current state of the art in
that the entities comprising documents are not icons
explicitly connected to Knowledge Representations.
Figure 53 provides a summary of the icon symbology
implicit in the descriptive database. The icon can
symbolize any of a number of concepts in the Knowledge
Representation database because of the association of the
icon with a plurality of record reference numbers. The
implications of the icon association with concepts in the
Knowledge Representation database are the basis for the
novel actions made possible by the invention. The
association referred to is stored in the descriptive
database, disclosed previously, wherein the icon is
associated with references to a plurality of records in
the Knowledge Representation database, and with the
location of said icon within the document display space.
The icon may be interpreted as representing any of the
items associated with the icon in the Descriptive
CA 02202867 1997-04-16
WO 96/12236 PGT/L1S95/10077
123
database. These items are associated by the domains
declarations of the Descriptive databaae and of the icon
structures in the Descriptive database.
There are at least nine items which are explicitly
associated with the icon in the Descriptive database.
These nine are enumerated in Column (53a). Each of these
associations can be interpreted as the item symbolized by
the icon. Column (53b) summarizes what each of these items
associated with the icon are that the icon can be
interpreted as symbolizing. Notice that, of the nine
items associated with the icon, six of them are concept
record reference numbers. Two of the items are entities,
comprising either the icon per se, or a value. The final
one is a definition of a location, or region in the display
occupied by the icon. Based on this, it is clear that the
icon, generically, can symbolize three possible types of
items: (1) a concept record reference number; (2) a
region or location in the document display space; and (3)
entities comprising the icon or items displayed in the
document display space.
Figure 54 provides a summary of the symbol
interpretation for each of the three types of items which
the icon can symbolize (i.e. location., entities, or
concept record reference numbers). Three icon
interpretations are summarized in Column (54a). Each of
these icon associations can be interpreted in a variety of
ways. The ways in which the associations can be
interpreted are summarized in Column (54b). Column (54c)
indicates a subsequent Figure number illustrating a flow
diagram of programmed means embodying the corresponding
interpretation.
- There is only one item for which the icon symbolizes
location, that being the location of the icon; there are
.. two items for which the icon symbolizes the entities; and
there are six items for which the icon. symbolizes a
concept record reference number. Each. of the two possible
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
124
symbolized entities can be interpreted in at least the
four ways shown in Figure 54. Similarly, each of the six
concept record reference numbers which the icon can
possibly symbolize can be interpreted in at least the
thirteen ways summarized in Figure 54. In general, there
will be approximately one hundred possible interpretations
for an icon. In specific usage, this range of possibility
is greatly reduced.
The richness of possible interpretation associated
with each icon provides for behaviors within the system
that are without precedent. Such behaviors are based on
the evaluation of the context of the event and of the icon
to determine which interpretation of the icon should
prevail. When appropriately implemented, such context
evaluation provides the sense to the user that the
computer is anticipating what the user is thinking about,
or reading their mind. This is possible because of the
. richness of possible meaning, which is explicitly enabled
by~ the associations within the Descriptive database.
20. Every event handler in the event processing Step
(52b) must determine the interpretation of the event.
This is done by programmed means embodying a decision tree
similar to that illustrated in Figure 55.
Fig. 55 illustrates a standard decision tree for
event processing. This is the type of decision tree
embodied in all standard event-based programs and is
presented to contrast with the means of this invention.
In Step (55a), a plurality of events are defined which the
system will respond to. These events are explicitly
identified by the system developer, and each of the
branches of this decision tree are a test to see whether
the logged event of Step (52a) is one of the plurality of
events known to the event processor. Given the detection
f a known event in Step (55a), then Step (55b) decides
o
h of a plurality of possible procedures to invoke in
hi
c
w
In many cases, the plurality of
the event
.
response to
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
125
,.
procedures in Step (55b) is reduced to a single procedure.
However, in general, there are a plurality of procedures,
and the specific procedure that is invoked is a function
-of the command history and previous system flags that have
been set. The specific procedure is then determined based
on the command history and system flags that are present.
The means of event processing far this invention are
illustrated in Figure 56 which shows the recommended
decision tree for icon symbol interpretation.
Step (56a) is to segregate the interpretation by
view. Each view is designed to show particular
relationships and a subset of concepts linked by those
relationships. Each view document is showing a small
subset of the concepts and relationships present in the
Knowledge Representation database. The icons which
symbolize those concepts and relationships will have
meanings that are intuitively clear to the user.
Each view document will be interpreted by the user as
having specific implicit meanings. The symbols will be
interpreted in relation to these implicit meanings. The
system designer will need to enable specific events and
interpretations based on the users likely perception of
the meaning of the icon, given the context of the view
document. Therefore, the view is a primary determinant of
the meaning of the icons in the view.
Step (56b) indicates that, given. the view, every view
event processor will have a set of interpretable events.
The same considerations as were discussed for Step (55a),
apply to Step (56b). The events of Step (56b) must be
specifically identified and enabled by the system
programmer. For each interpretable event, the icon will
' correspond to one of the possible symbols. In general,
the possible associations symbolized by the icon will be
significantly reduced based on knowledge of the view and
t:~e event. In most cases, knowing the view and knowing
the event will indicate the icon as symbolizing a
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
126
particular association. Step (56d) indicates that an
appropriate procedure or process will be invoked which
embodies the interpretation appropriate to the association
symbolized by the icon. Step (56d) indicates that the -
response may consist either of a procedure, which
corresponds to Step (55b). or may consist of a process.
The need for processes in Step (56b) is a distinguishing
feature of this invention in that the process may be
comprised of a recursive call to another view or may
IO consist of a call to one of the entity class editors
defined for the data types of the icons and values of the
system. A process which is a recursive call to another
view will obviously have an even processing decision tree
similar to that of Figure 56.
A process that corresponds to one of the editors will
have its own decision tree for event processing which will
be similar to that illustrated in Figure 55. In this
sense, the means of the invention can be seen as a
step to, or a superset of, the standard means
preliminary
-
for event interpretation as embodied in Figure 55.
In general the processes will in turn provide
additional decision trees for determining the significance
of the event. This stacking of the decision trees is a
distinguishing characteristic of this invention.
Figures 57 through 72 embody portions of typical
procedures which embody the means for interpreting the
icon symbol. The Figure numbers are associated with the
icon symbol and the interpretation in Column (54c). The
programmed steps illustrated in the figures are the
essence of the plurality of procedures embodying an
interpretation of as association symbolized by the icon.
The figures are not intended to exhibit the complete .
specific behavior of a given procedure. Rather, they are
the generalization of the essence of the procedure. A .
of specific embodiments of the illustrated
t
i
y
e
wide var
procedures will be developed by the system designer to
CA 02202867 1997-04-16
WU 96/12236 PGT/US95/10077
127
y accommodate the various meanings of the icons in the
plurality of views. In the plurality of procedures
comprising Step (56d) there will be many embodiments of
' the same procedure, wherein the specifics of the
embodiment are a function the event which triggers the
interpretation, and the association symbolized by the
icon.
The application of the illustrated programmed steps, which
embody the plurality of possible interpretations for the
symbols, are amply illustrated in the preferred embodiment
included in the appendix. Fig. 5'7 illustrates a
typical flow diagram for updating the active reference
based on the user event location. This is possibly t'te
,
most frequent use of the icon
location in the processes
for interpretation. The identification of the active
distinguishes all of the information associated with the
icon based solely on the location of the event within the
display space. Step (57a) gets the event location out of
the event log. The event location is typically expressed
in terms of screen coordinates, either as cursor location
or as mouse location. In either case, this location pan
be matched to the region occupied by the icon.
Step (57b) matches the event location to the location
occupied by the icon to determine which icon the event
'
occurred within. Step (57c) determines if a match was
found. If no match was found, then the event occurred
outside of an icon, in which no update occurs. If a match
was found in Step ( 57c ) , then Step ( 5'7d) updates the
active based on the reference number of the active which
the icon represents. Updating the active is the process
of replacing the reference number of the active concept in
' the active register. The active register is a means .or
recording which concept reference number is currently
active in the view.
Fig. 58 illustrates a flow diagram for highlighting
entities. This is one of the most frequent uses of the
CA 02202867 1997-04-16
WO 96/12236 PCT/US95110077
128
interpretation of the icon as symbolizing associated
entities. Step (58a) gets the entities and the location
for the active concept. Step .~8b) passes the entity list
ar_d the location to the output display driver, together ,
with the flag for highlighting. The output then refreshes
the screen with the entities ccmprising the symbol
highlighted.
Fig. 59 illustrates a flow diagram of programmed
ns for interpreting icons as system concepts associated
mea
with icon entities. The outcomes of this process are
indicated in Steps (59e), (59h), and (~9j.) The outcomes
illustrated are the generalizat_on of the three possible
interpretations for the system concepts associated with
In specific embodiments, it is often
entities
i
.
con
possible to know a priori that only one of the three
possible interpretations apply. As such, the process can
be simplified to embody the specific relevant
interpretation. Step (59a) is ~o get active reference
number, Step (59b) is to get the relationship
characterizatior_ reference number, and Step (59c) is to
get the icon-source reference number. These three
reference numbers will be used as the basis for
determining the system concepts associated with the icon
entities. Step (59d) test to see if the source reference
number is equal to a known system concept. If the source
is a system concept, it indicates that the icon was
derived by a programmed procedure. The system concept
ssociated with those entities is therefore the
i
s a
that
procedure whereby the icon was developed for the
illustrated concept. As~such, =he output Step (59e) will
reference number. If the icon source is not
be the source
(59_) gets the source library. ,
t
ep
a system concept, then S
e library reference number will indicate whether
The sourc
stored entities.
the entities comprising the iccn are
(59g) tests to see if the library equals the
St
3~ ep
If the library c. the source is the icon
icon library.
CA 02202867 1997-04-16
WO 96/12236 PCTYUS95/10077
129
library, t~:at means that the iccn entities were a stored
value and the system concept relevant to the icon is the
library class concept associated with the library and the
- concept. Step (59h) gets the class system concept for the
source, and Step (59i) outputs the icon class system
concept. The programmed procedure for determining the
icon class system concepts is outlined in Figure 71,
discussed subsequently. If the library is not the icon
library, then the system concepts relevant to the
characterization of the entities must be the
characterization system concepts, which are the system
concepts for the relationship characterization contained
in Step (59b). Step (59j) the prccedure for getting the
characterization system concepts is elaborated in Figure
I5 71, discussed subsequently. Step (59k) shows that the
output wil? be the characterization system concepts.
Fig. 60 illustrates a flow diagram for interpreting
an icon as the abstraction associated with the icon
entities. The abstraction associated with the icon
entities is the abstraction associated with the Pattern
Recognition, Storage, and Utilization as discussed in
connection with Figure 1. The implementation of the
abstractions is an optional enhancement to the system
which the system designer will, .n general, choose to
implement because of its power. The 'point cf this
interpretation is to identify which abstractions may be
relevant to the relationships of the active concept
symbolized by the icon.
Step (60a) is to get the active record reference
number, Step (60b) is to get the relationship
characterization, and Step (60c) is to get the abstraction
relationsh'_p which applies to the active and the
relationship characterization.
Fig. 61 illustrates a flow diagram of programmed
means for =nterpreting an icon as an entity editing
procedure. This interpretation will result in calling the
CA 02202867 1997-04-16
WO 96112236 PGT/US95110077
130
appropriate editor to edit the entities comprising the
icon. The steps illustrated in Figure 61 show a
generalization for determining which of the possible
editors apply to the entities comprising the icon. In .
general, the class of editor can be determined promptly by
examination of the data type of the entities, and
therefore a full sequence of test illustrated in Steps
(61c), (61d), and (61e) will not be required. However,
the elimination of the steps in a specific case will
readily occur to the system designer once the
generalization as illustrated in Figure 61 is clearly
understood.
Step (61a) gets the entities and the source of the
entities. Step (61b) typically unreads the event that
triggered the interpretation. This is done so that the
event may be-used within the editor as the first event for
the editing process. This is not always required, in that
it depends on the system designer's choice as to the
triggering event for the editing sequence. For example, if
such as <F2> is used to invoke the editor,
a function key
,
there is no point in unreading <F2>, as its entire
symbolic significance was the invocation of the editor.
If, however, the keyboard is enabled for invoking the
editor, then the user might strike the letter <A>,
intending to insert an 'A' in the icon at the current
position. In such case, the character 'A' and the
position should be unread or fed forward to the editor, so
the 'A' will in fact be inserted at the desired position.
The editor will control the modification of the entity
list comprising the icon.
Step (61c) is a test to determine if the icon is
comprised of a data type suitable for editing in the text
editor. If so, the Step (61f) passes the entity list,
and the unread event to the text editor. Step
source,
if the entity data type is suitable -
(61d) checks to see
for processing in the graphics editor. If so, the
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
131
graphics editor is invoked, and the entity list, source,
and the event pass forward to Step (61g) the graphics
editor. The testing may proceed to Step (61e) which
provides for a plurality of additional. editors as required
to accommodate the entity classes comprising the icons
supported by the system. Said plurality of editors will
be designed and implemented by the system designer in
accordance with the principles disclosed for the Knowledge
Representation, and each type of icon will have an
ZO associated editor. 2n all cases, the results of the
editor will be passed to Step (61h) which will replace the
entities in the descriptive database. They may also
replace the entities in the source record in the Knowledge
Representation database.
15 Step (61i) indicates that a flag should be set to
indicate that entities have been updated. This flag may
be used to remind the user at the completion of activity
Within a view document that the entities within the view
document have been modified and, possibly, should be saved
20 to the primary knowledge representation. This is only
applicable if Step (61h) replaces the entities in the
descriptive database, without updating the Knowledge
Representation database.
Fig. 62 illustrates a flow diagram for interpreting
25 an icon as procedure for transf erring view derivation to
the active. Many view documents are developed relative to
a specific concept. Shifting the concept that the
document is developed relative to will, in general, change
the document, even though the view, the view class, and
30 the document type remain constant, the specific embodiment
of the document will be altered based on the concept that
. is the basis for the derivation.
Step (62a) is to get the active concept. Step (62b)
is assert 'done.' 'Done' is asserted to a register which
~
35 will be used in Step (52c) as a flag to proceed with Step
(52d) the clearing the view active and Step (52e) cleaning
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
132
the descriptive database for the document. Step (62c)
asserts the current view type with the current active into
the active register. This assertion will provide a
redundant assertion of the active. This is required so
that when Step (52d) occurs and we clear a view active,
one of the redundant pair will be removed, leaving the
current redundant pair to serve as the basis for the view
regeneration.
Fig. 63 illustrates a flow diagram of programmed
means for changing a view of the current active. This is
similar to the procedure illustrated in Figure 62, except
that a different view document is being requested for the
active. Step (63a) gets the active concept. Step (63b)
determines choice of views available from the context of
I5 the active. Step (63c) provides for the selection of a
new view for the active concept. Step (63d) tests to see
whether a new view was in fact selected. In it was then,
Step (63e) update the view and the active and Step (63f)
assert 'done.' The result of this will be that the next
view and active will be the new requested view of the
active node. Step (63c), in.general, will consist of a
menu of views appropriate to the active. In many cases,
the triggering event will be such as to indicate transfer
to a specific view that is a logical view to transfer to,
based on the user profile, and the current view.
Fig. 64 illustrates a flow diagram for interpreting
icon as a procedure for identifying library system
th
e
concepts of the active. It consists of a single step,
which is to (64a) get the library of the active.
Fig. 65 illustrates a flow diagram for interpreting
abstraction associated with the icon. Step
the icon as an
(65a) is to get the reference number of the symbol, and
(65b) is to get the abstraction. associated with that
Step
The point here is that every symbol
mber
.
reference nu
bstraction associated with it, which
potentially has an a
abstraction can be readily derived based on patterns of
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
133
reference in the descriptive database, and within to
relationship storing the abstraction.
Fig. 66 illustrates a flow diagram f or interpreting
the icon as a procedure for concept and relationship
editing. The essence of this procedure is the concept and
relationship editor of the Knowledge Representation
database. Step (66a) is to get the symbol reference
number, and Step (66b) is to call the concept and
relationship editor of the Knowledge Representation
database for the symbol reference. A general call to the
concept and relationship editor will result in a menu of
relevant editing operations which may be performed with
respect to the referenced concept. The call to the editor
of Step (66b) in speci~ic procedures may bypass this menu
function and directly call the desired editing process.
Fig. 67 illustrates a flow diagram for interpreting
an icon as an external procedure. External procedures are
considered to be programs outside of the invention. Such
external procedures can readily be represented within the
Knowledge Representation database, and transfer to such
external procedures may occur through the process
illustrated in Fig. 67. Step (67a) is to get the symbol
reference number. Step (67b) is to get the filename
associated with symbol reference number. The filename
will be stored as an attribute within the relationships
applicable to the concept of the symbol. Step (67c;~ gets
the external procedure, which will be stored as a value of w
a relationship within the symbol applicable to the symbol.
Step (67d) is to execute the procedure for the file as
appropriate to the external procedure. The essence is
that both the filename and the procedure can be stored as
relationships for the symbolized concept. This enables
significant flexibility for the Knowledge Representation
to include knowledge of other computer programs, systems;
and files.
CA 02202867 1997-04-16
WO 96/12236 PGT/US95/10077
1.4
Fig. 68 illustrates a flow diagram of programmed
means for interpreting an icon as the ancestry context. '
The ancestry context is the series of parents ir. the
'parent' fundamental relationships applicable to the
p p ets the s of reference number,
conce t. Ste (68a) g Y~
Step (68b) reads the symbol ancestry, and Step (68c)
outputs the ancestry. The output is typically used to
report information about the ancestry context. For
example, in the preferred embodiment, the ancestry context
is concatenated and displayed in the top line to indicate
the context of the currently active item in the view
document.
Step (68b) is a call to she corresponding function of
the Knowledge Representation ;:atabase. Essentially, Step
(68b) consists cf reading the parents of the symbol,
reading the parents of the parents, and so forth until the
root record is read. The resulting collection of record
reference numbers are then consolidated in a sequential
list indicating the ancestry of the current concept.
Fig. 69 il~ustrates a flow diagram for interpreting
an icon as the descendants context. This is similar to
interpreting the symbol as the ancestry context, with the
exception that the fundamental relationship that is used
as the basis for establishing the descendants is the
children rather than the parents. The illustrated
procedure is for a chain of single children. This
procedure can be readily elaborated to the case of .
multiple children, just as Fig. 68 can readily be
elaborated for the case of multiple ancestry.
Step (69a) sets the next equal to the symbol
reference number. Step (69b) gets the children of the
next. Step (69c) checks to see if the children list is
nil. If it is, it means that here are no descendants, and
thus the process is done. If _t is not nil, then Step
(69d) adds the children record reference numbers to the
t: Step (69e) set next equal to the child, at
li
s
output
CA 02202867 1997-04-16
WO 96/12236 PCT/US95/10077
135
which point the process returns to Step (69b) to get the
subsequent children. The consolidation of children record
reference numbers in the output list means that when Step
(69c) does indicate that the process is done, the output
will be contained in the output format. Output may either
be a list, or some type of database assertions.
Fig. 70 illustrates a flow diagram for interpreting
an icon as the type context. The type context is
established by the fundamental relationship of type
between a project and a component. It is applicable only
to symbols which are project concepts. Equivalent
interst~ata relationships will establish an equivalent
context .or other propagations.
Step (70a) is to get the symbol. Step (70b) reads
the symbol record's type. Step (70c) outputs that type.
Step (70b) reading the symbol type is accomplished by
means of the Output operations of the Knowledge
Representation database.
Fig. 71 illustrates a flow diagram for identifying
the attribute class concepts for act9.ve attribute user
concepts. This provides the interpretation of the symbol
as the attribute class context of the symbol.
Step (71a) is to set next equal to the symbol reference
number. Step (7~1b) is to read the parents of next. Step
(71c) then checks to see if the parents include the
attribute library system concept. If so, then the reading
process Step (71g) is done. Step (71d) checks to see if
the parent is a system concept. The attribute class
concepts will be descendants of the attribute library
concept. Therefore, if the parent symbol is not the
attribute library (as determined in Step (71c)) but it is
a system concept (as determined in Step (71d)) then it is
a attribute class concept.
_ _ Attribute class concepts are to be saved in Step
(71e) by adding the parents to the attribute class list.
Step (7~f) then continues by setting next equal to the
CA 02202867 1997-04-16
WO 96/12236 PCT/US95l10077
136
parent, which then returns to Step (71b) to read the next
parents.
Fig. 72 illustrates a flow diagram for interpreting
the icon as the user connection context. This is similar
to the processes used to determine the other contexts
wherein we are determining the relationships maintained by
the concept. Step (72a) is to get the symbol reference
number. Step (72b) is to look at the descriptive database
to determine if there are any user relationships present
in the descriptive database for the symbol. If there are
o next relationships, then the process is completed. If
n
there is a next relationship, then Step (72c) checks to
ee if the next relationship should be output as one of
s
the user relationships. Step (72c) may include
constraining which of the user relationships to output.
For example the user relationships to be output may be
restricted to those which indicated wire connections.
Such restrictions are. implemented by the system designer,
and the test of Step (72c) is a test to determine if the
user relationship is to be part of the user context to be
reported in the output. If it is, the Step (72d) adds
that next relationship to the output and the process
cycles back to Step (72b) to determine if there are any
additional relationships in the descriptive database.
The invention having been thus described, it will be
apparent that the same may be varied in many ways without
departing from the spirit of the invention. Any and all
such modifications are intended to be covered by the
following claims.
