OWL 2: The Next Step for OWL

Transcription

1 OWL 2: The Next Step for OWL Bernardo Cuenca Grau a,ianhorrocks a,borismotik a,bijanparsia b, Peter Patel-Schneider c,ulrikesattler b a University of Oxford, Oxford, UK b University of Manchester, Manchester, UK c Bell Labs Research, New Jersey, USA Abstract Since achieving W3C recommendation status in 2004, the Web Ontology Language (OWL) has been successfully applied to many problems in computer science. Practical experience with OWL has been quite positive in general; however, it has also revealed room for improvement in several areas.wesystematicallyanalyzetheidentifiedshortcomings of OWL, such as expressivity issues, problems with its syntaxes, and deficiencies in the definition of OWL species. Furthermore, we present an overview of OWL 2 an extension to and revision of OWL that is currently being developed within the W3C OWL Working Group. Many aspects of OWL have been thoroughly reengineered in OWL 2, thus producing a robust platform for future development of the language. Key words: Ontologies, Ontology Languages, Semantic Web 1. Introduction Since the inception of the Semantic Web, the development of languages for modeling ontologies conceptualizations of a domain shared by a community of users has been seen as a key task. The initial proposals focused on RDF and RDF Schema; however, these languages were soon found to be too limited in expressive power [18]. The World Wide Web Consortium (W3C) therefore formed the Web Ontology Working Group, whose goal was to develop an expressive language suitable for application in the Semantic Web. The result of this endeavor was addresses: bernardo.cuenca.grau@comlab.ox.ac.uk (Bernardo Cuenca Grau), ian.horrocks@comlab.ox.ac.uk (Ian Horrocks), boris.motik@comlab.ox.ac.uk (Boris Motik), bparsia@cs.man.ac.uk (Bijan Parsia), pfps@research.bell-labs.com (Peter Patel-Schneider), sattler@cs.man.ac.uk (Ulrike Sattler). the OWL Web Ontology Language, which became aw3crecommendationinfebruary2004.owlis actually a family of three language variants (often called species) ofincreasingexpressivepower:owl Lite, OWL DL, and OWL Full [28]. The standardization of OWL has sparked the development and/or adaption of a number of reasoners, including FacT++ [37], Pellet [32], RACER [11], and HermiT [26], and ontology editors, including Protégé 1 and Swoop [21]. OWL ontologies are being developed in areas as diverse as e-science, medicine, biology, geography, astronomy, defense, and the automotive and aerospace industries. OWL is extensively used in the life sciences community, where it has rapidly become a de facto standard for ontology development and data interchange; for example, see BioPAX, 2 NASA s SWEET ontologies, 3 and the Preprint submitted to Elsevier 8November2008

2 National Cancer Institute Thesaurus. 4 Despite the success story surrounding OWL, the numerous contexts in which the language has been applied have revealed some deficiencies in the original design. In Section 2, we present a systematic analysis of problems identified by OWL users and the designers of OWL tools such as editors and reasoners. For example, ontology engineers developing ontologies for biomedical applications have identified significant expressivity limitations of the language. Also, the designers of OWL APIs have identified several practical limitations such as difficulties in parsing OWL ontologies or the inability to check for obvious errors, such as mistyped names. In response to users comments and requests, the idea was born to address some of these needs via an incremental revision of OWL, provisionally called OWL 1.1. The initial goal of OWL 1.1 was to exploit recent developments in DL research in order to address some of the expressivity limitations of the language. After extensive discussions at the 2005 OWL Experiences and Directions Workshop, 5 a consensus was reached regarding the new features to be provided by OWL 1.1. This set of new features roughly corresponds to the intersection of what users wanted, what theoreticians said was possible, and what implementors believed was practicable. As the design of OWL 1.1 progressed, it was decided to also take the opportunity to clean up the language and its specification, so as to provide amorerobustplatformforfuturedevelopment. The development of OWL 1.1 was initially undertaken by an informal group of language users and developers. After the original specification reached amaturestateandfirstimplementationswerereleased, the OWL 1.1 proposal was submitted to the W3C as a Member Submission 6 with the intention of using it as a starting point for a new W3C Working Group. The Working Group was officially formed in September As the work on the new language progressed, the initial Member Submission evolved significantly. Consequently, the Working Group eventually decided in April 2008 to call the new language OWL 2 and so indicate a substantial step in the evolution of the language. In Section 3, we present the design of OWL 2 and discuss how it addresses the drawbacks of OWL 1 that we identified in Section 2. We discuss differ ent aspects of the language, such as its expressivity, syntax, specification style, and various metalogical features. In Section 4 we discuss the current state of implementation, and conclude in Section 5 with adiscussionofpossiblefutureextensions.toavoid any ambiguity, we refer to the initial version of OWL as OWL 1 in the rest of this paper. 2. Why Go Beyond OWL 1? Although, or even perhaps because, OWL 1 has been successful, certain problems have been identified in its design. None of these problems are severe, but, taken together, they indicate a need for a revision of OWL 1. In this section, we discuss what these problems are Expressivity Limitations Practical experience with OWL 1 has shown that OWL 1 DL the most expressive but still decidable language of the OWL 1 family lacks several constructs that are often necessary for modeling complex domains [31,30]. As a response, the community of OWL 1 users and application designers developed various patterns for approximating the missing constructs. 7 Since the actual expressive power is missing, these workarounds are often unsound or incomplete with respect to the intended semantics. Furthermore, it is usually difficult, if not impossible, to identify all the cases in which these patterns yield incorrect results. Such patterns are therefore not only cumbersome but also of limited utility, and extending the language with the missing constructs seems to be the only satisfactory solution to the problem Qualified Cardinality Restrictions The existential restrictions of OWL 1 DL allow the restriction to be qualified with a class; for example, one can define a class such as persons that have at least one child who is male. Cardinality restrictions, however, cannot be qualified with a class; thus, OWL 1 DL allows for the definition of a person with at least three children, but not of a person with at least three children who are male. Expressing the latter class requires the restriction to be qualified with respect to the class (i.e., male) to which the objects being counted (i.e., children) belong. This 7 2

