XML Reference Guide

Last week, I talked about the Semantic Web, a version of today's World Wide Web in which data is understandable not just by people, but also by computers. On the Semantic Web, computerised agents -- author David Brin called them "ferrets" -- can go out and find information not just by what's explicit -- the content that's present -- but also the information that's implicit. That implicit data includes not just traditional "metadata", but also information that defines relationships between objects.

That information comes in the form of an "ontology". An ontology defines classes of "things", and their relationships to each other. For example, the XML Reference Guide weblog is a "blog" that has an "author", which has a "name". Next week, we'll look at Web Ontology Language (OWL) -- no, that's not a typo -- but for this week, I wanted to look at actually developing the ontology. Next week we'll take that ontology and encode it in XML using OWL, so we can see an application called a "reasoner" act on it.

Let's start by talking about the overall "domain" of the ontology. That's the general subject matter we're going to define. Last week I talked about movie theaters, and we could certainly go with that, but since I'm not in charge of the web site or any other data for any theater chains, I thought instead I'd talk about creating an ontology the average person could use.

Well, the average blogger, anyway. That's right, this article details the genesis of the Blog Ontology, an ontology that attempts to define the classes and objects involved in a typical blog. Next week we'll encode that ontology using OWL, and finally we'll look at how to use it to mark up the content of a real blog so that a reasoner can understand the content.

Let's start by defining some of the classes we're going to need. As in object oriented programming, an ontology class is a "type" of object, with various properties. Unlike in object oriented programming, however, ontology classes don't define any methods, just properties and relationships with other classes. (Later, when we have all of our classes, we'll create "individuals", which are instances of a class, just as an object is an instance of an object oriented class.)

The simplest look at this ontology shows the Blog, Entry, Author, Content, Comment, and Trackback classes, along with their relationships:

The first thing to understand here is that there is really only one "thing" we're dealing with, and that's the Blog. (Other ontologies can and do deal with more than one thing, but we're keeping it simple.) Everything else that you see in this diagram, from the Author class to the Trackback class, is a property, or a piece of information about something else.

Let's step back and look at that for a moment. The Blog is written by a specific person, the Author. It has a specific set of Entrys that define its content. Both of these properties are objects, but there are also simpler data properties, such as the title or URL for the Blog. We might consider looking at the Blog like this:

The first two properties, isCalled and hasURI, are simple string values, while the third consists of an Author object, and the fourth consists of zero or more Entry objects. These last two, in turn, have their own properties. In short, the object properties look like this:

The reason for the funny names is that ultimately we're going to use these properties to make assertions about the individual objects we're describing. For example, consider the weblog for this Guide. I could say that:

The XML and Web Services weblog hasAuthor Nicholas Chase.

In some cases, properties are transitive, meaning they can chain. On other words, if A > B and B > C, then A > C. Or in this case:

The XML and Web Services weblog hasContent 

"Yahoo targets Google Web Services API"

and

"Yahoo targets Google Web Services API" hasContent
"Well, it was only matter of time. Yahoo, which lots it's title as the 800 pound 
gorilla of search to Google some time ago, is trying to get it back..."

So if the hasContent property is transitive, then we know that:

The XML and Web Services weblog hasContent 
"Well, it was only matter of time. Yahoo, which lots it's title as the 800 pound 
gorilla of search to Google some time ago, is trying to get it back..."

Being able to figure out that kind of statement is the point of the exercise.

Now, I mentioned earlier that there are some similarities between modeling an ontology and modeling an object oriented system, so it should come as no suprise that ontologies can also have subClasses. For example, while we've been talking about blogs in general, we might want to define a specific kind of blog, such as a Journal, which might be mostly commentary on personal issues, rather than pointing to other sites. We can then define the Journal class as a subClass of Blog.

Another area in which this might come in handy is in the Entry class. Entry is a pretty generic term. What if I wanted to do a search for reviews, or technical advice? We can create several different subClasses of Entry, including Commentary, Advice, and LinkReferral. The structure might look something like this:

In this case, Journal, LinkFest, and TipSheet are all subClasses of Blog, so they have all of the properties of the parent class. Similarly, News, Advice, and LinkReferral have only the properties defined as part of their parent class, Entry. Commentary, on the other hand, has all of the properties of the Entry class plus the additional isAbout property. Review includes two additional properties.

For now, these are the basic structures we're going to encode in OWL.