Cogui User Guide (version 1.0)

Introduction
1 User Interface: basics
2 Ontology edition
3 Rule edition
4 Fact graph edition
5 Querying

6 Tools
Appendix

---

Introduction

Developed by RCR team at LIRMM (http://www.lirmm.fr/RCR/) CoGui is a visual tool for building (conceptual graph) knowledge bases.

CoGui tool provides the following functionalities::

    * Concept type hierarchy editor
    * Relation type hierarchy editor
    * Nesting type hierarchy editor for nested graphs
    * Rule editor
    * Pattern and Prototypic graph definitions allowing to assist the annotation process
    * Individual Manager with optional attached graphs
    * Modules (subsets of vocabulary)
    * Multilingual capabilities
    * etc

 
Requirements
Being written in Java, this software can be used on any platform that has installed a Java Runtime Environment 1.5 (or higher). Please note that, currently, the query wizard requires the Windows operating system in distribution.
Starting from 0.6.5 each new version CoGui will be reported and described at: http://www.lirmm.fr/cogui/changelog.html

Installation
The software can be run directly at this address: http://www.lirmm.fr/cogui/cogui61.jnlp

1 User Interface Basics

1.1 Main commands

CoGui provides a classical frame GUI with a main menu and a toolbar.
1.1.1 Main menu

	The File menu allows to open and save projects in COGXML format.
	The Edit menu provides Undo/Redo mechanisms for graphs / rules editors. Please note that each editor has its own history of commands, and the undo and redo will only apply to the selected editor. The selection of objects, as well as the copy and paste commands also concern editing graphs and rules.
	The View menu provides actions for both view management and visual effects inside the editors.
	Commands inside the Graph menu only concern building and modifying the graph-based editors. All these commands can be activated directly inside editors with widgets, contextual popup menus and keyboard shortcuts (see chapter 1.3).
	Tools menu allows to export graph images, last updates that have been validated, as well as access preferences.
	This allows users access to documentation and informations about LIRMM-RCR team.

1.1.2 Main toolbar

1.2 Views
The CoGui workbench is divided into a number of views. A view has the functionality of a window. Depending on the type of the view it can be closed (sometimes allowed), minimized (sometimes allowed), maximized (always allowed). Views are also dockable/undockable and the windows layout is user customizable. Unlike editors, each type of view has only one instance with a particular behaviour. In the following sections we will first give general information about view management, and then a description of particular behaviour for each kind of view.
1.2.1 Default view layout
figures below present the views in the default application layout
1.2.2 Docking windows framework

view title bar buttons

Users can customize the layout of the application according to their preferences. Users can minimize, maximize, close, dock, undock and move around the windows to create a personalized windows layout. The title bar of each view is provided with buttons on the right corner. Depending on the type of view some buttons can be hidden.

A double click on the view title bar directly maximizes the view. If it is already maximized, it will retrieve its original size.

The default windows layout keeps every view inside a main window (which contains the main menu and the tool bar). However, the user can place one or more views in a floating window somewhere on the screen, independently of main window. The user can also drag a view outside the main window, and in this case a floating window containing the view will be automatically created.

This animation shows how to place views in a floating window.

It is also possible to drag and drop views inside the main window in order to conveniently arrange views.

This animation shows how to arrange views inside the main window.

Once the users are satisfied with the layout they can easily save their settings which will be restored the next time the application is started. In the main menu the option "View/Save current layout" saves the new layout, size and position of each view to automatically restore it later. It is always possible to retrieve default windows layouts presented in paragraph 1.2.1 with the option "View/Restore default layout".

Note that views are not closeable in the main window but can be closed in a floating window. If a view is closed, it is possible to retrieve it with the option "View/Show view" in the main menu.

1.2.3 Tabbed Panels
Default view layout provides three tabbed panels.
1) Left panel contains the project,the types and the individuals views
2) Bottom panel contains the error, the result and the property views
3) Center panel contains the task view and the editors

contextual menu on tabs

Tabs can be placed on either side of the center panel. The titled tabs can be rotated 90°, 180° and 270° thus making it possible to have vertical texts and icons. You can even reorder tabs using the mouse. All these features are provided by the contextual menu (right click on tab). These preferences can be saved with the same mechanism as windows layout: options "View/Save current layout" and "View/Restore default layout" in main menu.

