Restrictions provide a concise way to describe a class of individuals in terms of the properties we know that describe the individuals themselves. As we saw in the previous chapter, we can use this construct to define notions like Vegetarian (describing someone in terms of they type of food that they eat), to sift information from a table (describing something according to a value of one property), and to manage groups of people or terms (describe something based on its membership in a group). The restrictions defined in Chapter 9 are powerful methods for defining classes of individuals.

In this chapter, we see that OWL augments this capability with a full set theory language, including intersections, unions, and complements. These can be used to combine restrictions together (e.g., the set of planets that go around the sun and have at least one moon) or to combine the classes we use to define restrictions (a Vegetarian is someone who eats food that is not Meat). This combination provides a potent system for making very detailed descriptions of information.

OWL also includes restrictions that refer to cardinalities—that is, referring to the number of distinct values for a particular property some individual has. So we can describe “the set of planets that have at least three moons” or “the teams that contain more than one all-star player.” Reasoning with cardinalities in OWL is surprisingly subtle. Perhaps not surprising, when one considers that reasoning is taking place under the Open World assumption and the NonUnique Naming assumption.

Perhaps we shouldn’t be surprised that it is difficult to count how many distinct things there are when one thing might have more than one name (i.e., more than one URI), and we never know when someone might tell us about a new thing we didn’t know about before. These are the main reasons why cardinality inferencing in OWL is quite conservative in the conclusions it can draw.

UNIONS AND INTERSECTIONS

We begin with the basic logical combinations, which are familiar from set theory. OWL provides a facility for defining new classes as unions and intersections of previously defined classes. All set operations can be used on any class definition at all in OWL, including named classes and restrictions. This allows OWL to express a wide variety of combinations of classes and conditions. The semantics for the constructors is as one would expect, matching the set operations of the same name.

Syntactically, they use the list constructs of RDF, as follows:

U1 a owl:Class;

owl:unionOf (ns:Ans:B …).

I1 a owl:Class;

owl:intersectionOf (ns:A ns:B …).

The union of two or more classes includes the members of all those classes combined; the intersection includes the members that belong to every one of the classes.

The intersection of two (or more) classes is a new class; this can be represented in OWL/RDF by either naming that class (as just shown) or by defining an anonymous class (an individual of type owl:Class), which is defined to be the intersection of other classes using the property owl:intersectionOf (likewise owl:unionOf). An anonymous class of this sort can be used again in a model by naming using owl:equivalentClass, as follows:

bb:MajorLeagueBaseballPlayer owl:equivalentClass

[a owl:Class;

owl:intersectionOf

(bb:MajorLeagueMember bb:Player bb:BaseballEmployee)].

Although the semantics of intersectionOf and unionOf are straightforward, they have a particular application to Semantic Web modeling when used in conjunction with restrictions.

Natural language descriptions of restrictions often have a notion of intersection built-in. “All planets orbiting the sun” is actually the intersection of all things that orbit the sun (hasValue restriction) and all planets. The set of major league baseball players is the intersection of the things that play on a major league team (someValuesFrom restriction) and baseball players. Intersections work just as well on restrictions as they do on named classes; we can define these things directly using intersections:

:SolarPlanet a owl:Class;

owl:intersectionOf (

:Planet

[a owl:Restriction;

owl:onProperty :orbits;

owl:hasValue :TheSun

]).

:MajorLeagueBaseballPlayer a owl:Class;

owl:intersectionOf (

:BaseballPlayer

[a owl:Restriction;

owl:onProperty :playsFor;

owl:someValuesFrom :MajorLeagueTeam

]).

Closing the World

A key to understanding how set operations and counting works in OWL is the impact of the Open World Assumption. Not only does it make counting difficult, but even the notion of set complement is subtle when you assume that a new fact can be discovered at any time. Who’s to say that something isn’t a member of a class when the very next statement might assert that it actually is? Fortunately, there are ways in OWL to assert that certain parts of the world are closed; in such situations, inferences having to do with complements or counting become much clearer.

Consider, for example, the following bit of dialogue:

RIMBAUD: I saw a James Dean movie last night.

ROCKY: Was it Giant?

RIMBAUD: No.

ROCKY: Was it East of Eden?

RIMBAUD: No.

ROCKY: James Dean only made three movies; it must have been Rebel Without a Cause.

RIMBAUD: Yes, it was.

This sort of inference relies on the fact that James Dean made only three movies. In light of the open world assumption, how can we make such a claim? After all, in an open world, someone could come along at any time and tell us about a fourth James Dean movie. We will use the example of James Dean’s movies to illustrate how OWL provides a controlled means for modeling closed aspects of the world.

Enumerating Sets with owl:oneOf

In the James Dean example, it wasn’t necessary that we reject the open world assumption completely. We simply needed to know that for a particular class (James Dean movies), all of its members are known. When one is in a position to enumerate the members of a class, a number of inferences can follow.