3 feature is typically called a qualified cardinality restriction (QCR). Ontology modelers have repeatedly identified the importance of QCRs in various modeling problems. For example, one may want to define a quadruped as an animal with exactly four parts that are legs, or a medical oversight committee as a committee that consists of at least five members, of which two are medically qualified, one is a manager, and two are members of the public [30]. In OWL 1, qualified cardinality restrictions are commonly approximated using design patterns discussed in [30,40]; however, these workarounds are often unsound, or incomplete, or both. At the time the Web Ontology Working Group was designing OWL 1, it was already known that QCRs can be added to the language without affecting its computational properties, both from a theoretical and from an implementation point of view; in fact, QCRs were included in DAML+OIL a language that served as the basis for OWL 1 [18]. The final decision was, however, not to include this particular feature in the language due to concerns about user understandability Relational Expressivity While OWL 1 provides a wide range of constructors for building complex classes, relatively little can be said about properties. Ontology modelers have repeatedly asked for greater relational expressivity (i.e., expressivity about properties), and the lack of this expressivity has been identified as a major impediment for the adoption of OWL 1. We will illustrate this point with two prominent use cases. Propagation along properties. Applications commonly need to model interactions that are sometimes described as one property propagating or being transitive across another. Use cases abound in the life sciences domain, where one often needs to describe interactions between locative properties and various kinds of part-whole properties [29]. For example, we might want to assert that an abnormality of a part of an anatomical structure constitutes an abnormality of the structure as a whole [29]. This allows us to draw many useful inferences, such as inferring that a fracture of the neck of the femur is a kind of fracture of the femur, or that an ulcer located in the gastric mucosa is a kind of stomach ulcer. Languages specifically designed for use in life sciences such as OBO 8 and SNOMED 9 commonly provide for such features, even though they typically support a much smaller set of class constructors than OWL 1. Thus, supporting transitive propagation of roles in OWL seemed vital if OWL were to gain widespread acceptance in the life sciences. Properties of properties. In mereology the philosophic study of parts and wholes the partof relation is often specified to be transitive (if x is a part of y and y is a part of z,thenx is a part of z), reflexive (every object is a part of itself), and asymmetric (nothing is a part of one of its parts). Many applications that describe complex structures (such as life science and engineering applications) extensively use part-whole relations axiomatized according to these principles. Other types of properties with different axiomatizations are often found in practice (see, e.g., the OBO Relations Ontology 10 ), such as locative relations (typically transitive and reflexive), causal relations (typically transitive and irreflexive), and membership relations (typically irreflexive). At the time OWL 1 DL became a W3C recommendation, it was not known whether the language could be augmented with such features (apart from transitivity) without giving up the decidability of key inference problems, much less whether it would be possible to develop practical reasoning procedures for such extensions. Consequently, such features were excluded from OWL 1. As in the case of QCRs, users have developed modeling patterns intended to approximate the missing features, which has often lead to problems in practice Datatype Expressivity OWL 1 provides very limited expressive power for describing classes whose instances are related to concrete values such as integers and strings. In OWL 1, it is possible to express restrictions on datatype properties qualified by a unary datatype. For example, one could state that every British citizen must have a passport number which is an xsd:string, where the latter is an XML Schema datatype a unary predicate interpreted as the set of all string values. In OWL 1, however, it is not possible to represent the following kinds of statements:

