Intro

This blog post is part of a series on Web Application Development with Ontopia.

1. Part 1: Installation & Requirements
2. Part 2: Creating the Database
3. Part 3: Creating the JSPs

In part 1, we looked at how to set up Ontopia. We also described the application that we intend to build (a blog) and what we need to develop in order to achieve our goal.

This time we’ll look at how to set up the “database schema” and create new blog posts by using Ontopia’s web interface. The resulting topic map can be browsed here.

Ontopoly

As mentioned in Part 1 of this series, Ontopoly is Ontopia’s  built in editor.

Since Ontopoly is a general purpose topic map editor we don’t have to create a specialized database schema for our blog application. We simply create and populate a topic map (think of it as our database) using Ontopoly.

Because we’ve already defined our model, all we need to do in order to get started is to open Ontopoly in a web browser and start typing.

The boxes in the illustration above represent classes of objects while the arrows represents relationships between different classes; for instance the fact that every post is written by a person. In this particular relationship the person is the author of the post. We also know that the classes have specific kinds of attributes attached to them, such as the `Publish Date’ of a blog post.

Some terms

When dealing with topic maps, we call the classes (`Person’ and `Post’, for instance) topics, the `Publish Date’ an occurrence, the `written by’ relationship an association and `author’ a role (played by person). Associations are like relational tables of relational databases, but with some extra information added (explicitly to the model).

A particular blog post is called an instance of the blog post concept – kinda like objects are instances of classes in object-oriented programming.

The rest of this entry will show you how to create the different kinds of concepts using Ontopoly. If you want to know more you really should look into Steve Pepper‘s The TAO of Topic Maps.

Also, please be aware that Ontopoly is a general purpose topic map editor and as such its interface can sometimes feel a bit messy (in my opinion, at least). Once you get familiar with it makes creating topic maps a breeze though — and if you’re a developer you can always create more application specific interfaces on top of it

Creating the Topic Map

The steps involved in creating the topic map which will act as our database are:

1. Start Ontopia (see “Setting up Ontopia“).
2. Open http://localhost:8080/ontopoly/ in your favorite web browser (hopefully not IE).
3. Create a new topic map by typing something (for example “Blog Topic Map”) into the name field of the “Create New Topic Map” form.
4. Hit the Create button.

The topic map will now be created and the resulting screen should look somewhat similar to the screen-shot below.

From here, we have to create the items that make up our model.

Defining Attributes

