RDFS provides a very limited set of inference capabilities that, as we have seen, have considerable utility in a Semantic Web setting for merging information from multiple sources. In this chapter, we take the first step toward the Web Ontology Language OWL, in which more elaborate constraints on how information is to be merged can be specified. We have selected a particular set of OWL constructs to present at this stage. This set was selected to satisfy a number of goals:

Pedagogically, these constructs constitute a gentle addition to the constructs that are already familiar from RDFS, increasing the power of the language without making a large conceptual leap from RDFS.

Practically, we have found that this set of OWL constructs has considerable utility in the information integration projects we have done. In fact, it is much easier to find and describe case studies using RDFS plus this set of OWL constructs than it is to find case studies that use RDFS by itself.

Computationally, this subset of OWL can be implemented using a wide variety of inferencing technologies, lessening the dependency between the Semantic Web and any particular technology.

For these reasons, we feel that this particular subset will have value beyond the pedagogical value in this book. We call this subset of OWL RDFS-Plus, because we see a trend among vendors of Semantic Web tools and Web applications designers for determining a subset of OWL that is at the same time useful and can be implemented quickly. We have identified this particular subset via an informal poll of cutting-edge vendors, and from our own experience with early adopters of Semantic Web technology.

Just as was the case for RDFS, RDFS-Plus is expressed entirely in RDF. The only distinction is that there are a number of resources, all in the namespace owl. The meaning of these resources is specified, as before, by the rules that govern the inferences that can be made from them.

In the case of RDFS, we saw how the actions of an inference engine could be used to combine various features of the schema language in novel ways. This trend will continue for RDFS-Plus, but as you might expect, the more constructs we have to begin with, the more opportunity we have for useful and novel combinations.

INVERSE

The names of many of the OWL constructs come from corresponding names in mathematics. Despite their mathematical names, they also have a more common, everyday interpretation. The idea owl:inverseOf is a prime example; if a relationship—say, hasParent—is interesting enough to mention in a model, then it’s a good bet that another relationship—say, hasChild—is also interesting. Because of the evocative names hasParent and hasChild, you can guess the relationship between them, but of course the computer can’t. The OWL construct owl:inverseOf makes the relationship between hasParent and hasChild explicit, and describes precisely what it means.

In mathematics, the inverse of a function f (usually written as f^–1) is the function that satisfies the property that if f(x) = y, then f^–1(y) = x. Similarly in OWL, the inverse of a property is another property that reverses its direction.

To be specific, we look at the meaning of owl:inverseOf. In OWL, as in RDFS, the meaning of any construct is given by the inferences that can be drawn from it. If we have the following triples:

P owl:inverseOf Q.

xPy.

then we can infer that

yQx.

In the examples in the book, we have already seen a number of possibilities for inverses, though we haven’t used them so far. In our Shakespeare examples, we have the triples

lit:Shakespeare lit:wrote lit:Macbeth.

lit:Macbeth lit:setIn geo:Scotland.

If, in addition to these triples, we also state some inverses, such as:

lit:wrote owl:inverseOf lit:writtenBy.

lit:settingFor owl:inverseOf lit:setIn.

then we can infer that

lit:Macbeth lit:writtenBy lit:Shakespeare.

geo:Scotland lit:setingFor lit:Macbeth.

Although the meaning of owl:inverseOf is not difficult to describe, what is the utility of such a construct in a modeling language? After all, the effect of inverseOf can be achieved just as easily by writing the query differently. For instance, if we want to know all the plays that are setIn Scotland, we can use the inverse property settingFor in our query pattern, such as

{geo:Scotland lit:settingfor ?play.}

Because of the semantics of the inverse property, this will give us all plays that were setIn Scotland.

But we could have avoided the use of the inverse property and simply written the query as

{?play lit:setIn geo:Scotland.}

We get the same answers, and we don’t need an extra construct in the modeling language.

While this is true, owl:inverseOf nevertheless does have considerable utility in modeling, based on how it can interact with other modeling constructs. In the next challenge, we’ll see how the Property Union challenge can be extended using inverses.

Challenge: Integrating Data that Do Not Want to Be Integrated

In the Property Union challenge, we had two properties, borrows and checkedOut. We were able to combine them under a single property by making them both rdfs:subPropertyOf the same parent property, hasPosession. We were fortunate that the two sources of data happened to link a Patron as the subject to a Book as the object (i.e., they had the same domain and range). Suppose instead that the second source was an index of books, and for each book there was a field specifying the patron the book was signedTo (i.e., the domain and range are reversed).

Challenge: Using the Modeling Language to Extend the Modeling Language

