Ontology Design Pattern Language Expressivity Requirements Matthew Horridge1 , Mikel Egaña Aranguren2 , Jonathan Mortensen1 , Mark Musen1 , and Natalya F. Noy1 1 Stanford Center for BioInformatics Research (BMIR), Stanford University, California, USA 2 Biological Informatics, Centre for Plant Biotechnology and Genomics (CBGP), Technical University of Madrid, (UPM), Spain Abstract. In recent years there has been a large amount of research into capturing, publishing and analysing Ontology Design Patterns (ODPs). However, there has not been any analysis into the typical language ex- pressivity required to represent ODPs and how these requirements sit with lightweight fragments of the widely used ontology language OWL. In this paper we therefore present a survey on the language expressivity required to express the ODPs contained in the two main ODP catalogs: ODP.org and ODPS.sf.net. We surveyed a total of 104 machine process- able ODPs and found that the OWL representations of these patterns typically require highly expressive fragments of the OWL language such as ALCHIN , SHOIN , SHOIQ and SROIQ. We observed that most ODPs required the use of inverse properties, cardinality restrictions and universal restrictions, and that 10 patterns require OWL 2 constructs such as property chains, disjoint properties and qualified cardinality re- strictions that are not available in OWL 1. Moreover, we found that most of the ODPs cannot be incorporated into ontologies that are constrained to fit into one of the OWL 2 profiles. Specifically, only 12 out of the 104 ODPs surveyed can be represented in OWL2EL, 13 in OWL2RL and 23 in OWL2QL. Despite this, we conjecture that it may be possible to rewrite and weaken some of them so that modellers using lightweight fragments of OWL can incorporate ODPs into their ontologies. 1 Introduction Ontology Design Patterns (ODPs) are modelling solutions that solve recurrent ontology design problems [4]. Much of the work on ODPs has been inspired by the well known work on software design patterns from the mid nineties [3]; Gamma et al. presented and categorised small object-oriented models which are intended to be general solutions to specific but common problems in software design. The main benefit behind the use of software design patterns is that they decrease the incidence of poor modelling choices that could cause problems at a later date. Additionally, code that is based on software design patterns is more readable, more maintainable, and more reusable than code which is not. In many ways these are the exact reasons that motivate the use of design patterns as applied to ontologies and in recent years there has been a thrust of research aiming at inventing and promoting the use of ODPs in ontology engineering. Two prominent sources of ODPs are the ontologydesignpatterns.org cat- alog (ODP.org), and the odps.sourceforge.net catalog on the SourceForge.net website (ODPS.sf.net). The first is a centralised repository, initiated by Gangemi et al., which takes submissions from researchers and practitioners that work in a variety of research areas and application domains. At the time of writing, this repository contains over 150 submissions binned into different categories. The second is based on the experience of Egaña et al. at the University of Manch- ester in representing biomedical knowledge. They propose 17 ODPs designed to tackle modelling problems and ontology language limitations. Both of these catalogs are specific to the Web Ontology Language OWL [10]. That is, ODPs are presented and described in terms of fragments of OWL ontologies. The focus on OWL, as opposed to a “generic” (logic) based ontology lan- guage, is unsurprising. OWL is one of the most widely used ontology languages, it has excellent tool support in terms of editors and reasoners, and it is a World Wide Web Consortium (W3C) recommendation. The latest version of OWL is OWL 2, which became a W3C recommendation in October 2009 and is based on Description Logics. This logical underpinning provides a precise semantics and makes it possible to specify various reasoning tasks such as consistency checking, satisfiability testing and general entailment checking. Off the shelf au- tomated reasoners such as ELK, FaCT++, HermiT, Pellet and Racer can be used to perform these key reasoning tasks and ontology development environ- ments such as Protégé and the NeOn Toolkit provide hooks for integrating third party reasoners. Since OWL 2 is a highly expressive language key reasoning tasks like consistency checking have an extremely high worst case complexity: 2NExpTime-Complete [8], i.e., intractable. This, coupled with the fact that im- plementing a highly optimised and scalable reasoner for the full language is a non-trivial task, and the fact that several well known biomedical ontologies, such as SNOMED [13], fit within smaller tractable fragments of the language, led to the development of the three so-called “profiles”: OWL2EL, OWL2RL and OWL2- QL [9]. Each profile was carefully designed with practical use cases in mind, but a key aspect of each one is that it restricts what can be modelled so as to limit expressivity and make it possible, and easy, to implement efficient and scalable reasoners. When it comes to applying ODPs to a domain or application ontology, and in particular an ontology which is specifically designed to fit into one of the OWL 2 profiles, it is not clear whether it is possible to incorporate any of the cataloged ODPs without compromising language expressivity constraints. This is a real concern, particularly for biomedical ontologies. For example, the large and well known medical ontology SNOMED is constrained to fit within the lightweight OWL2EL profile [12]. Many of the ontologies in the NCBO BioPortal reposi- tory [2] fall into the OWL2EL profile [6], and a sizeable number of them fall into the OWL2RL profile. Whether these ontologies were deliberately constrained to these profiles or not, it seems plausible that application of ODPs to these ontolo- gies could easily take them outside of these profiles, thus losing the possibility of efficient, scalable reasoning. Ultimately, little is known about the language expressivity required to represent cataloged ODPs and how many ODPs can be represented or used within one of the OWL 2 profiles. The aim of this paper is therefore to present a survey and discussion of ODP language expressivity requirements. 2 Preliminaries OWL 2 An OWL 2 ontology is a set of axioms (statements) which state some- thing about the domain of interest. For example, a subclass axiom states that one class is a subclass of another class (e.g. Car is a subclass of Vehicle); an in- verse properties axiom states that one property is the inverse of another property (e.g. hasPart is the inverse of isPartOf ); and a disjoint classes axiom states that one class is disjoint with another class (e.g. Plant is disjoint with Animal). The OWL 2 language is underpinned by a highly expressive Description Logic called SROIQ [7]. This gives statements made in OWL a precisely defined mean- ing and, for a given ontology, makes it possible to use automated reasoning to compute whether or not a statement follows from the ontology. Statements that follow from an ontology are known as entailments. The process of reasoning used to determine whether or not an entailment follows from an ontology is known as entailment checking. Generally speaking, expressivity comes at a price—as expressivity increases so does the complexity (difficulty) of various reasoning problems such as entailment checking. Description Logics As mentioned, OWL is underpinned by a Description Logic called SROIQ. Generally speaking, Description Logics (DLs) are decidable frag- ments of First Order Logic. There are many different DLs, with each one being defined by the class, property and axiom constructors that it admits. One of the simplest DLs is known as AL (Attributive Language). This DL supports concept intersection (owl:intersectionOf), universal quantification (owl:allValuesFrom), limited existential quantification (owl:someValuesFrom with a filler restricted to owl:Thing) and atomic negation (owl:complementOf to named classes). More ex- pressive DLs can be obtained from AL by adding further constructors. Each constructor is given a specific letter which is used to derive a name for any par- ticular DL. For example, adding full negation C to AL produces the DL ALC. Adding property hierarchy H (rdfs:subPropertyOf) to ALC produces ALCH. Adding nominals O (owl:oneOf), inverse properties I (owl:inverseOf) and num- ber restrictions N (owl:minCardinality, owl:maxCardinality or owl:cardinality) to ALCH produces ALCHOIN . Finally adding transitive properties (owl:Trans- itiveProperty) to ALCHOIN produces SHOIN , as the combination of ALC with transitive properties is abbreviated to S. SHOIN is the DL that under- pins OWL 1. OWL 2 extends the expressivity of OWL 1 with qualified cardi- nality Q to give SHOIQ, and complex chains (owl:propertyChainAxiom), reflex- ive (owl:ReflexiveProperty), irreflexive (owl:IrreflexiveProperty), and disjoint properties (owl:disjointWith) R to give SROIQ. Distinct from the AL based family of DLs are EL based DLs. Rather than being based on universal quantifi- cation (owl:allValuesFrom), the EL family is based on existential quantification (owl:someValuesFrom), and universal quantification is prohibited. An important EL based DL is EL++ [1]. This is the DL which underpins OWL2EL and for which entailment checking can be efficiently performed in polynomial time w.r.t. the size of the input ontology. OWL 2 Profiles As mentioned in the introduction, OWL 2 contains three profiles: – OWL2EL—Based on the lightweight EL++ DL. OWL2EL is designed for rep- resenting large and moderately complex ontologies. In particular, it was de- signed with biomedical ontologies in mind. – OWL2RL —This profile was designed to allow reasoning to be efficiently implemented with traditional rule engine based technologies. – OWL2QL —Based on the lightweight DL-Lite family of DLs. This profile was designed for applications that combine a simple ontology with large amounts of instance data (possibly stored in a database). Each profile limits the class, property and axiom constructors that it admits in order to achieve desirable properties in terms of reasoning. Of particular interest to this work is the OWL2EL profile, which is designed for represent- ing large BioMedical ontologies. This profile prohibits the use of universal re- strictions (∀, owl:allValuesFrom), cardinality restrictions (owl:minCardinality, owl:maxCardinality, owl:cardinality), functional (owl:FunctionalProperty), in- verse functional properties (owl:InverseFunctionalProperty), inverse properties (owl:inverseOf), disjunction (t, owl:unionOf), arbitrary negation (¬, owl:comp- lementOf), enumerations involving more that one individual (owl:oneOf), and disjoint, irreflexive and asymmetric properties. A full specification of each pro- file is beyond the scope of this paper—the interested reader is referred to the OWL 2 Profiles specification document [9]. Ontology Design Pattern Documents As mentioned in Section 1, the two main repositories of ODPs are the ODP.org repository and the ODPS.sf.net cata- log. Each repository describes ODPs in a fairly standard way, i.e., the name of the pattern, the problem the pattern is supposed to solve, limitations etc. Most of the patterns in each repository also contain a small ontology document that represents the pattern: a “pattern ontology”. This pattern ontology document either (1) provides a domain specific example of the pattern, or (2) represents a small ontology that can be reused in the domain ontology. In the first case, the idea is that the pattern ontology document is copied into the domain ontol- ogy document with the appropriate translation of vocabulary from the example domain to the real domain. In the second case, the pattern ontology document is directly reused, by import, without modification. Patterns that fall into the second category are known as Content Design Patterns [11]. 3 Materials and Method Pattern Selection The ODPs that we considered for this study are the ones which contain a pattern ontology document as part of their pattern definition. That is, ODPs which are described with a parsable OWL ontology. Being able to parse a pattern (or an exemplar of a pattern) from an ontology document provides a clean way to automatically and unambiguously analyse the pattern, determine the expressivity of the language that is required to represent that pattern, and determine if this language falls into one of the three OWL 2 pro- files. In the case of the ODP.org catalog, there are 91 proposed content ontology design patterns3 that are represented as ontology documents. In the case of the ODPS.sf.net catalog4 all 17 cataloged patterns are described with exemplar ontology documents. Pattern Retrieval We accessed both catalogs on the 8th of August 2012. A total of 91 content patterns were listed in the ODP.org catalog. However, the on- tology documents for the patterns PharmaInnova and BiologicalEntities could not be downloaded due to HTTP 404 (File Not Found) errors. Thus, we obtained a total of 89 pattern ontology documents from the ODP.org catalog. In the ODPS.sf.net catalog we retrieved all 17 pattern ontology documents. Out of these, we discarded the Normalisation and UpperLevelOntology pattern documents: these patterns do not require a fixed or minimum level of expres- sivity for instantiating them—the Normalisation pattern depends upon the class definitions that are appropriate to the domain being modelled, while the UpperLevelOntology pattern depends on the particular upper level ontol- ogy in question. This provided us with a total of 15 ontology pattern documents from the ODPS.sf.net catalog, and therefore a grand total of 104 pattern ontology documents for processing. Pattern Processing and Analysis Each ontology document was parsed with the OWL API [5] (Version 3.3) in order to check that it was well formed. Next the OWL API Metrics and Profiles APIs were used to first compute the expressivity required to represent the pattern and then to check to see whether the pattern falls into OWL2DL and the three OWL profiles: OWL2EL, OWL2RL and OWL2- QL. The results are summarised in the two tables in Section 4 below. 4 Results Results are summarised in Table 1 and Table 2. The columns display the name of the pattern, the expressivity required to represent the pattern, whether the pattern fits into OWL2DL (DL), OWL2EL (EL), OWL2RL (RL) or OWL2QL (QL), whether the pattern contains universal restrictions (∀), or disjunctions (t), and whether or not OWL 2 constructs are required to represent the pattern 3 http://ontologydesignpatterns.org/wiki/Category:ProposedContentOP 4 http://odps.sourceforge.net/ (Req.OWL2). Patterns that fulfil these latter seven properties are denoted with tick (4) in the appropriate cell, otherwise the cell is left empty. Usage of uni- versal restrictions (∀) and disjunction (t) has been singled out for presentation because these two constructors would otherwise be “lumped in” with the base language AL. In addition to this, their use is prohibited in two out of the three OWL 2 profiles, namely OWL2EL and OWL2QL. Table 1: Expressivity required for the ODPs from the ODP.org catalog. Id Name Expressivity DL EL RL QL ∀ t Req.OWL2 ++ 1 EthnicGroup EL 4 4 4 2 RTMSMapping EL++ 4 4 4 3 SpeciesConservation EL++ 4 4 4 4 Airline EL++ 4 4 4 4 5 ConceptGroup EL++ 4 4 4 4 6 ConceptTerms EL++ 4 4 4 4 7 Metonymy EL++ 4 4 4 4 8 SpeciesNames EL++ 4 4 4 4 9 GoTop EL++ 4 4 4 10 Invoice ALF (D) 4 4 11 Classification ALI 4 4 12 Collection ALI 4 4 13 CollectionEntity ALI 4 4 14 Constituency ALI 4 4 15 ActingFor ALI 4 4 4 16 PartOf ALI+ 4 17 Place ALI+ 4 18 Set ALI(D) 4 4 19 Region ALI(D) 4 4 20 Parameter ALI(D) 4 4 4 21 SpeciesEat ALEI 4 4 22 AOS ALU HIF + (D) 4 4 23 HasPest ALU HIF + (D) 4 4 24 TimeInterval ALHN (D) 4 4 25 ObjectRole ALHI 4 4 26 Componency ALHI+ 4 4 27 Sequence ALHI+ 4 28 IntensionExtension ALIN 4 4 29 Situation ALIN 4 30 TimeIndexedSituation ALHIN (D) 4 31 LiteralReification ALHIN + (D) 4 4 32 CommunicationEvent ALEHOIN (D) 4 4 33 TypesOfEntities ALC 4 4 34 AquaticResources ALCI 4 4 35 Participation ALCI 4 4 36 SpeciesHabitat ALCI 4 4 37 InformationRealization ALCI 4 4 38 GearVessel ALCI 4 4 4 39 RoleTask ALCI 4 4 4 40 TaskRole ALCI 4 4 4 41 AgentRole ALCHI 4 4 42 GearSpecies ALCHI 4 4 43 GearWaterArea ALCHI 4 4 44 Communities ALCHI 4 4 45 VesselSpecies ALCHI 4 4 46 VesselWaterArea ALCHI 4 4 47 Move ALCHI 4 4 4 48 CoParticipation ALCIN 4 49 CountingAs ALCIN 4 50 Price ALCIN (D) 4 51 SpeciesBathymetry ALCIN (D) 4 52 Criterion ALCHIN 4 53 CriterionSetter ALCHIN 4 Table 1: Expressivity required for the ODPs from the ODP.org catalog. Id Name Expressivity DL EL RL QL ∀ t Req.OWL2 54 Description ALCHIN 4 55 DescriptionAndSituation ALCHIN 4 56 ParticipationRole ALCHIN 4 57 Persons ALCHIN 4 4 58 SpeciesConditions ALCHIN 4 59 TaskExecution ALCHIN 4 4 60 Bag ALCHIN (D) 4 61 BasicPlanExecution ALCHIN (D) 4 4 62 ClimaticZone ALCHIN (D) 4 63 NaryParticipation ALCHIN (D) 4 64 Observation ALCHIN (D) 4 65 ResourceAbundanceObs ALCHIN (D) 4 66 ResourceExploitationObs ALCHIN (D) 4 67 Tagging ALCHIN (D) 4 4 68 TimeIndexedClassification ALCHIN (D) 4 69 TimeIndexedParticipation ALCHIN (D) 4 70 TimeIndexedPersonRole ALCHIN (D) 4 71 VerticalDistribution ALCHIN (D) 4 72 LinneanTaxonomy SHI 4 4 4 73 SimpleOrAggregated SHI 4 4 74 ControlFlow SHIN 4 4 75 InformationObjects SHIN 4 4 4 76 SimpleTopic SHIN 4 4 77 Topic SHIN 4 4 78 Action SHIN (D) 4 4 79 BasicPlan SHIN (D) 4 4 80 List SHIN (D) 4 81 PlanConditions SHIN (D) 4 4 82 TimeIndexedPartOf SHIN (D) 4 83 PeriodicInterval SHOIN (D) 4 84 CatchRecord SHIQ(D) 4 4 4 4 85 Transition SHIQ(D) 4 4 4 86 AquaticResourceObs SHOIQ(D) 4 4 4 4 87 Roles SRIN 4 4 88 SocialReality SRIN 4 4 89 Reaction SRIQ 4 4 ODP.org results summary Out of the 89 content ODPs 9 fit into the lightweight EL++ DL and therefore the OWL2EL profile. 13 fit into OWL2RL profile, and 22 into OWL2QL. One pattern, Reaction, violates the OWL2DL global restrictions which forces any ontology that includes this pattern out of OWL2DL. This par- ticular pattern contains some disjoint properties axioms which specify that some properties which happen to be Non-Simple are disjoint with each other5 . In terms of other prominent constructs, 77 patterns require inverse properties (I), 45 pat- terns require cardinality restrictions of some form—either plain (N ) or qualified (Q) min, max, or exact cardinality restrictions, 3 patterns require the implicit use of cardinality restrictions through the use of functional properties (F), and 27 patterns use universal restrictions (∀). Six patterns require OWL 2 constructs, that are not present in OWL 1, for their representation. Specifically, the Re- action pattern uses disjoint properties axioms and complex property chains, Roles uses complex property chains and anonymous inverse properties, and 5 Non-Simple properties may not be used in certain positions in certain axioms, for example as operands in a DisjointProperties axiom. Roughly speaking, a property is Non-Simple if it is implied by a property chain (or transitive property). SocialReality uses complex property chains. Four patterns (CatchRecord, Transition, Reaction and AquaticResourceObs) require the use of qual- ified cardinality restrictions (Q), which are only available in OWL 2. Table 2: Expressivity required for the ODPs from the ODPS.sf.net catalog. Id Name Expressivity DL EL RL QL ∀ t Req.OWL2 ++ 1 NaryRelationship EL 4 4 4 2 CompositePropertyChain EL++ 4 4 4 3 DefinedClassDescription EL++ 4 4 4 NaryDataTypeRelationship ALEF (D) 4 5 Closure ALC 4 4 6 EntityPropertyQuality ALCF 4 4 7 ValuePartition ALCF 4 8 Selector ALCHF 4 4 9 Exception ALCN 4 4 10 EntityFeatureValue ALCQ 4 4 4 11 InteractorRoleInteraction ALCQ 4 4 4 4 12 EntityQuality ALCIQ 4 4 4 4 13 AdaptedSEP S 4 4 14 Sequence SHF 4 15 List SHN 4 4 ODPS.sf.net results summary Out of the 15 pattern ontology documents, 3 fall into the OWL2EL profile, 0 fall into the OWL2RL profile, and 1 falls into the OWL2QL profile. One of these OWL2EL ontologies requires property chains, which are an OWL 2 construct. One of the patterns, EntityQuality, uses in- verse properties (I), 4 patterns use some form of explicit plain (N ) or qualified (Q) cardinality restriction, while 5 ontologies require implicit cardinality restric- tions due to the use of functional properties (F). Only 3 patterns use universal restrictions (∀), while 8 patterns use disjunction (t). 5 Analysis Pattern Expressivity Requirements As can be seen from Tables 1 and 2, patterns from both the ODP.org and the ODPS.sf.net catalogs require a range of language expressivity, from the lightweight EL++ to the highly expressive lan- guages ALCHIN , SHIN , SHOIQ, and SROIQ. Both catalogs lean towards requiring more expressive fragments of OWL, with many patterns that use con- structs which bump up the expressivity from the base languages of EL++ or AL. For example, in the ODP.org catalog it is typically the case that patterns require the use of inverse properties (77 out of 89 patterns) and cardinality restrictions (45 out of 89 patterns). It is also evident that both universal restrictions (∀) and disjunctions (t) are sprinkled throughout the patterns in both patterns catalogs, with notable use universal restrictions in the ODP.org catalog, and disjunction within the ODPS.sf.net catalog. Universal restrictions are typically used to “close off” possibilities or model the local range of a property, whereas disjunctions are used to model “choices” or options for a property, so at first glance it makes sense that they appear in many patterns. Pattern Expressivity and the OWL 2 Profiles While both pattern catalogs contain some patterns that can be represented within one or more of the OWL 2 profiles, it is clear that most of the patterns (59 out of 89 patterns from the ODP.org catalog and 12 out of 15 patterns from ODPS.sf.net catalog) cannot be represented in any languages corresponding to the profiles. This means that large swaths of patterns from both catalogs are “off limits” for ontology engineers targeting a specific profile. Only 9 out of 89 and 3 out of 15 patterns from the ODP.org and ODPS.sf.net catalogs respectivelly can be represented in the OWL2EL profile language. One of the startlingly obvious reasons for this is that OWL2EL prohibits the use of inverse properties (I), the use of cardinality restrictions (N , Q or F) and the use of universal restrictions (∀). Interestingly, as far as the ODP.org catalog is concerned, more patterns fall into the OWL2RL and OWL2QL profiles than the OWL2EL profile. Unlike the OWL2EL profile, both of these profiles admit the use of inverse property axioms. Despite this OWL2QL is not strictly more expressive than OWL2EL, in fact it is a lightweight language profile that arguably puts more constraints on modellers than OWL2EL. This would seem to indicate inverse properties do play a major role in patterns violating the OWL2EL profile. Pattern Expressivity and BioMedical Ontology Expressivity As men- tioned previously, the OWL2EL profile is a pertinent profile for modelling and reasoning with biomedical ontologies. In fact, because of the prominence and importance biomedical ontologies OWL2EL was designed with these kinds of on- tologies in mind. The language that underpins OWL2EL is expressive enough that it can be used to model typical biomedical ontologies, but its expressivity is limited to guarantee efficient reasoning. Indeed, OWL2EL reasoners such as ELK are able to classify large ontologies like SNOMED in a few seconds. To put things into perspective, more than half of the BioMedical ontologies contained in the NCBO BioPortal repository are OWL2EL ontologies [6], and the large medical ontology SNOMED expressly targets a fragment of this language in or- der to guarantee efficient reasoning [12]. It is therefore somewhat unfortunate that only a handful of ODPs can be expressed in OWL2EL. In essence, there is currently a tension between staying within a profile that offers fast and efficient reasoning and using ODPs. An interesting aspect of this tension is that patterns in the ODPS.sf.net catalog were specifically designed with biomedical ontology engineering in mind6 . 6 Towards Profile Friendly Patterns Given the tension between typical biomedical ontology expressivity and the ex- pressivity required to represent ODPs, an argument can be made in favour of producing versions of patterns that require limited expressivity. This argument also holds for other domains and the other profiles OWL2RL and OWL2QL. One 6 It should be noted that the ODPS.sf.net catalog was compiled before OWL2EL was designed and published. way of going about this would be to take existing patterns and rewrite or weaken them to conform to the required expressivity. In what follows we provide some examples of the ways in which the current ODP definitions could be modified to make them more usable with profile constrained ontologies. Rewrite Cardinality Restrictions There is an abundance of patterns that required cardinality restrictions (45 out of 89 ontologies in the ODP.org catalog and 5 out of 15 in the ODPS.sf.net catalog). With both catalogs, it is plausible that cardinality restrictions were introduced into patterns either due to side-effects of particular tools, or due to modeller taste. This is a reasonable conclusion to arrive at because there are a high number of patterns which use min-one cardinality restrictions that could be directly replaced with existential restrictions without any loss of information7 —in the case of the ODP.org catalog 24 patterns could be rewritten and in the case of ODPS.sf.net all 5 patterns which use cardinality restrictions could be rewritten. Replace Universal Restrictions with Range Axioms Another construct that is prevalent throughout the patterns in ODP.org catalog but is not permitted in either OWL2EL or OWL2QL is the universal restriction (∀). Upon casting an eye over patterns that use universal restrictions, it appears that many of them use these kinds of restrictions as simple local range constraints. For example, SubClassOf(A ObjectAllValuesFrom(hasPart B)) imposes a local range of B on the property hasPart for the class A. In patterns where the properties in these uni- versal restrictions have limited usage (i.e. only one such universal restriction per property) it may be possible to replace the universal restriction with a global property range axiom (i.e.ObjectPropertyRange(hasPart B))8 —these kinds of ax- ioms are permitted in both OWL2EL and OWL2QL. Out of the 27 patterns from the ODP.org catalog that use universal restrictions, 23 patterns use them to im- pose one local range constraint on one property for one class. For these patterns it would be possible to write these local range constraints as global OWL range axioms without affecting the consistency and intended semantics of the pattern ontology. Make Inverse Properties Optional The inverse properties axiom (I) is prevalent throughout the ODP.org catalog and increases pattern expressivity lead- ing to OWL2EL profile violation. From a philosophical point of view it is hard to say whether or not inverse properties are intrinsic to the ODPs in this catalog. However, an analysis of inverse property usage suggests that in some cases such usage could be due to the routine modelling practice of always declaring an in- 7 The restriction ObjectMinCardinality(1 hasPart A) is semantically equivalent to the existential restriction ObjectSomeValuesFrom(hasPart A). 8 Obviously, some care must be taken to ensure that multiple local ranges for a given class and property (possibly asserted in different patterns or in a domain ontology) do not produce an unsatisfiable range when converted to a global range and intersected with each other. verse for a property9 —irrespective of whether the inverse is used in a meaningful manner elsewhere in the ontology. As an illustration, consider that the axioms below appear in some pattern. ObjectProperty(hasPart) ObjectPropertyDomain(hasPart, A) ObjectPropertyRange(hasPart, B) ... ObjectInverseOf(hasPart, isPartOf) ObjectPropertyDomain(isPartOf, B) ObjectPropertyRange(isPartOf, A) The property hasPart will be declared and used throughout the pattern, but 3 additional axioms will be also added: the inverse of hasPart (isPartOf ) and the domain and range for this inverse as the “reverse” of the domain and range for hasPart (the primary property). In these cases, inverses could be made into an optional part of the design pattern that could be “bolted on” for domain or application ontologies that specifically require them, but left out for (biomedical) ontology engineers who want to remain with a profile such as OWL2EL. This optionality could be realised by offering different versions of the ODP or by splitting the ODP into separate ontologies which can be selected and imported by modellers only as required. Out of the 71 ontologies that contain inverse property axioms, 13 ontologies contain inverse usage as described above. A further 22 ontologies contain this “good practice” use of inverses plus asserting a property hierarchy for the inverses so that the inverse property hierarchy mirrors the primary property hierarchy. This hierarchy based kind of inverse usage could also be made optional. 7 Conclusions In this paper we presented a study of the language expressivity required for us- ing OWL ODPs. ODPs from the two main catalogs, ODP.org and ODPS.sf.net, were studied. Although there are a handful of patterns that can be represented using lightweight fragments of OWL most patterns require more heavyweight fragments containing inverse properties, cardinality restrictions, universal re- strictions and disjunction. A small number of patterns require constructs that are only available in OWL 2, including property chains, disjoint properties and qualified cardinality restrictions. What is evident is that very few patterns can be represented in fragments of the language that are contained within one or more of the OWL 2 profiles. In particular, very few patterns, including ones specifically targeted at biomedical ontology construction, conform to the OWL2- EL profile. This means that there is a tension between using a language that was designed with biomedical ontologies in mind and using design patterns that were 9 Often perceived as a good practice. designed for biomedical ontologies. More generally, since all three OWL profiles were designed with the goal of supporting fast and efficient reasoning, modellers must currently make a choice between taking advantage of ODPs or taking ad- vantage of high performance tools. An initial analysis of the constructs which lead to the high expressivity requirements of patterns suggest that some of these issues could be dealt with by rewriting patterns to use different constructs and making parts of patterns, especially those that use inverse properties, optional. As future work, it would be interesting to assess the impact of such changes on ontology engineering. Acknowledgements This work was supported by the NIH Grants GM086587, HG004028, and LM007033. Mikel Egaña Aranguren is funded by the Marie Curie-COFUND Programme (FP7) of the European Union. References 1. Franz Baader, Sebastian Brandt, and Carsten Lutz. Pushing the EL envelope. In IJCAI 05, Edinburgh, Scotland, UK, July 30-August 5, 2005, 2005. 2. Natalya F. Noy et al. BioPortal: Ontologies and integrated data resources at the click of a mouse. Nucleic Acids Research, 37(suppl 2):W170–W173, May 2009. 3. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. 4. Aldo Gangemi and Valentina Presutti. Ontology Design Patterns. International Handbooks on Information Systems. Springer, 2009. 5. Matthew Horridge and Sean Bechhofer. The OWL API: A Java API for OWL ontologies. Semantic Web, 2(1):11–21, February 2011. 6. Matthew Horridge, Bijan Parsia, and Ulrike Sattler. The state of biomedical on- tologies. In BioOntologies 2011 15th–16th July, Vienna Austria, 2011. 7. Ian Horrocks, Oliver Kutz, and Ulrike Sattler. The even more irresistible SROIQ. In KR 2006, Lake District, United Kingdom, pages 57–67. AAAI Press, June 2006. 8. Yevgeny Kazakov. RIQ and SROIQ are harder than SHOIQ. In KR 2008, Sydney, Australia, September 16-19, 2008. 9. Boris Motik, Bernardo Cuenca Grau, Ian Horrocks, Zhe Wu, Achille Fokoue, and Carsten Lutz. OWL 2 Web Ontology Language Profiles. W3C Recommendation, W3C – World Wide Web Consortium, October 2009. 10. Boris Motik, Peter F. Patel-Schneider, and Bijan Parsia. OWL 2 Web Ontology Language structural specification and functional style syntax. W3C Recommen- dation, W3C – World Wide Web Consortium, October 2009. 11. Valentina Presutti and Aldo Gangemi. Content Ontology Design Patterns as Prac- tical Building Blocks for Web Ontologies. In Proceedings of the 27th International Conference on Conceptual Modeling, ER ’08, pages 128–141, Berlin, Heidelberg, 2008. Springer-Verlag. 12. Kent A. Spackman. An examination of OWL and the requirements of a large health care terminology. In OWLED 2007. 13. Kent A. Spackman and Keith E. Campbell. SNOMED RT: A reference terminol- ogy for health care. In In Proc. of AMIA Annual Fall Symposium, 1997.