What is the difference between DatatypeProperty, ObjectProperty, & FunctionalProperty, and when should I use them?
When writing an ontology, there are several very commonly used types, including:
- DatatypeProperty
- ObjectProperty
- FunctionalProperty
- InverseFunctionalProperty
The first three kinda look like they'd be used in a particular set of ways, but I find my idea of them being challenged by how I've seen them used in FOAF.
When should each of them be used or not be used?
Answer
The first two of these, DatatypeProperty and ObjectProperty, describe what kind of values a triple with the property should have. Datatype properties relate individuals to literal data (e.g., strings, numbers, datetimes, etc.) whereas object properties relate individuals to other individuals. Something like hasAge would typically be a datatype property, since an age is a number, but hasMother would be an object property, since a mother is another individual.
The last two of these, FunctionalProperty and InverseFunctionalProperty, are used to put some constraints on the values of properties for individuals. That something is an functional property means that a given individual can have at most one value for it. Logically, this means that if p is a functional property, then
∀ x, y, z.( [p(x,y) &wedge p(x,z)] &rightarrow y = z )
Since OWL does not make the unique name assumption, a different IRI can refer to the same individual, so if hasMother is a functional property, we can infer from
:John :hasMother :Margaret .
:John :hasMother :Peggy .
that
:Margaret owl:sameAs :Peggy
Of course, this can also be used to provide some "negative inference," too. If we know that Susan is a different person than Peggy, then we can infer that Susan is not John's mother. I.e., from
:John :hasMother :Peggy .
:Susan owl:differentFrom :Peggy .
that it's false that
:John :hasMother :Susan .
For datatype properties, this works the same way, but there's much more built in information about which literals are different. E.g., a reasoner should know that "1"^^xsd:int is different from "2"^^xsd:int.
Inverse functional properties are similar, but in the reverse direction. If a property p is an inverse functional property, then for a given individual y, there should be at most one x such that p(x,y).
However, there is a slight caveat here. OWL 2 DL only supports inverse functional object properties, not inverse functional datatype properties. While we can describe the semantics that an inverse functional datatype property would have as ∀x,y,z ( [p(x,z) &wedge p(y,z)] &rightarrow x = y), we cannot have the equivalence between the conditions that
p is an inverse functional property
and that
p-1 is a functional property
because datatype properties cannot have inverses. This arises from the fact that RDF (at least in the current versions; I've heard that there's talk of changing this, though I don't know whether the change would ripple out to OWL) does not allow literal values as the subjects of triples. If datatype properties had inverses, we would have this situation:
:hasName owl:inverseOf :nameOf .
:john :hasName "John"@en .
and we'd infer
"John"@en :nameOf :john . # Not legal.
This means that a inverse functional property must be an object property.
(In OWL Full, a reasoner could use the logical assertion and make the appropriate inferences there, I guess, based on the logical representation. Alternatively, some reasoners, e.g., jena's rule-based reasoners) remove the "no literals allowed as subjects" restriction from their internal representations, and then filter the results on the way out to make sure that illegal-RDF doesn't escape.)
Now, let's look at the cases you mentioned:
gender (functional and datatype)
This is functional, because we expect each individual to have at most one value for the gender property. It's a datatype property because the designers of FOAF expected the values to be something like "male" or "female". If they had defined some symbolic constants, e.g., <http://.../MALE> and <http://.../FEMALE>, then this could have been an object property.
mbox (inverse functional and object)
mbox is an object property, presumably because its values are IRIs of the form <mailto:[email protected]>. It's an inverse functional property because for a given mailbox, we'd expect at most one person to have that mailbox. (Of course, some people might share a mailbox, so this isn't quite right all the time, but oh well.) It's not a functional property, though, because a person can easily have multiple mailboxes.
mbox_sha1sum (inverse functional and datatype)
As I recall, this property relates an indvidual to the sha1sum of their mailbox. Use of this property means that people don't necessarily have to share their real email address. It's an inverse functional property for the same reason that mbox is; we expect each mbox_sha1sum to belong to at most one individual. Similarly, it's not an functional property, because a person can have more than one mailbox, and thus more than one sha1sum.
This is the problematic case, because this is a datatype property and an inverse functional property, and that shouldn't happen (as described above). However, an OWL Full reasoner still might let you infer that if x and y both have the same mbox1_shasum, then x = y.
References
You can read the formal definitions in OWL 2 Web Ontology Language Direct Semantics (Second Edition). You'd be interested in 2.3.2 Object Property Expression Axioms and 2.3.3 Data Property Expression Axioms.