Classes
In this chapter we review the core concepts about classes that we saw in Chapter 2 and then explore them in more depth.
5.1 REVIEW: CLASSES AND SETS
OWL classes are used to represent different kinds of things such as person and corporation. Mathematically, a class corresponds to a set. All the members of the set share certain properties, which is why they are grouped together into a class. Classes can be arranged into hierarchies using rdfs:subClassOf. The subclass relationship means subset, and it corresponds to logical implication. For example, to say that Nurse is a subclass of Person is precisely to say that:
Finally, Venn diagrams are a helpful way to visualize classes and subclasses (see Figure 4.2).
5.2 CLASS RELATIONSHIPS
There are three main ways that classes can be related to each other, and all correspond to relationships between sets.
1. C1 rdfs:subClassOf C2
2. C1 owl:equivalentClass C2
3. C1 owl:disjointWith C2
5.2.1 SUBCLASS
Subclassing is used to indicate that one class is more specific than another. To say that C1 rdfs:subClassOf C2 is precisely to say that for any individual, x
For example, to say that Corporation rdfs:subClassOf LegalEntity is to say that for any individual, x
This is depicted in Figure 3.1.
5.2.2 CLASS EQUIVALENCE
Class equivalence is used to state that the members of one class are exactly the same as the members of another class. To say that C1 owl:equivalentClass C2 is precisely to say the following two things:
Note that the statement on the left is just what we saw above; it means C1 is a subclass of C2. On the right, the two classes have been swapped, which therefore is the same as saying that C2 is a subclass of C1. Thus to say that two classes are equivalent is really just a shorthand way to say that two classes are subclasses of each other. At the end of Section4.9 we saw the same thing with equivalent properties and subproperty.
If we visualize this in terms of a Venn diagram where the classes are sets, C1 subclass of C2 means that C1 is inside C2, and C2 subclass of C1 means C2 is inside C1. The only way both can be “inside” each other is by having them be identical to each other.
This is related to the idea of proper subset, which means there are individuals that are not in the subset that are in the superset. Using the idea of subclass to define class equivalence tells us that rdfs:subClassOf does not imply proper subset, the sets can be the same.
There are two common uses of class equivalence. The main one is to specify additional meaning using class expressions. An example of this is depicted in Figure 2.9. This is explored in depth in Section 5.3 below. The other use is for stating that two classes from two different ontologies mean the same thing. The latter is not part of building an ontology, but rather of mapping one ontology to another.
5.2.3 DISJOINT CLASSES
Disjointness between classes is used to say that the classes cannot have any individuals in common. To say that C1 owl:disjointWith C2 is to say the following two things:
Recall that “¬” is the symbol for logical negation—it means what follows cannot be true. The term “disjoint” comes from sets that do not share any members.
There are two main uses of class disjointness. One is to communicate to humans more about the meaning of the classes involved. An equally, if not more important, use is to help the inference engine spot logical errors in the ontology. If any individual is asserted to be a member of both classes, the inference engine will detect a logical inconsistency. We saw the pattern using high-level disjoint classes at the very end of Section 2.3.5 and we will see another example in Section 8.2.2.
5.3 CLASS EXPRESSIONS
As discussed in Section 3.1.7, we are familiar with the idea of building up expressions using operators. For example, 4*(11-3) is an expression that indirectly refers to the number thirty-two. The simple expression, “32” is the direct way to refer to the same number. Similarly, a class expression in OWL is an expression consisting of classes and operators that indirectly refers to a class. In Section 2.3, we saw some examples:
1. doe:Organization or doe:Person
2. doe:TwoWheeledVehicle and doe:MotorizedVehicle
3. doe:Person and (doe:careRecipientOn some doe:PatientVisit)
These expressions indirectly refer to classes. Simple expressions that directly refer to classes are plain IRIs such as doe:Person, doe:PatientVisit, and doe:Corporation. They function more as names for classes.
Table 5.1: Expressions in arithmetic and in OWL |
||
Arithmetic |
OWL Classes |
|
Simple Expressions |
An Arabic numeral directly refers to a number, e.g., 3, 32 |
An IRI directly refers to a class, e.g., |
Complex Expressions (indirect reference) |
An expression indirectly refers to a number. |
An expression indirectly refers to a class. |
Just like for arithmetic expressions, the meaning of the expression is derived from the meaning of the parts of the expression. This gives us the ability to encode meaning of a class in terms of other classes, properties and occasionally, individuals. Among the most commonly used class operators are the OWL constructs: owl:intersectionOf, owl:unionOf, and owl:someValuesFrom. In Manchester syntax these constructs show up as “and,” “or,” and “some,” respectively. Furthermore, the meaning of the constructs is available to an inference engine. An IRI by itself, with the addition of some text annotations, allows a human to get a good idea of the intended meaning. However, the inference engine has no access to that meaning.
Everywhere a class is expected in OWL, any class expression can be used (see Table 5.1).
5.3.1 ANONYMOUS CLASSES AND BLANK NODES
Each of the above class expressions describes a class, but they don’t have IRIs or names and are thus called anonymous classes. For each of the above examples, we can think of good names and assign them to the classes, e.g., Party, Motorcycle, and Patient. We use owl:equivalentClass to do that (as we did in Section 2.3).
We want to have a triple with Motorcycle as the subject and owl:equivalentClass as the predicate. Somehow we want to achieve the effect of having an expression with no IRI be the object. Until now, objects of triples have always been either IRIs or literal values. For this, there is a third kind of node, which is used to represent anonymous classes. It is called a blank node. In the Turtle syntax, square brackets enclose a blank node (see below).
A slightly simplified view of the triples are depicted in Figure 5.1. Make sure you can find in the Turtle each of the four triples that are in the figure. Blank node 1 is enclosed in square brackets in the Turtle. Blank node 11 shows up enclosed in round parentheses. The node in the lower right is dotted to indicate there are some missing details that are not important for now.
5.3.2 BOOLEAN EXPRESSIONS
Intersection
In Figure 2.12 we defined Motorcycle to be the intersection of TwoWheeledVehicle and MotorizedVehicle. This involved three steps.
1. Create a class called Motorcycle (using a simple class expression).
2. Create an expression that intersects the two classes.
3. Set Motorcycle to be equivalent to the intersection expression.
Sanctioned Inferences
In terms of sets, the intersection includes just those individuals that are members of both sets. Therefore, the inferences that are justified using the intersection construct are as follows.
From this, and from the definition of rdfs:subClassOf,
Convince yourself that these inferences are justified. You may find it helpful to draw a Venn diagram.
Syntax Variations
So that we can focus more on ease of understanding the meaning and less on the syntax, I am using a mix of Manchester and Turtle syntax. The expression:
is represented in Turtle as follows:
It looks like this, in Manchester syntax:
Note that in the Turtle above it explicitly says that C1 is an instance of owl:Class. However, “rdf:type owl:Class” also appears directly after the open square bracket “[.” That makes explicit that the blank node is also an instance of owl:Class, as depicted in Figure 5.1.
Manchester syntax is widely used in tools for creating class expressions. For most other things, people tend to use Turtle or RDF/XML, with use of the former becoming much more widespread and the latter receding in popularity.
Union
In Figure 2.13 we defined Party to be the union of Person and Organization. This also involved three steps.
1. Create the class Party.
2. Create the expression that is the union of Person and Organization.
3. Set Party to be equivalent to the expression (Party or Organization).
In terms of sets, the union includes just those individuals that are members of either or both sets. Therefore, the following inferences using the union construct are justified.
From 1 and 2 above, and from the definition of rdfs:subClassOf, we can conclude that:
There is one additional inference that is a bit more subtle. We have not yet introduced the OWL constructs needed to represent it in triples, but it works in the following way. If C1 is the union of C2 and C3 as above, and if it can be proven that the triple x rdf:type C2 is false, then the triple x rdf:type C3 is inferred to be true (and vice versa, swapping C2 and C3).
For example, if you know that x is a Party which is defined to be the union of Person and Organization, and you also know that x is not a Person, then x must be an Organization. The Turtle syntax is exactly analogous to that for the intersection example with intersectionOf replaced by unionOf.
Figure 5.2: A simplified view of a blank node representing a union expression.
The final Boolean expression we discuss corresponds to the set complement operation. The complement of a set is defined to be everything that is not in that set. For example, the complement of the set of all organizations, is everything that is not an organization. This includes not only things that are relevant to organizations—such as people, agreements and contracts—but it also includes elephants, drugs, jokes, and pickles—and literally anything else that you can think of (besides organizations, that is). Not surprisingly, the need for this rarely arises, but we include it for completeness.
We saw that owl:intersectionOf corresponds to logical and, and owl:unionOf corresponds to logical or. The construct, owl:complementOf corresponds to logical negation. If an individual is in the set, it is not in the complement of the set, and vice versa.
Sanctioned Inferences
The main inferences that are sanctioned are as follows. For classes C1 and C2:
From the meaning of disjoint classes, we can further conclude that:
The latter triple introduces a new construct that we have not seen before. Its meaning is self evident, but the need to say it may not be. It follows from the fact that OWL does not make the unique name assumption. It is possible for the same individual to have two IRIs. If you know that is the case, you use owl:sameAs to link them; we saw this in Figure 4.13. Note that owl:sameAs and owl:differentFrom are closely related.
Exercise 1: Create Venn diagrams to convince yourself that the inferences for intersection, union, and complement are justified.
5.3.3 ENUMERATION
In all of our examples so far, we have talked about creating classes and then declaring that or determining whether a given individual is or is not a member of that class. We never spoke of a limit as to how may members a class may have.
Sometimes you do know exactly what the members of a class are beforehand, e.g., when placing things into categories. In the U.S., there is a distinction between exempt and non-exempt employees. So you might have a class called ExemptType with just two members corresponding to those two categories.
Another example is the set of the base units in the System Internationale. These include meter, second, candela, ampere, and a few others. There are just so many, and they are not adding new ones any time soon.
The OWL construct for this is called owl:oneOf. It works like this (in Turtle syntax):
Recall that anonymous classes are expressed in Turtle using square brackets and lists are enclosed in round parentheses. The expression using owl:oneOf returns a class with the two members specified. Note that the structure of the Turtle is just like that for intersection and union, except that oneOf is being used in place of intersectionOf or unionOf. Instead of having a list of classes that are all in an intersection or union, there is a list of individuals in the enumerated class.
The Manchester syntax for enumeration is to enclose the individuals in squiggly brackets and separate with commas, like this: {doe:_exempt, doe:_nonExempt}.
Sanctioned Inferences
An enumerated class is closed. This means that if an individual is known to be different from all the enumerated members of a class, then it cannot be a member of the class This is another way of saying it is in the complement of the enumerated class.
Also, if any resource, y, is in fact referring to the same thing as one of the members of the enumerated class, then it is inferred to be a member of the enumerated class.
Another kind of OWL class expression is used to create property restriction classes, which define a class based on how many individuals (or literals) it is connected to by a given object (or data) property. We saw a few examples in Section 2.3.4 (e.g., ThingWithTwoWheels). Restrictions are covered in the next major section.
5.3.5 SUMMARY: CLASS EXPRESSIONS
1. Classes may be defined as expressions using a variety of operators.
2. The main ones are existential and cardinality property restrictions (described in the next section) and the Boolean operators union and intersection.
3. A class expression consists of various combinations of classes, properties, and individuals and the result is a new class which may be used in any OWL expression anywhere a class is expected. For example:
a. as a domain or a range,
b. as a filter class in a property restriction, and
c. in any other Boolean expression.
4. It is possible to nest expressions to arbitrary levels, but doing so gets confusing quickly. Keep things simple.
5. A class expression is not itself a triple, but it can be used in triples where a class is expected. Expressions show up triples as blank nodes, as depicted in Figures 5.1 and 5.2.
5.4 PROPERTY RESTRICTIONS
The Boolean expressions in the prior section are used to formally represent something about what it means to be a member of the class, as reflected by specific inferences that are sanctioned. To be a member of the class Motorcycle, an individual must be a member of two different classes: TwoWheeledVehicle and MotorizedVehicle. This is important, but it begs the questions: what does it mean to be members of those classes? Remember, as a human, you can read into the meaning of the names, but the computer cannot. We have to spell it out.
Central to understanding the meaning of a class is to know what properties members of that class have. For example, every two-wheeled vehicle has two different wheels as parts. To be a patient, an individual must have received care on some patient visit.
In this section we explore a variety of ways that OWL provides to give meaning to classes based on the nature and number of properties that members of the class may, must or must not have. Classes defined this way are called property restrictions. This idea was introduced with several examples in Section 2.3.4.
Below are examples of classes that are naturally defined as restrictions. They exemplify the six main types of restrictions provided by OWL. For each we give the Manchester syntax of one way to model the restriction; it is just what you could type into an ontology editor to create these restrictions.
Existential: The set of all things that cover some party (in the context of insurance). (doe:cover some doe:Party)
Universal: The set of all things that have only physicians as members. (doe:hasMember only doe:Physician)
Minimum cardinality: The set of all things that are verified by at least 2 people. (doe:verifiedBy min 2 doe:Person)
Maximum cardinality: The set of all things that have no more than 3 registered devices. (doe:registeredOn max 3 doe:Device)
Exact cardinality: The set of all things that have exactly two wheels. (doe:hasPart exactly 2 doe:Wheel)
Individual value: The set of all things that are part of Sentara Healthcare. (doe:partOf value :_SentaraHealthcare)
There are other variations that we will describe later in this section.
5.4.1 USAGE SCENARIOS
Because a restriction is a class, it can be used anywhere that classes are used. That includes domain and range as well as anywhere in an expression that uses any combination of intersection, union or complement. However, by far the most common way to use a restriction is when you have a class in mind and you want to add meaning to it using either equivalentClass or subClassOf. If you have a restriction in mind and want to name it with an IRI, you use class equivalence and the restriction provides an exact meaning of the class. If instead you are just interested in ensuring that every member of the class has a particular property, you use subclass.
Restrictions Using Class Equivalence
Class equivalence is deployed when you want to use a restriction as an expression, or as part of an expression that you wish to give a name (i.e., an IRI). A good reason to do this is if you expect to use the class in a number of other places, e.g., in domains and ranges or in larger class expressions.
Earlier we used the class TwoWheeledVehicle in an intersection to define the class MotorCycle. Using a restriction, we can be more explicit about what that means. Delving deeper, a two-wheeled vehicle is both a vehicle and something with two wheels. The latter is naturally represented as an OWL property restriction.
In English, the class TwoWheeledThing is the set of all things that have exactly two parts that are wheels. If there is certainty about having more or fewer than two wheels, an individual is ruled out of the class. In terms of triples, the class TwoWheeledThing is the set of individuals that are the subjects of exactly two triples using the hasPart predicate where the objects of the triples are different from each other and both are of type Wheel. The differentness criteria is important. Two copies of the exact same triple do not count as two wheels. Also, because there is no unique name assumption, if there were two different IRIs for a given wheel then there could be two triples pointing to the same wheel (see Figure 5.3). What is important but is not shown in the figures, is that the pairs (w1, w2), (w3, w4), and (w5, w6) each refer to distinct wheels.
Figure 5.3: Property restrictions using class equivalence.
In principle, the usage pattern is:
1. create a class;
2. create a property restriction; and
3. make the class equivalent to the property restriction.
In practice, ontology-authoring tools often combine steps 2 and 3. For example, in Protégé, you select the class, you click to indicate you wish to create an equivalent class, and then you specify the restriction as an expression (see Figure 5.4).
The result in Manchester syntax is:
When using equivalence, the inference goes both ways. Specifically:
1. if you know an individual is a member of the class, TwoWheeledThing, you know it is connected to exactly two (different) wheels via hasPart; and
2. conversely, at least in principle, if you know that an individual is connected to exactly two (different) wheels via hasPart then you know it is a member of the class TwoWheeledThing. In practice, due to the open world, it is generally not possible to be sure. There might be other wheels not known about.
Exercise 2: Spell out the inferences regarding TwoWheeledThing in a more precise notation using triples.
Restrictions Using Subclass
The second common way to use a restriction is very similar to the first way, except we use subclass instead of equivalence. This achieves the goal of saying that every member of a particular class necessarily has a particular property. It does not say that having that property is sufficient to warrant being a member of that class. In other words unlike equivalence, the inference only goes one direction. For example, an insurance policy necessarily covers one or more parties, be they persons or organizations. To proceed, we create a property restriction using the expression as: “covers some Party,” which refers to “the set of all things that cover some party.” Then we make InsurancePolicy a subclass of this property restriction class. In Manchester syntax:
Because of the meaning of subclass, if an individual is a member of the class InsurancePolicy, then they are also a member of the class “covers some Party,” which means every insurance policy covers at least one party (see Figure 5.5).
Figure 5.5: Property restrictions using subclass.
The inferences sanctioned by this usage scenario are:
The usage pattern is:
1. create a class;
2. create a property restriction; and
3. make the class a subclass of the property restriction.
This is accomplished in Protégé just like the equivalent usage scenario, the only difference is that you click the plus sign next to where it says SubClassOf rather than where it says Equivalent To (see Figure 5.6).
Summary: Property Restriction Usage Scenarios
There are two main usage scenarios for property restrictions. Both entail having a class in mind that you want to add meaning to, and in each case you create the class and you create the restriction. If you are just interested in ensuring that every member of the class has a particular property, you use subclass. If instead you want to give the restriction a name and have the flexibility to use it in other expressions, you use class equivalence. A good example of this is Party, which we defined to be equivalent to the union of Person and Organization. You can just use the class Party as a domain or range or filter class on a restriction instead of repeating the expression “Person or Organization” over and over.
This is very important: read those few sentences again and review the material in this section and at the beginning of Section 2.3.4, in particular, Figure 2.8 until you understand it.
In addition to these two main usage scenarios, keep in mind that because a restriction is a class expression, it may be used anywhere that classes are expected. We already saw one example of this in Figure 2.10 where we defined doe:Patient to be equivalent to the expression:
doe:Person and (doe:careRecipientOn some doe:PatientVisit).
Here the restriction is being used as one of the arguments in a larger intersection expression. You can also have a restriction be the filter class in another restriction. We will see an example of this in Chapter 6.
5.4.2 ANATOMY OF A PROPERTY RESTRICTION
A restriction denotes a set of subjects of triples using a given predicate that satisfy certain conditions. I think of these as the restriction’s grounding triples. They are depicted in thick lines in Figure 5.7. The subjects of the grounding triples in the figure are s1, s2, … sN. Each property restriction has three parts.
1. Property: An object or data property IRI.
2. Type: The type of restriction. We just saw two examples, each indicated by a specific keyword. Existential restrictions use the keyword “some” and exact cardinality restrictions use “exactly N.”
3. Filter: A qualification that constrains what the type of the objects of the restriction’s grounding triples may or must be. The filter is optional for some of the restrictions, and required for others.
Figure 5.7: A restriction is defined in terms of triples.
The first part is straight-forward. The main point of interest is whether it is an object property or a data property. There are six main types of restriction, as laid out in the beginning of this section: existential, universal, three cardinality restrictions (minimum, maximum, and exact), and individual value. The cardinality restrictions require a number to be specified. For example, the restriction that defined TwoWheeledThing was an exact cardinality restriction using the number 2.
For the first five restriction types, the filter is a class for object restrictions and a datatype for data restrictions restrictions. For individual value restrictions, the filter is either an individual or a literal, depending on whether the restriction uses an object or data property, respectively. For brevity, we will at times shorten the terms “data property restriction” and “object property restriction” to “data restriction” and “object restriction.”
The filter is required for universal, existential and individual value restrictions. It is optional for the cardinality restrictions. If a filter is not specified for an object property restriction, it is exactly the same as if the filter class was owl:Thing. When the filter is specified for a cardinality restriction it is called a qualified cardinality restriction. When using common ontology editors to build ontologies, you may not see the term “qualified cardinality” anywhere. You also will not see it if you export the ontology in Manchester syntax. However, it is there if you export it as Turtle or RDF/XML, or if you load it into a triple store.
The anatomy of a restriction as described above is reflected in the Turtle syntax for our two examples below as well as in Figure 5.8.
The class expression in Manchester syntax, “covers some Party,” shows up in Turtle syntax as an expression inside square brackets that represents the anonymous class as a blank node. This anonymous class is an instance of owl:Restriction. The construct owl:onProperty is used to specify the property IRI. The construct owl:someValuesFrom is used to specify the type of restriction (existential), as well as the filter class Party. Manchester syntax is more human readable, Turtle is closer to the actual triples, which is important if you plan to be using SPARQL to query a triple store using the ontology.
Notice that the keyword owl:qualifiedCardinality is used in the first example. There are two aspects to this. First, it needs to be qualified cardinality because there is a filter class (in this case, Wheel). Second, this construct means the number is exact, rather than a minimum or maximum. The OWL keywords for exact, min and max cardinality are owl:qualifiedCardinality, owl:minQualifiedCardinality, and owl:maxQualifiedCardinality, respectively. A more informative keyword for the first construct would have been: owl:exactQualifiedCardinality. We will look into each of these in the sections below.
Notice also that although the filter is in the same place for all restriction types in Manchester syntax, it is different for Turtle. The predicates indicating the type of restriction for existential, universal, and individual value restrictions are owl:someValuesFrom, owl:allValuesFrom, and owl:hasValue. The objects of the triples using these three predicates to define restrictions are all filters. Due to the names of the constructs, people frequently use the terms “some values,” “all values,” and “has value” instead of “existential,” “universal,” and “individual value.” We will follow that convention. For the cardinality restrictions, the predicates indicating the type of restriction are: owl:qualifiedCardinality, owl:minQualifiedCardinality, and owl:- maxQualifiedCardinality. The objects of triples using these predicates to define restrictions are non-negative integers.
Object vs. Data Property Restrictions
Data properties are used in the same way as object properties when creating restrictions. The main difference is that the filter is a datatype, not a class. For the cardinality restrictions, the filter is specified separately, using owl:onClass for object property restrictions and using owl:hasDataRange for data property restrictions.
Figure 5.7 accurately reflects all but one of the restriction types. Not covered are individual value restrictions; they are described in Section 5.4.8. Note that a member of a restriction class can sometimes have more than one triple using the property that matches the filter. That is a question of cardinality.
Figure 5.9: Examples of object and data restrictions.
In every case the restriction defines a class whose members may, must, or must not be the subject of certain numbers of triples using the property as the predicate and the object obeying the filter. In the next sections we will look at these six kinds of OWL restrictions. Each kind works for both object and data properties.
Figure 5.9 depicts two ways to represent the set of individuals with first names. They are examples of the general patterns shown in Figure 5.7. One uses a data property, the other uses and object property. The thicker lines are the grounding triples for the respective restrictions.
5.4.3 EXISTENTIAL: SOMEVALUESFROM
We have seen several examples of this type of restriction already, including the insurance policy example above. In Manchester syntax, the form is: (p some C) where p is a property and C is a class.
Sanctioned Inferences
In the insurance example, this corresponds to:
The phrase “there exists” sheds light on why this is called an “existential” restriction. To represent the fact that every insurance policy covers at least one party, we make the class for insurance policy a subclass of the restriction class, “covers some Party.” We will discuss this kind of inference more in Section 6.4.2.
For data restrictions, it works the same way. The difference is that the filter is not a class, C, but a datatype, D. Also, the typing of a literal does not use rdf:type, rather it is appended to the string connected by the characters “^^”, e.g., “John”^^xsd:string (see Figure 5.9).
5.4.4 UNIVERSAL: allValuesFrom
In healthcare, physicians often band together as groups to negotiate better agreements with insurance companies. So there is a class called PhysicianGroup. We could use an existential restriction to ensure that there is at least one physician as a member. We also don’t want anything else to be a member of a physician group. This is what the universal restriction is for. We want to say that a physician group only has physicians as members. In Manchester syntax, the form is: (p only C) where p is a property and C is a class.
Sanctioned Inferences
In English, it means that a member of the restriction class (p only C) can be connected via property p only to individuals of type C. In the physician example, this expands to:
By making PhysicianGroup a subclass of this restriction, we achieve the intended effect. The use of the term “for all” sheds light on why this is called the universal restriction.
Note that due to the open world, you cannot infer an individual to be a member of an all values from restriction. You could have hundreds of members of a group and all of them might be physicians, but the inference engine leaves open the possibility that there non-physician members that it does not yet know about.
Must a Physician Group Have Members?
A question arises in a situation like this as to whether you want to allow an individual resource to be a PhysicianGroup if it has no members at all. Suppose you don’t. It turns out that the above inference rule for universal restrictions says nothing about this case, it only says what must be true if there are members.
So using a universal restriction on its own, does allow a PhysicianGroup with no members. To force at least one member, just add an existential restriction. You end up making the class PhysicianGroup a subclass of each of the following restrictions “hasMember some Physician” and “hasMember only Physician.” This is a commonly used pattern.
5.4.5 MINIMUM CARDINALITY
Minimum cardinality is a generalization of the someValuesFrom restriction. To say that there is some hasMember triple is to say that there is a minimum of 1 hasMember triples. Rather than just being able to say there is a minimum of one, you can use any non-negative integer. In Manchester syntax, the form is: (p min n C) where p is a property and C is a class.
Sanctioned Inferences
Let’s say that there is a requirement that a physician group has at least 20 members. We will make PhysicianGroup a subclass of the restriction (hasMember min 20 Physician). The general case expands as follows for this example:
Other Remarks
Note that the filter class is optional for all the cardinality restrictions. If you leave it off, it is the same as if you used owl:Thing for an object restriction. For a data restriction the default filter is rdfs:Literal. When you do use the filter class (or datatype), the restriction is said to be a “qualified cardinality restriction.”
Note that although a minimum 1 restriction is logically identical to using a some values restriction, the inference engines treat them differently and there are some useful things you can do with someValues restrictions that you cannot do with min cardinality restrictions. Thus, it is better to use some values rather than min cardinality. This is explained more fully in Section 7.6.
5.4.6 MAXIMUM CARDINALITY
Sometimes it is useful to limit the number of relationships of a certain type that an individual may have. For example, software licenses often limit use to a specified number of devices. Suppose there were three tiers of licenses for a large software firm. The basic tier allows just 1 device, the small business tier allows up to 5, and the enterprise tier allows an unlimited number. One way to model the middle tier is to create a subclass of SoftwareLicense called SmallBusinessLicense and make it also be a subclass of a restriction that means “the set of things that are registered to a maximum of 5 devices” (see Figure 5.10). Notice that the Turtle syntax below explicitly calls out the fact that this is a qualified cardinality restriction.
In Manchester syntax, the form is: (p max n C) where p is a property and C is a class.
Sanctioned Inferences
When applied to the software example, we get the following.
In practice, this means that if the inference engine can independently verify that that a particular license is already registered to more than 5 different devices then the license cannot be in the class, SmallBusinessLicense. If someone comes along and asserts that license into class SmallBusinessLicense there is a logical contradiction.
Note that unlike a min cardinality restriction, there is no way to infer that an individual is a member of a max cardinality restriction. This is due to the open world. The inference engine might only know about 5 device registrations, but there could be more out there.
Max 1 Cardinality vs. Functional Property
Max cardinality will be mostly used with n=1. This is very similar to functional properties that also have a maximum of 1 value. It turns out that declaring a property p to be functional is precisely to say that owl:Thing is a subclass of the property restriction (p max 1). Specifically, the following two assertions are identical in meaning:
1. :hasOfficialName rdf:type owl:FunctionalProperty
2. owl:Thing rdfs:subClassOf (:hasOfficialName max 1)
Exercise 3: Can you convince yourself that asserting a given property, p, to be functional means the same thing as asserting that owl:Thing is a subclass of the restriction (p max 1)?
5.4.7 EXACT CARDINALITY
Sometimes you know beforehand exactly how many relationships of a given kind a member of a given class always has. Two examples we have previously seen are:
1. a patient visit has exactly one person receiving care; and
2. a bicycle has exactly two wheels.
Exact cardinality is a shorthand for the combination of minimum cardinality and maximum cardinality. Specifically, the following two class expressions are equivalent:
1. (hasPart min 2 Wheel) and (hasPart max 2 Wheel)
2. (hasPart exactly 2 Wheel)
Because it is just a short hand, the inferences sanctions are just those that are described above. We do not repeat them. However, I do repeat the fact that the open world prevents inferring an individual to be a member of a max cardinality restriction. And because an exact cardinality restriction combines a min and a max, the inference engine will also never be able to infer an individual into an exact cardinality restriction.
5.4.8 INDIVIDUAL VALUE: hasValue
It is common in an enterprise to refer to internal organizations vs. external organizations. What does that mean? Essentially, it means that the organization is or is not ultimately a part of the enterprise itself. For example, _SentaraHealthcare is a Corporation. A SentaraOrganization is an organization that ultimately is a part of _SentaraHealthcare. This could include informal departments, right up to major subsidiaries. We want to create a property restriction the means: “something that is a part of Sentara Healthcare, a particular company.” This is very similar to a someValuesFrom restriction, but the filter is not a class, it is a particular individual.
It works for data properties in exactly the same way, the only difference is the filter is a literal, not an individual. As an example, we could use the subclass pattern in conjunction with hasValue to represent that that all members of the class RedCar have the color red, where colors are represented as strings (see Figure 5.11 and compare it to Figure 5.9). Note that the keyword for an individual value restriction in Manchester syntax is value. For example: :hasColor value “red”^^xsd:string, as shown in Figure 5.11.
Figure 5.11: Individual value restrictions with grounding triples.
Note that until now all of the restriction types have been specified in the TBox only, that is by referring only to properties and classes from the ontology. The individual value restrictions are unique in that to give meaning to a class in the TBox, they must refer to an individual that would normally be in the ABox. In this case, because the individual is being used to define the subject matter, it probably should go in the TBox with other classes and properties.
5.4.9 DATA PROPERTY RESTRICTIONS
Most of the above examples and illustrations use object properties. However, all of the six kinds of restriction can be used with either object properties or data properties. It works exactly the same way and the inferences are exactly analogous. The main difference is in the filters. Except for the individual value restrictions, the filter for a data property restriction is a datatype rather than a class. For the individual value restrictions, the filter is a literal value rather than an individual. Below we list the general form of a data restrictions for each of the six kinds of restriction, including an example. The symbols D and v below denote datatype and literal value, respectively.
1. Some values: (p some D)
e.g., (:firstName some xsd:string)
2. All values: (p all D)
e.g., (:hasSSN all xsd:integer)
3. Min cardinality: (p min n D)
e.g., (:hasDescription min 1 xsd:string)
4. Max cardinality (p max n D)
e.g., (:hasLicenseNumber max 1 xsd:string)
5. Exact cardinality (p exactly n D)
e.g., (:hasCodeName exactly 2 xsd:string)
6. Has value: (p value v)
e.g., (:hasColor “red”^^xsd:string)
Exercise 4: Write down in English the meaning of each of the above data property restrictions.
5.4.10 SUMMARY: PROPERTY RESTRICTIONS
What Is a Property Restriction?
A property restriction is a class that is defined in terms of what relationships individuals of that class may or must have with other individuals (for object property restrictions) or with literals (for data property restrictions). Having a relationship means being the subject of a triple.
A filter can be specified to indicate what type of individual or literal the object of the triple must be. It is specified as a class for an object restriction, and as a datatype for a data restriction. Such filters are required for all values and some values restrictions. They are optional for cardinality restrictions. A cardinality restriction that uses a filter is called a qualified cardinality restriction.
Using Restrictions
There are two main scenarios for using restrictions to capture meaning of the classes in your ontology. The first is via class equivalence. In this scenario, you are effectively giving a name to a property restriction which by itself is an anonymous class represented as a blank node. More specifically, you are creating a separate IRI that can be used instead of the blank node. This sanctions the following two inferences. First, if you know an individual is a member of the class, then you can infer that it has properties of the sort dictated by the restriction. Second, if you have an individual that meets the conditions of the restriction, you can infer it into the class.
The second scenario for using property restrictions is via the subclass relationship. You create the restriction and make your class a subclass of the restriction. This achieves the goal of saying that every member of a particular class necessarily has a particular property without saying that everything that has that property is a member of that class. In this case, inference only goes one way.
In addition to the above usage scenarios for individual restrictions, because a restriction is a class, it may be used anywhere that a class is use in any other specification or expression.
5.5 SUMMARY LEARNING
Classes and Sets
A class represents a mathematical set of individuals that share certain properties. Venn diagrams are a helpful way to visualize class expressions and relationships.
Class Expressions
Classes may be defined as expressions using a variety of operations. The main ones are existential and cardinality property restriction operators and the Boolean operations, union, and intersection. A class expression combines classes, properties, and individuals and the result is a new class that may be used in any OWL expression where a class is expected. A class expression is not itself a triple, but it can be used in triples.
Class Relationships
Classes may be related to other classes in three main ways.
Subclass: The most common is the subclass relationship that specifies that the set of member individuals of one class is a subset of the set of member individuals of the other class. This relationship gives rise to a class hierarchy.
Class equivalence: Two classes are equivalent if both sets have exactly the same member individuals. The most common use of class equivalence is to specify additional meaning using a class expression. Another use is for mapping two ontologies.
Disjoint classes: Two classes being disjoint means that there are no individuals that are members of both classes, i.e., their respective sets of member individuals are disjoint. In addition to specifying more meaning for humans to understand the ontology, disjointness plays an important role in catching logical errors in an ontology.
Property Restrictions
Object property restrictions are used to state how many relationships of what kind an individual of a given class may have with other individuals that are members of another specified class.
Data property restrictions are used to state how many relationships of what kind an individual of a given class may have with literals of a given datatype.
A cardinality restriction indicates the number of relationships of a given kind that an individual may or must have with individuals or literals from a specified class or datatype.
A someValues restriction is equivalent to a min 1 cardinality restriction. It requires an individual to be in at least one other relationship of a specified kind with another individual in a specified class or datatype.
An all values restriction indicates that an individual can be related in a certain way only to individuals from a particular class or datatype.
Inference engines can infer individuals to be members of some values, min cardinality, and has value restrictions, but due to the open world, that is not possible for all values, max, or exactly restrictions.
5.6 CONCLUSION FOR PART 2
This concludes the meatiest part of the book. Congratulations, that was a lot of work! In the next and final part of the book we look into how to use OWL in practice.