OWL allows us to enumerate the members of a class using a construct called owl:oneOf, as shown here:

ss:SolarPlanet rdf:type owl:Class;

owl:oneOf (ss:Mercury ss:Venus ss:Earth

ss:Mars ss:Jupiter ss:Saturn

ss:Uranus ss:Neptune).

The class SolarPlanet is related via the property owl:oneOf to a list of the members of the class. Informally, the meaning of this is that the class SolarPlanet contains these eight individuals and no others. owl:oneOf places a limit on the AAA slogan. When we say that a class is made up of exactly these items, nobody else can say that there is another distinct item that is a member of that class. Thus, owl:oneOf should be used with care and only in situations in which the definition of the class is not likely to change—or at least not change very often. In the case of the solar planets, this didn’t change for 50 years. We can probably expect that it won’t change again for quite a while.

Although owl:oneOf places a limitation on the AAA slogan and Open World assumption, it places no limitation on the Nonunique Naming assumption. That is, owl:oneOf makes no claim about whether, say, Mercury might be the same as Venus.

When combined with owl:someValuesFrom, owl:oneOf provides a generalization of owl:hasValue. Whereas owl:hasValue specifies a single value that a property can take, owl:someValuesFrom combined with owl:oneOf specifies a distinct set of values that a property can take.

This inference differs from the inferences that we have seen so far. Up to this point, we were able to express inferences in terms of new triples that can be inferred. In this case, the inference tells us that some triple from a small set holds, but we don’t know which one. We can’t assert any new triples, and we can’t respond to a query any differently.

How do we turn this kind of inference into something from which we assert a triple? If we compare where we are now with the conversation between Rocky and Rimbaud, we are right at the point where Rocky has heard from Rimbaud that he saw a James Dean Movie. Rocky doesn’t know which movie he has seen, but because of his background knowledge, he knows that it was one of three movies. How does Rocky proceed? He eliminates candidates until he can conclude which one it is. To do this in OWL, we must be able to say that some individual is not the same as another.

Differentiating Individuals with owl:differentFrom

There’s an old joke about the three major influences on the price of a piece of real estate: location, location, and location. The joke is, of course, that when you promised to name three influences, any reasonable listener expects you to give three different influences. Because of the nonunique naming assumption in the Semantic Web, we have to be explicit about these things and name things that are, in fact, different from one another. OWL provides owl:differentFrom for this. Its use is quite simple: To assert that one resource is different from another requires a single triple:

ss:Earth owl:differentFrom ss:Mars.

Informally, this triple means that we can rely on the fact that ss:Earth and ss:Mars refer to different resources when making arguments by counting or by elimination. Formally, owl:differentFrom supports a number of inferences when used in conjunction with other constructs like owl:cardinality and owl: oneOf, as we shall see.

We can see these assertions and the inference in Figure 10-1.

DIFFERENTIATING MULTIPLE INDIVIDUALS

The nonunique naming assumption allowed us to use a new resource—RimbaudsMovie—to stand in for an indeterminate movie. With appropriate use of modeling constructs, we were able to get inferences about which movie it actually was, using owl:sameAs to indicate the answer. The nonunique naming assumption applies to all resources. For instance, even though we intuitively know that ss:Earth and ss:Mars do not refer to the same thing, we need to state that in our model. We did this before using owl:differentFrom. We also want to say that ss:Earth is different from ss:Jupiter and ss:Venus, ss:Venus is different from ss:Mars, and so on.

To simplify the specification of lists of items, all of which are different from one another, OWL provides owl:AllDifferent and owl:distinctMembers—two constructs. Using these, we will specify that a list of individuals is distinct from one another. The list of items is specified as an RDF list. We specify that this list should be treated as a set of mutually different individuals by referring to it in a triple using owl:distinctMembers as a predicate. The domain of owl:distinctMembers is owl:AllDifferent.

It is customary for the subject of an owl:distinctMembers triple to be a bnode, so the statement that all eight planets are mutually distinct would be expressed in N3 as

[a owl:AllDifferent;

owl:distinctMembers (ss:Mercury

ss:Venus

ss:Earth

ss:Mars

ss:Jupiter

ss:Saturn

ss:Uranus

ss:Neptune)].

Formally, this is the same as asserting the 28 owl:differentFrom triples, one for each pair of individuals in the list. In the case of James Dean’s movies, we can assert that the three movies are distinct in the same way:

[a owl:AllDifferent;

owl:distinctMembers (:EastOfEden

:Giant

:Rebel)].

The view of this bit of N3 in terms of triples is shown in Figure 10-2. The movies are referenced in an RDF list (using rdf:first and rdf:next to chain the entities together). For longer lists (like the planets), the chain continues for each entity in the list.

