Just as in any computer language (modeling languages, markup languages, or programming languages), sometimes it is helpful if a document author can leave natural language comments about a model for future readers to see. Since RDFS is implemented entirely in RDF, the comment feature is also implemented in RDF. To make a comment on some part of a model, simply assert a triple using the property rdfs:commentas a predicate. For example:
sales:nextDeparture rdfs:comment "This indicates the next planned departure date for a salesperson."
SUMMARY
RDFS is the schema language for RDF; it describes constructs for types of objects (Classes), relating types to one another (subClasses), properties that describe objects (Properties), and relationships between them (subProperty). The Class system in RDFS includes a simple and elegant notion of inheritance, based on set inclusion; one class is a subclass of another means that instances of the one are also instances of the other.
The RDFS language benefits from the distributed nature of RDF by being expressed in RDF itself. All schema information (classes, subclasses, subproper- ties, domain, range, etc.) is expressed in RDF triples. In particular, this makes schema information, as well as data, subject to the AAA slogan: Anyone can say Anything about Any topic—even about the schema.
The semantics of RDFS is expressed through the mechanism of inferencing; that is, the meaning of any construct in RDFS is given by the inferences that can be inferred from it. For example, it is this simple but powerful mechanism for specifying semantics that allows for the short and elegant definition of subclass and subproperty.
RDFS also includes the constructsrdfs:domainand rdfs:rangeto describe the relationship between properties and classes. The meanings of these con- structs are given by very simple rules, but these rules have subtle and far-reaching impact. The rules may be simple, but the statements are powerful.
Even with its small set of constructs and simple rules, RDFS allows for the resolution of a wide variety of integration issues. Whenever you might think of doing a global find-and-replace in a set of structured data, consider using
rdfs:subPropertyOforrdfs:subClassOfinstead. It may seem trivial to say that
one should merge only entities from multiple sources that don’t have important differences. Using the inference mechanism of RDFS, we can determine just what happens when we do merge things and judge whether the results are desirable or dangerous. Although RDFS does not provide logical primitives like union and intersection, it is often possible to achieve desired inferences by using specific patterns of subClassOf and subPropertyOf. RDFS provides a framework through which information can flow; we can think of subClassOf
and subPropertyOf as the IF/THEN facility of semantic modeling. This utility
persists even when we move on to modeling in OWL. In fact, usingsubClassOf in this way provides a cornerstone of OWL modeling.
When used in careful combination, the constructs of RDFS are particularly effective at defining how differently structured information can be used together in a uniform way.
Fundamental Concepts
The following fundamental concepts were introduced in this chapter.
rdfs:subClassOf—Relation between classes, that the members of one class
are included in the members of the other.
rdfs:subPropertyOf—Relation between properties, that the pairs related
by one property are included in the other.
rdfs:domain and rdfs:range—Description of a property that determines
class membership of individuals related by that property.
Logical operations (Union, Intersection, etc.) in RDFS—RDFS constructs
can be used to simulate certain logical combinations of sets and properties.
CHAPTER
7
RDFS-Plus
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:
n Pedagogically, these constructs constitute a gentle addition to the con- structs that are already familiar from RDFS, increasing the power of the language without making a large conceptual leap from RDFS.
n 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. n 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 123
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 com- mon, everyday interpretation. The idea owl:inverseOfis 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 nameshasParentandhasChild, you can guess the rela- tionship 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 f1) is the
function that satisfies the property that if f(x)¼y, then f1( 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 . x P y .
then we can infer that y Q x .
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 ofowl:inverseOfis not difficult to describe, what is the utility of such a construct in a modeling language? After all, the effect ofinverse- Of can be achieved just as easily by writing the query differently. For instance,
if we want to know all the plays that aresetInScotland, we can use the inverse propertysettingForin 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
weresetInScotland.
But we could have avoided the use of the inverse property and simply writ- ten 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:inverseOfnevertheless 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.