4 restrictions to a subset of datatype values (e.g., a gale is a wind whose speed is in the range from 34 to 40 knots); relationships between values of data properties on one object (e.g., a square table is a table whose breadth equals its depth); relationships between values of data properties on different objects (e.g., people who are older than their boss); or aggregation functions (e.g., the duration of a process is the sum of the durations of its subprocesses). Another important limitation of the datatype support in OWL 1 is the lack of a suitable set of built-in datatypes. OWL 1 relies on XML Schema 11 for the list of built-in datatypes. The design of OWL 1, however, did not involve a thorough analysis of which XML Schema datatypes were appropriate for OWL 1. OWL 1 only requires the implementation of xsd:string and xsd:integer, andleavestheimplementation of other XML Schema datatypes as optional. A subsequent analysis has revealed that datatypes in XML Schema and OWL 1 are used in different ways, so not all datatypes of one formalism are appropriate for the other and vise versa. In particular, many XML Schema datatypes can be difficult to implement in OWL 2. The datatypes xsd:double and xsd:float are finite and are thus equivalent to very large disjunctions, which can be a significant source of inefficiency. Furthermore, datatypes that represent time intervals, such as xsd:gday and xsd:time, requiretherepresentation of infinite sets of irregular intervals; currently, it is not clear whether and how such datatypes should be implemented in practice Keys OWL 1 DL does not provide means for expressing key constraints on data properties, which are a core feature of database technologies. For example, in OWL 1 DL it is not possible to state that US citizens are uniquely identified by their social security number. Such statements can be expressed in OWL 1 Full by means of inverse-functional data properties; however, since no implementations of OWL 1 Full are available (see Section 2.7), there was no practical reasoning support for such statements. Furthermore, no variant of OWL 1 supports compound key constraints on either data or object 11 properties, such as that each address is uniquely identified by its street, street number, postcode, and country. The lack of keys in OWL 1 has been recognized as an important limitation in expressive power. Unfortunately, adding keys in its full generality to OWL 1wouldharmthecomputationalpropertiesofthe language and could even lead to undecidability[23] Syntax Issues OWL 1 comes with two normative syntaxes: the Abstract Syntax 12 and OWL 1 RDF. 13 The standard also defines an XML syntax, but this syntax is not normative and it has not been widely used, so we do not discuss it here. The Abstract Syntax serves as the actual definition of the language, and it has often been used as basis for the design of OWL 1 APIs. Certain design choices taken in OWL 1AbstractSyntax,however,havemadethesyntax confusing for developers, which resulted in the suboptimal design of OWL APIs. Furthermore, both syntaxes have proved difficult to parse correctly. Finally, the relationship between the two syntaxes is rather complex, which causes problems when transforming an ontology from one syntax into the other. We next discuss these problems in more detail Frame-Based Paradigm The design of the OWL 1 Abstract Syntax has been heavily influenced by the tradition of frame-based ontology languages. The frame-based paradigm was already familiar to many users, and has proved natural and popular. Consider the OWL 1DLaxiom(1),whichdeclaresaclassTiger and states that it is a subclass of the class Cat: Class(Tiger partial Cat) (1) In a frame-based system, this axiom is usually interpreted as a frame specification for the class Tiger, which typically acts as a declaration a statement that a class exists in an ontology and groups all relevant properties of the class in one place. Although the frame-based paradigm is sometimes useful for modeling, the logical underpinning of OWL 1 is actually provided by the somewhat different paradigm of description logics (DLs). The fundamental modeling concept in DLs is not a frame, but an axiom a logical statement about

