Preface

The Topic Maps standard is an ISO standard (ISO 13250), which defines a representation of meta information. This information can be for instance the name of the author of a document or the artist and album of a music file. This information is mainly stored as so-called topics. Each topic stands for a specific subject. This topic has one or more identifiers. It can be typed, using a topic representing a type. The topic which stands for "Max Powers" can be typed with a topic representing the concept of persons.

Topics may have names, which can be typed via another topic. Additionally occurrences can be attached to topics. These occurrences represent additional information about the subject, for instance the C.V. of the person "Max Powers". These occurrences have a type, which is a topic too and a datatype. The datatype specifies the kind of information and is usually a datatype of the XML schema specification (see http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/).

Topics can be in a relationship, which are represented by associations. These associations use topics to type the kind of relationship for instance an association typed by the topic representing "working for something or someone" could be used to express that a person (represented as topic) is working for a company, which is represented by another topic. Additionally any topic which is part of an association is assigned to another topic, which stands for the role. In the association "works for" the person is playing the role of the "employee" and the company is playing the role of the "employer". You can see it is very intuitive to model something like: 'The person Max Powers works for the Mighty Corporation.' by just defining topics for the roles, the players and the association.

Associations, names and occurrences can be scoped. This means that topics are used to set a specific area of validity, which is mostly the language for names or occurrences. That way it will be possible to add multiple names to a topic which are translations.

You can model anything in topic maps. Mostly new data are added to an existing topic map and a sort of input mask is created for the editor to change the ontology.

For instance a topic map containing the employees of a certain company should not contain topics representing the company cars. To define the content of the topic map a schema is needed. Some engines provide a proprietary schema language, where you define the topic map in the engine specific way. To change the engine would mean to recreate the schema.

