This book is about modeling in the context of the Semantic Web—in particular, using the W3C languages RDF, RDFS, and OWL to build and distribute those models. The meaning of these models is given by the inferences that each of these languages defines for the models. RDFS provides rudimentary inferencing about types based on class membership and properties. OWL provides a wide array of more advanced modeling features to describe how data can be related.

In Chapter 7, we introduced a subset of OWL that we called RDFS-Plus. There are a number of reasons why someone might define a subset of a language like OWL. In the case of RDFS-Plus, we were interested in a subset of the language that has considerable utility for semantic modeling but does not place a large burden on either a modeler or someone trying to understand a model. RDFS-Plus includes features that are similar to what can be found in familiar data representation systems like relational database and object-oriented systems. Researchers, implementers, and product developers have defined a number of subsets based on modeling expressivity, computational complexity, and, often, on what parts of the OWL language can best be handled by whatever inferencing system is already in place.

In the initial OWL specification, the W3C identified three particular variants (or “species”) of OWL, which they called OWL Lite, OWL DL, and OWL Full. The distinction between OWL DL and OWL Full is particularly subtle, and it is the topic of much of this chapter. We will examine the motivations behind these variants and the ramifications these motivations have in terms of technology and modeling style.

Any language will grow as it is used, especially a Semantic Web language. Realizing this, the W3C processes encourage the evolution of languages to provide new functionality while maintaining backward compatibility. As we shall see, there are a number of useful modeling idioms that are clumsy or impossible in the current definition of OWL. This chapter outlines the particular features that are being considered in the ongoing process in the W3C for the OWL recommendation.¹

OWL DIALECTS AND MODELING PHILOSOPHY

Normally, when we refer to different subsets of a language, we can list the language structures in one subset that are not found in the other. For instance, RDFS has rdfs:domain, rdfs:range, rdfs:subPropertyOf, and so on, whereas RDFS-Plus has all of those, plus some new language features like owl :inverseOf and owl: TransitiveProperty. We can define how these two languages are similar or different, based on which language terms are available in each one.

In the case of OWL Full and OWL DL, the situation is more subtle. Both OWL Full and OWL DL use exactly the same set of modeling constructs. That is, if we were to list all the properties and classes that make up OWL Full and then compile the same list for OWL DL, the lists would be exactly the same. In fact, it would be the list of OWL features that you have been reading about in this book. Everything you have learned so far applies equally well to OWL Full and OWL DL.

So what is the difference? What was so important that the W3C saw fit to make two distinct standards if they have the same language constructs and the same meanings? The distinction between these two variants—or “species,” as they are often called—of OWL has to do with how the language constructs are used. The differences in allowed usage are motivated by a difference in the basic philosophy of why one builds models for the Semantic Web. We will outline these two basic philosophies—one in which the emphasis is placed on having provable models and one in which the emphasis is placed on making executable models. We examine each in turn, along with the intuitions that motivate them.

Provable Models

An important motivation for formal modeling (as opposed to informal modeling) is to be precise about what our models mean. In the context of the Semantic Web, this tells us precisely and without doubt when concepts from two different sources refer to the same thing. Does my notion of a James Dean movie correspond to yours? A formal description can help us determine whether or not this is the case. My definition of a “James Dean movie” is one that stars James Dean, but your definition of a “James Dean movie” might be movies about James Dean or movies with the words James Dean in the title. How can we tell if we have the name “James Dean movie” as the only indication of these definitions? A formal model makes these distinctions clearer. Then it becomes a simple matter of automation to decide whether two classes are the same, if one subsumes the other, or if they are unrelated.

It is this aspect of modeling that motivates a logical definition of OWL. Each construct in OWL is a statement in a formal logic. The particular logical system of OWL DL is called Description Logic. As the name suggests, Description Logic is a logical system with which formal descriptions of classes, individuals, and the relationships between them can be made. The inferences in OWL that have formed the basis of the bulk of this book are formally defined by a model theory based on Description Logic.

