OWL Limitations
In this chapter, we briefly introduce some variants of OWL and describe some limitations of the most widely used variant: OWL 2 DL.
When first released in 2004, there were three OWL variants (sometimes called species): OWL Lite, OWL DL, and OWL Full. When OWL 2 was released in 2012, OWL Lite went away and OWL Full was updated. This chapter will focus on OWL 2 DL, which is the most widely used OWL variant. Unless otherwise specified, when I say OWL or OWL DL, I will be referring to OWL 2 DL.
The Main Limitations
There are a variety of limitations that are important to be aware of in your day to day modeling. As with any designed artifact, the design of the OWL language involved navigating various tradeoffs. The major one follows from a result in theoretical computer science saying that even a small amount of additional expressivity can have a major negative impact on the ability to build efficient inference engines. The OWL designers consciously chose to favor inference performance, giving up some expressive power.
This chapter explains the things that you cannot say in OWL DL that were traded off to get that performance. They relate to the idea of metaclasses, what you can have as an object of a triple, rules, property chains, dates and cardinality restrictions. In particular:
1. you cannot create true metaclasses;
2. not all triples are created equal; there are some things you cannot do with user-created properties and classes that are possible with classes and properties that are part of the OWL language;
3. certain kinds of rules are not allowed;
4. you cannot specify just a date, you need so specify the time as well; and
5. not all properties can be used with all kinds of restrictions.
Pertinent to the discussion below is the distinction between properties and classes that the ontologist user of OWL creates vs. those that are part of the OWL language. See Table 7.1 for examples.
User-created |
OWL Construct |
|
Properties |
|
|
Classes |
|
|
7.1 METACLASSES
Most of the classes that you will be creating will have member individuals where those individuals are just that, individuals. A member of the class :Person is an individual person. A member of the class :Agreement is an individual agreement. It does not make any sense to think of an individual person or agreement as a set that also has members.
However, this is not always the case. Suppose you want to create a class that corresponds to a product model like iPhone7 or Lenovo T470P. You could create a class called ProductModel. It could have two subclasses, SmartPhoneModel and LaptopModel, with _iPhone7 and _LenovoT470P as member individuals, respectively. In this case, it does make sense to think of the members of the ProductModel class as more than just individuals. In the world, a particular smartphone model or a laptop model corresponds to the set of all individual phones or laptops that are instances of those particular models. Because they are sets, one might reasonably create classes for each product model.
The fact that their member individuals are themselves classes makes the product model classes quite different from the other classes we have considered. This introduces the concept of a metaclass: a class whose members are also classes.24 Unfortunately, OWL DL does not allow something to be both an individual and a class at the same time. Another way to put this is there cannot be two consecutive rdf:type links connecting user-created individuals and classes. This is depicted in Figure 7.1.
If metaclasses were allowed, our naming convention would not always work. The item would need to both have a leading underscore and to not have a leading underscore. The brown arrows show the iPhone 7 being represented as an instance of SmartPhoneModel. The blue arrows show it as a class whose instances are individual iPhone 7’s. The situation is exactly analogous for laptop models.
You have to decide whether you represent the product model as a class or as an instance. Figure 7.2 shows two options for representing the iPhone 7.
Figure 7.2: Two workarounds to avoid a metaclass.
1. Create the individual, _iPhone7 as an instance of a class, SmartPhoneModel. Use the property hasModel to indicate the model of a particular phone.
2. Create the class, IPhone7, in a class hierarchy of kinds of phones. Use the property rdf:type to indicate the model of a particular phone.
The first approach would make sense in a product development or marketing context, where there is no interested in tracking individual phones. The second approach would make sense for a retail operation where serial numbers for individual phones matter for inventory and for servicing maintenance plans such as Apple Care.
What if you want to build and integrate systems that handle both aspects? This means you need to say things about the product model, so it will need to be an individual. This is option 1 in Figure 7.2.
What you give up is the ability to use OWL’s built in sub-classing and inheritance mechanism for kind of products. For example, because iPhone7 and iPhone would both be instances, you cannot use rdfs:subClassOf to relate them. You would have to use a different property, perhaps skos:broader and use SPARQL to achieve any inheritance inferencing you may need.
A Non-workaround: OWL Punning
The OWL spec allows you to use a single IRI such as :IPhone7 to represent both the class of iPhones that has individual phones as instances, and also as an individual representing a particular model of smartphone. This is called punning, because one IRI is being used to represent both a class and an individual.
This contrasts from our approach of using two IRIs, as depicted in Figure 7.2. The OWL spec mentions the words “metamodeling” and “metaclass” in this context, but I find that misleading. Punning only gives the illusion of the true sense of a metaclass. Why? Because the OWL 2 DL semantics dictates that the reasoners treat “different uses of the same name as completely separate.”25 Under the covers, OWL reasoners have to do extra work to keep track of the fact that there are really two different things with the same name. The net result is no different than if you has used two different IRIs. That is why I call it a non-workaround.
You might wonder what this buys you. I wonder too. It’s a bit of syntactic trickery that brings to mind the phrase “worse than useless.” First, it does not address the fundamental limitation about metaclasses. Second, by giving the illusion of representing metaclasses, it is going to cause confusion. If you manage to avoid confusing yourself, you will almost certainly confuse others trying to understand and use your ontology.
All of the triples we have shown that have user-created properties as the predicate, have objects that are either literals or OWL individuals. However, sometimes it would be convenient to have the object be a class or a property.
Classes as Property Values
Suppose we created the classes IPhone7 and LenovoT470P that we described above. Say we are also interested in classifying books and newspaper and magazine articles by topic, and one of the more narrow topics is the iPhone 7. It would be convenient to just have a triple that connects an article to the class.
Figure 7.3: The object of a triple cannot be a class.
Unfortunately, this is not possible in OWL DL. Although it is common for classes to be objects of triples with existing predicates such as rdfs:range, rdfs:subClassOf, and rdf:-type, you cannot create a property and use it in a triple where the object of the triple is a class. This is depicted in Figure 7.3.
This problem and various workarounds is described in detail in the document: “Representing Classes As Property Values on the Semantic Web.”26 A fascinating paper on what it means to be a subject that touches on this issue is “A Formal Ontology of Subject,” by Chris Welty.27
Properties as Property Values
The object of a triple cannot be a property either; it must be an individual or a literal. The desire for the latter arises when modeling product specifications. But first let’s consider a particular phone. Say it weighs 138 g and has 2GB of RAM. An easy thing to do would be to create two data properties called, say :weightInGrams and :gigOfRAM each with a range of xsd:decimal. Then the values for those data properties for that particular phone would be 138 and 2, respectively.
But, those values come from the technical specifications and should be the same for every iPhone 7. The values for specific phones is important for manufacturing tolerances, but not for the purpose of marketing and selling iPhones. For that, you care more about the technical specifications, which often consist of property-value pairs such as the following that apply to the iPhone 7:
1. weight is 138 g; and
2. GB of RAM is 2.
The technical specification for a product consists of several such entries, each, in turn consisting of a property and a value. You could have instances corresponding to each of these entries. Each instance would link to a property and a value, as depicted in Figure 7.4. The problem with this is that you cannot have a property as the object of a triple that has a user-created property as the predicate.
Figure 7.4: The object of a triple cannot be a property.
The workaround is similar to what we did in option 1 of Figure 7.2. There, we represented what would have been the class of iPhone 7s as an individual that corresponded to the iPhone 7 product mode. Similarly, we will not model the properties indicating RAM or weight as properties in OWL, but rather they will be individuals. It would be confusing to create a class called “Property,” so, instead, we create the class Characteristic which means the same thing. We create a class called SpecEntry to represent characteristic-value pairs and we create a class called ProductSpec to represent detailed specifications of products, mainly consisting of instances of SpecEntry. We’ll use hasPart to link the product specifications to their spec entries and hasCharacteristic to link the spec entries to their characteristics. Figure 7.5 shows the ontology and the updated triples. Figure 7.6 shows the Turtle syntax. Although this example has just three classes and two properties, the core idea illustrated has been used at more than one company, and it has gone into production.
There are many additional things to take into account in a production system. For a start, if you needed a wide variety of units, having properties like “weightInGrams” would result in a proliferation of similar properties where the unit is buried in the name of the property. In this case, you would want a richer ontology for quantities, units, and measures that could represent conversions and perhaps support dimensional analysis. Also, the specification for a given characteristic is not always a simple number. More generally it is a constraint on what the values must, may or may not be. For example:
1. it might be a range (e.g., 2–5 volts);
2. it might be a minimum (battery life) or a maximum (amperage); or
3. the values might be qualitative rather than quantitative (red, blue, green, or a scale like low, medium, and high).
Having It Both Ways
We have shown workarounds that enable you to make progress, but it’s always a choice. In the iPhone example, depending on whether you were more concerned with the phone models or the individual phones, you would represent the concept of an iPhone 7 with an instance or as a class. What if you need both?
In the case of the properties for technical specification. The solution described will work, so long as the main concern is specifications about characteristics such as weight and not the ability to represent the weight of individual things. If we want to represent specifications as we have done, but also assign weights to individual units, then we have to create a property for weight. We now have an instance and a property to model weight with no good way to connect them.
One workaround is to make use of the fact that an annotation property can have any IRI as a value. So when you would otherwise want to use an object property with a class or property as a value, use an annotation property instead. You will lose out on the ability to use OWL DL reasoners, but you can create and link the data you need as triples and access it in an application using SPARQL.
7.3 N-ARY RELATIONS
Consider the following statements, and how you might represent them.
1. The capacity for Emirates Stadium for the 2015–16 season is 60,362.
2. Stearyl alcohol is used as a surfactant in a shampoo.
3. Michael Uschold was employed at Boeing from 1997–2008.
If we were allowed to have predicates with more than two arguments, we might represent these facts this way:
1. employment (MichaelUschold, Boeing, 1997, 2008);
2. venueCapacityForSeason (Emirates, 2015-16, 60,362); and
3. materialUsageForProduct (Stearyl alcohol, surfactant, shampoo).
The problem is that OWL only allows binary relations. In the first case, there is an underlying binary relation between the employee and the employer which could easily be represented as a triple as follows. :_MichaelUschold :isEmployedBy :_Boeing. However, if we need to say that relationship held for a period of time, no single triple will work.
In the second case, you cannot just say stearyl alcohol is used as a surfactant; because it is only used that way in some products, it plays other roles in other products. You have to be careful about asserting that that stearyl alcohol is used in shampoo because many shampoos use other surfactants. In this example, we are saying how a given material is used in a given product. Again, no single triple will work.
In the third case, the capacity is not an attribute of the venue on its own, nor is it an attribute of the season. Conceptually, it is an attribute of the combination of the venue and the season. This is necessary because seats may be added or removed from season to season.
There is a standard workaround for these examples. You have to turn the n-ary relations into classes whose instances correspond to each of the above facts. This means you are turning a particular relationship into a thing, which is sometimes called “reification.”28 This is a more general case of what is called “RDF reification”29 which turns an rdf triple into a thing. We are not talking about that here.
How does it work? You create a class that has restrictions pointing to each of the n arguments. With n arguments, there will be n triples and n+1 instances (the main instance and one for each argument) (see Figure 7.7). Each rounded shape is an individual, whose class IRI is in a bold black font. Beneath that is the individual’s IRI in blue. The green rounded shapes in the Employment instance are data property assertions whose values are literals, not other individuals. They each represent a triple that is not explicitly shown as such.
The employment is a special case in which there is an underlying binary relation. That can be defined as a property chain and be inferred (hence the dotted line in figure).
Figure 7.7: Reifying n-ary relations.
Note that it is often difficult to find good natural sounding names for the properties for such instances. That is because the instances are often not natural objects, they are modeling fictions created to work around the binary relation limitation. There is no everydayword or phrase to refer to a “MaterialUsageInProduct” nor a “VenueCapacityForSeason.” In the case of employment, it is a bit more natural, people do work for companies for periods of time and we may refer to them, e.g., “my employment at Boeing.”
7.4 RULES
Recall from Section 3.1.1 that an inference rule specifies what new information can be logically concluded from a set of premises. For example for any two classes, C1 and C2, declaring that C1 is a subclass of C2 tells the inference engine to use the following inference rule when performing reasoning:
For any individual, x
So, declaring that :Lawyer rdfs:subClassOf :Person tells the inference engine to use the following rule:
We have introduced many such rules to specify the semantics of various OWL constructs, in this case, rdfs:subClassOf.
In any complex subject, whether it is healthcare, finance, or manufacturing, there is a wide variety of rules that one can think of where the conclusion logically follows from the premises. However, given the tradeoff between expressivity and inference performance, the OWL designers limited the kinds of rules that one can state. There is one very important broad category of rules that cannot be expressed in OWL DL. As an example, we will try to generalize the ideas about internal organizations and transactions considered in the previous chapter.
Requiring Two Individuals To Be Different
In Section 6.3, we defined the class FinancialTransaction to be an event with a buyer and a seller. If we want to ensure that the buyer and seller are different, we can make the properties hasSeller and hasBuyer disjoint. This is one case where we can require two individuals to be different, but as we will soon see, it is a special case.
Suppose we wanted to create a class called InternationalFinancialTransaction that required the countries that the buyer and seller were based in to be different. We start by asserting that InternationalFinancialTransaction is a subclass of the following three classes:
1. a financial transaction;
2. a buying party that is based in some country; and
3. a selling party that is based in some country.
Figure 7.8 shows what this looks like in Protégé, which is using Manchester syntax.
Figure 7.8: International financial transaction.
This is another example of a chained restriction. We saw this in when we modeled security agreements in Section 6.2. This is fine as far as it goes, but it says nothing about the countries being different from each other. It turns out that you cannot say this in OWL DL.
There are different ways to approach this. However you proceed, it is a good idea to add a comment into the definition of international financial transaction that says something like: “NOTE: OWL DL cannot express the requirement that the countries are different.” This successfully communicates to any human using the ontology how that class is expected to be used. Unfortunately, it does not allow us to infer a given financial transaction to be an international one. Nor will it be possible to catch an error if someone erroneously creates an explicit instance of an international financial transaction when both the buyer and seller are based in the same country.
The only way to accomplish these things is to extend or augment OWL with features that support a wider range of inference rules. Several such languages have been proposed, including SWRL,30 SPIN,31 and more recently SHACL,32 which is based on SPIN. It is also possible to use a SPARQL CONSTRUCT query to assert that a given individual is a member of the :InternationalFinancialTransaction class.
The details of rule languages are beyond the scope of this book. We will show how this might work using a SWRL-like syntax. SWRL has been around for a long time, and Protégé has plugin for it, so you can experiment to get some inferences to work. We use the following notation:
• C(?x) is short for the triple: ?x rdf:type C.
• p(?x,?y) is short for the triple: ?x ?p ?y.
• <=> means logically equivalent to
Thus, if you know that ?t is an international financial transaction, then you can conclude that there are buyer and seller parties based in two different countries. Conversely, if you know that there are buyer and seller parties based in two different countries, you can conclude that ?t is an international financial transaction. This works just like the owl:equivalentClass construct.
Even if this was integrated into a logic reasoner there is nothing to stop someone from putting in the same bad data. But if you asserted an individual to be an instance of :InternationalFinancialTransaction and the two countries were the same, the inference engine would find a contradiction and notify you.
Requiring Two Individuals To Be the Same
The flip side of an international financial transaction is a domestic one. That means that the buyer and seller are based in the same country. The same underlying limitation of OWL DL that prevents one from fully expressing the meaning of an international financial transaction makes it impossible to fully express the meaning of a domestic financial transaction. The SWRL-like rule above can be tweaked to cover this case by renaming the class to be DomesticFinancialTransaction and changing the differentFrom to sameAs. This would work, but it would be easier to just use a single variable for the country. This obviates the need to use sameAs. See below:
A similar situation arises if we want to capture the meaning of an internal transaction, where the buyer and seller are both from the same organization. In Section 6.3, we defined the class :InternalSemviaTransaction, and successfully inferred an individual to be one of its instances.
This worked fine, but it was from the perspective of a single organization, Semvia. Suppose we wanted to capture the general idea of an internal financial transaction. We want to say that both the buyer and seller are parts of the same organization without specifying which organization that might be. This also cannot be said in OWL DL, but as in the prior examples, we can say it in a more general rule language. For example:
How To Tell When You Need a Rule that OWL Does Not Support
If you get into modeling in a serious way, you will inevitably encounter situations like this. You might think you can do it in OWL, and spend hours trying, only to fail. You may be none the wiser about whether the limitation was in your own creativity or the expressivity of the OWL language. A good rule of thumb, as it were, is to watch for situations where coming up with an accurate English definition requires you to use words that mean “different from” or “same as,” as in the above examples. If so, chances are you cannot say it in OWL. Another good resource to use is Stack Overflow.33
There is some ambiguity in how the term “rule” is used in the context of OWL. People will often say OWL cannot do “rules.” But as we said above there are many dozens of inference rules that OWL does support. This apparent contradiction is resolved by realizing that the word is being used in two different senses, a broad sense and a narrow sense. In the narrow sense of the term, it is true that OWL does not support “rules.” What this means is that you cannot do the kinds of things we just talked about in this section—where you need to ensure sameness or differentness in certain ways in an expression to convey the meaning you want. In technical terms, you cannot use a variable to ensure co-reference as we did with ?country when defining a domestic financial transaction and with ?org when we defined an internal financial transaction.
7.5 DATES AND TIMES
In the spirit of reuse, the developers of OWL borrowed from a large set of existing XML Schema datatypes rather than inventing something new. Not everything is available in OWL, but the smaller set is more manageable.34 One case where a genuine inconvenience arises is for dates and times. Where XML gives a moderate variety of options for specifying dates and times, OWL basically gives only one: xsd:dateTime. It represents a specific date and time which is a concatenation of the date and the time plus an optional time zone offset from Universal Coordinated Time (UTC). See Table 7.2 for a few examples.35 If you are not going to use a time zone offset, then make sure it is clear from context.
Table 7.2: Examples of |
|
|
9:30am, September 29, 1977 |
|
1:30pm on March 29, 1977 UTC |
|
9:30am on Sept. 29, 1977 US Eastern Daylight Time |
Specifying a Date Only
This means that you cannot just specify a date without specifying a time. This can be very inconvenient. We describe three ways to deal with this.
1. Stay in OWL DL, and use a programmatic workaround.
2. Stay in OWL DL and use or create a custom date and time ontology.
3. Go outside of OWL DL and use xsd:date.
The first option entails living with the inconvenience, and using some convention to indicate that you only care about the date and not the time. For example, you can treat any dateTime literal whose time part is 00:00:00 to be just the date. If you needed to specify the very beginning of the day, you could use 00:00:01 to include the intended meaning of 00:00:00, which is now reserved by convention for when no time is wanted. You would have to enforce this programmatically, when you write application code or SPARQL. This is workable, and allows you to take full advantage of OWL 2 inference.
The second option is to create your own classes and properties to provide the support you need. This approach was taken by the developers of the financial industry business ontology (FIBO 36). Alternatively, you can find an existing ontology that does this for you. Be careful about importing an existing ontology; it might be overly complicated. Be equally careful about getting too involved in creating lots of features that you might not need.
The third approach is to step out of OWL DL, staying in RDF and just use xsd:date and xsd:time from XML Schema. When you use this approach, some of the OWL DL reasoners will not run. This limits your ability to check the consistency of the ontology during development and evolution.
I almost always go with the first option. The complexity of option two is rarely needed, and I like to check my ontology with an OWL DL reasoner.
Date Math
Another thing that causes problems is the inability to add a duration to a date and get another date. First, there is nothing in OWL for the idea of a duration (e.g., 1 second, 12 hours, 3 weeks). So you will need to create or borrow an existing ontology that defines a duration. This will likely take you into the general idea of units and measures.37 SPARQL 1.1 supports xsd:date + xsd:yearMonthDuration and xsd:dateTime + xsd:dayTimeDuration, and other things. It is also possible to convert dateTime literals to numeric form (e.g., as in Unix time38 which uses the number of seconds since January 1, 1970) and do the math after that.
7.6 CARDINALITY RESTRICTIONS WITH TRANSITIVE PROPERTIES OR PROPERTY CHAINS
Suppose you want to represent a subsidiary as an organization that is part of another organization. You might create the classes and properties in Figure 7.9. We create the class, Subsidiary stating that is a subclass of Organization as well as the restriction “partOf min 1 Organization.” Thus, if we know something is a subsidiary, we know it an organization that is part of another organization. But not all organizations that are part of other organizations are subsidiaries. For one, it would have to also be a legal entity.
We have seen a number of examples of cardinality restrictions. We have seen that properties can have one or more of various characteristics, such as functional, symmetric, and transitive. We reuse the transitive partOf relationship that can connect many different kinds of things. This looks just like many other examples we have seen, and you would have no reason to expect a problem. However, if you try to run a description logic inference engine on an ontology with this small ontology, you may bump up against another limitation of OWL DL.
You get different behaviors from different inference engines. The error messages are all different, and not always very helpful. At the time of this writing, the inference engine Hermit 1.3.8.413 does not complain about this particular issue—it is not clear what it is doing. Pellet is fussier. It gives an error message, which is an important clue. It says “An error occurred during reasoning…UnsupportedFeatureException” and names the property: “TransitiveObjectProperty(doe:partOf).” This tells you where the problem is but not what the problem is.
For obscure technical reasons that are well outside the scope of this book, it turns out that a transitive property may not be used with a cardinality restriction, it takes you out of OWL DL. In this case, there is a simple workaround, replace the restriction “partOf min 1 Organization” with “partOf some Organization.” Logically they mean the same thing, but the inference engines treat cardinality differently.
The min 1 case is the special case where there is an easy workaround—not so if you want a min cardinality with a number other than 1, or if you want any max or exactly cardinality.
If we use the restriction with exactly 1 instead of min 1, both Pellet and Hermit complain. Pellet gives more or less the same error message as before, naming the offending property and saying there is an unsupported feature exception.
A more readable version of what Hermit literally says is: “The non-simple property partOf or its inverse appears in the cardinality restriction “partOf max 1 Organization.” Notice that there is a max. That is because exactly 1 is just a convenient shorthand for two separate restrictions, a min 1 and a max 1.
For the purpose of building OWL ontologies, it is sufficient to know that non-simple properties typically involve transitive properties and/or property chains. If you are interested in the details, have a look at the OWL spec.39 Be warned, it is not for the faint of heart.
In summary, when creating a cardinality restriction (i.e., one that uses min, max or exactly) you should avoid using a transitive property or a property defined using a property chain.
Workarounds
The simple case, as noted above is to never use min 1, always use some. They are logically equivalent, and the reasoners work better with the former. If you want to use a cardinality restriction with n greater than 1 with a transitive property or a property chain, then you need to give something up. The situation is analogous to that for rules. We want to express true facts about the subject, but OWL will not let us. Again, the task is to decide what to give up and what to keep.
For min cardinality, the easiest thing is to just use a someValues restriction that means min 1, but to have a text annotation saying what the minimum really is. For example, an agreement between two parties has a minimum of two obligations. But if you use the transitive property, :partOf, you cannot say that. So you can use “partOf some Obligation” instead, and the text comment should indicate that there should be two obligations.
An alternative is to keep the cardinality part intact, but to make sure the property in the restriction is neither a property chain nor transitive. One way to do this is to keep the transitive property but to not use it in that restriction. Create a non-transitive version that means the same thing in the world. This solution is workable, but care must be taken to avoid confusion and mistakes due to their being two properties that mean essentially the same thing.
You might be tempted to just ignore the inference engine. That will solve one problem, but is likely to leave errors in the ontology that the inference engine would have caught. Another strategy is to use a less fussy inference engine that will catch many logical errors, but will not complain about some of the more subtle details. An alternative is to separate out the parts of the ontology that are not OWL DL compliant, and run the inference engine on the rest. That is fiddly, but can also be made to work.
In any event, the things that are true in the world that you are not expressing formally due to OWL limitations should be documented in annotations. This enables users of the ontology to know what is needed by way of added constraints or specialized application code is needed to honor the intended semantics.
Property Chains
As noted above, you cannot use a property chain with a cardinality restriction. I no longer use OWL property chains. If I need a property chain, I just use SPARQL.
7.7 INFERENCE AT SCALE
Recall from Section 3.1.1 that OWL is a subset of the more powerful first-order logic. The particular subset was chosen to hit a sweet spot between computational efficiency for inference, and representational expressiveness. However, in practice for large triple stores with data, this sweet spot is not sweet enough. Performance and scalability is limited.
From the beginning, there was a concern for inference performance. The first version of OWL was released in 2004. There were three versions: OWL Lite, OWL DL, and OWL Full with increasing expressive power and decreased inference performance. A key difference that OWL Full brought was the ability to represent true metaclasses. The most widely used original version was OWL DL.
Based on user feedback, a new version called OWL 2 was released in 2012. OWL Lite went away, OWL Full was updated, but, to my knowledge, neither version of OWL Full ever got much traction. Efficient reasoners were never developed.
Today, the term OWL DL usually refers to OWL 2 DL. OWL 2 added a variety of new features, but what they are is now just a matter of historical interest.40 What is important is the introduction of three new sub-languages of OWL 2 called profiles, each designed to meet a different need. They are: OWL 2 QL, OWL 2 EL, and OWL 2 RL.41 Each limits the expressive features available in different ways in order to improve specific kinds of reasoning.
For Large TBoxes: OWL 2 EL
Many large biomedical ontologies have large numbers of classes and properties defined using a variety of complex expressions. The need is to infer additional relationships, and there is minimal focus on instance data. The EL profile is the preferred choice for this situation. Think “E” for expressive, EL is the most expressive profile; it also rhymes with “T” for TBox.
For Large ABoxes: OWL 2 QL
If you need to run inference over large amounts of instance data, and you want to provide database applications with an ontological data access layer, OWL 2 QL is a good choice. Its expressivity has been restricted so that any query over an OWL 2 QL data set can be expressed in SQL. Think ‘Q’ for SQL.
For Rules: OWL 2 RL
If you live in a business rules context and want traditional business rule engines to run efficiently, then OWL 2 RL is a good choice. The RL profile has also become the preferred approach for reasoning with Web data. Think “R” for rules.
All of the axioms can be expressed as logical implications, which is a synonym for a broad interpretation of the term “rule.” As we discussed in Section 7.4, OWL cannot express rules at all, in the narrower interpretation of the term “rule.”
7.8 SUMMARY LEARNING
Due to the design constraints of OWL, there are certain things you cannot do. These relate to the idea of metaclasses, what you can have as an object of a triple, rules, property chains, dates, and cardinality restrictions.
Variants of OWL
There are several variants of OWL, the most widely used of which is OWL 2 DL. It limits expressivity in certain ways to improve inference behavior. Given it has been several years since version 2 of OWL was released, OWL 2 DL is usually abbreviated as OWL DL. Also, quite a lot of the time, when people say OWL, they really mean OWL 2 DL since it is the most widely used variant.
Metaclasses and Objects of Triples
You cannot use a class or property as the object of a triple with a user-created property. OWL DL does not allow you to create something that is both an individual and a class. You have to decide which. OWL 2 DL provides punning which only gives the illusion of having something be a class and an individual. This limitation is related to not allowing metaclasses. To be precise, you cannot create an individual, X and two classes C1 and C2 where: X rdf:type C1 and C1 rdf:type C2. This would make C2 a metaclass, which is a class whose members are themselves classes.
Although OWL users cannot create metaclasses, OWL itself does have metaclasses. For example, _Michael rdf:type Person and Person rdf:type owl:Class. The metaclass is owl:Class.
N-ary Relations and Reification
All variants of OWL are limited to binary relations. Every triple has a subject and an object. The need commonly arises to represent relationships that hold between more than two individuals. Reification allows you to get the effect of an n-ary relationship using binary predicates only.
Rules
Many inference rules are not expressible in OWL. Specifically, if you require two variables to be the same or different, you probably cannot say it in OWL. Although OWL has many inference rules built in, there is a narrower sense of the term “rule” that is limited to more expressive rules that OWL cannot represent.
Dates and Times
OWL does not have a datatype that allows you to specify a date without also specifying a time. Neither OWL nor SPARQL directly support adding a duration to a date and getting a new date out of the box.
Cardinality Restrictions with Transitive Properties or Property Chains
Cardinality restrictions are not allowed with transitive properties or property chains. Always use a someValues restriction instead of a min 1. When you know something is true but cannot represent it in OWL, it is good practice to indicate that in a text annotation.
This limitation will not affect your ability to load triples into a triple store, but a DL inference engine may well complain. One strategy is to use a less fussy inference engine.
Inference at Scale
OWL 2 provides three profiles to improve inference at scale, at the price of decreased expressivity. OWL 2 EL is for large TBox reasoning; OWL 2 QL is for large ABoxes and OWL 2 RL is for rules.
24 In UML, these are called “power types.”
25 https://www.w3.org/TR/owl2-new-features/#F12:_Punning.
26 https://www.w3.org/TR/swbp-classes-as-values/.
27 https://pdfs.semanticscholar.org/b93f/5ed4d27056f6a7517589b2f0c63530e1b4e0.pdf.
28 https://en.wikipedia.org/wiki/Reification_(knowledge_representation).
29 https://www.w3.org/TR/rdf-primer/#reification.
30 https://www.w3.org/Submission/SWRL/.
31 https://www.w3.org/Submission/spin-overview/.
32 https://www.w3.org/TR/shacl/.
33 https://stackoverflow.com/questions/tagged/owl.
34 See: https://www.w3.org/TR/owl2-syntax/#Datatype_Maps for details.
35 At this date and time I got on my bike and rode from Buffalo, NY to San Diego, CA.
36 https://www.edmcouncil.org/financialbusiness.
37 For a simple, yet expressive, ontology for units and measures including durations, see: https://semanticarts.com/gist.
38 https://en.wikipedia.org/wiki/Unix_time (accessed January 23, 2018).
39 https://www.w3.org/TR/owl2-syntax/#Global_Restrictions_on_Axioms_in_OWL_2_DL.
40 https://www.w3.org/TR/2012/REC-owl2-overview-20121211/#Relationship_to_OWL_1.
41 http://korrekt.org/papers/Kroetzsch_OWL_2_Profiles_Reasoning_Web_2012.pdf.