For this work the Topic Maps standardising team has created a new language: the Topic Maps Constraint Language (TMCL, ISO 19756). The TMCL is not a new language, but a definition of topics and association and the specification of to interpret them. Currently the TMCL is in its final draft (see http://isotopicmaps.org/tmcl/). In addition to the topics, TMCL specifies a set of templates for the Compact Topic Maps Notation (CTM, see http://isotopicmaps.org/ctm/ctm.html). With the help of these templates it is possible to create a schema via any text editor.

Onotoa is an editor for TMCL. But instead of editing a text file, Onotoa lets you create the schema in a visual editor. The visualisation is based on the GTM level 1 standard (see http://isotopicmaps.org/gtm/). This standard is far from finalised, so some changes have been made. With Onotoa it is possible to create schemas visually. As the old saying goes: "a picture says more than thousand words" - a diagram which is easy to understand is clearer than hundreds ofCTM text lines. In Onotoa you can export the schema to CTM. So if you want to have the CTM using the TMCL templates, you can create them. It is also possible to import a CTM schema, so you can re-use schemas which had been designed previously and then create some diagrams.

Onotoa is based on the popular eclipse platform (see http://www.eclispe.org).

This handbook will explain the functionality of Onotoa.

The first part will show you how to use Onotoa: [_getting_started] will explain what is needed to install Onotoa. This chapter also describes the different parts of Onotoa and shows you how to create the first diagram.

In [_property_details_view] the input masks for all editable elements will be explained. It will also outline the elements, their properties and their relationship to TMCL.

[_the_model_view] explains the part of Onotoa which gives an overview of the topic map schema. It includes an explanation some functionality, like the creation and deletion of elements.

The visual editor will be explained in [_the_diagram_editor]. It explains the functions for creating and deleting elements apart from the visualisation of the schema elements.

The last chapter of the first part is [_preferences]. It will explain how Onotoa can be configured.

The second part of this handbook contains some tutorials which will guide you through your first topic map schemas.

Using Onotoa

1. Getting started

This chapter will explain how to get Onotoa and what is needed to start it. It also gives a short description of various parts of Onotoa. If you follow the instructions in this chapter you will be able to install Onotoa and create your first diagram.

1.1. The Website of the Onotoa Project

The Onotoa project maintains a website which provides you with all information about the ongoing developments. The website is available at http://onotoa.topicmapslab.de. In [website] you can see a screenshot of the Onotoa website.

images/onotoa_website.png
Figure:Website of the Onotoa project

In the left column of the website you can see the latest news from the Onotoa project. You can get the latest release information about Onotoa there, but also other important information for the Onotoa community like announcements of user group meetings. The news are also broadcasted by the RSS feed of the website. Subscribe to the feed and don’t miss any news about Onotoa! For more details about the RSS feed see the "Stay tuned" section below.

The central column of the website contains some introductory information about the Onotoa project. All background information about Onotoa is provided in the About Onotoa section of the website, which is one of the tab menus in the navigation bar of the Onotoa website.

Much more important is the right column. It contains the download packages of the latest release of Onotoa for the main operation systems. You can directly start to download the appropriate package for your environment. All available download packages, also from previous releases, are provided in the download section of the website, which is one of the tab menus in the navigation bar of the Onotoa website. You find all details about the download and installation of Onotoa in the section below.

The Documentation tab is the most important button in the navigation bar of the Onotoa website. It contains the full documentation of Onotoa. We highly recommend you that you read the documentation before you get started with Onotoa.

1.1.1. Stay Tuned

You should subscribe to the RSS feed in order to get updates about the latest developments in the Onotoa project. Add the URL of the feed http://onotoa.topicmapslab.de/news.rss to your favourite feed reader. Get more involved in the ongoing discussion about the further development of the Onotoa project and subscribe to the Onotoa mailinglist.

1.2. Licence and Requirements

Onotoa is published under the Eclipse Public License. You can download and use Onotoa for free and without any restrictions in functionality.

As described below in more detail, there are two ways to install Onotoa:

The Java Runtime Environment Version 5.0 must be installed to run Onotoa. The latest Java Version can be downloaded for free from http://java.sun.com.

Tip
You can check the your java version by opening a shell and enter java -version. Windows™ user open the shell by executing the command cmd.

1.3. Using the stand-alone version of Onotoa

Onotoa does not come with an installer. You just need to download the file for your system. For Windows™ you’ll need "onotoa-1.1.0-win32.win32.x86.zip" will be required. If you have a 64bit Windows™ you will have to download "onotoa-1.1.0-win32.win32.x86_64.zip".

After downloading the file for your system you will have to unzip it. The zip file contains a folder named "onotoa", so it is not necessary to create one. After unzipping the archive you should find an executable for your platform. This will include a binary file (e.g. "onotoa.exe" for Windows™ or "Onotoa.app" on MacOS™).

If you start Onotoa you should see the main window, like in [empty_win] after a brief for loading.

images/emptywin.png
Figure:Blank Onotoa window

To create a new model, use File→New... Choose the path of the file and name it "example.ono". After that your window should look like [emptyfile_win]

images/emptyfilewin.png
Figure:Onotoa window after creating a file

1.4. Using the plug-in version of Onotoa

The Onotoa plug-ins can be installed into an existing eclipse installation. You will need eclipse 3.5 (Galileo) for Onotoa.

An up and running version of eclipse is required and has to be installed. Choose Help→Install New Software… and enter http://onotoa.topicmapslab.de/update into the text field next to Work with:. Press enter and the content of the update site will be shown (see [updatemanager]).

images/update_manager.png
Figure:Update Manager of Eclipse 3.5

To create Topic Maps schemas it is only necessary to install Onotoa Plugins. If you want to export to CTM or import existing CTM files you will have to install the Import_feature or Onotoa Export Plugins. The tinyTiM feature is needed in both cases, so you will have to install this too. Choose the features you want to install (we advise to install all) and click on Finish. You should agree to the licence agreements after the dependencies have been checked and then restart eclipse after the installation.

You will have to create a project before you can create a Topic Maps. You can use any project type you want. In this example we will create a simple project. Select File→New→Project in the eclipse menu and choose General→Project. Set the name to "Onotoa Example" and press enter. We will use the workspace as project location.

Now create a new file by selecting File→New→Other (see [newfile1]). Select Onotoa→New Onotoa File and press Next. The Container of the following wizard page is the project we want to add the file. Press Browse… and select the Project "Onotoa Example". The other text field contains the name of the file. Please rename the file to "example.ono". The dialogue should look like [newfile2]. Press finish and the new file will be opened.

images/new_file1.png
Figure:File Wizard of Eclipse
images/new_file2.png
Figure:File Wizard of Onotoa

After creating the new file Onotoa switches to the Onotoa Perspective. This should look like [nonrcp_win].

images/emptyfilewin_nonrcp.png
Figure:Onotoa window after creating a file in Navigator

1.5. The Onotoa Perspective

A perspective is a definition of the content of the main window. It describes which parts of the application are visible and where they are located. These parts are called views and editors. Usually views are layouted at the border of the main window, whilst the editor is positioned in the center of the main window.

Onotoa consists of views and editors which are layouted in the Onotoa perspective. The perspective with labelled views is shown in [perspective].

images/perspective.png
Figure:The Onotoa perspective

1.5.1. Model View

The Model View provides an overview of the topic map schema and the diagrams. It is the centrepiece of the application. Diagrams are created in the Model View and an editor will open up by double clicking on a diagram name in the tree. A detailed description of the Model View is given in [_the_model_view].

1.5.2. Diagram Editor

The Diagram Editor provides the visual editing functionality. You can create new topic types and associations in it. A detailed description is included in [_the_diagram_editor].

1.5.3. Outline

The Outline is an overview of the diagram. You can move to a part of the diagram by clicking on the section you want to move to.

1.5.4. Property Details View

The Property Details View provides a data entry interface to edit the properties of an element in Onotoa. An element may be a schema construct, such as constraints, topic types or diagrams. Every element has its own property page, which is an input interface for the properties shown in the Property Details View. A detailed description of the property page of every element is given in [_the_property_details_view]

1.6. Creating the first diagram

With Onotoa it is possible to create multiple diagrams for a Topic Maps schemas. Although the schema can be created with wizards provided by the Model View, it is preferable to do so with the Diagram Editor.

Via the context menu of the Diagrams node in the Model View a new diagram can be created. After selecting Create New Diagram… a dialogue box will asks for the name of the diagram. Alternatively you can select Create New Diagram… in the drop down menu, marked with images/viewmenu_button.png . This name should be unique within each schema definition. After pressing okay, the diagram will be added to the Diagrams node and an editor will open where the diagram can be edited.

On the right hand side of the editor is a sidebar. This sidebar is called palette and contains the tools to create new diagram elements (see [palette]).

Palette of a diagram editor

:images/palette.png

To add a new element to the diagram just drag an palette entry onto the position of the diagram. Let us create a new topic type for persons. Drag the Topic Type entry of the palette onto the diagram. You will see a new topic type is being created. Types are named default plus a number. To rename a type, click on the topic type in the diagram. The Property Details View should show the properties of the name, as in [topictype1]. You can change the name, by editing the text field next to Name:.

images/new_topictype_pp.png
Figure:Property Page of TopicType
Note
Not every element is dragged into the diagram. For example, to create a new occurrence constraint you will have to drop the palette entry on an existing topic type.
Tip
Instead of dragging and dropping elements of the palette, it is possible to click on them and click on the target point in the diagram. A new element will be created after the second click.

Feel free to play a bit with the properties of a type. A detailed description of the other types and constraints and their property pages is included in [_the_property_details_view].

2. The Property Details View

Every element of an schema has a property page where the properties of an element may be changed. Examples for properties are the name of a topic type or the cardinality of a constraint. The following sections will explain the property pages of the elements. These pages are shown in the Property Details View. The view a property page of an element, you will have to select it either in the Model View or in a Diagram Editor.

Note
The property pages support undo and redo functions for model changes. To manage a lot of changes during entering the text, Onotoa processes the changes after the text field loses its focus or the enter key was pressed.

2.1. Documentation

Every element of the schema has a additional properties, which are used for documentation purposes. These properties are:

images/documentation_pp.png
Property Page of documentation

To modify these properties use the tab labelled Documentation, which is part of the Property Details View of almost every element.

Note
The documentation will be exported according to the TMCL draft if you export the schema.

2.2. Diagram

The diagram has only one property:

You can edit the name by modifying the value in the text field of the property page. If you enter a name which is already used, a red icon will appear on the left hand side, and the name will not be changed, when the focus is lost.

images/diagram_pp.png
Property Page of Diagram

2.3. Domain Diagram

Similiar to the diagram the domain diagram has only one property:

You can edit the name by modifying the value in the text field of the property page. If you enter a name which is already used, a red icon will appear on the left hand side, and the name will not be changed, when the focus is lost.

images/domain_diagram_name.png
Property Page of Domain Diagram

2.4. Topic Map Schema

Another top level element is the topic map schema. This element contains all the elements of the schema, despite the graphical representations.

The properties of a topic map schema are:

images/tmschema_pp.png
Property Page of TopicMapSchema

Both properties are optional.

2.5. Prefix

A prefix is used to abbreviate a IRI used in subject identifiers or subject locators. Let us suppose that all subject identifiers start with: "http://onotoa.topicmapslab.de/example/topics/". A topic for a person could have the subject identifier "http://onotoa.topicmapslab.de/example/topics/person". Another topic has the subject identifier 'http://onotoa.topicmapslab.de/example/topics/corporation'.

A prefix such as "ex" could be used for "http://onotoa.topicmapslab.de/example" to denote identifiers like: "ex:person" and "ex:corporation". They are equivalent to like the long versions, but if you want to change the prefix of a URL it only has to be done once in the prefix definition not for each individual topic.

Every diagram includes a box containing the prefixes. If you click on the prefix box in the upper left corner of the diagram, the prefix property page will open.

images/prefix_pp.png
Example of Prefix Property Page

To remove a prefix, just select and press Remove in the table. Press Add… to add a new prefix and a dialogue will be shown, which provides an input mask for the prefix. After pressing OK the new prefix will be added to the schema and will exported if the CTM export is applied.

images/newprefix_dialog.png
Example of Prefix Property Page

2.6. Topic Type

Topic type is a topic, which specifies that a topic, which is instance of topic type is used as type in a type-instance relationship. A schema defines topic types, their names and occurrences and their relationship. Every type in a schema is instance of the topic "topic-type", except for types which are used as name, role or occurrence type.

Every type in TMCL is instance of "topic-type", which means they all share a minimum of properties. The property page of a topic type can be seen in [tt_pp]:

images/topictype_pp.png
Property Page of topic type

A topic type has the following properties:

images/si_dialog.png
Subject Identifier Dialog
images/isa_selection.png
Topic Selection Dialog

2.7. Name Type

A name type is used to specify the topics to type a name. In a topic map, a topic may have more than one names. Their meaning is realized by using topics, for instance the topic "firstname". These topics should be typed by a name type. The TMCL standard says, that any type of a name which is not instance of "name-type" is invalid.

Names can be reified, which means a topic is used to add more information to the name, such as its origin, its meaning and so on. The topic which may reify names using this name type can be specified in the reifier property.

It is also possible to add a scope to names of topics. With the scope property you can tell which topics may be used as scope and how often.

images/nametype_pp.png
Property Page of name type

The properties of topic type are inherited by a name type(see [_topic_type]). In addition it has the following properties:

Note
If you remove the scope constraint, its topic types will continue to exist.

2.8. Occurrence Type

An occurrence type is used to specify the topics to type an occurrence. In a topic map, a topic may have more than one occurrence. Their meaning is realized by using topics, for instance the topic "content" in a topic "document". These topics should be typed with occurrence type. The TMCL standard says, that any type of an occurrence which is not instance of "occurrence-type" is invalid.

Occurrence types can be reified and scoped similar to name types.

images/occtype_pp.png
Property Page of occurrence type

The properties of a topic type are inherited by an occurence type (see [_topic_type]). In addition it has the following properties:

Note
If you remove the scope constraint its topic types will continue to exist.

2.9. Association Type

An association type is used to define the type of an association, for instance "worksFor". A topic which is not instance of an association type is invalid.

In addition an association type is related to a set of role types. These define the roles to be used when an association of this type is created.

Similar to names and occurrences, associations may be reified and scoped.

images/assoctype_pp.png
Property Page of association type

The properties of topic type are inherited by association type(see [_topic_type]). In addition it has the following properties:

Note
If you create a new topic type for a scope constraint or role constraint it won’t be removed if you remove the constraint.

2.10. Role Type

A role type is used to specify if a topic type is used to specify a role. Every topic which is used as role has to be typed by "role-type".

The properties of a topic type are inherited by a role type (see [_topic_type]).

images/roletype_pp.png
Property Page of role type

2.11. Name Constraint

A name constraint connects a topic type to a name type. For instance you have the topic type "person" and the name type "first name". If a name constraint is added to the topic "person" it will be possible to specify that it has to have exactly one name of type "first name".

A name constraint is an element of an topic type. It has the following properties:

images/nameconstr_pp.png
Property Page for name constraint

After creating a new name constraint the type is set to the default name type "tmdm:default-name". This can be changed by pressing the button on the right hand side. A dialogue will appear, proposing all name types in the schema. To create a new name type press the label Type: on the left of the text field. This will open the new type wizard. After the creation it will be selected as type for this constraint.

If a special type is set it is possible to edit its properties in the second tab, called Name Type. It lists all type properties, see [_name_type] for details.

2.12. Occurrence Constraint

An occurrence constraint is used to connect a topic type with an occurrence type. For instance the topic "document" has to have at least one occurrence of type "content". This constraint will have a cardMin of 1 and a cardMax of *.

An occurrence constraint is an element of a topic type. It has the following properties:

images/occconstr_pp.png
Property Page for occurrence constraint

After creating a new occurrence constraint the type is set to the default type "tmdm:subject". This can be changed by pressing the button on the right hand side. A dialogue appears proposing all occurrence types in the schema. To create a new occurrence type press the label Type: on the left of the text field. This will open the New Type Wizard. After the creation it will be selected as type for this constraint.

If a special type is set it will be possible to edit his properties in the second tab, called Occurrence Type. It lists all type properties, see [_occurrence_type] for details.

Note
Although "tmdm:subject" is set in the namespace of TMDM, it is specified in the TMCL standard. This type just means every topic is allowed.

2.13. Subject Identifier Constraint

The subject identifier constraint is used to request for a subject identifier of topics using the containing topic type. It is possible to constraint the number of identifiers and also the syntax with a regular expression.

images/si_constr_pp.png
Property Page subject identifier constraint

The following attributes can be modified:

2.14. Subject Locator Constraint

The subject locator constraint is used to request for a subject identifier of topics using the containing topic type. It is possible to constraint the number of subject locators and also the syntax with a regular expression.

images/sl_constr_pp.png
Property Page subject locator constraint

The following attributes can be modified:

2.15. Association Constraint

An association constraint is used as connection between an association type and it’s role player constraints.

The association constraint has only one property:

You can select an existing Association Type by pressing the right button and selecting the desired type. To create a new type, click on the Type label on the left. The wizard to create a new type will appear and after the creation the new type will be the type of the constraint.

images/assoc_constr_pp.png
Property Page for association constraint
Note
There is no such thing as an association constraint in the TMCL draft. It was introduced to encapsulate the association type and the constraints using this type. See the following section for more information.

2.15.1. Differences between TMCL and Onotoa

In TMCL, there are three different kinds of constraints to describe the signature of an association, each of which can be declared using a speficic TMCL template:

tmcl:topic-role-constraint

declared using plays-role within a TopicType
is used to constrain the cardinality of a specific role type an instance of the topic type plays within an association.

tmcl:association-role-constraint

declared using has_role within an AssociationType
is used to constrain the cardinality of a specific role type with the association type.

tmcl:role-combination-constraint

declared using role-combination within an AssociationType
is used to constrain instances of which topic type can play which role type within an association together with instances of which other topic type with which role type_. In other words: it defines a path navigating from one topic of a given type to another topic of a given type over an association of a given type by constraining which role type the source topic plays and the role type the destination topic plays. It does not constrain how many times an instance of a topic type can be involved in such a path (this is where the topic-role-constraint comes in) and it does not constrain how many roles of a specific type can be involved within a particular association (this is where the association-role-constraint comes in).

It is obvious that for a binary association, one role-combination constraint is enough, but for an association with three roles, three role-combination constraints are needed. For associations with four roles, six role-combination constraints are needed and so on. Instead of this, Onotoa creates one association constraint (which does not exist in TMCL) that has an association type and a list of role player constraints which manage the needed data in an application-specific way.

As a user, you don’t have to worry about the internal representation of the constraints. Onotoa takes care of importing and exporting valid TMCL schemas.

2.16. Role Combination Constraint

The role combination constraint is used to constraint the possible variations of players and roles.

For instance given three topic types "city", "state" and "continent" and an association type "contains". We know, that if a state contains a specific, the continent containing this state will also contain the city. So we don’t want to have the explicit relationship "continent" contains "city". With the role combination constraint we can specify that if the role "container" in the association "contains" is played by "continent", the role "containee" may only be played by "state".

In Onotoa you would say: The role type is "container" and the topic type is "continent". The other role is "containee" and the other topic type is "state".

The role combination constraint is a property of association type, so you can find it as additional tab in the association type property page.

The properties of the role combination constraint are:

images/role_comb_constr_pp.png
Property Page for role combination constraint

To add a new role combination constraint press the Add… button and fill out the prompted dialogue.

images/role_comb_constr_dialog.png
Dialogue to create a new role combination constraint

If no specific role combination is specified for the players all combinations will be valid.

3. The Model View

The Model View is the centrepiece of Onotoa. It represents the schema, visualising it as a tree. The state of the schema is saved as attribute of the Model View. The Diagram Editors are just views on the model, or parts if only a few elements of the schema are visualised in a diagram. This makes it possible to create multiple diagrams to realize different views of the same schema.

images/modelview.png
Figure:Model View

In the title bar of the Model View you will see a button. This button can be used to start a validation of the current schema. Additionally the Model View has a menu, which can be opened by clicking on images/viewmenu_button.png . Right now the menu contains Create New Diagram… and Validate.

Every element in the tree is called a node. A node has a parent and may have children. For example the node Diagrams is used as parent for node representing diagrams. These nodes are named after the diagram. A description of the different nodes and their children will follow. Every node has a context menu. To open this menu just click with the right mouse button on the node.

If a node represents a schema element or a diagram, the properties of the element will be shown in the Property Details View after selecting it. To select a node, just click on the node with the left mouse button.

3.1. Managing diagrams

The node Diagrams is the parent of all nodes representing diagrams.

To create a new diagram, use the context menu of the Diagrams node. It contains two entries, Create New Diagram… and Create New Domain Diagram…. Choose the entries, by clicking with the left mouse button on it and a dialogue appears and asks for the name of the new diagram. If you want to abort, just press the Cancel button.

Every diagram must have a different name, so if you enter a name, which is already used, it is not possible to press OK. After pressing OK a new diagram is created and an editor is automatically opened. You can also recognize, that the node Diagrams got a new child node labelled with the name of the diagram.

images/create_diagram_ctx_1.png
Figure:Context menu of Diagrams in the Model View

The context menu of a diagram node has two entries:

Note
The deletion of the diagram does not delete the schema elements, which are represented in the diagram.

To reopen a closed Diagram Editor just double click on the node representing the diagram.

3.2. Managing the schema

A Topic Maps schema consists of topic types and their specialisations and constraints, which are associated with each other. The Model View groups the elements of the schema by topic type. The main node of the Topic Maps schema is labelled as Topic Map Schema. It represents the current schema. If you select it, the property page of the schema will be shown in the Property Details View with an input mask for the schema name and base locator. For more information see [_topic_map_schema].

With the Model View it is possible to create almost every schema element, by using the context menu of the different nodes. The properties of new elements can be edited by selecting them and filling out their property page in the PropertyDetails Views. First a user should select the property page of the node Topic Map Schema. Especially the property base locator is useful for creating new topic types. Then select the node topic map schema and enter the URL "http://onotoa.topicmapslab.de/example". The base locator is used to create a subject identifier for any new topic type created. The identifier is formed by using the base locator and attaching the name. The example shows that if a topic type with the name "person" is created the subject identifier "http://onotoa.topicmapslab.de/example/person" will be created automatically.

After setting the base locator, it’s time to create some topic types. Mostly you only need to create the topic types of your schema. It is possible but not necessary to create name, association, occurrence or role types in the Model View. These specialisations of topic type can be created on demand in the property pages.

To create a new topic type "person", use the context menu of the node Topic Type. Choose Create TopicType… and a dialogue will open to create a new topic type, as illustrated in [new_topic_type].

Currently Onotoa only supports one name per topic. If the topic is used to type a constraint, the name will be displayed therefore Onotoa will not allow topics with the same name. If the schema has a base locator which it should you will realize, that the subject identifier text field is automatically filled by the URL created with the base locator.

images/new_tt_dialog.png
New Topic Type Wizard

For the name "Person" and the topic has the subject identifier "http://onotoa.topicmapslab.de/example/person". You may change the identifier by editing the subject identifier text field. After modifying the subject identifier it will not be changed anymore if you change the name. You may notice a pop-up window showing a list of proposals for your subject identifier. You can navigate through the list with the up and down keys. Select one by pressing Enter. The proposals are filtered by the text you have already written. If you enter "http://psi" only identifiers starting with that prefix will be in the proposal list.

images/newperson_dialog.png
Create Person Topic Type with Proposal Pop-up

There are two proposal providers installed in Onotoa:

Note
Sometimes the connection to the subj3ct server is to slow for results before the time-out. Therefore it may happen that you get a shorter proposal list before you restart the filtering by entering another letter in the subject identifier text field. If you don’t want to use the proposal providers you can deactivate them in the preferences.

After creation of the topic "Person" some constraints can be added to the type. The context menu provides the following entries:

After creating a constraint, you can expand the type node and the constraints of that type are shown as child nodes of the topic type node. To edit the properties of a new constraint, select it in the Model View and the property page of that constraint is opened in the Property Details View.

4. The Diagram Editor

The diagram editor is used to visually create and modify Topic Maps schemas. It provides a graphical view of the schema elements. The visualization is based on the GTM level 1 proposal (see http://isotopicmaps.org/gtm/gtm-oslo-2008-04.pdf ). GTM is planned to be the standard for the visualization of Topic Maps and Topic Maps schemas. Unfortunately there is no work done on GTM at the moment. The following sections will explain how schema elements are created and how they are represented.

4.1. Palette

The palette provides the functionality of the editor. It contains a set of tools to create new elements.

Onotoa distinguishes between diagram and schema elements. Schema elements are used to define the Topic Maps schema. These are the constraints, topic types and their properties. A diagram element is a visual representation of a schema element. For example the rectangle, which represents a topic type or the line within this rectangle which represents constraint of the topic.

The palette will create a diagram element and a new schema element which it represents. If you select a diagram element the properties of the represented schema element will be shown in the Property Details View.

The palette can be seen in [palette_elements].

images/palette.png
Palette of a diagram editor

The elements of the palette are:

To create a new Topic Type just drag the Topic Type palette entry into the diagram. A new Topic Type with a default name will be created. To add another Topic Type simply repeat this process.

To add a Name Constraint to the Topic Type, just drag Name Constraint onto the Topic Type and a new Name Constraint with default properties will be added to the Topic Type. The other constraints work similarly. But Scope Constraint and Reifier Constraint need to have a scopeable or reifyable constraint, i.e. Association, Name and Occurrence Constraints as parent.

To create an Is a or Kind of relationship, click on the tool entry in the palette. Then click on a topic type representation and after that on another one. In an Is a relationship, the first Topic Type will be the instance and the second one the type. In a Kind of relationship the first Topic Type will be the subtype and the second one is the supertype. The editing state will remain in the relationship creation mode, so you don’t have to go through the palette menu again for creating another relationship. To go back to selection mode press the right mouse button or Select in the palette.

4.2. Graphical Representation

This section explains how to interpret the graphical representation of the schema elements. The representation is based on the GTM level proposal, which you can find at http://isotopicmaps.org/gtm/gtm-oslo-2008-04.pdf .

4.2.1. Topic Type

The Topic Type representation is basically a divided rectangle. The first part contains the name of the topic type. Left to the name an icon reflects the kind of topic type. The following table lists the icons:

images/types/topictype.gif

Topic Type

images/types/associationtype.gif

Association Type

images/types/nametype.gif

Name Type

images/types/occurrencetype.gif

Occurrence Type

images/types/roletype.gif

Role Type

After the name a list of subject identifiers and subject locators are shown. The identifiers are a bit smaller than the name. To differentiate between subject identifier and subject locator the latter is marked with an =.

images/topic_header_rep.png
Header of a Topic Type Representation

The next section contains the name constraints of the topic type. This means, all name constraints which are connected to the topic type via "tmcl:topic-name-constraint". The name constraint consist of a name type, a regular expression and the cardinality. This is reflected in the graphical representation. The syntax of the name constraint is:

name type cardMin..cardMax [regExp]
      ~reifier type [cardMin..cardMax]
      @scope type [cardMin..cardMax]

If the regular expression equals the default value .* it is omitted. If the default-name type is used, default is written at the name type part.

images/name_ex_rep.png
Name Constraints Representation of a Topic Type Representation
Note
Constraints regarding scope and reification are tied to the constraining type, not to the constraint. If you reuse a name type in two different topic types to create a name constraint, both will have the same reifier or scope constraint.

The following section contains the occurrence constraints. Similar to the name constraint, they have the following syntax:

occu. type cardMin..cardMax : datatype
      ~reifier type [cardMin..cardMax]
      @scope type [cardMin..cardMax]

If an occurrence type is set, the name of it will be used. If not the subject identifier tmdm:subject will be used, which represents every topic. The regular expression is not shown in the occurrence constraint. Although it can be set via property page, it was considered too confusing to be added to the graphical representation.

Note
Constraints regarding scope and reification are tied to the constraining type, not to the constraint. If you reuse an occurrence type in two different topic types to create an occurrence constraint, both will have the same reifier or scope constraint.
images/occ_ex_rep.png
Occurrence Constraints Representation of a Topic Type Representation

The last section contains the identifier constraints. They say how many subject identifier or subject locator a topic type may or must have. They also can set a required form of the identifier using a regular expression. The layout of these constraints is:

subject identifier cardMin..cardMax [regexp]
subject locator cardMin..cardMax [regexp]

Again if the regular expression equals the default, it is omitted.

images/identifier_ex_rep.png
Identifier Constraints Representation of a Topic Type Representation
images/topic_rep.png
Example for topic representation of a whole topic

4.2.2. Supertype-Subtype Relationship

It is possible to create a hierarchy of topics with the supertype-subtype relationship. A top of this hierarchy is a general representation of a subject. Its lowest topic is a specialization of a subject. In the diagram this is shown

like the inheritance in UML, with a connection between two topic type representations. The supertype is the type where the arrow points. See the following example:

images/supertype_rep.png
Example for supertype-subtype relationship

4.2.3. Type-Instance Relationship

Although the type-instance relationship in a schema is rarely used, it is possible to do so in Onotoa. An example is shown below. The connection representing the relationship has an open arrow, which points to the type. The source of the connection is the instance.

images/typeinstance_rep.png
Example for type-instance relationship

4.2.4. Association Constraint

An association constraint is represented by an ellipse. It contains a label, which renders the name of the association type and a list of scope types, associated with the association type. This ellipse is used as connection node between the topic types, which represent the players.

The syntax of the text in the ellipse is:

association type
~reifier type cardMin..cardMax
@scope type   cardMin..cardMax

The example shown in [assoc_constr_rep] illustrates the specification of an association constraint for the "works for" association. Instances of that association can be reified by any topic and have to be scoped by a topic of type time.

images/assoc_constr_rep.png
Example for Association Constraint in Diagram

The use of reifier constraints or scope constraints is optional.

Instead of connecting the ellipse with role types as well, a better approach was implemented. The name of the role type, and the cardinality of the role constraint are connection labels next to the ellipse. The connection between the association constraint and a topic type, which is a player in the association has another label at the player’s site. This represents the cardinality of the player. If a role is played by only one player, the player cardinality and the role cardinality should be equal.

4.3. Exporting Diagrams

It is possible to export a diagram as png or svg image. To do so use the button labelled Export Diagram. After pressing the button, a file dialogue will open. Choose the file or enter a new filename and save the file. The fileformat is chosen by the file suffix. If your name end with .svg a svg is created, a png else. Ths suffix .png will be added if no suffix is chosen.

images/export_diagram_button.png
The "Export Diagram" button

The button is linked to the current diagram editor, which means the diagram in the current editor is exported. If no editor open, the button will be hidden.

5. The Domain Diagram Editor

The Diagram Editor should be the editors first choice to create and modify a Topic Maps schema. It displays detailed informations about the schema and represents an exact graphical representation.

The Domain Diagram Editor presents the informations in an abstract way without the loss of important information. Because of this it is predestined for demonstrative issues. The diagram is reduced to the main aspects of a schema and does not seem to be overcharged. Schemas could be created in a fast and easy way. The following information does not appear in the diagram:

Look at the images below to see the differences.

images/example_diagram_view.png
Diagram of a schema
images/example_domain_diagram_view.png
Domain Diagram

The Palette of the Domain Diagram Editor also differs from the one of the Diagram Editor. Some constraints, types and the Is A… relation are absent to simplify the menu. There is no loss of complexity. All missing properties are still available and modifiable in the Property Detail View below the diagram but this is not the recommended way to use the Domain Diagram Editor.

images/domain_diagram_palette.png
Domain Diagram Palette

In contrast to the Diagram Editor, two additional operations are directly available by the use of the context menu:

The Domain Diagram provides the insertion of an image for each Topic Type to increase the visual accessibility. Click on the Add image… entry in the context menu of a Topic Type, choose one from the file system and confirm your choice to add an image. The entries of the context menu change after the adding of an image. Instead of the add function the following ones will appear:

images/context_menu_image.png
Context Menu

5.1. Palette

The palette will create a diagram element and a new schema element which it represents. If you select a diagram element the properties of the represented schema element will be shown in the Property Details View.

The palette can be seen in [domain_palette_elements].

images/domain_diagram_palette.png
Palette of a Domain Diagram editor

The elements of the palette are:

To create a new Topic Type just drag the Topic palette entry into the diagram. A new Topic Type with a default name will be created. To add another Topic Type simply repeat this process.

To add a Name Constraint to the Topic Type, just drag Name onto the Topic Type and a new Name Constraint with default properties will be added to the Topic Type. The Occurrence Constraint works similarly.

To create a’Kind of' relationship, click on the tool entry in the palette. Then click on a topic type representation and after that one another one.

To add a Association just drag the Association palette entry into the diagram. A new Association Constraint with a default name will be created and the specific Association Type too.

To add a Topic Role Constraint just click on the Player palette entry. Then click (order does not matter) on the association representation and the topic representation.

The editing state will remain in the relationship creation mode, so you don’t have to go through the palette menu again for creating another relationship. To go back to selection mode press the right mouse button or Select in the palette.

5.2. Creating a schema with the Domain Diagram

The domain diagram shows the topic types and their associations. For a topic type the type of anems and occurrences are shown too, but it is not possible to see or modify the cardinality, scope, reification or regular expression of the types. It is possible to create a schema with the Domain Diagram Editor first and refine it afterwards using the Property Details View.

The goal of the design of the Domain Diagram Editor was to allow the creation of a schema in the editor without the use of any other view. To achieve this goal the diagram context menu was extended. It is possible to set a type of a name or occurence via the context menu. Another change is, that the creation of a constraint automatically creates a typing topic. This topic can be renamed by clicking on the name in the diagram. If a typing topic should be used which already exists, it is possible to select it in the context menu. After choosing an existing type, the new created type will be deleted.

5.3. Interaction between Diagram and Domain Diagram

Every newly created diagram is reachable by its respective named tab at the top of the main editor window.

Onotoa provides the exchange of elements between a Domain Diagram Editor and the Diagram Editor. There are two different methods to perform this exchange as you can see in the context menu of every Topic type:

images/move_copy_context.png
Move and Copy

The user could choose the number of elements he would move or copy. It is possible to copy or move single topics as well as selections or the whole schema. Use the Marquee feature or click on each element while holding the Ctrl key pressed to make a selection.

Basically you can search Topic Types and identifiers. The results are displayed as tree structure in a new view. The root shows informations about the specific search (type, search string e.g.) and the children represent the results. The button above the tree refreshes the last search. All searches are reachable by the menu entry Search.

images/documentation/search/result_view.png
Result View
Tip
Double click on any entry to open its Property page.

Onotoa provides several different searches for different purposes. These are:

6.1. Search Topic Type

This is a search for any Topic Type of the schema. Access this search via Search→Search Topic Type at the menu. You can refine the search by the use of some constraints. These are:

Note
Check Name, Check Subject Identifier and Check Subject Locator are connected as logical disjunction.
images/documentation/search/search_dialog.png
Search Dialog

6.1.1. Advanced Mode

The search for an Association or a Topic Type allows you to enable the advanced mode. Click on the Advanced >> button to show more search options.

At this mode you can define constraints the searched type should use. The left list shows all available Topic Types. Select one or more entry and click the images/documentation/search/buttons/add_one.png button to add them or double click on one entry. Your selection should appear in the right list. Remove them by double clicking or the use of the images/documentation/search/buttons/remove:one.png button. Above every list is a small text box that you can use to filter (case sensitive) the shown entries by their names.

images/documentation/search/buttons/clear.png

Clear all selections and reset the name filter

images/documentation/search/buttons/add_one.png

Add selected types to use list

images/documentation/search/buttons/remove_one.png

Remove selected types from use list

images/documentation/search/buttons/filter.png

Enable or disable type filtering

If you search an Association Type, you can:

If you search a Topic Type you can:

Note
All types the searched topic should use are connected as logical conjunction.
images/documentation/search/advanced_dialog.png
Advanced Mode

6.2. List Topics without Identifier

To find all Topic Types without any identifier call this search via Search→List Topics without Identifier. That means: Every result don’t have at least one Subject Identifier or Subject Locator or Item Identifier. By the use of the context menu at the Result View you can change this immediately. If you do this, the Result View will be refreshed automatically.

images/documentation/search/non_id_context.png
Add Identifier

6.3. List All Subject Identifier

List all Subject Identifiers of the schema. Open the search by Search→List All Subject Identifier. Double click on a result to open the corresponding Property Details Page of the Topic Type that uses this Subject Identifier.

images/documentation/search/si_list.png
Result List

6.4. List All Subject Locator

List all Subject Identifiers of the schema. Open the search by Search→List All Subject Locator. Double click on a result to open the corresponding Property Details Page of the Topic Type that uses this Subject Locator.

images/documentation/search/sl_list.png
Result List

6.5. Find Use

With this search you can find all uses of a specific Topic Type. To define this one open the Topic Selection Dialog via Search→Find Use at the menu. The following dialog consists of a list that shows all available Topic Types and a text field to filter the list. Select one entry and confirm your choice.

images/documentation/search/topic_selection_dialog.png
Topic Selection Dialog

All Topic Types that uses the defined Type are now displayed at the Result View. To see the kind of the use click on the triangle in front of an entry to expand the node. Now you can also use the context menu by right click on a Topic Type to search the use for this Type.

images/documentation/search/find_use_context.png
Result View

6.6. Clean Schema

Onotoa offers this little feature to keep your schema clean. Open the cleaner via Search→Clean Schema t the menu. It searches unused Topic Types and provides the opportunity to delete them. If the list is empty, everything seems to be fine. Above the list is a text field, that you can use to filter (case sensitive) the results.

Depending on its type, a topic is recognized as unused when:

images/documentation/search/buttons/clear.png

Clear all selections and reset the name filter

images/documentation/search/buttons/new.png

Mark Topic Type for deletion

images/documentation/search/buttons/remove.png

Restore Topic Type

images/documentation/search/buttons/filter.png

Enable or disable type filtering

Once the cleaner found unused topics you can delete them. Select the unused type and press the images/documentation/search/buttons/remove.png button. The font color of the entry will change to grey. If you want to restore him, press the images/documentation/search/buttons/new.png button. All decisions you made have no effect until you press the Clean button. After this all selected types will be really deleted.

images/documentation/search/cleaner.png
Clean Schema
Tip
Are there too many Topic Types? Use the type filter.

7. Preferences

Note
If you are using Onotoa within an eclipse installation, you only need to read [_identifier_assists] and [_diagram_colours]

Onotoa provides a preference dialogue, which will be explained in this section. To open it just click Window→Preferences… in the menu bar.

The preference dialogue is split into two parts. On the left is a tree with the categories and their subcategories of the preferences. On the right, the preferences of the current selected category will be shown. Next to Onotoa is a category called Install/Update. This category is used to configure the update mechanism of Onotoa.

7.1. Install/Update

The Install/Update node has two subcategories, which can be viewed after expanding the node. The first node is the Automatic Updates node. Click on it and you’ll see the preferences for automatic updates on the right, as in [automatic_update].

images/update1_pf.png
Preferences for Automatic Update

If you want to deactivate the automatic update, just uncheck the button labelled Automatically find new updates and notify me. You can instruct Onotoa to look for updates in the menu Update schedule. The following section, called Download options assists to configure the download of updates. In the last group you can give instructions for notification.

The second page, shown in [update_site] shows a list of update sites used by Onotoa. With the buttons it is possible to add new update sites, edit or remove existing ones. You also can disable update sites, which means, when looking for updates or new installable plug-ins, this site will be ignored.

images/update2_pf.png
Preferences for Update Sites

7.2. Identifier Assists

Onotoa provides a content assistant for subject identifiers. This assistant creates proposals for topics based on the name or on the identifiers in the topic map schema. The proposals are prepared by so-called PSIProvider. You can create you own provider or install providers from other sources. If you don’t want to use a specific PSIProvider, for instance the Subj3ct Provider, because of a slow or non existent internet connection, you can deactivate it by uncheck the checkbox next to the name. Check it again, and the PSIProvider is activated again.

images/provider_pf.png
Preferences for Identifier Assists

7.3. Diagram colours

The colours of a diagram can be changed in Onotoa. This might be useful if the default colour scheme doesn’t look good, for instance on a beamer.

Onotoa supports colour schemes. A colour scheme is one setting of colours for topic types and comments. Additionally a secondary colour and the font colour can be set.

A list of schemes is shown in Diagram Colors in the category tree (see [colour_scheme_list]).

images/diagram_1_pf.png
Preferences for colour Schemes

Use the check box left of the name of the scheme to select a scheme. Press the Add… button to create a new one and the colour scheme editor will open (see [colour_scheme_dialog]). Enter a name of the scheme and choose the colours, by pressing the buttons next to the label. If you want to use gradients, such as the default colour, check the Use Gradient button and choose a secondary colour for the topic type and comment representations. The gradient will go from the primary colour on the top to the secondary colour at the bottom.

images/diagram_2_pf.png
Preferences for Colour Schemes

It is possible to export your colour scheme list and import it to another installation of Onotoa.

Warning
If you import colour schemes, all existing schemes will be deleted.

8. Export an schema

Onotoa provides a set of export functions to generate a schema topic map, java source code or even a complete editor. The latter is explaines in [_generating_an_instance_editor]

To use the export functions use the menu File→Export….

images/export_dialog.png
Export Dialog

8.1. Exporting the Schema

After creating the schema with Onotoa you might use it to validate a topic map. For that you need a schema according to the TMCL standard. Use the Export TMCL entry and press Next.

The dialog shows the following input mask:

images/export_tmcl_dialog.png
Export TMCL Dialog

The file is the absolute path to the file.

The check boxes below have the following meaning:

A TMCL schema is a topic map and therefore different notations for the serialization are possible. In the list below the check boxes you can choose from the given types. The suffix of the file name will be changed based on the selection.

After pressing finish the topic map is created from the schema and serialized in the given file.

Note
If you choose CTM the TMCL templates will be used to create the topic map.

8.2. Exporting to Maiana

Another option is to upload the schema topic map to Maiana, the generic Topic maps Browser of the Topic Maps Lab. Use Maiana Export and enter your API-Key and press apply. The table below lists all topic map end points which may be overwritten. Select an end point and press finish to overwrite the topic map.

To create a new end point in Maiana select Create new Maiana Endpoint. Tje following values are necessary:

Note
You need a Maiana account at http://maiana.topicmapslab.de. Your API-Key is on the left side of the user page.

8.3. Exporting Aranuka annotated Java Sources

Another Use-Case for a schema is the generation of Java classes. With Aranuka the Topic Maps lab provides a library which maps java objects with topic maps using some schema annotations in the code. Onotoa provides a generator for this kind of classes.

Note
See http://code.google.com/p/aranuka for more information on Aranuka.

Choose Aranuka Code Generator in the exporter list provides a simple input mask with the following entries:

Target Directory the target directory of the generated code. Package Name Specifies the package name of the generated classes. Generate Kuria Annotations Flag whether the generated classes should also be annotated for the usage with Kuria input masks Generate Genny ModelHandler Classes Generates additional classes necessary for the generated editor. THis might be useful if an existing editor should get an updated model.

9. Generating an Instance Editor

With the Generic Editor SDK and Maven3 it is possible to create an editor based on a topic map schema.

The generated editor uses Aranuka for mapping the java instances to topics therefore there are some restrictions for the schema:

In addition to the TMCL constructs the code generator needs some annotation which are explained in the following sections. For most of the constructs a new node will be shown in the ModelView which can be disabled in the preferences. Selecting one of the node labeled "Code Generation Data" a page is shown in the PropertyDetailsPage. In contrast to the constructs property details page, the annotation pages need to apply the values by pressing the apply button in every page. Without pressing "apply" the changes are lost!

Note
It is possible to add the annotations in the constructs annotation table instead of using the input mask.

The sections are titled with the annotated constructs.

9.1. Topic Map Schema

The code generator page for the topic map schema has only one text field: "Default Category". Its value is used to label the editors ModelView tab for every topic type. If no value is given the tab is labeled "Model".

Used annotations for topic maps schema
Key Description

de.topicmapslab.genny.category

Default category name

9.2. Topic Type

For every topic type another category can be set. For each category a new tab is added to the ModelView of the editor. In addition the name of the generated can be set. This might be useful if the name of the topic type is not useable as class name or its in another language than the wanted code.

The annotation keys used are:

Used annotations for topic types
Key Description

de.topicmapslab.aranuka.name

Class name

de.topicmapslab.genny.category

Category name

9.3. Identifier Constraints

Every identifier constraint of a topic type will be represented as field in the generated class.

The nodes in the ModelView have a generator child node which provides an input mask. The widgets shown represent the following annotations:

Used annotations for identifier constraints
Key Description

de.topicmapslab.aranuka.name

name of the field of the generated class

de.topicmapslab.aranuka.generateattribute

generate a field

de.topicmapslab.kuria.hidden

indicates that there should be no widget for the generated field; its hidden in the input mask

de.topicmapslab.kuria.read-only

generates a widget but it is only read-only

de.topicmapslab.kuria.label

Every widget has a label which shows the name of the field in the class. This can be overridden.

de.topicmapslab.kuria.typelabel

Instead of using toString the field will be used as string representation of the instance

de.topicmapslab.aranuka.autogenerate

identifier will be auto generated when the instance will be persisted into the topic map.

de.topicmapslab.kuria.weight

A weight used to sort the widgets of the input mask

Warning
Aranuka allows only one field for each identifier type. This includes contraints inherited from super types.

9.4. Name and Occurrence Constraints

Every name and occurrence constraint of a topic type will be represented as field in the generated class.

The nodes in the ModelView have a generator child node which provides an input mask. The widgets shown represent the following annotations:

Used annotations for identifier constraints
Key Description

de.topicmapslab.aranuka.name

name of the field of the generated class

de.topicmapslab.aranuka.generateattribute

generate a field

de.topicmapslab.kuria.hidden

indicates that there should be no widget for the generated field; its hidden in the input mask

de.topicmapslab.kuria.read-only

generates a widget but it is only read-only

de.topicmapslab.kuria.label

Every widget has a label which shows the name of the field in the class. This can be overridden.

de.topicmapslab.kuria.typelabel

Instead of using toString the field will be used as string representation of the instance

de.topicmapslab.kuria.createnew

used to create a new instance before adding it to the list - only used for lists or sets

de.topicmapslab.kuria.weight

A weight used to sort the widgets of the input mask

Warning
It is not allowed to have names or occurrences with the same type. This also valid for super types. This means if you specify a name contraint with type x in a super type there must be no subtype with a constraint using x.

9.5. Associations

Associations have no special property pages for annotations yet. So the annotations need to be added directly into the annotation table. Associations also are represented by fields in the class. The type will be the class for the other players.

Mostly it is not wanted that every player has a field with the counter player. For instance an person should have the attribute where she lives which is of type address. On the contrary the address instance should not have a set of persons. To hide the field the annotation "de.topicmapslab.aranuka.generateattribute" is set to false. The construct annotated with this annotation will be the which will not be a field. In the example it is necessary to select the topic role constraint connecting the association constraint with the topic type person.

The code generator sets the name of the field in binary associations to the name of the type. If the card-max is more than 1 the field is named "typeNameSet". To prevent that this name is used as label the "de.topicmapslab.kuria.label" annotation is used.

Other annotations createnew and so on are listed below and are used like in other fields.

Used annotations for topic role constraints
Key Description

de.topicmapslab.aranuka.generateattribute

generate a field

de.topicmapslab.kuria.hidden

indicates that there should be no widget for the generated field; its hidden in the input mask

de.topicmapslab.kuria.read-only

generates a widget but it is only read-only

de.topicmapslab.kuria.label

Every widget has a label which shows the name of the field in the class. This can be overridden.

de.topicmapslab.kuria.createnew

used to create a new instance before adding it to the list - only used for lists or sets

de.topicmapslab.kuria.weight

A weight used to sort the widgets of the input mask

9.6. General Information

Every constraint has a cardinality which will be used for the code generation. If the card-min is zero, the field will be marked as optional, which means the input mask does not demand this values.

If card-max is greater then 1 a set of the type is created. Especially for primitive data types it is necessary to set the create new flag to true.

9.7. Generate the Editor

After annotating the schema the editor can be generated using the "Generate Genny Application" entry in the export wizard.

The following dialog is shown in [genny_export_dialog]

images/genny_export.png
Create an application dialog

The Target Directory leads to a directory where the generated code will be stored. The Application ID is a string similar to a package name. You should use a qualified domain to be sure your application plug-ins will have a unique id. The Name of the application will be used as executable name.

After pressing Finish another dialog will open which shows a progress bar for the generation. If the bar is at 100% the close button will be enabled win32, macosx and linux for 32 and 64 systems.

Note
The application is build with Maven3. If you start the generator for the first time the building process will take some time because maven needs to download all dependencies. After that there are stored in a local repository.

Short Tutorials

1. How to Create a Schema based on a natural description

1.1. Theoretical background

This tutorial is about the creation of a Topic Maps schema based on a natural description. In this case natural means spoken word or text by men about a real life "thing", its relationships, (inter)acting objects, players and so on.

Lets think about the following statement:

"A company is an institution, where many different persons work. These persons have got a name (first and given name) and an address. They may change the company they working for, so an employment is a time relative contract with a beginning and an end. One company differ from another by name and address."

When we analyse this short statement, we can figure out our two main topics "person" and "company". Both got a name and an address (occurrences). There are three associations those describe the relationships between them:

We recognise that more than one person could work for a company, but one person could not work for more than one company. That point effects the cardinality. In equal measure we handle the other cardinalities:

Association

Role One

Role Two

work for

employee [1..*]

employer [1..1]

lives in

inhabitant [1..*]

place [1..1]

located in

locatee [1..1]

location [1..1]

At this point, the occurrence "address" does not contains many informations, because only one value per occurrence is allowed. If we want to specify the address, we must transform it into a own Topic Type with its own occurrences. These are:

Now we are able to associate them to the topics "person" and "company" without the lost of detailed information and can get into Onotoa.

1.2. Into Onotoa

First of all, we have to create an new model and a new diagram. Click on File→New and choose your preferred name for the model, e. g. "example_domain.ono". To create a new diagram, right click on Diagram in the Model View and choose Create New Diagram… in the context menu. After your decision for a diagram name, the Onotoa window should looks like this:

images/documentation/description_to_schema/create_model_diagram.png
Onotoa with an empty diagram

We start with the creation of the topics "company" and "person". On the left side of the Onotoa window you can see a box, the so called Palette. You can add anything in this box by drag and drop into the diagram. Press and hold left mouse button on Topic Types, move the cursor into the diagram and release the button and a yellow box will appear. At the bottom of the window is the "Property Details View". There you can modify the properties of a topic. We need to change the name, because "default0" is not correct. So name the new topic "person" by clicking on the name and an editor will open. As next step, we create the topic "company" in equal measure.

images/documentation/description_to_schema/set_topic_name.png
Set topic name

Now we turn to the deeper details of "person". We specified, that a person works in a company, has got at least one first name, exact one given name and an address.

The Model View is on the left side of the editor window. To create an occurrence click right on OccurrenceTypes and choose the Create OccurrenceType… entry. A pop up appears and we type "first name" as name.

images/documentation/description_to_schema/create_occurrence.png
Create an occurrence

To add this occurrence to the "person" topic click once on the Occurrence Constraints entry in the Palette and twice on the topic in the diagram. In its property page we have to choose a type. Click on the button at the right and select the currently created "fist name" occurrence.

We specified, that a person have got between one and infinite first names. We realize this by the change of the cardinality in the property page. The incorrect default values for cardMin and cardMax are zero and infinite. Set cardMax to 1.

images/documentation/description_to_schema/set_occurrence_cardinality.png
Set occurrence cardinality

In the end our "fist name" occurrence need a data type. Switch to the Occurrence Type tab in the "Property Details View" an scroll down to the Datatype entry and press the button at the right. Select "xsd:string" in the following dialogue and confirm your decision. The first occurrence is finished.

images/documentation/description_to_schema/select_datatype.png
Select data type
Note
You can specify valid names by the use of regular expressions.

After this is done we repeat this procedure to create the "given name" occurrence for "person" and the "name" occurrence" for "company". But set the cardinality in this two cases to "1..1", because this is exactly we want it to be.

A person works for a company. To figure this out, we create the association "works for". Drag an drop an new Association Constraint from the Palette into the diagram. A circle with the label "No type set" will appear. So far we have not created an Association Type but could do this now. Click on Type at the left side in the property menu, enter "works for" as name in the appearing window and our new Association Type will be generated.

images/documentation/description_to_schema/create_association_type.png
Create association type

An association demands for roles and these are "employer" and "employee". We search for the roles entry in the tap Association Type in the "Property Details View". There we create a new one by clicking on the New… button. Choose "employer" as name an repeat the whole procedure for "employee". More than one person could work for a company, so we change the employees cardMax value from 1 to *.

images/documentation/description_to_schema/create_roles.png
Create Roles

As next step we add this relationship to the diagram. Choose Topic Role Constraint in the Palette, click once on "person" and twice one the association. Repeat this for the "company" and two thin black lines should be added to the diagram. As we see there are no roles entries. We change this by clicking on the "no role_type_set" label in the diagram an select of course "employee" for "person" and "employer" for "company" in the property page.

The cardinality of a Topic Role Constraint tells how often a specific instance of the player type may be used in associations of the given association type. In the example we set the cardinality of the company to 1..* and for the person 1..*.

images/documentation/description_to_schema/diagram_view_1.png
Diagram view

Of course an employment is a time relative relation and we want to integrate this in our schema. Click once on Scope Constraint in the Palette and click twice on the "works for" association in the diagram. Choose "time" as name. Set the cardinality to "1..1", because we want exact one scope. No we have created a new topic, but we need two occurrences to specify the scope: "start" and "end". Right click on the "time" topic in the Model View and choose the the Create Occurrence Constraint… entry in the context menu. In this way create two occurrence constraints.

images/documentation/description_to_schema/model_view.png
Model view

Of course both of them need a Topic Type. Click on Type in the property page and create one named "start" and and one named "end". As data type, we select "xsd:date" (Occurrence Type → Datatype) and set both cardinalities to "1..1".

images/documentation/description_to_schema/diagram_view_2.png
Diagram view

Now the relationship between "company" and "person" is finished. But there is something we miss in both topics: The address. Lets proceed with this.

Add a new Topic Type by drag and drop from the Palette and name it "address". This topic has got four occurrences:

Create them in the common way. All of them are needed only once, that is why we set cardMin and cardMax to 1. As data type we choose "xsd:string". If you have done all right, the graphical representation of the topic should looks like these:

images/documentation/description_to_schema/address.png
Address Topic Type

Now the last thing to do is the association between "company" respectively "person" and "address". A person lives anywhere and an object like a company is located anywhere. So build the two associations types "located in" and "lives in" in your preferred way. I do this by the use of context menu in the "Model View". After this I add two Association Constraints from the Palette to the diagram and allocate the just created Association Types to them.

To create the roles for the associations take once more a look at the "Property Details View", click on the Association Type tap, build the new ones in the usual way and change their cardinality:

Association

Role One

Role Two

lives in

inhabitant [1..*]

place [1..1]

located in

locatee [1..1]

location [1..1]

After this, your Onotoa window should looks like these and we completed the tutorial:

images/documentation/description_to_schema/final_screen.png
Final Onotoa screen

2. How to create unary associations

2.1. Theoretical background

An unary association is an association that needs only one role to be complete. Some examples are:

We pick up the first example an create the according schema. We need a Topic Type "person", a Association Type "is single" and its only role "single". That is all we need and now we are ready for Onotoa.

2.2. Into Onotoa

First of all, we have to create an new model and a new diagram. Click on File→New and choose your preferred name for the model, e.g. "example_unaryAsso.ono". To create a new diagram, right click on Diagram in the Model View and choose Create New Diagram… in the context menu. After your decision for a diagram name, the Onotoa window should looks like this:

images/documentation/unary_association/create_model_diagram.png
Onotoa

A the right side next do the editor window is the so called Palette. With its help we can add topics the the schema. Left click on Topic Type and left click twice anywhere in the editor to add our new topic. A yellow box with the label "default" should appear. The label represents the name of the topic and we have to change it. This and all other properties of every topic is editable in the Property Details View at the bottom of the Onotoa window. The first entry should be the name. Click in the field and change the name from "default" to "person".

images/documentation/unary_association/set_name.png
Set topic name
Note
Click on a topic to get its focus and its unique property page will be available in the Property Details View.

Now we will create the association. Use the Palette to add an Association Constraint and look at its property page. We have to select or create the type of the constraint. Click on the blue label Type and a dialogue to create an Association Type will appear. Type "is single" as name and press the Finish button to create the type.

images/documentation/unary_association/new_asso_type.png
Create Association Type

An association needs roles and we have to define them. In this case it is only one. Click on the graphical representation of the association to reach their property page. Click on the tab "Association Type" scroll down to the roles entry. At the right hand side is the New… button the create roles. Click on it and type "single" as name in the following dialogue. The new role will appear in the property page.

images/documentation/unary_association/new_role_type.png
Create Role Type

At the next step we will connect the "person" and "is single. We do this by the use of the Topic Role Constraint. Select it from the Palette and click first on the topic and second on the association (order does not matter). From now on a thin black line connect the two topics.

The label "no role type set" means what its look like. Let us set it. Therefore click on the label to get to the property page. At the right hand side is a small arrow. If you click on it, you will see a list of all available roles and have to choose one. In this case the choice should be easy. The cardinality of the "Topic Role Constraint* should be 0..1 . This means an instance of person may be in exactly one association instance or in none.

images/documentation/unary_association/editor_view.png
Unary Association

3. How to Use the Domain Diagram

3.1. Theoretical background

The objective of domain diagrams is the fast creation of Topic Maps schemas and the clearly arranged presentation of these. As red line for these tutorial we choose the following example:

A person has got at name and a homepage. These person is the member of a unique named society. This society has got a homepage too and a statue.

Through the analyse of these example we figure out the following topics:

After we create the whole schema, we will use the copy and move function to change between the different diagram types. That is all we need. Let us get into Onotoa.

3.2. Into Onotoa

3.2.1. Creating a schema in the Domain Diagram

First of all, we have to create an new model and a new diagram. Click on File→New and choose your preferred name for the model, e.g. "example_domain.ono". To create a new Domain Diagram, right click on Diagram in the Model View and choose Create New Domain Diagram… in the context menu. After your decision for a diagram name the Onotoa window should looks like this:

images/documentation/domain_diagram/create_model_diagram.png
Onotoa

Now we create the topic "person". At the right hand side of the editor window you find the Palette. Add per drag and drop a new topic to the diagram. Press and hold left mouse button on Topic, move the cursor into the the diagram and release the button. A yellow box named "default0" will appears. Click on the topic to get the focus and click on the name to enter the editor modus to change this value. Type "person" and confirm this by pressing the enter key. Repeat this to create the "society" topic type.

images/documentation/domain_diagram/set_topic_name.png
Set Topic name
Note
All properties of a topic are also editable in the Property Details View, even more than in the Domain Diagram. We do not use it for demonstrative reasons in this tutorial. Because of this, we do not set cardinalities, select data types for occurrences and so on.

A person should have one name constraint. We add these by the use of the context menu. Right click on the topic and chose Add Name Constraint. A new entry named "name0" will appear in the box. Click on it to get the focus and click twice to change the entry to "name".

images/documentation/domain_diagram/name_constraint.png
New Name Constraint

The topic "society" also needs a name constraint (in our example the same one), but this time we add it per drag and drop from the Palette. Press and hold left mouse button on Name, move the cursor into the the topic "society" and release the button. We just created the Topic Type "name". Because of this, is is not necessary to re-create this one. Right click on the constraint and click on Set Name→name to chose the existing one. The name created with the constraint will be deleted automatically.

All our topics still need are some occurrences. Add them per drag and drop or by the use of the context menu(Add Occurrence Constraint). Enter "homepage" and "statue" as their names.

Afterwards your Onotoa window should looks like this:

images/documentation/domain_diagram/onotoa_screen_1.png
Onotoa

The next step will be the creation of the "member of" association. Add an association per drag and drop from the Palette to the diagram and a blue big dot will appear labelled "association0". The according association type will be generated automatically. Click on the dot to get the focus and click on the name to edit it. Type "member of" and press the enter key to acknowledge your decision.

The entry Player in the Palette represents the Player Association Constraint. We need this to connect topics and associations. Select the Player" entry from the *Palette. Now click first on the topic "person" and twice on the "member of" association". A thin black line appears to show the connection. Repeat this for the "society" topic.

images/documentation/domain_diagram/create_association.png
Create association

If we look at the association labels in the diagram, we will see three question marks instead of roles, because we did not create them until now. Let us do this next. Click right on person as ??? to open the context menu, proceed with Set Role → New Role… and type "member" as name in the appearing window. Repeat this for the player "society" but name the role "organization".

images/documentation/domain_diagram/create_role_type.png
Create Role Type

At this point, we finished the complete schema and created an abstract model of the tutorial example. To improve the diagrams clearness we add a picture for each Topic Type. Use the topics context menu, click on Add Image… and select an image from your hard disk.

images/documentation/domain_diagram/diagram_view_1.png
Diagram view

3.2.2. Switching between diagrams

Sometimes it will be necessary to switch between the different diagram types for various reasons. Onotoa allows you to move and copy the complete schema or only parts of this. These operations are lossless and easy to do.

First of all we have to create an normal diagram additional to the existing Domain Diagram. Use the context menu in the Model View to create a new one named "example_diagram" ) and a new tap will appear in the editor window.

images/documentation/domain_diagram/second_diagram.png
Create a second Diagram

To copy the the whole diagram we have to mark all topics in the diagram. Select the Marquee entry in the Palette and mark all topics with a frame or press otherwise the key combination Ctrl + A and a fat black line should surround every selected part of the diagram.

Note
Of course it is also possible to move and copy single elements or selections.

Access the context menu of one element (for example the topic "person"), click on Copy To…→example_diagram and all should be done.

images/documentation/domain_diagram/move_elements.png
Move elements

Take a look at the normal diagram where the complete schema of this tutorial should appears. You can see all informations we create in the last view minutes. We see also that the values for data types and cardinalities are the default values, because we did not set them before in the Domain Diagram.

images/documentation/domain_diagram/normal_diagram.png
Diagram
Note
The position of the diagram elements could varies after the move / copy operation. == How to Create a Role Combination Constraint ==

3.3. Theoretical background

With the help of the role combination constraint we are able to avoid unnecessary variations of players and roles.

A common example to figure out this constraint is a transitive association like "contains". Transitive means: If a contains b and b contains c, a automatically contains c, which is not necessary to specify. According to this, we will create a simple example with the three players "continent", "country" and "city" and our association "contains".

Obviously we recognise the top bottom relationship. A state may contains countries and a country may contains cities. Other combinations (like a state may contains cities) are not allowed and through the transitive character of the association dispensable.

So all we need to create a topic map schema is:

With the knowledge of these cornerstones, we can get into Onotoa

3.4. Into Onotoa

First of all, we have to create an new model and a new diagram. Click on File→New and choose your preferred name for the model. I have chosen example_rcc.ono. To create a new diagram, right click on Diagram in the Model View and choose Create New Diagram… in the context menu. After your decision for a diagram name (example_rcc for example), the Onotoa window should looks like this:

images/documentation/create_model_diagram.png
Onotoa

From now on, we are ready to start with the real work. First of all we generate our three Topic Types "continent", "country" and "city" (to simplify matters, there is no need for additional details like subject identifiers, occurrences, scopes and so on).

In the Model View section we right click on TopicType→Create TopicType… and choose "continent" as name for our new Topic Type. We handle "country" and "city" in equal measure. Like you can see in [tut_topic_types_in_model_view], the three new created Topic Types should appear in the Model View and we can add them do the diagram by drag and drop.

Note
You change properties of any topic, by use of the "Property Details View" at the bottom of the Onotoa window.
images/documentation/topic_types_in_model_view.png
New created Topic Types

Now we create the association "contains" and their according roles. At the left side of the editor window is a Palette called box located. Click once on Association Type in the Palette and twice anywhere in the diagram to add our new type. To modify the values of the new Association Type, take a look at "Property Details View" at the bottom. As we can see, the name of our association is "default0". Change it to "contains". Every association demands for specific roles and now we step forward to this.

Note
There are different methods to create a new topic. You can use the context menu in Model View, add them by drag and drop from the Palette or create them ad hoc in some cases. I switch between them for demonstrative issues.

Once again we use the Model View to create a new topic. We need exactly two roles: "container" and "containee". Right click on RoleTypes→Create RoleType… and give them their names.

images/documentation/create_containee_role.png
New created Role Type
Note
We could add our roles to the diagram, but this is not necessary because their is no need for a graphical representation of these two Role Types. They will appear later in the diagram, when we set the Topic Role Constraints.

After these step, we can finish the "contains" association by editing their role set.

Therefore we proceed to "Property Details View" of the association by clicking on their graphical representation in diagram. We scroll down until the roles entry and click on the add button at the ride side. The appearing window should list our two created roles and we only have to check the two entries and acknowledge them by pressing the OK button.

Note
Of course it is now possible to change the cardinality values in the "Property Details View" , but we will do this later.
images/documentation/set_roles.png
Choose Role Type

At this point, we created and set the basic structures of our example and your diagram window should looks like this:

images/documentation/diagram_view_1.png
Diagram view

All Topic Types are defined and finally we can model the exact relationships in the schema. To do that, we add an Association Constraint by drag and drop from the Palette. A black circle with the label No type set will appear in the diagram and we recognise what our next task will be. Likewise all other topic properties, we can set them in the "Property Details View". Click on the "…" button at the right side an choose "contains" in the pop-up menu. Now the label of the circle should have changed.

images/documentation/association_constraint.png
Choose type
Tip
If no Association Type exists, you can alternatively create an new one by clicking on "Type"

Connecting the Topic Types with the Association Constraint will be the next step. Therefore click on the Topic Role Constraint entry in the Palette to select it. Click on the type "continent" and the association "contains" to link them. One thin black line with two annotations should appear. The first annotation represents the role type and the second the cardinality. Proceed in the same manner with the topic "city". For the topic "country" we must create two Topic Role Constraints, because a country could be a "container" and a "containee".

images/documentation/diagram_view_2.png
Diagram view
Tip
Press and hold the left mouse button to move elements in the diagram for visual purposes.

Now we specify each Topic Role Constraint by selecting a Role Type and setting cardinality:

We start with the "continent". Click on the No role type set label in the diagram and select "container" as role in the Property Detail View. As you can see in the diagram, the default role cardinality is “1..1”, which is exactly what we want it to be. So we guarantee the existence of exactly one "container". In some cases no Topic Type "continent" will be used, so we have to change the player cardinality. Set the cardMin value to 0. The cardMax value is correct.

images/documentation/set_player_cardinality.png
Topic Role Constraint specification

The "country" topic will be next .Remembering, that this type could play both roles, we start with the "containee" role and select this one for one of the two Role Association Constraints. But there could be many countries, those a continent contains. Thats why me must change the role cardinality. Click on the "contains" association in the diagram, change into the Property Detail View an scroll down to the roles entry. There we change the cardMax value to infinity. Finally we set the player cardinality to "0..*". So the schema allows any quantity of the player "country" as "containee".

images/documentation/set_role_cardinality.png
Set role cardinality

Turning to the second role of "country", we notice, that this is similar to the explanation for the Topic Type "continent". Select "container" as role in the "Property Detail View" and change the player cardinality to "0..1". The rest is already correct.

Our finally topic is "city". Set the role to "containee" in the usual way. The player cardinality “0..* ” matches our wishes, but we have to modify the role cardinality to "1..*" That way guarantees at least one "containee" and allows the possibility of no "city" player.

images/documentation/diagram_view_3.png
Diagram view

We are ready for the last and final step, the declaration of the Role Combination Constraints. Select the "contains" Association Constraint in the "Model View", turn to its property page and select the additional tab Role Combination Constraints. We add a new entry by the use of the add button. The appearing window contains four changeable properties:

We have to fill in our two possible cases to finalize our first project.

images/documentation/rcc_1.png
Role Combination Constraints 1
images/documentation/rcc_2.png
Role Combination Constraints 2

Now we have finished the first tutorial and your Onotoa window should looks like these:

images/documentation/final_screen.png
Final Onotoa screen

4. How to use the reifier constraint

4.1. Theoretical background

We use reifiers to provide additional informations for a topic and distinguish between reifyable topics and topics, that reifies another topic (only topic types can do this). Reifyable topics are:

Once the constraint is used to make a topic reifyable, there are three possible settings for the reifyable topic:

To demonstrate the constraint, we will create the following short example:

A company has got a homepage and we want to specify the information who created this homepage. To simplify matters we define that a person created it. So we need a topic "company" her reifyable occurrence "homepage" and a second topic "person" which is the refier. Let us get into Onotoa.

4.2. Into Onotoa

First of all, we have to create an new model and a new diagram. Click on File→New and choose your preferred name for the model, e.g. "example_reifier.ono". To create a new diagram, right click on Diagram in the Model View and choose Create New Diagram… in the context menu. After your decision for a diagram name, the Onotoa window should looks like this:

images/documentation/reifier/create_model_diagram.png
Onotoa

Let us start with the reifier topic. Open the context of the node TopicTypes in the Model View at the right hand side of the Onotoa window and choose Create TopicType… . Type "person" in the following dialogue to finish our first topic. Create the "company" topic in the same way.

images/documentation/reifier/create_topic_type.png
Create Topic Type

As we can see the topics do not appears in the editor window. Click on the triangle on the left hand side of the TopicType node to list all topics and add the existing ones to the editor by drag and drop. Your editor window should looks like this one:

images/documentation/reifier/editor_view_1.png
Editor View

As next step we will create the occurrence "homepage". Therefore right click on the "company" topic and select the entry Add Occurrence Constraint in the context menu. Now we must create and set the specific Occurrence Type. Create a new one by the use of the Model View and name it "homepage". Switch to the property page of the Occurrence Constraint and click on the button at the left hand side to set the type. A list of all available types appears and we choose our only existing one: "homepage".

Now we take hand on the reifier constraint. All necessary settings can be done in the Property Details View. We start with the topic "person" and wanted to set the topic this one will reifies. Click on the graphical representation to get access to its property page and scroll down to the section reifies. Click on the add button and Onotoa provides all possible topics in a list. Select "homepage" and confirm your choice.

/// a picture should be right here but bug #32 is not fixed at this moment.

The final step will be to define that

Glossary

Association Constraint

An association constraint is used to connect an association type with its roles to topic types, namely players.

Association Type

An association type is a specialized topic type. Only instances of an association type should be used to type an association.

Bundle

A bundle or plug-in is a component of an eclipse application.

Cardinality

The cardinality specifies the amount of usage of an element. CardMin defines how often the element must occur at least. CardMax defines the maximum occurrence of the element.

Constraint

A constraint is a topic which represents a definition of a specific topic type. The topic name constraint for instance is used to define, that a topic has names of a specific type. The topic constraint may have some occurrences, which specify additional restrictions, for instance the cardinality.

Content Assist

For some text fields Onotoa will provide proposals based on the characters already entered. The proposals are shown in a list under the text field. You can select one by using the up and down arrow keys. If some information of the proposal exists, it will be shown in another window on the right of the list. To select a proposal press enter. The whole process is called content assist.

Diagram

A diagram is a view of the Topic Maps schema. It consists of graphical representation of schema elements and connects them if they have a relationship, e.g. the supertype-subtype relationship.

Diagram Element

A diagram element is any element which is part of the diagram. Basically a diagram element is the visualization of a schema element.

Domain Diagram

A Domain Diagram is an abstract view of the Topic Maps schema. It consists of graphical representations of schema elements and connects them if they have a relationship, e.g. the "Kind of" relationship, but in a more abstract way than the normal diagram. Some informations, e.g. cardinalities, aren´t displayed in this diagram type.

Feature

A feature bundles a set of plug-ins. Additionally it contains meta information, such as the licence model or copyright information.

Model

The set of schema and diagram elements is called the model.

Model View

The Model View shows all elements of the Topic Maps schema in a tree viewer. It also lists the diagrams.

Name Constraint

A topic may have a number of names of different types. By using name constraints the number of names and their type may be specified for a topic type. All instances of that topic type need to fulfill this constraint.

Name Type

A name type is a specialized topic type. Only instances of a name type should be used to type a name.

Node

A node is an element in the tree of the Model View. It has a label, mostly the name of the schema element it represents and may have child elements.

Occurrence Constraint

A topic may have a number of occurrences of different types. By using occurrence constraints the number of occurrences and their type may be specified for a topic type. All instances of that topic type need to fulfill this constraint.

Occurrence Type

An occurrence type is a specialized topic type. Only instances of an occurrence type should be used to type an occurrence.

Palette

The palette provides the functionality of the editor. It contains a set of tools to create new elements.

Perspective

A perspective defines what views are shown in eclipse and where they are located.

Property Details View

The Property Details View contains property pages for every element of an schema and provides input masks to change their properties.

Schema Element

A schema element is an element in the schema like a topic or role type, or any constraint added to the schema element.

Role Constraint

A role constraint specifies, which role type and cardinality belongs to an association type. This means any association of that type must have a number of roles within the range specified in the constraints cardinality.

Role Type

A role type is a specialized topic type. Only instances of a role type should be used as roles of association.

Subject Identifier Constraint

The subject identifier constraints specifies the number of identifiers a topic type may have. It also has a property which defines the syntax of the identifier with a regular expression.

Subject Locator Constraint

The subject locator constraints specifies the number of locators a topic type may have. It also has a property which defines the syntax of the locator with a regular expression.

TMCL

The Topic Maps Constraint Language is the specification of the schema language for Topic Maps. See http://www.isotopicmaps.org/tmcl for more information.

TMDM

The Topic Maps Data Model is the specification of the standard Topic Maps. See http://www.isotopicmaps.org/sam/sam-model/ for more information.

Topic Maps Schema

A Topic Maps Schema is a description of the form of a topic map. It consists of topic type and constraints.

Topic Maps Schema Element

Topic Maps schema element is simply a part of the schema. This may be any constraint or topic type (and its specializations).

Topic Role Constraint

A topic role constraint specifies which topic type is the player of an association of a specific association type. It also specifies which role it plays. This constraint also specifies the number of players playing the role.

Topic Type

A topic type is a topic which is used in a type-instance relationship. Types are defined in a Topic Maps schema and the instances are created in the topic map.

Update Site

An update site is a web page containing eclipse features. Features can be installed via the install dialogue of Onotoa. If a new version of an installed feature is available on an update site, Onotoa will realizes and offer an update.

Widget

A widget is a visual element of an application, e.g. windows, buttons, text fields, tables and combos.