Vocabulary

Overview

CoGui is able to create multilingual ontologies designed for Conceptual Graphs (CGs).A CG Ontology is composed of exact knowledge and contextual knowledge. The vocabulary is one important part of the exact knowledge and consists of two hierarchies:
1) a hierarchy of concept types (also named concept or class or object type)
2) a hierarchy of relation types (also named relation) with arity greater or equal to 1.
The above hierarchies are respectively organized in partially ordered sets (not necessarily a tree or a lattice).
The exact knowledge of the ontology, apart from the vocabulary, consists of:
* a collection of individuals and eventually associated individual graphs
* rules

Editors allow end users to navigate through the ontology and edit graphically its structure and content. The ontology is controlled and, if necessary, tools are provided to correct it.

Graphically, types are displayed as vertices. An arc connecting vertex A to vertex B means that the type A is a kind of type B (or A is a specialization of B or B is a generalization of A):

concept types relation types

In most cases the ordered set looks like this:

simple ordered set of concept types

In this case, the hierarchical structure is a tree. But the model accepts extra connections. Two examples below illustrate non arborescent hierarchies:

The edit operation is not heavily constrained by the model, in practice, the only critical error occurs when a circuit is detected. More details can be found in following chapters.

Open,create and save project

CoGui stores data in XML format file named COGXML. COGXML documents can contain a vocabulary definition or a set of conceptual graphs or both sections. The menu file and the main toolbar contain the following commands:

New Creates a new document. The initial vocabulary consists of concept type hierarchy restricted to one concept type (Top), a relation type hierarchy restricted to one relation (Link(Top,Top)), a nesting type hierarchy restricted to one nesting type (Nesting) and a graph set containing one empty fact graph (_g1).
Open... Opens existing COGXML document. If the vocabulary and the graphs are stored in separate files, the command must be used for each files. The vocabulary must be opened before graphs file.
Open recent project Opens an existing project stored in the history of recently opened documents.
Save Saves the current document.
Save As... Saves a new file and saves the vocabulary and the graphs.

How to browse through type hierarchies

When a document is opened (or created) a vocabulary panel appears on the left part of the main window. Concept types, relation types and nesting types are displayed in three separated tabbed panels. An arborescent representation containing every path between maximal type and others. Types are alphabetically sorted, relation types are also sorted by arity.

concept types
relation types
nesting types

The tree representation is useful to create vertices in conceptual graphs by dragging types into the graph editor (see Graph Edition chapter). Please remember that the type's order is not necessarily a tree. That's why the same type may be retrieved several times in the tree representation. For the same reasons tree is not automatically expandable if hierarchy contains at least one circuit. 

click right button and choose 'Edit concept types: graph editor option'
directly run command from project view

A double click inside the vocabulary tree has the same effect: open the hierarchy in right panel, select the highlighted type and scroll if necessary to make the vertex visible:

two displaying modes for concept type hierarchy

Another way to retrieve a type inside the graph representation is to use the search tool included in each graph editor. Press Ctrl-F and enter the searched string:

Unless you decide to improve speed with a big vocabulary (see below: How to work with a big vocabulary), trees and graphs are being kept in synchronization and you can navigate between both representations:

* a simple double click on a vertex in left panel select and show the (unique) corresponding vertex in the hierarchy view

* a right click on vertex displays a popup menu: the 'Show type in tree' action selects (and scrolls if necessary) the corresponding node(s) int the left panel.

select 'Show element in tree'
corresponding nodes are selected in tree

Two other options show parents or children inside the graph (the scrolling process is automatically performed).

Shows corresponding vertex in the left panel
Shows parent vertex in the graph representation and select them
Shows children vertex in the graph representation and selected them

1 Concept type edition

This demo shows how to edit the concept type hierarchy
This demo creates a concept type with multiple inheritance

1.1 Insertion


A newly created concept type hierarchy contains only one type named 'Top' . A new concept type can be inserted with 'Graph/Insert vertex/Insert concept type' in main menu. The button placed in the local toolbar has the same effect. 'Insert concept type' int the popup menu inserts the desired type at the mouse location. 

A concept type can also be created into the tree representation. 'New concept type' option in the type view popup menu creates a new concept type as a type of selected item:


A concept type can be created directly into the tree


Newly created type is kind of previously selected item