It is not unusual for beginning modelers to look at the list of constructs defined in OWL and say, “There is a feature of the OWL language I would like to use that is very similar to the ones that are included. Why did they leave it out? I would prefer to build my model using a different set of primitives.” In many cases, the extra language feature that they desire is actually already supported by OWL as a combination of other features. It is a simple matter of using these features in combination.

Selecting namespaces for resources that extend the capabilities of the OWL language is a delicate matter; in the next chapter, we will examine a case study in which this has been done in a careful way.

Challenge: The Marriage of Shakespeare

In a previous chapter, we lamented that even though we had asserted that Anne Hathaway had married Shakespeare, we did not know that Shakespeare had married Anne Hathaway. We are now in a position to remedy that.

SYMMETRIC PROPERTIES

owl:inverseOf relates one property to another. The special case in which these two properties are the same (as was the case for bio:married for the Shakespeare example) is common enough that the OWL language provides a special name for it: owl:SymmetricProperty. Unlike owl:inverseOf, which is a property that relates two other properties, owl:SymmetricProperty is just an aspect of a single property and is expressed in OWL as a Class. We express that a property is symmetric in the same way as we express membership in any class—in other words:

P rdf:type owl:SymmetricProperty.

As usual, the meaning of this statement is given by the inferences that can be drawn from it. From this triple, we can infer that

P owl:inverseOf P.

So in the case of the marriage of Shakespeare, we can assert that

bio:married rdf:type owl:SymmetricProperty.

Using OWL to Extend OWL

As we describe more and more of the power of the OWL modeling language, there will be more and more opportunities to define at least some aspects of a new construct in terms of previously defined constructs. We can use this method to streamline our presentation of the OWL language. We have seen a need for this already in figure Figure 7-1, in which all of our inverses are expressed in one direction but we really need to have them go both ways, as shown in Figure 7-2.

We asserted the triples from left to right—namely:

:possessedBy owl:inverseOf :hasPossession.

:signedTo owl:inverseOf :signedOut.

:lentTo owl:inverseOf :borrows.

But we would like to be able to infer the triples from right to left—namely:

:hasPossession owl:inverseOf :possessedBy.

:signedOut owl:inverseOf :signedTo.

:borrows owl:inverseOf :lentTo.

In either case, we get the inferences we desire for Figure 7-2, in which the inverses point both ways. This also means that all the inferences in both directions will always be found.

TRANSITIVITY

In mathematics, a relation R is said to be transitive if R(a, b) and R(b, c) implies R(a, c). The same idea is used for the OWL construct owl:TransitiveProperty. Just like owl:SymmetricProperty, owl:TransitiveProperty is a class of properties, so a model can assert that a property is a member of the class

P rdf:type owl:TransitiveProperty.

The meaning of this is given by a somewhat more elaborate rule than we have seen so far in this chapter. Namely, if we have two triples of the form

X P Y.

Y P Z.

then we can infer that

X P Z.

Notice that there is no need for even more elaborate rules like

APB.

BPC.

CPU.

implies

APD.

since this conclusion can be reached by applying the simple rule over and over again.

Some typical examples of transitive properties include ancestor/descendant (if Victoria is an ancestor of Edward, and Edward is an ancestor of Elizabeth, then Victoria is an ancestor of Elizabeth) and geographical containment (if Osaka is in Japan, and Japan is in Asia, then Osaka is in Asia).

Challenge: Relating Parents to Ancestors

A model of genealogy will typically include notions of parents as well as ancestors, and we’d like them to fit together. But parents are not transitive (my parents’ parents are not my parents), whereas ancestors are.

Information about the heritage is integrated, regardless of whether it originated with hasParent or hasAncestor. Information about hasParent, on the other hand, is only available as it was directly asserted because it was not declared to be transitive. The results of this inference are shown in Figure 7-3.

Challenge: Layers of Relationships

Sometimes it can be somewhat controversial whether a property is transitive or not. For instance, the relationship that is often expressed by the words “part of” in English is sometimes transitive (a piston is part of the engine, and the engine is part of the car; is the piston part of the car?) and sometimes not (Mick Jagger’s thumb is part of Mick Jagger, and Mick Jagger is part of the Rolling Stones; is Mick Jagger’s thumb part of the Rolling Stones?). In the spirit of anticipating possible uses of a model, it is worthwhile to support both points of view whenever there is any chance that controversy might arise.

Managing Networks of Dependencies

The same modeling patterns we have been using to manage relationships (like ancestry), or set containment (like part of) can be used just as well in a very different setting—namely, to manage networks of dependencies. In the series of challenges that follow, we will see how the familiar constructs of rdfs:subPropertyOf, owl:inverseOf, and owl:TransitiveProperty can be combined in novel ways to model important aspects of such networks.