5 the relationships between properties and/or classes in the domain. The following is a subclass axiom that defines an additional property of tigers: SubClassOf(Tiger Predator) (2) The relationship between frames and axioms in the Abstract Syntax has been a major source of confusion. For example, in a frame-based system, one would expect each class or property to be defined using at most one frame; furthermore, such a system would naturally support an operation such as get all explicitly told superclasses of a class C that would extract the set of superclasses of C from the frame of C. SinceOWL1mimicstheframe-based paradigm, it should support such an operation; however, since it provides for both frames and axioms, the meaning of such an operation is not clear. For example, given the axioms (1) (2), according to the frame-based paradigm alone, the result should be only Cat, sinceonlythisclassappearsintheframe of Tiger.TheclassPredator, however,isalsoatold superclass of Tiger; theonlydifferenceisthatthis relationship has not been defined in the frame for Tiger. Thus,accordingtotheaxiomparadigm,the intuitively correct answer is Cat and Predator. These problems have affected the design of OWL 1APIs.Forexample,thewell-knownManchester OWL API 14 initially tried to faithfully reflect both paradigms. Given axioms (1) (2), it would return Cat as the only superclass of Tiger, whiletherelationship between Tiger and Predator is made accessible separately as an axiom. This turned out to be confusing for API users since, from the logical point of view, both (1) and (2) just specify an inclusion relationship between two classes Alignment with DL Constructs Even though OWL 1 is based on DLs, the constructs of the OWL 1 Abstract Syntax do not completely correspond to the constructs of DLs. Consider the following class definition: restriction(hasparent somevaluesfrom(person) allvaluesfrom(person)) (3) Most DLs allow only one class to appear in a property restriction. For example, all DL implementations known to us translate definitions of the form (3) into the following form: 14 intersectionof( restriction(hasparent somevaluesfrom(person)) restriction(hasparent allvaluesfrom(person))) (4) This caused confusion with developers of OWL 1 APIs who, whenever such differences arose, chose to follow the DL structure. Thus, reading and saving an ontology can actually change the structure of the axioms due to mismatches between the API representation and the actual language Determining the Types of Ontology Entities Neither the Abstract Syntax nor OWL 1 RDF is fully context-free that is, an axiom containing a URI often does not contain sufficient information to disambiguate the type of ontologyentity (i.e., a class, aproperty,oranindividual)thattheurirefersto. Consider the following OWL 1 class definition: Class(Person partial restriction(hasmother somevaluesfrom(woman)) (5) From this axiom alone, it is not clear whether hasmother is a data property and Woman is a datatype, or whether hasmother is an object property and Woman is a class. To disambiguate the syntax, OWL 1 DL relies on a strict separation of the vocabulary into individuals, classes, and data and object properties. The specification of OWL 1DL,however,doesnotpreciselyspecifyhowto enforce this separation at the syntactic level. Thus, whereas the semantics of OWL 1 DL requires strict typing of all names, the syntax does not enforce it, which can prevent certain ontologies from being interpreted. For example, an ontology containing only the axiom (5) seems to be a valid OWL 1 DL ontology; however, the axioms in it are not sufficient to disambiguate the types of the symbols hasmother and Woman, sotheontologycannotbe correctly interpreted. The typing problem is further exacerbated by the fact that the types of ontology entities can be defined in imported ontologies, and the specification of OWL 1 DL provides no guidance on how to disambiguate the types in such cases and how to resolve potential conflicts. OWL 1 tools have dealt with this problem in ad hoc ways, which has adversely affected interoperability. This problem is made even more complex by the fact that names for ontology entities can be introduced without any prior announcement. This makes detecting trivial syntactic problems difficult, such as 5

6 typographical errors in entity names. Consider, for example, the following two axioms: DisjointClasses(Animal Plant) (6) SubClassOf(Human Animla) (7) In axiom (7), instead of Animal,theuserhasinadvertently typed Animla, whicheffectivelyintroduces a new class. Such errors are quite difficult to detect in OWL 1: since there is no explicit statement that an entity exists, axioms (6) and (7) constitute avalidowl1ontology Problems with OWL 1 RDF The vast majority of OWL 1 ontologies have been written in the OWL 1 RDF syntax; this syntax has, however, shown itself to be quite difficult to use in practice [5]. The main difficulty is that RDF represents everything using triples, which specify relationships between pairs of objects. In contrast, many OWL 1 constructs cannot be represented using triples without the introduction of new objects. For example, to represent in OWL 1 RDF that class A is the union of B and C, thefollowingcollection of triples is required, in which the union operator is represented by a blank node :x1 thatencodesalist of objects: A, owl:unionof, :x1 (8) :x1, rdf :first,b (9) :x1, rdf :rest, :x2 (10) :x2, rdf :first,c (11) :x2, rdf :rest, rdf :nil (12) This makes OWL 1 RDF ontologies difficult to read and process. Another problem with OWL 1 RDF is that the triples corresponding to a single OWL 1 construct need not be grouped together, and may even be split across multiple documents. This further exacerbates the typing problems discussed in Section In order to deal with this situation, all OWL 1 RDF parsers known to us first load all RDF triples into memory, analyze them, and then produce appropriate OWL 1 axioms. This is clearly inefficient, and it limits the scalability of OWL 1 systems. Moreover, the OWL 1 RDF and OWL 1 Abstract Syntax do not correspond completely. For example, the axioms Class(Human partial Animal) (13) SubClassOf(Human Animal) (14) are both equivalent to the following RDF triple: Human, rdfs:subclassof, Animal (15) The OWL 1 specification provides only a mapping from the Abstract Syntax into OWL RDF, but not the converse. As a result, according to the OWL 1 specification, an RDF graph G is an OWL 1 DL ontology if there exists an ontology O in Abstract Syntax such that the result of the normative transformation of O into triples is precisely G. Thismakes checking whether G is an OWL 1 DL ontology very hard in practice: one essentially needs to examine all relevant ontologies O in abstract syntax and check whether the normative transformation of O into RDF yields precisely G. This is clearly inefficient, so different OWL 1 tools have applied different ad hoc optimizations, which is a significant source of incompatibility between tools Metamodeling In many practical cases, the distinction between classes and individuals is not clear-cut. Consider the statements that Harry is an Eagle and Eagles are an endangered species. The first statement can be modeled in OWL 1 by asserting the individual Harry to be an instance of the class Eagle. Thesecond statement, however, talks about eagles as a species, and not as a set of all living eagles; therefore, it should be modeled by stating the individual Eagle to be an instance of the class EndangeredSpecies. Hence, Eagle plays the role of a class in one and of an individual in another context. This style of modeling is often called metamodeling. The W3C OWL Working Group acknowledged the importance of metamodeling in practice; however, at the time OWL 1 was designed, metamodeling had not been widely considered in DL research. Furthermore, as we discussed in Section 2.2.3, the sets of names used for classes, properties, and individuals must be disjoint in OWL 1 Lite and OWL 1 DL ontologies. Therefore, metamodeling is possible only in the OWL 1 Full species of OWL 1. This is problematical, as OWL 1 Full has not been widely implemented. Moreover, in [24] it was shown that the style of metamodeling used in OWL 1 Full leads to the undecidability of standard reasoning problems, making it unlikely that this style of metamodeling will be made available in OWL 1 tools. Users are therefore forced to choose between metamodeling, which may be needed in their application, and tool support for ontology development. 6

7 2.4. Imports and Versioning OWL 1 provides a basic mechanism that allows an ontology O to import another ontology O,and thus gain access to all entities and axioms in O.This can be understood as a form of virtual inclusion: semantically, every model of O must also satisfy all axioms of O ;however,thetwoontologiesarekept physically separate. Imports in OWL 1 DL are by name and location : the ontology O is required to contain a URI pointing to the location of O,and this location should match with the name of O. The coupling of names and locations seems appropriate when ontologies are published at a fixed location on the Web. Applications, however, often use OWL 1 ontologies off-line, by loading them from local ontology repositories. Ontologies are also often moved between locations. Thus, in many realistic use cases, the location of an ontology does not correspond with its name. Tools have dealt with this in various ways. Some tools have stayed true to the official OWL 1 specification, thus requiring users to manually adjust the names of ontologies and the import relations between them when ontologies are moved around. This approach is often cumbersome, particularly when an ontology depends on a large number of other ontologies; therefore, many tools have sacrificed compatibility with the official specification and have provided ad hoc caching and location redirection mechanisms. These problems become even more acute when one needs to maintain several different versions of the same ontology. The specification of OWL 1 provides no guidelines on how to handle such cases Annotations OWL 1 ontologies and entities can be assigned annotations, which are pieces of extra-logical information describing the ontology or entity. Annotations in OWL 1 are written using annotation properties. OWL1providesseveralbuilt-inannotation properties, some of which are inherited from RDF: owl:versioninfo, rdfs:label, rdfs:comment, rdfs:seealso, andrdfs:isdefinedby. Ontologyengineers can also create their own annotation properties and use them in their ontologies. OWL 1 Full does not put any constraints on the usage of annotation properties in an ontology. OWL 1 DL, however, disallows the usage of annotation properties in OWL 1 DL axioms; for example, it is not possible in OWL 1 DL to define a subproperty or to place a domain or a range constraint on an annotation property. To harmonize their treatment between OWL 1 DL and RDF, annotation properties are given semantics as binary relations in the interpretation domain. In this sense, annotation properties are treated semantically in a very similar way to object properties. Because they cannot be used in axioms, users typically expect annotations to be extra-logical constructs: adding or removing annotations should not affect the set of consequences derivable from an ontology. Therefore, providing an explicit semantics to annotations in OWL 1 DL is rather counterintuitive, as it makes annotation properties look like poor man s properties. All OWL 1 DL tools we know of simply ignore the formal semantics of annotations and thus are not strictly compliant with the official specification of OWL 1 DL. Access to annotations is typically provided in such tools through nonlogical methods such as various API extensions. In addition to this basic issue, the annotation system of OWL 1 has been found to be inadequate for many applications. In particular, OWL 1 does not allow axioms to be annotated, which can be necessary, for example, to represent provenance information (e.g., who wrote a particular axiom) or for language extensions (e.g., to represent the confidence in the validity of axioms). Finally, users of OWL 1 DL have often complained about the inability to define domains and ranges of annotation properties, or to use annotation properties in property hierarchies (e.g., to say that the range of the proteinid annotation property is string) OWL Semantics OWL 1 DL was designed, on the one hand, as a notational variant of the expressive description logic SHOIN(D) [17];ontheotherhand,itwasvery important for OWL 1 to be compatible with existing Semantic Web languages such as RDF. Semantic differences between SHOIN(D) and RDF made it difficult to satisfy both requirements. The solution to this problem chosen by the OWL Working Group was to provide two coexisting semantics for OWL 1. The first is a direct model-theoretic semantics based on the semantics of SHOIN(D), and is the normative semantics for OWL 1 Lite and OWL 1 DL. The second is an extension of the RDF model theory [12], and is applicable to OWL 1 ontologies writ- 7

8 ten in RDF. The practical experience with OWL 1 has identified a number of problems in each of these semantics alone, as well as in the difficult marriage between the two semantics OWL 1 DL Semantics The description logic SHOIN(D) hasbeenextensively investigated in the literature, and its expressivity and computational properties are wellknown [36,19]. The OWL 1 DL specification provides an explicit (and quite complex) definition of the semantics, which does not straightforwardly correspond to SHOIN(D). This caused a number of problems regarding presentation and understandability. Tool implementors are thus unnecessarily burdened with the effort of establishing a correspondence between OWL 1 DL and SHOIN(D) inorder to reuse known reasoning algorithms. Asourceofconfusionistheabilitytouseunnamed individuals in OWL 1 facts (this feature was inspired by RDF blank nodes). For example, one can assert an individual John to be a friendof a friendof an individual Paul without naming the intervening individual. Unnamed individuals are not directly available in SHOIN(D), and it is not obvious how to simulate them. Another source of confusion is due to the framebased constructs of OWL 1 (see Section for an in-depth discussion). SHOIN(D) is purely axiombased and it provides no frame-like features. The frame-like axioms of OWL 1 DL thus need to be translated into SHOIN(D) for the purpose of reasoning, which is unnecessarily complex RDF-Compatible Semantics OWL 1 ontologies written as RDF graphs can be interpreted using an extension of the RDF semantics. This semantics, however, has proved to be extremely complex to understand, use, and implement. First, the RDF-compatible semantics of OWL 1 is not a standard first-order semantics; rather, it is fully reified: classes and properties are assigned extensions indirectly, by first mapping them into elements of the domain of discourse and then assigning an extension to the domain elements. This adds an additional level of complexity in understanding the logical consequences of an ontology. Second, the RDF-compatible semantics of OWL 1includesso-calledcomprehension principles that enforce the existence of an individual in the interpretation domain for each class and property that can be formed using the vocabulary of the ontology. For example, if A and P are a class and a property, respectively, and I is an RDF interpretation, then I must contain domain elements o A and o P for A and P themselves, as well as for all the infinitely many classes that can be built from A and P,such as o P.A, o P P.A,andsoon.Asaconsequence,the domain of every OWL 1 Full interpretation must be infinite. Furthermore, the comprehension principles make it difficult to verify whether the RDFcompatible semantics of OWL 1 contains a built-in contradiction; that is, it may even be the case that even an empty RDF graph is inconsistent under the RDF-compatible semantics. Third, even if the semantics were consistent, the implementation of a complete reasoner would still be infeasible, as checking satisfiability of RDF graphs interpreted under the RDF-compatible semantics of OWL 1 is undecidable due to the mixing of logical and metalogical symbols [24]. Fourth, the RDF-compatible semantics of OWL 1isnotrobustunderlanguageextensions:ifOWL 1wereextendedtocoveralloffirst-orderlogic,the RDF-compatible semantics would become inconsistent due to logical paradoxes [27] Relating the DL and the RDF Semantics AkeyideabehindthetwosemanticsofOWL1 was that they should be equivalent on OWL 1 DL and OWL 1 Lite ontologies. This requirement, however, has been found difficult to realize, so it was subsequently weakened. The OWL 1 DL specification contains a proof that, for any two OWL 1 DL ontologies O and O written in OWL 1 Abstract Syntax, if O entails O,thenthetranslationofO into RDF entails the translation of O into RDF as governed by the (extended) RDF semantics. Furthermore, maintaining this compatibility becomes increasingly problematical with increasing expressive power. It has been shown that it would be impossible to maintain compatibility with the OWL 1 RDF semantics if OWL 1 were extended to the expressive power of first-order logic [27]. The coexistence of the two semantics is therefore clearly a dangerous choice with respect to the possible extension of OWL 1 DL: even if these extensions would be decidable under either semantics, the two semantics might no longer be equivalent. 8

9 2.7. OWL 1 Full OWL 1 Full is the most expressive variant of OWL 1. Each RDF graph is a syntactically valid OWL 1 Full ontology; that is, in contrast to OWL 1 DL, in OWL 1 Full there are no syntactic restrictions on the usage of the built-in OWL 1 vocabulary and the vocabulary elements defined in the ontology. The semantics of OWL 1 Full is given by the RDFcompatible semantics of OWL 1. As discussed in the previous section, the basic reasoning problems for the RDF-compatible semantics are undecidable. Furthermore, the free usage of vocabulary adds an additional source of undecidability; for example, OWL 1 Full does not enforce the well-known restrictions needed for decidability, such as using only simple roles in number restrictions [20]. To the best of our knowledge, no complete implementation of OWL 1 Full currently exists, and it is not clear whether OWL 1 Full can be implemented in practice OWL 1 Lite Although it is decidable, reasoning in OWL 1 DL is of a high worst-case computational complexity (NExpTime-complete [36]). Therefore, the OWL Working Group considered it important to define a fragment of OWL 1 DL with more tractable inference problems and that was easier to understand and use. To this purpose, the W3C OWL Working Group defined the OWL 1 Lite subset of OWL 1 DL. OWL 1 Lite is a syntactic subset of OWL 1 DL that excludes constructors that some thought to be difficult to use and/or lead to high computational complexity. In particular, OWL 1 Lite does not allow the use of union and complement constructors in class descriptions, it limits descriptions in the scope of a quantifier to be class names, it disallows the oneof constructor (i.e., nominals), and it limits the numbers in cardinality restriction to 0 and 1 only. Unfortunately, even though OWL 1 Lite seems to be much simpler than OWL 1 DL, most of the complexity of OWL 1 DL can be captured due to implicit negations in axioms. For example, the following two OWL 1 Lite axioms implicitly define the class C as the negation of D: Class(C complete restriction(p allvaluesfrom(owl:nothing))) (16) Class(D complete restriction(p somevaluesfrom(owl:thing))) (17) In fact, of all the OWL 1 DL constructors, only nominals and cardinality restrictions with cardinality larger than one cannot be captured in OWL 1 Lite, thus making the language equivalent to the description logic SHIF(D). Hence, from a users perspective, OWL 1 Lite is confusing since the available modeling constructs do not correspond to the expressivity of the language. Moreover, from a computational perspective, basic reasoning problems are only slightly less complex for OWL 1 Lite than for OWL 1 DL (ExpTime- insteadofnexp- Time-complete), so the language remains highly intractable Species Validation Species validation is the problem of determining whether an OWL 1 ontology is in OWL 1 Lite, OWL 1DL,orOWL1Full.Thisseeminglytrivialtask turned out to be rather problematic in OWL OWL 1 Lite or OWL 1 DL? The OWL 1 specification defines OWL 1 Lite in terms of a fragment of the OWL 1 DL Abstract Syntax: an OWL 1 DL ontology O in Abstract Syntax is also an OWL 1 Lite ontology if and only if it can be generated using the OWL 1 Lite grammar, as given in the normative documents. In the case of ontologies written in OWL 1 RDF, the lack of a direct mapping between OWL 1 RDF and Abstract Syntax makes species validation problematic. If O is given in the OWL 1 RDF syntax, then it is an OWL 1 Lite ontology if and only if there exists an ontology O in the OWL 1 Lite fragment of the Abstract Syntax such that the translation of O into triples is precisely O. Similarly,anontology O in the OWL 1 RDF syntax is an OWL 1 DL ontology if and only if there exists an ontology O in the Abstract Syntax such that the translation of O into triples is precisely O. Therefore, determining whether an ontology in RDF is an OWL 1 Lite or an OWL 1 DL ontology becomes very hard in practice since it involves guessing ontologies in Abstract Syntax and checking whether their normative transformation into RDF yields precisely the original ontology. In practice, validating parsers are usually based on 9

10 informal guidelines [4] that are not an official part of the OWL 1 specification. Moreover, as we already discussed, the expressive power of OWL 1 Lite corresponds to the description logic SHIF(D). Now consider an ontology O that, for example, uses the unionof construct, but actually corresponds to SHIF(D). Technically, O is an OWL 1 DL ontology; however, an OWL 1 Lite ontology O exists that is equivalent to O. Anyreasoner for O could handle O without any problems (the complexity of the reasoner is defined by the actual DL fragment). Thus, the distinction between O and O seems quite artificial, and classifying O as being harder than O is not intuitive Species Validation and Imports Suppose that O 1 is an OWL 1 ontology that imports another OWL 1 ontology O 2 ;logically,wethus get a new ontology O = O 1 O 2.Weidentifytwo basic requirements concerning the robustness of the imports mechanisms regarding species validation. First, membership in a certain species of OWL 1 should ideally be preserved under imports; for example, if O 1 and O 2 are in OWL 1 DL, then it is intuitive to expect O to be in OWL 1 DL as well. Second, if O 1 and O 2 are written in different species, one would expect O to be in the most expressive one; for example, if O 1 is in OWL 1 Lite and O 2 is in OWL 1 DL, we would expect O to be in OWL 1 DL. Unfortunately, imports can interact with OWL 1 species in a quite unpredictable and unintuitive way. As a result, none of these requirements are satisfied. As an example of a violation of these requirements, suppose that O 1 is an OWL 1 DL ontology that defines a property P as transitive. Assume also that the ontology O 2 is an OWL 1 DL ontology that uses P in a cardinality restriction, but it does not define P as transitive. The ontology O is no longer in OWL 1 DL since P is not a simple property (due to transitivity) and it is used in a cardinality restriction. Therefore, O is an OWL 1 Full ontology. Furthermore, the following example demonstrates asurprisingfact:o 1 and O 2 can be in OWL 1 Full, while O is in OWL 1 Lite. Suppose that O 1 contains just the following triples: A, rdfs:subclassof, B (18) A, rdf :type, owl:class (19) Furthermore, O 2 contains just the following triples: B,rdfs:subClassOf,A (20) B,rdf :type, owl:class (21) The ontology O 1 is in OWL 1 Full because it does not contain the triple (21) specifying the type of B; similarly, O 2 is is OWL 1 Full because it misses the triple (19). The union of these ontologies, however, contains all necessary triples, so it is in OWL 1 Lite. 3. The Design of OWL 2 To address the problems with OWL 1 that we identified in Section 2, the design of OWL 2 has departed from that of OWL1 in several ways Increasing Language Expressivity The drawbacks of OWL 1 regarding expressivity identified in Section 2.1 have long been recognized in the DL community, and a significant amount of research has been devoted to finding possible solutions. The cumulative results of this work are embodied in the DL SROIQ [16], which is strictly more expressive than SHOIN.This is evidenced by an increase in the computational complexity of the basic reasoning problems: reasoning in SROIQ is 2NExpTime-complete [22], whereas in SHOIN it is NExpTime-complete [36]. Although reasoning in SROIQ is harder than in SHOIN, thetableaux-basedreasoningalgorithm for SROIQ [16] follows the same principles as the one for SHOIN. Ifthenewfeaturesarenotused, then the new reasoning algorithm behaves just like the old algorithm for SHOIN. Furthermore,the source of added complexity is well understood [22], and it seems realistic to expect that the complexity increase will not occur on typical practical problems. Finally, existing reasoners can and have been easily extended to SROIQ. Thus,SROIQ seems to provide a good logical underpinning for OWL 2 from both a theoretical and a practical perspective Qualified Number Restrictions Even while OWL 1 was being designed, it was known that QCRs could have been added to the language without any theoretical or practical problems: the resulting logics are still decidable and have been successfully implemented in practical reasoning systems. Moreover, as mentioned in Section 2.1.1, QCRs have been supported in DAML+OIL a predecessor of OWL. Thus, qualified number restrictions are not really a novel feature of either 10

11 SROIQ or of DL-based ontology languages, and were incorporated into OWL 2 in the obvious way Relational Expressivity As mentioned in Section 2.1, a major drawback of OWL 1 is the limited expressivity regarding properties. This is addressed in SROIQ and OWL 2 by the addition of complex property inclusion axioms, which significantly increase the relational expressivity of the language. In particular, they provide for the propagation of one property along another. For example, axiom (22) states that, if a contains b and b has a part c, thena also contains c: SubPropertyOf( PropertyChain(contains haspart ) contains) (22) If such axioms are used in an unrestricted way, they easily make the logic undecidable. To achieve decidability, SROIQ (and hence OWL 2) imposes a regularity restriction on such axioms: roughly speaking, it must be possible to arrange all properties in atotalordering such that, for each property p on the left-hand side of a subproperty axiom, p is either equal to or a -predecessor of the property on the right-hand side of the axiom. Although this might seem rather complex, it merely formalizes a simple restriction that complex subproperty axioms should not define properties in a cyclic way. For example, although (22) by itself does not cause problems, it should not be simultaneously used with the following axiom, which states that if b is a part of a and b contains c, thenc is also a part of a: SubPropertyOf( PropertyChain(hasPart contains) haspart) (23) The axioms (22) and (23) together introduce a cyclic dependency between contains and haspart, which can easily lead to problems with decidability. In addition to complex property inclusion axioms, properties in SROIQ and OWL 2 can be transitive, reflexive, irreflexive, symmetric, and/or asymmetric, and pairs of properties can be made disjoint. Thus, OWL 2 provides many of the features necessary for applying the principles of mereology Increasing Datatype Expressivity OWL 2 significantly extends the set of built-in datatypes of OWL 1 by reusing certain datatypes from XML Schema. Thus, OWL 2 now supports owl:boolean, owl:string, xsd:integer, xsd:datetime, xsd:hexbinary, andanumberofdatatypesderived from these by placing various restrictions on them. In addition, xsd:decimal, xsd:double, andxsd:float will most likely be complemented with owl:real a datatype interpreted as the set of all real numbers. OWL 2 also provides a datatype restriction construct, which allows new datatypes to be defined by restricting the built-in datatypes in various ways. For example, the following expression defines a new datatype by specifying a lower bound of 18 on the XML Schema datatype xsd:integer: DatatypeRestriction(xsd:integer xsd:mininclusive 18) (24) It is worth mentioning, however, that the Working Group has still not made a final decision on the exact set of datatypes that the language will support. Therefore, some of the information in this section may become obsolete in the future Keys As mentioned in Section 2.1.4, keys are important in many applications. Extending DL-based languages such as OWL 2 with keys, however, poses both theoretical and practical problems [23]. Therefore, the Working Group has decided to include a more restricted variant of keys that can be useful in practice as well as relatively easy to implement, commonly known as easy keys. OWL 2 thus provides for key axioms of the form HasKey(CP 1...P n ), which state that the object or data properties P i are keys for (named) instances of the class C that is, no two (named) instances of C can coincide on the values of all P i. For example, the following OWL 2 axiom states that persons are uniquely identified by their social security number: HasKey( Person hasssn ) (25) The following assertions state that two individuals PSmith and PeterSmith have the same social security number: PropertyAssertion(PSmith hasssn ) PropertyAssertion(PeterSmith hasssn ) (26) (27) Since the individuals PSmith and PeterSmith are known by name, axioms (25) (27) entail that PSmith and PeterSmith are the same individuals: SameIndividual(PSmith PeterSmith) (28) 11

12 Unlike the general keys, easy keys are not applied to individuals not known by name. For example, the following axiom states that Jane is connected through marriedto to an individual α that is an instance of Man and that has as the value of hasssn : ClassAssertion( SomeValuesFrom(marriedTo IntersectionOf( Man HasValue(hasSSN ) ) ) Jane ) (29) Even though α has the same value for hasssn as, say, PSmith, individualα is not known by name. Therefore, the key axiom (25) is not applicable to α so, consequently, axioms (25), (26), and (29) do not entail the following assertion: ClassAssertion(Man PSmith) (30) Thus, the main drawback of easy keys is that they can only produce consequences about explicit data and are thus relevant mainly for query answering, whereas the general variant of keys [23] can also affect the subsumption hierarchy between classes. The main benefits of easy keys are that adding them to OWL 2 do not increase the worst-case complexity of reasoning, and that implementing them in the existing reasoners is relatively straightforward Extensions under Discussion The Working Group is currently discussing whether to extend OWL 2 with n-ary datatypes, such as the binary datatype equal.suchdatatypes could then be used to compare values of data properties for a given object. For example, the following expression defines the class of objects whose width is equal to their height: AllValuesFrom(width height equal) (31) Unfortunately, ever since concrete datatypes were introduced in [2], it has been known that comparing values of data properties for different objects (e.g., defining the class of people who have a child who is older than their spouse) easily leads to undecidability, unless the concept language is significantly weakened. Similarly, aggregate functions can be combined only with very simple DLs if decidability is desired [3], so it was therefore decided not to include these expressive features into OWL The MOF Metamodel for OWL 2 To solve the problems identified in Section 2.2, the structure of OWL 2 ontologies has been unambiguously specified using OMG s Meta-Object Facility (MOF). 15 MOF is a well-known metalanguage, and has been extensively used for specification of other languages. The MOF metamodel also called the structural specification of OWL 2 is presented in the documents using the Unified Modeling Language (UML). The classes of the MOF metamodel describe the canonical structure of OWL 2 ontologies in a way that is independent of the syntax used to serialize the ontologies. The specification consists of 22 UML class diagrams. For example, Figure 1 shows the UML diagram that defines an ontology as consisting of a set of axioms and of a set of annotations; furthermore, it shows that an ontology can import asetofontologiesandthateachaxiomcancontain asetofannotations. OWL 2 axioms are defined as subclasses of the abstract class Axiom. Forexample,Figure2shows the diagram that defines the structure of class axioms, where the axiom EquivalentClasses is defined as taking a set of classes. The MOF metamodel for OWL 2 can be seen as analogous to the Document Object Model (DOM) specification 16 for XML. It unambiguously specifies what OWL 2 ontologies are in terms of their structure and thus makes the specification precise. Moreover, it can be taken as a foundation for the design of an OWL 2 API. By committing to a well-known metamodel, APIs of different developers should be interoperable, which will reduce the burden on application developers. The MOF metamodel of OWL 2 also defines the notion of structural equivalence, whichdetermines whether two ontology components are considered to be the same. For example, the following two OWL 2axiomsarenotidentical;theyare,however,structurally equivalent, since the EquivalentClasses axiom consists of a set of classes in which the order of the elements is not relevant: EquivalentClasses(Person Human) (32) EquivalentClasses(Human Person) (33) Structural equivalence is important for the definitions of the functionality of OWL 2 APIs and ser