I always find it easiest to start off by creating the data fields or attribute types, i.e. the different kinds of information items that can be attached to our core concepts – such as `excerpt’ and `publish date’ for blog post, `description’ for categories, etc.

In topic maps lingo these are called occurrences and we specify the different kinds of occurrences that might exist in our application.

From the requirements in Part 1, we know that we need to define the following attribute types:

• Description (categories — and possibly other stuff as well)
• Excerpt (blog posts)
• Body (blog posts)
• Publish Date (blog posts)
• Created Date (blog posts)

The Title attribute for the blog and individual blog posts will be modeled as a name type (more on that below).

Creating Occurrence Types

Here’s how to create an occurrence in Ontopoly:

1. Move to the Occurrence Types page (see screen shot below).
2. Type the name of the new occurrence type into text field of the “Create New Occurrence Type” form.
3. Click Create.

This will create the new occurrence type and redirect to a new page.

The resulting page lists information that can be attached to the new occurrence type. You’ll see that the Name is already populated using the value that you provided in the previous step.

Now enter data for the remaining fields: Subject Identifier (a URI-identifier of our type), Name (this seems superfluous or at least confusing to me — what’s the point, Ontopians?).

Afterwards, click the “Save” icon in the top right corner if you want to be absolutely sure your changes are saved (strictly speaking, this is not necessary as Ontopoly will save the information in the background).

Note that it is a good idea to always add Subject Identifiers (SIs) to types so that you can easily refer to them later on – for example in queries (an even better idea would be to use Published Subject Indicators (PSI) instead of bogus URLs like I’ve done in the example above).

Now repeat the above steps for each of the remaining occurrence types that are listed above.

Creating the Title (Name Type)

Without going into details, one thing that is worth noting about Topic Maps is that names have been given a special role. The names of things are thought of as quite important.

Names can even be typed. That is, there are different kinds of names out there. This does for instance apply to the Title that we use for our blog and blog posts. The title of a blog post is really the name of said blog post AND it does also differ from the name of a person.

We represent the title by creating a name type called Title which will be added to the Blog and Blog Post types later (see below).

Create the name type by moving to the Name Types page. Enter “Title” into the text box and click Create. Feel free to use “http://purl.org/dc/elements/1.1/title” as Title’s Subject Identifier (this tells topic maps applications that our title represents the same concept as the Title that has been defined by the Dublin Core Metadata Initiative).

Defining Classes

As soon as we have created our occurrence types, we’re ready to create the classes of things that will be used in our application. In topic maps terms, these are called Topic Types and represent the kinds of topics that may exist in our application / model.

The procedure for creating Topic Types is more or less identical to what we did for the occurrence types above.

The list of topic types that we have to create are as follows (squares in our illustration):

• Blog
• Blog Post
• Person (i.e. authors)
• Category
• Tag
• Status (draft/published)

For each of the topic types, we register the occurrence types that are to be used on the particular type. By doing so, we ensure that all instances – i.e. all blogs (instances of Blog), all blog posts (instances of Blog Post), etc. – that we create can or will have the correct kinds of attributes set.

For example that all blogs can have a description or that all blog posts may have  a publish date. This is similar to creating a domain model in a programming language like Java or PHP, but there is a higher level of flexibility here as we can easily change our model by adding/removing concepts.

Creating Topic Types

Let’s have a look at an example; creating the Blog topic type.

1. Move back to the Topic Type page.
2. Locate the “Create new Topic Type” form and enter a name, e.g. “Blog”.
3. Click create
4. Enter data for Subject Identifier.
5. Associate the topic type with the correct name type, if applicable (Title for Blog and Blog Post).
6. Associate the topic type with the correct occurrence types; “Description” for blog.

Screen shots are provided below.

If you’re a mere mortal like myself, there are some things that might confuse you at this point (unless I’ve already done a good job at that).

1. The description field that shows up is not the same as the “Description” occurrence type that you added to the type.
2. Adding fields like names and occurrence types might be cumbersome.

The description field does not state that all Blogs should have a description, but is rather meant for a description of the concept (Blog) itself. If you want all blogs to have a description, you have to assign the occurrence type “Description” to the Blog topic type.

When you add fields like occurrence types to your topic types you first have to make them visible by clicking the actual text “Occurrences” describing the field type that you want to add. You may then associate the field with the given topic type by clicking the small icon to the left of the field that you are adding (highlighted in screen-shot #2 below).

Clicking the name of the field will bring you to the edit window for the item whose name you clicked – e.g. the Description occurrence type. This might be a logical action to some, but to me it’s quite annoying.

I don’t know how many times I’ve clicked one of these links by mistake, meaning to click that little icon instead (Ontopians: I would assume this violates the primary/secondary navigation principle as the primary action is given less visual emphasis ).

Create the remaining topic types by applying the same procedure for each one of them.

Defining Relations

At the beginning of this post I mentioned (implicitly, at least) that we need two things to get the relationships, or association types, right: the association type itself and the roles played by the different members of the association.

For example the association type written by which represents a relationship between a blog post and a person. The blog post is said to play the role of work while the person is an author.

For the sake of clarity, let’s make another illustration of our model. This time we add the names of our associations to the drawing. We also include role types.

This gives us the following role types:

• Author
• Work
• Broader
• Narrower
• Container
• Containee
• Resource
• Value

And association types (relationship types):

• Blog Has Post
• Written by
• Has status
• Subject
• Broader/Narrower
• Container of

We may start by creating the role types before creating the association types, like we did for the occurrence types that we associated with topic types. Or we can create them as part of creating the association types.

As an example, let’s create the Subject association type. This association is meant to represent the relationship between a blog post and a tag/”subject”. In an association of this kind the tag will play the role of a value while the post is the resource.

These types are based on a vocabulary defined by the Dublin Core Metadata Initivative (DCIM), and we use the following subject identifiers in order to identify the three concepts:

• Subject:

  http://purl.org/dc/elements/1.1/subject

• Resource:

  http://psi.topicmaps.org/iso29111/resource

• Value:

  http://psi.topicmaps.org/iso29111/value

By doing so, we ensure that the meaning behind our association- and role types is conveyed in a formal manner — by being stored as part of our information model.

If we were to exchange our model with other systems, the other systems would be able to infer more from our data based on the fact that we use terms that are “universally” agreed upon.

Creating the Association Type

We create the association type by moving to the Association Type page of Ontopoly. Once there, we once again type the name of our concept – this time it’s “Subject” – into the form. Clicking the create button then directs us to a page for registering the details of our new association type.

As shown in the screen shot above, this screen looks a little different from the others we’ve looked at this far.
The section “Association field” lets you specify the Roles (“role type” drop-down) and players (“used by” drop-down) of the newly created association type.

Since we haven’t created any role types yet we have to do so from this screen. Clicking the icon next to the “Role type” drop down list opens up a new window where we enter the details for the new role type.

Enter the name – “Resource” – and PSI – “http://psi.topicmaps.org/iso29111/resource” – of the new role type and click OK or close window (we’ll enter the remaining information on the main form). Now choose “Blog Post” for “Used By”, “Zero or more” for “Cardinality” and “Browse dialog” for “Interface control”.

Now repeat the procedure for the second “Roles” block; create a role type named “Value” with PSI “http://psi.topicmaps.org/iso29111/value” which is used by zero or more “Tag”.

We then enter a meaningful text into the “Name” field indicating the direction of the association — for example “has subject” for blog post and “subject for” for tag. These are names that can be used in an interface when looking at the association — the proper name can be picked depending on the role player’s type.

Don’t worry if it’s a bit confusing — it will be easier once we create a blog post and you see everything in action. Also, have a look at the screen shot in case that makes more sense than my words.

Feel free to create the rest of the association types, or download a copy of my topic map.

Creating Content

We have now looked into how to build an information model using Ontopoly. With the model – schema if you like – in place, it’s time to finally create some content.

In our case, content is the same as instances. Instances of our types, that is. As an example, you may think of your own car (if you have one) as an instance of the type Car. There’s really not more to it than that.

You may have noticed that in Part 1, I recommend creating a topic type representing the publish status of a blog post, or that we didn’t create an attribute indicating the publish status. The reason why we did not do so is that this is a type that has a fixed number of instances; namely Publish and Draft. We could have represented it using an occurrence type – with values on the individual posts, but it’s somewhat cleaner to represent it using an associations (post <– has status –> published).

Before we create our first blog post let’s create the two possible publish statuses. We do so by moving to the Instances tab in Ontopoly. This page lists all topic types and clicking one of them will bring up a page displaying all instances of the particular type.

If we click Publish Status, we’ll see a close to empty screen that is supposed to list all instances of Publish Status.

By entering the name Published into the text box and clicking create we create the Published instance. We then do the same for Draft. The instances page will now list the two newly created instances.

Creating a Blog and Author

Before we start creating blog posts, we need to create a blog and a person (author). We do so by moving to the Instances tab. From there;

1. Click the Blog link
2. Enter a name
3. Click create
4. Enter an optional description
5. Go back to the instances tab
6. Click the Person link
7. Enter a name
8. Click create
9. Enter an optional description

Creating a Blog Post

We are now ready for the finale: creating our first blog post from Ontopoly. Please remember that this is a general purpose editor and that it’s possible to create more specialized interfaces (like a more sleeker / clean) on top of Ontopia.

Creating a blog post is as easy as creating an instance of the topic Blog Post:

1. Move to the Instances tab
2. Click Blog Post. You’ll now see a screen similar to the screen shot below.
3. Enter the data for the title, excerpt and body.
4. Set a publish date
5. Associate with existing, or create related categories (similar to procedure for creating role types from association type page).
6. Associate with existing or create new related tags
7. Associate with author
8. Associate with blog
9. Set the publish status

One thing you should note and remember is to make sure you always click the little floppy icon on each HTML occurrence whose content you change. If you happen forget to, Ontopoly wont save the text you’ve entered (kinda annoying feature).

You can now browse the topic map in Omnigator; Ontopia’s built in topic map navigator. Every page in Ontopoly has a link which says “Browse this topic in Omnigator” (see e.g. image above). Doing so may help you understand what we’ve just created. Browse the example topic map.

Moving on

Now we’re done setting up the “database” needed for our application. You can view the result in either Ontopoly (obviously) or Omnigator. You may also want to try to add additional instances of each one of the topic types, link them together in Ontopoly and browse the result in Omnigator.

The topic map that I created for this example may be browsed or downloaded.

If you wish, you may also download this blog’s XTM feed, place it into your Ontopia installation’s <install-dir>\apache-tomcat\webapps\omnigator\WEB-INF\topicmaps directory, restart Ontopia (or refresh the sources using the management page) and browse it using Omnigator. Or you may browse a snapshot of it.

The next thing on our list is to create the custom view. More on that later.