We’ve been working with two clients lately, both of whom are using an ontology as a basis for their SOA messages as well as the design of their future systems. As we’ve been building an ontology for this purpose we became aware of a distinction that we think is quite important, we wanted to formalize it and share it here.
In an ontology there is no real distinction that I know of between a class and a category. That is: classes are used for categorizing, and you categorize things into classes. If you wanted to make a distinction it might be that category is used more in the verb form as something you do, and the class is the noun form.
Categories and Classes in traditional apps
But back in the world of traditional applications there is a quite significant difference (although again I don’t believe this difference has ever been elaborated). In a traditional (relational or object oriented) application if you just wanted to categorize something, (say by gender: male and female) you would create a gender attribute and depending on how much control you wanted to put on its content you would either create an enum, a lookup table or just allow anything. On the other hand if you wanted behavioral or structural differences between the categories (let’s say you wanted to distinguish sub contractors from employees) you would set up separate classes or tables for them, potentially with different attributes and relationships.
We’ve been studying lately what drives the cost of traditional systems, and getting this category/class distinction right is one of the key drivers. Here’s why: in a traditional system, every time you add a new class you have increased the cost and complexity of the system. If you reverse engineer the function point methodology, you’ll see that the introduction of a new “entity” (class) is the single biggest cost driver for an estimate. So every distinction that might have been a class, that gets converted to a category, provides a big economic payoff.
It’s possible to overdo this though. If you make something a category that should have been a class you end up pushing behavior into the application code, which generally is even less tractable than the schema. So we were interested in coming up with some guidelines for when to make a distinction a category and when to make it a class.
Category and class in gist
As it turns out, we had foreshadowed this distinction, although not for this reason, in gist, our upper ontology. Gist has a class called “category” whose intent is to carry categorical distinctions (from one lower level ontology to another) without necessarily carrying their definitions.
For instance when we worked with a State Department of Transportation, we had a class in their enterprise ontology called “Roadside Feature.” A Roadside Feature has properties such as location and when by what process it was recorded. Several of their applications had specific roadside features, for instance “fire hydrants.” In the application fire hydrant is a class, and therefore is one in the application ontology. But in the enterprise ontology “fire hydrant” is an instance of the category class. Instances of fire hydrant are members of the roadside feature class at the enterprise ontology level, and associated with the category “fire hydrant” via a property “categorizedBy.” A fire hydrant can therefore be created in an application and communicated to another application that doesn’t know the definition of fire hydrant, with almost no loss of information. The only thing that is lost on the receiving end is the definition of fire hydrant, not any of the properties that had been acquired by this fire hydrant.
Category and Class a formal distinction
So we came to this: a category is an intensional set with criteria for defining membership. A class is an extensional set where membership is explicitly asserted and specific properties can be defined as necessary
In an ontology these two definitions can, and almost always do, overlap. But in a traditional system they don’t. In a traditional system the overlap is “the excluded middle”
This is helpful for us if we’re using our ontology to
generate artifacts for traditional systems, but on closer inspection we’re
finding interesting use even in ontology driven systems. The area in the class rectangle outside the
category box is essen
tially the primitive classes, those that can not be
defined in terms of other classes and properties. The intersecting region are classes that are
formally defined, and therefore we could infer membership. And the category outside class is something
where we accept that a distinction has been made, we may know the sufficient properties,
but we don’t necessarily know any other
necessary properties. Nor do we need to
know how the individual got categorized.
In an ontology, we focus most of our effort on the intersection
As these are the classes that have formal definitions. But if we think deeply about it, what we are d
oing when we define a class and give it a formal definition is: we name a class and say it is equivalent to a restriction. The two things we traditionally haven’t focused on are classes with
out
definitions (primitive classes) and categories without classes (many instance based taxonomies fit this pattern).
Our initial work suggests that this is a key pattern for getting large constellations of ontologies to work together. Feedback, comments, brickbats all welcome.
Hi Dave. Can you give (or point to) an example of how you can use this pattern to get large constellations of ontologies to work together?
Posted by: Mark Wallace | August 25, 2008 at 06:49 PM