Knowledge Base Layer

by

Adil KABBAJ

 

Introduction

Knowledge Base in Amine

Edition of Knowledge Base with Ontology/KB GUI

Knowledge Base and Dynamic Knowledge Integration Process

Knowledge Base and Memory-Based Inferences

Knowledge Base API

Implementation issues

 

Introduction

Unlike the previous versions of Amine, Amine 5.0 offers the possibility to make an explicit distinction between ontology and Knowledge Base (KB). Amine 5.0 provides two entities (classes): Ontology and KnowledgeBase, both are defined and implemented as graph of Conceptuals Structures (CS). With this new extension, the user (or the intelligent system/agent) can define an ontology for its domain and can develop various KBs that embeed various experiences or expertises about the domain. An ontology offers ontological knowledge  (type hierarchy, conformity relations between instances and types, types definition, individuals description, canons) and conceptual vocabulary (types, instances, relations) that can be used to express knowledge about different areas of a domain. A KB offers commonsense or expertise about a domain or about a specific area of a domain. Each KB should be supported by an ontology.

 

Knowledge Base in Amine

Definition

A Knowledge Base (KB) is a graph of Conceptual Structures with a specific ontology as its ontological support.

Rule Based and Case Based KB are examples of KBs that can be defined and developed separatly from the ontology that constitutes their ontological support.

In our current definition of KB, any type, or instance/individual or relation used in the KB should exist already in the associated ontology. This means that a KB will not contain a new type (or instance or relation); a type that is not specified in the ontology. Also, any ontological knowledge about the conceptual elements/vocabulary (types, instances and relations) such as the super-types or subtypes of a type, the definition of a type, the description of an instance/individual, etc. is looked for in the ontology; not in the KB.

Basically, in our current definition of KB, a KB will be composed of situations, rules and indexedTypes.

IndexedType CS is a new "auxiliary" CS added since Amine 5. It is defined as a specialization of Type CS; it is a reference to a Type CS contained in the ontology. IndexedTypes play the role of Indexes to Situations and Rules in a KB (see example below).

The Ontology GUI has been extended to enable both the edition of ontologies and KBs (see Edition of Knowledge Base with Ontology/KB GUI). Also, Knowledge Integration Processes have been updated to apply on both ontologies and KBs (see Knowledge Base and Dynamic Integration Process). Last but not least, memory-based inferences have been defined and implemented on both ontologies and KBs (see Knowledge Base and Memory-Based Inferences).

 

Example

This example illustrates a KB of situations. Figure 2 shows this KB while Figure 1 shows the ontology that supports the KB.

Figure 1: The ontology  (to be found at: samples\ontology\Sowa_CG_Generalization_Hierarchy.xml) used as support for the KB of Figure 2

 

Figure 2 shows a KB of Situations. This example was proposed first by John Sowa to show CG hierarchy. Figure 2.a presents the KB as displayed by Amine Ontology/KB GUI. Figure 2.b presents the CG hierarchy as drawn by John. The two hierarchies are equivalent. Chase, Wash and Act (as well as Universal) in Figure 2.a are IndexedTypes: they refeer to the associated Types in the ontology. Their role in the KB is to index Situations (and/or Rules). Note that only types that are needed to index direclty Situations/Rules are specified (as IndexedType) in the KB.

     

               (a)  a KB of Situations                                                            (b) CG Hierarchy that corresponds to (a)

Figure 2: The KB (Situations KB) supported by the ontology of Figure 1

 

Edition of Knowledge Base with Ontology/KB GUI

Ontology and Knowledge Base are edited with the same GUI: Ontology/KB GUI. Here, we show the first steps in the manual creation of a KB. See Ontology/KB GUI for more detail on the GUI.

Ontology GUI has been extended to enable both the edition of ontologies and KBs. Thus, file operations (like "New", "Open", "Save", "SaveAs", "Close") apply on both ontologies and KBs.

Figure 3.a illustrates the case of the creation of a new KB. A message is then prompted that inform the user to Open/Load an ontology first since any KB requires an ontology as its ontological support (Figure 3.b).

                 

                (a) Creation of a New KB                                                                (b) The first action is to load an ontology

