DirectionalObjectProperties

Tip: Directional Object Properties

When defining object properties in an OWL conceptual model, it is often useful to think carefully about the primary direction of the property.

This idea is closely related to a point from Domain-Driven Design (DDD), which we will discuss more in Chapter 13. In DDD, Eric Evans emphasizes the importance of establishing a direction for associations. UML uses the term association for links between objects. In OWL, the corresponding modeling construct is usually an object property. To avoid switching terminology, this tip uses the term object property throughout.

---

➤ Why Direction Matters

Some object properties are naturally many-to-many, and there may not be an obvious primary direction. For many properties, however, one direction is more natural than the other.

For example, consider the property:

has_prime_minister

with:

Domain: Nation
Range: Person

The natural question is usually:

Who is the prime minister of Canada?

rather than:

Which nation is this person prime minister of?

Both questions are valid, but the first one reflects the more natural direction of the relationship. In that case, has_prime_minister is a good primary property, and an inverse property such as is_prime_minister_of can be added when useful.

---

➤ Use Inverses During Conceptual Modeling

In OWL conceptual modeling, it is often helpful to define an inverse property early in the modeling process.

For example:

has_prime_minister
is_prime_minister_of

Defining both directions can help reveal modeling errors. If a person is incorrectly asserted as the value of has_prime_minister, the inverse property gives you another way to notice the problem. In effect, you double your chances of finding errors in the sample data or in the model.

After you have a better understanding of the conceptual model and the sample data, you can decide whether the inverse property is worth keeping in the design model.

---

➤ Choosing the Primary Property

When two object properties are inverses, one should be treated as the primary property. This is the property that represents the main direction of the relationship and is the one you would keep if you later decide to remove the inverse.

As a general rule, the primary property should follow these conventions:

• Use the has_property naming pattern when it is natural and readable.
• Use the is_property_of naming pattern for the inverse property when that is natural and readable.
• Define the domain and range on the primary property.
• Assert values using the primary property.
• Let the reasoner infer values for the inverse property.

These are conventions, not absolute rules. Sometimes another naming pattern is clearer. The goal is readability and consistency, not mechanical adherence to a naming formula.

---

➤ Example: has_pet and is_pet_of

In the People Ontology, the property has_pet points from a person to that person’s pet.

Person --has_pet--> Animal

The inverse property is:

is_pet_of

The primary direction is from the person to the pet:

Alan_Turing has_pet Some_Cat

The inverse can be inferred by the reasoner:

Some_Cat is_pet_of Alan_Turing

In this example:

• has_pet is the primary property.
• is_pet_of is the inverse property.
• The domain and range are defined on has_pet.
• Assertions are made using has_pet.
• The reasoner infers the corresponding is_pet_of values.

This makes the model easier to maintain. If you decide during the design phase that you do not need is_pet_of, you can delete the inverse property without changing the main property definitions or the asserted data.

---

➤ Bottom Line

Define object properties in the direction that best reflects how users and applications will normally ask questions about the domain. During conceptual modeling, define inverse properties when they help you understand, test, and debug the model. Later, during design modeling, you can decide whether each inverse property is still useful enough to keep.