Earlier we saw that the class JamesDeanMovie was defined using owl:oneOf to indicate that these are the only James Dean movies in existence. Now we have gone on to say that additionally these three movies are distinct. It is quite common to use owl:oneOf and owl:allDifferent together in this way to say that a class is made up of an enumerated list of distinct elements.

CARDINALITY

So far, we have seen restrictions that define classes based on the presence of certain values for given properties. OWL allows a much finer-grained way to define classes, based on the number of distinct values a property takes. Such a restriction is called a cardinality restriction. This seemingly simple idea turns out to have surprising subtlety when modeling in OWL. Cardinality restrictions allow us to express constraints on the number of individuals that can be related to a member of the restriction class. For example, a baseball team has exactly nine (distinct) players. A person has two (biological) parents. Cardinality restrictions can be used to define sets of particular interest, like the set of one-act plays or the set of books that are printed in more than one volume.

The syntax for a cardinality restriction is similar to that for the other restrictions we have already seen. Here is the restriction that defines the class of things that have exactly nine players:

[a owl:Restriction;

owl:onProperty :hasPlayer;

owl:cardinality 9]

Of course, instead of 9, we could have any nonnegative integer. We can also use cardinality restrictions to specify upper and lower bounds:

[a owl:Restriction;

owl:onProperty :hasPlayer;

owl:minCardinality 10]

and

[a owl:Restriction;

owl:onProperty :hasPlayer;

owl:maxCardinality 2]

These specify the set of things that have at least 10 players and at most 2 players, respectively. Specifying that the owl:cardinality is restricted to n is the same saying that both the owl:minCardinality and owl:maxCardinality are restricted to the same value n. Cardinality refers to the number of distinct values a property has; it therefore interacts closely with the nonunique naming assumption and owl:differentFrom.

The semantics of cardinality restrictions are similar to those of other restrictions. If we can prove that a individual has exactly (respectively at least, at most) n distinct values for the property P, then it is a member of the corresponding owl:cardinality (respectively owl:minCardinality, owl:maxCardinality) restriction. So a rugby union team (with 17 players) and a soccer team (with 11) are both members of the restriction class with minimum cardinality 10; a bridge team (with two players) is not, though it is a member of the restriction class with max cardinality 2.

Similarly, if we assert that something is a member of an owl:cardinality restriction, then it must have exactly n distinct values for the property P.Soif we define a baseball team to be a subclass of the restriction class with exact cardinality 9, we can conclude that a baseball team has exactly nine (distinct) players. Similar conclusions follow from restrictions on minimum and maximum cardinality. We will demonstrate the use of cardinality restrictions through a series of challenge problems based on the James Dean example.

This triple can be inferred from the model because all the values of the property ownsMovie for Rocky come from the class JamesDeanMovie, and there are only three of them, and they are all distinct, so Rocky can own at most three movies. This inference is shown in Figure 10-3.

These assertions and inferences can be seen in Figure 10-4.

Small Cardinality Limits

OWL provides the facility to use any natural number as a cardinality. We have seen how this provides an inference engine with the information needed to determine membership in a class based on counting the number of distinct individuals that satisfy some condition. The particular restrictions of cardinalities to the small numbers 0 and 1 have special modeling utility.

minCardinality 1: The restriction of the minCardinality to 1 indicates the set of individuals for which some for the specified property is required. The Restriction onProperty ownsMovie minCardinality 1 explicitly specifies the set of individuals that own at least one movie.

maxCardinality 1: The restriction of maxCardinalilty to 1 specifies that a value is unique (but need not exist). The Restriction onProperty ownsMovie maxCardinality 1 explicitly specifies the set of individuals who own at most one movie—in other words, they have limited themselves to a single movie.

minCardinality 0: The restriction of the minCardinality to 0 describes a set of individuals for which the presence of a value for the onProperty is optional. In the semantics of OWL, this is superfluous (since properties are always optional anyway), but the explicit assertion that something is optional can be useful for model readability. The Restriction onProperty ownsMovie minCardinality 0 explicitly specifies the set of individuals for which owning a movie is optional.

maxCardinality 0: The restriction of the maxCardinality to 0 indicates the set of individuals for which no value for the specified property is allowed. The Restriction onProperty ownsMovie maxCardinality 0 explicitly specifies the set of individuals that own no movies.

These four special cases of cardinality are closely related. minCardinality 1 and maxCardinality 0 form a partition of minCardinality 0; that is, minCardinality 1 and maxCardinality 0 are disjoint from one another, they are both subclasses of minCardinality 0, and together (minCardinality 1 union maxCardinality 0) they make up all of minCardinality 0 (which is equivalent to owl: Thing, the class of all individuals).

SET COMPLEMENT

The complement of a set is the set of all things not in that set. The same definition applies to Classes in OWL. The complement of a class is another class whose members are all the things not in the complemented class. Since a complement applies to a single class, we can define it using a single triple:

ex:ClassA owl:complementOf ex:ClassB.

Although set complements seem quite straightforward, they can be easily misused, and OWL (like any formal system) can be quite unforgiving in such situations.

