Conceptual Ontology

and

Conceptual Structures

 

by

Adil KABBAJ

 

Last update: January 2008

Last version: Amine 5

 

 

N.B: We suggest to consider first the Introduction. Then Consider News for the new version Amine 5.

 

Introduction

Conceptual Ontology and Conceptual Structures: A structural view

Lexicons / Ontology relationship

APIs for Conceptual Ontology and Conceptual Structures

Creation and use of an Ontology

Examples (part I)

Amine Genericity concerning Conceptual Structures Description

Examples (part II)

Ontology API in action

From “weak” to “strong” multi-lingua ontology

Next   

 

Introduction

 

Ontology

John Sowa summarized very well various "threads" that underly the need and importance of Ontology: "For centuries, philosophers have sought universal categories for classifying everything that exists, lexicographers have sought universal terminologies for defining everything that can be said, and librarians have sought universal headings for storing and retrieving everything that has been written. During the 1970s, the ANSI SPARC committee proposed the three-schema architecture for defining and integrating the database systems that manage the world economy. Today, the semantic web has enlarged the task to the level of classifying, labeling, defining, finding, integrating, and using everything on the World Wide Web, which is rapidly becoming the universal repository for all the accumulated knowledge, information, data, and garbage of humankind", from Building, Sharing, and Merging Ontologies

Ontology is a multi-disciplinary subject, treated for centuries by philosophers, linguists, cognitive psychologists, researchers in Artificial Intelligence, and now researchers in semantic web. John Sowa provides a good synthesis in his second book [Sowa, 00]. In the present document we are not concerned by a general introduction and presentation of the complex subject of Ontology. Our concern is rather the definition and use of Ontology in Amine Platform. For a general introduction of the Ontology subject, we suggest the document of [Farrar and Bateman, 04] : General Ontology Baseline. For a general discussion of Ontology in Amine, see [Kabbaj and al., 06].

So what is an ontology ? Again, Sowa provides this general answer: "The subject of ontology is the study of the categories of things that exist or may exist in some domain. The product of such a study, called an ontology, is a catalog of the types of things that are assumed to exist in a domain of interest D from the perspective of a person who uses a language L for the purpose of talking about D. The types in the ontology represent the predicates, word senses, or concept and relation types of the language L when used to discuss topics in the domain D.", from Building, Sharing, and Merging Ontologies

Any conceptual description about a domain D is expressed in terms of concept types and relation types specified in the Ontology. For instance, the description "The boy eats an apple" involves three concept types (Boy, Eat, Apple) and two relation types (agentOf: the Boy is the agent of Eat, and objOf: apple is the object of Eat).

In general, concept/relation types are ordered in a generalization/specialization hierarchy, called type hierarchy. Type hierarchy constitutes the kernel of an ontology. An ontology that contains only type hierarchy can be called type hierarchy ontology (Figure 1). This minimal definition of an ontology can be extended by associating to each type its definition. The result is a  terminological/definitional ontology (Figure 1).

Also, we can associate to each type its instances (individuals) with their descriptions. Moreover, it is well known in Philosophy, linguistics and Cognitive Science that some "real-world" types have no clear and complete definition but only a canonical description that describes constraints on the use of the type. Other "real-world" types have only a cluster of schemas that illustrate the use of the type in common situations. Yet other "real-world" types are "presented" by a prototype. Type definition, canon, schemas cluster, individual description, and prototype constitute various types of Conceptual Structures (CS). An ontology that is constitued from these Conceptual Structures may be called knowledge based or commonsense based ontology (Figure 1).

       

Figure 1: Ontology Types hierarchy

 

Conceptual Structures and Knowledge

The first book of John Sowa, Conceptual Structures: Information Processing in Man and Machine, 1984,  presents conceptual structures in detail and provides a good synthesis of works in Cognitive Science about their relevance in describing knowledge. See Conceptual Structures for an overview of Sowa's presentation of CS and examples of their formulation in Amine.

