OWL-DL: property restrictions and/or domain-range?

Question

I have a doubt regarding the proper way to use domain, range and restrictions to define an ontology. If I want to represent that “a student must have only one identification,” I think that I could do one of the following:

1. Define the domain and range for the property (for example, :hasId rdfs:domain :Student; rdfs:range :Identification ) and make the property functional.

2. Define the property and create a restriction in the student class: “hasId exactly 1 Identification”.

In terms of semantics, do these mean the same thing? If so, is there a preferred option in terms of conventions or best practices? Lastly, does the same apply for datatype properties? Can I simply define the domain/range and/or should I create restrictions in the class to link it with the property?

Answer 1

OWL2 has quantified restrictions, which means that you can have class expressions of the form

∃pC

which denotes the class of individuals that have a value for the property p that is of type C . Similarly you can use the restriction

∀pD

which is the class of individuals all of whose values for property p (there might not be any, though) are of type D . There are also numeric restrictions, so that you can specify a minimum number of values, a maximum number of values, or an exact number of values.

≤ n pC
≥ n pC
= n pC

You can also have axioms that declare the domain and range of a property. Eg, if you have the axiom

p has domain C

then anything that is related by p to something else must be a C . Similarly, if you have the axiom

p has range D

then anything which is to which something is related by p must be a D . It's interesting to note that the range axiom can actually be recast as a subclass axiom involving a universal restriction. You can write p has range D as

⊤ ⊑ ∀pD

which says that ⊤ (or owl:Thing , ie, everything) is such that every one of its values for p must be a D . By using inverse properties, you can get domain axioms as well. p has domain C is equivalent to

⊤ ⊑ ∀p ^-1 .C

All that is a bit of background for the answers to your questions:

If I want to represent that “A student must have only one identification”, I think that I could:

1. Define the domain and range for the property (for example, :hasId rdfs:domain :Student; :hasId rdfs:range :Identification) and make the property functional.

2. Define the property and create a restriction in the student class: “hasId exactly 1 Identification”.

So, in terms of semantics is this the same? If it is the same, is there a preferred option in terms of conventions or best practices?

First, these are not the same. Option 1 will ensure that any time you have

x hasId y
x hasId z

you'll be able to infer that x is a Student, that y and z are Identifications, and that y must be the same as z (because the property is functional), but you don't have the ability to infer that every student has an identification. Declaring a property to be functional in OWL says that each individual has at most one value for the property, ie, no value, or one value. It's actually equivalent to a maximum cardinality restriction. Saying that hasId is functional is the same as saying

⊤ ⊑ ≤1 hasId.⊤

Your second option is the better bet. If you want to say that students have exactly one identification, then you can can be explicit and assert

Student ⊑ =1 hasId.Identification

There is a bit of redundant information here, though, if you've declared that the domain and range of hasId are Student and Identification, respectively, because you already know that every thing that is the object of a hasId assertion is an Identification, you could equivalently say

Student ⊑ =1 hasId.⊤

I think the best option here is to be a bit more permissive with your domain and ranges, and a bit more explicit with your subclass axioms. After all, non-students can generally have identifications (eg, a driver's license), and students can actually have more than one identification (eg, a student ID and a driver's license). In light of that, you might do something like this, then:

Classes

• Person
  • Student {⊑ =1 hasId.StudentIdentification}
• Identification
  • StudentIdentification

Properties

• hasId {domain: Person, range: Identification}

(Even this has some issues, since a student could be a student at multiple schools, but that's a separate issue.)