For example, we might be tempted to say that minor league players are the complement of major league players (asserting that there are just these two types of players and that nobody can be both).

bb:MinorLeaguePlayer owl:complementOf bb:MajorLeaguePlayer.

From this description, all of the players who are not bb:MajorLeaguePlayers will be included in bb:MinorLeaguePlayer. However, the complement class includes everything that is not in the referred class, so in addition to hopeful rookies, the class bb:MinorLeaguePlayer includes managers, fans, and indeed anything else in the universe, like movies or planets.

To avoid such a situation, common practice is not to refer to complementary classes directly. Instead, it is common practice to combine complement with intersection.

bb:MinorLeaguePlayer owl:intersectionOf

([a owl:Class;

owl:complementOf bb:MajorLeaguePlayer]

bb:Player).

That is, a MinorLeaguePlayer is a Player who is not a MajorLeaguePlayer.

Thus, members of bb:MinorLeaguePlayer include only members of the class bb:Player but does not include players that are included in bb:MajorLeaguePlayer. This is much closer to the natural meaning suggested by the name. This definition makes use of a bnode to specify an anonymous class. There is no need to name the class that is the complement of bb:MajorLeaguePlayer, so it is specified anonymously using the bnode notation ”[a owl:Class …].”

These assertions and conclusion can be seen in Figure 10-5.

DISJOINT SETS

We have seen how we can use owl:complementOf to describe the class that includes all the individuals that are not in some class. A related idea is that two sets have no individual in common. When this happens, we say that the sets are disjoint, and we represent this situation in OWL using owl:disjoint-With, as follows:

:Man owl:disjointWith :Woman.

:Meat owl:disjointWith :Fruit.

:Fish owl:disjointWith :Fowl.

For any members of disjoint classes, we can infer that they are owl:different-From one another—for instance, we might assert that

:Irene a :Woman.

:Ralph a :Man.

we can infer that

:Irene owl:differentFrom :Ralph.

This simple idea can have powerful ramifications when combined with other constructs in OWL, as we can see in the following challenge problems.

These assertions and inferences can be seen in Figure 10-6.

Notice how owl:someValuesFrom interacts with cardinality; each restriction of someValuesFrom guarantees the existence of one value for the specified property. When these values are known to be distinct, we can count (at least) one per someValuesFrom restriction.

Just as we had owl:AllDifferent as a way to specify that several individuals are mutually distinct, we could have something like owl:AllDisjoint to indicate that a set of classes are mutually disjoint. As it happens, the OWL standard did not include such a construct, though some proposals for extensions to OWL include such a facility.

PREREQUISITES REVISITED

We have already explored how prerequisites can be modeled in OWL using owl:allValuesFrom. At that point, we had a problem with the Open World Assumption—namely, how can we tell that all prerequisites have been satisfied if we have to assume that someone can come along and set new prerequisites at any time? We’ll use prerequisites to demonstrate a number of ways we can close the world.

As a reminder from Chapter 9, we modeled the fact that something that has all its prerequisites satisfied (i.e., selected) is an EnabledQuestion as follows:

q:hasPrerequisite a owl:ObjectProperty.

[a owl:Restriction;

owl:onProperty hasPrerequisite;

owl:allValuesFromq:SelectedAnswer]

rdfs:subClassOf q:EnabledQuestion.

If something satisfies the restriction (all its values are members of Selected-Answer), then it is also a member of EnabledQuestion.

No Prerequisites

Let’s start with the simple situation in which we know that there are no prerequisites at all. If something has no prerequisites, then there are no conditions to be checked, so it should be an EnabledQuestion. How can we know that something has no prerequisites?

We can assert the number of distinct values that an individual has for some property by using the cardinality restrictions. In particular, if we say that

c:WhatProblem a [a owl:Restriction;

owl:onProperty q:hasPrerequisite;

owl:cardinality 0].

Then we know that there are no triples of the form

c:WhatProblemq:hasPrerequisite ?.

That is, WhatProblem has no prerequisites. Therefore it satisfies the restriction

c:WhatProblem a [a owl:Restriction;

owl:onProperty hasPrerequisite;

owl:allValuesFrom q:SelectedAnswer].

hence

c:WhatProblem a q:EnabledQuestion.

The interpretation of owl:allValuesFrom in such a situation—that is, when we know that there are no values from the indicated class (or even no values at all!) can be a bit confusing. If there are no values at all, how can all of them be members of some class? The correct way to think about owl:allValuesFrom is as something that sets prerequisites, regardless of the name of the restricted property. Let’s take a simple example: If a person has no children, then all of their children are boys.

First we define the set of people all of whose children are boys, with an allValuesFrom restriction:

:ParentOfBoysOnly owl:equivalentClass

[a owl:Restriction;

owl:onProperty :hasChild;

owl:allValuesFrom :Boy].