Conceptual Structures (CS) represent, organize and encapsulate Knowledge. It can be ontological knowledge; knowledge that constitutes an ontology, or  background and common sense knowledge that constitutes a Knowledge Base. The important conclusion is that both ontology and knowledge base are constitued of Conceptual Structures. Amine provides possibilities to manipulate CS and to construct both ontologies and KB that are based on CS.

 

Knowledge Base

A Knowledge Base represents knowledge, experience and expertise of an agent about a domain D. Before the interest to ontology in AI (in the 90's), no (clear) distinction was made between ontological knowledge and background/commonsense knowledge; a Knowledge Base (KB) may contain any kind and combination of Knowledge. Like an ontology, the kernel of a KB is a type hierarchy, with optionally type definition, individual description, canons and schemata. These correspond to the various CS introduced before. Beside this kind of KB, an Intelligent System can have also a Rule Based KB; like Expert Systems. Also and especially with the advance of case-based systems, a system can have a case or situation based KB: a KB of specific and/or generic cases (situations). It can have also an assertional or a factual based KB; a KB for specific facts concerning a particular domain. The assertional (or factual) base can be viewed as a special kind of case/situation based KB.

An Intelligent System can keep separate these various kinds of KB or it can have one integrated KB that includes all these kinds of knowledge. Such an integrated KB maybe considered also as an integrated knowledge based ontology (Figure 1).

Please, note that while the term “schema” is used in general instead of "situation" to describe a generic and stereotyped knowledge, our use of the term situation is much broader: a situation can be generic like a schema (or a generic case) or it can be specific like a fact, a specific case or a specific situation.

 

Build ontology and KB with Amine Platform

Amine provides possibilities to manipulate CS and to build, edit and use both ontologies and KB that are based on CS. Amine Platform allows the user to build and manipulate various types of ontology (Figure 1) and KB. In the previous versions of Amine (versions 1-4), there was no clear distinction between ontology and KB: previous versions of Amine provide an entity (i.e. a class) that represents Ontology, but no entity (no class) for KB. A KB was represented and defined as a Knowledge/Commonsense based ontology. Amine 5.0 offers the possibility to define and specify ontology and KB as two distinct entities; beside the entity (the class) Ontology, Amine 5.0 offers the entity (the class) KnowledgeBase. Of course, each KB has an ontological support wich is an ontology. Note also that several KBs may have the same ontological support; the same ontology.

See Introduction for the new architecture of Amine 5.0 and KnowledgeBase for more detail on Knowledge Base in Amine.

It should be stressed that Amine Platform does not provide a specific ontology (like CYC or WordNet) that other systems can access, use or extend. Amine provides rather a framework and tools that allow a user to build, use, update and manipulate ontologies and KB. Simple examples of ontologies are provided below and more complex ontologies are provided in Samples.

 

In conclusion

The above introduction can be summarized as follows:

1. Conceptual Description and Conceptual Ontology/KB: concepts and relations between concepts are the basic components of any conceptual description. A concept corresponds either to a generic and existential reference to a type (a Man, a Table) or to a specific individual of a type (Man 'Karl', Dog 'michou'). More precisely, we have three basic conceptual elements: type (or category), individual and relation. Any conceptual description, being generic or specific, is composed of these three basic conceptual elements. We come closer in this sense to the existential graph of the great logician and philosopher C. Peirce who developed a more realistic logic and philosophy than his contemporaries (Frege, Carnap and Russell), a point that John Sowa exposed in his second book [Sowa, 00]. At the next level of the "conceptual realm", we have the type hierarchy, which denotes the specialization/generalization order/relation between types (or categories), and conceptual structures (CS) that "organize/encapsulate" different kinds of knowledge about type, individual and relation: definition of a type (and of a relation), canon for a type (and for a relation), description of an individual, situations for types and individuals, and rules. In conclusion and to stress the strong relation between conceptual description and ontology, we can say that: Conceptual description is composed of concept types, individual and relation types, and ontology is composed of CS that provide semantic (ontological knowledge) for the components (concept types, individual and relation types) of any conceptual description.

    

2.  The mutual dependence of Basic Conceptual Elements and Conceptual Structures: A CS is described in terms of conceptual elements (type, individual, relation) which are defined/described by the associated CSs. It is important to be aware of this circular definition and of the mutual dependence of CSs and conceptual elements. Recall also that the meaning of a type in Amine ontology is an open and extensible cluster of CSs associated to this type. Thus, and according to meaning, a type is just an abstraction or a reference to its cluster of associated CSs in the ontology (and/or the KB).

3. Amine Conceptual Ontology is a "language free ontology" ; It is made of abstractions: An Amine ontology is a graph of CSs and since CSs are abstract structures, it follows that an ontology in Amine is a conceptual ontology; a "language free ontology" ; it is made of abstractions. For instance, if we adopt Conceptual Graph (CG) as a description scheme for CSs and if we look "inside" the implementation of CG in Amine Platform, we will not find symbols (identifiers) in the place of concept types, designators and relation types, but instead references to CSs (in the ontology) for these conceptual elements. An example is given below to illustrate this important point.

4. Amine ontology is independent from any specific description scheme. It is important to stress that Amine's definition of an ontology and of a KB is not committed to Conceptual Graph (CG) theory; type hierarchy and CSs are not specific to this theory, they refeer to Cognitive Structures that are identified and studied by Cognitive Science which constitutes the background for Amine. John Sowa provides Conceptual Graph as a notation for the representation of these conceptual/cognitive structures. They can be represented by different notations, i.e. a CS can be described by any description scheme, not only CG. In the context of Amine, any description scheme (CG, KIF, RDF, XML, Frame-Like, etc.) that is implemented in Java can be used as the description scheme for CSs. Due to different constraints (time, human resources and financial constraints), we have worked and developed tools for one specific description scheme; Conceptual Graphs (CG) structure. Other description schemes can be (developed and) adopted however. There is even the possibility to use different description schemes in the same ontology (see Examples below). Why we have adopted CG ? CG is not "yet another" specific semantic network version, it is a "generic" definition of any conceptual description. CG has the power and formality of first-order logic and the readability and expressiveness of semantic networks.

5. A clear and precise treatment of the relationship between conceptual and linguistic aspects. There is a clear and strong relation between conceptual elements (type, individual, relation) and symbols (or identifiers) in a specific language (natural or artificial): to communicate knowledge we need language. To communicate Knowledge from a conceptual ontology or from a KB which are "abstract and free language", an Amine application needs an "interface": symbols (words) and hence a language. Amine Platform supports multi-lingua conceptual ontology/KB: the user can associate to any conceptual ontology and KB, not only one language but several languages with their lexicons. A lexicon records the relation between symbols (identifiers) and CSs. As shown in Lexicon, Lexicon API provides operations that deal with linguistic problems such as synonymy. At the front side, Amine Platform accepts a CG description that is expressed in a specific language (English, French, etc.), parses it to a "language free, abstract" description and then apply operations on this abstract structure. At the end side, Amine Platform returns, to the user, a "linguistic" formulation of a CG in a specific language and notation (LF, CGIF or graphic notation).

 

Conceptual Ontology and Conceptual Structures in Amine : A structural view

Definition: An ontology (in Amine) is a graph of Conceptual Structures (CS) with one type root (a Type node for the most general concept type) and one relation root which is a direct subtype of the type root. As nodes of a graph, each CS s refers to the immediate CSs that s specialize (i.e. the direct fathers of s) and to the immediate CSs that are specialization of s (i.e. the immediate children of s). Also, each ontology has a collection of lexicons that are associated to it.

Definition: A lexicon of a language L for an ontology O contains the association between identifiers (words) in L and CSs in O.

Definition: Conceptual Structure (CS) are of five categories:

·                    Type CS/node: Each concept type is represented by a Type CS/node in the ontology. Type CS specifies/stores the definition and/or the canon of a type.

·                    RelationType CS/node: Each relation type is represented by a RelationType CS/node in the ontology. RelationType CS specifies/stores the definition and/or the canon of a relation type. RelationType is a specialization of Type.

·                   Individual CS/node: An individual of a concept type is represented by an Individual CS/node. The description of an individual is stored in this Individual node. An individual CS is immediately related to the individual's Type CS.

·                    Situation CS/node: A situation is stored in a Situation CS/node. A situation can be related to Types, RelationTypes, Individuals, and Situations.

See Conceptual Structures for some background information and examples. See KnowledgeBase for the definition of Knowledge Base.

 

Three new categories of CSs have been added since Amine 3:

·                   Context CS/node: a node that contains the description of a context. This type of nodes is used for the representation and integration of composed descriptions (like compound CGs). A Context is a kind of Situation that is embedded in a description. Like Type and individual, Context plays an abstraction and an indexation role. The many advantages and the enhance of the expressive power that is gained with the addition of Context CS is illustrated especially by the integration of complex structures in Amine Ontology. See Dynamic integration for more detail.

 ·        Rule CS/node: A rule is stored in a CSRule CS/node. A rule can be related to Types, RelationTypes, Individuals, Situations and Rules.

 

·                   Metaphor CS/node: a node that represents a metaphor. See metaphor and related processes for more detail.

Remarks:

1. A concept type can have a definition and/or a canon, can have several situations and several individuals. A relation type can have a definition and/or a canon and several situations. Canon for a relation type will specify the signature of the relation (required types for source and target concepts). An individual of a concept type can have a description and several situations. A situation has a description and it can be specialized by other situations.

2. Amine ontology is in general a graph hierarchy, not a tree hierarchy. One reason is that a concept type can be defined as a specialization of not only one direct superType (one genus) but of several direct superTypes. Examples of concept type and relation type definitions are given in Conceptual Structures and Examples. A second reason is that a situation can be indexed as a situation for not only one type but for several Types, Individuals, and Situations.

3. We can access the graph of CSs that constitutes the body of the ontology from its main type root, from any CS/node, or from any entry of any lexicon associated to the ontology.

4. In Amine, we are not concerned by the “semantic” of the ontology: how to identify types for a specific domain?; what types should be considered as primitives and what types should be considered as derived types (and derived from what types ?), what is concept type and what is relation type ?, what information should be contained in a type definition ?, etc. We are concerned more by organizational and representational issues. It is the responsibility of the user to use Amine organization and representation scheme to model his/her ontology (and to decide what primitive types are and what are derived types, etc.).

5. In Ontology Processes, we present current basic Amine ontology-based processes:

   a) Elaboration process: a process that enables an incremental elaboration of a given description by adding relevant information from the current ontology,

   b) Elicitation process: an interactive process that helps the user to make its description more precise and more explicit,

   c) Information retrieval process: a process that enables the retrieval of information from the ontology,

   d) Dynamic integration (or automatic formation) process is presented in a separate document.

 

