I think, you are combining two distinctions here, that you might want to argue for separately:
- When should I use subclassing and when should I use property references?
- When should I represent a discrimination at the TBox level (subclassing) and when at the ABox level (property values, instances)?
(1) is more or less the same as the old inheritance or delegation question. And the answers are also more or less the same: Use inheritance when the discrimination is an inherent property of the objects represented, when that discrimination property is central to your knowledge model and when the discrimination property has no independent reason for existence.
On the other hand, use delegation when the discrimination property only adds additional information to your class/object or has sufficient reason to "exist" by itself (i.e. is not completely tied only to the referencing object). In your case: Check, how much information hinges on the PropertyType that is dependent on the PropertyType itself and not on the individual Property. If there are things like "Villas with swimming pools and circular driveways" and that distinction is important and can be re-used, you might consider delegation.
(2) follows along the same lines of functional dependency.
My personal rules of thumb are
- Make it a class if you expected to formulate additional axioms based on the subdivision, i.e. if you need to refer to the subdivided set, if you need to attach data or object properties or if you expect further refinement maybe needed (think
LuxuryApartment or the Garden that can only attach to a Villa and the like).
- Make it a class if you want the ontology to be definite and if new sub-classifications are expected to be rare. But mind that your expectations may be wrong.
- Make it a property if the property value introduces no or very limited functional dependencies and if the distinction is not expected to have any additional properties itself.
However, there is in general not necessarily a correct or wrong.
Pro Classes
If Apartment and Villa are classes then it is easy to formulate additional axioms based on these classes. Hypothetically, for example, only Propertys that are Villas are allowed to have gardens:
(∃ hasPropertyFeature . Garden) ⊑ Villa
If you try to formulate this using a hasPropertyType data property, you end up with something like
(∃ hasPropertyFeature . Garden) ⊑ (∃ hasPropertyType . "villa"^^xsd:string)
which is not only significantly harder to grasp but also slower to reason with. Also, classes can be subclassed i.e. there is a straightforward way for additional subdivisions.
Contra Classes
However, having a hasPropertyType property without additional restrictions allows you to add additional property values purely at the instance level without needing to touch the original ontology.
If townHouse comes a long as a new property type, a class based version needs to change the original ontology's TBox and add a new TownHouse class. While this is usually unproblematic (it is most of the time a conservative extension) it is still a TBox change and you basically need to create a new version of your ontology for such changes.
This is version --however-- becomes less feasible, when the property introduces functional dependencies; see above.
