Ontologies

I.What are ontologies ?

An ontology is a way to describe a knowledge domain: the concepts that compose this domain, the properties that characterize them, and the relations between these concepts.
An ontology is composed of two parts : the taxonomy (i.e. the hierarchy) of the classes that compose the domain, and the constraints that describe which kind of associations are allowed between these classes.
The document 'Ontology Development 101: A Guide to Creating Your First Ontology' (by Natalya F. Noy_ and Deborah L. McGuinness, available on the web) gives two good explanations of what is an ontology.
  • Short explanation :
    'An ontology defines a common vocabulary for researchers who need to share information in a domain. It includes machine-interpretable definitions of basic concepts in the domain and relations among them.

    Why would someone want to develop an ontology? Some of the reasons are:
    • To share common understanding of the structure of information among people or software agents
    • To enable reuse of domain knowledge
    • To make domain assumptions explicit
    • To separate domain knowledge from the operational knowledge
    • To analyze domain knowledge'


  • Longer explanation :
    'An ontology is a formal explicit description of concepts in a domain of discourse (classes (sometimes called concepts)), properties of each concept describing various features and attributes of the concept (slots (sometimes called roles or properties)), and restrictions on slots (facets (sometimes called role restrictions)). An ontology together with a set of individual instances of classes constitutes a knowledge base. In reality, there is a fine line where the ontology ends and the knowledge base begins.

    Classes are the focus of most ontologies. Classes describe concepts in the domain. For example, a class named 'wines' represents all wines. Specific wines are instances of this class. The Bordeaux wine in the glass in front of you while you read this document is an instance of the class of Bordeaux wines. A class can have subclasses that represent concepts that are more specific than the superclass. For example, we can divide the class of all wines into red, white, and rosé wines. Alternatively, we can divide a class of all wines into sparkling and non-sparkling wines.

    Slots describe properties of classes and instances: Château Lafite Rothschild Pauillac wine has a full body; it is produced by the Château Lafite Rothschild winery. We have two slots describing the wine in this example: the slot body with the value full and the slot maker with the value Château Lafite Rothschild winery. At the class level, we can say that instances of the class Wine will have slots describing their flavor, body, sugar level, the maker of the wine and so on.
    All instances of the class Wine, and its subclass Pauillac, have a slot maker the value of which is an instance of the class Winery. All instances of the class Winery have a slot produces that refers to all the wines (instances of the class Wine and its subclasses) that the winery produces.

    In practical terms, developing an ontology includes:
    • defining classes in the ontology,
    • arranging the classes in a taxonomic (subclass–superclass) hierarchy,
    • defining slots and describing allowed values for these slots,
    • filling in the values for slots for instances.

    We can then create a knowledge base by defining individual instances of these classes filling in specific slot value information and additional slot restrictions.'


II.Ontologies inside Goozzee

Inside Goozzee, ontologies are implemented the following way :
  • a) The 'Classes' topic is the base of the classes taxonomy. As explained in the section concerning Classes, from this topic starts the tree of classes/instances. Each instance or subclass can inherit properties and documents from its parent class(es), and the inheritance can be multiple, meaning that one instance or subclass may have multiple parent classes simultaneously.
  • b) The ontologies constraints are defined within the association types. As explained in the section concerning Metadata, 'Association Types' is a topic that regroups the possible association types you can use. Each association type is an instance of this Association types topic.
Here's how a constraint is defined, behind the scene (hold-on tight ! it's pretty hard to explain) :

Given an association type named Foo, each class that may be used in an association of type Foo is associated to Foo with an association of type default association type, where Foo has the role 'Used in Assoc. Type', and the class has the role that will be used when applying the constraint to normal topics.

In other words, in each association type, you define the various classes that may be linked using this association type, with their respective role. But don't worry, next section will introduce a very easy way to create and manage constraints.

Once you have defined all the constraints of your knowledge domain, whenever you create an association between two topics, the program will force you into using the association types and roles defined in the constraints, depending on the types of classes you intend to link together.


III.Creating and managing constraints : The Ontology Editor

Since the creation of constraints isn't intuitive at all, a special screen is here to ease up the process : the Ontology Editor. You open this screen via the Display/Ontology Editor menu.

The left side of the screen shows three tabs :
  • your classes hierarchy
  • your roles
  • your scopes
From here, you can create new classes, subclasses, roles and scopes, as well as rename or delete them : right clicking on a class, role or scope brings up a contextual menu showing the possible actions.

The right part of this screen is used to list the constraints and properties associated with a class. Click on a class to display the constraints and properties associated to it.

On the top of the Right Panel, the name of the class being edited is displayed. Below is a notebook, with a tab for displaying its constraints, and another one for editing its properties.

In the constraints tab, some constraints may appear in blue. It means that these constraints are inherited from a parent class (i.e. a class upper in the classes hierarchy). Note that blue - inherited classes cannot be edited nor deleted. They are just displayed to help you see directly what constraints can be applied to the currently selected class. In order to be able to modify these inherited constraints, you must climb the classes hierarchy and select the class where they are defined.

Ontology Editor
In the example below, I selected the 'Publication' class fro my repository. We can see that I have created two constraints : the first one says that a 'publication' can be linked to an 'author', in which case the publication will get the 'published' role the author will get the 'author' role the second one says that two publications may be linked to each other, meaning that one publication is mentioned in the other.
Ontology Editor 2
And a third constraint appears in blue, since it is inherited from the Classes class. It says that one could have a meeting about anything – i.e. any class, including Publication.

Constraint Creation

