n a previous article I showed you how to leverage Semantic Web technology to create a relatively sophisticated sommelier application that recommended wines based on an understanding of wine styles. The application’s understanding of wine was based on a model?a pre-existing ontology of wines and their relationships. As you may remember from my previous article, an ontology is a set of concepts and relationships that can be used by people and computers to reason about a domain. The application extended the ontology through inferencing into a much richer and more complete model.

The sommelier application made a good example, but may have left you wondering how you could accomplish something similar in your own applications, for which there are most likely no pre-built ontologies available. In this article I will show you how to create a basic ontology using the Web Ontology Language (OWL). If you aren’t already familiar with ontologies and haven’t read my previous article then I recommend you do so before reading this one, as I will build on the concepts outlined in it.

Building an ontology can be a slippery slope because the world that we inhabit and attempt to model is complex, dynamic, and perceived in different ways by different people. It is all too easy when trying to model something to end up modeling far more than was truly necessary to solve your particular business problem. The business context for developing an ontology is very important in building one, so here’s a quick description of the application that this article uses to illustrate the process of constructing an ontology.

Introducing the Clothing Store Application

Figure 1. Clothing Storefront: Users arriving at the storefront web page see a list of clothing items available for purchase and a set of categories to navigate in order to further refine their search.

In this article you will see how to build a basic clothing storefront application (see Figure 1) that lets users browse and purchase clothing. This clothing store organizes its inventory by type and by gender. The type hierarchy is fairly straightforward; for example, Levi’s are jeans, which are pants, which are a type of clothing.

The gender hierarchy is a little more interesting because some types of clothing items are specific to a particular gender, whereas others are equally appropriate for both men and women. For example, skirts are worn exclusively by women and ties exclusively by men, so these entire categories of clothing are gender specific. In contrast, jeans belong to a category that includes items worn by either gender; both men and women wear jeans. But even though both men and women wear jeans, they often wear different styles, so that a particular style of jeans may look fine on a woman but wouldn’t be stylish for a man to wear. Yet another case consists of items such as some types of sandals, which can be worn by anybody.

Web clothing stores often present several paths by which users can navigate to the items they intend to purchase. Most common are paths oriented by gender, for example, men’s and women’s clothing. But stores often create top-level links for other common items such as shoes and jewelry. Thus a user interested in purchasing a new pair of shoes could either navigate to the shoes through the men’s clothing path or through the shoes path. To accommodate this flexibility, the store example will need to merge the type and gender hierarchies discussed above, which is where ontologies come into play.

Developing a Clothing Catalog Ontology
I could choose to model this multi-dimensional hierarchy of products by explicitly creating relationships between each item and its corresponding type and gender categories. But this approach would necessitate more upfront work and ongoing maintenance, not to mention exponentially increase in complexity as other dimensions are added. An easier approach is to model the store’s inventory in a single inheritance ontology, as illustrated in Figure 2.

Figure 2. Asserted Class Hierarchy: It’s easier to create, maintain, and infer relationships from this single-inheritance representation of the store’s inventory than to explicitly define each possible relationship.

Figure 3. Inferred Class Hierarchy: Ontologies let you infer information about the domain, enabling richer models such as this, which are simpler to create and maintain.

This simple hierarchy expresses a type-oriented view of the store’s clothing catalog, but doesn’t provide a path to navigate items in a gender-oriented way. By choosing to model the store’s catalog as an OWL ontology (that prescribes semantic meaning for particular types of relationships) you can infer a richer model, as illustrated in Figure 3.

As you can see, new relationships have been added to Figure 3 that provide a navigation path between gender-oriented categories. With this goal in mind, the first step is to develop the type-oriented perspective into the catalog.

Developing the Type-Oriented Hierarchy
I’ll present a step-by-step guide to developing a small ontology such as the clothing hierarchy described here. Because the focus of this article is on developing the ontology itself I won’t delve deeply into the Java code used to query it; you can see more such code in my previous article, or you can download the accompanying source code for this article.

In the spirit of limiting the modeling work to tasks that will provide value from the user’s perspective, it’s useful to start by developing some unit tests upfront. For this example I have added eight clothing items for purchase into the store’s catalog as shown in Table 1.

With this inventory I would expect to be able to execute the following unit tests against the application:

   src/test/java/com/devx/clothing/catalog/CategoryTest.java   ...       @Test       public void testListItems_Clothing()       {           // ensure eight items           Category category =               catalogManager.findCategoryByName("Clothing");           assertEquals(8, category.listItems().size());       }          @Test       public void testListItems_Jeans()       {           // ensure two items of type "Jeans"           Category category = catalogManager.              findCategoryByName("Jeans");           assertEquals(2, category.listItems().size());       }          @Test       public void testListItems_Shoes()       {           // ensure three items of type "Shoes"           Category category = catalogManager.              findCategoryByName("Shoes");           assertEquals(3, category.listItems().size());       }          @Test       public void testListItems_Skirt()       {           // ensure one item of type "Skirt"           Category category = catalogManager.              findCategoryByName("Skirt");           assertEquals(1, category.listItems().size());       }          @Test       public void testListItems_Ties()       {           // ensure two items of type "Tie"           Category category = catalogManager.              findCategoryByName("Tie");           assertEquals(2, category.listItems().size());       }   ...

Note that the tests assert that the number of instances defined in the various categories all roll up to the root clothing category. Now you need to build enough of the clothing catalog ontology to make these tests pass.

An ontology consists of a collection of statements about the domain in the form of “