Ontology, KB and Metaphor

Several studies [Ortony, Lakoff and Johnson, Carbonell, Indurkhya, Chibout and Vilnat] show the importance of metaphor in human cognition. They show also that metaphor takes root deeply in human cognition and a model of human/cognitive ontology should consider and integrate this important aspect. Metaphor is no more a taboo subject or a phenomenon that should be avoided (because it is not clearly defined); it is a cognitive element, essential and basic like any other (basic) cognitive element. The author is currently working on metaphor and related processes; metaphor resolution and metaphor creation, and their integration in Amine Platform. We introduce in this document a new Conceptual Structure (CS): metaphor, which represents a metaphor in ontology. The document Metaphor Processes introduces our current modelization of these processes.

 

Conceptual Structure (CS) description

As stated in the introduction, Amine Platform is independent from any specific description scheme (concerning the description of CS). Any Amine structure (AmineSet, AmineList, Term, Concept, Relation, or CG) can be used. Moreover, a user can define/use his own structure (this point will be discussed below). However, a description scheme will have a high expressive power if it allows a "natural and easy" expression of all the elements of a conceptual description (recall that a conceptual description is composed of types, individuals/instances, and relations). CG has such a high expressive power. See Conceptual Graph (CG) for more further details on "CG in Amine".

If CG is used to describe CSs, concept type definition and relation type definition have to use Amine keywords parameters: "super", "x_source", and "y_target":

