1 User Interface: basics
1.2.2 Docking windows framework
1.2.3 Tabbed panels
1.2.4 Views description
2.2 Open, create and save projects
2.3 How to browse through type hierarchies
2.4 Concept types edition
2.5 Relation types edition
2.5.2 Naming conventions
2.5.3 Relation type signatures
2.5.4 Relation type hierarchy control
2.5.5 Relation types alteration
2.7 Multilingual vocabulary
2.8 How to work with a big vocabulary
2.10 Individual graphs
2.11 Contextual knowledge
4 Fact graph edition
4.1.2 Create and edit facts
4.1.3 Concept insertion
4.1.4 Relation insertion
4.1.6 Use prototypical graphs
4.1.7 Partial edition
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
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
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
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
default view layout (2)
view title bar buttons
|Users can customize the layout of the application
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
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.|
Each view has a unique instance and a particular behaviour in the application, in this chapter we will describe each type of view.
220.127.116.11 Project View
The project view gives access to the different objects of the project in a 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.
|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.
|The search tool supports generic characters such as '*' and '?'. For instance "*pro" will find all items containing the string "pro" such as 3approach".|
Each type hierarchy is displayed in a specialized view (concept type view, relation type view and nesting type view).
|These views provide a representation in the tree-like structure. But hierarchies of concept types and relation types are not necessarily trees, therefore dupplication might occur.|
Each element of the tree is associated with a context menu accessible by right click. Below is a table listing the possible actions from these menus.
|Edit type||Open an editor containing the graphical representation of the type hierarchy|
|Label and description||CoGui can create multilingual ontologies. This action helps to describe the labels and descriptions of each type in several languages.|
|Properties||Give access to properties of the currently selected type|
The tree types can be dragged from the views to the editors. This feature is available to editors of graphs, hierarchies, rules and modules (for more information see the relevant chapter).
|To use drag'n'drop, note that it is possible to select multiple types in the tree. For this, keep the Ctrl key down.|
Lexicographic search in types trees
search a type by label
|The type view benefits from a search tool. It is thus possible to find a type by its label. To do this, make sure that the type view is selected 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 browse through the different found types or the different paths for the same found type.|
supports generic characters such as '*' and '?'. For instance "*animal"
will find all types containing the string "animal".
Note that relation type view items display the signature of each relation type but this signature is not taken into account by the search.
18.104.22.168 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).
the error view
|A double click on an error message opens the editor and hightlights the concerned objects, an easy way to correct errors on graphs.|
22.214.171.124 Result view
This view works with the query wizard. When projections (potential answers for the query) are found, they are listed in the table.
|A double click on a query anwer opens the corresponding editor and hightlights the projected vertices.|
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.
126.96.36.199 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.
use contextual menu to access to the corresponding individual graph
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.
188.8.131.52 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.
184.108.40.206 Editing graphs
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|
|To add or remove an object from the selection set, keep Ctrl key pressed.|
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.
|Pending edges are not allowed in selection set. Thus an edge can only be copied if its source and target vertices are also selected.|
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.)
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|
|Because the two algorithms for arrangement of hierarchies do not work with circuits, so they generally can not be used with the graphs and rules.|
220.127.116.11 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
|Depending on the characters already entered, the fields of concepts and relations provide a list of compatible types and individuals. For conjunctive concept types please enter a new line for each type.|
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.
|By default ports placed at the center of each vertex are visible, ports can be hidden and connection mode turned off with the button on the graph editor toolbar.|
18.104.22.168 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.
22.214.171.124 Keyboard shortcuts
|Ctrl-C or Ctrl-Ins||Copy selected objects|
|Ctrl-V or Shift-Ins||Paste|
|Ctrl-F||Popup the search toolbar|
|Del||Delete selected objects (when a vertex is deleted all edges connected to it are also deleted)|
1.3.2 Module editor
a module editor
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
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:
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.
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.|
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 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
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
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
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.
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
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).
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.
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.
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
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.
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).
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 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|
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
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
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.
3 Rule Edition
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:
a rule example
A bi-colored representation of this rule could be simplest with just a conclusion relation "child of" added to the hypothesis. The advantage of this representation is that it allow specialization of a concept type in the conclusion. For instance, from the hypothesis [human]-1-(mother of)-2-[human] it can be deduce that the first person is a woman. Thus, rule represented below is more powerful than previous example.
But it is better to express each deduction in a separate rule and add a new rule to the first one:
a simple rule for each deduction
Due to saturation, rules must be builded carefully when at least one rule can create concept: The rules may loop and cause an infinite production of concepts. Example below is trivial but combinations of rules can generate loops very difficult to detect.
below does appear when clicking on stop button. Note that
there may be a delay before the message popup.
To create a new rule or edit an existing rule go on the tree project in the "Rules" item and use the popup menu. As other graphs, rules are organized in folders. It is particularly interesting to classify the rules on families, especially for testing purposes. Editing rules is very similar to editing simple fact graphs (see chapter below). But the editor is splitted in two parts: hypothesis and conclusion. By default hypothesis is placed on the left part and conclusions on right part of the editor.
3.3 Applying rules
Actual version of CoGui apply rules just before queryng. Please consult corresponding chapter
4 Fact graph edition
4.1 Simple graphs (SGs)
is labeled bipartite graph. One class of nodes (the concept nodes) is
used to represent entities of the discourse universe. A concept node
is labeled by a concept type (e.g. Painter,
or a conjunctive type such as Painter,Catalan) and,
possibly, by an
individual (e.g. Picasso).
A concept node which is labeled by a concept type without an
individual is called a generic concept node. Such a node represents
an unidentified element of the type. For instance, contrarily to a
node labeled [Painter : Picasso]
representing the painter
Picasso, a concept node labeled [Painter]
represents “a” painter.The
second class of nodes represents the relationships between the
entities (represented by the concept nodes). For instance, if
Guernica is an individual representing the well-known painting realized
Picasso then a relation node labeled (hasPainted)
could relate the concept node [Painter
: Picasso] to
the concept node
The edge between
: Picasso] is
labeled by 1, and the
edge between (hasPainted)
: Guernica] is
labeled by 2. This
edge labeling is used to represent different roles (e.g. to
distinguish the subject
from the complement). It is also possible to say that two different
concept nodes represent the same entity by linking them by a
below is described by a simple graph:
4.1.2 Create and edit facts
New facts and sets of facts can be created by the popup menus of "Facts" item and sub-items from project tree. After creating and naming a new graph, edit by selecting "Edit" menu, or by clicking twice on tree item. An empty graph editor is opened. Use same "Edit option" to re-open existing facts.
the fact graph contains too many vertices, it couldn't be possible
to display the entire graph. In this case the "Edit" menu
item open the fact
graph "partially" (See 4.1.6 about partial edition). Choose "Edit whole
graph" to force the edition of all graph.
4.1.3 Concept insertion
New concepts are inserted by using "Graph/insert vertex/Insert concept" from the main menu or the contextual popup menu or the local toolbar option . Concept types dragged from the concept types tree cause the creation of a new generic concept of these type. Concepts associated with individuals can be dragged from individual view. The newly created concepts have the privileged type of the individual.
Double left click
triggers a popup dialog to define type and
individual associated with selected concept. when user begin to enter
text, a list of compatible terms are listed for both concept types and
individual is not already defined, it is automatically created in
knowledge base. For type definition, two modes are available: strict
mode doesn't accept undefined concept type, free mode accept references
to type which is not already defined in vocabulary. Check "free edition
mode" in preferences/General if needed. Modes also acts on relation
Free edition can be useful during the building of the ontology, it avoid to go back to vocabulary editor. But, of course, it must be done, error message can help:
4.1.4 Relation insertion
New relations are inserted by using "Graph/insert vertex/Insert relation" from main menu or contextual popup menu or local toolbar option . Relation types dragged from the relation types tree causes the creation of a new relation.
Double left click triggers a popup dialog to define
type associated with selected relation. when user begin to
text, a list of relation types is listed.
The insertion of the relationship is not sufficient, we must also link the relation to adjacent concepts. Chapter 126.96.36.199 explain how to create an edge between two vertices.
Because the relation signature is ordered, edges between concepts and relation are associated with a number from 1 to relation arity. Edge order can be defined with popup menu on the selected edge.
You can also use double-click on selected edge, edge label successively take all compatible values between the relation signature and the type of concept.
Of course, copy/paste mechanism can also be used to duplicate pieces of graphs inside the graph or from one to another. Pending edges cannot be copied. Otherwise this error message appears when you try to copy:
See chapter 188.8.131.52 about objects selection
It is also possible to say that two different concept nodes represent the same entity by linking them by a coreference link.
4.1.6 Use prototypical graphs
4.1.7 Partial edition
If a graph is too big it could be very tedious (or impossible) to edit it entirely. In this case, CoGui provide a partial edition mode. Just a part of the graph is displayed. Visible relations are always completed, but displayed concept can have hidden neighbors. Example below shows concepts with hidden neighbors, the number of hidden neighbors is displayed on the upper right corner of the concept.
In the fact graph paragraph of general section of preferences, the user can defined limits to choose partial edition rather than whole graph edition:
To edit parts of the graph without any error, we must query the graph (See chapter 5) and browse through projections in the result view.
4.2 Graphs with nestings
Nested graphs can be inserted inside a concept, these subgraphs are typed (see chap.2.6 about nested types).
Why use nested graphs rather than a "flat" graph to represent informations ?
Consider, for instance, a cottage. It is possible to distinguish internal from external pieces of information about that cottage. The owner's name can be considered as an external piece of information concerning the cottage, whereas the number of rooms is internal information.
In information retrieval the ISBN number of a book can be considered as an external piece of information about that book, whereas the subject of the book is an internal piece of information. In these examples, the internal information can be also called (partial) description of the cottage or of the book).
Zooming is a related notion. Let us consider again the cottage example. Having the land registry position of the cottage, one may want to zoom into the cottage, e.g. one may want to have the cottage blue print, which can be considered as an internal information about the cottage. Or, at a deeper level, having the cottage blue print, one may want to know the furniture distribution in a specific room. In the book example, zooming can consist of obtaining the content of a chapter from a reference to this chapter (e.g. the number of this chapter).
Nested graphs can also be related to the notion of context. For instance, in the previous cottage example, the context of the furniture distribution (in a room) is precisely the room having this furniture distribution; the context of the content of a book chapter is precisely this chapter, and so on. The notion of context is close to the two previous notions of external versus internal piece of information, and to zooming. Indeed, zooming takes its full meaning when one knows from where the zooming is done, and an internal piece of information takes its full meaning when the piece of information whose it is an internal piece of information is known. In the forthcoming model only very simple contexts can be represented. Indeed, a context will be represented by a path of nested concept nodes. Thus, having in mind partial description as an intuitive meaning of what we aim to represent is more convenient than context. A partial description can be included into another partial description, thus a recursive model is proposed, and the entities are represented by a hierarchical structure. Similarly to the classical notion of ``boxes within boxes'' used in document processing, a nested graph consists of ``graphs within graphs''.
Example below say at first level that "Miss Michel has lost her cat, she shows a painting".
second level include a nested graph of the type "description" to describe the painting and finally, the coref link expresses the fact that the cat appearing on the painting is, indeed, the lost cat.
4.2.2 Nesting a graph
To insert a new nested graph inside a concept, select the concept and right click to obtain to contextual menu:
4.2.3 Nested graph edition
Nested graphs can be edited directly at the level of graph containing the parent concept (called the root graph), or edited alone as a classical graph.
Use contextual menu to edit the nested graph alone in the editor and return to the root graph:
Choose "Edit nested graph" option to edit the nested graph alone.
After editing the nested graph, choose this menu option to retreive to root graph edition
Sometimes it may be useful to view the graph root and the nested graphs at the same level. The + sign on the left of the nested graph expands the box to make the nested graph visible. It is useful to see the graphs but it becomes more complex to edit the content of the nested graph. However, it is very convenient to insert a pattern graph or drag selected objects to the nested graph (see animation below).
4.2.4 Use pattern graphs
See chapter 2.10.2 about pattern graphs.
Depending on the type of the nested graph, some pattern
graphs can be proposed in the contextual menu. This
action automatically insert the pattern graph into the nested
animation shows how to
nest a graph and use a pattern
The approach of the querying mechanism is to search homomorphisms between the query graph and the "knowledge base". The founded pieces of graphs (called projections) are specialization of the query graph. Above all, it is worth clarifying the concept of "knowledge base". Fact graphs can be considered separately or grouped in a unique graph crossing all informations (via the operation of normalization). Then rules can be applied (or not) to the fact graphs (or to the unique graph). The query wizard helps you to build a "knowledge set" and call Cogitant to apply rules and query the facts. Cogitant is C++ API that execute these operations, it is an open source project available here: http://cogitant.sourceforge.net
The wizard is very easy to use, just:
1) Select the query wizard in the task view
2) Write a query graph
3) Select Facts and appliable rules
4) Click on "Search" button
the query wizard
the query graph
select facts and choose to apply rules and sum facts (or not)
you can now browse through founded projections with the result view.
current distribution (with java web start) is deployed only with
compiled for Windows. That is the reason why, for now, querying and
applying rules is only
possible under Windows.
below is described by a simple graph:
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.
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
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
Ontology part of DTD is reproduced below. Retrieves entire document for COGXML 1.0 format here: http://cogitant.sourceforge.net/cogxml.dtd
<!ENTITY % cogxmlExtensions "">
% supportExtensions "">
<!ENTITY % conceptTypesExtensions "">
<!ENTITY % relationTypesExtensions "">
<!ENTITY % nestingTypesExtensions "">
<!ENTITY % conformityExtensions "">
<!ENTITY % supportObjectExtensions "">
<!ENTITY % ctypeExtensions "">
<!ENTITY % rtypeExtensions "">
<!ENTITY % ntypeExtensions "">
<!ENTITY % markerExtensions "">
<!ENTITY % orderExtensions "">
<!-- Document. -->
cogxml (support?, (graph | rule)*)>
app CDATA #IMPLIED
<!-- Propriétés supplémentaires des chaque objet du modèle. -->
subid CDATA #REQUIRED
<!-- Support. -->
support (conceptTypes, relationTypes?, nestingTypes?, conformity?,
name CDATA #IMPLIED
conceptTypes (ctype*, order*)>
id ID #IMPLIED
label CDATA #REQUIRED
id1 IDREF #IMPLIED
id2 IDREF #IMPLIED
label1 CDATA #IMPLIED
label2 CDATA #IMPLIED
relationTypes (rtype*, order*)>
id ID #IMPLIED
label CDATA #REQUIRED
idSignature CDATA #IMPLIED
labelSignature CDATA #IMPLIED
nestingTypes (ntype*, order*)>
id ID #IMPLIED
label CDATA #REQUIRED
id ID #IMPLIED
label CDATA #REQUIRED
idType IDREF #IMPLIED
labelType CDATA #IMPLIED