How do we decide about membership in this class? Each triple with predicate hasChild places a prerequisite for its subject to be a member of the class. So the triple

:ElizabethII :hasChild :Charles.

places a prerequisite for ElizabethII to be a member of ParentOfBoysOnly—namely, that Charles must be a Boy. In this case, the prerequisite is satisfied.

But in order for ElizabethII to be a member of ParentOfBoysOnly, all prerequisites must be satisfied. In particular, if we assert that

:ElizabethII :hasChild :Anne.

we have a prerequisite that isn’t satisfied, so we won’t be able to infer that ElizabethII is a member of ParentOfBoysOnly.

How can we ever know in the face of the Open World Assumption that all prerequisites will be satisfied? One way is if we assert that there are none. For instance, Elizabeth’s famous ancestor, ElizabethI, was famous for having died childless. We can assert this in OWL by asserting her membership in a restriction class of cardinality 0, thus:

:ElizabethI a [a owl:Restriction;

owl:onProperty :hasChild;

owl:cardinality 0].

Now we know that there are no prerequisites on ElizabethI, so we can infer

:ElizabethI a :ParentOfBoysOnly.

Many people find this result counterintuitive—that someone with no children would have all of their children be boys. This conclusion is much more intuitive if you think of owl:allValuesFrom as working with prerequisites; it is intuitive to say that something that has no prerequisites is satisfied. In the semantics of OWL, this is the appropriate interpretation of owl:allValuesFrom.

Counting Prerequisites

Another way to determine that something has satisfied all of its prerequisites is to count how many of them there are. Just as we have done with counting James Dean movies, we can count prerequisites. Suppose we know that something has exactly one prerequisite:

TvSymptom a [a owl:Restriction;

owl:onProperty hasPrerequisite;

owl:cardinality 1].

and that, furthermore, we actually know one prerequisite, and its type:

TvSymptomq: hasPrerequisite d:STV.

d:STV a q:SelectedAnswer.

We know that one of the prerequisites is a member of the class q:SelectedAnswer. We also know that there aren’t any others (since the cardinality says there is just one of them). So we know that all of the prerequisites are members of the class q:SelectedAnswer:

c:TVSymptom a [a owl:Restriction;

owl:onProperty hasPrerequisite;

owl:allValuesFrom q:SelectedAnswer].

Just as in the James Dean examples, we can make inferences from larger counts if we know that all the entities are different. If we know, for example, that

c:TVTurnedOn a [a owl:Restriction;

owl:onProperty hasPrerequisite;

owl:cardinality 2].

c:TVTurnedOn q:hasPrerequisite c:TVSnothing.

c:TVTurnedOn q:hasPrerequisite c:STVSnosound.

c:TVSnothing owl:differentFrom c:STVSnosound.

c:TVSnothing a q:SelectedAnswer.

c:STVSnosound a q:SelectedAnswer.

we can infer that

c:TVTurnedOn a [a owl:Restriction;

owl:onProperty hasPrerequisite;

owl:allValuesFromq:SelectedAnswer].

since there are only two prerequisites, and we know which two they are.

Guarantees of Existence

The issue of prerequisites revealed a subtlety in the interpretation of owl: allValuesFrom—namely, that the membership of an individual A in an allValuesFrom restriction on property P does not guarantee that any triple of the form

AP ?.

exists at all. What should be the corresponding situation in the case of someValuesFrom? That is, if we say that an individual A is a member of a restriction onProperty P someValuesFrom another class C, should we insist that there is some triple of this form?

AP ?.

The interpretation of someValuesFrom is that we do know that there is a pair of triples of the form

A PX.

X rdf:type C.

Evidently, if we have both of these triples, then we certainly have a triple of the desired form. That is, in contrast to allValuesFrom, someValuesFrom does guarantee that some value is given for the specified property.

The case for hasValue is even more evident than that for someValuesFrom. Not only does hasValue guarantee that there is such a triple, but it even specifies exactly what it is. That is, if A is a member of the restriction onProperty P hasValue X, we can infer the triple

APX.

CONTRADICTIONS

These assertions are shown in Figure 10-7; no inferences are shown, since the model contains a contradiction.

The OWL semantics can tell us that there is a contradiction in this example, but it cannot tell us which assertion is wrong. The validity of an assertion has nothing to do with the OWL standard or its semantics; it has to do with the domain that is being modeled. Did Rocky lie about owning only James Dean movies? Or is he lying now about owning Judy Garland movies? Or, perhaps we are mistaken, and there is a Judy Garland/fames Dean collaboration out there that nobody knows about (that is, we were mistaken when we said that these two classes were disjoint). There is no way to know which of these statements is incorrect. But OWL can tell us that their combination results in a contradiction.

The notion of contradiction gets to the heart of what we mean by modeling. A model is a description of the world and can be mistaken; that is, the model may not actually correspond to the actual state of affairs. The tools that surround OWL models help us to determine the nature of our models. If they are logically inconsistent, then we know that either our model is defective or our understanding of how it relates to the world is mistaken.