1.2.4 Views descriptions
Each view has a unique instance and a particular behaviour in the application, in this chapter we will describe each type of view.
1.2.4.1 Project View
The project view gives access to the different objects of the project in a project tree.
Actions on the project tree
Each element of the tree is associated with a context menu accessible by  right click. Please find below a table listing all the possible actions from these menus.

Item	Action	Description
Concept types	Edit concept types: tree view	Open the concept types tree panel (concept type view)
	Edit concept types: graph editor	Open an editor containing the graphical representation of  the concept type hierarchy
Relation types	Edit relation types: tree view	Open the relation types tree panel  (relation type view)
	Edit relation types: graph editor	Open an editor containing the graphical representation of the relation type hierarchy
Nesting types	Edit nesting types: tree view	Open the nesting types tree panel (nesting type view)
	Edit nesting types: graph editor	Open an editor containing the graphical representation of the nesting type hierarchy
Modules	New module	Create a new empty module
Module item	Edit module	Open the editor corresponding to the selected module
	New module	Create a new empty module
	Rename	Rename the selected module
	Delete module	Delete the selected module
	Properties	Open a dialog to access the properties of the selected module
Patterns	New set of patterns	Create a new folder for pattern graphs
Pattern set item	New pattern	Create a new pattern graph inside the currrent selected folder
	New set of patterns	Create a sibling set (folder) of patterns
	Rename	Rename the folder
	Delete	Delete the current selected folder and all pattern graphs contained in it
Pattern graph item	Edit	Open an editor containing the graphical representation of the corresponding pattern graph
	Edit whole graph	Open an editor containing the graphical representation of the corresponding pattern graph. Force all vertices to be displayed and forbid the edition of the reduced mode (the reduced mode allows a partial view of larger graphs)
	New pattern	Create a sibling new pattern graph
	New set of patterns	Create a new set (folder) of patterns. Please note that there is only one level in the folder structure. This means that the new folder is a child of the 'Patterns' item and not a sibling of the currently selected pattern graph.
	Rename	Rename pattern graph
	Delete pattern	Delete pattern graph
	Properties	Open a dialog box to access the properties of the selected pattern graph
Prototypics	New set of prototypic graphs	Create a new folder for prototypic graphs
Prototypic set item	New prototypic for concept	Create a new prototypic graph for the concept inside the currrent selected folder
	New prototypic for relation	Create a new prototypic graph for the relation inside the currrent selected folder
	New set of prototypics	Create a sibling set (folder) of prototypic graphs
	Rename	Rename the folder
	Delete	Delete the current selected folder and all prototypic graphs contained in it
Prototypic graph item	Edit	Open an editor containing the graphical representation of the corresponding prototypic graph
	Edit whole graph	Open an editor containing the graphical representation of the corresponding prototypic graph. Force all vertices to be displayed and forbid reduced edition usage (see above for a description of the reduced usage)
	New prototypic for concept	Create a sibling new prototypic graph for concepts
	New prototypic for relation	Create a sibling new prototypic graph for relations
	New set of prototypics	Create a new set (folder) of prototypic graph. Please note that there is only one level of folder. This means that the new folder will be a child of 'Prototypics' item and not a sibling of the currently selected prototypic graph.
	Rename	Rename prototypic graph
	Delete pattern	Delete prototypic graph
	Properties	Open a dialog to access the properties of selected prototypic graph
Rules	New set of rules	Create a new set (folder) of rules
Rule set item	New rule	Create a new rule inside inside the currently selected rule set
	New set of rules	Create a new sibling set (folder) of rules
	Rename	Rename the set of rules
	Delete	Delete current rules set and all the rules contained in it
Rule item	Edit rule	Open an editor containing the graphical representation
	New rule	Create a new sibling rule
	New set of rules	Create a new set (folder) of rules. Note that there is only one level of folder. So the new folder is a child of 'Rules' item and not a sibling of the currently selected rule.
	Rename	Rename the currently selected rule
	Delete rule	Delete the currently selected rule
	Properties	Open a dialog box to access the properties of selected rule
Facts	New set of facts	Create a new set (folder) of graph facts
Fact set item	New fact	Create a new fact inside the currently selected set
	New set of facts	Create a new set (folder) of facts. Note that there is only one level of folder. So the new folder is a child of 'Facts' item and not a sibling of the currently selected set of fact.
	Rename	Rename the set (folder) of facts
	Delete	Delete the currently selected set of facts and all facts contained in it