1. Concept type definition with CG: In CG theory, a lambda expression is used to describe concept type definition. Instead of lambda expression, Amine provides the keyword super to specify the genus for the type being defined. Note that a type can be a specialization of one or several genus.

Examples :

Type Man is  [Person :super]-attr->[Sex = male] which has one genus.

Type Intelligent_System is

  [Intelligent :super]<-attr-[System :super]<-obj-[Build]-agnt->[AIScientist]

  Intelligent_System has two genus (Intelligent and System).

2. Relation type definition with CG: In CG theory, a lambda expression is used to describe relation type definition. Instead of lambda expression, Amine provides two keywords: x_source and y_target to specify what concepts in the definition of the relation correspond to the source concept and to the target concept.

Example:

RelationType workOf is [Person :x_source]<-agnt-[Work]-obj->[Job :y_target]

 

Conceptual Structure description is an abstract description

As noted in the previous section, the description of a CS, which can be a CG or any other structure, is not composed of identifiers but of references to other CSs and so it is "abstract and language free description". The use of identifiers (and lexicons) occurs only when an Amine application has to communicate or to express its knowledge (descriptions) to a language-based system (i.e. to human for instance). Consider the following example:

Example:

Figure 2 shows "free language" descriptions and illustrates the types of relations between CSs: Man is a subTypeOf Person (Man is a Person with sex male), Carla is an individualOf of Person, a situation (“Person loves nature”) is a situationOf Person. We use CG to describe the content of CSs but other structures can be used. Note also that concept types, individuals/instances and relation types in the CG are not identifiers but rather references (pointers or addresses) to CSs. For instance, “^cs01” in [^cs01: super] means a reference to the Type CS (a Java object) that defines the concept type identified (in English) by “Person”.