Using logic as the foundation of a modeling language makes perfect sense; we can draw upon decades, or even centuries, of development work in logical formalism. The properties of various logical structures are well understood. Logic provides a framework for defining all of the inferences that our modeling language will need. But there is one fly in the ointment: In a computational setting, we would like our logic to be processed automatically by a computer. Specifically, we want a computer to be able to determine all of the inferences that any given model entails. So, if we want to be able to automatically determine whether my notion of a James Dean movie is exactly the same as yours, we must show the set of all facts true in one are true in the others, and all facts untrue are untrue.

It is at this point that the details of the logic become important. What does it mean for our modeling formalism if we base it on a logic for which this kind of automation cannot, in principle, exist? That is, what happens if we can’t exactly determine whether my notion of a James Dean movie is the same as yours? If we view this sort of provable connection as essential to the nature of modeling, then we have failed. We simply cannot tolerate a logic in which this kind of question cannot be answered by automated means in some finite amount of time.

In the study of formal logic, this question is called decidability. Formally, a system is decidable if there exists an effective method such that for every formula in the system the method is capable of deciding whether the formula is valid (is a theorem) in the system or not. If not, then the system is undecidable. It is not our intention in this book to go into any detail about the mathematical notion of decidability, but a few comments on its relevance for modeling are in order.

The first thing to understand about decidability is also the most surprising: how easy it is for a formal system to be undecidable. Given the formal nature of logic, it might seem that, with enough patience and engineering, a program could be developed to correctly and completely process any formal logic. One of the most influential theorems that established the importance of the notion of decidability shows that even very simple logical systems (basically, any system that can do ordinary integer arithmetic) are undecidable. In fact, it is actually quite challenging to come up with a logical system that can represent anything useful that is also decidable.

This bit of tightrope walking is the impetus behind the OWL DL sublanguage. OWL DL is based on a particular Description Logic. This means that it is possible to design an algorithm that can take as input any model expressed in OWL DL and determine which classes are equivalent to other classes, which classes are subclasses of other classes, and which individuals are members of which classes. The most commonly used algorithm for this problem is called the Tableau Algorithm. It works basically by keeping track of all the possible relations between classes, ruling out those that are inconsistent with the logical statements made in the model. The Tableau Algorithm is guaranteed to find all entailments of a model in OWL DL in a finite (but possibly quite long!) time. Furthermore, it is possible to determine automatically whether a model is in fact in OWL DL so that a program can even signal when the guarantees cannot be met.

Modeling in OWL DL supports the intuition that a model must be clear, unambiguous, and machine-processable. The Tableau Algorithm provides the machinery by which a computer system can make determinations about equivalence of classes.

Executable Models

A different motivation for modeling in the Semantic Web is to form an integrated picture of some sort of domain by federating information from multiple sources. If one source provides information about the places where hotel chains have hotels and another describes what hotels appear at a particular place, a formal model can tell us that we can merge these two sources together by treating them as inverses of one another. The model provides a recipe for adding new information to incomplete information so it can be federated with other sources.

Seen from this point of view, a model is similar to a program. It provides a concise description of how data can be transformed for use in other situations. What is the impact of decidability in such a situation? Standard programming languages like FORTRAN and Java are undecidable in this sense. The undecidability of these languages is often demonstration with reference to the Halting Problem. It is impossible in principle to write a computer program that can take another arbitrary computer program as input, along with input for that program, and determine whether that program will halt on that input. Even though these languages are undecidable, they have proven nevertheless to be useful engineering languages. How can we write programs in these languages if we can’t automatically determine their correctness or, in some sense, even their meaning? The answer to this question in these cases is what programming is all about. Even though it is not possible in general to determine whether any program will terminate, it is usually possible to determine that some particular program will terminate and, indeed, with what answer. The skill of engineering good computer programs is to write programs that not only will terminate on all input but will actually perform well on particularly interesting input.

Seen from this point of view, decidability is not a primary concern. Models are engineered in much the same way as programs. If a model behaves poorly in some situation, then an engineer debugs the model until it performs correctly. Since we are not concerned with decidability, we don’t need the guarantee that any algorithm will find all possible inferences. This opens up the choice of processor for OWL to a much wider range of algorithms, including algorithms like Forgy’s RETE algorithm that have enjoyed considerable popularity as processors for rule-based languages.

