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:
|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).
|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.
|Saves the current document.
|Saves a new file and saves the vocabulary and the graphs.
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.
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
|This demo shows how to edit the concept type hierarchy
|This demo creates a concept type with multiple inheritance
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
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
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.
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
|This demonstrate the use of banned concept types
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.
|This demo shows how to edit the relation types hierarchy
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).
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.
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.
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..
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.
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.
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.
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
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