Figure 2: Relations between CSs and "language free descriptions"

 

 

Lexicons/Ontology relationship

An ontology in Amine Platform is a conceptual and “language free” ontology: descriptions are not composed of identifiers but of references to CSs. The example above illustrates this aspect. To communicate with other language-based systems, conceptual ontology should be augmented with a linguistic interface, i.e. a lexicon that records the association between words (identifiers) and CSs (especially Type and Individual CSs). Humans use, in general, a subset of a natural language lexicon as a source for his set of identifiers to consider, i.e. a French speaker will use French words as identifiers, an English speaker English words, etc.

Amine Platform supports multi-lingua ontology: many lexicons (one per language) can be associated to one ontology and many identifiers in the same lexicon and/or in other lexicons can refer to the same CS. Those identifiers are synonyms. We refer the reader to Lexicon for more detail about this basic component. Here we use the previous example to illustrate the relationship between lexicons and ontology (Figure 3): we associate two lexicons to the ontology. As explained in Lexicon, the real structure of a lexicon is more complex (composed of two lexicons), but we illustrate it here with an abstract view of the lexicon. In the EnglishLexicon (Figure 3), Person and Human are synonyms because they refer to the same CS (cs01). They are in turn “synonyms” of Personne and Humain (the two are from the FrenchLexicon) since all these identifiers refer to the same CS (Figure 3).

 

 Figure 3: Multi-lingua ontology

 

Implementation of the strutural part of Ontology and CSs

An ontology in Amine is implemented as a Java class with the following attributes: a Type root, a RelationType root, and a collection of lexicons that are associated to the ontology. In addition, we specify the main lexicon that is associated to the main language. For any concept type, relation type or individual, the user must specify the identifier in the main language and he/she can specify synonyms in the main language and/or in other languages. As a consequence of supporting multi-lingua ontology, we consider the case of “mixed language description”: a description in any language associated to an ontology can contain identifiers for concept types, relation types or individuals that can be formulated in the main language. We can have for instance a description in French with identifiers (words) that belong to English. Thus, we associate to an ontology a boolean attribute, "mixedLanguage", which is common to all the languages associated to the ontology: mixedLanguage attribute enables to switch on or off the possibility to have "mixed descriptions". If mixedLanguage is true, a description can be in a mixed language. If mixedLanguage is false, the description should be described with the current language only.

