Conceptual Ontology
and
Conceptual Structures
by
Adil KABBAJ
N.B: We suggest to consider first the Introduction. Then Consider News for the new version Amine 9. The new here is the "Import ontologies" (see below).
Conceptual Ontology and Conceptual Structures: A structural view
Lexicons / Ontology relationship
APIs for Conceptual Ontology and Conceptual Structures
Creation and use of an Ontology
The mapping between OWL and Amine Ontology
Import ontologies (using several ontologies in
one application) 
Amine Genericity concerning Conceptual Structures Description
From “weak” to “strong” multi-lingua ontology
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 (since Amie 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.
3. 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).
4. 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.
5. 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.
6. 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).
7.
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.
· 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:
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 f
ollowing 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, w
e 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.
Operations defined directly in the class Ontology:
- constructors : different ways to construct an ontology,
- finalize for the
destruction of an ontology to recover space,
- getters: getLexicons() to get the lexicons associated to the ontology, getMainLanguage() that is associated to the mainLexicon, getLanguages() to get the languages of the lexicons that are associated to the ontology, getLexicon() to get the lexicon for the given language, etc.,
- checkers: isKnownLanguage() check if the specified language is a language already known to the current ontology, isMainLexicon() check if the current lexicon corresponds to the main lexicon of the current ontology, etc.,
- setters: setRoot(), setRelationRoot(), setMainLexicon(), etc.,
- adders: addLexicon() to add the specified lexicon as new lexicon for the current ontology,
- removers: removeCS() to remove a specified CS from the ontology, removeLexicon() to remove a specified lexicon from the list of lexicons associated to the current ontology,
- input-output operations: Amine provides two ways for the storage of an Ontology: a) an internal representation which is produced by the serialization process of Java, b) an XML representation. load()/open() methods specified in the Ontology API concern the internal representation: they are based on the Java deserialization process. Similar methods (loadFromXML()/openFromXML()), that concern the XML representation, are provided as static methods of util.AmineObjects class. loadFromXML() creates an internal representation of the ontology (as Java objects) from its XML representation. store()/save() methods enables the storage of the ontology in an internal representation, based on the Java serialization process. storeInXML()/saveInXML() methods enables the storage of the ontology in an XML representation.
Note: loadFromXML()/openFromXML() are not defined in Ontology because they make use of the util package and our aim is to let the kernel package indepedent from any other Amine package. So, the adopted solution is to define the two methods in AmineObjects which is a "service" class of util package. storeInXML()/saveInXML() are defined in Ontology because they don't make use (directly) of util package.
Operations defined in the class CS
(Conceptual Structure) : th
ese
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).
Operations defined in the class Type: th
ese 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.
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.
The mapping between OWL and Amine Ontology
In their DESA, A. Tamouh and A. Mniai [Tamouh and Mniai 2009] have developed a mapping between OWL and Amine Ontology (in the two directions) for the case of taxonomic ontology. User can now create/edit/use a taxonomic ontology with Amine and then store/save it in OWL. An ontology editor that read OWL (like Protégé) can read the ontology.
For instance, Figure 7 shows an Amine ontology that is saved in OWL.
Figure 7: Amine ontology saved in OWL
This ontology can be opened by an OWL editor like PROTEGE (Figure 8):
(a): Amine ontology opened by PROTEGE
(b) Amine ontology edited by PROTEGE
Figure 8: Amine ontology in PROTEGE
The inverse is also true: a user can create/edit/use a taxonomic ontology with Protégé (or any other ontology editor that reads OWL) and then save it in OWL. The ontology can be opened by Amine.
See [Tamouh and Mniai 2009] for the detail of the mapping. An english paper that summarizes their work is "in progress".
Import ontologies (using several ontologies in one application)
It is now possible to use several ontologies in one application; to import types from other ontologies. With this extension, a CG can contain concepts with types from different ontologies. For instance, Figure 9 illustrates that the ontology "ManOntology2.xml" imports from two ontologies (CatMouseOnt and VehicleOnt) as shown in the window "Import ontologies" which presents the logical name of the imported ontology and the associated absolute path. Figure 9 provides also a situation for the type Build that contains two "imported types", one imported from the ontology "CatMouseOnt": "CatMouseOnt.DisneyMouse", and the other is imported from the ontology "VehicleOnt": "VehicleOnt.PetrolEngine".
Figure 9: Import ontologies
The new menu "Action" has been added to the bar menu of "Ontology/KB GUI", it provides the menuItem "Import ontologies" that has the effect to display the "Import ontologies" window. With this editable window, the user can consult the list of (already) imported ontologies, or she/he can add new ones. To add a new one, user has to specify the logical name of the ontology to import and its absolute path. Once the new line is added, please click on the next blank line, in the Import ontologies window, to make effective the new inserted line(s). Then click on "OK" button.
To use an imported type in a CG, use the following format: "ontologyLogicalName.TypeIdentifier", like "VehicleOnt.PetrolEngine".
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.
1. Import the
required packages from Amine Platform for the creation of the ontology :
public class BuildManOntology {
public BuildManOntology() {
Amine Platform has its own Identifier class, used to create identifiers in various languages that are associated to types, relation types, and individuals. Identifier class is used also to create an identifier for any language.
try {
2. Creation of a new ontology :
new Ontology(rootIdentifier, relationRootIdentifier,
mainLanguageIdentifier)
The Ontology constructor creates a new ontology object with a new lexicon for the English language. This later is considered as the main lexicon for this new ontology. The ontology constructor creates also a Type CS for the rootIdentifier and a RelationType CS for the relationRootIdentifier. Then, it adds two entries in the english's lexicon for rootIdentifier and relationRootIdentifier respectivelly. Last, the ontology constructor links the RelationType CS (associated to relationRootIdentifier) as a direct subType of the root Type CS (associated to rootIdentifier). Note that the created Type CS for rootIdentifier and RelationType CS for relationRootIdentifier are "empty" CSs; they have no definition and no canon.
3. Get the
english's lexicon in order to add in it new entries
4. Create new identifiers
5. Link the identifiers Object, Human, Attribute, and Action as subTypes of the rootType.
More precisely, the method linkSubTypesToType() creates first a Type CS for each identifier (if it has not already been created), adds an entry in the englishLexicon for each new identifier (an entry concerns an identifier and its associated CS), and then calls the method link(). This later operates on a Type CS, not an identifier, and it is defined in the class Type (see above). link() links a Type CS to a subType.
Note that the above method, linkSubTypesToType(),
is a method of the class Lexicon (not ontology); it operates on identifiers
(not CSs) and corresponds to a "lexical" version of link() method
that is defined in the ontology package and that operates on CSs. Logically
speaking, these link methods should be defined only in the ontology package
since they concern the creation (and consultation) of links between CSs, the
basic ontology operations. However and for practical purposes (human users
manipulate identifiers and not CSs directly), we offer the two versions of
these methods: a) an 'identifier free' version defined in the ontology package
where only CSs are involved, b) an 'identifier based' version defined in 
the class
Lexicon.
4. Do the same thing for identifiers of some relations
5. Add
subtypes for type Object, Human, Action and Attribute respectively
Identifier Car = new Identifier("Car");
Identifier Bus = new Identifier("Bus");
objs = new Object[] {Water, Car, Bus};
englishLexicon.linkSubTypesToType(objs, Object);
Identifier Man = new Identifier("Man");
Identifier Woman = new Identifier("Woman");
objs = new Object[] {Man, Woman};
englishLexicon.linkSubTypesToType(objs, Human);
Identifier Drink = new Identifier("Drink");
Identifier Drive = new Identifier("Drive");
objs = new Object[] {Drink, Drive};
englishLexicon.linkSubTypesToType(objs, Action);
6. Add a new entry for Sex and link this new type to its superType Attribute
Identifier Sex = new Identifier("Sex");
englishLexicon.linkTypeToSuperType(Sex, Attribute);
7. Add
individuals for the type Man
Identifier imad = new Identifier("imad");
Identifier michael = new Identifier("michael");
Identifier karim = new Identifier("karim");
objs = new Object[] {imad, michael, karim};
More precisely, the method linkIndividualsToType() creates first an Individual CS for each identifier (if it was not already created), adds an entry in the englishLexicon for each new identifier, and then calls the method link() that links the Individual CS to the Type CS for Man.
We will skip other steps that illustrate the use of Lexicons and that are specified in Lexicons.
Note: Text in italic and in green color represents comments on the associated Java code.
15. Store
(save) the ontology in the file "C:/ManOntology.ont"
// Save the Lexicons/Ontology in the specified file.
The ontology
can be saved also in XML format:
ontology.storeInXML("C:/ManOntology.xml");
}
The ontology created by this class (i.e. BuildManOntology) and saved in the file “ManOntology.ont” (or "ManOntology.xml") can be loaded (opened) and used in various ways, by other Java programs (that use Amine Platform) or by the LexiconsOntology GUI:
// Load a Lexicons/Ontology from the specified file.
Of cource,
the ontology can be loaded also from an XML file :
Ontology ontology = AmineObjects.loadFromXML("C:/ManOntology.xml");
// ... code that use the ontoloy
The execution of BuildManOntology
will create the ontology and store it in files ManOntology.ont and ManOntology.xml,
if both formats are wanted. AminePlaformGUI
provides a menu Ontology that enables the execution of BuildManOntology
and other similar cases (this is a solution for a reader that is not familiar
with Java). The class BuildManOntology can be (compiled and) executed directly
using Java commands. For instance, under
Windows, the class BuildManOntology can be
compiled and executed as follows:
> javac –classpath “.;c:\aminePlatorm.jar”
aminePlatform.samples.buildOntology.BuildManOntology.java
> java –classpath “.;c:\aminePlatorm.jar”
aminePlatform.samples.buildOntology.BuildManOntology
A fragment of the ontology, especially the hierarchy view, is displayed as follows (a snapshot of the LexiconsOntology GUI):
b) An ontology with CG as description scheme of CS description
We use the same example but we provide, in addition, descriptions to some CSs. The descriptions are in CG. In this case, two additional import declarations are required (the first for CG structures and the second for the parsing and textual formulation of CG).
13. Assign a definition for the concept
type Man: this is done in two steps; get the Type CS associated to the
identifier Man (from the englishLexicon), and then
set the definition to the located Type CS.
// get the
Type CS of Man. Note that identifier Man was declared
// before.
Call the static method CG.parseLF(String,
Lexicon) to parse a CG expressed in English with a linear form. The result is
an internal and abstract representation of a CG.
// Specify in CG the definition body of type Man
// Set the CG cgDefMan as the definition body of Type Man
Note how parseLF() allows an easy, direct, and quick formulation of CG: the user provides the CG as String and the method parseLF() will parse the string as a Linear Form CG notation, using the specified lexicon (englishLexicon).
14. Associate a canon for the concept type Drink
// get the
Type CS associated to the identifier Drink.
Note that
// identifier
Drink was declared before.
Type drinkType = englishLexicon.getTypeCS(Drink);
// The description of the canon in CG
CG cgCanon = CG.parseLF("[Animate]<-agnt-[Drink]-obj->[Liquid]",
enlishLexicon);
15. Associate
two situations for the concept Type Man
// add a
situation with its description for the ManType
// We can of course put directly the method parseLF() as argument
// for addSituation()
16. Assign a description for the individual imad
// Get the Individual CS associated to the identifier imad. Note that
// imad was declared before.
Individual indImad = englishLexicon.getIndividualCS(imad);
// The description of the individual imad in CG
CG cgDescr = CG.parseLF("[Man:imad]-attr->[Intelligent]",
enlishLexicon);
17. Associate a situation for the individual imad
CG
cgSit = CG.parseLF("[Man:imad]<-agnt-[Work]-manr->[Hard]",
enlishLexicon);
18. Assign a definition for the relation type workOf
// get the
RelationType CS associated to the identifier workOf. Note
// that
identifier workOf was declared before.
RelationType workOfType = englishLexicon.getRelationTypeCS(workOf);
// The description of the definition body in CG
19. Assign a canon for the relation type workOf
// The canon's description for the relation workOf in CGIF.
// This example illustrates that a CG can be formulated in LF or in CGIF
20. Associate a situation for the relation type workOf
// This example illustrates the possibility of a relation type to have
// situation also
16. Get the definition of the Type Man and express it in English and in CGIF:
if (cg != null) {
System.out.println("Definition of " + Man + " is :\n" + cgTxt);
}
Result of the code above:
Definition of Man is : (attr [Human :super] [Sex = male])
Remarks:
1. The method getDefinition() returns an Object, the user has to cast it to apply specific operations on the result. In the example above, we know that the description is a CG, so we cast the object to CG and we call the method toCGIF() to get a CGIF formulation of the CG. It is, however, not mandatory to know the specific description scheme used. Amine user can cast the result to AmineObject which is a Java interface implemented by all Amine structures (AmineSet, AmineList, Term, Concept, Relation, CG) and it can be implemented also by any Java class. AmineObject interface specifies many operations; the user can cast the result to AmineObject and then call these operations without caring about the specific type of the used structure. Examples below illustrate these possibilities that exploit the genericity of Amine.
2. The method toCGIF() and the alternative method toLF() return the CGIF formulation and alternatively the Linear Form formulation of a CG. The two methods are equivalent to the Java method toString(). Again, the example above illustrates how powerfull and usefull methods, like toLF() and toCGIF(), can make CG manipulations an easy and natural task.
The following code :
TextualDisplayOntology txtDsplyOntFrm = new
TextualDisplayOntology(ontology);
txtDsplyOntFrm.displayOntology();
txtDsplyOntFrm.addWindowListener(new WindowAdapter() {
public void windowClosing(WindowEvent e) {
System.exit(-1);
}
});
will involve the display of the following frame:
We hope that this small example will give the reader an idea of how much it is easy to specify CG, in LF or in CGIF, and how it is easy to create, define and associate Conceptual Structures to types.
Amine Genericity concerning Conceptual Structures Description
Amine platform is not committed to a particular description scheme: CS description can be a CG, any other Amine structure, any Java class that implements AmineObject or ToString interface, or even any Java class. We used above CG. In the next examples, we use String (text) and Term. Moreover, the last example illustrates the possibility to use various description schemes in the same ontology.
c) An ontology with Text (String) as descriptions of the CSs
We consider the same example (BuildManOntology), but instead of using CG, we use String:
Associate a definition, formulated as a text, to the type Man:
Associate
two situations to the Type Man, using String for their description:
Get the definition of the Type Man. In this case, it will be a text (String)
String text = (String) ManType.getDefinition();
if (text != null) {
System.out.println("Definition of " + Man + " :\n" + text);
}
Result of the above code:
Definition of Man : is a Person with a sexe male
The following textual display frame shows the CSs associated to the type Man:
d) An ontology with Term as descriptions of the CSs
In this section, instead of CG or String, we use Terms to represent the content of CSs.
Associate a definition, formulated as a term, to the type Man:
// get the
Type CS of Man
Type ManType = englishLexicon.getTypeCS(Man);
// Specify the definition of Man as a Term
Term termDefMan = Term.parse("Person(sexe(male))", englishLexicon);
ManType.setDefinition(termDefMan);
Associate
two situations to the Type Man
// add
situations with their descriptions for the ManType
ManType.addSituation(Term.parse("Drink(Man, Water)", englishLexicon));
ManType.addSituation(Term.parse("Drive(Man, Car)", englishLexicon));
Get the definition of the Type Man. In this case, it will be a Term specified in English
Term term = (Term) ManType.getDefinition();
if (term != null) {
System.out.println("Definition of " + Man + " is :\n" +
term.toString(englishLexicon));
}
Note how the use of methods like parse() and toString() make the use of structures like AmineSet, AmineList, Term, and CG very easy and natural.
Result of the above code:
Definition of Man is : Person(sexe(male))
The following textual display frame shows the CSs associated to the type Man:
The examples above illustrate the fact that various description schemes (or structures) can be used to describe CSs. We noted earlier that the user does not need to know the type of the used description scheme. For instance, if the user wants only to print the definition of type Man, he can proceed as follow:
ToString descr = (ToString) ManType.getDefinition();
if (descr != null) {
System.out.println("Definition of " + Man + " is :\n" +
descr.toString(englishLexicon));
}
Note that the object returned by getDefinition() is not casted to a specific structure (like Term, AmineList, CG, etc.) but to the ToString interface which is implemented by all these structures. ToString interface specifies the method toString(Lexicon).
Genericity in action
If the user is interested in applying operations on the returned object, like the operations specified in the Matching interface, the casting should be done to Matching. Here is an example:
Matching descrDef = (Matching) ManType.getDefinition();
Object descrCanon = ManType.getCanon();
if (descrDef != null) {
ToString result = (ToString) descrDef.maximalJoin(descrCanon);
System.out.println("Result of the maximal join is :\n " +
result.toString(englishLexicon));
}
The user writes his code in a generic level; without caring about the specific description to be used: it can be any Java class that implements Matching, ToString and AmineObject interfaces. These interfaces are defined In Amine structures and operations.
Different description schemes in the same Ontology
The following example illustrates the possibility to use different description schemes in the same ontology.
In all the above examples, we used the simple ontology: 'ManOntology'. See Samples for more 'realistic' ontologies, developed in different domains.
The Graphical User Interface for Ontology is specified in this document: Ontology GUI.
The Java class OntologyTest illustrates the use of some methods defined in Ontology API (and their mirrors methods in Lexicon API). This section shows excerpts from the Java code of this class.
a) Load the ontology 'ManOntology.ont' and get its main lexicon:
Ontology
ontology = Ontology.load(AmineFrame.ontologyDirPath
+ "ManOntology.ont");
Lexicon englishLexicon = ontology.getMainLexicon();
b) Get from the main lexicon the identifiers with names "Action", "Drive", etc.
Identifier
Action = englishLexicon.getIdentifier("Action");
Identifier Drive = englishLexicon.getIdentifier("Drive");
Identifier Man = englishLexicon.getIdentifier("Man");
Identifier Person = englishLexicon.getIdentifier("Person");
c) Get (all) subTypes of the type Action
The method getSubTypes() returns en enumeration of all subTypes identifiers of the type Action. Again, this "lexical" version of getSubTypes() operates on identifiers and it calls a similar method, that operates on the CSs associated to the specified identifiers. More specifically, the method getSubTypes() searchs, from englishLexicon, the Type CS associated to the identifier Action, then calls a method that returns the subTypes (a collection of Type CSs) of the current Type, and then it makes access to englishLexicon to get an identifier for each returned Type CS.
Identifier typeIdent;
if (e != null) // check that the enumeration is not null
// for each element of the enumeration,
while (e.hasMoreElements()) {
// get the current element,
typeIdent = (Identifier) e.nextElement();
System.out.println(typeIdent); // and print the element
}
else System.out.println("none \n");
Result of the code above:
Subtypes of Action :
Drink
Drive
Eat
Walk
Go
Love
Break
Build
Rent
Begin
Press
Look
Work
Think
Believe
Read
d) Get the minimal common superType of types Drive and Man
System.out.println("minimal common superType of " + Drive +
" and " + Man + " is :\n");
System.out.println(minComSuperType + "\n");
Result of the code above:
Minimal common superType of Drive and Man is : Universal
From “weak” to “strong” multi-lingua ontology
In Amine, we present ontology as “conceptual”, “language free”, and multi-lingua. The ontology is conceptual because nodes that compose the ontology are not identifiers (defined in a specific language) but Conceptual Structures (CSs). It is “language free” because identifiers are not used to describe the CSs that compose the ontology. And it is multi-lingua because several languages/lexicons can be associated to an ontology.
This is true in a “weak sense” only: “weak” because currently, Amine ontology is composed of three types of nodes: Type, Individual, and Situation (with context and metaphor as specialization of Situation). Type and Individual are “notions” that are “language-dependent”, not “language free”. For instance, in Arabic, the word “Qaswara” corresponds to the category of “running lions”. A French or English speaker has no such a category and no synonymous word that designates this category. What is a definition (a category) for an Arabic speaker can be viewed as a situation for a French or English speaker.
This is a big and difficult problem in the Ontology field and cognitive psychology; namely the “deep” relation between human conceptualization/categorization (category formation) and human language. The question can be reformulated as follows: does language influences the formation of human category ? Assuming a “yes” answer, it becomes clear that the repartition of ontology nodes into three categories (Type, Individual, and Situation) is not totally compatible and coherent with our assumption of providing “conceptual” and “language free” ontology. The most “primitive” node category is Situation (generic and/or specific). In one language a Situation can be viewed as a Definition of a Type or a Description of an Individual. Type and Individual have to “move” from the Ontology to the Lexicons. For instance, in the Arabic Lexicon, we will have an entry for “Qaswara” with its association to the description “Running Lion” and the information that this description corresponds to the definition of a Type/Category. We should specify also in this entry that “Qaswara” is a specialization of Lion.
The “strong” multi-lingua ontology is not better than the “weak” multi-lingua ontology. In applications that are mono-lingua or that have one main language (and other secondary languages), “weak” multi-lingua ontology is more appropriate. In other applications (like translation from/to Arabic <-> English for instance), “strong” multi-lingua ontology is more appropriate. This "hot" topic will be investigated later.
Next From this
document, the
reader may consider Lexicons which is a
complement of Ontology, the two constitute the kernel of Amine Platform. Then
he/she can consider the LexiconsOntology GUI, Samples, the APIs specification, ontology basic processes,
and/or the higher levels/layers of Amine Platform (Amine structures and operations,
Engines level, etc.).
References
J. G. Carbonell, Metaphor: An Inescapable Phenomenon in Natural-Language Comprehension, in W; G.
Lehnert and M. H. Ringle (Eds.), Strategies for Natural Language Processing, Erlbaum, 1982.
K. Chibout and A. Vilnat, Computational Processing of Verbal Polysemy with Conceptual Structures, in M-L
Mugnier and M. Chien (Eds.), Conceptual Structures: Theory, Tools and Applications, 6th ICCS,
ICCS'98, Springer, 1998.
B. Indurkhya, Approximate Semantic Transference: A Computational Theory of Metaphors and Analogies,
in Cognitive Science 11, 445-480, 1987.
G. Lakoff and M. Johnson, The Metaphorical Structure of the Human Conceptual System, Cognitive
Science 4, 195-208, 1980.
G. Lakoff and M. Johnson, Metaphors we live by, University of Chicago Press, 1980.
A. Ortony (Ed.), Metaphor and Thought, Cambridge University Press, 1979.
John F. Sowa, Knowledge Representation: Logical, Philosophical, and Computational Foundations, Brooks
Cole Publishing, 2000.
Farrar Scott and John Bateman, General Ontology Baseline, 2004.
Kabbaj A., K. Bouzoubaa, K. ElHachimi and N. Ourdani, Ontology in Amine Platform: Structures and Processes,
in the 14th Proc. Int. Conf. Conceptual Structures, ICCS 2006, Aalborg, Denmark, 2006
Tamouh Abdelhamid and Mniai Ayoub, Conception et Réalisation d'une Interface entre une Ontologie Amine et une
Ontologie OWL, mémoire de DESA, Univ. Mohammed V - Rabat, 2009