Abstract:
A method, apparatus, and program product for designing, implementing, distributing, and deploying computer programs that consist of packaged knowledge components written in modem object oriented programming languages. A meta model defines a model for representing facts, intelligence, and packaging facts and intelligence into readily usable knowledge components implemented in off the shelf object oriented programming languages and tools. In addition, the meta model defines knowledge algebra to assemble and cascade knowledge components into larger and more powerful knowledge components and knowledge oriented software applications. A kernel is provided that links and executes knowledge components and knowledge oriented applications. The kernel dynamically links logical definition of knowledge components and the knowledge application to real implementations.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
       [0001]    This application claims priority to provisional application No. 60/328,069, filed Oct. 9, 2001, which is incorporated herein by reference. 
     
    
     
       FIELD OF THE INVENTION  
         [0002]    The invention relates to computers and more particularly to knowledge oriented programming on a computer.  
         BACKGROUND OF THE INVENTION  
         [0003]    Object Oriented Programming Languages (OOPL) and Relational Database Management Systems (RDMS) are the two major technological components of most of the contemporary computer programs. An OOPL encodes the domain knowledge (the logic layer) and visualization (the presentation layer) of the application. A database persistently stores application data and provides a declarative query language to selectively retrieve application data when needed.  
           [0004]    The existence of two distinct technologies (OOPL and RDMS) leads to an impedance mismatch that must be resolved in the interface layer between the logic layer and the database. Layered architectures try to minimize and contain the impact of two distinct technologies on the design, development, and maintenance of applications.  
           [0005]    Multiple approaches were proposed to merge the two different paradigms of computing: object oriented and relational database technologies. Primary motivations were: the elimination of the impedance mismatch between the persistence and logic layers, persistent storage and query of complex objects, and a single computing framework  
           [0006]    These attempts led to competing proposals and standards. The object oriented community responded with extensions to object oriented technologies while the relational database community proposed extensions to relational databases. Two major proposals are, therefore, object databases and object relational databases  
           [0007]    Object databases extend the object oriented paradigm to incorporate the concept of relation. In contrast, object relational databases extend the relational data model by providing support for complex data types. In either case, the goal is to provide a single platform that provides persistence and ad hoc query of complex objects.  
           [0008]    The logic layer typically consists of rules. It has been anticipated for decades that rules stored and managed in a rule engine or knowledgebase would revolutionize the software industry. Given the fact that relational data model is firmly founded on logic, one might expect that the (object) relational databases should include rules. Although some proposals require the rules as essential, there is not a consensus on whether they are an essential or required as part of next generation systems.  
           [0009]    Expert systems explicitly support rules and a significant number of object oriented concepts. Although expert systems are well known, they are not widely adopted by the mainstream software designers and developers. Common characteristics of expert systems (shells) are: a declarative rule language, a declarative language support for object oriented concepts, a pattern matching algorithm (typically a variant of the RETE algorithm), and host language support, for example Java or C++.  
           [0010]    Rule engines have several major drawbacks. First, rule engines contain concepts and syntax that are alien to object oriented programming languages and relational databases. Second, rule engines include a fixed pattern-matching algorithm, which may not perform or scale to complex problems. Third, rule engines need to be integrated into object oriented programming languages and relational databases. Fourth, rule engines lack standards for defining, packaging, sharing, and integrating knowledge from different sources. Finally, rule engines are not extensible or adaptable to the particular needs of an application, i.e., they are a fixed generic solution.  
           [0011]    Despite the strong need for isolating the logic layer and contrary to the long anticipation, widespread adaptation of rule engines to object oriented software applications did not materialize.  
           [0012]    Intelligent databases, i.e., active and deductive databases, are proposals to extend databases to include the rule and event support. Most commercial databases do not yet include explicit rule support that is capable of representing and executing rules in the database. These proposals do not address the impedance mismatch, which is likely to become even more severe if logic layer is moved to persistence layer. The closest database feature, databases triggers, does not meet the needs of business rules.  
           [0013]    What is needed to solve these problems is a single computing environment that seamlessly integrates object oriented programming, rules, and relations of complex objects.  
         SUMMARY  
         [0014]    The invention may provide a method, apparatus, and program product for designing, implementing, distributing, and deploying computer programs that consist of packaged knowledge components written in object oriented programming languages. A meta model defines a model for representing facts, intelligence, and packaging facts and intelligence into readily usable knowledge components implemented in off the shelf object oriented programming languages and tools. In addition, the meta model defines knowledge algebra to assemble and cascade knowledge components into larger and more powerful knowledge components and knowledge oriented software applications. The invention provides a kernel that links and executes knowledge components and knowledge oriented applications. The kernel dynamically links logical definition of knowledge components and the knowledge application to real implementations.  
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0015]    [0015]FIG. 1 depicts a block diagram of a computer system, according to an embodiment of the invention.  
         [0016]    [0016]FIG. 2 depicts a block diagram of a Relation Function, according to an embodiment of the invention.  
         [0017]    [0017]FIG. 3 depicts a block diagram of how new knowledge is derived from existing knowledge, according to an embodiment of the invention.  
         [0018]    [0018]FIG. 4 depicts a block diagram of how relation functions and relations form a closed algebra, according to an embodiment of the invention.  
         [0019]    [0019]FIG. 5 depicts a block diagram of the relationship between the Event, Event Handler, and Relation Function, according to an embodiment of the invention.  
         [0020]    [0020]FIG. 6 depicts a block diagram of a Recursive Relation Function, according to an embodiment of the invention.  
         [0021]    [0021]FIG. 7 depicts a UML representation of a Meta Knowledge Model, according to an embodiment of the invention.  
         [0022]    [0022]FIG. 8 depicts a UML representation of a Meta Logic Model, according to an embodiment of the invention.  
         [0023]    [0023]FIG. 9 depicts a UML representation of a Knowledge Definition Model, according to an embodiment of the invention.  
         [0024]    [0024]FIG. 10 depicts a UML representation of a Run-time Model, according to an embodiment of the invention.  
         [0025]    [0025]FIG. 11 depicts a UML representation of a Catalog Model, according to an embodiment of the invention.  
         [0026]    [0026]FIG. 12 depicts a UML representation of a SYS_Catalog, according to an embodiment of the invention.  
         [0027]    [0027]FIG. 13 depicts a UML representation of SYS_App and SYS_AppKnowledge, according to an embodiment of the invention.  
         [0028]    [0028]FIG. 14 depicts a UML representation of SYS_AppSessionKnowledge and SessionKnowledge, according to an embodiment of the invention.  
         [0029]    [0029]FIG. 15 depicts a UML representation of SYS_AppRelation, according to an embodiment of the invention.  
         [0030]    [0030]FIG. 16 depicts a UML representation of SYS_AppEvent, according to an embodiment of the invention.  
         [0031]    [0031]FIG. 17 depicts a UML representation of SYS_AppEventHandler, according to an embodiment of the invention.  
         [0032]    [0032]FIG. 18 depicts a UML representation of SYS_AppRelationEvent, according to an embodiment of the invention.  
         [0033]    [0033]FIG. 19 depicts a UML representation of SYS_KeyDefinition, according to an embodiment of the invention.  
         [0034]    [0034]FIG. 20 depicts a UML representation of SYS_ThingDefinition, according to an embodiment of the invention.  
         [0035]    [0035]FIG. 21 depicts a UML representation of SYS_ReferenceDefinition, according to an embodiment of the invention.  
         [0036]    [0036]FIG. 22 depicts a UML representation of SYS_RelationDefinition, according to an embodiment of the invention.  
         [0037]    [0037]FIG. 23 depicts a UML representation of SYS_RelationFunctionDefinition, according to an embodiment of the invention.  
         [0038]    [0038]FIG. 24 depicts a UML representation of SYS_FactDefinition, according to an embodiment of the invention.  
         [0039]    [0039]FIG. 25 depicts a UML representation of SYS_SessionRelation, according to an embodiment of the invention.  
         [0040]    [0040]FIG. 26 depicts a UML representation of SYS_SessionEvent, according to an embodiment of the invention.  
         [0041]    [0041]FIG. 27 depicts a UML representation of SYS_SessionEventHandler, according to an embodiment of the invention.  
         [0042]    [0042]FIG. 28 depicts a UML representation of SYS_SessionRelationEvent, according to an embodiment of the invention. 
     
    
     DETAILED DESCRIPTION  
       [0043]    In the following detailed description of exemplary embodiments of the invention, reference is made to the accompanying drawings (where like numbers represent like elements), which form a part hereof, and in which is shown by way of illustration specific exemplary embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, but other embodiments may be utilized and logical, mechanical, electrical, and other changes may be made without departing from the scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims.  
         [0044]    In the following description, numerous specific details are set forth to provide a thorough understanding of the invention. However, it is understood that the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the invention.  
         [0045]    [0045]FIG. 1 depicts a block diagram of a system for implementing an embodiment of the invention. The system  100  may include an electronic device  110  and a network  120 .  
         [0046]    Electronic device  110  may include a processor  135 , a storage device  140 , a network adapter  145 , an input device  150 , and an output device  155 , all communicatively coupled via bus  180 . Processor  135  may represent a central processing unit of any type of architecture, such as a CISC (Complex Instruction Set Computing), RISC (Reduced Instruction Set Computing), VLIW (Very Long Instruction Word), or a hybrid architecture, although any appropriate processor may be used. The processor  135  executes instructions and includes that portion of the electronic device  110  that controls the operation of the entire electronic device. Although not depicted in FIG. 1, the processor  135  typically includes a control unit that organizes data and program storage in memory and transfers data and other information between the various parts of the electronic device  110 . The processor  135  may receive input data from the input device  150  and the network adapter  145 , read and store code and data in the storage device  140 , and may present output data via the output device  155 . The processor  135  also may transmit and receive packets of information across the network  120  using the network adapter  145 .  
         [0047]    The network  120  may be any suitable network capable of supporting communication to the electronic device  110 . Although one network  120  is shown, in other embodiments any number of networks and/or combinations of networks may be present. In an embodiment, the network  120  may support wireless communications. In another embodiment, the network  120  may support hard-wired communications, such as a telephone line or cable. In an embodiment network, the network  120  may be the Internet and support IP (Internet Protocol). In other embodiments, the network  120  may be a local area network (LAN) or a wide area network (WAN). In still other embodiments, the network  120  may support any appropriate protocol or protocols.  
         [0048]    Although the electronic device  110  is shown to contain only a single processor and a single bus, the present invention applies equally to electronic devices that may have multiple processors and to electronic devices that may have multiple buses with some or all performing different functions in different ways.  
         [0049]    The storage device  140  represents one or more mechanisms for storing data. For example, the storage device  140  may include read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and/or other machine-readable media. Although only one storage device  140  is shown, multiple storage devices and multiple types of storage devices may be present. Further, although the electronic device  110  is drawn to contain the storage device  140 , it may be distributed across other electronic devices.  
         [0050]    The storage device  140  may include a Meta Model  160 , an Application  161 , and a Run-time  162 . The Run-time  162  may include instructions capable of being executed on the processor  135  to carry out the functions of the present invention. In another embodiment, some or all of the functions of the present invention may be carried out via hardware in lieu of a processor-based system. Of course, the storage device  140  may also contain additional software and data (not shown), which is not necessary to understanding the invention. The Run-time  162  runs applications, such as application  161 . The Run-time  162 , Meta Model  160 , and Application  162  may be embedded into another program: an application server, a web server, or a standalone application. The Run-time  162  is also the interface to other applications. The Run-time  162  dynamically binds the Application Definition  174  to the Application Implementation  177 .  
         [0051]    The Meta Model  160  may include a Meta Knowledge Model  165 , a Meta Logic Model  166 , a Knowledge Definition Model  167 , a Catalog Model  169 , and a Run-time Model  171 .  
         [0052]    The Application  161  may include an Application Knowledge Model  172 , an Application Logic Model  173 , an Application Definition  174 , Application Data  175 , Application Logic  176 , and an Application Implementation  177 . The Application Knowledge model  172  complies with the Meta Knowledge Model  165 . The Application Logic Model  173  complies with the Meta Logic Model  166 . The Application Definition  174  complies with the Knowledge Definition Model  167 . The Application Definition  174  is stored in the Catalog Model  169 . The Application Data  175  is stored in Knowledge Model  172 . Application Logic  176  is stored in Application Logic Model  173 .  
         [0053]    The Meta Model  160  is a formally-defined programming model and may provide knowledge oriented software design and construction; packaging of knowledge into knowledge components; generalized queries as knowledge components; assembling knowledge components into knowledge oriented applications; independence from a programming language and development tool; rules, events, constraints, relations, classes, and objects within a single programming environment; a computing model based on most common object oriented programming and database concepts; independence from any persistence mechanism; declarative application design and binding; object oriented representation of knowledge; packaged, ready to use, sharable knowledge components; a run-time that can integrate knowledge components into knowledge applications; a software design and development model that emphasizes the componentization of knowledge; and persistence formats compatible with widely accepted formats, such as relational databases and XML.  
         [0054]    Informally, knowledge consists of what we know, how we infer, and how we react to external events. The Meta Model  160  is a formal method for modeling knowledge (Meta Knowledge Model  165 ), modeling inferencing (Meta Logic Model  166 ), dynamically binding a declaratively defined application to a computer executable process using the Knowledge Definition Model  167 , modeling declarative applications and their bindings (Catalog Model  169 ), and providing a run-time environment via the Run-time Model  171 .  
         [0055]    Application  161  consists of an Application Knowledge Model  172 , Application Logic Model  173 , Application Definition  174 , Application Data  175 , Application Logic  176 , and Application Implementation  177 . Application Knowledge Model  172  complies with the Meta Knowledge Model  165 . Application Data  174  is stored in data structures defined by the Application Knowledge Model  172 . Meta Knowledge Model  165 , Application Knowledge Model  172 , and Application Data  175  are analogous to Relational Model, Database Schema, and Data of Relational Databases. Application Logic Model  173  stores the Application Logic  176 . Application Logic Model  173  complies with the Meta Logic Model  166 .  
         [0056]    Run-time  162  may include a Kernel  163  and a Catalog  164 . Catalog  164  is stored in data structures defined by the Catalog Model  169 . The Kernel  163  manages the Meta Model  160 , Application  161 , and the Catalog  164 . The Kernel  163  also provides the interface to the external clients and/or applications.  
         [0057]    Meta Knowledge Model  165   
         [0058]    [0058]FIG. 7 shows the Meta Knowledge Model  165  described using the Unified Modeling Language (UML) notation. The Meta Knowledge Model  165  has the building blocks of an application&#39;s knowledge model. Thing, Key, Fact, and Relation are the fundamental building blocks. They are analogous to the Attribute, Key, Tuple, and Relation of Relational Data Model. The Meta Model  160  defines building blocks as abstract types. The abstract types specify the Meta Knowledge Model unambiguously and independently of any host programming language.  
         [0059]    The Thing is the base class of all objects in the data model, in other words, all the domain objects. An instance of a Thing is a named object that is the subject of the knowledge. All application objects have a type that is a sub type of the Thing.  
         [0060]    The Key class is the base class of a unique identifier of an application object. A key is required to be unique within the scope of the object it refers to. When an object is created, it is stored by value in only one relation. All other relations refer to the same object by its key. The Meta Model  160  does not allow facts to refer to objects by pointers or object references. The Meta Model  160  requires that all sub types of Key implement usual comparison operators: Equality, Greater Than, and Less Than.  
         [0061]    A fact is a statement that is assumed to be true. A fact consists of a predicate and the list of arguments for which the predicate is true. For example, in the statement “John is a biologist,” “biologist” is the predicate and “John” is the thing for which the predicate is true.  
         [0062]    In the Meta Model  160 , the Fact class is a generic structure type to organize and hold subjects of predicates. Formally, the Fact is a set of things.  
         [0063]    A relation is the container for a set of facts and the predicate of the facts it contains. The name of the relation is the name of the predicate. The predicate restricts the types of facts that can be inserted into the relation. Facts can be inserted into, updated in, deleted from, or queried in a relation. All facts of a relation must be of the same type or they must have a common base type. All facts of a relation may have the same cardinality, i.e., facts contain same number of things. A Fact implementation may have a fixed cardinality, that is, the number of elements in the Thing set is fixed.  
         [0064]    StringKey, DateKey, and IntegerKey are three common types of keys. Additional key types can be added if necessary. ThingList and ThingSet are commonly needed sub types of Thing. They often used to encode a fact between one object and a set or list of other objects. SimpleFact is the implementation of a fact type that has a cardinality of one. OneToOneFact is the implementation of a fact type that has a cardinality of two. In practice, higher cardinality facts are rarely needed. If required they can be created by extending the Fact class or OneToManyFact. MapRelation is a generic implementation of Relation. As the name suggest, MapRelation uses a hash map to store and index its facts.  
         [0065]    The Meta Knowledge Model  165  has the expressive power to represent and index any type of data structure and relationship types encountered in relational database design and object oriented programming.  
         [0066]    Meta Logic Model  166   
         [0067]    The Meta Knowledge Model  165  is a protocol for organization, indexing, and retrieval of objects. The Meta Logic Model  166  is a protocal for deriving new relations from a set of base relations, and imposing rules and constraints on the relations. It specifies the building blocks of an application&#39;s logic: Event, Event Handler, and RelationFunction. FIG. 8 shows the Meta Logic Model described using the Unified Modeling Language (UML) notation.  
         [0068]    The Meta Knowledge Model  160  requires that all knowledge is stored in relations. Similarly, Meta Logic Model  165  requires that all computed or inferred knowledge be returned as a relation. Relation Functions are special in that they take relations as input and return a relation. The Relation Function is a generalization of both a database query and function concept in programming languages.  
         [0069]    RelationFunction is an abstract class. The application provides the implementation. Typically a relation function is a thin wrapper to an existing algorithm. The simplicity and the generality of the RelationFunction enable the end users and the application designers to reuse or integrate existing code. RelationFunctions forms a closed algebra. Closure property ensures that RelationFunctions can be cascaded to implement complex logic.  
         [0070]    An Event is a change in a relation. The Run-time  162  monitors the changes to the relations to ensure that change is allowed and to take necessary actions. An event is associated with a relation. Typical changes are insertion, deletion, and update of facts. An event may apply to any fact or to a number of specific facts. Once an event is detected, an action may need to be taken. An event has an event handler that represents the action. An event and event handler pair represents a rule or a constraint: If &lt;event&gt; then &lt;eventHandler&gt;. The designer of Application  161  may specify the events. Typically, there is no need to override the Event and EventHandler classes. An event has one of the following scopes: Application, and Session. Application and Session will be discussed later in detail. When an event is application scope, it applies to all sessions of the application. When it is session scope, it applies to specific session in which it is declared. An event has one of the following types: Insert, Delete, Update, Add, and Drop. These are the allowed operations on relations. Since all knowledge is stored in relations, every event is one of these types. There are two levels of an event: Relation, and Fact. When an event has the Relation Level, it applies to any fact in the relation. When it is Fact Level, it only applies to specified facts.  
         [0071]    An event handler is a specification of what action will be taken and where. An event handler has a relation function (what to execute) and a target relation (where to put the result).  
         [0072]    When an event handler is invoked, its relation function is executed. The action of an event handler is an operation between two relations: the output of the relation function and the target relation. An event handler has the following action types: Clear, Drop, Replace, Insert, Delete, and Update. An action type determines the operation on the target relation.  
         [0073]    The Relation Function, Event, and Event Handlers together provide the functionality of query, computation, rule, and constraint. The Meta Logic Model  166  is a model of the logical flow of a software application  161 . Separation of the application logic is critical to on-demand assembly of applications from a set of data structures and algorithms.  
         [0074]    Knowledge Definition Model  167   
         [0075]    The Meta Model  160  may separate the logical structure of a software application from its implementations. The Knowledge Definition Model  167  is an object-oriented model to capture and store the logical design of an application. FIG. 9 shows the Knowledge Definition Model  167  described using the Unified Modeling Language (UML) notation. The Kernel  163  binds the logical design to a real implementation at run time. In the Meta Model  160 , users design the application at a logical level and then assemble a set of implementing components at run time. Logical application definition and dynamic binding is key to realizing knowledge component technologies and markets. A precise mapping of the logical design to physical implementation is also critical to the development of visual design tools and automatic code generation. The conversion from logical to physical model is lossless. The separation of logical and physical design enables the domain experts do design the application without worrying about the implementation.  
         [0076]    Most of the building blocks of the Application  161  has a matching component in the Knowledge Definition Model  167 . The logical definition of an application is also used to enforce type safety.  
         [0077]    Catalog Model  169  and Catalog  164   
         [0078]    The Catalog  164  stores the applications, their logical design, and their user sessions and run-time data. The Catalog Model  169  specifies the structure and building blocks of Catalog  164 .  
         [0079]    SYS_Catalog is the root relation of Run-time  162 . Storage Device  140  may have multiple instances of Run-time  162  running. Each instance has its own catalog. An instance of SYS_Catalog is created by the Run-time  162  automatically. SYS_App is the root relation of an application. SYS_App and the relations contained in it form the application catalog. End users with sufficient privileges can query and modify the application catalog directly. Knowledge definitions stored the Catalog  164  are used to instantiate objects, enforce type constraints, and referential integrity by the Runtime  162 .  
         [0080]    Kernel  163  creates an instance of an application catalog when it loads the application. The application catalog is destroyed when an application is unloaded.  
         [0081]    SYS_AppSessionKnowledge is the root relation of session specific application knowledge. SYS_AppSessionKnowledge and the relations contained in it form the session catalog. Kernel  163  creates an instance of a session catalog when the session is created. The session catalog is destroyed when user closes the session or when the session expires.  
         [0082]    The Kernel  163  manages the application catalog and the session catalog. The Catalog  164  may have multiple applications loaded. Each application may have multiple sessions. Knowledge can be shared between the applications and sessions.  
         [0083]    Runtime  162   
         [0084]    The Runtime  162  consists of Kernel  163 , and the Catalog  164 . FIG. 10 shows the Run-time described using the Unified Modeling Language (UML) notation. The Runtime  162  is the container for the applications, and the components that manages the applications. Responsibilities of the Kernel  163  include system initialization, loading and binding of the applications, providing client access to application relations and relation functions, linking the application to a real implementation, monitoring relations for events, executing the event handlers when events are detected, and managing multiple user sessions. The clients of System  100  may create an instance of the Kernel  163  as the first step. All system functionality is then accessible from the kernel object. A kernel object can be embedded to any container application, for example, web server, application server, or a desktop application. The Kernel  163  is independent of the application and the host environment. The Kernel  163  can accommodate multiple clients (users) for multiple applications. The Kernel  163  allocates a separate copy of the application for each concurrent client.  
         [0085]    The Kernel&#39;s role is equivalent to the role of an operating system. The Kernel  163 , like an operating system, runs the applications without knowing their context. It needs to know only a small number of things. The Kernel  163  manages an application using the information contained in the Meta Model  160 . The operational job of the Kernel  163  is to respond to client requests, detect system events, call the event handlers, and take specified actions on the relations. Details of the application are not need to be known to the Kernel  163 .  
         [0086]    A session is where a client&#39;s work is stored. A session is created when a client sends the first request to the Kernel  163 . It is destroyed when it is expired, or when the client explicitly terminates the session. The Kernel  163  can have multiple applications loaded and running. When a client requests an application to be loaded, the Kernel  163  reads the Application Definition  174  from a text file. The Application Definition  174  includes the logical definition of the application and its run-time bindings.  
         [0087]    Application  161   
         [0088]    Application  161  consist of the Application Knowledge Model  172 , Application Logic Model  173 , Application Data  175 , Application Logic  176 , Application Definition  174 , and Application Implementation  177 .  
         [0089]    Application Knowledge Model  172  is the set of application domain classes that specify how the known facts are organized and indexed. There can be any number of classes. Each class must be a sub class of a class contained within the Meta Knowledge Model  165 . Application Data  175  are the set objects that are instances of the classes defined within the Application Knowledge Model  172 .  
         [0090]    Application Logic Model  173  is the set of application domain Relation Functions. Each domain Relation Function must be a sub type of the base Relation Function specified by the Meta Logic Model  166 . Application Logic  176  is the set objects that are instances of classes defined within the Application Logic Model  173  and the set of objects that are instances of Event and Event Handler classes defined by the Meta Logic Model  166 .  
         [0091]    Application Definition  174  is a textual or binary file that specifies all the domain classes, and domain objects and their constraints. Application Definition  174  includes both a logical specification and their bindings to an implementation. Application Implementation  177  is a set of compiled libraries that implements the classes and objects specified in the Application Definition  174 .  
         [0092]    Class  
         [0093]    Class is the fundamental concept of Object Oriented Programming. Domain is the equivalent concept in Relational Databases. Data type, or Type, commonly used to mean Class or Domain. Type is a more general concept. We might have types that are not classes. We will use only Class, instead of type, to emphasize our intention to firmly base the Meta Model  160  on Object Oriented Programming.  
         [0094]    A Class defines methods that collectively specify the external behavior of the objects that are instances of that Class. A class may also have public attributes.  
         [0095]    Object  
         [0096]    An object can be anything. An object may have one or more classes. Every object has at the least one class. We will use object to refer to an instance of a Class.  
         [0097]    Inheritance  
         [0098]    Class B inherits Class A, if Class B provides all of the external behavior of Class A. In other words, Class B is a subtype of Class A or Class A is super class of Class B.  
         [0099]    Object Name  
         [0100]    Object names start with lower case letters and classes start with upper case letters. For example, “relation” refers to an instance of “Relation” class. Object names are used when discussing properties of instances of a class. For example, “A relation must have a unique key” means that every instance of the Relation Class has a unique key.  
         [0101]    Current Object Reference  
         [0102]    The reference to the object itself is this. For example, in description of method getName( ), “Gets the name of this”, this refers to the object on which getName( ) is called.  
         [0103]    Variables  
         [0104]    The concept of variable is inherited from the host programming language. Variable names used in the text follow the programming element conventions. For example, in the description of method setName(String newName), “Sets the name of this to newName”, newName refers to a variable that points to a string.  
         [0105]    Meta Knowledge Model  165   
         [0106]    The classes Key, Relation, Fact, and Thing are the building blocks of a knowledge model. The Meta Knowledge Model  165  may specify them as abstract classes. All application specific components must be a subclass of one of these classes.  
         [0107]    Key  
         [0108]    The Key class is the base class of a unique identifier of an object. A key is required to be unique within the scope of the object it refers to. When an object is created, it is stored by value in only one relation. All other relations refer to the same object by its key.  
         [0109]    A key identifies an object by name. Two objects are the same if they have the same key. Typically a key is a wrapper around a string or an integer. Three most common sub classes of Key are StringKey, DateKey and IntegerKey. They have methods to construct keys from strings, dates, and integers. They also have methods to get the string, date, and integer values of the keys.  
         [0110]    Key Class is an abstract class.  
         [0111]    public Key getKey( )  
         [0112]    Returns the key of a key. The key of a key is itself. All key classes are sub classes of Key.  
         [0113]    The StringKey Class is a sub class of Key.  
         [0114]    public StringKey(String newValue)  
         [0115]    Constructs a key out of a String.  
         [0116]    public String getAsString( )  
         [0117]    Returns the string value of the key. This is the same string that is used to construct the key.  
         [0118]    public int compareTo(Object newKey)  
         [0119]    Compares two keys. The input is another key of the same type: StringKey. This method delegates the comparison of two keys to the comparison of their string values.  
         [0120]    public boolean equals(Object obj)  
         [0121]    Compares two keys for equality. The input is another key of the same type: StringKey. Two keys are equal if they compare to be the same.  
         [0122]    public int hashCode( )  
         [0123]    Returns the hash code of the key. The hash code of the key is the hash code of the string value of the key.  
         [0124]    IntegerKey Class is a sub class of Key.  
         [0125]    public IntegerKey(int newValue)  
         [0126]    Constructs a key out of an int value.  
         [0127]    public int compareTo(Object newKey)  
         [0128]    Compares two keys. The input is another key of the same type: IntegerKey. This method delegates the comparison of two keys to the comparison of their integer values.  
         [0129]    public int getAsInt( )  
         [0130]    Returns the integer value of the key. This is the same integer that is used to construct the key.  
         [0131]    public boolean equals(Object obj)  
         [0132]    Compares two keys for equality. The input is another key of the same type: IntegerKey. Two keys are equal if they compare to be the same.  
         [0133]    public int hashCode( )  
         [0134]    Returns the hash code of the key. The hash code of the key is the integer value of the key.  
         [0135]    The DateKey Class is a sub class of Key.  
         [0136]    public DateKey(Date newValue)  
         [0137]    Constructs a key out of a Date value.  
         [0138]    public int compareTo(Object newKey)  
         [0139]    Compares two keys. The input is another key of the same type: DateKey. This method delegates the comparison of two keys to the comparison of their date values.  
         [0140]    public Date getAsDate( )  
         [0141]    Returns the date value of the key. This is the same date that is used to construct the key.  
         [0142]    public boolean equals(Object obj)  
         [0143]    Compares two keys for equality. The input is another key of the same type: DateKey. Two keys are equal if they compare to be the same.  
         [0144]    public int hashCode( )  
         [0145]    Returns the hash code of the key. The hash code of the key is hash code of the date.  
         [0146]    Thing  
         [0147]    Thing is the abstract base class of all objects in the Run-time  162 . The Thing class has the methods that are common to all of the Run-time  162  classes.  
         [0148]    Thing Class  
         [0149]    public String getDefinition( );  
         [0150]    Gets the name of the knowledge definition of this.  
         [0151]    public void setDefinitionName(String newDefinitionName);  
         [0152]    Sets the name of the knowledge definition of this.  
         [0153]    public abstract Key getKey( );  
         [0154]    Gets the key of this. The method getKey( ) ensures that all objects in the data model have a key that identifies the logical object.  
         [0155]    The ThingList Class is the base class of domain things that represents an ordered list of things.  
         [0156]    public ThingList( );  
         [0157]    Construct an empty thing list.  
         [0158]    public void add(int index, Thing thing);  
         [0159]    Adds a thing at the specified position. The index must be zero or positive.  
         [0160]    public boolean add(Thing thing);  
         [0161]    Adds a thing to the end of the list.  
         [0162]    public boolean addAll(ThingList newThings);  
         [0163]    Adds all the thing of newThings to the end of this.  
         [0164]    public boolean addAll(int startindex, ThingList things);  
         [0165]    Adds all the thing of a thingList starting at the startIndex. If list contains elements beyond position i, they are overridden.  
         [0166]    public Thing set(int index, Thing newThing);  
         [0167]    Sets the thing at index to newThing.  
         [0168]    public Thing get(int index);  
         [0169]    Gets the thing at index.  
         [0170]    public Thing remove(int index);  
         [0171]    Removes the thing at index.  
         [0172]    public void clear( );  
         [0173]    Removes the all thing of this.  
         [0174]    public boolean contains(Thing newThing);  
         [0175]    Searches the list for an item whose key matches the key of the newThing. Returns true if a match is found. Return false otherwise.  
         [0176]    public int size( );  
         [0177]    Returns the number of things in this.  
         [0178]    public void trimToSize( );  
         [0179]    Trims the size of the list to the number of things in the list.  
         [0180]    public void ensureCapacity(int newCapacity);  
         [0181]    Sets the minimum capacity of this to newCapacity.  
         [0182]    public boolean isEmpty( );  
         [0183]    Returns whether this is empty.  
         [0184]    public int indexOf(Thing thing);  
         [0185]    Returns the index of the thing. If thing does not exist, it returns—1.  
         [0186]    public Key getKey( );  
         [0187]    Returns the key of this.  
         [0188]    The ThingSet Class is the base class of domain things that represent a set of objects.  
         [0189]    public ThingSet( );  
         [0190]    Construct an empty thing set.  
         [0191]    public int size( );  
         [0192]    Returns the number of things in the set.  
         [0193]    public boolean isEmpty( );  
         [0194]    Returns whether the set is empty.  
         [0195]    public boolean contains(Thing newThing);  
         [0196]    Searches the set for an item whose key matches the key of the newThing. Returns true if a match is found. Return false otherwise.  
         [0197]    public Thing[ ] toArray( );  
         [0198]    Gets the things in the set as array of things.  
         [0199]    public boolean add(Thing thing);  
         [0200]    Adds a thing to this.  
         [0201]    public boolean addAll(ThingSet thingSet);  
         [0202]    Adds all the thing of a thingSet to this.  
         [0203]    public boolean remove(Thing thing);  
         [0204]    Removes the thing from this.  
         [0205]    public boolean removeAll(ThingSet thingSet);  
         [0206]    Removes all the things of thingSet from this.  
         [0207]    public void clear( );  
         [0208]    Removes all the things of this.  
         [0209]    public Key getKey( );  
         [0210]    Returns the key of this.  
         [0211]    The Fact Class is the abstract base class of all objects that represent a fact.  
         [0212]    public abstract int getSize( );  
         [0213]    Returns the cardinality of the fact; the number of things in the facts.  
         [0214]    public abstract boolean set(int i, Thing thing);  
         [0215]    Sets the thing at the position i. Input thing is an object whose subtypes include Thing. If the requested position i is negative or greater than or equal to the number of things, no value is set.  
         [0216]    public abstract Thing get(int i);  
         [0217]    Returns the thing stored at the position i. Return value is an object whose subtypes include Thing. If the requested position i is negative or greater than or equal to the number of things, it returns null.  
         [0218]    public abstract Thing get(Key key);  
         [0219]    Returns the thing whose key is equal to key. If no matching key exists, it returns null. The return value is an object whose subtypes include Thing.  
         [0220]    public abstract Thing[ ] get( );  
         [0221]    Returns all the thing of the fact. The returned array of things can have only those objects whose subtypes include Thing.  
         [0222]    public abstract boolean update(int i, Thing thing);  
         [0223]    Replaces the thing at position i with the thing. If requested position i is greater than or equal to the number of things of the fact, or if i negative, it does not modify the fact. In other words, only existing things can be updated.  
         [0224]    public abstract boolean update(Key key, Thing thing);  
         [0225]    Replaces the thing whose key is equal to key. If no matching key exists, it does not update the fact.  
         [0226]    public abstract boolean delete(int i);  
         [0227]    Deletes the thing at position i. If requested position i is greater than or equal to the number of thing in the fact, or if i negative, it does not modify the fact. Only existing things can be deleted. After the successful deletion, the size of the thing list is still the same. The position i has a null value after deletion.  
         [0228]    public abstract boolean delete(Key key);  
         [0229]    Deletes the thing whose key is equal to key. If no matching key exists, it does not modify the fact. After the successful deletion, the size of the thing list is still the same. The position i has a null value after deletion. If multiple matches are found, all matched things are deleted.  
         [0230]    public abstract boolean deleteAll( );  
         [0231]    Delete all things of the fact.  
         [0232]    public Key getKey( );  
         [0233]    Return the key of the fact. getKey( ) is overridden in a sub type to return the desired key.  
         [0234]    Simple Fact  
         [0235]    The Simple Fact class is an implementation of the abstract Fact class. A simple fact has only one thing. The default key of the fact is the key of the thing. A relation with simple facts is equivalent to a hash table. The thing of the fact can be any sub type of Thing, including Key, and Relation.  
         [0236]    One-to-One Fact  
         [0237]    This class is an implementation of abstract Fact class. A One-to-One fact has two things. The default key of the fact is the key of the first thing. The things of the fact can be any sub type of Thing, including Key, and Relation.  
         [0238]    One-to-Many Fact  
         [0239]    A fact whose cardinality is greater than 2 is required to extend this class. The default key of the fact is the key of the first thing. The things of the fact can be any sub type of Thing, including Key, and Relation.  
         [0240]    Relation  
         [0241]    A Relation is the container for a set of facts and the predicate of the contained facts. The name of the relation is the name of the predicate. The predicate restricts the types of facts that can be inserted into the relation.  
         [0242]    Relation Class  
         [0243]    abstract public String getName( );  
         [0244]    Gets the name of a relation. Name identifies the logical name of the relation object. The application designer assigns the logical name. Name is the default key for the relation. If name is not unique, getKey( ) method is overridden to provide a unique key. abstract public void setName(String newName);  
         [0245]    Sets the name of a relation. Every relation has a name. The name is expected to be descriptive of the purpose of the relation.  
         [0246]    abstract public boolean insert(Fact fact);  
         [0247]    Inserts a fact to the relation. The key of the fact cannot be null. The type of the fact must match with Fact or with one of sub types of Fact. If key type does not match, it raises InvalidKeyException. If key exists, it fails. It raises DuplicateKeyException. If key is null, it raises NullKeyException.  
         [0248]    abstract public boolean update(Fact newFact);  
         [0249]    If there is a fact whose key matches with key of newFact, it replaces that fact with newFact. If no matching fact is found, relation is not updated. If key newFact is null, relation is not updated.  
         [0250]    abstract public boolean delete(Fact newFact);  
         [0251]    If there is a fact whose key matches with key of the newFact, it deletes that fact. If key of the newFact is null, relation is not updated.  
         [0252]    abstract public boolean delete(Key newKey);  
         [0253]    If there is a fact whose key matches with newKey, it deletes that fact. If newKey is null, relation is not updated.  
         [0254]    abstract public boolean deleteAll( );  
         [0255]    Deletes all the facts in this.  
         [0256]    abstract public boolean insert(Relation r);  
         [0257]    Inserts all the facts of the relation r into this. If r is null, it raises InvalidRelationException. Key and the Fact type of relation r must match the key and fact type of this. Otherwise InvalidRelationException is raised. This operation loops over the facts of r and inserts each one of them into this.  
         [0258]    abstract public boolean update(Relation r);  
         [0259]    Update all the facts of the relation r in this. If r is null, it raises InvalidRelationException. Key and the Fact type of relation r must match the key and fact type of this. Otherwise InvalidRelationException is raised. This operation loops over the facts of r and updates each one of them.  
         [0260]    abstract public boolean delete(Relation r);  
         [0261]    Deletes all the facts of the relation r from this. If r is null, it raises InvalidRelationException. Key and the fact type of relation r must match the key and fact type of this. Otherwise InvalidKeyException is raised. This operation loops over the keys of r and deletes each one of them from this.  
         [0262]    abstract public int getSize( );  
         [0263]    Returns the number of facts in this.  
         [0264]    abstract public Fact get(Key newKey);  
         [0265]    Returns the fact whose key matches newKey. If no matching record is found, it returns null.  
         [0266]    abstract public Fact[ ] getAll( );  
         [0267]    Returns all the facts of this as an array.  
         [0268]    abstract public boolean contains(Key newKey);  
         [0269]    Returns true if there is fact whose key matches newKey. If no matching record is found, it returns false.  
         [0270]    abstract public Relation intersect(Relation r);  
         [0271]    Returns the facts that exist in r and this. If r is null, it raises InvalidRelationException. Key and the Fact type of relation r must match the key and fact type of this. Otherwise InvalidRelationException is raised.  
         [0272]    abstract public Set keys( );  
         [0273]    Returns the set of keys of this.  
         [0274]    abstract public Key getKey( );  
         [0275]    Returns the key of this.  
         [0276]    MapRelation Class  
         [0277]    MapRelation is the default implementation of Relation. As the name suggests, MapRelation uses a HashMap to store and index facts.  
         [0278]    Meta Logic Model  166   
         [0279]    The System  100  may have two types of fact: base and derived  
         [0280]    A base fact exists independently of other facts. We cannot derive them from other facts. They are the axioms of the System  100 . Derived facts are consequences of base facts. We refer to the ability to derive facts from base facts as intelligence. In the System  100 , intelligence is represented as a Relation Function, FIG. 3.  
         [0281]    A client of the System  100  may request the execution of a relation function. Or the Run-time  162  may execute a set of relation functions to enforce rules and constraints. The ability of the Run-time  162  to enforce the rules and constraints is provided by Relation Function, Event, and Event Handler. The Meta Logic Model  166  specifies the Relation Function, Event, Event Handler, and their supporting classes.  
         [0282]    Relation Function  
         [0283]    Relation functions are special in that they take relations as input and return a relation. A relation function is a generalization of both a database query and function concept in programming languages. The System  100  stores relation functions in the Catalog  164 . Relation Function is a sub type of Thing. Relation Function is an abstract class. The application provides the implementation.  
         [0284]    [0284]FIG. 2 graphically depicts the Relation Function. A relation function may be recursive. FIG. 4 graphically depicts a recursive relation function. Relation functions form a closed algebra. Due to its closure property, relation functions can be cascaded to construct complex logic. FIG. 4 graphically depicts how relation functions can be cascaded. FIG. 5 depicts how events and relation functions cooperate to implement rules.  
         [0285]    [0285]FIG. 6 depicts how events and recursive relation functions cooperate to implement cascaded rules and actions.  
         [0286]    Relation Function Class  
         [0287]    Relation Function is an abstract sub class of Thing.  
         [0288]    public String getName( )  
         [0289]    Gets the logical name of this. Logical name uniquely identifies a relation function. Logical names are assigned by the application. The name is the default key of a relation function.  
         [0290]    public void setName(String newName)  
         [0291]    Sets the logical name of this to newName.  
         [0292]    public abstract Relation execute(Relation[ ] r)  
         [0293]    Executes the relation function. Application designer specifies what execute does. Application developers implement execute method in a sub type of Relation Function. Input is an ordered list of relations. The Run-time  162  ensures the type safety at run time.  
         [0294]    public Key getKey( )  
         [0295]    Return the key of this. Default implementation return a StringKey constructed from the name of this.  
         [0296]    Event  
         [0297]    An event is change in a relation. The Run-time  162  may monitor the changes to the relations to ensure that change is allowed or to take an action.  
         [0298]    An event is associated with a relation. Typical changes are insertion, deletion, and update of facts. An event may apply to any fact or a number of specific facts. Once an event is detected, an action may need to be taken. An event has an event handler that represents the action. An event and event handler pair represents a rule:  
         [0299]    If&lt;event&gt;then &lt;eventHandler&gt; 
         [0300]    The designer of Application  161  specify the events and their handlers. Typically, there is no need to override the Event.  
         [0301]    An event may have scopes of Application or Session Application and Session will be discussed later in detail. When an event is application scope, it applies to all sessions of the application. When it is session scope, it applies to specific session in which it is declared.  
         [0302]    An event has one of the following types: Insert, Delete, Update, Add, or Drop  
         [0303]    These are the five types of operations on relations. Since all knowledge is stored in relations, every event is one of these types.  
         [0304]    There may be two levels of an event: Relation and Fact.  
         [0305]    When an event has the Relation Level, it applies to any fact in the relation. When it is Fact Level, it only applies to specified facts.  
         [0306]    Event Class  
         [0307]    Event is a sub class of Thing.  
         [0308]    public Event( )  
         [0309]    Constructs an event.  
         [0310]    public String getName( )  
         [0311]    Gets the name of this as a string. A name uniquely identifies an event within its scope. If scope is Session, name must be unique within the session. If scope is Application, name must be unique within the application.  
         [0312]    public void setName(String newName)  
         [0313]    Sets the name of this to newName.  
         [0314]    public String getRelationName( );  
         [0315]    Gets name of the relation to whom event is attached.  
         [0316]    public void setRelationName(String newRelationName);  
         [0317]    Sets the name of the relation to whom event is attached.  
         [0318]    public Relation getKeys( )  
         [0319]    Returns the keys of facts to which event are applicable. If the level of the event is Relation, returns null. When the level is Relation, event is applicable to all facts of the relation.  
         [0320]    public int getPriority( )  
         [0321]    Returns the priority of the event. The highest priority is 0. The priority decreases with increasing value. The Run-time  161  checks highest priority event first. Default value is zero. When a set of events has the same priority, their keys prioritize them. The smallest key value has the highest priority.  
         [0322]    public void setPriority(int newPriority)  
         [0323]    Sets the priority of this to newPriority.  
         [0324]    public EventScope getScope( )  
         [0325]    Returns the scope of this. Valid scopes are Session, and Application When the scope is Session event is monitored for the current session only. When the scope is Application event is monitored for all session of the application only.  
         [0326]    public void setScope(EventScope newScope)  
         [0327]    Sets the scope of this to newScope.  
         [0328]    public EventLevel getLevel( )  
         [0329]    Returns the level of this. Valid level are Relation and Fact. When the scope is Relation event is monitored for every fact of the target relation. Otherwise it is monitored for a specified set of facts.  
         [0330]    public void setLevel(EventLevel newLevel)  
         [0331]    Sets the level of this to newLevel.  
         [0332]    public String getEventHandlerName( )  
         [0333]    Gets the event handler name of this. When the event is detected, the event handler is executed.  
         [0334]    public void setEventHandlerName(String newEventHandlerName)  
         [0335]    Sets the event handler of this to newEventHandlerName.  
         [0336]    public Key getKey( )  
         [0337]    Returns the key of this.  
         [0338]    Event Handler  
         [0339]    An event handler is a specification of what action will be taken and where. An event handler may have a Relation Function (what) and a Target Relation (where).  
         [0340]    When an event handler is invoked, relation function is executed. The action is an operation between the output of the relation function and the target relation.  
         [0341]    An event handler may have the following action types: Clear, Add, Drop, Replace, Insert, Delete, or Update.  
         [0342]    An action type determines the operation on the target relation.  
         [0343]    Class ActionType  
         [0344]    Action is a super class of EnumeratedType.  
         [0345]    public static final int Clear=1;  
         [0346]    Removes all facts from the target relation.  
         [0347]    public static final int Add=2;  
         [0348]    Adds the target relation to Catalog  164 . Target relations within the scope of the event are added. For example, if the scope of the event is Session, it is added to the session of the triggered event. If scope is Application, target relation is added to all the sessions of the application.  
         [0349]    public static final int Drop=3;  
         [0350]    Drops the target relation from Catalog  164 . Target relations within the scope of the event are dropped. For example, if the scope of the event is Session, it is dropped from the session of the triggered event. If scope is Application, target relation is dropped from all the sessions of the application.  
         [0351]    public static final int Replace=4;  
         [0352]    Replaces the target relation in a Catalog  164 . Target relations within the scope of the event are replaced. For example, if the scope of the event is Session, it is replaced in the session of the triggered event. If scope is Application, target relation is replaced in all the sessions of the application.  
         [0353]    public static final int Insert=5;  
         [0354]    Inserts into the target relation the facts of the relation returned by the relation function. Target relation must be within the scope of the event.  
         [0355]    public static final int Delete=6;  
         [0356]    Deletes from the target relation the facts of the relation returned by the relation function. Target relation must within the scope of the event.  
         [0357]    public static final int Update=7;  
         [0358]    Updates in the target relation the facts of the relation returned by the relation function. Target relation must be within the scope of the event.  
         [0359]    public ActionType(int newType)  
         [0360]    Constructs an action type from its integer id newType.  
         [0361]    public String getDescription( )  
         [0362]    Gets the description of the action type.  
         [0363]    public void setDescription(String newDescription)  
         [0364]    Sets the description of the action type to newDescription.  
         [0365]    EventHandler Class  
         [0366]    EventHandler is a sub class of Thing.  
         [0367]    public EventHandler( )  
         [0368]    Constructs and EventHandler.  
         [0369]    public String getName( )  
         [0370]    Gets the name of this. Name is the key of this.  
         [0371]    public void setName(String newName)  
         [0372]    Sets the name of this to newName.  
         [0373]    public ActionType getActionType( )  
         [0374]    Gets the actionType of this.  
         [0375]    public void setActionType(ActionType newActionType)  
         [0376]    Sets the actionType of this to newActionType.  
         [0377]    public String getRelationFunctionName( )  
         [0378]    Gets the name of the relation function that is to be executed. The name is the logical name. The Run-time  162  may map the logical name to a physical implementation at run time.  
         [0379]    public void setRelationFunctionName(String newRelationFunctionName)  
         [0380]    Sets the name of the relation function that is to be executed to newRelationFunctionName.  
         [0381]    public String getTargetRelationName( )  
         [0382]    Gets the name of the relation that is to be acted upon. The name is the logical name. The Run-time  162  may map the logical name to a physical implementation at run time.  
         [0383]    public void setTargetRelationName(String newTargetRelationName)  
         [0384]    Sets the name of the relation that is to be acted upon to newTargetRelationName.  
         [0385]    public Key getKey( )  
         [0386]    Gets the key of this.  
         [0387]    Run-Time Model  171  and Run-Time  162   
         [0388]    Run-time Model  171  consists of Kernel, Application, and Session. FIG. 10 shows the Run-time Model described using the Unified Modeling Language (UML) notation. Run-time  162  consists of an instance of Kernel Class, a set of instances of Application Class, and a set of instances of Session Class.  
         [0389]    Class Application  
         [0390]    public String getVersion( );  
         [0391]    Gets the version of this.  
         [0392]    public void setVersion(String newVersion);  
         [0393]    Sets the version of this to newVersion.  
         [0394]    public String getName( );  
         [0395]    Gets the name of this.  
         [0396]    public void setName(String newName);  
         [0397]    Sets the name of this to newName.  
         [0398]    public void addRelationDefinition(RelationDefinition relationdefinition, String name);  
         [0399]    Adds a relation definition to this.  
         [0400]    public RelationDefinition getRelationDefinition(String name);  
         [0401]    Gets a named relation definition.  
         [0402]    public void dropRelationDefinition(String name);  
         [0403]    Drops a relation definition.  
         [0404]    public void addRelation(String relationName, String relationDefinitionName);  
         [0405]    Adds a relation to this.  
         [0406]    public Relation getRelation(String name);  
         [0407]    Gets a relation.  
         [0408]    public void dropRelation(String name);  
         [0409]    Drops a relation.  
         [0410]    public void addEvent(String relationName, String eventName, Event event);  
         [0411]    Adds an event to this.  
         [0412]    public void dropEvent(String relationName, String eventName);  
         [0413]    Drops an event.  
         [0414]    public Event getEvent(String relationName, String eventName);  
         [0415]    Gets an event.  
         [0416]    public void addEventHandler(String eventHandlerName, EventHandler event);  
         [0417]    Adds an event handler to this.  
         [0418]    public void dropEventHandler(String eventHandlerName);  
         [0419]    Drops an event handler.  
         [0420]    public Event getEventHandler(String eventHandlerName);  
         [0421]    Gets an event handler.  
         [0422]    public void addRelationFunctionDefinition( RelationFunctionDefinition relationFunctionDefinition, String name);  
         [0423]    Adds a relation function definition to this.  
         [0424]    public RelationFunctionDefinition getRelationFunctionDefinition(String name);  
         [0425]    Gets a relation function definition.  
         [0426]    public void dropRelationFunctionDefinition(String name);  
         [0427]    Drops a relation function definition.  
         [0428]    public void addRelationFunction(String relationName, String relationDefinitionName);  
         [0429]    Adds a relation function to this.  
         [0430]    public RelationFunction getRelationFunction(String relationFunctionName);  
         [0431]    Gets a relation function.  
         [0432]    public void dropRelationFunction(String name);  
         [0433]    Drops a relation function.  
         [0434]    public void addThingDefinition(String thingDefinitionName, ThingDefinition keyDefinition);  
         [0435]    Adds a thing definition to this.  
         [0436]    public void dropThingDefinition(String thingDefinitionName);  
         [0437]    Drops a thing definition.  
         [0438]    public Event getThingDefinition(String thingDefinitionName);  
         [0439]    Gets a thing definition.  
         [0440]    public void addKeyDefinition(String keyDefinitionName, KeyDefinition keyDefinition);  
         [0441]    Adds a key definition to this.  
         [0442]    public void dropKeyDefinition(String keyDefinitionName);  
         [0443]    Drops a key definition.  
         [0444]    public Thing getKeyDefinition(String keyDefinitionName);  
         [0445]    Gets a key definition.  
         [0446]    public void addFactDefinition(String factDefinitionName, FactDefinition factDefinition);  
         [0447]    Adds a fact definition to this.  
         [0448]    public void dropFactDefinition(String factDefinitionName);  
         [0449]    Drops a fact definition.  
         [0450]    public FactDefinition getFactDefinition(String factDefinitionName);  
         [0451]    Gets a fact definition.  
         [0452]    public void addReferenceDefinition(String referenceDefinitionName, ReferenceDefinition referenceDefinition)  
         [0453]    Adds a reference definition.  
         [0454]    public void dropReferenceDefinition(String referenceDefinitionName);  
         [0455]    Drops a reference definition.  
         [0456]    public ReferenceDefinition getReferenceDefinition(String referenceDefinitionName);  
         [0457]    Gets a reference definition.  
         [0458]    public void startTransaction( );  
         [0459]    Starts a transaction.  
         [0460]    public void commitTransaction( );  
         [0461]    Commits a transaction.  
         [0462]    public void rollbackTransaction( );  
         [0463]    Rollbacks a transaction.  
         [0464]    public Relation execute(String relationFunctionName);  
         [0465]    Executes a relation function.  
         [0466]    public Key getKey( );  
         [0467]    Gets the key of this.  
         [0468]    Class Session  
         [0469]    public Application getApplication( );  
         [0470]    Loads an application to this.  
         [0471]    public Key getKey( )  
         [0472]    Gets the key of this.  
         [0473]    Class Kernel  
         [0474]    public void addUser(String userName, String password);  
         [0475]    Adds a user to this.  
         [0476]    public void dropUser(String userName);  
         [0477]    Drops a user.  
         [0478]    public void grant(String touser, String appName);  
         [0479]    Grants access privilege to a user for an application.  
         [0480]    public Session connect(String userName, String password, String appName);  
         [0481]    Opens a session to an application.  
         [0482]    public void removeSession(Key key);  
         [0483]    Closes a session.  
         [0484]    public Key loadApplication(File applicationDefinition);  
         [0485]    Loads an application to this.  
         [0486]    public void unloadApplication(Key key);  
         [0487]    Unloads an application.  
         [0488]    public Key getKey( );  
         [0489]    Gets the key of this.  
         [0490]    The network adapter  145  facilitates communication between the electronic device  110  and the network  120 . The network adapter  145  provides the electronic device  110  with a means of electronically communicating information with a remote electronic device, not shown. In addition, in another embodiment, the network adapter  145  may support distributed processing, which enables the electronic device  110  to share a task with other devices linked to the network  120 . Although the network adapter  145  is shown as part of the electronic device  110 , in another embodiment they may be packaged separately. Although only one network adapter  145  is shown, in other embodiments multiple network adapters of the same or of a variety of types may be present.  
         [0491]    The input device  150  is that part of the electronic device  110  that accepts input from a user. In an embodiment, the input device  150  may be a keyboard, but in other embodiments, the input device  150  may be a pointing device, mouse, trackball, keypad, touchpad, touch screen, pointing stick, microphone, or any other appropriate input device. Although only one input device  150  is shown, in other embodiments any number of input devices of the same or of a variety of types may be present. In another embodiment, the input device  150  may not be present.  
         [0492]    The output device  155  communicates information to the user of the electronic device  110 . The output device  155  may be a cathode-ray tube (CRT) based video display well known in the art. But, in other embodiments the output device  155  may be replaced with a liquid crystal display (LCD) based or gas, plasma-based, flat-panel display. In still other embodiments, any appropriate display device may be used. In yet other embodiments, a speaker that produces audio output may be used. Although only one output device  155  is shown, in other embodiments, any number of output devices of different types or of the same type may be present. In other embodiments, the output device  155  might not be present.  
         [0493]    The bus  180  may represent one or more busses (e.g., PCI, ISA (Industry Standard Architecture), X-Bus, EISA (Extended Industry Standard Architecture), or any other appropriate bus and/or bridge (also called a bus controller).  
         [0494]    The electronic device  110  may be implemented using any suitable hardware and/or software, such as a personal computer or other electronic computing device. Portable computers, laptop or notebook computers, and mainframe computers are examples of other possible configurations of the electronic device  110 . The hardware and software depicted in FIG. 1 may vary for specific applications and may include more or fewer elements than those depicted. For example, other peripheral devices such as audio adapters, or chip programming devices, such as EPROM (Erasable Programmable Read-Only Memory) programming devices may be used in addition to or in place of the hardware already depicted. Thus, an embodiment of the invention may apply to any hardware configuration that supports a Meta Model  160 , Run-time  162 , and Application  161 .  
         [0495]    As will be described in detail below, aspects of an embodiment pertain to specific apparatus and method elements implementable on electronic devices. In another embodiment, the invention may be implemented as a program product for use with an electronic device. The programs defining the functions of this embodiment may be delivered to an electronic device via a variety of signal-bearing media, which include, but are not limited to:  
         [0496]    (1) information permanently stored on a non-rewriteable storage medium (e.g., read-only memory devices attached to or within an electronic device, such as a CD-ROM readable by a CD-ROM drive);  
         [0497]    (2) alterable information stored on a rewriteable storage medium (e.g., a hard disk drive or diskette); or  
         [0498]    (3) information conveyed to an electronic device by a communications medium, such as through a computer or telephone network accessed via network adapter  145 , including wireless communications.  
         [0499]    Such signal-bearing media, when carrying machine-readable instructions that direct the functions of the present invention, represent embodiments of the present invention.  
         [0500]    [0500]FIG. 2 depicts a block diagram of a Relation Function, according to an embodiment of the invention. The Relation Function comprises an object-oriented representation of actions, queries, rules, constraints, or functions. The Relation Function receives a set, or array, of Relations as input and returns a Relation as output. The Relation Function can implement a query, an algorithm, a rule, a constraint, or a function.  
         [0501]    [0501]FIG. 3 depicts a block diagram of how new knowledge is derived from existing knowledge, according to an embodiment of the invention. The relation function F represents an algorithm to calculate or derive new facts that is returned in relation R.  
         [0502]    [0502]FIG. 4 depicts a block diagram of how Relation Functions and Relations form a closed algebra, according to an embodiment of the invention. A Relation Function can be substituted for a relation and vice versa.  
         [0503]    [0503]FIG. 5 depicts a block diagram of the relationship between the Event, Event Handler, and Relation Function, according to an embodiment of the invention. A relation can have events. An event has an event handler. An event handler has a relation function, an action, and a target relation. The action is the operation between the output of the relation function and the target relation.  
         [0504]    [0504]FIG. 6 depicts a block diagram of a recursive event, according to an embodiment of the invention. A recursive event modifies the relation that generated the event. Recursion ends when the calculated relation is empty.  
         [0505]    [0505]FIG. 7 depicts a UML representation of the Meta Knowledge Model  165 , according to an embodiment of the invention.  
         [0506]    [0506]FIG. 8 depicts a UML representation of the Meta Logic Model  166 , according to an embodiment of the invention.  
         [0507]    [0507]FIG. 9 depicts a UML representation of the Knowledge Definition Model  167 , according to an embodiment of the invention.  
         [0508]    [0508]FIG. 10 depicts a UML representation of the Run-time Model  171 , according to an embodiment of the invention.  
         [0509]    [0509]FIG. 11 depicts a UML representation of the Catalog Model  169 , according to an embodiment of the invention.  
         [0510]    [0510]FIG. 12 depicts a LML representation of a SYS_Catalog, according to an embodiment of the invention. SYS_Catalog is the root relation that stores all other relations. An instance of SYS_Catalog is created by the kernel automatically.  
         [0511]    [0511]FIG. 13 depicts a UML representation of SYS_App and SYS_AppKnowledge, according to an embodiment of the invention. SYS_App is a root relation of the Application Catalog.  
         [0512]    [0512]FIG. 14 depicts a UML representation of SYS_AppSessionKnowledge and SessionKnowledge, according to an embodiment of the invention. SYS_AppSessionKnowledge is the root relation of session specific knowledge. SYS_AppSessionKnowledge and the relations contained in it form the Session Catalog. An instance of a session catalog is created for each session. Session catalog is destroyed when user closes the session or when the session expires.  
         [0513]    [0513]FIG. 15 depicts a UML representation of SYS_AppRelation, according to an embodiment of the invention. SYS_AppRelation is a relation that stores application scope relations  
         [0514]    [0514]FIG. 16 depicts a UML representation of SYS_AppEvent, according to an embodiment of the invention. SYS_AppEvent is a relation that stores application scope events.  
         [0515]    [0515]FIG. 17 depicts a UML representation of SYS_AppEventHandler, according to an embodiment of the invention. SYS_AppEventHandler is a relation that stores application scope event handlers.  
         [0516]    [0516]FIG. 18 depicts a UML representation of SYS_AppRelationEvent, according to an embodiment of the invention. SYS_AppRelationEvent is the relation of that stores the events of application scope relations.  
         [0517]    [0517]FIG. 19 depicts a UML representation of SYS_KeyDefinition, according to an embodiment of the invention. SYS KeyDefinition is a relation that stores the definitions of application keys.  
         [0518]    [0518]FIG. 20 depicts a UML representation of SYS_ThingDefinition, according to an embodiment of the invention. SYS_ThingDefinition is a relation that stores the definitions of application things.  
         [0519]    [0519]FIG. 21 depicts a UML representation of SYS_ReferenceDefinition, according to an embodiment of the invention. SYS_ReferenceDefinition is a relation that stores the definitions of application references.  
         [0520]    [0520]FIG. 22 depicts a UML representation of SYS_RelationDefinition, according to an embodiment of the invention. SYS_RelationDefinition is a relation that stores the definitions of application relations.  
         [0521]    [0521]FIG. 23 depicts a UML representation of SYS_RelationFunctionDefinition, according to an embodiment of the invention. SYS_RelationFunctionDefinition is a relation that stores the definitions of application relation functions.  
         [0522]    [0522]FIG. 24 depicts a UML representation of SYS_FactDefinition, according to an embodiment of the invention. SYS_FactDefinition is a relation that stores the definitions of application facts.  
         [0523]    [0523]FIG. 25 depicts a UML representation of SYS_SessionRelation, according to an embodiment of the invention. SYS_SessionRelation is the root relation of all session scope relations.  
         [0524]    [0524]FIG. 26 depicts a UML representation of SYS_SessionEvent, according to an embodiment of the invention. SYS_SessionEvent is the root relation of all session scope events.  
         [0525]    [0525]FIG. 27 depicts a UML representation of SYS_SessionEventHandler, according to an embodiment of the invention. SYS_SessionEventHandler is the root relation of all session scope event handlers.  
         [0526]    [0526]FIG. 28 depicts a UML representation of SYS_SessionRelationEvent, according to an embodiment of the invention. SYS_SessionRelationEvent is the relation of that stores the events of a session relation.