It’s also the case that, in many Web applications, the size of datasets we would like to analyze are quite huge, dynamic, or not well represented. The question could be asked as to whether one needs a 100 percent correct model to analyze data that is itself scraped from the Web by some heuristic program that is not perfect. On the Web, people use Google because it can find good answers a lot of the time, even if it can’t find perfect answers all the time. Some Semantic Web systems are targeted at this rough-and-tumble Web application space, and thus provable correctness, as opposed to efficient computation, may not be a key goal.

This executable style of modeling is the primary motivation behind the OWL Full standard. The meaning of a modeling construct in OWL Full is given in much the same way as the meaning of a construct in a programming language. Just as the meaning of a statement in a procedural programming language is given by the operation(s) that a machine will carry out when executing that statement, the meaning of an executable model is given by the operation(s) that a program (i.e., an inference engine) carries out when processing the model. Information federation is accomplished because the model describes how information can be transformed into a uniform structure.

OWL FULL VERSUS OWL DL

So far, we have described the motivation behind OWL Full and OWL DL without actually describing what the differences are in terms of the actual language. The first thing to understand about OWL DL and OWL Full is that they use exactly the same constructs. Every modeling construct you have learned in this book can be used for both. The inferences that you can draw from them are also the same, with the understanding that in the case of OWL Full, it might not be possible for an automated system to draw all correct conclusions, while in OWL DL it may not be possible to use every feature in every way.

The difference between the languages lies in the usage. Describing these differences is also problematic, since the determination of the precise boundary between OWL Full and OWL DL is a popular topic for Description Logic researchers. Many of the restrictions that were originally defined for OWL DL have since been proven to be too harsh. Inclusion of these usages has been shown not to damage the decidability of the model. For this reason, it is more important to understand the decidability-based motivation of the distinction than any particular usage distinction. Here we will outline the major kinds of restrictions on the modeling language that are enforced by OWL DL. The details of these may continue to change as research in description logic proceeds.

Class/Individual Separation

In OWL DL, classes and individuals are completely separate; that is, a model cannot specify that some resource is both a class and a member of a class. Recalling an example from Chapter 6, we defined a number of ranks as classes:

ship:Captain rdfs:subClassOf ship:Officer.

ship:Coniniander rdfs:subClassOfship:Officer.

ship:LieutenantCommander rdfs:subClassOfship:Officer.

ship:Lieutenant rdfs:subClassOfship:Officer.

ship:Egn nsirdfs:subClassOfship:Officer.

We can specify the rank of an individual using membership in one of these classes:

:Warwick rdf:type ship:Captain.

By virtue of their use in rdfs:subClassOf triples, all of the entities mentioned here are classes. In another context, we might want to express what we know about these ranks—for instance, these ranks have a particular order, by which Captain outranks Commander, which in turn outranks LieutenantCommander, and so on. We could express this relationship in RDF using a series of triples:

ship:Captain ship:outranks ship:Commander.

ship:Commander ship:outranks ship:LieutenantCommander.

ship:LieutenantCommander ship:outranks ship:Lieutenant.

ship:Lieutenant ship:outranks ship:Ensign.

We represent the use of ship:outranks with domain and range specifications as well:

ship:outranks rdfs:domain ship:Rank.

ship:outranks rdfs:range ship:Rank.

Although this seems like a natural thing to do, it violates the separation of class and individual in OWL DL. Each rank is a class (with members who hold that rank), but the domain and range information of ship:outranks makes each rank also a member of the class rank, so they are individuals. In OWL Full, there is no condition forbidding this usage.

InverseFunctional Datatypes

In Chapter 7, we learned that owl:InverseFunctionalProperty is an important construct for data federation. Whenever two individuals share a value for an InverseFunctionalProperty, we can infer that they are the same individual. Things like social security number, employee number, driver’s license number, serial number, and so on are commonly used this way. In Chapter 8 we saw that FOAF uses foaf:mbox this way.

Unfortunately, OWL DL has a condition that outlaws exactly these uses. It stipulates that an InverseFunctionalProperty must not also be a DatatypeProperty—that is, it cannot refer to a string, date, number, and so on. In other words, exactly the things that make up social security numbers, e-mail addresses, and dates of birth are forbidden from InverseFunctional Properties. This is a stringent restriction and one that is quite often responsible for placing a model into OWL Full instead of OWL DL.