A common application of this idea is in workflow management. In a complex working situation, a variety of tasks must be repeatedly performed in a set sequence. The idea of workflow management is that the sequence can be represented explicitly and the progress of each task tracked in that sequence. Why would someone want to model workflow in a Semantic Web? The answer is for the same reason one wants to put anything on the web: so that parts of the workflow can be shared with others, encouraging reuse, review, and publication of work fragments.

Real workflow specifications are far too detailed to serve as examples in a book, so we will use a simple example to show how it works. Let’s make some ice cream, using the following recipe:

Slice a vanilla bean lengthwise, and scrape the contents into 1 cup of heavy cream. Bring the mixture to a simmer, but do not boil.

While the cream is heating, separate three eggs. Add 1/2 cup white sugar, and beat until fluffy. Gradually add the warm cream, beating constantly. Return the custard mixture to medium heat, and cook until mixture leaves a heavy coat on the back of a spatula. Chill well. Combine custard with 1 cup whole milk, and turn in ice cream freezer according to manufacturer’s instructions.

First, let’s use a property dependsOn to represent the dependencies between the steps and define its inverse enables, since each step enables the next in the correct execution of the workflow:

:dependsOn owl:inverseOf :enables.

Now we can define the dependency structure of the recipe steps:

:SliceBean :enables :HeatCream.

:SeparateEggs :enables :AddSugar.

:AddSugar :enables :BeatEggs

:BeatEggs :enables :GraduallyMix.

:HeatCream :enables :GraduallyMix.

:GraduallyMix :enables :CookCustard.

:CookCustard :enables :Chill.

:Chill :enables :AddMilk.

:AddMilk :enables :TurnInFreezer.

Because of the inverseOf, we can view these steps either in enabling order as asserted or in dependency order, as show in Figure 7-5.

From these triples, for instance, we can infer that GraduallyMix has five prerequisites—namely:

:GraduallyMix :hasPrerequisite :AddSugar;

:hasPrerequisite :SeparateEggs;

:hasPrerequisite :SliceBean;

:hasPrerequisite :HeatCream;

:hasPrerequisite :BeatEggs.

Figure 7-7 shows the two patterns. For inSameRecipe, we have a single transitive property at the top of a subPropertyOf tree; both primitive properties (enables and dependsOn) are brought together, and any combinations of the resulting property (neighborStep) are chained together as a TransitiveProperty (inSameRecipe). For otherStep, the top-level property itself is not transitive but is a simple combination (via two subPropertyOf links) of two transitive properties (hasPrerequisite and prerequisiteFor). Inference for each of these transitive properties is done separately from the other, and the results combined (without anymore transitive interaction). Hence, for inSameRecipe, the reflexive triples like

:GraduallyMix :inSameRecipe :GraduallyMix.

are included, whereas for otherStep, they are not.

EQUIVALENCE

RDF provides a global notion of identity that has validity across data sources; that global identity is the URI. This makes it possible to refer to a single entity in a distributed way. But when we want to merge information from multiple sources controlled by multiple stakeholders, it is not necessarily the case that any two stakeholders will use the same URI to refer to the same entity. Thus, in a federated information setting, it is useful to be able to stipulate that two URIs actually refer to the same entity. But there are different ways in which two entities can be the same. Some are more equal than others. RDFS-Plus provides a variety of notions of equivalence. As with other constructs in OWL, these different constructs are defined by the inferences they entail.

Equivalent Classes

We previously used a simple idiom to express that one class had the same elements as another; in particular, we asserted two triples

:Analyst rdf:subClassOf :Researcher.

:Researcher rdf:subClassOf :Analyst.

to indicate that every Analyst is a Researcher and every Researcher is an Analyst. As we saw, the rule for rdf:subClassOf can be applied in each direction to support the necessary inferences to make every Analyst a Researcher and vice versa. When two classes are known to always have the same members, we say that the classes are equivalent. The preceding pattern allows us to express class equivalence in RDFS, if in a somewhat unintuitive way.

RDFS-Plus provides a more intuitive expression of class equivalence, using the construct owl:equivalentClass. A single triple expresses class equivalence in the obvious way:

:Analyst owl:equivalentClass :Researcher.

As with any other construct in RDFS or OWL, the precise meaning of owl:equivalentClass is given by the inferences that can be drawn. In particular, if we know that

A owl:equivalentClass B.

r rdf:type A.

then we can infer that

r rdf:type B.

So far, this is just the type propagation rule that we used to define the meaning of rdf:subClassOf in Chapter 6. But owl:equivalentClass has another rule as well—given

