document.148

2. Why Go Beyond OWL 1? Although, or even perhaps because, OWL 1 has been successful, certain problems have been identi- fied 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. 2.1. 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. 2.1.1. 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 http://www.w3.org/2001/sw/BestPractices/OEP/ 2 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, quali- fied 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. 2.1.2. 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, then x 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. 2.1.3. 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: 8 http://obo.sourceforge.net/ 9 http://www.snomed.org/ 10 http://www.obofoundry.org/ 3 – 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 , and leaves the implementation 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, require the representation of infinite sets of irregular intervals; currently, it is not clear whether and how such datatypes should be implemented in practice. 2.1.4. 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 http://www.w3.org/TR/xmlschema-2/ 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 1 would harm the computational properties of the language and could even lead to undecidability[23]. 2.2. 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 1 Abstract Syntax, however, have made the syntax 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.