Properties
A property represents a way that two resources can be related to each other. Properties are the glue that holds the Semantic Web together. This chapter gives more of a theoretical underpinning and explains how semantics can be given to properties. We will first describe object properties, which link resources to other resources, followed by data properties, which link resources to literals.
4.1 PROPERTIES, RELATIONSHIPS, AND SETS
Consider the relationship between a subsidiary and its parent company. Alphabet Inc. has several subsidiaries, including Google and Nest Labs. Berkshire Hathaway subsidiaries include GEICO and The Buffalo News. Each of these relationships can be represented as a triple using an object property as follows:
If we collect together all the triples that use this property, we get a set of ordered pairs of companies as follows: (Google, Alphabet), (Nest Labs, Alphabet), (GEICO, Berkshire Hathaway), (The Buffalo News, Berkshire Hathaway), and many others. A set of ordered pairs—that is what an OWL property is from a mathematical perspective. It is spelled out as such in the formal semantics of OWL.
An object property represents a way that two resources can be related to each other. Formally, an object property is the set of all ordered pairs of resources are in fact related to each other in that particular way. In our example, that “way” corresponds to the first resource in the pair being a subsidiary of the second resource in the pair. This is the real-world semantics of the property isSubsidiaryOf. For brevity we use usually the term “pair,” but we are always talking about ordered pairs.
We saw some Venn diagrams in Chapter 2 where the sets were classes. A subclass is shown as one set being inside another. There is a direct parallel with subproperties. A super-property of isSubsidiaryOf would be a set of ordered pairs that included all the ordered pairs in the above diagram. A subproperty would include only a subset of the ordered pairs. Thinking of OWL properties in terms of sets can help disentangle meaning when things get a bit complex, especially when debugging.
Exercise 1: Can you think of examples of real-world properties that might be either a subproperty or superproperty of isSubsidiaryOf?
4.2 PROPERTIES ARE FIRST-CLASS OBJECTS
All modeling languages and paradigms have a way to represent a kind of thing. The term “entity” is frequently used for data modeling for relational databases. An entity results in a table; relationships and attributes result in columns. The term “class” is used for object-oriented modeling and programing and also in OWL—but, importantly, the term “class” does not have the same meaning in each context.
In general, kinds of things are characterized by what attributes and relationships their instances typically have. For example, companies have CEOs, subsidiaries, stock prices, and a number of employees. Employees have names, dates of birth, bosses, salaries, and organizations or departments that they work in.
An “entity” in entity-relationship modeling is much like a “class” in object-oriented modeling (hereafter an OO-class). In both cases, the relationships and attributes belong to the entities and OO-classes. When an instance of an OO-class or entity is created, the set of relationships and attributes of the class or entity determine the structure of the instances. An instance of an entity corresponds to a row in a database table. There is a column for each relationship or attribute, and NULL values are possible. When an object in object-oriented programming is instantiated, a data structure is created with space for each relationship or attribute. In this sense, entities and object-oriented classes act as templates for creating instances. There is space set aside whether it is used or not.
Because they belong to particular entities or OO-classes, attributes and relationships do not have independent existence. For example, if you want to model the subsidiary relationship between companies you might create a relationship called “parent” and it would belong to the class or entity called Company. It would become a column in a table, or a field in a data structure for an object.
If you wanted to model being a biological parent, which would be important for child support cases, you might have an entity or object called Person and use the same name “parent” for the biological parent relationship. Although there are two different relationships called “parent,” each is subserviant to its OO-class or entity. This means there is no possibility of mixing up the two. If you are lucky, the modeler will document the meaning of the relationships, but often you just see the name and you make your best guess about its meaning.
In this case, it is a good thing that the two uses of parent cannot be confused, given their very different meanings. However, some relationships commonly occur for many kinds of things, e.g., being a part of something. A steering wheel is a part of a car. A chapter is part of a book. A screen is part of a laptop. In entity relationship (ER) and object modeling, because the relationships belong to their entities or classes, it is necessary to create several different versions of what is essentially the same relationship: being a part of something else. In OWL, it works very differently.
An OWL Property Stands Alone
In OWL, a property is a first-class object. It does not belong to any particular class, it can be used with any number of classes in a variety of ways. For example, in OWL we can create a property called partOf and use it to relate steering wheels to cars, chapters to books, and screens to laptops. The property is not dependent on any class for its existence, and is not owned by any class. We can create and use the inverse of the partOf property (hasPart) to say that an instance of a car has a part that is a steering wheel. Not all properties can be used in such a wide variety of contexts—e.g., isSubsidiaryOf only really makes sense between companies.
OWL Properties are Reusable
A major consequence of OWL properties being first-class objects is that they can be reused in a variety of situations.
An OWL Class is not a Template
Another consequence of properties being first-class objects is that OWL classes do not act as templates when instances are created. No space has to be allocated for NULLs in a relational table, or for empty fields on an object. Instead, space is allocated only when the actual triple is created.
We Can Specify the Semantics of a Property
A third major consequence of properties being first-class objects is that we can define and specify the meaning of a property in one place and reuse it with any number of classes. There are various things we can say about properties to specify their meaning. We saw examples of this in Section 2.3.5. The main ways to specify meaning for properties are:
• property hierarchies;
• domain and range;
• property characteristics (e.g., functional, transitive); and
• property inverses.
The next few sections of this chapter will explain how this works.
4.3 PROPERTY HIERARCHIES
Class hierarchies are very common, we saw one in healthcare in Figure 2.6. Because classes represent sets, we can illustrate classes and their subclasses using Venn diagrams.
Figure 4.2: Class hierarchy as a Venn diagram.
None of the classes are known to be disjoint, so the diagram allows for the possibility that the same individual is a member of all three classes: Doctor, Nurse, and Patient.
But we just saw that properties also represent sets, so we can draw Venn diagrams for them too. The main difference is that whereas classes represent sets of individual resources, properties represent sets of ordered pairs of resources (see Figure 4.3).
The set perspective for properties illustrated in the Venn diagram makes it easy to see by inspection that anyone that is a contractorFor a given company also worksFor that same company. The same ordered pair of resources is in both sets. There are also pairs that are neither for employees or contractors. This allows for the possibility of other ways of working. Finally, there is one pair that is in the intersection of the two sub-property sets. This allows for the possibility of a given person being an employee and contract worker for the same company.
These things may or may not be true for your particular organization. To describe inferences, we will transition from speaking about ordered pairs to writing down triples. The triple, “x p y” is a shorthand for saying that the ordered pair(x, y) is a member of the set of pairs represented by property p.
Exercise 2: What would the Venn diagram in Figure 4.3 have to look like to rule out being an employee and a contractor for the same company?
Sanctioned Inferences
Specified as an inference rule, where the notation “x p y” indicates an asserted triple, the meaning of subproperty is:
So, when viewed from a set perspective, rdfs:subClassOf and rdfs:subPropertyOf are very close in meaning:
• IF: a resource is a member of the subclass
THEN: it is also a member of the superclass.
• IF: an ordered pair of resources is a member of the subproperty
THEN: it is also a member of the superproperty.
You cannot have a stand-alone subproperty or superproperty. The OWL construct, rdfs:subPropertyOf is a property representing a way that two properties can be related to each other.
Similarly, you cannot have a stand-alone subclass or superclass. The OWL construct, rdfs:subClassOf is a property representing a way that two classes can be related to each other.
4.4 DOMAIN AND RANGE
Creating subproperties is one way to specify meaning for a property; it does so by relating a property to another property. Another way to give meaning to properties is to specify when it makes sense to use a given property. For example, it makes no sense to say that a laptop has a subsidiary, nor could a biological parent be a corporation. Recall from Section 2.3.2 that “domain” translates informally to “only applies to.” If a property has domain C, then it only applies to instances of C. Similarly, “range” translates to “range of possible values.” If a property has range C, then the range of possible values that a property can have must all be instances of C.
More formally, consider the triple: x p y. The domain of property p answers the question: “What class is the subject necessarily a member of?” The range of p answers the question: “What class is the object necessarily a member of?”
Consider isSubsidiaryOf. If you know that x is a subsidiary of y, what can you say about x and y? A good place to start is to name the kinds of things you intend to use the property for; here the property will be used to link two companies. So the class Company is a candidate for both the domain and the range. However, for determining domain or range, focusing on what you merely intend is not going to work. For Company to be both the domain and range for isSubsidiaryOf, the subject and object must be instances of Company in every conceivable use of the property. By the very meaning of being a subsidiary, it is logically necessary for the subject and object to be instances of Company. It makes no sense to be otherwise.
These are strong criteria. However, I cannot think of what else isSubsidiaryOf might be used for and if someone wanted to use the property for something else, it would likely be wrong or an obscure edge case that you can safely ignore. So we are justified in using Company as the domain and range of isSubsidiaryOf.
Consider partOf. It is used to link a wide variety of things. That would include physical objects, countries, agreements, and books. In this case, it is probably best to not specify a domain or a range. Doing so could give wrong results.
For example, say the domain and range of partOf were specified to be a class called PhysicalObject. Then someone decided to use it to model different parts of agreements. Then those agreements and their parts would be wrongly inferred to be physical objects.
These are two extreme examples. Most of the time, it is not so easy to decide. There is a strong tendency for ontologists to over-constrain domain and range. This limits property reuse; we will see other examples of this in the next section.
Sanctioned Inferences
What happens if there is more than one domain or range, i.e., what happens if all three of the following triples are present?
We can work this out from the sanctioned inferences above. The first domain allows us to infer that x rdf:type C1. The second domain allows us to infer that x rdf:type C2. Therefore, the net effect is for the domain to be the intersection of C1 and C2. It would be logically equivalent to specify the domain using the following expression of the sort we discussed in Section 3.1.7.
The situation is exactly analogous for range. Specifying two ranges is logically eqivalent to specifying a single range to be the intersection of the two individual ranges.
4.4.1 USE DOMAIN AND RANGE WITH CARE
It’s easy to make mistakes using domain and range. We consider several examples.
Multiple Domains or Ranges are Intersected
Suppose we have a property for borrowing. The borrower could be either a person or organization, and so can the lender. An easy mistake to make would be to do this:
Can you see the problem? This means that if we assert that_JohnDoe borrowsFrom _CommunityBank then John Doe will also be inferred to be an organization (as well as a person) and the Community Bank will be inferred to be a person (as well as an organization).
Figure 4.4: Domain and range in Protégé. Separate domain or range classes are intersected.
Instead the domain and range should be specified as the union of the two classes, Person and Organization (see Figure 4.4). Recall that Protégé is a commonly used ontology authoring and viewing tool. The sanctioned inferences would then correctly say that both John Doe and the Community Bank must each independently be either a person or an organization. Because this commonly arises, it makes sense to have a class that means: “either a person or an organization.” That is exactly how Party is defined (see Figure 2.13). In Manchester syntax, this is:
Don’t Define Domain or Range Too Narrowly
Another common source of mistakes is to define domain and range too narrowly. For example, suppose you want to reuse the W3C media ontology.15 A large number of properties use the class MediaResource as their domain. These include data properties such as date and description, and object properties such as hasContributor, hasLanguage, and hasPolicy. This means that the only things that can conceivably have any of these properties is a MediaResource—by definition. Because no company, country or person can also be a MediaResource, the domains of the above properties dictate that a company cannot have a policy, a country cannot have a language and no person can contribute to manufacturing a car. This is dictated by their use of the OWL construct, rdfs:domain. There is nothing to stop you from asserting that a country has a language, but when you run inference the ontology will be inconsistent (see below).
Even if you are a media company whose bread and butter is exactly the production and sale of media resources, there are other uses of the properties that makes sense. If you decided to use this media ontology as part of your larger enterprise ontology, then it means you have to create duplicate properties for hasLangauge, hasPolicy, etc. that can be used in a context broader than media resources.
Let’s take one of these and explore further: hasLanguage. What exactly can have a language? Media resources are the obvious answer, but a country can have an official language. A technical conference might have an official language. If you were 100% certain that these were the only things that could have a language, then you could create a class that was equivalent to the union of these classes and make that the domain. But that class is not very meaningful: “Conference or MediaResource or Country.” In these cases, it can make sense to not have a domain at all. The range is a bit easier; it must be a Language.
Don’t Regard Domain and Range as Integrity Constraints
A third major mistake is to regard domain and range as integrity constraints. The formal semantics of domain and range have surprising consequences, especially for ER and OO modelers. Consider the hasLanguage property from the W3C media ontology. Suppose someone tries to assert the triple: _Italy hasLanguage _Italian. If domain acted as an integrity constraint, the assertion would be rejected. However, instead, the domain of hasLanguage sanctions the inference engine to infer the nonsense assertion that _Italy is an instance of MediaResource. The inference engine is doing the right thing, the model is wrong.
You can leverage the inference engine to find such mistakes, but you may need to give it more information. You need to say that Italy is a country and that countries and media resources are disjoint. That will cause the ontology to be inconsistent. Garbage-in, garbage-out applies here.
The user made what seems to be a perfectly sensible assertion, and the ontology was inconsistent. This is a trigger to go track down the error, which in this case was an overly narrow domain axiom. Here are the needed triples:
The use of domain and range in conjunction with disjoint axioms is powerful way to catch errors. It is important to include the disjoint axioms, and to say what classes individuals belong to. Otherwise, the logical errors lurking in the ontoloty could cause problems later on.
Summary: Domain and Range.
Given two things connected by a given property, domain and range are used to indicate what classes those two things necessarily belong to. Use with care. Don’t think of them as integrity constraints. Specifying domain and range too narrowly is often worse than not specifying them at all. Be careful with multiple domains and ranges—it implies intersection.
4.5 INVERSE PROPERTIES AND PROPERTY CHAINS
Another way we can give a property meaning is to define it in terms of other properties. We will look at two examples: inverse properties and property chains.
4.5.1 INVERSE PROPERTIES
Each triple has a subject and an object, and the order is important. To say that Google isSubsidiaryOf Alphabet is taking the perspective of the smaller entity. If you are interested in the [opposite] perspective of the larger entity you might say Alphabet hasSubsidiary Google (see Figure 4.5).
Figure 4.5: Property perspectives.
Taking the opposite perspective just means inverting the subject and the object. In terms of sets, you just invert the order of the items in the ordered pairs. Thus, the property from the opposite perspective is called the inverse of the original property (see Figure 4.6).
In English, taking the opposite perspective is just changing the way we write the sentence; the following two sentences are saying the same thing in two different ways.
1. “Nest Labs is a subsidiary of Alphabet” and
2. “Alphabet has Nest Labs as a subsidiary.”
Figure 4.6: Inverse properties.
So in one sense there really is only one relationship, but in practice you have to choose a perspective to communicate which resource is the subsidiary vs. which resource has the subsidiary. It’s a bit like a coin: it has two sides, but you can only look at one side at a time. It’s also a bit like two quantumly entangled particles. If you change the spin of one, then the spin of the other one that might be millions of light years away simultaneously changes.
Choosing a Perspective
When we speak of triples, choosing a perspective for a property means fixing the subject and the object. When we draw a triple, the perspective corresponds to the direction of the arrow (from the subject, to the object). See Figure 4.5.
When you create a property in OWL choose the perspective that seems the most natural way to think about it, or the way that it will most frequently arise when you populate and use the ontology. For example, consider a property that connects a loan contract to the borrower. It is central to the idea of a loan contract to know who the borrower is. However, from the perspective of a person or an organization, what loans they have is but one of many things that might be of interest. This suggests using the perspective where the loan contract is the subject and the borrower is the object. The property might be called “hasBorrower.”
Recall also the example from Figure 2.10. There was the property careRecipient and its inverse, careRecipientOn. Which perspective seems most natural and intuitive to you? Note that there is not always a preferred perspective, both may be equally useful.
When inverses are needed you can do one of two things. First, you can create an explicit named property that is the inverse of an existing property and use it as you would use any other property. In Manchester syntax:
Alternatively, you can just use an object property expression directly and not bother to create an explicit inverse property.
The only difference between the two snippets of OWL is that the property used to define the restriction is named in the first snippet and is a property expression in the second. The property expression gives rise to an anonymous property just like class expressions give rise to anonymous classes, as we saw in Sections 2.3.4 and 2.3.5.
Explicit Inverse Properties: Yay or Nay?
It is not unusual to see ontologies where many if not all properties have explicit named inverses. However, there are limited upsides and several downsides.
1. If you store inferred triples, it will double the number of triples for that predicate.
2. It adds to the number of properties.
3. It’s not always easy to find good names or definitions
Inferred triples: Most inferences say new things, but inverse property inferences just say the same thing in a different way. If you run inference and store the results in a triple store, it doubles the number of triples for a given property. So there is a cost with limited upside.
Extra properties: You can clutter up the ontology with unnecessary properties. Strictly speaking, explicit inverse properties are never necessary because you can always use an expression instead.
Names: When you do want the inverse, you must think of a name for it. The inverse of the property, isSubsidiaryOf, has an obvious name: hasSubsidiary, and hasPart is a good name for the inverse of partOf. But thinking of a name for the inverse that is reasonably natural English is not always easy.
Exercise 3: Can you think of a good name for the inverse of hasBorrower? What about works-For? Sometimes there aren’t any good names.
Here are some hints for the exercise. It is good practice to use names so that when used in a triple, it reads roughly like a sentence. For example, the triple:
is fairly close to the real sentence: “Loan contract 857466 has borrower: John Doe.”
What about the triple going in the other direction? Try filling in the blank in this sentence: “John Doe ___________ loan contract 857466.” Then use that as the basis for deciding on a name of the inverse property that you would be happy to have in your ontology. What did you come up with? Do the same thing for the worksFor property by inverting the sentence: “Tim Cook works for Apple.” Fill in the blank: “Apple ___________ Tim Cook” then try to find a good name for the inverse property.
Even if you can find a good name, it may not be easy or particularly useful to come up with a good text definition. One way around this is to have the definition simply say: “the inverse of …” where the ellipsis is replaced by the property name.
Sanctioned Inferences.
A property is the same as its inverse except that the subject and object are reversed. That’s it. For example, if Scotland is partOf the UK then the UK hasPart Scotland. Also, if hasPart is the inverse of partOf, then it follows that partOf is the inverse of hasPart. So, the inferences warranted for inverse properties are quite straightforward:
In addition,
Summary: Inverse Properties
When creating object properties, choose the perspective that is likely to be used most often and is most intuitive. The main time when you need to refer to an inverse property is for restrictions that require the opposite perspective from an already defined property (see Figure 2.10). When inverses are needed you can either create an explicit inverse property or you can just use an expression that refers to the existing property.
There are numerous downsides to explicit inverse properties, so create inverses only if you can see a clear benefit. The main justification for doing the latter is if property is routinely used in both directions, and the future users will expect to see both.
Please note: the recommendations and guidelines you see here are just that. There are good ontologists that I personally know and respect who take a different view about property inverses. They prefer to have them all or most of the time and to give them names and definitions. You will need to decide what works best for you. For additional discussion about inverse properties, see the blog article: “Named Property Inverses: Yay or Nay?”16
4.5.2 PROPERTY CHAINS
The second way to define a property in terms of other properties is by chaining two or more properties together. For example, if genealogy was important to your business, you might want to define an uncle to be the brother of a parent. In the example in Figure 4.8, you want to infer that Gene is Michael’s uncle if you know Gene is the brother of one of Michael’s parents. The figure uses the notation p1 o p2. The “o” symbol means composition; it is borrowed from mathematics. A new mathematical function can be composed by chaining one function after the other. Here we are doing something similar for OWL properties.
How It Works
The way OWL handles property chains is incomplete and slightly confusing. The obvious thing to do here would be exactly analogous to what we have done before with class expressions. We created the class expression (Organization or Person) and set it to be equivalent to the class Party. In effect this was giving that class expression a name. By analogy, we would like to give the property expression (hasParent o hasBrother) the name hasUncle by using owl:equivalent-Property. This would meet the main requirement to be able to infer that Michael has an Uncle Gene. However, for technical reasons beyond the scope of this book, it does not work that way.
Instead the inference requirement is met by making the property chain expression a subproperty of the new property, hasUncle. If the pair, (Michael, Gene) is in a subproperty of hasUncle, then (Michael, Gene) is also in the property hasUncle. Viewing properties as sets allows you to see this by inspection. This is depicted in Figure 4.9.
Figure 4.9: Venn diagrams for property chains.
Another Example: Giving Care
Let’s go back to our patient visit events (Figure 2.4). A PatientVisit is linked to both a care provider and a care recipient. However, it might be of interest to answer the question: who are all the patients that Nurse Jane gave care to? There is no direct link. Furthermore, unlike for the uncle example, there is no path from NurseJane to either of the two patients, Ellen and John Doe, that goes in the direction of the arrows. To make a property chain that goes from a care provider to the patient, we must refer to the inverse of careProvider. We could use the expression (owl:inverseOf careProvider), or define an explicit inverse property and call it say, care-ProviderOn. They mean exactly the same thing (see Figures 4.10 and 4.11). There are now three cases where the two properties careProviderOn and careRecipient are chained together resulting in a third property called gaveCareTo.
Exercise 4: Draw a Venn diagram like the one in Figure 4.9 for this example. Hint: the property chain you want is: ‘“careProviderOn o careRecipient.” It will be a sub-property of gaveCareTo.
Figure 4.10: Patient visit events.
Practical Considerations
Tools provide different ways to create OWL property chains, and each syntax will show you something different. It is not clear from the syntax that property chains are implemented using subproperties. For example, here is what it looks like in Turtle:
Manchester syntax shows evidence of the idea of subproperty, but does not have an explicit subproperty relationship.
The syntax used in each case is shorthand for longer expressions using the formal subproperty axiom. It is more evident in the Protégé user interface.
To define a property chain in Protégé, for doe:gaveCareTo, you click the + button next to the text: “SuperProperty of (Chain).” The chain is defined using the p1 o p2 notation. Protégé then tells you that the chain is a subproperty of doe:gaveCareTo.
Here, it helps to realize that if rdfs:subPropertyOf had an inverse, it would be called rdfs:superPropertyOf. It explains why you see both superproperty and subproperty in the Protégé window. One is from the perspective of the property chain itself, the other is from the perspective of the new property, gaveCareTo.
Sanctioned Inferences
Summary: Property Chains
Property chains are defined using the idea of function composition borrowed from mathematics. The desire for property chains arises frequently in modeling. However, there are some shortcomings that limit their use, the main one being that it cannot be used in a cardinality restriction. This is discussed more fully in Section 7.6. I have found the limitations often outweigh the benefits, and tend not to use them any more. If I need to use a property chain, I can always do it in SPARQL.
We just looked at four ways we can specify the semantics of a property: by creating property hierarchies, specifying domain and range, being the inverse of an existing property and creating property chains. In this section we look at a fifth major way.
There is no limit to the number of ways two resources can be related to each other: having a biological mother, being older than, borrowing from, geographically bordering, being identified by, being a part of, among others. It turns out that if we look at large collections of properties, we notice that there are some characteristics that some properties have that others lack.
4.6.1 FUNCTIONAL PROPERTIES
For example, in Figure 2.6 we modeled the relationship between a patient visit and the care recipient so that there was never more than one care recipient. Properties with this characteristic are said to be functional. Another example is the relationship between various identifiers, and the things being identified. The whole point of an identifier is that it is identifying only one thing. A loan identification number identifies just one loan. A social security number identifies just one U.S. citizen. The two perspectives on this relationship are as follows.
1. The identifier identifies the thing.
2. The thing is identified by the identifier.
Can you think of a preferred perspective for this relationship? In this case, both are likely to be commonly used, and neither is obviously preferred. So let’s call the two properties identifies and isIdentifiedBy and make one the inverse of the other.
The property identifies is functional. What about its inverse? Can a single individual have more than one identifier? Think about that for a few minutes. Consider the examples above from the perspective of the thing with the identifier: the employee, the U.S. citizen, the loan. For the property identifiedBy to be functional, it can only have one value for all and every conceivable scenario. You don’t even need to be a citizen to have a national identification number. I lived in Scotland for many years and had a UK national insurance number that served much the same purpose as my U.S. social security number. So in fact, I was identified by two different numbers. Thus, isIdentifiedBy is not functional.
Suppose we preferred the perspective from the thing being identified so we created the property, isIdentifiedBy, but not its inverse. Since things can be identified by many things, this property is not functional. There is a way to say that the inverse of a property is functional without having to explicitly create the inverse and set it to be functional. We just say that the property isIdentifiedBy is inverse functional. Saying that a property has this characteristic is to say that its inverse property is functional (whether or not it is explicitly created).
If a given identifier is the subject of two triples using the identifies property and the objects have different IRIs, they are inferred to be the same thing. This is represented by the OWL construct: owl:sameAs (Figure 4.13).
Figure 4.13: Functional [F] and inverse functional [IF] properties.
A functional property can only have one value for a given individual. The two-character ISO code that is “US” identifies only one country. If it points to two different URIs that means the two URIs refer to the same thing.
This is another illustration of how OWL does not make the unique name assumption. An inverse functional property is a property whose inverse property is functional. In the example, the functional property is identifies. Because the inverse of identifiedBy is functional, identifiedBy is by definition, inverse functional.
Other examples of properties that are functional in most situations include: hasBoss, has-BiologicalMother, and hasCEO. I say in most situations because it’s not impossible to imagine having two people share a CEO role. With advances in medicine or freak situations in nature, someone could plausibly have more than one biological mother. Because you are building an enterprise ontology for practical purposes, it is usually safe to ignore such edge cases. When creating a property, always ask “Can this property ever have more than one value for a given individual?” If the answer is no, then the property is functional. If the answer is no for the inverse of a property, then the property is inverse functional.
Functional properties:
Inverse functional properties:
4.6.2 TRANSITIVE PROPERTIES
Another characteristic that commonly arises, relates to what happens if you have a chain of triples linked by the same property. If you want to know who is richer or taller or faster than the next person you might have properties such as richerThan, tallerThan, and fasterThan. For each of these, if you chain them together the relationship will always hold between the first and last item in the chain, and everything in between. In general terms, these properties have the characteristic that if A is related to B and B is related to C, then A is related to C. This characteristic is called transitivity.
When you create a property, you should always ask: is it transitive? Some of OWL’s built-in properties are transitive, for example: rdfs:subClassOf. If person is a subclass of primate and primate is a subclass of mammal, and mammal is a subclass of … all the way up to lifeform, then person is a subclass of mammal and of everything in the chain up through lifeform (see Figure 4.14). Dotted lines depict sanctioned inferences.
Figure 4.14: Transitive [T] and symmetric [S] properties.
Transitive properties:
4.6.3 SYMMETRIC AND ASYMMETRIC PROPERTIES
We have emphasized that order matters for properties. There is a real difference between being the parent or the child, or between being a subsidiary vs. having one. However, consider the relationship of sharing a geographic border. Saying that Canada borders the U.S. is no different in meaning than saying that the U.S. borders Canada. In this case, order does not matter. You can flip the subject and object and the relationship still holds. Another way of saying this is that the property is its own inverse. Properties with this characteristic are called symmetric. Another common example is siblingOf.
In the opposite situation, if the property holds in one direction, then it cannot possibly hold in the other direction. For example, if company A is a subsidiary of company B, then company B cannot possibly be a subsidiary of company A.
If a property is neither symmetric nor asymmetric, that means sometimes the relationship holds both ways and sometimes not.
Exercise 5: Think of a few more properties in each category: symmetric, asymmetric, and neither. Which category do you think will generally have the most properties? Why?
Sanctioned Inferences
Symmetric properties:
Asymmetric properties:
Recall that “¬” symbol is for logical negation, or “not” for short. It means what follows is provably false. You could think of this as negatively asserting a triple.
There are two more property characteristics that I have never seen used in practice, but I mention them here for completeness: reflexive and irreflexive. Check out the OWL 2 documentation if you are curious.17
4.7 PROPERTY CHARACTERISTICS OF SUBPROPERTIES AND INVERSE PROPERTIES
4.7.1 SUBPROPERTIES
Next we consider what if anything can be inferred about the characteristics of a property given the characteristics of its super-property. For example:
IF: property p1 is functional, transitive and symmetric and
property p2 is a subproperty of property p1
THEN: what can we say about the characteristics of property p2?
Let’s consider functionality first. This is a good time to consider properties from a set perspective. Stare at the Venn diagram in Figure 4.3. Recall that a property is a set of ordered pairs, and a subproperty is a subset of the pairs of the superproperty. For the sake of this discussion, let’s say that worksFor is functional (i.e., you can only work for one person or organization). This means that no two pairs in the worksFor property can have the same subject but a different object. If you look at this in the right way, it becomes immediately obvious whether or not employedBy and contractorFor must also be functional. Can you see it?
Pick any two pairs from the employedBy subproperty. They are both in the worksFor property, and we already know that no two of those pairs can have the same subject and two different objects. Therefore, the subproperty of a functional property is functional. The same line of reasoning says that:
• the subproperty of an inverse functional property is inverse functional and
• the subproperty of a symmetric property is symmetric.
You may be thinking that all property characteristics are in effect, inherited from their super-property. What about transitivity? Again, it helps to think about the property as a set of pairs. Let P and subP be properties with the following pairs:
• P = {(x,y), (y,z), (x,z)}
• subP = {(x,y), (y,z)}
The property subP is clearly a subproperty of P and not transitive, whereas the P is transitive. Therefore:
• the subproperty of a transitive property need not be transitive.
Note that the set perspective of properties sometimes allows you to more or less “see” the solution by merely inspecting Venn diagrams of subproperty relationships. The alternative way to convince yourself (or others) amounts to working out (often simple) step by step lines of reasoning which lead you to the conclusion you are after. This entails writing down expressions with triples. In the next exercise you will get a chance to do exactly that.
4.7.2 INVERSE PROPERTIES
Exercise 6: Answer the following three additional questions asking what we can know about the characteristics of the inverse of a property from the characteristics of the property.
1. If property p is functional, what can we say about whether p_inv is or is not functional?
2. If property p is symmetric, what can we say about whether p_inv is or is not symmetric?
3. If property p is transitive, what can we say about whether p_inv is or is not transitive?
Hint: it may help to draw some Venn diagrams representing properties as sets of pairs.
4.8 DATA PROPERTIES
A data property connects an individual to a literal rather than to another individual. Despite this important difference, data properties share much in common with object properties. They are firstclass objects, they can be arranged in a sub-property hierarchy, they have domains and ranges, they can be functional, and they can be used to create property restrictions. We consider these in turn and highlight the differences.
4.8.1 DATA VS. OBJECT PROPERTIES
Recall from Section 3.1.5 that from a set perspective, datatypes are just like classes, except that their members are literals instead of individuals. Despite the close analogy between classes/individuals and datatypes/literals, there is a stark divide between individuals and literals that is enforced by OWL. We will not explore the technical reasons; instead, we focus on the ramifications.
The most direct consequence is that the range of every data property must be a datatype (hence the name). We saw examples of this already with the properties for names having a range of xsd:string, and the date of a patient visit having range of xsd:dateTime.
The fact that a literal cannot be the subject of a triple means that a data property cannot have an inverse. For example, given that firstName is a data property, we can say that someone’s first name is “Jane,” but OWL does not allow us to assert in a triple that the string “Jane” is the first name of someone.
This has major consequences on what characteristics make sense for datatypes. Before you continue reading, ask yourself: can a data property be inverse functional or transitive or symmetric? Why or why not? Refer to at Figures 4.13 and 4.14.
For a data property to be inverse functional, its inverse property has to be functional. But a datatype cannot have an inverse, so this characteristic cannot apply.
To be symmetric, a property has to hold in both directions. But a data property only goes in one direction, so a data property can never be symmetric.
To be transitive, a datatype has to be chained, meaning that the object of the first triple becomes the subject of the next triple. But a literal can never by the subject of a triple, so a datatype can never be transitive either.
What about functional? Suppose we want to say that a no one can have more than one last name. Does that make sense? It does. So being functional applies equally to object and data properties. It is the only property characteristic that applies to data properties.
4.8.2 WHEN TO USE DATA PROPERTIES
Often, you will create object properties because you know you are connecting to other individuals, so there is no question. Frequently, you will be inclined to create a data property, because it seems like the right thing to do. For example, in Chapter 2 we modeled first and last names as data properties. However, the right thing to do depends on what the intended usage of that property is. If you are tracking patient names, a data property is probably fine.
However, suppose your use case involves tracking large numbers of attorney names in a database. You could instead make firstName and lastName object properties both of whose ranges are a class called Name. In turn, each instance of the class Name, would be linked via a data property to the string representing the name. The data property might be called text. This means having individuals rather than literals that directly correspond to specific first and last names, e.g., _Name_Johnnie and _Name_Cochran (see Figure 4.15).
Using an object property enables you to say something about the name. You could create an inverse of hasLastName that relates a name to a person with that name as their last name. That inverse property could be used to discover all the attorneys with a given last name. You could say other things about the name, e.g., which countries is it commonly used in. None of that is possible using a data property. At least not with the inference engine.
However, you can use SPARQL to find out who has a particular last name. The following returns all the (IRIs for) people whose last name is “Cochran” along with their first name.
The effect is similar to traversing the arc from literal to individual. You start with the string “Cochran” and see what it is connected to via the hasLastName data property. Recall from Section 3.1.12 that there are two steps to executing a SPARQL query. First you find triples in the triple store that match the pattern in the WHERE clause. Once the individual with the specific last name is found, the first name is retrieved. Then a table of results is returned based on what is asked for in the SELECT part of the query. There could be a performance hit because of the string matching.
Another example is in the context of offers that must indicate the amount of something that is for sale. If you are selling a 50-lb bag of sand in your local classified ads, it’s probably fine to have it all in a string: “50-lb of sand.” The financial markets that are offering 50 million barrels of Brent crude oil will want to track things more carefully. For that, it will be necessary to separate out the product being sold (Brent crude) from how much of it is on offer (50 million barrels). To aggregate sales volumes where things are sold in different units will require separating out units of measure from the number amount. This is shown in detail in Figure 4.16.
Sometimes it is not so obvious what the best thing to do is. In that case, it boils down to answering the following question:
Given a property that has some kind of value, do you now or might you in the future have the need to say something about that value?
If so, then the value will have to be the subject of a triple and an object property will be required. If not, you can safely choose to use a data property. If you are uncertain, you could choose to future-proof your ontology by using object properties, in case you needed them later. The cost of doing this is the need to create an extra individual and and extra triple each time you assign a value (as depicted in Figure 4.15).
4.9 DISJOINTNESS AND EQUIVALENCE
Figure 4.3 allows for a given individual to be both an employee and a contract worker for the same company. If you know this to be impossible, the two properties can be specified to be disjoint. Although we can think of a few examples, this is an infrequently used construct in OWL.
Exercise 7: Can you think of another example where two properties will be disjoint? Hint: think about loans, borrowers, and lenders.
Two properties can also be specified to be equivalent. In terms of sets, that means both properties have the exact same set of ordered pairs. The main situation when this is useful is if you are mapping one ontology to another and you need to keep both names around. For example, employedBy might be called isEmployedBy in another ontology. In Section 8.2.3, we will see an example of using equivalent property for mapping.
Figure 4.17: Disjoint and equivalent properties. Here, because they overlap exactly, employedBy and isEmployedBy are equivalent. Both are disjoint from contractorFor.
Sanctioned Inferences
Disjoint properties: If two properties are disjoint, then no single pair can be in both properties. In terms of triples:
Equivalent properties: If two properties are equivalent, then if a pair is in one of the properties, then it is also in the other. In terms of triples:
This has broad implications. If two properties are equivalent, then everything that is true about one is also true about the other. That applies to all the characteristics such as transitivity, functionality, symmetry etc.
Recall from the Section 3.1.1 that the “=>” symbol means logical implication (not greater than or equal to). It is a more compact way of saying IF <some premise> THEN <some conclusion>. Here it avoids ugly nesting of IF/THEN statements. Based on what subproperty means, we can rewrite the definition of property equivalence this way:
So, if two properties are sub properties of each other that means the two properties are equivalent to each other. There are two main situations when you use property equivalence:
1. when creating a crosswalk or mapping from one ontology to another and
2. when giving a property a new name and deprecating the old name. Deprecation is discussed in Section 8.4.5.
Exercise 8: A symmetric property is its own inverse. What similarly pithy thing can be said that characterizes the essence of what it means to be an asymmetric property? Hint, it involves disjointness.
4.10 ANNOTATION PROPERTIES
We have just completed a thorough treatment of object and data properties, addressing everything that you are likely to need in of your day-to-day OWL modeling. We looked at what you can say to define the meaning of the properties, and what that means in terms of what inferences are sanctioned.
There is one more kind of property that we briefly introduced in Chapter 2 that allows you to assign human readable labels and text definitions to classes and properties. These are examples of annotations that help humans understand the ontology and are accessible to SPARQL, but are ignored by the inference engine. There are nine that are provided in the OWL spec.18 The most common ones are:
• rdfs:label attaches a human readable label to an IRI
• rdfs:comment attaches a human readable comment to an IRI.
Labels are often used by tooling. For example, the property isSubsidiaryOf might have the label “is subsidiary of” and the class PatientVisit might have the label: “patient visit.” Comments can be used for anything, often they are definitions. For example, PatientVisit might have the comment: “The event of a person receiving healthcare.”
Annotation vs. Object and Data Properties
Like object and data properties, annotation properties are used to assert triples, can have domain and range, and can be arranged in a subproperty hierarchy. Here is a triple assigning a label: doe:PatientVisit rdfs:label “patient visit.”
The main difference is that annotations do not participate in inference. Another important difference is that there is no object vs. datatype distinction. The value of an annotation property can be either an IRI or a literal. For example, the following triple says that a particular class is defined in the Good Relations19 ontology about product offerings on the Web:
where the gr is the abbreviation for the namespace prefix:
Using Annotations
Unless you have a good reason not to, you should generally use labels. Some tools will create them for you automatically converting from camel case. Many ontologies use rdfs:comment for a variety of things including offhand remarks hinting at the meaning, a carefully crafted definition, examples, counterexamples, notes on usage, and even notes about the development of the ontology itself.
It’s a good idea to make it clear what kind of comment you are writing. A simple approach is to prefix each rdfs:comment with something like “DEFINITION:”, “NOTE:”, or “EXAMPLE:”. An alternative is to create or use existing annotation properties for each of the separate purposes. For example, it is increasingly common for ontology authors to make use of skos:definition20 for definitions. It is a matter of style and preference. Whichever approach you use, it is important to use it consistently.
Think about the consequences of creating a large number of different kinds of annotations. It means every time someone (including yourself) wants to add a comment, they have to scan through a large number of options to make sure they use the right one. It is also error-prone because people are often lazy and may not use the annotation properties consistently.
Before creating your own, look at the SKOS ontology for some commonly used annotations (see Figure 4.18). Notice how they are arranged in a hierarchy. There are three kinds of labels, and several kinds of notes. If you want a special annotation for synonyms or abbreviations, then you can create them and put them under skos:altLabel in the annotation property hierarchy.
Language Tags
If you anticipate creating multi-lingual applications, you can specify what language you are using for text annotations. For example, the English word “contract” is “Fabrik” in German and “contrato” in Spanish. If there was a class for contract in your finance ontology whose IRI was fin:Contract, you could assign it all three labels as shown below. The two character country codes (en, de, and es) are ISO standards.21
Machine Processable
Although annotations are ignored by inference engines, they are machine processable. For example, you could use SPARQL to find all the comments that have a particular string in them. There are commercial tools using natural language processing that read and processes the comments and labels for a variety of purposes. For example, some tools will do auto-tagging of text documents using the concepts in an ontology as tags. They analyze the comments to find the best match.
1. Annotation properties are much like datatype and object properties. The main difference is that they do not participate in inference.
2. The most commonly used annotations are for labels and comments.
3. Annotations are a good way to create synonyms and abbreviations
4. Annotations with literals as values are typically strings, but they can be of any datatype.
5. Like object properties, annotations can also have IRIs as values.
4.11 SUMMARY LEARNING
Properties, Relationships, and Sets
OWL properties are used to represent real-world relationships. They are the glue that holds the Semantic Web together. Properties are stand-alone first-class objects that do not belong to any class and are broadly reusable. Underneath the covers, a property is a set of ordered pairs, just like classes are sets of individuals. Both subclasses and subproperties correspond to subsets.
Property Semantics
The semantics for a property can be specified in a number of ways. The subproperty relationship gives rise to a property hierarchy in the same way that the subclass relationship gives rise to a class hierarchy.
Special care must be taking when using domain and range, which indicate the kinds of things that are related. Don’t think of them as integrity constraints. Don’t specify them too narrowly, it limits reuse. Also, multiple domains or ranges implies intersection.
Properties can have one or more of a variety of characteristics, such as being functional, symmetric or transitive. A functional property can have only one value, a symmetric property is its own inverse and a transitive property allows inference along a chain of uses of the same property. Property chains use other properties to specify the semantics of a given property.
Inverse Properties
Order matters for properties. If you flip the subject and object, the property typically will not hold. Being a subsidiary is different from having a subsidiary. By flipping the subject and object, the inverse of a property is representing the same relationship from the opposite perspective. You can create explicit inverse properties, or you can use an expression to refer to a property’s inverse. Create explicit inverses only when you need them. There are some downsides.
Data Properties
A data property is just like an object property, but it only connects an individual to a literal, not to another individual. Data properties cannot have inverses. Sometimes it is not clear whether to use a data property or object property. If you think you might need to say something about the value, then create an object property because a literal cannot be the subject of a triple.
Disjointness and Equivalence
Properties are sets, so they can be disjoint or equivalent, just like classes can.
Annotation Properties
Annotation properties are used to say things that do not participate in inference, but are accessible to SPARQL. Annotations can have literals or IRIs as values. The most commonly used annotations provided by OWL are rdfs:label and rdfs:comment.
15 https://www.w3.org/TR/mediaont-10/.
16 https://semanticarts.com/blog/named-property-inverses/.
17 https://www.w3.org/TR/owl2-syntax/#Reflexive_Object_Properties.
18 https://www.w3.org/TR/owl2-syntax/#Annotation_Properties or https://www.w3.org/TR/owl2-quick-reference/#Annotations.
19 http://purl.org/goodrelations/v1.
20 See: https://www.w3.org/2009/08/skos-reference/skos.html.