A rdf:subClassOf B.

r rdf:type B.

then we can infer that

r rdf:type A.

That is, the two classes A and B have exactly the same members.

It seems a bit of a shame that something as simple as equivalence requires two rules to express, especially when the rules are so similar. In fact, this isn’t necessary; if we observe that

owl:equivalentClass rdfs:type owl:SymmetricProperty.

then there is no need for the second rule; we can infer it from the first rule and the symmetry of equivalentClass.

In fact, we don’t actually need any rules at all; if we also assert that

owl:equivalentClass rdfs:subPropertyOf rdfs:subClassOf.

we can use the rules for subPropertyOf and subClassOf to infer everything about equivalentClass! Let’s see how the rules for OWL, which we have already learned work for owl:equivalentClass, in the case of the Analyst and the Researcher.

From the rule about rdfs:subClassOf and the statement of equivalence of Analyst and Researcher, we can infer that

:Analyst rdfs:subClassOf :Researcher.

But since owl:equivalentClass is symmetric, we can also infer that

:Researcher owl:equivalentClass :Analyst.

and by applying the rule for rdfs:subClassOf once again, we get

:Researcher rdfs:subClassOf :Analyst.

That is, simply by applying what we already know about rdfs:subClassOf and owl:SymmetricProperty, we can infer both rdfs:subClassOf triples from the single owl:equivalentClass triple.

Notice that when two classes are equivalent, it only means that the two classes have the same members. Other properties of the classes are not shared; for example, each class keeps its own rdfs:label. This means that if these classes have been merged from two different applications, each of these applications will still display the class by the original print name; only the members of the class will change.

Equivalent Properties

We have seen how to use rdfs:subPropertyOf to make two properties behave in the same way; the trick we used there was very similar to the double subClassOf trick. We use rdfs:subPropertyOf twice to indicate that two properties are equivalent.

:borrows rdfs:subPropertyOf :checkedOut.

:checkedOut rdfs:subPropertyOf :borrows.

RDFS-Plus also provides a more intuitive way to express property equivalence, using owl:equivalentProperty, as follows:

:borrows owl:equivalentProperty :checkedOut.

When two properties are equivalent, we expect that in any triple that uses one as a predicate, the other can be substituted—that is, for any triple

A borrows B.

we can infer that

A checkedOut B.

and vice versa. We can accomplish this in a manner analogous to the method used for owl:equivalentClass. We define owl:equivalentProperty in terms of other RDFS-Plus constructs.

owl:equivalentProperty rdfs:subPropertyOf rdfs:subPropertyOf.

owl:equivalentProperty rdf:type owl:SymmetricProperty.

Starting with the asserted equivalence of borrows and checkedOut, using these triples, and the rules for rdfs:subPropertyOf and owl:SymmetricProperty, we can infer that

:borrows rdfs:subPropertyOf checkedOut.

:checkedOut owl:equivalentProperty borrows.

:checkedOut rdfs:subPropertyOf borrows.

Once we have inferred that borrows and checkedOut are rdfs:subPropertyOf one another, we can make all the appropriate inferences.

When we express new constructs (like owl:equivalentProperty in this section) to constructs we already know (rdfs:subPropertyOf and owl:SymmetricProperty), we explicitly describe how the various parts of the language fit together. That is, rather than just noticing that the rule governing owl:equivalent Property is the same rule as the one that governs rdfs:subPropertyOf (except that it works both ways!), we can actually model these facts. By making owl: equivalentProperty a subproperty of rdfs:subPropertyOf, we explicitly assert that they are governed by the same rule. By making owl:equivalentProperty a owl:SymmetricProperty, we assert the fact that this rule works in both direct ions. This makes the relationship between the parts of the OWL language explicit and, in fact, models them in OWL.

Same Individuals

Class equivalence—that is, owl:equivalentClass—and property equivalence (own:equivalentProperty) provide intuitive ways to express relationships that were already expressible in RDFS. In this sense, neither of these constructs have increased the expressive power of RDFS-Plus beyond what was already available in RDFS. They have just made it easier to express and clearer to read. These constructs refer respectively to classes of things and the properties that relate them.

But when we are describing things in the world, we aren’t only describing classes and properties; we are describing the things themselves. These are the members of the classes. We refer to these as individuals. We have encountered a number of individuals in our examples so far—Wenger the Analyst, Twelfth Night the Play, Shakespeare the Playwright, Kildare the Surgeon, Kaneda the All-Star Player—and any number of things whose class membership has not been specified—Wales, The Firm, and Moby Dick. But remember the nonunique naming assumption: Often, our information comes from multiple sources that might not have done any coordination in their reference to individuals. How do we handle the situation in which we determine that two individuals that we originally thought of separately are in fact the same individual?

