OWL how can I know if something should be class or instance?

Question

I am trying to build an Ontology to represents properties (assets), the property should have a type such as villa or apartment ...

My question is that I don't know if villa and apartment should be classes or instances. how can I know ?

I am thinking of having a class called Property and a relationship called isTypeOf and a class called PropertyType, which has two instances apartment and villa. is that correct please? or I should make Apartment and Villa as classes that are subclass of PropertyType class?

Answer 1

I think, you are combining two distinctions here, that you might want to argue for separately:

1. When should I use subclassing and when should I use property references?
2. 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.

Answer 2

RDF, RDFS and OWL have the necessary t-box terms. OWL DL by default is based on Description Logic which draws heavily from Set Theory, so its natural strengths are on using classes, intersections, and unions for describing things.

Having said that, I you prefer to model using slightly softer/looser semantics and want to use taxonomies (enumerations) then how about looking at SKOS to help facet stuff if you don't know enough about your domain.

Using SKOS, you can create ConceptSchemes that include various classes that described as broader/narrower to other Concepts and ConceptScheme. Furthermore it is completely compatible with OWL