Fact graph item	Edit	Open an editor containing the graphical representation of the corresponding conceptual graph
	Edit whole graph	Open an editor containing the graphical representation of the corresponding conceptual graph. Force all vertices to be displayed and forbid reduced edition usage
	New fact	Create a sibling new fact graph
	New set of facts	Create a new set (folder) of fact graphs. Note that there is only one level of folder. So the new folder is a child of 'Facts' item and not a sibling of the currently selected graph.
	Rename	Rename fact graph
	Delete fact	Delete fact graph
	Properties	Open a dialog to access the properties of selected fact graph

A double-click on the selected element triggers the following action by default: depending on the type of the element it either displays the view of the corresponding hierarchy or it opens the editor of the selected element.

Search for elements in the project tree
The tree project has a search tool. It is thus possible to find anything using its label as a search string. To do this, please make sure the project view is selected and then type the first letters on the keyboard: the first element of the tree beginning with those letters will be automatically selected. If the item is hidden, some elements of the tree will be expanded so that it becomes visible. In addition, if several elements correspond to the query, just use the arrow keys to scroll.
1.2.4.4 Error view
The Error view displays a list of messages. These messages are generated by the control of the project. This control is triggered either (1) manually by the "control" button or (2)automatically, at the opening of the project or (3)before carrying out certain tasks (querying for example).
1.2.4.6 Task view
Unlike other views, the task view is not dockable, it cannot be moved to a floating window or placed elsewhere. It is always placed in a central position and all opened editors are associated with this view in a tabbed panel. Its contents depends on the state of the application, actions and wizards are placed contextually in the task view.

1.2.4.7 Individual view
The Individual view lists all the individuals in a sortable table.Click on the header column to sort. Individuals could be dragged from the list to the editors.
1.3 Editors
Contrary to the views, editors are closeable, they can not be moved, they are always placed in the central panel. Editors provide a graphical way of modifying the objects of the model. With the exception of the module editor (a table), they use the graph representation.

1.3.1 Graph-based edition
Most objects in the model are graphs and are edited in a graph-based editor. Of course, each edition has its own features, but most of the editing functions are common, and in this chapter we will describe them.

1.3.1.1 Vertex insertion
Each kind of graph editor has its own vertices factory:
* Concept type hierarchy allows insertion of concept types and banned vertices
* Relation type hierarchy allows insertion of relation types
* Nesting type hierarchy allows insertion of nesting types
* Other editors (fact graphs, rules, pattern graphs, prototypic graphs, individual graphs) allow insertion of concept and relation vertices

Vertices can be added to the graph by using either the menu "Graph/Insert vertex" option or local toolbar buttons. But the easiest way to place vertices at mouse position is to right-click and choose insert menu options in the contextual menu. It is also possible to drag a type (or several types) from type view trees to the editor.

1.3.1.2 Editing graphs
Selection
Just click on a vertex to select it. Selected vertices can easily be recognized by the handles decorating them. Hold down the left mouse button to select an area: all objects (vertices and edges) entirely contained in this area will be selected. It is useful to do multiple selection to move a large part of the graph with only one operation. Another reason to select several vertices is that they remain fixed during the Spring Layout arrangement. In the case of multiple selection the property view remains empty.

This animation shows how to select and move several objects

Copy, Paste
Selected vertices can be copied, cut and pasted in a graph editor or from an editor to another. Edition commands are accessible from main menu, toolbar, contextual menu and via keyboard shortcuts.


Drag'n'drop
Vertices can be dragged and dropped inside the editor. Types can also be dragged from type tree to graph based editors. If the edited object is a conceptual graph or a rule, the copied object is created with the dragged type (i.e. dragging a concept type creates a concept of this type etc.)

Automatic arrangements
Three layouts are preavailable. The algorithms provided to arrange type hierarchies cannot support circuits. The Spring Layouter use a force-based layout and can be used everywhere.

	Arrange hierarchy horizontally
	Arrange hierarchy vertically
	Start Spring Layouter
	Stop Spring Layouter

1.3.1.3 Inline edition
Double click on a vertex edits its content (more precisely parameters that are most often used). You can also click on the upper left corner. The popup dialog is more (concept) or less (concept type) sophisticated, it depends on the nature of the vertex.This is the easiest way to edit vertices.

edition of a concept type

edition of a relation type

edition of a concept

edition of a relation

The nature of edges depends on the type of edited graph. However, this time, the nature of vertices is enough to guess the nature of the edges that will connect them, ensuring no ambiguity.
The different types of edges are:

