CHAPTER 6

More Examples

The last two chapters went into a great amount of detail explaining the different ways to use OWL properties and classes to capture the semantics of important concepts in the subject matter of a given ontology. In this chapter we revisit some old examples with new insights, and we look at new examples showing how to put together all the knowledge about OWL we have discussed so far. We first present the examples, and what they look like as triples. After than we look at the kinds of inferences that you get with each of these examples.

6.1    PATIENT VISIT

Let’s reconsider the patient visit example from Figure 2.9. Below we show the human-friendly Manchester syntax for OWL, and then the Turtle syntax which means exactly the same thing. Notice that the former is fairly easy to read, but the underlying triples are not evident. That’s where Turtle shines. When you use your ontologies to develop applications, they will be loaded into a triple store and it will become more important to better understand things as triples.

In the Manchester syntax version, there is also no evidence of the four blank nodes that are used underneath the covers in a triple store. We introduced blank nodes in Section 5.3.1.

Manchester Syntax

Turtle Syntax

Figure 6.1 shows how all this unpacks as triples. We create the :PatientVisit class and set it to be equivalent to another class. That other class is represented as a blank node which in Turtle is enclosed by square brackets. When you encounter a left square bracket (i.e., “[”) you can read it more or less as “an anonymous class that is the subject of the following triples” where the closing square bracket means there are no more triples for that blank node. For example, :PatientVisit is equivalent to an anonymous class (called :blank_7) that is the subject of the two triples:

The blank node, :blank_8 is the list of classes that are to be intersected. The list is enclosed by round parentheses rather than square brackets. There is more detail that I am suppressing here about how lists are represented in RDF. It’s pretty ugly and you shouldn’t need to worry about it for a while.

Of the intersected classes, one is :Event and the other two are restrictions, each of which are also represented as blank nodes (numbered 9 and 10 in Figure 6.1).

Using the guideline from above on how to read a blank node in Turtle, let’s try to read the first restriction in the list:

We read this as: “an anonymous class (called :blank_9) that is the subject of the following three triples:

The names I am giving to the blank nodes are just for illustrative purposes; they need to be created and given distinct names internally, but they are temporary and local. They cannot be used anywhere else, unlike IRIs for non-blank nodes in an RDF graph.

6.2    COLLATERAL

A slightly more complicated example comes from the finance industry, specifically how to represent the fact that many loans are protected by a security agreement in the event that the borrower stops making payments. We will introduce the idea of a security agreement that is a specialization of a more generic written contract. We define a security agreement to be equivalent to a written contract that has associated collateral.

For car and home mortgages, the collateral is usually the car or the home, but it can in principle be any owned thing of sufficient value. Let’s start by just saying there is collateral. Figure 6.2 shows one way to do this.

We have said nothing about what the collateral can be, so the default is owl:Thing (in blue in the figure). One way to be more specific is to creating a class called Collateral, but then you have a restriction that says “hasCollateral some Collateral.” Setting aside that unsatisfying air of redundancy, collateral is not really a kind of thing. Something of value that is owned becomes collateral when used to limit the liability of a lender.

You want to focus on the meaning: what is true and important about the thing that is being used as collateral? It has to have some estimated value and it has to be owned. We can use property restrictions to say this without creating a class for collateral. We will extend the definition above by replacing the filter class on the hasCollateral restriction (owl:Thing) with a new class expression. We will create an OWL definition of :SecurityAgreement that means: “a written contract that is backed by an something with value that is owned.” The filter class is an expression which is the intersection of the following two restrictions in Manchester syntax (see Figure 6.3).

1.  :hasEstimatedValue some :MonetaryAmount

2.  :isOwnedBy some :IndependentParty

This means that if an individual is asserted into the class, SecurityAgreement, then:

1. it is known to be an instance of WrittenAgreement; and

2. it is known to have collateral that is both owned and has an estimated dollar value.

Suppose we also require that a security agreement is always attached to a loan contract. We can add another restriction, but in this case we use subclass instead of equivalence. This extra restriction is not in Figure 6.3, but what it looks like in Protégé, e6Tools, and Manchester syntax is shown in Figures 6.4 and 6.5. Notice how Protégé uses Manchester syntax in its user interface. It mirrors the ontology when exported to a file (as shown in Figure 6.5).

Notice that the two intersected restrictions are part of the filter class for another restriction. The nesting of one or more restrictions inside another restriction sometimes called chaining restrictions. This works because a restriction is a class expression and a restriction can take any class as a filter. This particular example comes from the Financial Industry Business Ontology (FIBO).²²

Even in Manchester syntax this takes a bit of thought to see what is going on. The Turtle would be more complicated, and it is not included here. Take some time to go over this a few times until you are comfortable. Look again at Figure 6.3. This example combines a number of important things all in one place and shows the power of using class expressions:

•  both the subclass and the class equivalence patterns for using restrictions;

•  nesting of an intersection within an intersection; and

•  using an intersection of two restrictions as a filter nested within a restriction.

Note that the round parentheses in Manchester syntax are used purely for removing ambiguity, just like in arithmetic. They do not enclose a list, as they do in Turtle.

6.3    INTERNAL VS. EXTERNAL TRANSACTIONS

Every enterprise engages in financial transactions with other companies or individuals regarding costs paid to vendors and revenue generated from sales. However, in any large company there are many internal organizations with separate budgets that transact business among themselves. For example, a company that provides cloud services to the public may also sell those same services to organizations within the enterprise. A single transaction is regarded as a cost by the purchasing organization and is regarded as revenue by the selling organization.

If you wanted to track internal financial transactions you might create a class defined to be a financial transaction where the buyer and seller were both internal organizations. We already talked about the idea of an internal organization (see Figure 5.11).

We introduce a company called Semvia that provides cloud services (among other things). We represent it as an instance of :Organization with IRI :_Semvia. We define the class, :SemviaOrganization to be equivalent to the intersection of two classes:

1. :Organization

2. :partOf value :_Semvia

The second class is a hasValue restriction. Note that partOf must be transitive to ensure that a lower organization in the company that has several layers of larger organizations above it is still regarded as being a part of Semvia. We will use class equivalence here because we want the inference to go both ways—that is, we want to infer into the class, as well as inferring information about something that is already known to be in the class.

To get to a definition of an internal Semvia transaction, we’ll start by introducing a class for financial transaction that is an event where there is a seller, a buyer, and an amount of money that is paid. Also, the buyer and seller are both parties, where a party is defined to be either a person or an organization.

We create the class FinancialTransaction and make it a subclass of each of the following four classes:

1. :Event

2. :hasBuyer some :Party

3. :hasSeller some :Party

4. :hasAmount some :MonetaryAmount

We can now define a class for internal Semvia transactions where the buyer and seller are both internal Semvia organizations. It is defined as a financial transaction where the buyer and seller are both members of the class SemviaOrganization that we defined above. The class InternalSemviaTransaction is equivalent to the intersection of the following three classes:

1. :FinancialTransaction

2. :hasBuyer some :SemviaOrganization

3. :hasSeller some :SemviaOrganization

This structurally very similar to the definition of the patient visit class we just looked at. This is a common pattern that can be used for any subject.

Because we are using equivalence rather than subclass, the inference works both ways. First, if an individual is a member of all three classes, we can infer it to be an instance of the class InternalSemviaTransaction. Going the other way, if an individual is an instance of InternalSemviaTransaction, we can infer membership into each of the three classes.

The whole ontology that represents these ideas consists of eight classes and four object properties plus one inverse. See Figure 6.6 for a compact visual representation format. Most individuals, especially particular organizations would normally be in the ABox. However in this case, because: _Semvia is used to define a class, we include it in the TBox. Figure 6.7 shows how to populate this ontology with a few individuals. Each of the colorless rounded boxes represent individuals.

Figure 6.10 shows what this looks like in Protégé after running inference. See if you can explain to yourself exactly how and why the individual transaction, :_Trans_456 gets inferred into the class, :InternalSemviaTransaction. We will go through this in detail in Section 6.4.4.

6.4    INFERENCE

Next, we consider what inferences can be drawn from the definitions in the previous examples.

6.4.1    PATIENT VISIT

Recall that with equivalence the inference goes both ways. If we assert an individual into the class, then we can conclude things from the definition. Conversely, if we assert certain things about an individual, we can conclude that it is a member of the class. The latter inference is depicted at the top of Figure 6.8. Every link corresponds to a triple, and the solid ones are asserted, the dotted ones are inferred. The heavy lines indicate what class an individual is an instance of.

The diagram tells us that if we assert that a given individual is an event, has a care provider, and has a care recipient (both of which are persons), then we can infer that individual into the class, PatientVisit. Conversely, if we assert the individual into the class, PatientVisit, then we can infer that: (1) the individual is a member of the class Event; (2) has a care provider that is a person; and (3) has a care recipient that is a person. See the bottom of Figure 6.8.

Because we don’t know who the caregiver and care recipients are on the patient visit, the inference engine will temporarily make some distinct identifiers for those individuals that could potentially be used to draw other conclusions. This is called inference with partial information.

6.4.2    INFERENCE WITH PARTIAL INFORMATION

What is interesting about this is that we have no idea who those people are, we just know that they exist. This is analogous to knowing that Julius Caesar has a birthdate, even though you don’t know what it is. In fact, no one knows. There is broad agreement among scholars that it was on July 12 or 13 and that it was one of the years 100, 101, or 102 BC.

We also saw this in the insurance policy example. We can infer the existence of a party that is covered even if we don’t know exactly who that party is.

If we were modeling U.S. citizens we might wish to say that they all necessarily have a social security number. We could create a restriction and use the subclass pattern using a data property connecting people to their social security numbers as follows (in Manchester syntax).

This enables us to infer that any individual known to be of type :Person will have a social security number, but we would generally not expect to store such information in a triple store.

6.4.3    SECURITY AGREEMENT AND COLLATERAL

At the top of Figure 6.9 we have asserted that a particular individual is a written contract, and also that it has collateral. Furthermore, the collateral has estimated value of $450k and is owned by Jane Will. This is sufficient to infer into the class SecurityAgreement. Convince yourself that this is true based on the above definition.

Once this happens, we can infer additional information based on the restriction (partOf some LoanContract) which security agreement is a subclass of. We know that it is part of a loan contract, even though we don’t know which loan contract it is.

In the bottom part of the figure, we assert a single triple that places the individual _secAgree_123 into the class SecurityAgreement. This triggers eight inferences, all depicted with dotted lines. The equivalence axiom sanctions the six inferences on the left of the diagram.

Exercise 1: Given our definition for a security agreement in Figure 6.5, what if any inference can be made if all you know is the following:

6.4.4    INTERNAL ORGANIZATIONS AND TRANSACTIONS

Figure 6.10 shows what the ontology in Figure 6.6 looks like in Protégé after running inference. Inferences show up with light yellow shading. You can get an explanation justifying the inference by clicking on the question mark to the far right. Figure 6.11 gives the details of why the individual, _Trans_456 is inferred into the class, InternalSemviaTransaction.

We are going to unpack this. If we can determine that the individual _Trans_456 is an instance of each of the three intersected classes making up the definition, then we can infer it to be in the class InternalSemviaTransaction. Those classes are depicted at the top of the lower right area of the Protégé window in Figure 6.10 and listed below.

1. :FinancialTransaction

2. :hasBuyer some :SemviaOrganization

3. :hasSeller some :SemviaOrganization

Look closely at the ABox depicted in Figure 6.7 to follow the reasoning. Each rounded shape is an individual, whose class IRI is in a bold black font. Next is the individual’s IRI in blue. Below that in a smaller blue font is a comment. The same individuals in Turtle syntax are depicted in Figure 6.12.

First, we see that _Trans_456 is directly asserted into the class FinancialTransaction. Next we need to show that _Trans_456 is the subject of a triple with the predicate hasBuyer where the buyer is an instance of the class SemviaOrganization. The buyer is directly asserted to be SemviaITServices. Next we will try to show that SemviaITServices is a SemviaOrganization, which will enable us to conclude that _Trans_456 is in fact a member of “hasBuyer some SemviaOrganization.”

The definition of the class SemviaOrganization tells us that any instance that is an organization that is part of Semvia is a SemviaOrganization. So our specific strategy is to show that _SemviaITServices is a member of the following two classes:

1. :Organization

2. :partOf value :_Semvia

_SemviaITServices is directly asserted to be an instance of Organization; it is also asserted to be a be a part of _SemviaServices, which is not quite what we want. We need it to be part of _Semvia. However, _SemviaServices is a part of _Semvia and by transitivity of partOf; we can conclude that _SemviaITServices is indeed a part of _Semvia. This allows us to infer it to be a member of the second class: “partOf value _Semvia.” This sanctions inferring _SemviaITServices into the class _SemviaOrganization, which in turn allows us to infer that _Trans_456 is an instance of “hasBuyer some SemviaOrganization,” the second of the three intersected classes defining InternalSemviaTransaction.

By the same line of reasoning, we can conclude that the seller _SemviaCloud is also a SemviaOrganization, which in turn allows us to infer that _Trans_456 is an instance of the third of the three intersected classes. We have now shown that _Trans_456 is a member of all three of the classes in its defining intersection. This is sufficient to infer it into the class InternalSemviaTransaction. Thus, we add the triple:

The class SemviaOrganization gained the three new members: _SemviaCloud, _SemviaITServices, and _SemviaServices.

There is quite a lot going on here. It may take a few careful readings with a piece of paper before you follow all the details.

6.4.5    CLASSIFICATION INFERENCE

The many different inferences that are sanctioned by the various constructs combine to do some powerful things. The examples we have just seen involve automatically classifying individuals by inferring them into a class using the rdf:type construct. There are also many rules for inferring new rdfs:subClassOf links in the class hierarchy. The main ones are listed below and described in Section 5.3.2.

1.  Inferring that a class defined as the intersection of two or more classes is a subclass of each of the intersected classes.

2.  Inferring that class defined as the union of two or more classes has each of the classes as subclasses.

A common pattern is the intersection of a named class and one or more property restriction classes. We defined PatientVisit to be the intersection of Event and two restrictions about giving and receiving care; therefore, by rule 1 above, PatientVisit is inferred to be a subclass of Event. Similarly, a SecurityAgreement is inferred to be a subclass of WrittenContract, and Patient is inferred to be a subclass of Person. Similarly, because Party is defined to be the union of Person and Organization, both of the latter classes are subclasses of Party.

The upper half of Figure 6.13 shows the top level classes before and after inference. Organization and Person are inferred to be subclasses of Party. The lower half of the figure shows both hierarchies fully expanded. Inference tidies things up a bit, putting things where they belong.

Other more complex combinations also arise. For example, there is an ontology of generic enterprise concepts called gist.²³ In it, there is a class called Intention with four subclasses: Goal, Permission, Requirement, and Restriction (not an OWL restriction). In addition, the class, Commitment is defined to be the union of Requirement and Restriction. It turns out that Commitment is inferred to be a subclass of Intention. Any OWL DL compliant inference engine will draw that conclusion given the above information. Figure 6.14 depicts what happens to the hierarchy after running inference. The number of top-level categories is 31% smaller (from 26 to 18).

Question to reader: Draw a Venn diagram to make it easy to see why :Commitment is inferred to be a subclass of :Intention.

Benefits of Classification Inference

There are two kinds of classification inference. One puts an individual into a class using rdf:type. The other results in adding new rdfs:subClassOf links between classes. This process is dynamic. When new triples are added, inference is run again. This updates the class hierarchy and may result in some individuals being members of new classes.

Classification inference helps in various ways. First, it saves work in maintaining the subclass hierarchy. Many relationships are added for you. If you make changes that have ripple effects, the inference engine takes care of that for you. This makes it easier to maintain the ontology. Another important benefit is that it helps to spot mistakes. For example, if Commitment is inferred to be a subclass of Person, this tells you there is an error somewhere that you need to track down.

6.5    SUMMARY LEARNING

Syntax, Blank Nodes, and Examples

There is a huge difference between Manchester and Turtle syntax. The former is very easy for humans to read. It achieves this by hiding a lot of what is going on under the covers with triples and blank nodes. If you want to see those things, then Turtle is a good option.

A number of OWL constructs take lists of things as arguments. These include owl:intersectionOf, owl:unionOf, and owl:oneOf (the latter is used for enumerated classes). Lists in Turtle are enclosed in round parentheses.

Filter classes are most often simple class IRIs, but they can be arbitrarily complex class expressions. For example, there must be some collateral for a security agreement, but we don’t need a class called Collateral, since it is not really a kind of thing, but rather it is something of value that is owned by someone. The filter class in this case is the intersection of two restrictions nested inside another restriction.

Inference

Inference works both ways when you define a class using :equivalentClass as in the :PatientVisit example. If you know an individual is member of the class, you can infer that it is an event with a care provider and care recipient that are both persons. However, it also goes the other way, if you have an individual and you come to know that it is an event with a care provider and care recipient that are both persons, then you can infer into the class :PatientVisit.

OWL is capable of drawing inferences with partial information. Classification inference is useful in a number of ways. It:

•  determines new subclass relationships;

•  determines which classes an individual belongs to;

•  makes it easier to maintain the ontology; and

•  helps to point out errors.

This concludes the introduction and detailed exploration of all the major components of OWL. In the next chapter we point out some things you cannot do in OWL and describe some workarounds.

²²  https://www.edmcouncil.org/financialbusiness

²³  www.semanticarts.com/gist. Disclosure: I have been using and co-developing gist since 2010.