Creating an ontology with Relatude CMS

Before you can start to publish any meaningful content you will need to define an ontology for your site. The ontology is the structure or schema to use for your content. In more philosophical terms it defines your world. What concepts you talk about and how they relate.

The Ontology enables semantics

In Relatude we separate between presentation, content and meaning (semantics). This has several advantages and it is this separation of semantics that lays the foundation for our Semantic Web capabilities. You can read more on this this in our article on semantics.

Why is the ontology important?

By having a separate ontology layer we can make knowledge explicit through ontology languages such as OWL. The ontology layer describes and identifies what our concepts mean so we can use that metadata to create services to integrate, federate, share and process the data. The ontology gives a shared understanding and it enables reuse of domain knowledge. Ontologies are the backbone of the Semantic Web. When aligning it with or reusing existing vocabularies you can begin to leverage the semantics and enable third party agents to reason about your data. We have just seen that ontologies are important to enable the Semantic Web. Not everyone needs to share their ontologies. For these organizations ontologies is helpful to visualize and communicate the domain. This makes it easier for the CMS editors and it makes sure the structure of the web site is consistent and intuitive. The ontology layer allows you to alter the model without changing the database or rewriting any code. In many knowledge centric environments knowledge evolve and there are even revolutions where suddenly there is a new understanding of the domain and the entire model has to be changed. In traditional information architectures only a small minute change in a database schema or web service API is enough to cause an entire information system to fall apart.

How is an ontology different from a database schema or DTD/XSD XML schema?

The ontology is usually more high level and entirely tech agnostic while the database or XML schema are often tuned towards performance or in some way designed to encompass some technical system. With a more philosophical view we can make the following distinctions:

How is designing an ontology different from designing a UML model or a class structure in object oriented programming?

They share several similarities but an OOP class is usually more designed based on the operations and purpose it is to perform rather that the structure of the real world. In OOP design you use design patterns such as the mediator, factory, observer pattern etc. etc. to design class structures to deal with such things as the SOLID principles. In OOP classes are designed based on the constraints of the programming language and many classes are simply artificial constructs to make the system more scalable or maintainable. Ontology design is more philosophical and concerned with reuse, sharing and extensibility.

Designing your ontology

Step 1 Acquire domain knowledge

• Assemble appropriate information resources and expertise.
• Find someone who knows the field or domain you are to map. Bring in several stakeholders with different views on the domain.
• Find documentation and other documents that contain information that can be used to describe the domain.
• Look at the intranet, at internal databases etc.

Step 2 Domain and scope

• Decide on the purpose.
• Who is the target group (internally and externally)?
• Who will maintain the ontology?
• How often is the ontology going to change?
• Ask questions. What are relevant questions to ask about our data? E.g. in a tourism domain is it relevant to ask “Where can I go to see indigenous people?” This raise questions such as if places as a concept need to be explicit. What level of granularity of places is needed? Should indigenous people be a separate sub class of inhabitant or a type of attraction? Or is this question out of scope all together?

Step 3 Consider reuse

• Look for overlapping domains/fields/disciplines.
• What other relevant ontologies exists? Look at
• Should we reuse other ontologies? This makes sharing data more effective and more entities will be able to reason about your data but you might also lose some expressivity or the ontology may be too large and result in more work/noise.

Step 4 Flesh out the ontology

• Enumerate terms (classes)
• Perhaps try card sorting. Write down each concept/idea on a card. Organize into piles. Link piles together. Iterate.
• Use singular naming convention. E.g. If your domain is the transportation domain you may add a class named Vehicle. You can then later say “car is a sub type of vehicle” or “Roy’s Aston Martin Rapide is an instance of car”. When you in code load an instance of a class you need to specify its type. By using singular form you make it clear that you are fetching a single item and not a collection.
• Define taxonomy (class hierarchy).
• Use a bottom up or top down approach or both. Bottom up: Start with the most detailed classes and work your way up the class hierarchy.
• When to create a sub class: Subclasses of a class usually (1) have additional properties that the superclass does not have, or (2) restrictions different from those of the superclass, or (3) participate in different relationships than the super classes.
• Define properties (characteristics).
• Adding a new property or class? Create a new class when the distinction is important and you have much to say about the class. Classes are things/concepts you talk about. Properties are characteristics of that concept.
• Define relations and cardinality.

Always use natural spoken language for classes, properties and relations. Do not prefix or use abbreviations.

Step 5 Test

• Populate the ontology with instances.
• Check for anomalies.
• Iterate all the previous steps.

Creating the ontology in Relatude

Adding a class

On the ontology module tab go to the classes tab and hit the ‘New class’-button.

The “Create content class” dialog will appear and you can type the name of your new class and select a content class to inherit from. If you want to create a completely new clean content type select ContentClass as type to inherit from. The Namespace field should match the name of your organization.

Adding a property

Click on a class to be able to edit or add properties of that class. Click the ‘New property’-button.

When the Create property dialog appear enter a name for the property and select the most appropriate type.

You should also add a description to your property. Go to the 'Names'-tab and add a new row.

This description will be visible to editors as a tooltip on the property label in the editor interface while editing content using this class. The same description will also be used when auto generating OWL ontology files etc. in futuere versions of Relatude. 

Adding a relation

Relations between classes can be found on the Relations-tab. Click the “New relation”-button to open the Create new relation page.

On the New relation page you will find the following fields:

• Namespace. Your organizations name.
• Tablename is the name of table as it will be created in the database. A default name for the table is automatically suggested.
• Relation type is the cardinality. Select what type of cardinality you want for you relation one to many of many to many.
• Parents are what types are allowed in the relation on the left side of the relation. We use the words parent and child although relations are usually horizontal. A parent-child relation makes it easier to identify the direction of the relation when on to many cardinality is used. Type the name of one or more classes including the namespace. E.g. “MySpace.MyClass”. If you want to allow several types add more types separated by a newline.
• Children is the types on the other side of the relation.

Once the relation is created do a rebuild of the definition, as shown below.

When the ontology is built go back to create a property for the relation on the class. Similar to the Add property step create a new property. Name it for example with the name of the class on the other side of the relation in plural or you might prefix it with “Related”. Click OK and you will be presented with a new dialog (below) where you have to select what existing relation to use. Here pick the relation that you created a few steps back.

Create a similar relation on the related class. Make sure to choose Content child. To make the relation go live on the website do another Rebuild.

You may now use this relation in your templates forexample with the RelationVisitPropertyControl.

<waf:RelationVisitPropertyControl runat="server"  PropertyName="Restaurant.RelatedCuisine" EnableViewState="false">
    <HtmlStartTemplate>Cuisine:</HtmlStartTemplate>
    <ItemTemplate>
        <a href="?nid=<%# Container.Child.RootContent.NodeId %>"><%# Container.Child.RootContent.Name %></a>,  
    </ItemTemplate>        
</waf:RelationVisitPropertyControl>