edge between a concept and a relation (numbered)
coreference link between concepts representing the same object
oriented edge to express "kind of" relation between types.
correspondance link between a concept placed in the hypothesis of a rule and a concept placed in the conclusion of this rule.

To create a new edge, just place the mouse pointer on port placed at the center of the source vertex: the shape of the mouse pointer is automatically modified and replaced by a hand . Then press on the left button of the mouse and release it when you have reached the target vertex. Note that the order is only important for the "kind of" link between types, for the other edges, it makes no difference. It is always possible to change the source or target vertex after creation by using one of the two handle of a selected edge.



1.3.1.5 Lexicographical search on graph
The graph editor has its own lexicographical search tool. Press Ctrl-F to popup a search toolbar at the bottom of the editor.


1.3.1.6 Keyboard shortcuts

Ctrl-C or Ctrl-Ins	Copy selected objects
Ctrl-V or Shift-Ins	Paste
Ctrl-X	Cut
Ctrl-F	Popup the search toolbar
Del	Delete selected objects (when a vertex is deleted all edges connected to it are also deleted)
F5	Refresh
F8	Control

1.3.2 Module editor

2 Ontology Edition

2.1 Overview

CoGui  is able to create multilingual ontologies designed for Conceptual Graphs (CGs).A CG Ontology is composed by exact knowledge and contextual knowledge. The vocabulary is one important part of the exact knowledge and consists of three 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.
3) a hierarchy if nesting types (to type subgraphs nested in concepts)
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
Contextual knowledge aims at assisting the annotation task. Unlike the exact knowledge, contextual knowledge is not used for doing reasonings, but only used to suggest to the user some usual context of a concept type, a relation type or a nesting type:
* prototypical graphs
* pattern graphs

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	nesting types

In most cases the ordered set looks like this:

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.

2.2 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.

2.3 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 same reasons an empty panel is displayed if hierarchy contains at least one circuit. Fortunately CoGui provides another graphical representation for each hierarchy.

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

Another search tool is provided to retrieve a type by name. 'Search type' action in Edit menu displays a dialog box. Press OK button and the retrieved type is shown in both representations.

a search tool for each type hierarchy	all relation types begining by the letter 'H' are displayed (not case sensitive)

the type is shown on both representations

2.4 Concept type edition

2.4.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 using the 'Rename' action.

rename on graph	rename on tree

2.4.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

2.4.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

2.4.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

 2.4.5 Forbidden types

In a graph, the concept vertices may have a conjunctive type concepts accept 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 "vegetal" 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 special vertex  in the graph 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.

2.4.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.5 Relation type edition

2.5.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.

	insertion of a new relation type

   The following vertex is displayed: . Click twice on the vertex to edit the type name. Relation types can be renamed directly on the vocabulary tree using the 'Rename' action.

rename on graph	rename on tree

2.5.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 therelation 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.5.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.

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 or removes lines in signature table

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.5.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 'Propose 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 'Propose signature...' can help signature definition in this situation.

The wizard proposes a list of compatible concept types for each element of the signature. This list depends on the direct parents signatures and can be restricted by existing children signatures:

proposition is defined by parent	specialization is limited by children

2.5.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.

2.6 Nesting type edition and modules

2.6.1 Overview

Nesting types and modules are used to facilitate the construction of (well-structured) nested graphs. The set of nesting types is hierarchically structured by "kind of" relation in the same way as the set of concept types. For instance, if metadata is a nesting type it may have indexation and annotation for subtypes, and annotation may have comment and judgment for subtypes. The module notion allows restricting the vocabulary to a subset dedicated to represent a specific kind of annotation. A module is a subset of the global vocabulary associated with a nesting type. To design the modules, the user chooses a selection of concept types, of relation types and of nesting types in the global vocabulary which can be constructed before this selection or at the same time. 

2.6.2 Building nesting type hierarchy

Newly created nesting type hierarchy holds an unique nesting type named 'Nesting'.

Naming conventions and structure restrictions are exactly same as concept types hierarchy, consult 'Concept type edition' paragraph. Of course homonymous types are allowed through different hierarchies but not recommended (suppose future function transforming nested graphs).

2.6.3 Building 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. 

2.7 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 edit 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

2.8 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 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 the 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