UNSATISFIABLE CLASSES

A contradiction arises when the assertions that have been made simply cannot all be true. There is a fundamental disagreement in the asserted statements. A similar situation can arise when we define a class in an inconsistent way. A slight variation on the previous example shows how this can happen. First, suppose we define the class of people who own Judy Garland movies that Rocky claims to be a member of:

:JudyGarlandMovieOwner owl:equivalentClass

[a owl:Restriction;

owl:onProperty :ownsMovie;

owl:someValuesFrom :JudyGarlandMovie].

Now, instead of claiming that Rocky is a member of both this class and James-DeanExclusive, let’s define the class of such people:

:JDJG owl:intersectionOf

(:JudyGarlandMovieOwner :JamesDeanExclusive).

Rocky has claimed to be a member of this class; this claim led to a contradiction.

We can define this class without asserting that Rocky is a member of it. Although this does not lead to a contradiction, the same argument that showed that Rocky cannot (consistently) be a member of this class can be used to show that nothing can be a member of this class, or that this class is empty. When we can prove that a class is empty, we say that the class itself is unsatisfiable. Although a contradiction indicates that some statement in the model is in conflict with others, an unsatisfiable class simply means that there can be no individuals who are members of that class. Of course, if we go on to assert that some individual is a member of an unsatisfiable class (as Rocky did, when he claimed to be a member of JDJG), and then the model contains a contradiction.

Figure 10-8 shows these assertions and the conclusions that follow. JDJG is a subclass of both JudyGarlandMovieOwner and JamesDeanExclusive, since it is defined as the intersection of these two classes. But it is also inferred to be subclass of owl:Nothing. This indicates in OWL that it can have no members, since owl:Nothing is the class that corresponds to the empty set.

Propagation of Unsatisfiable Classes

Once a model contains an unsatisfiable class, it is easy for other class definitions to be unsatisfiable as well. Here are a few of the simpler ways in which this can happen:

subclass: A subclass of an unsatisfiable class is itself unsatisfiable. If the subclass could (without contradiction) have an individual member, then so could the superclass.

someValuesFrom: A restriction (on any property) with owl:someValuesFrom an unsatisfiable class is itself unsatisfiable, since owl:someValuesFrom requires that there be some value that the property can indicate.

domain and range: If a property has an unsatisfiable domain or range, then the property becomes basically unusable. Any someValuesFrom restriction on that property is unsatisfiable. If any triple is asserted using that property as predicate, then the model results in a contradiction.

intersection of disjoints: The owl:intersectionOf two disjoint classes is unsatisfiable. The intersection of any class with an unsatisfiable class is unsatisfiable.

Some operations do not propagate unsatisfiable classes; the union of an unsatisfiable class and another class can be satisfiable. A restriction owl:allValuesFrom an unsatisfiable class can still be satisfiable (but none of its members can have any value for the property specified by owl:onProperty in the restriction).

These rules seem intuitive enough in isolation; their usefulness in modeling comes in during analysis of the results of an inference engine. Many inference engines will report on unsatisfiable classes, but in the face of several such classes, it can be difficult to tell just what is going on. Although some engines have tools to assist the modeler in tracking this, the use of these tools requires some understanding of how unsatisfiable classes can arise. This short list is not exhaustive, but it covers most of the common cases.

INFERRING CLASS RELATIONSHIPS

In the previous discussion, most of the inferences we drew were about individuals: Wenger is an Analyst, Jupiter is a Solar Planet, Kaneda is a Star Player, or Shakespeare married Anne Hathaway. In this chapter, we have begun to draw conclusions about classes—for example, JDJG is unsatisfiable. OWL allows us to draw a wide range of conclusions about classes. We can, in some circumstances, infer that one class is a subclass of another or that a class is the domain (or range) of a property. There are countless possibilities for how this can happen, but there are a few common patterns that are worth calling out. We’ll return to our descriptions of baseball teams for examples:

Intersection and subclass: The intersection of two (or more) classes is a subclass of each intersected class. If AllStarBaseballTeam is the intersection of AllStarTeam and BaseballTeam, then it is also rdfs:subClassOf each of those classes.

Union and subclass: The union of two (or more) classes is a superclass of each united class. If JBallTeam is the union of PacificLeagueTeam and CentralLeagueTeam, then PacificLeagueTeam and CentralLeagueTeam are both rdfs:subClassOf JBallTeam.

Complement and subclass: Complement reverses the order of subclass. For example, if AllStarBaseballTeam is a subclass of BaseballTeam, then the complement of BaseballTeam is a subclass of the complement of AllStarBaseballTeam.