OWL LITE

Along with OWL Full and OWL DL, the original OWL specification identified a subset of OWL DL with the intention that it would be easier to implement and would accelerate the adoption of OWL. As OWL implementations mature, the significance of OWL Lite is fading. Many implementations have skipped over OWL Lite entirely and gone directly into support of OWL Full or OWL DL or, more commonly, proceeded to supporting a proprietary subset of OWL. The simplifications in OWL Lite include the following.

Limited Cardinality Restrictions: Cardinality restrictions are limited in OWL Lite to the integers 0 and 1, but, as we have seen in Chapter 10, cardinality restrictions to 0 or 1 have natural and common interpretations. Most cardinality restrictions in real models use 0 or 1 anyway.

No oneOf constructs: OWL Lite does not include owl:oneOf constructs. This is in line with a simplified model of cardinality.

No hasValue restrictions: OWL Lite does not include any of the owl :hasValue restrictions.

OTHER SUBSETS OF OWL

OWL Full, OWL DL, and OWL Lite are the only sublanguages defined in the OWL specification, but they’re certainly not the only ones in use. As different companies implement OWL tools, they can decide which parts of OWL to implement. Similarly, for different modeling needs, different subsets may prove useful. We’ve already seen an example in this book—RDFS-Plus is defined earlier as being useful in modeling and is being implemented in some systems; however, it is not an “official” OWL language. Many other such OWL fragments have been designed and explored based on issues such as scalability and efficiency, as well as on decidability.

There is an important thing to note, however, in the use of these dialects. If the subsets use the restrictions of OWL DL, then they are in OWL DL (or OWL Lite if they use its restrictions). On the other hand, if the restrictions of DL are not followed, then the models technically are in OWL Full. So an ontology defined in RDFS-Plus could be in OWL DL or in OWL Full depending on the details. If the RDFS-Plus model includes a property that is both an InverseFunctionalProperty as well as a DatatypeProperty, for example, then it is technically in OWL Full even though it does not use many of the OWL language terms.

In general, users working with some particular subset of OWL are usually doing so based on using a particular tool, or trying to meet a particular need. In these cases, it often doesn’t really matter whether the ontology is in OWL Full, OWL DL, or OWL Lite.

BEYOND OWL 1.0

Web languages, like applications, often go through a versioning process. As new users come along with new needs, the languages evolve. Eventually, new standardization efforts can create new versions of the language. OWL is currently in a relatively early stage of its development, and thus there is an expectation that it will be extended in the future. To this end, some have taken to referring to the current OWL specification as OWL 1.0, in anticipation of future releases. In this chapter, we discuss some of the extensions that Semantic Web developers are exploring that go beyond OWL 1.0.

Metamodeling

Metamodeling is the name commonly given to the practice of using a model to describe another model as an instance. One feature of metamodeling is that it must be possible to assign properties to classes in the model. But as we have just seen, putting properties on classes typically violates the separation of class and individual that allows a model to be described in OWL DL.

A number of motivations for metamodeling exist. One such motivation is that a model often needs to play more than one role in an application: A particular concept should be viewed as a class in one role but as an instance in another role. If we are modeling animals, we might say that BaldEagle is an endangered species, thereby referencing BaldEagle as an individual. In another application, we could view BaldEagle as a class, whose members are the particular eagles in the zoo. Similarly, wine connoisseurs speak of individual wines in terms of vintage. For them, the vintage is an individual, but for a wine merchant who is calculating how many bottles he has sold, the bottles themselves are individual members of the class that are indicated by the vintage.

We have already seen a number of examples of this kind of metamodeling in this book. In Chapter 8, we saw how a foaf:Group is an individual that corresponds to a class of all the members of the group. In Chapter 11, we saw how the Class-Individual Mirror pattern allowed us to view a line of business either as an individual or as a class of all the subfunctions that comprise it. In Chapter 13, we saw how military ranks can be seen as both classes and individuals.