As introduced above, an ontology in Amine Platform is a graph of CSs. A CS is either a Type, a RelationType, an Individual, a Situation, a Context, a Metaphor or a CSRule. At the implementation level, we have a Java class, called CS, with four main subclasses: Type, Individual, Situation and CSRule. Type is itself specialized in RelationType, Situation is specialized in Context and Metaphor. The graph structure of the ontology is implicitly encoded by the links that are specified in each CS: like nodes of a graph, each CS s refeers to the immediate CSs that s specialize (the direct fathers of s) and to the immediate CSs that are specializations of s (the immediate children of s). Both Individual and Situation inherit the attribute description (declared as a Java Object) from CS. Type and RelationType use the inherited attribute "description" to formulate the "definition" of the type and they have a specific attribute, "canon" which is declared as a Java Object, to formulate the canon of the type. Context node extends Situation by adding the subject of the context (either a Type CS or an Individual CS). Metaphor extends Situation by adding a reference to the metaphorical object (in the description), the source type and the target type, both are Type CS. In the metaphor "Karla devoured the book", source type is Devoured and target type is Read.

Remark: While it is redundant to specify both the fathers and the children of a CS/node, it is however more efficient for the traversal, search and update of the ontology. We prefer efficiency, at the expense of redundancy.

 

The meaning of links in the Ontology

We adopt in Amine a generic model of an Ontology: different categories of ontologies are supported, from a simple type hierarchy based ontology to an integrated ontology where knowledge-based ontology is merged with situation or case-based ontology. The underlying assumption of Amine is the possibility to associate to each type (and individual) all (or most of) the knowledge acquired by the system concerning this type. Such knowledge is organized in terms of Conceptual Structures (CSs).

This genericity in our definition of an ontology is reflected in the types of nodes that compose an ontology (Type, RelationType, Individual, Situation, Context, Metaphor and CSRule) and also in the types of links that relate these CSs: specialization “s”, instantiation “i” (an individual is an instance of a Type) and use “u” (a Type/Individual is used in a description of a Type/Individual/Situation). Specialization has two interpretations: a) “specialization by definition”: a Type is defined as a specialization of another type, b) “specialization by description”: the description of a situation is more specific than the description of another situation. We precise below the structure of an Ontology: for the three categories of nodes (Type, Individual, and Situation) we specify the possible relations that can exist between the current node and the other nodes. Let us start with the case of a Type:

Possible relations of a Type to other CSs (Figure 4):

                           

Figure 4: Possible relations of a Type to other CSs

Type –u-> Situation : a Type can be used in the description of a Situation. Note that Type can be used in the descriptions of several situations.

Type –u-> CSRule : a Type can be used in the description of a Rule. Note that Type can be used in the descriptions of several Rules.

Type –s-> Type : a Type (the source of the relation) can be specialized by another Type (the target). A Type can be specialized by several other Types.

Type –u-> Type : a Type can be used in the definition of another Type. A Type can be used in the definition of several other Types.

Type –u-> Individual : a Type can be used in the description of an Individual. A Type can be used in the description of several Individuals.

Type –i-> Individual : a Type can be instantiated by an Individual. A Type can have several instances (Individuals).

If we consider CSs that can be linked to a Type, we find of course Type –s-> Type and Type –u-> Type. But there is also the possibility : 

Situation –s-> Type : the description of a Situation can be specialized by the definition of a Type.

Individual –u-> Type : an Individual can be used in the definition of a Type.

Possible relations of an Individual to other CSs (Figure 5):

                                                          

Figure 5: Possible relations of an Individual to other CSs

