Classes / Instances in Ontology

Question

I am trying to understand the basics of ontology. Here is an example:

• car (class)
• 2009 VW CC (subclass or instance?)
• My Neighbor 2009 VW CC (Instance)

My problem is understanding what the 2009 VW CC is (like a car model). If you make a product model a subclass of ontology, then suddenly your ontology is inflated with thousands of subclasses of the “car”. It's too much. At the same time, we cannot say that "2009 VW CC" is an instance, at least it is not a tangible instance of a class.

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

On the other hand, if both are instances (of a different nature, so to speak), then how does an example inherit the properties / relationships of a nonclass?

Answer 1

I hate to say that it depends, but it depends.

If you need to simulate every single car in the world, and you have methods that you can call on them (for example, "change the tire", this is a process that is very different for each model), then yes, you are going to have many bloated classes , because your real situation in the world is also bloated.

If you just want to have a database with images of archetypal cars, and you are not a car, be it a photo of your neighboring copy or your sister’s copy, you can reset the bottom layer. "2009 VW CC" may well be an instance, although you can visualize that it is also a class in another model.

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

This strictly does not follow “Use inheritance for the is-a relationship,” but the operations for all types of cars are identical - these are only changes (for example, the insurance price per year) that change, and new car models are recorded in the database, not in code.

It is assumed that you can simulate the differences between difference models as just parameters for the same methods on the car.

(Beyond this: when the iPhone became available through the telephone company’s websites, I noticed that it broke its class models — their websites seemed to handle dozens of phone brands and models on one page — presumably using a simple phone database and their functions, and then you need a special page to process iPhone models, apparently because their classes required new special methods to support some aspects of selling iPhone. Automated trading tables said: “Press 1 to buy a phone n. Press 2 to buy an iPhone. ")

Answer 2

You have it back.

2009 VW CC inherits from the car class. Thus, the 2009 VW CC should know about car , but car does not need to know about 2009 VW CC . Although we sometimes use the term “subclass” in reality, car does not know anything about any of its subclasses.

What's even more interesting is if you are considering prototype inheritance (e.g. in javascript) where objects are inherited directly from other objects (imagine if your 2009 VW CC inherited aspects of your neighbor 2009 VW CC ). In fact, as it is implemented, the new object has a secret pointer to the object to which they are inherited. If you think about this secret pointer, you can see how the original object does not swell.

Now, if you assume that multiple inheritance and long tree families can lead to confusing structures, I agree with you.

Answer 3

I really agree with Oddthinking. Also, if you need car models as classes, "suddenly your ontology gets bloated with thousands of car subclasses," that's not really a problem. Why should it be? You simply define classes instead of individuals, you can have an “abstract” ontology, base classes and a “specific” ontology with classes that represent a specific situation in the real world. This is not OOP, defining thousands of classes that are actually between several instances and classes, it does not matter much, at least conceptually, no one considers this to be "bloated" or strange in some other way. Indeed, they do this all the time in my field (life science, where we usually do not care about P53 proteins in our body, so P53 is a class, although it was also used to model records in a relational database).

In addition, my experience is that tools like Virtuoso seem optimized for the situation of several classes and many cases. In fact, I saw significant performance improvements when I turned millions of classes in Virtuoso into instances. So this is complicated ...