Another purpose of metamodeling is to imitate capabilities of other modeling systems (like object-oriented modeling) in which the value for some property can be specified for all members of a class at once. Metamodeling in itself is not an issue in OWL Full, since there is no restriction against using the same resource as an individual and as a class. The formal issues really arise only when trying to achieve the results of metamodeling in OWL DL. Although there is no formal issue with overloading a single resource to refer to a class and an individual, currently it is often best to keep these things separate, even in OWL Full. There really is a difference between a species and the set of animals of that species; there is a difference between Shakespeare’s family and the set of people in it. These distinctions could be important to someone who wants to reuse a model. Keeping them distinct in the first place will often enhance the model’s utility.

Fortunately, there are a number of possible approaches to doing metamodeling in OWL (either OWL DL or OWL Full). For most situations, we recommend the Relationship Transfer pattern from Chapter 9 or the Class-Individual Mirror pattern from Chapter 11.

Recent Description Logic research has determined that in certain cases, the Class-Individual separation constraint can be relaxed without any danger to the decidability of the logic. Thus, it is possible to have a new version of OWL DL in which metamodeling of the sort we have described here can be done as easily in OWL DL as in OWL Full. Whether or not such a proposal reaches fruition in the OWL standard, we still recommend using one of the patterns in this book whenever possible instead of resorting to overloading resource usage.

Multipart Properties

In RDFS, we have seen how properties can relate to one another using rdfs: subPropertyOf. This establishes a hierarchy of properties: Any relations that hold lower in the hierarchy also hold higher in the hierarchy. There are other ways in which properties can relate to one another. A common example is the notion of uncle: A is the uncle of B only if A is the brother of someone who is the parent of B. This is called a multipart property—that is, the property uncle is made up of two parts (in order): parent and brother.

When multipart properties are used with other RDFS and OWL constructs, they provide some powerful modeling facilities. For instance, we can model the constraint “A child should have the same species as its parent” by stating that the multipart predicate made up of hasParent followed by hasSpecies (denoted as :hasParent + :hasSpecies) is rdfs:subPropertyOfhasSpecies. Let’s see how this works. Suppose we have the following triples:

:Elsie :hasParent :Lulu.

:Lulu :hasSpecies :Cow.

Now we can infer

:Elsie :hasParent + :hasSpecies :Cow.

But since the multipart predicate :hasParent + :hasSpecies is a rdfs: subPropertyOf :hasSpecies, we can infer that

:Elsie :hasSpecies :Cow.

One reason that multipart predicates were not included in OWL was that they were thought to cause undecidability, and thus could only have been available in OWL Full, not OWL DL. To add these to the language, new vocabulary terms were needed, and that would have meant that the parallel between OWL Full and OWL DL would have been changed. Recently, however, it has been shown that under certain conditions it is possible to represent multipart properties in OWL in such a way that they do not endanger the decidability of OWL DL.

Qualified Cardinality

Cardinality restrictions in OWL allow us to say how many distinct values a property can have for any given subject. Other restrictions tell us about the classes of which those values can or must be members. But these restrictions work independently of one another; we cannot say how many values from a particular class a particular subject can have. A simple example of qualified cardinality is a model of a hand: A hand has five fingers, one of which is a thumb.

Qualified cardinalities may seem like a needless modeling detail, and in fact, a large number of models get by quite fine without them. But models that want to take advantage of detailed cardinality information often find themselves in need of such detailed modeling. This happens especially when modeling the structure of complex objects.

For example, when modeling an automobile, it might be useful to say that a properly equipped automobile includes five tires, four of which must be regular road-worthy tires and a fifth that is a designated spare tire which might not have all the properties of a regular tire. Structural models of this sort often make extensive use of qualified cardinalities. Qualified cardinalities also will require syntactic extensions to OWL; in this case, however, they do work within the decidability constraints of OWL DL and thus they are likely to be added in a future version of OWL.

Multiple Inverse Functional Properties

Inverse functional properties can be used to determine the identity of individuals based on the values of the properties that describe them. If two people share the same social security number, then we can infer that they are actually the same person. This kind of unique identifier is indispensable when merging information from multiple sources.

Unfortunately, anyone who has done a lot of such integration knows that this kind of merging only scrapes the surface of what needs to be done. Far more common is the situation in which some combination of properties implies the identity of two or more individuals. For instance, two people residing at the same residence with the same first and last names should be considered to be the same person. Two people born in the same hospital on the same day and at the same time of day should be considered to be the same person. Examples of this kind of multiple identifiers are much easier to come by than single identifiers, as required for an InverseFunctionalProperty.

