Warning:
This wiki has been archived and is now read-only.

Profile Explanations

From OWL
Jump to: navigation, search

This section is (for now) moved to Primer#OWL_Profiles.

OWL Profiles

OWL 2 has two major dialects, OWL 2 DL and OWL2 Full. Both use the entire OWL built-in vocabulary: that is, the basic concepts of the languages is very similar. Both allow you define classes using restrictions or constraint properties with property chains, and so on. Similarly, OWL DL ontologies are all syntactically legal OWL Full ontologies and the consequences under each semantics generally coincides. (Under OWL Full semantics, there may be additional entailments. Ssome ontologies may be inconsistent under OWL Full semantics while consistent under OWL DL semantics.)

Conceptually, we can think of the difference between OWL DL and OWL Full in two ways:

  • One can see OWL DL as a syntactically restricted version of OWL Full where the restrictions are designed to make life easier for implementors. In fact, since OWL Full is undecidable, OWL DL makes writing a reasoner that, in principle, can return all yes and no answers<<Yes yes, needs elaborating>> (subject to resource constraints) possible. As a consequence of its design, there are several production quality OWL DL reasoners that cover the entire language (modulo bugs in the implementation). There are no such OWL Full reasoners.
  • One can see OWL Full as the most straightforward extension of RDFS. As such, it follows the RDFS semantics and general syntactic philosophy (i.e., everything is a triple and the language is fully reflective). OWL DL, as the name suggests, is designed to be a syntactic variant of a description logic, that is, a fragment of standard first order logic. OWL Full has been used to help specify extensions to RDFS in implementations (e.g., some implementors "add a little OWL" to their RDFS systems for various applications).

Of course, OWL Full and OWL DL have been designed together and thus have influenced each other. For example, one design goal of OWL 2 was to bring OWL DL syntactically closer to OWL Full (that is, to allow more RDF Graphs/OWL Full ontologies to be legal OWL DL ontologies). This led to the incorporation of punning into OWL 2.

In addition to OWL DL and OWL Full, OWL 2 specifies three additional [Profiles] of OWL. OWL, in general, is a very expressive language (both computationally and for users) and thus can be difficult to implement well and to work with. These additional profiles are designed to be approachable subsets of OWL sufficient for a variety of applications. As with OWL DL, computational considerations are a major requirement of these profiles (and they are all much easier to implement with robust scalability given existing technology), but there are many subsets of OWL that have good computational properties. The selected OWL 2 profiles were identified as having substantial user communities already, although there were several others not included and one should expect more to emerge. The profiles document provides a clear template for specifying additional profiles.

In the following sections we discuss each profile and their design rationale, and provide some guidance for users in selecting which profile to work with. Please be aware that this discussion is not comprehensive, nor can it be. Part of any decision has to be based on available tooling and how that fits it with the rest of your system or workflow. For example, you may require that your tools are implemented in Java and that dominates any decision. So you might choose to use a profile that doesn't fit as well with your modeling problem in order to use the better Java tool. Before making a major commitment we would suggest at least consulting with [public-owl-dev@w3.org] which hosts such discussions, or consulting with an expert.

EL++

EL++ was designed with large biohealth ontologies in mind, such as SNOMED-CT, the NCI thesaurus, and Galen. Common characteristics of such ontolgoies include complex structural descriptions (e.g., defining certain body parts in terms of what parts they contain and are contained in or propagating diseases along part-subpart relations), huge numbers of classes, the heavy use of classification to manage the terminology, and the application of the resulting terminology to vast amounts of data. Thus, EL++ has a comparatively expressive class expression language and it has no restrictions on how they may be used in axioms. It also has fairly expressive property expressions, including property chains but excluding inverse.

(Sensible use of EL++ is not restricted to the bioheath domain: as with the other profiles of OWL, EL++ is domain independent. However, EL++ shines when your domain and your application require recognition of structurally complex objects. Such domains include system configuration, product inventories, and many scientific domains.)

Working with EL++ is fairly similar to working with OWL DL: one can use class expressions on both sides of a subClassStatement and even infer such relations. For many class expression oriented ontologies, EL++ makes a good approximation target, that is, by only a little simplification one can get an EL++ ontology and preserve much of the meaning of the original ontology.

EL++ is very robust computationally and reasonably easy to implement. Not only does it scale well for facts and axioms, but it scales well for complex expressions.

Two key missing features are allValuesFrom and cardinality restrictions....

Editor's Note: What else? I suppose some examples.

DL Lite

DL Lite emerged from research on database integration. Implementationally, it can be realized on top of standard relational database technology (e.g., SQL) simply by expanding queries in the light of class axioms. This means it can be tightly integrated with RDBMSs and benefit from their robust implementations and multi-user features. Furthermore, it can be implemented without having to "touch the data", so really as a translational/preprocessing layer. Expressively, it can represent key features of Entity-relationship and UML diagrams (at least those with functional restrictions). Thus, it is suitable both for representing database schemas and for integrating them via query rewriting. As a result, it can also be used directly as a high level database schema language, though users may prefer a diagram based syntax.

It also captures many commonly used features in RDFS and small extensions thereof, such as inverse properties and subproperty hierarchies. DL Lite restricts class axioms asymmetrically, that is, you can use constructs as the subclass that you cannot use as the superclass.

Editor's Note: Illustrative example here, obviously

OWL-R

The design of OWL-R stems from two related impulses:

  • It should be implementable by direct translation into standard rule systems.
  • It should capture all the OWL Fullish features of RDFS.
Editor's Note: The second is not quite right or helpful. Must ponder more...

As a consequence, OWL-R is ideal for enriching RDF data, especially when the data must be massaged by additional rules. From a modeling perspective, however, this pushes us farther away from working with class expressions: OWL-R ensures we cannot (easily) talk about unknown individuals in our superclass expressions (this restriction follows from the nature of rules). Compared with DL Lite, OWL-R works better when you have already massaged your data into RDF and are working with it as RDF.

OWL-R also has two dialects: The OWL DL dialect and the OWL Full dialect....

Editor's Note: Ran out of steam

OWL 1 Species

In OWL 1, profiles were called "species" and there were three of them, OWL Lite, OWL DL, and OWL Full. OWL DL 1 and OWL Full 1 are proper subsets of OWL DL 2 and OWL Full 2. There's no major reason to continue to distinguish them in OWL 2 as they are fairly close in extensibility and OWL 2 tools can handle OWL 1 ontologies without problems.

OWL Lite was intended to be similar to EL++, DL Lite, or OWL-R but there were several problems with its design, most notably that it was not significantly easier to implement nor more robustly scalable than OWL DL. Thus, there wasn't a huge performance (or tool) benefit to staying inside OWL Lite. OWL Lite also could express things that were in OWL DL but in very indirect ways that were very surprising. For example, while the "complementOf" construct was not part of the syntax of OWL Lite, that one class was a subclass of another could be encoded in OWL Lite.

OWL Lite is a subset of OWL DL 2 and OWL Full 2 but is no longer a recommended profile.