In RDFS-Plus, this is done with the single construct owl:sameAs. Our old friend William Shakespeare will provide us with an example ofhow owl:sameAs works. From Chapter 3, we have the following triples about the literary career of William Shakespeare:

lit:Shakespeare lit:wrote lit:AsYouLikeIt;

lit:wrote lit:HenryV;

lit:wrote lit:LovesLaboursLost;

lit:wrote lit:MeasureForMeasure;

lit:wrote lit:TwelfthNight;

lit:wrote lit:WintersTale;

lit:wrote lit:Hamlet;

lit:wrote lit:Othello.

Suppose we have at our disposal information from the Stratford Parish Register, which lists the following information from some baptisms that occurred there. We will use spr: as the namespace identifier for URIs from the Stratford Parish Register.

spr:Gulielmus spr:hasFather spr:JohannesShakspere.

spr:Susanna spr:hasFather spr:WilliamShakspere.

spr:Hamnet spr:hasFather spr:WilliamShakspere.

spr:Judeth spr:hasFather spr:WilliamShakspere.

Suppose that our research determines that, indeed, the resources mentioned here as spr:Gulielmus, spr:WilliamShakspere and lit:Shakespeare all refer to the same individual, so the answer to the question “Did Hamnet’s father write Hamlet?” would be “yes.” If we had known that all of these things refer to the same person in advance of having represented the Stratford Parish Register in RDF, we could have used the same URI (e.g., lit:Shakespeare) for each occurrence of the Bard. But now it is too late; the URIs from each data source have already been chosen. What is to be done?

First, let’s think about how to pose the question “Did Hamnet’s father write Hamlet?” We can write this as a graph pattern in SPARQL as follows:

{spr:Hamnet spr:hasFather ?d.

?d lit:wrote lit:Hamlet.}

that is, we are looking for a single resource that links Hamnet to Hamlet via the two links spr:hasFather and lit:wrote.

In RDFS-Plus, we have the option of asserting the sameness of two resources. Let’s start with just one:

spr:WilliamShakspere owl:sameAs lit:Shakespeare.

The meaning of this triple, as always in RDFS-Plus, is expressed by the inferences that can be drawn. The rule for owl:sameAs is quite intuitive; it says that if A owl:sameAs B, then in any triple where we see A, we can infer the same triple, with A replaced by B. So for our Shakespeare example, we have that for any triple of the form

spr:WilliamShakespere P O.

we can infer that

lit:Shakespeare P O.

Similarly, for any triple of the form

S P spr:WilliamShakespeare.

we can infer that

S P lit:Shakespeare.

Also, as we did for owl:equivalentClass and owl:equivalentProperty, we assert that owl:sameAs is a owl:SymmetricProperty :

owl:sameAs rdf:type owl:SymmetricProperty.

This allows us to infer that

lit:Shakespeare owl:sameAs spr:WilliamShakspere.

so that we can replace any occurrence of lit:Shakespeare with spr:WilliamShakspere as well.

Let’s see how this works with the triples we know from literary history and the Register. We list all triples, with asserted triples in Roman and inferred triples in italics. Among the inferred triples, we begin by replacing lit:Shakespeare with spr:WilliamShakspere, then continue by replacing spr:WilliamShakspere with lit:Shakespeare :

lit:Shakespeare lit:wrote lit:AsYouLikeIt;

lit:wrote lit:HenryV;

lit:wrote lit:LovesLaboursLost;

lit:wrote lit:MeasureForMeasure;

lit:wrote lit:TwelfthNight;

lit:wrote lit:WintersTale;

lit:wrote lit:Hamlet;

lit:wrote lit:Othello.

spr:Gulielmus spr:hasFather spr:JohannesShakspere.

spr:Susanna spr:hasFather spr:WilliamShakspere.

spr:Hamnet spr:hasFather spr:WilliamShakspere.

spr:Judeth spr:hasFather spr:WilliamShakspere.

spr:WilliamShakspere

lit:wrote lit:AsYouLikeIt;

lit:wrote lit:HenryV;

lit:wrote lit:LovesLaboursLost;

lit:wrote lit:MeasureForMeasure;

lit:wrote lit:TwelfthNight;

lit:wrote lit:WintersTale;

lit:wrote lit:Hamlet;

lit:wrote lit:Othello.

spr:Susanna spr:hasFather lit:Shakespeare.

spr:Hamnet spr:hasFather lit:Shakespeare.

spr:Judeth spr:hasFather lit:Shakespeare.