To further complicate matters, in real information federation situations, it is often the case that even these combinations of properties cannot guarantee the identity of the individuals. Two people at the same address with the same name are very likely to be the same person (but not for certain—a father could live with his son of the same name). OWL has no facility to deal with uncertainty, so there is no way to express this sort of information. Extending OWL to deal with uncertainty is a topic of current research and standardization efforts in the Semantic Web.

A few proposals have been made for how to deal with multiple inverse functional properties in OWL. However, expressing these bring up syntactic problems (how to express a relation including an arbitrary number of properties), as well as logical ones (what are the logical properties of the resulting system?). One proposal for dealing with these is to extend some or all of OWL by the use of rules, which have been proposed to be a more natural way of expressing complex relationships like this.

Rules

While OWL is the most powerful modeling system currently defined for the Semantic Web, it does have limitations. Some of these are best addressed, for the purposes of data management, using rules, and thus the development of a rules language for the Web is currently being explored.

Rule-based systems have a venerable tradition starting in the days of Expert Systems and are in common use in business logic applications to this day. A number of useful algorithms for processing data with rules have been known for many years, and many of them have been made very efficient.

Many of the issues with OWL presented in this chapter can be addressed with rules. Multipart properties (like the definition of uncle) are easily expressed in rules. Multiple inverse functional properties can be expressed in rules as well. There are even a number of approaches to reasoning with uncertainty in rules. Many of these have considerable research and practical examples behind them, making uncertainty in rules a relatively well-understood issue.

Given all these virtues of rules and rule-based systems, why don’t they play a bigger role in modeling on the Semantic Web than they do? In fact, one could even ask why there is a need for a modeling language like OWL when there is a mature, well-understood rules technology that already exists. One could even ask this question in greater generality. Why aren’t more software systems in general written in rules?

We cannot treat this issue in full detail in this book, but we can outline the answer as it relates to OWL and the Semantic Web. One of the lessons learned from the history of rule-based systems is that software engineering in such systems is more difficult than it is in modular, procedural languages. Although it is unclear whether or not this is an essential feature of rule-based systems, it is undeniable that rule-based programmers have not achieved the levels of productivity of their more conventional counterparts. This has particular ramifications in the Semantic Web. One defense for using OWL Full instead of OWL DL was that the software engineering discipline makes the notion of decidability basically irrelevant for model design. In the case of rule-based systems, software engineering cannot provide this same support. Unconstrained rule-based systems are just as undecidable as general-purpose languages like FORTRAN and Java.

Is there a way to get the best of both worlds? Could a Web-oriented rules language integrate well with OWL? It is clear that for some applications, such as the NCI Cancer Ontology discussed in Chapter 11, the class-oriented models of OWL are an excellent fit. For other applications, such as representing business processes, it may be the case that rule-based reasoning is better. At the time of this writing, there is a W3C standards group exploring the development of an interoperable rules language for the Web and trying to clearly define the relationship between this language and OWL.

SUMMARY

OWL should be considered a living language, growing in the context of the ways it is being used on the web and in commerce. As shortcomings in the language are identified, the system grows to accommodate them. Sometimes that growth takes the form of additional constructs in the language (e.g., multipart properties), sometimes as connections to other systems (rules), and sometimes progress in a language comes from specifying limitations to the language (as is the case for OWL DL and OWL Full). All of these processes are moving in parallel for the Semantic Web.

Fundamental Concepts

OWL Full—Unrestricted dialect of OWL, with all the constructs used in any combination.

OWL DL—Dialect of OWL restricted to ensure decidability; all constructs allowed but with certain restrictions on their use.

OWL Lite—Subset of OWL DL designed to encourage early adoption. Significance wanes as implementations reach OWL DL and OWL Full levels.

Metamodeling—Models that describe models, usually requires that classes be treated as individuals.

Multipart properties—Daisy-chain composition of properties.

Multiple Inverse Functional Properties—Uniquely identify an individual based on matching values for several properties.

Qualified Cardinality—Cardinality restriction whereby the class of the value being counted is specified as well as the number of distinct values.