Individual –u-> Situation : An Individual can be used in the description of a Situation. An Individual can be used in descriptions of several situations.

Individual –u-> Type : An Individual can be used in the definition of a Type. An Individual can be used in definitions of several Types.

Individual –u-> Individual : An Individual can be used in the description of another Individual. An Individual can be used in descriptions of several other Individuals.

If we consider CSs that can be linked to an Individual, we find of course Type –i-> Individual, Type –u-> Individual, and Individual –u-> Individual. But there is also the possibility:  Situation –s-> Individual : the description of a Situation can be specialized by the description of an Individual.

Possible relations of a Situation to other CSs (Figure 6):

Figure 6: Possible relations of a Situation to other CSs

Situation –s-> Situation : the description of a Situation can be specialized by the description of another Situation. A Situation can be specialized by several other Situations.

Situation –s-> CSRule : the description of a Situation can be specialized by the description of a CSRule. A Situation can be specialized by several CSRules.

Situation –s-> Type : the description of a Situation can be specialized by the definition of a Type. A Situation can be specialized by definitions of several Types.

Situation –s-> Individual : the description of a Situation can be specialized by the description of an Individual. A Situation can be specialized by descriptions of several Individuals.

 If we consider CSs that can be linked to a Situation, we find of course Situation –s-> Situation, Type     –u-> Situation, CSRule -s-> Situation, and Individual –u-> Situation.

 

Possible relations of a CSRule to other CSs :

A CSRule can be specialized by other CSRules. It can be specialized also by situations; a situation is compared to the antecedent of a CSRule.

 

APIs for Conceptual Ontology and Conceptual Structures 

Ontology API is partitioned over the Ontology class and over the CS class and its subclasses (Type, RelationType, Individual and Situation). Here, we give only an overview of this API. For further details, see the API specification of these classes. Of course, the reader can consult the source code for specific implementation details. We made a great effort to produce a very easy and readable code, very close to the conceptual and specification descriptions.  

2.  Operations defined in the class CS (Conceptual Structure) : these operations concern the creation and destruction of links between CSs, and also traversal of links (browsing the ontology), operations that are common to all CS subclasses (Type, RelationType, Individual, and Situation). More specifically, operations defined in the class CS concern:

- getters: getFathers() to get the direct fathers of the current Cs, getSituations() to get the direct situations of the current CS, etc.,

- setters: setFathers(), setChildren(),

- checkers: isFather() check if the specified CS is a direct father of the current CS, isChild() check if the specified CS is a direct children of the current CS, isType() check if the current CS is a Type CS, isRelationType() check if the current CS is a RelationType CS, isDescendant() check if the specified CS is a descendant of the current CS, isAntecedent() check if the specified CS is an antecedent of the current CS, canBeRemoved() check if the current CS can be removed from the current ontology, etc.,

- adders: addSituation() add the specified situation as a new situation for the current CS, link() add a link between the current CS (the father or source of the link) and a specified CS (the child or the target of the link),

- removers: removeLink() remove the link between the current CS (the father) and the specified CS (the child). The specified CS can be a Type (the first version of removeLink()) or a Situation (the second version of removeLink()). removeSituationAt() remove the situation at the specified range for the current CS.

- translators: toString() returns the identifier associated to the current CS. The identifier is taken from the specified lexicon. If the current CS is a situation, its description is returned. toXml() returns the XML formulation of the current CS. It is called especially by the method storeInXML() defined in Ontology API.

Note: The reader can note that operations on situations are specified in this common class CS. The reason is that a situation can be linked to any CS (i.e. a Type, an Individual, or a situation). 

 

3.    Operations defined in the class Type: these operations are specific to Type and RelationType CSs. Among them:

- constructors, finalizer and clear() (to clear the content of the current type),