Subclass propagation through restriction: The subclass relationships propagate through restrictions. If AllStarBaseballTeam is a subclass of BaseballTeam, then the restriction (on any property—say, playsFor) owl:allValuesFrom AllStarBaseballTeam is a subclass of the restriction (on the same property playsFor) owl:allValuesFrom BaseballTeam. Ifwe call the first restriction AllStarBaseballPlayer and the second restriction BaseballPlayer (both are reasonable names for these restrictions), then this pattern says that AllStarBaseballPlayer is a subclass of BaseballPlayer. The same propagation principle holds for any property and also for owl:someValuesFrom; If AllStarBaseballTeam is a subclass of BaseballTeam, then the restriction on property playsFor some values from AllStarBaseballTeam is a subclass of the restriction on property playsFor some values from BaseballTeam.

hasValue, someValuesFrom, and subClassOf: Propagation for owl:has Value works a bit differently from the way it works for owl:allValuesFrom or owl:someValuesFrom, since owl:hasValue refers to an individual, not a class. Suppose that the individual TokyoGiants is a member of classBaseballTeam; the restriction on property playsFor owl:hasValue Tokyo Giants is a subclass of the restriction on property playsFor owl:some ValuesFrom BaseballTeam.

Relative cardinalities: Subclass relations between cardinality restrictions arise from the usual rules of arithmetic on whole numbers. For example, if a ViableBaseballTeam must have at least nine players on its roster (owl:minCardinality 9), and a FullBaseballTeam has exactly 10 players on the roster (owl:cardinality 10), then FullBaseballTeam is a subclass of ViableBaseballTeam.

owl: someValuesFrom and owl:minCardinality: If we say that something has some value from a particular class, then we can infer that it has at least one such value. So if BaseballTeam has some pitcher (i.e., BaseballTeam is a subclass of the restriction owl:onProperty hasPlayer owl:someValuesFrom Pitcher), we can infer that it has at least one pitcher (i.e., BaseballTeam is a subclass of the restriction owl:onProperty hasPlayer owl:minCardinality 1). Note that the same conclusion does not hold for owl:allValuesFrom; in short, someValuesFrom guarantees that there is some value; allValuesFrom makes no such guarantee.

The logic underlying OWL goes beyond these propagation rules and encompasses inferences about subclasses regarding cardinalities. The technical details of the logic are beyond the scope of this book. In short, any class relationship that can be proven to hold, based on the semantics of restrictions, unions, intersections, and so on, will be inferred. The propagation patterns presented here don’t cover all the possible class relationship inferences, but they are the most common patterns that appear in semantic models.

The ability in OWL to infer class relationships enables a style of modeling in which subclass relationships are rarely asserted directly. Instead, relationships between classes are described in terms of unions, intersections, complements and restrictions, and the inference engine determines the class structure. If more information is learned about a particular class or individual, then more class structure can be inferred. Subclass relationships are asserted only in that the members of one class are included in another.

The baseball model demonstrates this principle at work-we summarize the statements about baseball players and their teams in Table 10-1.

In Table 10-1, we write ≡ if the class in the left column is defined as equivalent to the expression in the right column, and ⊆ if the class is a subclass of the expression in the right column. Notice that the only direct subclass assertion (i.e., one class is a subclass of another) is for JBallTeam, which is asserted to be a subclass of BaseballTeam. All other assertions in the model either refer to logical combinations (intersections or unions) or to restrictions. Thus, the class tree as asserted is shown in Figure 10-9.

We can infer a number of subclass relationships from the definitions of the model in Table 10-1 and the subclass inferencing patterns we have seen.

Since AllStarBaseballTeam is the intersection of BaseballTeam and AllStarTeam, then AllStarBaseballTeam is a subclass of BaseballTeam and AllStarTeam.

Both AllStarBaseballPlayer and AllStarPlayer are someValuesFrom restrictions on the same property, playsFor, referencing AllStarBaseballTeam and AllStarTeam, respectively. The fact that AllStarBaseballTeam is a subclass of AllStarPlayer can be propagated, so we can infer that AllStarBaseballPlayer is a subclass of AllStarPlayer. Similar reasoning allows us to infer that AllStarBaseballPlayer is a subclass of BaseballPlayer.

Since JBallTeam is the union of PacificLeagueTeam and CentralLeagueTeam, we can conclude that PacificLeagueTeam and CentralLeagueTeam are subclasses of JBallTeam.

Since the Hiroshima Carp is a CentralLeague team, it is also a JBallTeam and thus a BaseballTeam. A CarpPlayer is a hasValue restriction on the Carp; thus, we can infer that CarpPlayer is a subclass of BaseballPlayer.

The domain of playsFor is also used to make class inferences. Since AllStarPlayer is equivalent to the someValuesFrom restriction onProperty playsFor, any individual member of AllStarPlayer playsFor some team. But the domain of playsFor is Player, so that individual must also be a Player. We have just shown that any AllStarPlayer must be a Player; thus, AllStarPlayer is a subclass of Player.