2.9 Individuals
An individual is an identifier which is a surrogate for a precise entity of the discourse universe. For instance, if Town is a concept type then Budapest is an individual of type Town. A concept type may have subtypes, e.g. SmallTown could be a subtype of Town, an individual cannot have ‘subindividuals’. The ontological individuals are the individuals about which all the users agree, i.e. for all users an ontological individual must represent the same entity in the discourse universe. An ontological individual is entered into a COGUI-ontology with a primitive concept type called its privileged type. For instance, if the COGUI-ontology concerns  Modern Art, and if Picasso is an ontological individual of privileged type Artist representing the famous artist Pablo Picasso, then it is impossible to use the identifier Picasso for representing a Citroën car (unless the conjunctive type Car, Painter is not banned). COGUI checks that an ontological individual appearing in an annotation has a type which is compatible (i.e. not banned) with the privileged type of the individual. The ontological individuals can be usedl to define banned types.
All individuals appearing in a COGUI-ontology (e.g. in rules, constraints or prototypical knowledge) must be ontological individuals.  Thus, the set of ontological individuals can be completed only whenever all knowledge representing in a COGUI-ontology have been considered.

The individual view list all individuals in a sortable table. Needless to complete the list of individuals, it automatically updates when the user reference individuals in different graphs. Select individuals in the list to drop them to the graphs and right click to popup the contextual menu to rename, change the privileged type or edit the associated individual graph (see chapter below).

2.10 Individual graphs
An individual graph is a simple conceptual graph (SG) having a special concept node called its head. This special node is an individual node, and the individual graph represents exact knowledge about this individual. For instance, one could build an individual graph having [Painter : Picasso] for head and gathering exact information about Picasso (relatives, selected works, museums having some of his work). As soon as an annotation contains the individual Picasso then the information gathered into the individual graph associated with Picasso are considered by the system.Giving many rules and individual graphs will give to the system an “intelligent” behavior because these knowledge are used in the answering algorithm.

2.11 Contextual knowledge

2.11.1 Prototypical graphs
A prototypical graph is a Simple Concept graph (SG) which can be associated with a concept type or with a relation type. A prototypical graph defines usual contexts of a type.
A prototypical graph owns a special node, called the head of the prototypical graph, with the same type as the type from which it is the prototype. A node x of an annotation graph having a type with an associated prototypical graph allows an extension of the annotation by merging the node x with the head of the prototypical graph. A concept type or relation type can have several prototypes which represents different ways for describing an entity or a relation. The annotator has only access to prototypes whose all vertices are in the vocabulary of the current module during the annotation process.

creation of a prototypic	selection of the head
completion of the prototypic graph	use the prototypic in a fact graph

the result

This animation shows how to create and use a prototypic graph

2.11.2 Pattern graphs
A pattern graph is a Simple Conceptual Graph (SG) associated with a nesting type. In an annotation context a nesting type is an annotation type. Thus a pattern graph is a template for a kind of annotation. Several pattern graphs can be associated with the same nesting type. A pattern graph represents a starting point when describing a document with respect to the chosen annotation type, i.e. a nesting type n. It gathers general and frequent notions appearing when describing a document with respect to n. A pattern graph has to respect the vocabulary of the module associated with the nesting type. This constraint ensures that the use of a pattern does not break the consistency of the annotation.

This animation shows how to nest a graph and use a pattern

3 Rule Edition

3.1 Overview

Rules are used to represent implicit (common sense) knowledge. For instance, let us assume that the fact that Eve is the mother of Abel is represented in a fact graph. If the ontology contains a rule saying that if x is the mother of y then y is a child of x then the system can automatically add the information that Abel is a child of Eve. Such a rule is represented by two simple graphs. One represents the hypothesis (e.g. [woman]-1-(mother of)-2-[human]) the other represents the conclusion ([human]-1-(child of)-2-[woman]). Furthermore, there is a link between the first person in the hypothesis and the second person in the conclusion, and a link between the second person in the hypothesis and the first person in the conclusion. A rule “if A then B” is used as follows: if an annotation contains A then B can be added to the graph. See below the graphical representation of this rule:

6 Tools
6.1 Image exportation

Graphs can be exported from CoGui viewers to different graphical format files.

'Tools/Export image' menu action exports currently displayed graphs (hierarchies, fact graphs or rules) and shows a file selector dialog:

choose a file type

JPEG and PNG are well-known image formats.

FIG (Facility for Interactive Generation of figures) graphics format is a vector drawing format. This format preserves initial attributes and produces very small files. It gives access to a lot of other formats with associated softwares. Software description can be found here for version 3.2: http://www.xfig.org/userman/fig-format.html. Information about associated software can be found at this site: http://homepage.usask.ca/~ijm451/fig/