- getters: getDefinition() to get the definition of the current type, getCanon() to get the canon, getDirectSubTypes() to get the direct subtypes of the current type, getDirectSuperTypes() to get the direct superTypes of the current type, getComSubTypes() to get the common subtypes of the current type and the specified type, getComSuperTypes() to get the common superTypes of the current type and the specified type, getMaxComSubType() to get the maximal common subtype of the current type and the specified type, getMinComSuperType() to get the minimal common superType of the current type and the specified type, getSubTypes() to get all  subtypes of the current type, getSuperTypes() to get all superTypes of the current type, getIndividuals() to get the individuals of the current type,

- checkers: isConceptType() to check if the current type is a concept type, hasCanon() to check if the current type has a canon, hasDefinition() to check if the current type has a definition, isSubType() to check if the specified Type is a subType of the current Type, etc.,

- setters: setDefinition(), setCanon(),

- removers: removeCanon() to remove a canon description, removeDefinition() to remove a definition description.

 

Remarks:

1. As a subclass of Type, RelationType inherits all the operations defined in Type.

2. Two types/nodes can have, in principle, more than one maximal common subType and more than one minimal common superType. Amine platform assumes however that there is only at most one maximal common superType and at most one minimal common subType. Hence, either the ontology fullfills this constraint or it should be modified to make it conform to the above constraint.

3. The reader may ask why the return-type of many methods of the classes above (Ontology, CS, Type) is Enumeration. Indeed, when the data to return is an ArrayList (like children of a node in Ontology, income relations of a concept, etc.), we return an Enumeration on the ArrayList, not the ArrayList itself. Security is the main reason for this decision: if the ArrayList itself is returned, user will be able to modify the ArrayList (change, add, remove), while (s)he should be able to read-only. Even, Iterator over the ArrayList is not safe enough since user can remove elements from the ArrayList. With Enumeration over the ArrayList, user can read-only.

 

4. Operations defined in the class Individual: these operations are specific to this class. In particular:

- constructors,

- getters: getDescription() to get the description of the current individual, getType() to get the type of the individual,

- setters: setDescription() to set the description of the current individual,

- checkers: isType() to check if the specified type corresponds to the type of the individual, isConform() to check if the current individual is conform to the specified type, i.e. if the specified type is a superType of the individual type, etc.)

- removers: removeDescription() to remove the description of the individual.

 

Creation and use of a (Lexicons)Ontology

In the current version of Amine Platform, an ontology with its associated lexicons can be created, edited and manipulated by using the LexiconsOntology GUI, or by using directly Lexicons and Ontology APIs in a Java program. We refer the reader to LexiconsOntology GUI for the use of this GUI to create, consult, edit and ask an ontology. Here we present examples that illustrate the direct use of the APIs for the creation of an ontology. These examples show also the independence of the ontology from any specific description scheme, and illustrate the "proximity" of the conceptual, the specification, and the implementation levels.

 

Examples (part I)

Several variants of the same simple example are presented in this section and the following (i.e. Examples part II). In this section, we present:

a) an ontology with no descriptions for the CSs and

b) the same ontology with the use of CG as descriptions of the CSs.

 

In section Examples part II, we present:

c) the same ontology with the use of a Text (a String) as descriptions of the CSs,

d) the same ontology with the use of Term as descriptions of the CSs, and

e) the same ontology with the use of different descriptions structures.

 

These examples show that various description schemes (Amine structures in these examples) can be used to describe CSs. In addition to Amine structures, user can define and use his own description scheme. All the above examples use a very simple ontology. For more "realistic" examples of ontologies, see Samples.

 

Note: the following examples assume a minimal knowledge of Java (Amine is implemented in Java and the direct use of Amine APIs is to be done via Java classes).

 

a) An ontology with no descriptions for CSs: a simple type hierarchy ontology

As noted above, an ontology can be created using the LexiconsOntology GUI or it can be created directly using Ontology and Lexicon APIs. The Java class BuildManOntology illustrates the second method of ontology creation. The simplified version of BuildManOntology presented in this section creates an ontology composed of only a simple type hierarchy. Basic parts of the source code are given here with comments. The example is also an opportunity to show how various methods of the Lexicon and Ontology APIs can be used in a specific context and how it is easy to use them.