Even the range information gets into the act; since an AllStarTeam employs some AllStarPlayer, and since employs is the inverse of playsFor, that means that some person playsFor any AllStarTeam. But the range of playsFor is Team, so AllStarTeam must be a team, as well.

We can see the inferred class structure in Figure 10-10. Notice that every class is involved in some class inferencing pattern so that in contrast to the asserted model, the inferred model has considerable depth to its class tree.

REASONING WITH INDIVIDUALS AND WITH CLASSES

From an RDF perspective, inferencing about individuals and inferencing about classes is very similar. In both cases, new triples are added to the model based on the triples that were asserted. From a modeling perspective, the two kinds of reasoning are very different. One of them draws specific conclusions about individuals in a data stream, while the other draws general conclusions about classes of individuals. These two kinds of reasoning are sometimes called A-box reasoning (for individuals) and T-box reasoning (for classes). The curious names A-box and T-box are historical and no longer have any relevance.

The utility of reasoning about individuals in a Semantic Web context is clear, and we have seen a number of examples of it throughout this book. We inferred things about the wife of Shakespeare, which movies belong to which people, and what terms are broader than others. All of these things are examples of reasoning about an individual. Information specified in one information source is transformed according to a model for use in another context. Mappings from one context to the next are specified using constructs like rdfs:subClassOf, rdfs:subPropertyOf, and various owl:Restrictions. Data can then be transformed and processed according to these models and the inferences specified in the RDFS and OWL standards for each of them.

The utility of reasoning about classes is more subtle. It can take place in the absence of any data at all! Class reasoning determines the relationships between classes of individuals. It determines how data are related in general. In advance of seeing any data about the Pacific League, we can determine that any team in that league is a baseball team. There is no need to process all the particular teams, or indeed any of them. We can guarantee that this is the case. Even if new teams join the league, we know that this will still be true. In this sense, class reasoning is similar to a compilation of the model. Whereas individual reasoning processes particular data items as input, Class reasoning determines general relationships among data and records those relationships with rdfs:subClassOf, rdfs:subPropertyOf, rdfs:domain, or rdfs:range. Once these general relationships have been inferred, processing of individual data can be done much more easily.

When we use individual and class reasoning together in a single system, we have a powerful system that smoothly integrates general reasoning with specific data transformations. This allows us to smoothly manage information based on whatever information we come across, generic or specific.

SUMMARY

At each level of our exposition of the Semantic Web languages from RDF to RDFS to the various levels of OWL, we have introduced new notions of how to understand a model. For RDF, the fundamental aspect of the model had to do with data sharing and federation. RDF answers the question “How do I get all the information I know about a single thing in one place?” For RDFS, we introduced the notion of inference, answering the question “Given that I know certain things about my data, what else can I figure out?” RDFS-Plus and the basic use of OWL gave us more comprehensive capabilities to infer new information from old. As we move on to the advanced features OWL, we are still working within the paradigm of inferencing as the source of meaning of our models, but we expand the sort of inferencing we can make to include inferences not just about our data but also about the model itself.

Up to this point, we could, for the most part, ignore the ramifications of the Open World Assumption of the Semantic Web. With the advanced constructs of OWL, where we can draw conclusions based on arguments of enumeration and elimination (as well as arguments based on properties and types, as we did with RDFS and RDFS-Plus), the impact of the open world becomes more apparent.

Armed with the concepts and constructs OWL from this chapter, we are now in a position to examine some more comprehensive OWL models. We can see how a modeler can use the constructs of OWL to describe how data from different sources will be federated on the Semantic Web. Just as we saw for RDFS-Plus, a model can mediate information from sources that have not yet been examined. Advanced OWL provides more powerful and complete ways to make this happen.

Fundamental Concepts

The following fundamental concepts were introduced in this chapter:

owl:unionOf, owl:intersectionOf, owl:complementOf—Basic set operations applied to classes. Each of these is used to create a new class, based on the specified set operation applied to one or more defined classes.

Open World Assumption—This idea was introduced in Chapter 1, but strategies for closing the world for certain purposes were introduced here.

owl:oneOf—Specifies that a class consists just of the listed members

owl:differentFrom—Specifies that one individual is not owl:sameAs another. This is particularly useful when making counting arguments.

owl:disjointWith—Specifies that two classes cannot share a member. This is often used as a sort of wholesale version of owl:differentFrom.

owl:cardinality, owl:minCardinality, owl:maxCardinality—Cardinality specifies information about the number of distinct values for some property. Combined withowl:oneOf, owl:differentFrom, owl:disjointWith, and so on, it can be the basis of inferences based on counting the number of values for a property.

Contradiction—With the advanced constructs of OWL, it is possible for a model to express a contradiction—that is, for a model to be logically inconsistent.

Satisfiability (unsatisfiability)—With the advanced constructs of OWL, it is possible to infer that a class can have no members, so such a class is unsatisfiable.