Now the answer to the query “Did Hamnet’s father write Hamlet?” is “yes,” since there is a binding for the variable ?d in the preceding SPARQL graph pattern. In fact, there are two possible bindings: ?d = lit:Shakespeare and ?d = spr:Shakspere.

Challenge: Merging Data from Different Databases

We have seen how to interpret information in a table as RDF triples. Each row in the table became a single individual, and each cell in the table became a triple. The subject of the triple is the individual corresponding to the row that the cell is in; the predicate is made up from the table name and the field name; and the object is the cell contents. Table 7-1 (from Table 3-10) shows 63 triples for the 7 fields and 9 rows. Let’s look at just the triples having to do with the Manufacture_Location.

mfg:Product1 mfg:Product_Manufacture_Location Sacramento.

mfg:Product2 mfg:Product_Manufacture_Location Sacramento.

mfg:Product3 mfg:Product_Manufacture_Location Sacramento.

mfg:Product4 mfg:Product_Manufacture_Location Elizabeth.

mfg:Product5 mfg:Product_Manufacture_Location Elizabeth.

mfg:Product6 mfg:Product_Manufacture_Location Seoul.

mfg:Product7 mfg:Product_Manufacture_Location Hong Kong.

mfg:Product8 mfg:Product_Manufacture_Location Cleveland.

mfg:Product9 mfg:Product_Manufacture_Location Cleveland.

Suppose that another division in the company keeps its own table of the products with information that is useful for that division’s business activities—namely, it describes the sort of facility that is required to produce the part. Table 7-2 shows some products and the facilities they require. Some of the products in Table 7-2 also appeared in Table 7-1, and some did not. It is not uncommon for different databases to overlap in such an inexact way.

This solution has addressed the challenge for the particular data in the example, but the solution relied on the fact that we knew which product from one table matched with which product from another table. But owl:sameAs only solves part of the problem. In real data situations, in which the data in the tables change frequently, it is not practical to assert all the owl:sameAs triples by hand. In the next section, we will see how RDFS-Plus provides a solution to the rest of the challenge.

COMPUTING SAMENESS—FUNCTIONAL PROPERTIES

Functional Properties in OWL get their name from a concept in mathematics, but like most of the OWL constructs, they have a natural interpretation in everyday life. A function property is one for which there can be just one value. Examples of such properties are quite common: hasMother (since a person has just one biological mother), hasBirthplace (someone was born in just one place), and birthdate (just one) are a few simple examples.

In mathematics, a function is a mapping that gives one value for any particular input, so x² is a function, since for any value of x, there is exactly one value for x². Another way to say this is that if x = y, then x² = y². To solve the previous challenge problem, we have to have constructs in RDFS-Plus that have this same sort of behavior; that is, we want to describe something as being able to refer to only a single value.

The next two constructs, FunctionalProperty and InverseFunctionalProperty, we describe use this idea to determine when two resources refer to the same individual, thereby providing the OWL modeler with a means for describing how information from multiple sources are to be considered as a distributed web of information. These constructs provide an important semantic framework for using RDFS-Plus in the Semantic Web setting.

Functional Properties

RDFS-Plus borrows the name functional to describe a property that, like a mathematical function, can only take one value for any particular individual. The precise details of the meaning of owl:FunctionalProperty is given, as usual, as an inference pattern. If we have the following triples:

P rdf:type owl:FunctionalProperty.

X PA.

X PB.

then we can infer that

A owl:sameAs B.

This definition of owl:FunctionalProperty is analogous to the mathematical situation in which we know that x² has a single unambiguous value. More precisely, if we know that x² = a and x² = b, then we may conclude that a = b. In RDFS-Plus, this looks as follows, in which the first three triples are asserted and the fourth is inferred:

math:hasSquare rdf:type owl:FunctionalProperty.

x math:hasSquare A.

x math:hasSquare B.

A owl:sameAs B.

Functional properties are important in RDFS-Plus because they allow sameness to be inferred. For instance, suppose that in the Stratford Parish Registry we have an entry that tells us

lit:Shakespeare fam:hasFather bio:JohannesShakspere.

and that from Shakespeare’s grave we learn that

lit:Shakespeare fam:hasFather bio:JohnShakespeare.

We would like to conclude that John and Johannes are in fact the same person. If we know from a background model of family relationships that

fam:hasFather rdf:type owl:FunctionalProperty.

then we can conclude, from the definition of owl:FunctionalProperty, that

bio:JohannesShakspere owl:sameAs bio:JohnShakespeare.

as desired.

Although owl:FunctionalProperty provides us with a means of concluding that two resources are the same, this is not the usual pattern for determining that two entities are the same in most real data. Much more common is the closely related notion of owl:InverseFunctionalProperty, which we treat next.