Figure 3: Creation of a new KB

Figure 4 shows the selection of a specific ontology for our new KB. The selected ontology is "Sowa_CG_Generalization_Hierarchy.xml".

Figure 4: Selected Ontology for the new KB

Figure 5.a shows the initial state of the new KB: it is composed of one IndexedType "Universal". Figure 5.b shows the attempt to add a new IndexedType. IndexedTypes are added as if they are new types (but they aren't really new types; they are pointers to types that exist in the ontology).

                       

                    (a) initial state of the new KB                                                        (b) an attempt to add a new IndexedType

Figure 5: The initial state of a new KB

Figure 6.a shows the addition of a new indexedType "Act". Figure 6.b shows the addition of a new situation which is indexed under "Act". It shows also the attempt to provide a description for the situation, by activating the "Show/Edit content" action.

                       

                    (a) addition of a new IndexedType                                                (b) addition and edition of a new Situation

Figure 6: addition of a new type and a new Situation

Figure 7 shows the description of the situation.

Figure 7: Description of the situation

Other IndexedTypes, Situations and/or Rules can be added to the KB with the same process. Figure 8 shows the save action. Note that AminePlatform provides a default directory for KB (samples\knowledgeBase). But of course, user can save his/her KB in any other directory.

 

Figure 8: Save the new KB

Figures 9-10 show "Open/Load KB" action.

  

Figure 9: Open/Load a KB I

 

 

Figure 10: Open/Load a KB II

The ontology that supports the current KB can be displayed separatly, in another Ontology/KB GUI, by activating the action Display/"Run Ontology GUI", as illustrated in Figure 11.

Figure 11:  Selection of the action "Run Ontology GUI"

Figure 12 shows both the KB and the supported ontology. Of course, user can browse both the KB and the ontology.

Figure 12:  A KB and the ontology that supports it

 

Knowledge Base and Dynamic Knowledge Integration Process

Dynamic Knowledge Integration Process enables automatic and incremental construction/formation and update of both ontology and KB. See Dynamic Knowledge Integration Process for the detailed description of this important process.

Please, note that the GUI for Dynamic Knowledge Integration Process, DynamicIntegration GUI, is used for both ontologies and KBs.

The KB in Figure 2.a has been created/constructed using Dynamic Knowledge Integration Process and its related GUI. Here we show the first steps of this automatic formation/construction of a KB. The process starts with the initial state (illustrated in Figures 3-5): the KB contains only the indexedType "Universal" which is a pointer to the root of the ontology (the ontology used is "aminePlatform\samples\ontology\Sowa_CG_Generalization_Hierarchy.xml").

Figure 13 shows the selection of the Integration mode; in our case the selection of Classification.

Figure 13:  Selection of Classification Based Integration

Figure 14 shows the selection of the type of CS to classify; in our case the selection of Situation.

Figure 14:  Selection of the type of the CS to Integrate (to classify in this example)

Figure 15 shows the description of the first situation to integrate.

Figure 15:  The first situation to integrate (to classify)

Figure 16 shows the selection of pertinent types. Here, the type "Act" is selected and is considered as pertinent. Since no IndexedType exists already in the KB for the type "Act", the integration process will create first such an IndexedType and it will add it as a children/subtype of the IndexedType "Universal" (Figure 17). Then, the integration process proceeds by initiating the propagation process of the new description (i.e. the new situation) from the CS node that is associated to the specified pertinent type; that is: it will start the propagation from the IndexedType for "Act".

Figure 16:  Selection of pertinent types

Since the IndexedType "Act" has no child, the new situation is simply added as a new children for "Act" (Figure 17.a). Figure 17.b shows the first steps in the integration of the second situation. The type "Wash" is selected as the direct pertinent type in the description of the second situation.

        

            (a) result of the integration of the first situation                            (b) first steps in the integration of the second situation

Figure 17:  Integration of the second situation

Figure 18.a shows the selection of the supertype "Act" as another pertinent type. Recall that the integration process proposes also, as possibly pertinent types, the supertypes of the direct pertinent types. Figure 18.b shows the result of the integration of the second situation. Integration of other situations follows the same steps. The result of the integration of all the situations (proposed by John in his example; see Figure 2.b) is shown in Figure 2.a.

 

                

Figure 18:  The result of the integration of the second situation

 

Dynamic Integration of Rules in a KB

This section is a complement to Rule Dynamic Integration Process. Instead of dynamic integration of rules in an ontology, we present here an example of dynamic integration of rules in a KB.

As an example, let us start with KB "kb2.xml"  (aminePlatform\samples\knowledgeBase\kb2.xml). Figure 19 shows the state of the KB and also the first steps in the classification of the rule specified in Figure 19 (i.e. select/press button "Classification", enter/edit the rule to classify, provide the pertinent types, and press the button Classify to initiate the classification process).

 

Figure 19: Classification of a CSRule in a KB

Figure 20 shows the result of the classification. Note that even if the antecedent of the new Rule is EQUAL to the situation [Animal:a]<-Agnt-[Chase]-Theme->[Entity:e], the Rule is considered as MORE_SPECIFIC than the situation; the rule  specifies more information than the situation. See Rule Dynamic Integration Process for the presentation of comparison of Rule and Situation.

Figure 20: Classification of a CSRule in a KB (continue)

Now, integration (by classification) of the rule showed in Figure 21 leads to the content of the KB displayed in Figure 21.

Figure 21: Classification of a second CSRule in a KB (continue)

 

Knowledge Base and Memory-Based Inferences

Application of Memory-Based Inferences on a KB is similar to Memory-Based Inferences on ontology. See Ontology/KB/Memory Based Inferences for detail. Here we provide only an example of Memory-Based Inferences on a KB.

Let us use the KB "kb2.xml" after the addition of the two rules above (Figures 20-21). Figure 22 shows the initiation of KB-Based deductive inference (after the selection/press of button "Deduction" and the edition of the situation in "Memory-Based Inferences Frame" and the selection/press of button "Deduction").

Figure 22: Initiate KB-Based Deductive Inference

Figure 23 shows the result of the deduction.

Figure 23: Result of KB-Based Deductive Inference

 

Knowledge Base API

KnowledgeBase is a graph of CS supported by an ontology. A KnowledgeBase is implemented as an ontology augmented by a graph of CS. The root of this graph is the attribute "kbRoot".

public class KnowledgeBase extends Ontology {

        private IndexedType kbRoot;

        private String kbFilePath;

        ...

}

KnowledgeBase Constructors:

public KnowledgeBase() throws OntologyException ;

public KnowledgeBase(Ontology ontology) throws OntologyException ;

public KnowledgeBase(Type ontologyRoot) throws OntologyException ;

public KnowledgeBase(Type ontologyRoot, RelationType relationRoot) throws OntologyException ;

public KnowledgeBase(Identifier ontologyRootIdentifier, Identifier relationRootIdentifier, Identifier mainLanguage) throws OntologyException ;

public KnowledgeBase(Identifier ontologyRootIdentifier, Identifier relationRootIdentifier,Identifier mainLanguage, Object[] languages) throws Exception;

 

Getters and Setters

public IndexedType getKBRoot() ;

public void setKBRoot(IndexedType kbRoot) ;

public String getKBFilePath() ;

public void setKBFilePath(String kbFilePath) ;

public IndexedType getIndexedType(Type type);

public static KnowledgeBase loadKBFromXML(String filePath, ParseCSDescription parseCSDescr) throws Exception;

 

The method getIndexedType(Type type) returns the IndexedType, in the KB, that is associated to the type specified as parameter. All IndexedTypes in a KB are direct subtypes of the KBRoot.

 

Implementation issues

When created, the ontology that supports a KB is "incorporated" in the new KB. For instance, when a KB is created with the constructor KnowledgeBase(ontology), the ontology given in argument will be the ontology part of the KB. It is important to note that only the strict KnowledgeBase part; the graph of CS with root KBRoot, which is saved/stored as KB (in an xml file). The file path of the ontology that supports the KB is also stored as an attribute of the KB. But the ontology that supports the KB is stored in its own file. Open/Load a KB file involves first loading the associated ontology and then the creation of the KB from the xml file.