Copyright © 2008 W3C^{®} (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is being published as one of a set of 6 documents:
The OWL Working Group intends to make OWL 2 be a superset of OWL 1, except for some small bug fixes and changes to the formal semantics of annotations. This means that OWL 2 will be backward compatible, and creators of OWL 1 documents need only move to OWL 2 when they want to make use of OWL 2 features. More details and advice concerning migration from OWL 1 to OWL 2 will be in future drafts.
The OWL Working Group seeks public feedback on this First Public Working Draft. Please send your comments to publicowlcomments@w3.org (public archive). If possible, please offer specific changes to the text that would address your concern. You may also wish to check the Wiki Version of this document for internalreview comments and changes being drafted which may address your concerns.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Contents 
The purpose of an OWL 2 profile is to provide a trimmed down version of OWL 2 that trades expressive power for efficiency of reasoning. In logic, a profile is usually called a fragment or a sublanguage. This document describes three important profiles of OWL 2, each of them achieving efficiency in a different way and useful in different application scenarios:
The profiles EL++, DLLite, and OWLR DL are defined by placing restrictions on the syntax of OWL 2 DL. In contrast, OWLR Full is defined by placing restrictions on the semantics of OWL 2 Full.
Editor's Note: The working group intends to provide more guidance for users about how to select a profile well suited for their situation. It is not yet determined whether that guidance will be here or in the Primer.
Syntactic restrictions can be specified by modifying the grammar of the functionalstyle syntax [OWL 2 Specification], and (possibly) giving additional nonstructural restrictions. In this document, the modified grammars are specified in two ways. In each section defining a profile, only the difference to the full grammar is given; that is, only the productions that differ from [OWL 2 Specification] are presented and the productions that are the same as in [OWL 2 Specification] are not repeated. In order to make this document selfcontained, the full grammar for each of the fragments is given in the Appendix.
The reasoning tasks mentioned in the description of the profiles are defined as follows.
Apart from the ones specified here, there are many other possible profiles of OWL 2. For example, the OWL Lite version of OWL 1 [OWL 1 Reference] can be viewed as a profile of OWL 2. Since its computational properties have turned out to be less good than suspected when the OWL 1 recommendation was passed (e.g., satisifiability and subsumption are ExpTimecomplete), OWL 1 Lite is not treated explicitly in this document. OWL 1 DL can be viewed as a profile of OWL 2.
Editor's Note: See ISSUE108 The Working Group has not yet comitted itself to the names of different profiles. The names used in this document are likely to change in future.
Editor's Note: At the second F2F meeting, the Working Group has decided to simplify the vocabulary of OWL ontologies. In future versions of this specification, the terminals of the functionalstyle grammar and the RDF vocabulary will be significantly smaller.
The EL++ profile [EL++,EL++ Update] is designed as a maximal subset of OWL 2 DL that
A main design principle of EL++ is to focus on the class constructors ObjectIntersectionOf and ObjectSomeValuesFrom, but to provide ObjectAllValuesFrom only in the form of range restrictions. Many biomedical ontologies, such as SNOMED CT, fall within this profile.
EL++ provides the following features:
The following features of OWL 2 are missing in EL++:
The productions for EL++ are defined in the following sections. All global restrictions on axioms from the [OWL 2 Specification] apply. An additional such restriction is imposed, as detailed below.
The entities of EL++ are exactly as in the entire OWL 2 language. Furthermore, EL++ supports the owl:Thing and owl:Nothing predefined classes that are interpreted as specified in [OWL 2 Specification].
EL++ supports the following datatypes:
Furthermore, the following predefined datatypes of full OWL 2 are not available in EL++: xsd:double, xsd:float, xsd:long, xsd:int, xsd:short, xsd:byte, xsd:nonPositiveInteger, xsd:negativeInteger, xsd:unsignedLong, xsd:unsignedInt, xsd:unsignedShort, xsd:unsignedByte, xsd:time, xsd:gYear, xsd:gMonth, xsd:gDay, xsd:gYearMonth, and xsd:gMonthDay .
The design principle of EL++ is to focus on the class constructors ObjectIntersectionOf and ObjectSomeValuesFrom, which are used extensively in many largescale ontologies. It additionally provides for objectExistsSelf, objectHasValue, dataSomeValuesFrom, dataHasValue, and objectOneOf enumerations that contain a single individual (called nominals in the DL literature). Thus, EL++ class descriptions are defined according to the following production:
The productions for class constructors are as defined in [OWL 2 Specification], with the exception of objectOneOf which admits only a single individual:
EL++ disallows ObjectUnionOf, ObjectComplementOf, ObjectAllValuesFrom, DataAllValuesFrom, ObjectMaxCardinality, ObjectMinCardinality, ObjectExactCardinality, DataMaxCardinality, DataMinCardinality, and DataExactCardinality.
Inverse properties are not supported in EL++, and thus object property expressions are restricted to named properties. Data property expressions are as in OWL 2.
objectPropertyExpression := objectPropertyURI
A data range expression is restricted in EL++ to the predefined datatypes admitted in EL++ and enumerated datatypes consisting of a single constant.
dataRange := datatypeURI  dataOneOf
dataOneOf := 'DataOneOf' '('
constant')'
EL++ does not support DataComplementOf and DatatypeRestriction (i.e., no facet is admitted).
The class axioms of EL++ are the same as in full OWL 2, except that DisjointUnion is not allowed.
classAxiom := subClassOf  equivalentClasses  disjointClasses
The productions for all supported kinds class axioms are as in the [OWL 2 Specification], with the difference that they use the new description production. We refer to that document for details.
EL++ supports the following object property axioms.
objectPropertyAxiom :=
equivalentObjectProperties  subObjectPropertyOf 
objectPropertyDomain  objectPropertyRange 
transitiveObjectProperty reflexiveObjectProperty
The productions for all supported kinds of object property axioms are as in the [OWL 2 Specification]. EL++ disallows DisjointObjectProperties, IrreflexiveObjectProperty, InverseObjectProperties, FunctionalObjectProperty, SymmetricObjectProperty, and AsymmetricObjectProperty axioms.
Regarding data property axioms, EL++ provides the same facilities as OWL 2, except DisjointDataProperty. Therefore, data property axioms in EL++ are defined as follows.
dataPropertyAxiom :=
subDataPropertyOf 
equivalentDataProperties 
dataPropertyDomain 
dataPropertyRange 
functionalDataProperty
Again, the productions for all supported kinds of property axioms are as in the [OWL 2 Specification].
The facts in EL++ are the same as in OWL 2, with the diffence that descriptions and object property expressions are restricted as specified previously. Finally, the axioms of EL++ are the same as in OWL 2, with the difference that each axiom type is restricted as specified previously.
The axiom closure Ax of an EL++ ontology must obey the restrictions described in Section 10 of the structural specification [OWL 2 Specification]. To obtain polytime reasoning problems, one additional restriction is imposed.
Let CE be a class expression. We say that Ax imposes a range restriction to CE on an object property PE_{1} if it contains axioms
We require that if
then Ax imposes a range restriction to CE on PE_{n}.
Remarks: (1) The restriction is vacuously true if the SubObjectPropertyOf in the first item is a role inclusion statement  that is, if it does not contain SubObjectPropertyChain. (2) Range restrictions on reflexive and transitive roles are generally allowed, unless they are used in axioms following the forbidden pattern above.
DLLite is a syntactic profile of OWL 2 that admits sound and complete reasoning in LOGSPACE with respect to the size of the data (facts). DLLite includes most of the main features of conceptual models such as UML class diagrams and ER diagrams.
Several variants of DLLite have been described in the literature. The variant presented here is called DLLite_{R} since it allows for property inclusion axioms; it therefore contains the intersection between RDFS and OWL 2 DL. Other variants trade property inclusion axioms for functionality and inversefunctionality of object properties.
Note that the profile presented here is asymmetric: it is defined not only in terms of the set of supported constructs, but it also restricts the places in which these constructs can be used.
Editor's Note: Please note that Data Properties are not yet incorporated into DLLite in this draft, pending consultation with some DLLite experts.
Editor's Note: See ISSUE80 (DLLite) This document currently contains the DLlite_{R} version of DLlite. In future versions of this document, however, this language is likely to be extended with additional constructs that preserve its computational properties, such as Data Properties and suitably restricted Functional Properties.
The following constructs can be used to define subclasses in SubClassOf axioms:
The following constructs can be used to define superclasses in SubClassOf axioms:
All class axioms in DLLite are constrained in a way that is compliant with these restrictions. For example, the property domain and range axioms are allowed to refer only to the superclasses mentioned above:
Moreover, DLLite allows for the following property axioms and facts:
The following features of OWL 2 are missing in DLLite:
The productions for DLLite are defined in the following sections. The global restricitons on axioms defined in the structural specification [OWL 2 Specification] are not enforced in DLLite.
DLLite supports all OWL 2 entities apart from data properties. The entities in DLLite are defined as follows.
entity := owlClass  objectProperty  annotationProperty  individual
The only wellknown entity defined in DLLite is the class with URI owl:Thing, which is interpreted as specified in [OWL 2 Semantics].
In DLLite, there are two types of class expressions. The subClass production defines the classes that can occur in the antecedents of implications; for example, such classes can occur as subclasses in a SubClassOf axiom. The superClass production defines the classes that can occur in the consequents of implications; for example, such classes can occur as superclasses in a SubClassOf axiom.
subClass :=
owlClassURI
other than owl:Thing 
'ObjectSomeValuesFrom' '(' objectPropertyExpression owl:Thing ')'
superClass :=
subClass

'ObjectComplementOf' '(' subClass ')'
DLLite object property expressions are the same as in OWL 2 DL.
DLLite axioms are defined to exclude membership assertions on data properties.
axiom := classAxiom  objectPropertyAxiom  fact  declaration  entityAnnotation
Furthermore, DLLite redefines all axioms from the functionalstyle syntax [OWL 2 Specification] that refer to the description production. In particular, it restricts various class axioms to appropriate forms of classes, and it disallows DisjointUnion. The production for axioms about classes in DLLite are defined as follows.
subClassOf := 'SubClassOf'
'(' subClass superClass ')'
equivalentClasses :=
'EquivalentClasses' '(' subClass
subClass { subClass } ')'
disjointClasses :=
'DisjointClasses' '(' subClass
subClass { subClass } ')'
classAxiom := subClassOf  equivalentClasses  disjointClasses
DLLite disallows the use of property chains in property inclusion axioms (simple property inclusions are just like in OWL 2), it disallows the use of transitive, asymmetric, reflexive and irreflexive properties, and it redefines the domain and range axioms to use the new class productions.
objectPropertyDomain :=
'ObjectPropertyDomain' '(' objectPropertyExpression superClass ')'
objectPropertyRange :=
'ObjectPropertyRange' '(' objectPropertyExpression superClass ')'
objectPropertyAxiom :=
subObjectPropertyOf  equivalentObjectProperties 
disjointObjectProperties  inverseObjectProperties 
objectPropertyDomain  objectPropertyRange 
symmetricObjectProperty
Editor's Note: I assume that negativeObjectPropertyAssertion is not supported by DLLite
DLLite disallows axioms about data properties and negative object property assertion. Furthermore, class membership assertions in DLLite are restricted to only atomic classes. Equality and inequality axioms and property membership assertions are the same as in OWL 2. Therefore, the fact axioms of DLLite are defined as follows.
classAssertion :=
'ClassAssertion' '(' individualURI
classURI ')'
fact := sameIndividual  differentIndividuals  classAssertion  objectPropertyAssertion
OWLR is a profile of OWL 2 that allows for scalable reasoning using rulebased technologies. The profile has been designed so as to avoid the need to infer the existence of individuals not explicitly present in the knowledge base. This design goal enables a straightforward translation of OWL’s semantic conditions into rules, on which most rulebased reasoning engines terminate in a finite amount of time.
Another design goal for OWLR is flexibility. On the one hand, OWLR can accommodate OWL 2 DL applications that can trade the full expressivity of the language for efficiency; on the other hand, OWLR can also accommodate RDF(S) applications that need some added expressivity from OWL. For this purpose, this document provides two variants of OWLR.
The first variant of OWLR, called OWLR DL, is intended to be used by OWL 2 DL users who can trade some expressivity for being able to implement reasoning using rulebased systems. OWLR DL is defined as a syntactic subset of OWL 2 DL  that is, it places syntactic restrictions on OWL 2 DL axioms. For example, in this definition, one cannot declare an OWL class C1 to be a subclass of the union of two classes C2 and C3. The definition of OWLR DL is presented completely in Section 4.2.
The second variant OWLR, called OWLR Full, is intended to be used by RDF(S) users who want to augment RDF(S) with additional contructs. OWLR Full ontologies are thus RDF graphs that are interpreted under a weakened version of the extensional semantic conditions of OWL 2 Full. An axiomatization of the weakened semantics using firstorder implications is provided in the form of entailment rules that operate directly on RDF triples. This set of entailment rules provides a useful starting point for practical inference implementation using rulebased technologies. The definition of OWLR Full is presented completely in Section 4.3. Readers who are familiar with RDF(S) tripleoriented technology and are interested mainly in the semantic axiomatization of OWLR Full using firstorder implication may skip directly to Section 4.3.2.
The definitions of OWLR DL and OWLR Full are independent in the sense that it is not necessary to understand one variant in order to be able to understand the other. Thus, the readers interested in the DL version of OWLR can skip to Section 4.2, whereas the readers interested in the Full version of OWLR can skip to Section 4.3.
The relationship between OWLR DL and OWLR Full is specified precisely in Section 4.4. This clear relationship allows users to switch between the two versions of OWLR if necessary.
Editor's Note: There is an open issue concerning entailments that follow in the OWL Full, but not in OWLR.
OWLR, although just a profile of OWL 2, is quite expressive. An OWLR DL ontology can use, in a nutshell, most OWL 2 language constructs except owl:cardinality, owl:minCardinality, owl2:NegativeObjectPropertyAssertion, owl2:NegativeDataPropertyAssertion, and owl:complementOf.
Not all constructs of OWLR DL can be used freely in all places in the axioms. For example, in SubClassOf axioms, the usage of the constructs on the left and righthand side of the implication must follow the patterns shown in Table 4.1.
LeftHand Side  RightHand Side 

an OWL class a nominal class (OneOf) intersection of classes (ObjectIntersectionOf) union of classes (ObjectUnionOf) existential quantification to an OWL class (ObjectSomeValuesFrom) existential quantification to a nominal (ObjectHasValue) 
an OWL class intersection of classes (ObjectIntersectionOf) universal quantification to a class (ObjectAllValuesFrom) atmost 1 cardinality restrictions (ObjectMaxCardinality 1) existential quantification to a nominal (ObjectHasValue) 
Unlike OWLR DL, in OWLR Full there are no syntactic restrictions on the way language constructs can be used: any RDF graph constitutes a valid OWLR Full ontology. The semantics of language constructs, however, is weakened in OWLR Full to mimic the usage patterns of OWLR DL. For example, in OWL 2 Full (or DL), an OWL class C1 is a subclass of C2 if and only if the extension of C1 is a subset of the extension of C2. In OWLR Full, that "if and only if" condition is weakened to "only if." The principles according to which this weakening has been derived are presented in Section 4.3.1. An equivalent characterization of the weakened semantics by means of firstorder implications is given in Section 4.3.2. Table 2 lists the language constructs that are supported in OWLR Full.
Equality  owl:sameAs owl:differentFrom 
Property Expressions  owl:inverseObjectPropertyExpression 
Property Axioms  rdfs:domain rdfs:range owl:FunctionalProperty owl:InverseFunctionalProperty owl2:ReflexiveProperty owl2:IrreflexiveProperty owl:SymmetricProperty owl2:AsymmetricProperty owl:TransitiveProperty rdfs:subPropertyOf owl2:propertyChain owl:equivalentProperty owl2:propertyDisjointWith owl2:disjointDataProperties owl:inverseOf 
Class Constructs  owl:intersectionOf owl:unionOf owl:someValuesFrom owl:allValuesFrom owl:hasValue owl:maxCardinality 1 
Class Axioms  rdfs:subClassOf owl:equivalentClass owl:disjointClasses 
OWLR DL is a syntactic profile of OWL 2 DL. The profile is defined not only in terms of a set of supported constructs, but it also restricts the places in which these constructs can be used. It is based on Description Logic Programs [DLP]  a logic obtained by intersecting description logics with rulebased languages.
OWLR DL does not impose any restrictions on OWL 2 Entities. Therefore, entities defined here are the same as in [OWL 2 Specification]. Furthermore, OWLR defines the same set of wellknown entities as the entire OWL 2 language:
A data range expression defines a range over data values. In OWLR DL, a data range expression is restricted to either a named atomic datatype (the list of datatypes supported by OWLR DL is identical to the one in [OWL 2 Semantics]) or a datatype restriction, specified by applying some facets to limit the value space of an preexisting datatype.
dataRange := datatypeURI  datatypeRestriction
There are three types of classes in OWLR. The subClass production defines the classes that can occur in the antecedents of implications; for example, such classes can occur as subclasses in a SubClassOf axiom. The superClass production defines the classes that can occur in the consequents of implications; for example, such classes can occur as superclasses in a SubClassOf axiom. Finally, the equivClass production defines the classes that can occur in an EquivalentClasses axiom.
zeroOrOne := '0' 
'1'
subClass :=
owlClassURI
other than owl:Thing 
'ObjectOneOf' '(' individualURI { individualURI } ')'
'ObjectIntersectionOf' '(' subClass subClass { subClass } ')' 
'ObjectUnionOf' '(' subClass subClass { subClass } ')' 
'ObjectSomeValuesFrom' '(' objectPropertyExpression subClass ')' 
'DataSomeValuesFrom' '(' dataPropertyExpression { dataPropertyExpression } dataRange ')' 
'ObjectHasValue' '(' objectPropertyExpression individualURI ')' 
'DataHasValue' '(' dataPropertyExpression constant ')'
superClass :=
owlClassURI

'ObjectIntersectionOf' '(' subClass superClass { superClass } ')' 
'ObjectAllValuesFrom' '(' objectPropertyExpression superClass ')' 
'DataAllValuesFrom' '(' dataPropertyExpression { dataPropertyExpression } dataRange ')' 
'ObjectMaxCardinality' '(' zeroOrOne objectPropertyExpression [ subClass ] ')' 
'DataMaxCardinality' '(' zeroOrOne dataPropertyExpression [ dataRange ] ')' 
'ObjectHasValue' '(' objectPropertyExpression individualURI ')' 
'DataHasValue' '(' dataPropertyExpression constant ')'
equivClass :=
owlClassURI
other than owl:Thing 
'ObjectIntersectionOf' '(' equivClass equivClass { equivClass } ')' 
'ObjectHasValue' '(' objectPropertyExpression individualURI ')' 
'DataHasValue' '(' dataPropertyExpression constant ')'
OWLR constructs used to build more complex properties from existing ones are identical to the ones defined in [OWL 2 Specification].
OWLR redefines all axioms from the functionalstyle syntax OWL 2 Specification that refer to the description production. In particular, it restricts various class axioms to use the appropriate form of class expressions (i.e. one of subClass , superClass, or equivClass), and it disallows the DisjointUnion axiom.
classAxiom := subClassOf  equivalentClasses  disjointClasses
subClassOf := 'SubClassOf'
'(' subClass superClass ')'
equivalentClasses :=
'EquivalentClasses' '(' equivClass
equivClass { equivClass } ')'
disjointClasses :=
'DisjointClasses' '(' subClass
subClass { subClass } ')'
OWLR property expression language is very similar to OWL 2. The only difference is that OWLR restricts property domain and range axioms to the appropriate form of class expressions as follows:
objectPropertyDomain :=
'ObjectPropertyDomain' '(' objectPropertyExpression superClass ')'
objectPropertyRange :=
'ObjectPropertyRange' '(' objectPropertyExpression superClass ')'
dataPropertyDomain :=
'DataPropertyDomain' '(' dataPropertyExpression superClass ')'
Therefore, axioms about object and data properties in OWLR are defined as follows.
objectPropertyAxiom :=
objectPropertyDomain  objectPropertyRange 
subObjectPropertyOf  equivalentObjectProperties 
disjointObjectProperties  inverseObjectProperties 
functionalObjectProperty  inverseFunctionalObjectProperty 
reflexiveObjectProperty  irreflexiveObjectProperty 
symmetricObjectProperty  asymmetricObjectProperty 
transitiveObjectProperty
dataPropertyAxiom :=
dataPropertyDomain  dataPropertyRange 
subDataPropertyOf  equivalentDataProperties  disjointDataProperties 
functionalDataProperty
OWLR restricts the positive facts to a particular type of classes, and it disallows negative property assertions. Equality and inequality between individuals and positive facts are the same as in the entire OWL 2. Therefore, facts in OWLR are defined as follows.
classAssertion :=
'ClassAssertion' '(' individualURI
superClass ')'
fact :=
sameIndividual
 differentIndividuals 
classAssertion 
objectPropertyAssertion  dataPropertyAssertion
Finally, the axioms in OWLR are defined as follows.
axiom := classAxiom  objectPropertyAxiom  dataPropertyAxiom  fact  declaration  entityAnnotation
OWLR Full is defined by weakening the semantic conditions on an interpretation from OWL 2 Full. An equivalent definition is also provided in terms of an "axiomatization" using first order implications. The latter definition should provide a useful starting point for practical implementation using rulebased technologies. It is based on [pD*].
This section defines OWLR Full by weakening the OWL 2 Full semantic conditions on an interpretation.
Editor's Note: We need to add a reference of OWL 2 Full Semantics
Before specifying in more details how the semantic weakining is performed for various features of OWLR Full, we briefly present here the main elements of OWL 2 Full semantics.
First, a datatype map D is a partial mapping from URI references to datatypes that maps xsd:string and xsd:integer to the appropriate XML Schema datatypes.
Next, the OWL 2 Full modeltheoretic semantics defines an interpretation as follows.
From OWL 2 Full Semantics, for V a set of URI references and literals containing the RDF, RDFS and OWL vocabulary and D a datatype map, a Dinterpretation of V is a tuple I = < R_{I}, P_{I}, EXT_{I}, S_{I}, L_{I}, LV_{I} >. R_{I} is the domain of discourse or universe, i.e., a nonempty set that contains the denotations of URI references and literals in V. P_{I} is a subset of R_{I} consisting of the properties of I. EXT_{I} is used to give meaning to properties, and is a mapping from P_{I} to P(R_{I} × R_{I}). S_{I} is a mapping from URI references in V to their denotations in R_{I}. L_{I} is a mapping from typed literals in V to their denotations in R_{I}. LV_{I} is a subset of R_{I} that contains at least the set of Unicode strings, the set of pairs of Unicode strings and language tags, and the value spaces for each datatype in D. The set of all classes in R_{I} is C_{I}, and the mapping CEXT_{I} from C_{I} to P(R_{I}) is defined as CEXT_{I}(c) = { x∈RI  <x,c>∈EXT_{I}(S_{I}(rdf:type)) }. CEXT_{I}(c) maps a class c to its extension. Dinterpretations must meet several other conditions, as detailed in the OWL 2 Full semantics.
Finally, the following important sets are used in the definitions
of OWL 2 Full semantic conditions. IOOP denotes the set of OWL
object properties, and IODP the set of OWL datatype properties.
Both are subsets of P_{I}. IOC, a subset of C_{I},
denotes the set of OWL classes, and IDC is the set of OWL
datatypes. IOR represents the set of OWL restrictions. IOT is the
set of OWL individuals.
In OWLR Full, the weakening of the OWL 2 Full semantic conditions on an interpretation is mainly done by weakening some equivalences in the OWL Full semantics to implications.
For example, the semantics of the owl:someValuesFrom restriction is defined in OWL Full using the following restrictions on the RDF interpretation:
If  < x,y > ∈ EXT_{I}(S_{I}(owl:someValuesFrom)) ∧ < x,p > ∈ EXT_{I}(S_{I}(owl:onProperty))  then  x ∈ IOR, y ∈ IOC ∪ IDC, p ∈ IOOP ∪ IODP, and CEXT_{I}(x) = { u ∈ IOT  ∃ < u,v > ∈ EXT_{I}(p) such that v∈ CEXT_{I}(y) } 

In a simplified form, these conditions can be understood as the following two implications:
If  < x,y > ∈ EXT_{I}(S_{I}(owl:someValuesFrom)) ∧ < x,p > ∈ EXT_{I}(S_{I}(owl:onProperty)) ∧ < u,v > ∈ EXT_{I}(p) ∧ < v,y > ∈ EXT_{I}(S_{I}(rdf:type)) 
then  < u,x > ∈ EXT_{I}(S_{I}(rdf:type)). 

If  < x,y > ∈ EXT_{I}(S_{I}(owl:someValuesFrom)) ∧ < x,p > ∈ EXT_{I}(S_{I}(owl:onProperty)) ∧ < u,x > ∈ EXT_{I}(S_{I}(rdf:type)) 
then  ∃ v such that < u,v > ∈ EXT_{I}(p) ∧ < v,y > ∈ EXT_{I}(S_{I}(rdf:type)). 
The first implication captures the notion of existential restrictions occurring in the antecedents of implications, while the second implication captures the notion of existential restrictions occurring in the consequents of implications. In OWLR Full, the second implication is discarded. Note the parallel with OWLR DL, where syntactic restrictions prevent existential restrictions occurring in the consequents of implications.
Next, the restrictions that define OWLR Full are listed. Instead of repeating all the intricate definitions of OWL Full, this section just specifies the difference to the definitions in the OWL Full document. For readers less familiar with OWL Full semantics, the next section provides a more selfcontained axiomatization of OWLR.
This section defines OWLR Full in terms of firstorder (material) implications. This definition is intended to be equivalent to the one from the previous section. This definition should provide a useful starting point for the practical implementation using rulebased technologies.
The implications are given as universally quantified firstorder implications over a ternary predicate T. This predicate represents RDF triples; thus, T(s, p, o) represents a RDF triple with the subject s, predicate p, and the object o. Variables in the implications are preceeded with the question mark. The semantic conditions are split into several tables for easier navigation. These tables are exhaustive: they specify exactly all the semantic conditions that must hold.
Table 1 axiomatizes the semantics of equality. In particular, it defines the equality relation on resources owl:sameAs as being reflexive, symmetric, and transitive, and it axiomatizes the standard replacement properties of equality for it.
Rule name  If  then 

RE1  T(?s, ?p, ?o) 
T(?s, owl:sameAs, ?s) T(?p, owl:sameAs, ?p) T(?o, owl:sameAs, ?o) 
RE2  T(?x, owl:sameAs, ?y)  T(?y, owl:sameAs, ?x) 
RE3  T(?x, owl:sameAs, ?y) T(?y, owl:sameAs, ?z) 
T(?x, owl:sameAs, ?z) 
RE4  T(?s, owl:sameAs, ?s') T(?s, ?p, ?o) 
T(?s', ?p, ?o) 
RE5  T(?p, owl:sameAs, ?p') T(?s, ?p, ?o) 
T(?s, ?p', ?o) 
RE6  T(?o, owl:sameAs, ?o') T(?s, ?p, ?o) 
T(?s, ?p, ?o') 
RE7  T(?x, owl:sameAs, ?y) T(?x, owl:differentFrom, ?y) 
false 
Table 2 specifies the semantic conditions on axioms about properties.
If  then 

T(?p, rdfs:domain, ?c) T(?x, ?p, ?y) 
T(?x, rdf:type, ?c) 
T(?p, rdfs:range, ?c) T(?x, ?p, ?y) 
T(?y, rdf:type, ?c) 
T(?p, rdf:type, owl:FunctionalProperty) T(?x, ?p, ?y_{1}) T(?x, ?p, ?y_{2}) 
T(?y_{1}, owl:sameAs, ?y_{2}) 
T(?p, rdf:type,
owl:InverseFunctionalProperty) T(?x_{1}, ?p, ?y) T(?x_{2}, ?p, ?y) 
T(?x_{1}, owl:sameAs, ?x_{2}) 
T(?p, rdf:type, owl2:ReflexiveProperty) T(?x, ?y, ?z) 
T(?x, ?p, ?x) T(?y, ?p, ?y) T(?z, ?p, ?z) 
T(?p, rdf:type, owl2:IrreflexiveProperty) T(?x, ?p, ?x) 
false 
T(?p, rdf:type, owl:SymmetricProperty) T(?x, ?p, ?y) 
T(?y, ?p, ?x) 
T(?p, rdf:type, owl2:AsymmetricProperty) T(?x, ?p, ?y) T(?y, ?p, ?x) 
false 
T(?p, rdf:type, owl:TransitiveProperty) T(?x, ?p, ?y) T(?y, ?p, ?z) 
T(?x, ?p, ?z) 
T(?p_{1},
rdfs:subPropertyOf, ?p_{2}) T(?x, ?p_{1}, ?y) 
T(?x, ?p_{2}, ?y) 
T(?x_{1}, rdf:first, ?p_{1})
T(?x_{1}, rdf:rest, ?x_{2}) T(?x_{2}, rdf:first, ?p_{2}) T(?x_{2}, rdf:rest, ?x_{3}) ... T(?x_{n}, rdf:first, ?p_{n}) T(?x_{n}, rdf:rest, rdf:nil) T(?sc, owl2:propertyChain, ?x_{1}) T(?sc, rdfs:subPropertyOf, ?p) T(?u_{1}, ?p_{1}, ?u_{2}) T(?u_{2}, ?p_{2}, ?u_{3}) ... T(?u_{n}, ?p_{n}, ?u_{n+1}) 
T(?u_{1}, ?p, ?u_{n+1}) 
T(?p_{1},
owl:equivalentProperty, ?p_{2}) T(?x, ?p_{1}, ?y) 
T(?x, ?p_{2}, ?y) 
T(?p_{1},
owl:equivalentProperty, ?p_{2}) T(?x, ?p_{2}, ?y) 
T(?x, ?p_{1}, ?y) 
T(?p_{1},
owl2:propertyDisjointWith, ?p_{2}) T(?x, ?p_{1}, ?y) T(?x, ?p_{2}, ?y) 
false 
T(?p_{1},
owl2:disjointDataProperties, ?p_{2}) T(?x, ?p_{1}, ?y) T(?x, ?p_{2}, ?y) 
false 
T(?p_{1},
owl:inverseOf, ?p_{2}) T(?x, ?p_{1}, ?y) 
T(?y, ?p_{2}, ?x) 
T(?p_{1},
owl:inverseOf, ?p_{2}) T(?x, ?p_{2}, ?y) 
T(?y, ?p_{1}, ?x) 
T(?p_{1},
owl2:inverseObjectPropertyExpression, ?p_{2}) T(?x, ?p_{1}, ?y) 
T(?y, ?p_{2}, ?x) 
T(?p_{1},
owl2:inverseObjectPropertyExpression, ?p_{2}) T(?x, ?p_{2}, ?y) 
T(?y, ?p_{1}, ?x) 
Table 3 specifies the semantic conditions on classes.
If  then 

T(?x_{1}, rdf:first, ?c_{1})
T(?x_{1}, rdf:rest, ?x_{2}) T(?x_{2}, rdf:first, ?c_{2}) T(?x_{2}, rdf:rest, ?x_{3}) ... T(?x_{n}, rdf:first, ?c_{n}) T(?x_{n}, rdf:rest, rdf:nil) T(?c, owl:intersectionOf, ?x_{1}) T(?y, rdf:type, ?c_{1}) T(?y, rdf:type, ?c_{2}) ... T(?y, rdf:type, ?c_{n}) 
T(?y, rdf:type, ?c) 
T(?x_{1}, rdf:first, ?c_{1})
T(?x_{1}, rdf:rest, ?x_{2}) T(?x_{2}, rdf:first, ?c_{2}) T(?x_{2}, rdf:rest, ?x_{3}) ... T(?x_{n}, rdf:first, ?c_{n}) T(?x_{n}, rdf:rest, rdf:nil) T(?c, owl:intersectionOf, ?x_{1}) T(?y, rdf:type, ?c) 
T(?y, rdf:type, ?c_{1}) T(?y, rdf:type, ?c_{2}) ... T(?y, rdf:type, ?c_{n}) 
T(?x_{1}, rdf:first, ?c_{1})
T(?x_{1}, rdf:rest, ?x_{2}) T(?x_{2}, rdf:first, ?c_{2}) T(?x_{2}, rdf:rest, ?x_{3}) ... T(?x_{n}, rdf:first, ?c_{n}) T(?x_{n}, rdf:rest, rdf:nil) T(?c, owl:unionOf, ?x_{1}) T(?y, rdf:type, ?c_{1}) 
T(?y, rdf:type, ?c) 
...  ... 
T(?x_{1}, rdf:first, ?c_{1})
T(?x_{1}, rdf:rest, ?x_{2}) T(?x_{2}, rdf:first, ?c_{2}) T(?x_{2}, rdf:rest, ?x_{3}) ... T(?x_{n}, rdf:first, ?c_{n}) T(?x_{n}, rdf:rest, rdf:nil) T(?c, owl:unionOf, ?x_{1}) T(?y, rdf:type, ?c_{n}) 
T(?y, rdf:type, ?c) 
T(?x, owl:someValuesFrom, ?y) T(?x, owl:onProperty, ?p) T(?u, ?p, ?v) T(?v, rdf:type, ?y) 
T(?u, rdf:type, ?x) 
T(?x, owl:allValuesFrom, ?y) T(?x, owl:onProperty, ?p) T(?u, rdf:type, ?x) T(?u, ?p, ?v) 
T(?v, rdf:type, ?y) 
T(?x, owl:hasValue, ?y) T(?x, owl:onProperty, ?p) T(?u, rdf:type, ?x) 
T(?u, ?p, ?y) 
T(?x, owl:hasValue, ?y) T(?x, owl:onProperty, ?p) T(?u, ?p, ?y) 
T(?u, rdf:type, ?x) 
T(?x, owl:maxCardinality,
"0"^^xsd:nonNegativeInteger) T(?x, owl:onProperty, ?p) T(?u, ?p, ?y) T(?u, rdf:type, ?x) 
false 
T(?x, owl:maxCardinality,
"1"^^xsd:nonNegativeInteger) T(?x, owl:onProperty, ?p) T(?u, ?p, ?y_{1}) T(?u, ?p, ?y_{2}) T(?u, rdf:type, ?x) 
T(?y_{1}, owl:sameAs, ?y_{2}) 
Table 4 specifies the semantic conditions on class axioms.
If  then 

T(?c_{1},
rdfs:subClassOf, ?c_{2}) T(?x, rdf:type, ?c_{1}) 
T(?x, rdf:type, ?c_{2}) 
T(?c_{1},
owl:equivalentClass, ?c_{2}) T(?x, rdf:type, ?c_{1}) 
T(?x, rdf:type, ?c_{2}) 
T(?c_{1},
owl:equivalentClass, ?c_{2}) T(?x, rdf:type, ?c_{2}) 
T(?x, rdf:type, ?c_{1}) 
T(?c_{1},
owl:disjointClasses, ?c_{2}) T(?x, rdf:type, ?c_{1}) T(?x, rdf:type, ?c_{2}) 
false 
Table 5 specifies the semantic restrictions on the vocabulary used to define the schema.
If  then 

T(?c, rdf:type, owl:Class)  T(?c, rdfs:subClassOf, ?c) T(?c, owl:equivalentClasses, ?c) 
T(?c_{1},
rdfs:subClassOf, ?c_{2}) T(?c_{2}, rdfs:subClassOf, ?c_{3}) 
T(?c_{1}, rdfs:subClassOf, ?c_{3}) 
T(?c_{1}, owl:equivalentClass, ?c_{2})  T(?c_{1},
rdfs:subClassOf, ?c_{2}) T(?c_{2}, rdfs:subClassOf, ?c_{1}) 
T(?p, rdf:type, owl:ObjectProperty)  T(?p, rdfs:subPropertyOf, ?p) T(?p, owl:equivalentProperty, ?p) 
T(?p, rdf:type, owl:DatatypeProperty)  T(?p, rdfs:subPropertyOf, ?p) T(?p, owl:equivalentProperty, ?p) 
T(?p_{1},
rdfs:subPropertyOf, ?p_{2}) T(?p_{2}, rdfs:subPropertyOf, ?p_{3}) 
T(?p_{1}, rdfs:subPropertyOf, ?p_{3}) 
T(?p_{1}, owl:equivalentProperty, ?p_{2})  T(?p_{1},
rdfs:subPropertyOf, ?p_{2}) T(?p_{2}, rdfs:subPropertyOf, ?p_{1}) 
T(?p, rdfs:domain, ?c_{1}) T(?c_{1}, rdfs:subClassOf, ?c_{2}) 
T(?p, rdfs:domain, ?c_{2}) 
T(?p_{2}, rdfs:domain, ?c) T(?p_{1}, rdfs:subPropertyOf, ?p_{2}) 
T(?p_{1}, rdfs:domain, ?c) 
T(?p, rdfs:range, ?c_{1}) T(?c_{1}, rdfs:subClassOf, ?c_{2}) 
T(?p, rdfs:range, ?c_{2}) 
T(?p_{2}, rdfs:range, ?c) T(?p_{1}, rdfs:subPropertyOf, ?p_{2}) 
T(?p_{1}, rdfs:range, ?c) 
T(?c_{1}, owl:hasValue, ?i) T(?c_{1}, owl:onProperty, ?p_{1}) T(?c_{2}, owl:hasValue, ?i) T(?c_{2}, owl:onProperty, ?p_{2}) T(?p_{1}, rdfs:subPropertyOf, ?p_{2}) 
T(?c_{1}, rdfs:subClassOf, ?c_{2}) 
T(?c_{1},
owl:someValuesFrom, ?y_{1}) T(?c_{1}, owl:onProperty, ?p) T(?c_{2}, owl:someValuesFrom, ?y_{2}) T(?c_{2}, owl:onProperty, ?p) T(?y_{1}, rdfs:subClassOf, ?y_{2}) 
T(?c_{1}, rdfs:subClassOf, ?c_{2}) 
T(?c_{1},
owl:someValuesFrom, ?y) T(?c_{1}, owl:onProperty, ?p_{1}) T(?c_{2}, owl:someValuesFrom, ?y) T(?c_{2}, owl:onProperty, ?p_{2}) T(?p_{1}, rdfs:subPropertyOf, ?p_{2}) 
T(?c_{1}, rdfs:subClassOf, ?c_{2}) 
T(?c_{1},
owl:allValuesFrom, ?y_{1}) T(?c_{1}, owl:onProperty, ?p) T(?c_{2}, owl:allValuesFrom, ?y_{2}) T(?c_{2}, owl:onProperty, ?p) T(?y_{1}, rdfs:subClassOf, ?y_{2}) 
T(?c_{1}, rdfs:subClassOf, ?c_{2}) 
T(?c_{1},
owl:allValuesFrom, ?y) T(?c_{1}, owl:onProperty, ?p_{1}) T(?c_{2}, owl:allValuesFrom, ?y) T(?c_{2}, owl:onProperty, ?p_{2}) T(?p_{1}, rdfs:subPropertyOf, ?p_{2}) 
T(?c_{2}, rdfs:subClassOf, ?c_{1}) 
T(?x_{1}, rdf:first, ?c_{1})
T(?x_{1}, rdf:rest, ?x_{2}) T(?x_{2}, rdf:first, ?c_{2}) T(?x_{2}, rdf:rest, ?x_{3}) ... T(?x_{n}, rdf:first, ?c_{n}) T(?x_{n}, rdf:rest, rdf:nil) T(?c, owl:intersectionOf, ?x_{1}) 
T(?c, rdfs:subClassOf, ?c_{1}) T(?c, rdfs:subClassOf, ?c_{2}) ... T(?c, rdfs:subClassOf, ?c_{n}) 
T(?x_{1}, rdf:first, ?c_{1})
T(?x_{1}, rdf:rest, ?x_{2}) T(?x_{2}, rdf:first, ?c_{2}) T(?x_{2}, rdf:rest, ?x_{3}) ... T(?x_{n}, rdf:first, ?c_{n}) T(?x_{n}, rdf:rest, rdf:nil) T(?c, owl:unionOf, ?x_{1}) 
T(?c_{1}, rdfs:subClassOf, ?c) T(?c_{2}, rdfs:subClassOf, ?c) ... T(?c_{n}, rdfs:subClassOf, ?c) 
Let AXIOMS be a set containing all the implications listed in Section 4.3.2; let O be an OWLR DL ontology in which no URI is used both as an object and a data property; let F be a set of assertions of the following form:
Furthermore, let RDF(O) and RDF(F) be the translations of O and F into RDF graphs as specified in the RDF mapping [ OWL 2 RDF Mapping ] in which triples are represented using the T predicate. Then, the following relationship between consequences in OWLR DL and OWLR Full holds:
F is a consequence of O under the OWL 2 DL semantics if and only if RDF(F) is a consequence of RDF(O) ∪ AXIOMS under the standard firstorder semantics.
This section describes the computational complexity of important reasoning problems in the described profiles.
Note that in languages that are propositionally closed (i.e. that provide, either implicitly or explicitly, conjunction, union and negation of class descriptions), such as OWL 2 DL and OWL 2 Full, the problems of ontology consistency, concept satisfiability, concept subsumption and instance checking can be reduced to each other in polynomial time. However, none of the described profiles is propositionally closed, and these reasoning problems may thus have different complexity and require diferent algorithmic solutions.
This section describes the computational complexity of the most relevant reasoning problems in the languages introduced so far. The reasoning problems considered here are the following:
When evaluating the complexity, the following parameters will be
considered:
Table 6 summarizes the known complexity results for OWL 2 DL, OWL 1 DL, EL++, DLLite, and OWLR. Whenever the complexity for a given problem is described as Open, with a star, (*), it is meant that its decidability is still an open question; if the star (*) is omitted, then the problem is known to be decidable but precise complexity bounds have not yet been established.
Language  Reasoning Problems  Taxonomic Complexity  Data Complexity  Query Complexity  Combined Complexity 

OWL 2 DL  Ontology Consistency, Concept
Satisfiability, Concept Subsumption, Instance Checking 
2NEXPTIMEcomplete  Open (NPHard) 
Not Applicable  2NEXPTIMEcomplete 
Conjunctive Query Answering  Open*  Open*  Open*  Open*  
OWL 1 DL  Ontology Consistency, Concept
Satisfiability, Concept Subsumption, Instance Checking 
NEXPTIMEcomplete  Open (NPHard) 
Not Applicable  NEXPTIMEcomplete 
Conjunctive Query Answering  Open*  Open*  Open*  Open*  
Ontology Consistency, Concept
Satisfiability, Concept Subsumption, Instance Checking 
PTIMEcomplete  PTIMEcomplete  Not Applicable  PTIMEcomplete  
Conjunctive Query Answering  PTIMEcomplete  PTIMEcomplete  NPcomplete  PSPACEcomplete  
Ontology Consistency, Concept
Satisfiability, Concept Subsumption, Instance Checking, 
In PTIME  In LOGSPACE  Not Applicable  In PTIME  
Conjunctive Query Answering  In PTIME  In LOGSPACE  NPcomplete  NPcomplete  
Ontology Consistency, Concept
Satisfiability, Concept Subsumption, Instance Checking 
PTIMEcomplete  PTIMEcomplete  Not Applicable  PTIMEcomplete  
Conjunctive Query Answering  PTIMEcomplete  PTIMEcomplete  NPcomplete  NPcomplete 
In DLLite, instance checking and conjunctive query evaluation can be performed by exploiting relational database technology, i.e., through a translation to SQL queries. The fact that data complexity goes beyond LOGSPACE means that query answering and instance checking require more powerful engines than the ones provided by relational database technologies. PTIMEhardness essentially requires Datalog technologies. For the CoNP cases, Disjunctive Datalog technologies could be adopted.
Editor's Note: This appendix will contain the full grammars of each of the profiles. The grammar will be completed when the technical work on each of the profiles has been finished.