DOT is a specialized format for graph visualization. GraphViz layout tools [...make diagrams in several useful formats such as images and SVG for web pages, Postscript for inclusion in PDF or other documents...]. As in FIG format, CoGui preserves initial attibutes such like colors and shapes. But with DOT format it is no use to give vertices coordinates, layouters will simply calculate new positions. Software is available: http://www.graphviz.org .

About Graphviz layouters: DOT draws directed graphs as hierarchies, it is the best choice to represent CG types hierarchies. NEATO draws undirected graphs, is a better choice for conceptual graphs. But tested version of NEATO seems to ignore DOT language clustering features. Choose DOT layouter (it works with undirected graphs too) if conceptual graph contains nested graphs.

6.1.1 Exporting hierarchies

direct JPEG output from CoGui	direct PNG output from CoGui	FIG output displayed in JFig
JPEG obtained with DOT layouter from CoGui DOT file	PNG obtained with DOT layouter from CoGui DOT file	SVG output displayed in Internet Explorer

 

6.1.2 Exporting Conceptual Graphs

JPEG output from CoGui	FIG output inside JFig
JPEG obtained with NEATO from CoGui DOT file

 

 

PNG obtained from CoGui

 

 

with FIG output inside JFig editor

JPEG obtained with DOT(rather than NEATO) layouter from CoGui DOT file

 

Appendix

COGXML DTD

Ontology part of DTD is reproduced below. Retrieves entire document for COGXML 1.0 format here: http://cogitant.sourceforge.net/cogxml.dtd

<!ENTITY % cogxmlExtensions "">

<!ENTITY % supportExtensions "">
<!ENTITY % conceptTypesExtensions "">
<!ENTITY % relationTypesExtensions "">
<!ENTITY % nestingTypesExtensions "">
<!ENTITY % conformityExtensions "">
<!ENTITY % supportObjectExtensions "">
<!ENTITY % ctypeExtensions "">
<!ENTITY % rtypeExtensions "">
<!ENTITY % ntypeExtensions "">
<!ENTITY % markerExtensions "">
<!ENTITY % orderExtensions "">

<!-- Document. -->

<!ELEMENT cogxml (support?, (graph | rule)*)>
<!ATTLIST cogxml
app CDATA #IMPLIED
%cogxmlExtensions;
>

<!-- Propriétés supplémentaires des chaque objet du modèle. -->

<!ELEMENT subprop EMPTY>
<!ATTLIST subprop
subid CDATA #REQUIRED
%subPropExtensions;
>

<!-- Support. -->

<!ELEMENT support (conceptTypes, relationTypes?, nestingTypes?, conformity?, subprop*)>
<!ATTLIST support
name CDATA #IMPLIED
%supportExtensions;
>

<!ELEMENT conceptTypes (ctype*, order*)>
<!ATTLIST conceptTypes
%conceptTypesExtensions;
>

<!ELEMENT ctype (subprop*)>
<!ATTLIST ctype
id ID #IMPLIED
label CDATA #REQUIRED
%supportObjectExtensions;
%ctypeExtensions;
>

<!ELEMENT order EMPTY>
<!ATTLIST order
id1 IDREF #IMPLIED
id2 IDREF #IMPLIED
label1 CDATA #IMPLIED
label2 CDATA #IMPLIED
>

<!ELEMENT relationTypes (rtype*, order*)>
<!ATTLIST relationTypes
%relationTypesExtensions;
>

<!ELEMENT rtype (subprop*)>
<!ATTLIST rtype
id ID #IMPLIED
label CDATA #REQUIRED
idSignature CDATA #IMPLIED
labelSignature CDATA #IMPLIED
%supportObjectExtensions;
%rtypeExtensions;
>

<!ELEMENT nestingTypes (ntype*, order*)>
<!ATTLIST nestingTypes
%nestingTypesExtensions;
>

<!ELEMENT ntype (subprop*)>
<!ATTLIST ntype
id ID #IMPLIED
label CDATA #REQUIRED
%supportObjectExtensions;
%ntypeExtensions;
>

<!ELEMENT conformity (marker*)>
<!ATTLIST conformity
%conformityExtensions;
>

<!ELEMENT marker (subprop*)>
<!ATTLIST marker
id ID #IMPLIED
label CDATA #REQUIRED
idType IDREF #IMPLIED
labelType CDATA #IMPLIED
%supportObjectExtensions;
%markerExtensions;
>