Into the graph editor, the following vertex is displayed: . Click twice on the vertex to edit type name. Concept types can be renamed directly on the concept type tree. Click once on the tree item to edit type name. Both actions have same effect and are synchronized.

rename on graph
rename on tree

1.2 Naming conventions

Homonymous types are not allowed in the same type hierarchy. The case is respected but comparisons are case unsensitive. For instance user can decide to write 'Dog' or 'dog' but cannot define both words in the concept type hierarchy. Blank spaces are allowed.

unique name control

1.3 Graph arrangement

A vertex is moved by dragging its box with the mouse. Several vertices can be selected and moved at the same time. Another way to place vertices is to run an automatic arrangement with the Sugiyama layout algorithm. 'View/Arrange horiz.' and'View/Arrange vertic.' in the main menu are also placed in the local toolbar. Please feel free to try automatic arrangements, the undo command can be used to move vertices back to their original positions.

vertical layout
horizontal layout

1.4 Concept type hierarchy control

The control command in the toolbar controls in particular the concept types hierarchy. 

Only one critical error can occur with the graph structure: the detection of a circuit. Assume that 2 types A and B on a circuit, i.e. a path exist from A to B and another exist from B to A. It means A is a kind of B and B is a kind of A.

CoGui control detects circuits: all the animals are not dogs

Another model constraint is that the concept types hierarchy must have a maximal concept type. By default CoGui names it 'Top', feel free to change its name or to choose another vertex as the maximal. A warning message occurs if the hierarchy contains more than one maximal element. The tool does not automatically add a maximal abstract type to the hierarchy but it is recommended to respect this constraint.

a single maximal type is required

Another warning can occur when the user draws redundant arcs. If A is a kind of B and B a kind of C, by transitivity CoGui 'knows' that A is a kind of C, hence an arc beetween A and C is correct but redundant. These extra arcs can obstruct the graph view but extra entries on the tree representation could be used as sort of shortcuts for often used types.That is the reason why CoGui accepts and stores redundant arcs. They can be removed one by one with the warning popup menu. Another command named 'Transitive reduction' removes all redundant arcs.

redundant arcs can be removed one by one or together with transitive reduction

1.5 Forbidden types


This demonstrate the use of banned concept types

In a graph, the concept vertices may be associated to a conjonctive types, meaning it has several types. As a result, the model provides a mechanism to prohibit some incongruous associations. For instance, suppose you have defined both "Animal" and "Plant" concept types, you might want to prohibit associations between these types as well as between subtypes of them. It is possible to express this restriction in your concept type hierarchy. To this end, you are going to introduce a banned type in the concept type View to express this incompatibility. See below an example of such restriction expressed in the concept type hierarchy triggers and here it triggers an error in a conceptual graph.



1.6 Concept type alteration

As for relations, adding concept types does not affect the existing ones. The deletion of a concept type can affect not only the type hierarchies and fact graphs, but also the signatures of relations. All references to this type must first be removed from the base.

Removing a link between two concept types does not create inconsistencies in the knowledge base but can decrease the number of answers to a query, adding a link can increase the number of answers, the banned types may change and some constraints may become unsatisfied.

All consequences of these alterations are detected by the Cogui controler and error messages help the user to correct inconsistencies.


2 Relation type edition

This demo shows how to edit the relation types hierarchy

2.1 Insertion

Use 'New relation type' in relation type view popup menu.A new relation type can also be inserted with 'Graph/Insert vertex/Insert relation type' in main menu. A button placed in local toolbar has the same effect. You can also use 'Insert relation type' on popup menu insert type at mouse location. The dialog box below appears to define the label and the signature of the new relation type.


insert a type from the tree view
 

insertion of a new relation type

2.2 Naming conventions

Homonymous types are not allowed in the same type hierarchy. The case is respected but comparisons are case unsensitive. For instance the user can decide to write 'Binary_rel' or 'binary_rel' but cannot define both words in the relation type hierarchy. Blank spaces are allowed.

homonymous relation types are not allowed

 See the previous chapter about vertices arrangement (same features are provided for each hierarchy).

2.3 Relation types signature

A signature must be associated with each relation type. A signature is an ordered list of concept types (numbered from 1 to arity) where arity denotes the arity of the relation type, i.e. its number of arguments.

The signature can be edited with the 'Edit signature' command in the popup menu. The signature dialog box allows to change the arity and to specialize involved concept types.