You can easily create new constraints, by right clicking anywhere in the list of constraints and choose 'Create new constraint' in the contextual menu. You'll get the following new constraint appearing at the bottom of the list :
Ontology Editor 3
The left-hand class will be pre-filled with the class you selected in the classes hierarchy. But you can still replace this class with another one…
From here, just drag and drop classes and roles into your new constraint, click OK, the constraint is created.

Notes :
  • A warning message will popup if you are trying to create an constraint that already exists.
  • A constraint may contain many members, but limit yourself to two or three unless you really know what you do.
  • You cannot select another class in the classes hierarchy as long as you haven't click on either OK or Cancel.
  • Beware that other users will have to relaunch Goozzee to be able to use the constraint you just created..

Constraint Modification

Right-clicking on a constraint allows you to modify it, i.e. modify the roles or classes it uses.

Once you click the OK button to save your modifications, Goozzee will check if some associations were created using this constraint. If so, it will propose you various actions to apply to these existing associations, so that they remain compatible with your modifications. You can choose to :
  • leave existing associations as they are
  • replace them with the 'default association type'
  • delete them
Note that you cannot select another class as long as you haven't click on either OK or Cancel.

Constraint Deletion

Same as constraint modification, right-clicking on a constraint allows you to delete it.
Here, if some associations exist, based on this constraint, you'll have the choice to either delete them or replace them with the default association type.
Note that you cannot select another class as long as you haven't click on either OK or Cancel.

Example

If the whole constraints stuff isn't clear yet, here's a step by step tutorial that should clarify things.

This tutorial will be based on Steve Pepper's Italian Opera Topic Map. If you want try it on your own computer, I advise you to create a new repository (using the configuration dialog that's available from the login screen), and import the Italian Opera Topic Map XTM file into this new repository. You can easily get this XTM file on the Web.

Once this topic map is imported into Goozzee, you'll get a hierarchy of classes similar to the one appearing below. No inheritance is defined among these classes (since inheritance isn't supported by the XTM file format). But anyway, it doesn't matter for this tutorial...
Ontology Editor 4

We're going to define a constraint that says that a region can be linked to a country, where the region has the 'Containee' role, and the country the 'Container' role.

Just open the Ontology Editor, and right click on the empty right-hand panel to create a new constraint.
An empty constraint appears.
Now, in the Classes tab, browse and find the 'Country' class, and drag it into the first member of your constraint.

Do the same with the 'Region' class, and drag it into the second member of your constraint.

Your constraint should now look like this :
Ontology Editor 6

We now just have to assign the roles to our constraint, just the same way : from the Roles tab, browse and find the 'Container' and 'Containee' roles, and drag them to the roles of your constraint. It should now look like this :
Ontology Editor 5

Just click the OK button, and your new constraint is ready for use.

IV.Using constraints

a) when creating a new topic

Let's see how our new constraint applies when creating a new topic.

Search and open the 'Alsace' topic. As you can see, this topic tells us that Alsace is already defined as a region of France and Germany.

Click the 'New' button on the right-hand buttons area, and create a new association (i.e. create a new topic that will be associated to Alsace). For example, create the 'Luxembourg' topic. You can see that the creation dialog that opens limits the list of possible classes to the ones defined in the constraints – in our case, only the 'Country' class since we only defined one constraint. If we hadn't defined any constraint, this same dialog would have allowed us to create a topic of any class, but as soon as one constraint exists concerning a class – here the 'Region' class – , we are forced to respect it, unless we decide to create a topic that isn't a instance of any class (by clicking th 'No specific category' toggle button).

You can also see that the role proposed by the creation dialog is the one we had defined in the constraint ('Container').

Once this Luxembourg topic is created, right-click on the button we just added in the right-hand buttons area, and select 'Modify association'. In the windows that appears, you'll see that the association type and the roles of the two members have been set to the ones we had defined in the constraint.

b) when creating a new association

When linking two already existing topic, various situations can occur :
  • Linking two topics for which a constraint exists
    In such a case, the existing constraint will be enforced, and the association will automatically be created according to this constraint.

    For example, go to the 'Alsace' topic; then open the search window and search for the 'United Kingdom' topic. Finally, drag'n drop 'United Kingdom' onto the right hand buttons area of the 'Alsace' topic. Since 'United Kingdom' is defined as country, and 'Alsace' as a region, whatever the place where you drop it on this button area, it will always create the same association, respecting the constraint we had defined previously.

    If multiple constraints exist, that could apply to the association you are about to create, a popup window will appear, asking you to choose the kind of association you want to create – i.e. which constraint you want to apply.
  • Linking two topics for which no constraint exists
    If both topics are instances of some class, Goozzee will try to find a constraint corresponding to these two topics. But if it can't find any, a default association will be created between the two topics (i.e. an association of type 'Default association type' where each member has the 'See also...' role). So here, we bypassed the constraints.
  • Linking topics that aren't instances of any class
    When you try to create an association where at least one of the members isn't an instance of any class, then no constraints will apply, and no warning message will be displayed. To test it, search for the 'Root' topic, and drop it onto the right-hand button area of the 'Alsace' topic. A default association will be directly created. No check for constraints.... Such a behavior is intended for users who don't want to use Goozzee's classes system. This way, they can create associations, without being bothered with warning messages they do not care for.

c)when modifying an association

When you modify an association, the constraints don't apply anymore (at least for now…).For example, if we right-click on the 'Luxembourg' button we previously created, and modify the association, we'll be able to choose from all the available roles and association types, without any restriction. There won't even be any warning when we try to save our modifications...