Inverse Functional Properties

Some people consider owl:InverseFunctionalProperty to be the most important modeling construct in RDFS-Plus, especially in situations in which a model is being used to manage data from multiple sources. Whether or not this is true, it is certainly true that it has the most difficult name with respect to its utility of any construct.

The name owl:InverseFunctionalProperty was chosen to be consistent with the closely related owl:FunctionalProperty, and in fact one can think of an owl:InverseFunctionalProperty simply as the inverse of an owl:Functional Property. So if math:has Square is a functional property, then its inverse, math: hasSquareRoot, is an inverse functional property.

What exactly does this mean in terms of inferences that can be drawn? The rule looks very similar to the rule for owl:FunctionalProperty. If we know that

P rdf:type owl:InverseFunctionalProperty.

A PX.

BPX.

then we can infer that

A owl:sameAs B.

For example, if we define a property buriedAt to be sufficiently specific that we cannot have two people buried at the same location, then we can declare it to be an owl:InverseFunctionalProperty.If we were then to have two triples that assert

spr:Shakespere buriedAt :TrinityChancel.

lit:Shakespeare buriedAt :TrinityChancel.

then we could infer that

spr:Shakespere owl:sameAs lit:Shakespeare.

An owl:InverseFunctionalProperty plays the role of a key field in a relational database. A single value of the property cannot be shared by two entities, just as a key field may not be duplicated in more than one row. Unlike the case of a relational database, RDFS-Plus does not signal an error if two entities are found to share a value for an inverse functional property. Instead, RDFS-Plus infers that the two entities must be the same. Because of the nonunique naming assumption, we cannot tell that two entities are distinct just by looking at their URIs.

Examples of inverse functional properties are fairly commonplace; any identifying number (Social Security number, employee number, driver’s license number, serial number, etc.) is an inverse functional property. In some cases, full names are inverse functional properties, though in most applications, name duplications (is it the same John Smith?) are common enough that full names are not inverse functional properties. In an application at the Boston Children’s Hospital, it was necessary to find an inverse functional property that would uniquely identify a baby (since newborns don’t always have their Social Security numbers assigned yet). The added catch was that it had to be a property that the mother was certain, or at least extremely likely, to remember. Although babies are born at any time of day in a busy hospital, it is sufficiently unusual for two babies to be born at exactly the same minute that time of birth could be used as an inverse functional property. And every mother was able to remember when her baby was born.

Now that we have inverse functional properties, we are able to continue the solution to the challenge. Previously, we merged information from two databases by matching the global URIs of individuals from two databases with the following series of owl:sameAs triples:

p:Product1 owl:sameAs mfg:Product4.

p:Product2 owl:sameAs mfg:Product6.

p:Product4 owl:sameAs mfg:Product3.

p:Product5 owl:sameAs mfg:Product1.

p:Product7 owl:sameAs mfg:Product5.

p:Product8 owl:sameAs mfg:Product8.

Once we had these triples, we were able to cross-reference cities with facilities, using products as an intermediary. But we had to create these triples by hand.

Although this use of owl:InverseFunctionalProperty works fine for an example like this, most real data integration situations rely on more elaborate notions of identity that include multiple properties as well as uncertainty (what about that one freak day when two babies were born the same minute and the same second at the same hospital?). This problem can often be solved by using combinations of OWL properties that we will explore later in this book, although a fully general solution remains a topic of research.

Combining Functional and Inverse Functional Properties

It is possible and often very useful for a single property to be both an owl:FunctionalProperty and an owl:InverseFunctionalProperty. When a property is in both of these classes, then it is effectively a one-to-one property; that is, for any one individual, there is exactly one value for the property, and vice-versa. In the case of identification numbers, it is usually desirable that the property be one-to-one, as the following challenge illustrates.

To summarize, there are several ways we can use these properties:

Functional only—hasMother is a functional property only. Someone has exactly one mother, but many people can share the same mother.

Inverse Functional Only—hasDiary is an inverse functional property only. A person may have many diaries, but it is the nature of a diary that it is not a collaborative effort; it is authored by one person only.

Both Functional and Inverse Functional—taxID is both inverse functional and functional, since we want there to be exactly one taxID for each person and exactly one person per taxID.

A FEW MORE CONSTRUCTS

RDFS-Plus provides a small extension to the vocabulary beyond RDFS, but these extensions greatly increase the scope of applicability of the language. In the preceding examples, we have seen how these new features interact with the features of RDFS to provide a richer modeling environment. The inclusion of owl:inverseOf combines with rdfs:subClassOf by allowing us to align properties that might not have been expressed in compatible ways in existing data schemas. The inclusion of owl:TransitiveProperty combines with rdfs:subPropertyOf in a number of novel combinations, as seen here, allowing us to model a variety of relationships among chains of individuals.