select a relation type and choose 'edit signature' on popup menu
signature dialog box

Press the assistant button and choose arity or directly edit arity number and press the 'Apply' button to confirm. Lines are added or removed from the table. Each concept type can be changed directly or with the assistance button.

choose arity
Apply button adds lines in signature table to describe conjunctive types in signature

A fastest way to obtain a signature is to drag from the left vocabulary panel an existing relation type and to drop it into editor. Copy and paste do the same action. A new relation type is created with the same signature.

2.4 Relation type hierarchy control

Similar to concept type hierarchy, circuits are forbidden. The only difference with concept type hierarchy is due to signatures. The constraints are:

1) relation types are grouped by arity. Each 'arity family' must have a maximal element. It means that the relation type hierarchy is decomposed w.r.t. the arity and a unique maximal element is required for each of these sub-hierarchies.

2) Let A and B be two relation types in the same sub-hierarchy (i.e. A and B have the same arity). If A is a kind of B, it means that every concept type in A signature is respectively a kind of concept type in B signature. For example if graze(herbivore,plant) is kind of eat(animal,food) their signatures respect compatibility if herbivore is a kind of animal and if plant is a kind of food.

 
CoGui verify signature's compatibility and gives concept type number when error is detected
 

Another way to quickly define or pre-define signatures is to use 'Suggest signature...' command on popup menu. Use the command after a link is established between a new relation type and an immediate greater relation type: the parent signature is automatically proposed. But this command is designed for more a complex purpose.In a complex ontology it becomes difficult to define a new relation type signature. The command 'Suggest signature...' can help to find the maximal compatible signature..

2.5 Relation type alteration


Relation type labels can be changed. With respect to the signature covariance new relations can also be added without consequences for existing knowledge.
For obvious reasons of referential integrity, the removal of a relation assumes that all occurrences have disappeared from all graphs, both in annotations and within ontology.
The consequences of the change of a signature depends on its nature: if the arity of the signature is changed, all occurrences of the relation will require user’s intervention; if only the concept types of the signature are changed, then it will be a different signature.
If a concept type is replaced by a more general type, the content of the knowledge base will not be affected, and no error will occur. However, if a term is specialized, it can have an effect on the content of the knowledge base, and can also trigger errors in the annotations. Removing a link between two relation types does not create inconsistencies in the database but can decrease the number of answers; adding a link can increase the number of answers (new rules may be applicable) and some constraints may become unsatisfied.

3 Modules

Modules are created and accessed from the project tree (Vocabulary/Modules item). The module editor is a simple sortable table. Just drag 'n' drop the required types from types tree to the module editor. 


create a new module from project tree


edit the new module:an empty table is opened


edit the module
The selection of relation types can create some problems related to the signature constraints. The user has three choices in such a situation:
(1) remove the relation from the module;
(2) add all concept type parameters of the relation signature in the module: an option is provided in contextual menu to do this automatically.
(3) add (in the module and in the general vocabulary) a new relation defined as a specialization of the first and choose, the concept types of the signature being chosen in such a way that they belong to the module.

4 Multilingual vocabulary

Cogui can be used to build multiligual ontologies, all types can be translated in several languages. 

A label and a description is attached to each type (concept types, relations types and nesting types). A current language is always selected in the toolbar, so when the user edits the type name (see previous chapter), the update only concerns the label of the type in the current language. 

User can switch the current language, vocabulary and displayed graphs are automatically translated. 

A red bar will appear across the vertices for which there is no translation into the current language.

If the user wants to translate the vocabulary itself, it will select a type and use the menu option "Label & description". A dialog box is opened to edit label and description of the selected type in several languages

The tooltip display the description and all translations of the type name

5 How to work with a big vocabulary

Future release of CoGui will provide a reduced mode edition such like conceptual graph editor. At this time the whole hierarchy is edited.

If out of memory error occurs, change java command line options. For example -Xmx128m set maximal java heap size to 128 Mo (default is 64).

If edit actions on graph take a long time, speed can be improved by stopping synchronization between both representation. Hierarchy tree will not be updated until each action. To retrieve some lost browsing facilities, a control will synchronize again on demand. Select Tools/Preferences menu option. In general/voc.editor section uncheck 'update vocabulary during edition'.

synchronization between tree and graph can be stopped