Part 1 & Part 2
We just conducted a weeklong training session on OWL/DL and Ontology Engineering. Several of the participants will be attending the Semantic Technology Conference, and felt they will be getting a lot more out of the conference, because of the training. On drilling down a bit further, we found that the main benefit in this regard was breaking down their pre-conceived ideas of what semantics is. They were several days into the training before they were deprogrammed enough to completely follow what was going on.
In this blog, and perhaps the next couple, I want to summarize some of these preconceptions, and some ideas that will at least make you aware of them, and may help you get more out of the conference, or any other studying you may be doing in the area. We call this “Zen Mind” from the Zen masters belief that to really learn you have to get as many of your preconceived ideas out of your head long enough to establish some new patterns. I believe the Zen Masters called it “beginners mind” (perhaps they thought Zen Mind was too promotional).
In that spirit, let us offer up some preconceived ideas and the “koans” that seem to best address them.
Preconceived idea #1: Properties belong to Classes
People from a relational background make the partially correct analogy between relational attributes and semantic datatype properties and between foreign key relationships in relational and object properties in semantics. However, this analogy will bite you. Repeatedly, as our students demonstrated.
They had a tough time remembering that the same property can be associated with many different classes. They were so used to each property being unique, that when they did associate the same property with more than one class, they gave it different names (locatedIn, became locatedInState, locatedInCountry etc).
The koans we decided were most useful in this case were two:
• Classes are really “sets” (to help get past the idea that classes are some sort of template, as they are in relational and Object Oriented technologies. This seems to help overcome the temptation to believe that the property belongs to the class)
• Properties own classes (when you define a restriction class in OWL/DL, what you have really done is use a pre-existing property to create a set of instances that have “someValues” from that property. It is the property that gives rise to the class, and therefore is more useful to think of the properties owning the classes – at least compared to the classes owning the properties)
So, if you find yourself relapsing into relational thinking, just repeat the two koans until the symptoms disappear.
Multiple Inheritance v. Multiple Classification
Koan: MI is almost always Intersection
Koan: MI makes sets smaller, does not make capabilities larger
Preconceived Idea # 2: Multiple Inheritance
If you come from an Object Oriented background, in particular one that supports multiple inheritance, you might find an apparent similarity between multiple inheritance in OO and having a class be subsumed by two others. However, if you try this out, you’ll realize you’re not getting what your expecting. This is because the semantics are different. In OO there are really two things going on at the same time: subtyping and inheritance. The inheritance piece is giving you properties from both of your parents. If one parent had the “foo()” method and the other parent had the “bar()” method, the child now has both. The child has all of the attributes, and all of the behaviors of both parents. The child is essentially the union of the behaviors of the two parents. Semantics is not dealing with behavior, it’s dealing with typing, membership and classification.
So, take a couple of koans and call me in the morning:
Subclassing from two classes makes you the intersection, not the union of the two If a class A is a subclass of class B and class C, all members must be members of both parents. This is the intersection of the two parents, not the union. It is really a subclass of the intersection, but we’ll do that on another post.
Multiply classify an instance – The power in semantics lies in the ability to classify an instance multiple ways. This gets at what most OO people want to do with MI, and it’s far more flexible.
