Domain and range for ontological properties are not about data integrity, but logical necessity. Misusing them leads to an inelegant (and unnecessary) proliferation of properties.
Logical Necessity Meets Elegance
Screwdrivers generally have only a small set of head configurations (flat, Phillips, hex) because the intention is to make accessing
contents or securing parts easy (or at least uniform). Now, imagine how frustrating it would be if every screw and bolt in your house or car required a unique screwdriver head. They might be grouped together (for example, a bunch of different sized hex heads), but each one was slightly different. Any maintenance task would take much longer and the amount of time spent just organizing the screwdrivers would be inordinate. Yet that is precisely the approach that most OWL modelers take when they over-specify their ontology’s properties.
On our blog, we once briefly discussed the concept of elegance in ontologies. A key criterion was, “An ontology is elegant if it has the fewest possible concepts to cover the required scope with minimal redundancy and complexity.” Let’s take a deeper look at object properties in that light. First, a quick review of some of the basics.
- An ontology describes some subject matter in terms of the meaning of the concepts and relationships within that ontology’s domain.
- Object properties are responsible for describing the relationships between things.
- In the RDFS and OWL modeling languages, a developer can declare a property’s domain and/or its range (the class to which the Subject and/or Object, respectively, must belong). Domain and range for ontological properties are not about data integrity, but logical necessity. Misusing them leads to an inelegant (and unnecessary) proliferation of properties. Avoiding Property Proliferation 2
Break the Habit
In our many years’ experience teaching our classes on designing and building ontologies, we find that most new ontology modelers have a background in relational databases or Object-Oriented modelling/development. Their prior experience habitually leads them to strongly tie properties to classes via specific domains and ranges. Usually, this pattern comes from a desire to curate the triplestore’s data by controlling what is getting into it. But specifying a property’s domain and range will not (necessarily) do that.
For example, let’s take the following assertions:
- The domain of the property :hasManager is class :Organization.
- The individual entity :_Jane is of type class :Employee.
- :_Jane :hasManager :_George.
Many newcomers to semantic technology (especially those with a SQL background) expect that the ontology will prevent the third statement from being entered into the triplestore because :_Jane is not declared to be of the correct class. But that’s not what happens in OWL. The domain says that :_Jane must be an :Organization, which presumably is not the intended meaning. Because of OWL’s Open World paradigm, the only real constraints are those that prevent us from making statements that are logically inconsistent. Since in our example we have not declared the :Organization and :Employee classes to be disjoint, there is no logical reason that :_Jane cannot belong to both of those classes. A reasoning engine will simply infer that :_Jane is also a member of the :Organization class. No errors will be raised; the assertion will not be rejected. (That said, we almost certainly do want to declare those
classes to be disjoint.)
Read More and Download the White-paper
White Paper by Dan Carey
