Classes / instances in Ontology

Question

Hi, I'm trying to comprehend ontology basics. Here's an example:

• car (class)
• 2009 VW CC (sub-class or instance?)
• My neighbor's 2009 VW CC (instance)

My issue is understanding what is "2009 VW CC" (as a car model). If you're making product model a sub-class in the ontology - all of a sudden your ontology becomes bloated with thousands of subclasses of a "car". That's redundant. At the same time we can't say "2009 VW CC" is an instance, at least it's not material instance of a class.

Does it make sense to distinguish between regular instances and material (distinct physical objects)?

At the other hand, if both are instances (of different nature so to say), then how can instance inherit properties / relations of a non-class?

Answer 1

You have it backwards.

2009 VW CC inherits from the class car. Thus 2009 VW CC needs to know about car, but car doesn't need to know about 2009 VW CC. Though we do occasionally use the term "subclass" in reality, car knows nothing about any of its subclasses.

What's more interesting is if you consider prototypal inheritance (like in javascript), where objects inherit directly from other objects (imagine if your 2009 VW CC inherited the aspects of your neighbor's 2009 VW CC). In reality how this is implemented is that new object have a secret pointer back to the object they inherited from. If you think about this secret pointer you can see how the originating object doesn't become bloated.

Now if you're suggesting that multiple inheritance and long family trees can lead to confusing structures, then I would agree with you.

Answer 2

I hate to say it depends, but it depends.

If you need to model every single car in the world, and have methods that you can call on them (like "change tyre", which is a process that is very different for each model) then yes, you are going to have a lot of bloated classes, because your real world situation is bloated too.

If you just want to have a database of pictures of archetypal cars, and you don't car whether it is a picture of your neighbour's instance or your sister's instance, then you can drop the bottom layer. "2009 VW CC" could well be an instance, even though you can visualise that it is also a class in another model.

Alternatively, maybe you don't need to make it a true subclass at all. A simple reference might be sufficient. For example, an insurance company knows about a large list of car models and years, but the developers don't write one subclass for each. Instead, they have a database of car models, where one row may represent 2009 VW CC. When you insure your car, they create an instance of "Insured Car" with a reference to the "2009 VW CC" instance.

This doesn't strictly follow the "Use inheritance for a 'is-a' relationship", but the operations on all the car types are identical - it is just the parameters (e.g. insurance price per annum) that change, and new car models are recorded in the database, not in the code.

An assumption here is that you can model the differences between the difference models as merely parameters to the same methods on car.

(Aside: When the iPhone started becoming available through phone company web sites, I noticed that it broke their class models - their web-sites seemed to handle dozens of brands and models of phone on one page - presumably using a simple database of phones and their features - and then needed a special page to handle the iPhone models, presumably because new special methods were required on their classes to support some aspects of the iPhone sale. Automated sales desks would say "Press 1 to buy a phone. Press 2 to buy an iPhone.")