The most applicable extensions, from a Semantic Web perspective, are those that deal with sameness of different individuals. sameAs, FunctionalProperty, and InverseFunctionalProperty in particular provide the OWL modeler with a means for describing how information from multiple sources is to be merged in a distributed web of information.

OWL provides a few more distinctions that, although they do not provide any semantics to a model, provide some useful discipline and provide information that many editing tools can take advantage of when displaying models. For example, when displaying what value some property takes for some subject, should the GUI display be a link to another object or a widget for a particular data type? Tools that get this right seem intuitive and easy to use; tools that don’t seem awkward. So OWL provides a way to describe properties that can help a tool sort this out. This is done in OWL by distinguishing between owl:DatatypeProperty and owl:ObjectProperty.

In RDF, a triple always has a resource as its subject and predicate, but it can have either another resource as object or it can have a data item of some XML data type. We have seen plentiful examples of both of these:

ship:QEII ship:maidenVoyage “May 2, 1969”.

mfg:Product1 mfg:Product_SKU “FB3524”.

AnneHathawaybio:married lit:Shakespeare.

GraduallyMix inSameRecipe BeatEggs. spr:Susanna

spr:hasFather spr:WilliamShakspere.

Most tools that deal with OWL at this time prefer to make the distinction. In this case, ship:maidenVoyage and mfg:Product_SKU are datatype properties, while bio:married, inSameRecipe, and spr:hasFather are object properties. In triples, we say:

ship:maidenVoyage rdf:type owl:DatatypeProperty.

mfg:Product_SKU rdf:type owl:DatatypeProperty.

bio:married rdf:type owl:ObjectProperty.

inSameRecipe rdf:type owl:ObjectProperty.

spr:hasFather rdf:type owl:ObjectProperty.

Another distinction that is made in OWL is the difference between rdfs:Class and owl:Class.

In Chapter 6, we introduced the notion of rdfs:Class as the means by which schema information could be represented in RDF. Since that time, we have introduced a wide array of “schema-like” constructs like inverse, subproperty, transitivity, and so on. OWL also provides a special case of rdfs:Class called owl:Class. Since OWL is based on RDFS, it was an easy matter to make owl:Class backward compatible with rdfs:Class by saying that every member of owl:Class is also a member of rdfs:Class. This statement needn’t be made in prose, since we can say it in RDFS. In particular, the OWL specification stipulates that

owl:Class rdfs:subClassOf rdfs:Class.

Most tools today insist that classes used in OWL models be declared as members of owl:Class. In this chapter, we have left these class declarations out, since this level of detail was not needed for the modeling examples we provided. Implicit in the examples in this chapter, are statements such as

:Food rdf:type owl:Class.

:BakedGood rdf:type owl:Class.

:Confectionary rdf:type owl:Class.

:PackagedFood rdf:type owl:Class.

:PreparedFood rdf:type owl:Class.

:ProcessedFood rdf:type owl:Class.

mfg:Product df:type owl:Class.

p:Product rdf:type owl:Class.

Most OWL tools today will work more consistently if classes are defined as instances of owl:Class; most model editors will do this automatically when a class is created. However, there are subtle distinctions that we will discuss more in Chapter 13.

SUMMARY

The constructs in RDFS-Plus are a subset of the constructs in OWL. This subset provides considerable flexibility for modeling in the Semantic Web. In the next chapter, we will see some examples of how RDFS-Plus is used in some large-scale Semantic Web projects. A summary of the constructs in this set follow.

Fundamental Concepts

rdfs:subClassOf—Members of subclass are also member of superclass.

rdfs:subPropertyOf—Relations described by subproperty also hold for superproperty.

rdfs:domain—The subject of a triple is classified into the domain of the predicate.

rdfs: range—The object of a triple is classified into the range of the predicate

Annotation Properties

rdfs:label—No inferential semantics, printable name

rdfs:comment—No inferential semantics, information for readers of the model

OWL Features: Equality

equivalentClass—Members of each class are also members of the other.

equivalentProperty—Relations that hold for each property also hold for the other.

sameAs—All statements about one instance hold for the other.

OWL Features: Property Characteristics

inverseOf—Exchange subject and object

TransitiveProperty—Chains of relationships collapse into a single relationship.

SymmetricProperty—A property that is its own inverse

FunctionalProperty—Only one value allowed (as object)

InverseFunctionalProperty—Only one value allowed (as subject)

ObjectProperty—Property can have resource as object.

DatatypeProperty—Property can have data value as object.