What is the difference between DatatypeProperty, ObjectProperty, & FunctionalProperty, and when should I use them?

Question

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?

Aemia

Can you give an example of a challenging use of them in FOAF? (I would note that, last I knew, FOAF is an RDF vocabulary, not an OWL ontology, so its use of the different property types isn't necessarily correct, and it's probably not the best example of OWL.) – Duce

Sure... gender has types FP and DtP, mbox has IFP and OP, mbox_sha1sum has IFP and DtP. I can rationalize some of them, but some I cannot. And after reading your first comment, perhaps that's why some of them don't make sense to me. – Aemia

OK, I think those cases make sense, but I'll write up in an answer… – Duce

Actually, the last case is a problem in OWL 2 DL. @Ignazio proposed an edit that, unfortunately, got rejected, but I've updated my answer with similar text and pointed out that mbox_sha1sum is a problem case. – Duce

Answer 1

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) ∧ p(x,z)] → 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) ∧ p(y,z)] → 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.

Duce

Inverse functional and datatype properties are not really a problem in practice. It is only a problem for one who wants to define a correct and complete algorithm in the presence of such properties. Concrete OWL reasoners can be correct and compete on OWL DL ontologies, and still be able to do some more inferences on ontologies that are not OWL DL. For instance, both Pellet and HermiT are able to infer equality of individual based on inverse functional datatype properties. – Tal

@AntoineZimmermann It is good that some reasoners can handle these constructions. It's important to have some feel for what's actually allowed by the W3C specification, though, because it's easy to do something because "it works" and then have it unexpectedly break later because it turns out it wasn't actually within the limits of the specification. One place where this has bitten me has been the various constraints on simple and non-simple properties; Protégé doesn't stop you from using properties in ways that OWL 2 DL prohibits, and then reasoners blow up when you try to use them. :( – Duce

I've been logged out of this site for ages, but dug up my password to say thanks for this answer, which was clear and taught me a few details about OWL I had missed. Curious, is there still "talk" of allowing literals in subject position, or is this something that will be left to implementations to support internally as needed? – Kasandrakasevich

@Kasandrakasevich I think that some triple/quad stores may actually support more general notions of graph in which literals may appear in subject position, but I don't know whether there's been any motion toward changing anything in the RDF specs about it. – Duce

It seems that in OWL2 "DatatypeProperties" were renamed to "DataProperties". I get no results when I search for DatatypeProperty on page: w3.org/TR/owl2-syntax – Amazonas

@barrynl and it's even a little more complicated than that. The rdf mapping for owl2 uses the class owl:DatatypeProperty for what the structural spec calls data properties, so many people who only see owl ontologies serialized as RDF documents will only end up seeing that class name. – Duce

Aha, that explains the confusion in the community. I think DataProperty is more accurate and better aligned with ObjectProperty, so I'll keep 'promoting' that one :) – Amazonas

@JoshuaTaylor Quick question, how does OWL handle multiple FunctionalProperties that are also DataProperties? e.g. -->Assume ":hasAge" is a FunctionalProperty so ----> :John :hasAge "30" and :John :hasAge "40" but "30" not sameAs "40"; would this result in Inference Error? – Venus

@Venus I wouldn't use the term "inference error", exactly. A reasoning engine would infer that 30 = 40, but would also know that 30 != 40, and recognize that the ontology is inconsistent. That mechanism is important, because it's what allows proof by contradiction. E.g., if we know john hasAge 30 and ask whether john hasAge 40, the reasoner can temporarily assume john hasAge 40, then see that such an assumption leads to contradiction, and then infer that John does not have age, 40, i.e., it can infer NegativeDataPropertyAssertion(hasAge john 40). – Duce