Modelling RDF item features as subclasses or as references to other individuals

Question

I'm wondering what are the implications (i.e., benefits and drawbacks) of modelling RDF item features as:

1. classes (i.e., individuals belonging to a subclass)
2. individuals referring to another abstract individual representing a feature.

I don't want to use data properties. I need to represent clear concepts with their IRIs.

Example type 1

@prefix : <http://example.org#> .

:Car a rdfs:Class .
:Subaru rdfs:subClassOf :Car .
:Mercedes rdfs:subClassOf :Car .
:Ferrari rdfs:subClassOf :Car .

:c1 a :Subaru .
:c1 a :Mercedes .
:c1 a :Ferrari .

Example type 2

@prefix : <http://example.org#> .

:Car a rdfs:Class .
:CarModel a rdfs:Class .

:Subaru a :CarModel .
:Mercedes a :CarModel .
:Ferrari a :CarModel .

:c1 a :Car ;
    :model :Subaru .
:c2 a :Car ;
    :model :Mercedes .
:c3 a :Car ;
    :model :Ferrari .

Excuse me if this question could sound too broad. I'm aware there is any silver bullet in those cases and I'm trying to understand what are the implications of such different modelling strategies.

Answer 1

This is a conceptual modeling question that is not unique to RDF or OWL but applies very generally. As you say yourself, there's no single correct answer. However, there are some criteria that may help you decide one way or the other.

First, ask yourself if the property being modeled is an intrinsic property of the individual? Phrased slightly differently: is it necessary for any individual to have this property, or can there be individuals that don't have it? If the property is intrinsic, this is a point in favor of using sub-classes. In your example, arguably the property is intrinsic: no car can exist without being some model. Or to take a different example: no mammal can exist without being one of its specific sub-types (giraffe, mouse, dog, and so on).

Second, and closely related: is the property immutable? That, can the value of this property change over time for any individual? If it can change, that's a point in favor of using properties instead of subclasses. In your example, the car's model is likely immutable (so this is another point in favor of using subclasses), but if you were to add, say, the color of each car, that's possible to change (with a decent paint-job), which makes that a candidate for using properties (along with the fact that color is perhaps not an intrinsic property, if you consider that a car without a coat of paint is still a car).

Both of these criteria are entirely conceptual, and mostly deal with questions around how well your ontology reflects "the real world". Arguably this is important in terms of reusability and understandability of your domain ontology. Other considerations may be more practical and deal with things such as the kinds of queries you're likely to ask, which of the two modeling approaches results in the smallest possible dataset (in terms of number of statements), etc.