New Features &
Rationale
W3C Editor's Draft 21 November 2008
- This version:
- http://www.w3.org/2007/OWL/draft/ED-owl2-new-features-20081121/
- Latest editor's draft:
- http://www.w3.org/2007/OWL/draft/owl2-new-features/
- Authors:
- Christine
Golbreich, University of Versailles Saint-Quentin
- Evan K.
Wallace, NIST
- Vipul
Kashyap, Partners Health System, Inc.
- Contributors:
- Deborah
McGuinness, Rensselaer Polytechnic Institute
- Bijan
Parsia, The University of Manchester
Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
OWL 2 extends the W3C OWL Web Ontology Language
with a small but useful set of features that have been requested by
users, for which effective reasoning algorithms are now available,
and that OWL tool developers are willing to support. The new
features include extra syntactic sugar, additional property and
qualified cardinality constructors, extended datatype support,
simple metamodeling, and extended annotations.
This document is a simple introduction to the new features of the
OWL 2 Web Ontology Language, including an explanation of its
differences with respect to OWL 1. It also presents the
requirements that have motivated the design of the main new
features, and their rationale from a theoretical and implementation
perspective.
May Be Superseded
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 11 documents:
- Structural Specification and Functional-Style Syntax
- Direct Semantics
- RDF-Based Semantics
- Conformance and Test
Cases
- Mapping to RDF Graphs
- XML Serialization
- Profiles
- Quick Reference Guide
- New Features &
Rationale (this document)
- Manchester Syntax
- rdf:text: A Datatype for
Internationalized Text
Please Comment By 2008-11-25
The OWL Working Group seeks
public feedback on these Working Drafts. Please send your
comments to public-owl-comments@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 internal-review comments and changes being
drafted which may address your concerns.
No Endorsement
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.
Patents
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.
1 Overview
This document is an Overview of the main new features that have
been added to OWL 2 and of their rationale. These features are
based on real applications, user and tool developer experience,
much of which was documented and discussed as part of the OWLED Workshop Series. For each
new feature, the document informaly introduces its meaning, as
specified in the [Direct
Semantics] document, and also its syntax, as defined in the
[Syntax] document. It
provides an explanation of the fundamental reasons that have
motivated the design of these features, from a theoretical and
implementation perspective. Furthermore, each feature is
illustrated by simple examples from various applications, which are
referred in an Appendix including some Use Cases (among others)
that motivated these extensions. Finally, two synthetic tables
resume the links between the use cases, requirements, and examples
provided for illustration of the new features.
2 Features &
Rationale
OWL 2 is an update to OWL adding several new features, including
an increased expressive power - mainly w.r.t. properties, extended
support for datatypes, simple metamodelling capabilities, extended
annotation capabilities, database style keys. OWL 2 also defines
several profiles, OWL 2 language subsets that may better meet
certain performance requirements or may be easier to implement.
Thus, OWL 2 new features are presented in this document according
to the following categories:
- extra syntactic sugar to make some common statements easier to
say, e.g., the disjoint union of classes
- new constructs that increase the expressivity for properties,
e.g., qualified cardinality restrictions or property chain
inclusion, database style keys
- extended support for datatypes, e.g., data type restrictions
and facets for restricting a datatype to a subset of its
values
- simple metamodeling capabilities to express metalogical
information about the entities of an ontology
- extended annotations capabilities to annotate entities,
ontologies and also axioms
- other major innovations: declarations, new language profiles
(sublanguages).
All features are described according to a common pattern as
follows:
- a brief sentence explaining why the new feature is
required
- a feature description including: a short informal sentence
defining its meaning - with a link to the Semantics
document, followed by its syntax - with a link to the Syntax document
- and simple illustrative example(s) issued from the Use
Cases.
- the rationale from a theoretical and implementation
perspectives that led to the changes to OWL 1 seen in OWL 2.
- links to related use cases of the bibliography in the
Appendix.
Depending on his profile (e.g., user, theoretician, implementor)
the reader can focus on what he is more interested in this document
thanks to different buttons that allow to Hide and Show the
feature Examples, Theory or Implementation perspectives,
respectively.
2.1 Syntactic sugar
"Syntactic sugar" is a term for syntactic extensions that make a
language friendlier to users yet do not extend the expressivity of
the language. OWL 2 adds syntactic sugar to make some common
patterns easier to write. Among these are two new shorthands that
provide more concise ways to state disjointness among classes.
These shorthands are: DisjointUnion and DisjointClasses.
While OWL 1 provides means to define a set of subclasses as a
disjoint and complete covering of a superclass by using several
axioms, this cannot be done concisely. This feature has been
required as a shortcoming given the common use of such satements in
domain models.
- Feature
DisjointUnion defines a class as the union of other classes, all
of which are pair-wise disjoint. It is a shorthand for
owl:disjointWith statements used in combination with owl:unionOf to
define a complete superclass from a set of mutually disjoint
subclasses.
DisjointUnion :=
'DisjointUnion' '(' { Annotation }
Class ClassExpression ClassExpression { ClassExpression } ')'
Examples
| DisjointUnion(BrainHemisphere
LeftHemisphere RightHemisphere ) (UC#2) |
A BrainHemisphere is exclusively either a
LeftHemisphere or a RightHemisphere and cannot be
both a BrainHemisphere and a LeftHemisphere. |
| DisjointUnion(Lobe FrontalLobe
ParietalLobe TemporalLobe OccipitalLobe
LimbicLobe) (UC#1) |
A Lobe is exclusively either a FrontalLobe , a
ParietalLobe, a TemporalLobe, a OccipitalLobe
or a LimbicLobe and cannot be both of them. |
| DisjointUnion(AmineGroup
PrimaryAmineGroup SecondaryAmineGroup
TertiaryAmineGroup ) (UC#3) |
An AmineGroup is exclusively either a
PrimaryAmineGroup, a SecondaryAmineGroup or a
TertiaryAmineGroup and cannot be both of them. |
| DisjointUnion(CarDoor FrontDoor RearDoor
TrunkDoor) (UC#4) |
A CarDoor is exclusively either a FrontDoor, a
RearDoor or aTrunkDoor and not both of them. |
- Theoretical Perspective
Since DisjointUnion is simply a shorthand for several
disjointWith statements in combination with unionOf, it does
not change the expressiveness, semantics, or complexity of the
language.
- Implementation Perspective
Being syntactic sugar, it's possible to take an ontology that is
OWL 1 except for DisjointUnion and preprocess it into an equivalent
OWL 1 ontology without DisjointUnion. Implementations, however, may
prefer to take special notices of DisjointUnion for more efficient
loading reasons.
- Use cases
Use Case #1 Use Case #2 Use Case #3 Use Case #4
While OWL 1 provides means to state that two subclasses are
disjoint, stating that several subclasses are pair-wise disjoint
cannot be done concisely. This shortand has been required given the
common use of such disjointness statements by many
applications.
- Feature
DisjointClasses states that all classes from the set are
pair-wise disjoint. several owl:disjointWith It is a shorthand for
several owl:disjointWith statements to define a set of mutually
disjoint subclasses.
DisjointClasses :=
'DisjointClasses' '(' { Annotation
} ClassExpression ClassExpression { ClassExpression } ')'
Examples
| DisjointClasses( LeftLung RightLung
) (UC#2) |
Nothing can be both a Leftlung and a
RightLung. |
| DisjointClasses( UpperLobeOfLung
MiddleLobeOfLung LowerLobeOfLung ) (UC#2) |
UpperLobeOfLung MiddleLobeOfLung
LowerLobeOfLung are pairwise exclusive. |
Note : The FMA exhibit a huge number of such classes [4 C]:
3736 classes of template Left X vs Right X (e.g. Left lung
vs Right lung) 13989 classes of template X left Y vs X right
Y (e.g. Skin of right breast vs Skin of left breast) 25 classes
with template Male X vs Female X (e.g. Male breast vs
Female breast) 75 classes X male Y vs X female Y (e.g.
Right side of male chest vs Right side of female chest)
- Theoretical Perspective
Since DisjointClasses is simply a shorthand for several
disjointWith statements it does not change the
expressiveness, semantics, or complexity of the language.
- Implementation Perspective
Being syntactic sugar, it's possible to take an ontology that is
OWL 1 except for DisjointClasses and preprocess it into an
equivalent OWL 1 ontology without DisjointClasses. Implementations,
however, may prefer to take special notices of DisjointClasses
since the terseness and "groupiness" make for more efficient
loading.
- Use cases
Use Case #1 Use Case #2
While OWL 1 provides means to assert values of a property for an
individual, asserting that a property has not some values is
impossible. This requires the ability to assert facts about an
individual stating property values that it does not have.
- Feature
OWL 2 provides the shortands
NegativeObjectPropertyAssertion and
NegativeDataPropertyAssertion for asserting negative facts.
While an ObjectPropertyAssertion (resp.
DataPropertyAssertion) axiom states that a given property
holds for the given individuals, a
NegativeObjectPropertyAssertion (resp.
NegativeDataPropertyAssertion) axiom states that a given
property does not hold for the given individuals.
NegativeObjectPropertyAssertion :=
'NegativePropertyAssertion' '(' { Annotation } objectPropertyExpression sourceIndividual targetIndividual ')'
NegativeDataPropertyAssertion :=
'NegativePropertyAssertion' '(' { Annotation } DataPropertyExpression sourceIndividual targetValue ')'
Examples.
| NegativePropertyAssertion( livesIn
ThisPatient IledeFranceDistrict ) (UC#9) |
ThisPatient does not live in the
IledeFranceDistrict . |
| NegativePropertyAssertion( hasAge
ThisPatient 5^^xsd:integer ) (UC#9) |
ThisPatient is not five years old. |
- Theoretical Perspective
Since NegativePropertyAssertion is simply a shorthand it
does not change the expressiveness, semantics, or complexity of the
language.
- Implementation Perspective
Being syntactic sugar, it's possible to take an ontology that is
OWL 1 except for NegativePropertyAssertion and preprocess it into
an equivalent OWL 1 ontology without it.
- Use cases
Use Case #9
2.2 New constructs for
Properties
OWL 1 was mainly focused on constructs for expressing
information about classes and individuals, but paid less attention
to properties. OWL 1 exhibited some weakness regarding
expressivenes for properties. OWL 2 addresses it by complementing
OWL 1 with new constructs that increase the expressivity of the
language for properties, as requested by many users. OWL 2 offers
new constructs for expressing additional restrictions on
properties, new characteristics of properties, incompatibility of
properties, properties chains and key properties.
OWL 1 does not allow to define subclasses of objects that are
related to themselves by a given property, for example the subclass
of processes that auto-regulate themselves. Expressing this
requires local reflexivity.
- Feature
OWL 2 allows to assert restrictions on object properties by
means of the new construct HasSelf. The class expression
ObjectHasSelf defined using an
HasSelf restriction on an object property denotes the class
of all objects that are related to themselves via the given object
property. It can be viewed as a kind of local reflexivity
quality of the object property. [Syntax]
[Semantics]
ObjectHasSelf := 'HasSelf'
'(' ObjectPropertyExpression
')'
Examples.
| SubClassOf( AutoRegulatingProcess HasSelf(
regulate) ) |
Auto-regulating processes regulate themselves. |
| SubClassOf( RingMolecule HasSelf(
connectedTo)) (UC#3) |
Biochemical ring molecules are connectedTo
themselves. |
- Theoretical Perspective
The description logic underlying OWL-DL is SHOIN. OWL 2 is based
on a more expressive description logic: SROIQ [SROIQ]. SROIQ extension of SHOIN
was designed to provide all possible useful additions to OWL-DL
that were requested by users, while not affecting its decidability
and practicability. SROIQ logic extends SHOIN with reflexive,
asymmetric, and irrelexive roles, disjoint roles, a universal role,
and constructs ∃ R.Self. It also allows qualified number
restrictions and negated role assertions in Aboxes.
Additionaly, SROIQ offers complex role inclusion axioms of the
form R ◦ S < R or S ◦ R < R to express propagation of one
property along another one, which have proven to be very useful in
particular for biomedical ontologies (see F8: Property
chain inclusion).
- Implementation Perspective
Local reflexivity is already supported by existing tools, e.g.,
FACT++. According to developpers, local reflexivity was relatively
easy to implement [TOOLS] – for any individual x that must have a
relationship along a reflexive property, an appropriately labelled
edge <x, x> has been added to the model.
- Use cases
Use Case #5 Use Case #3
2.2.2 F5: Qualified
cardinality
While OWL 1 allows for the definition of persons that have at
least three children, specifying the subclass of persons that have
at least three children that are Girls is impossible. Expressing
the latter class requires the qualification of the target of the
property hasChildren (atleast 3 hasChildren
Girl).
- Feature
OWL 2 allows to assert minimum, maximum or exact qualified
cardinality restrictions on object or data properties by means of
the new constructs MinCardinality MaxCardinality
ExactCardinality. A qualified cardinality restriction (QCR)
defines a restriction on the number of instances of the property
and on its class or data range. The addition that qualified
cardinality restriction brings to the initial OWL 1 constructs for
cardinality restrictions is to allow defining restrictions not only
on the number of instances of the property but also on the class
or data range of the instances. In OWL 2, both qualified
or unqualified cardinality restrictions are possible. An
unqualified cardinality restriction is simply equivalent to a
qualified one where the restricting class is owl:Thing. [Syntax]
[Semantics]
The class expressions ObjectMinCardinality, ObjectMaxCardinality, and ObjectExactCardinality defined using a
MinCardinality, MaxCardinality or
ExactCardinality restriction on an object property denotes
the set of objects that are connected via the given object property
to at least, at most, or exactly the given number of individuals of
the given class.
ObjectMinCardinality :=
'MinCardinality' '(' nonNegativeInteger ObjectPropertyExpression [ ClassExpression ] ')'
ObjectMaxCardinality :=
'MaxCardinality' '(' nonNegativeInteger ObjectPropertyExpression [ ClassExpression ] ')'
ObjectExactCardinality :=
'ExactCardinality' '(' nonNegativeInteger ObjectPropertyExpression [ ClassExpression ] ')'
Examples.
The following examples are some examples of Object Property
Cardinality Restrictions from Use Cases among many in HCLS.
| ExactCardinality( 1 hasDirectPart
FrontalLobe ) (UC#1) |
Class of objects having exactly one direct part of type
frontal lobe. |
| MinCardinality( 5 hasDirectPart
owl:Thing ) |
Class of objects having at least 5 direct part. |
While in OWL 1 it was only possible to express that a Brain
Hemisphere has at least 5 direct part but not that it has exactly
one direct part of each type: frontal, parietal,
temporal, occipital, limbic lobe, as needed in UC#1),
both statements are possible in OWL 2 (see above).
| MaxCardinality( 3 boundedTo
Hydrogen) (UC#3) |
Class of objects bounded to at most three different
Hydrogen |
| MaxCardinality( 5 hasPart Door )
(UC#4) |
Class of objects having atmost 5 Door |
| ExactCardinality( 2 hasPart RearDoor
) (UC#4) |
Class of objects having exactly 2 RearDoor |
DataMinCardinality :=
'MinCardinality' '(' nonNegativeInteger DataPropertyExpression [ DataRange ] ')'
DataMaxCardinality :=
'MaxCardinality' '(' nonNegativeInteger DataPropertyExpression [ DataRange ] ')'
DataExactCardinality :=
'ExactCardinality' '(' nonNegativeInteger DataExactCardinality [ ClassExpression ] ')'
Examples.
| MaxCardinality( 1 hasSSN ) |
Each individual has at most one Social Security Number |
- Theoretical Perspective
As already said above, qualified cardinality restrictions are
present in the SROIQ description logic underlying OWL 2 since they
were required in various applications e.g.; [Medical Req] [Little Web] and did not pose
theoretical or practical problems to be added [SHOIQ]. It was known from a long
time that resulting logic is decidable and QCR was already
supported by DAML+OIL, the predecessor of OWL 1.
- Implementation Perspective
QCRs do not pose implementation problem either. It has been
successfully implemented both in earlier editor, e.g.; OilED, and
reasoner, e.g., FACT++, that already processed ontology with QCRs,
before OWL 1 recommendation. Current versions of tools under
development for OWL 2, e.g.; Protégé 4, FACT++, PELLET, RACER,
KAON2 also deals with QCRs [TOOLS] [OWL
API].
- Use cases
Use Case #1 Use Case #2 Use Case #3, Use Case #4 Use Case #8
While OWL 1 allows to assert that an object property is
symmetric or transitive, it is impossible to assert that it is
refelexive, irreflexive or assymetric. In mereology, the
partOf relation is defined 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 antisymmetric (if an object as a
part which in turn has part itself, then they are the same). Many
applications, particularly those where it is necessary to describe
complex structures such as life science applications, require
extensive use of part-whole relations, axiomatized according to
these principles. Similarly, other relations encountered in
ontology modeling require similar axiomatizations, possibly with
different sets of characteristics (see, e.g., [OBO] [RO]). Examples include proper part of and locative
relations (typically transitive and irreflexive), causal relations
(typically transitive and irreflexive) and membership relations
(typically irreflexive). Thus as illustrated by many use cases new
charactersitics of properties is a strong requirement to assert
characteritsics of Reflexivity, Irreflexivity, Asymmetry for an
object property.
2.2.3.1 Reflexive
Property
- Feature
A reflexivity axiom asserts that a given object property is
reflexive that is, the property holds for all the individuals, or
in mathematical notation, this is:
∀x x R x
[Syntax]
[Semantics]
ReflexiveObjectProperty :=
'ReflexiveProperty' '(' { Annotation } ObjectPropertyExpression ')'
Examples.
| ReflexiveProperty( sameBloodGroup )
(UC#9) |
Everybody has the same blood group as himself. |
| ReflexiveProperty( part_of )
(UC#2) |
Everything is part_of itself |
Note: there are different interpretations of the mereological
relations. For example OBO (Use Case #5) states that part_of is reflexive
while Use Case #1 states that the merological relation
anatomicalPartOf between anatomical entities is
irreflexive.
2.2.3.2 Irreflexive
Property
An irreflexivity axiom asserts that a given property is
irreflexive, that is the property does not hold for any individual,
or in mathematical notation, this is:
∀x ¬ (x R x)
[Syntax]
[Semantics]
IrreflexiveObjectProperty :=
'IrreflexiveProperty' '(' { Annotation } ObjectPropertyExpression ')'
Example
| IrreflexiveProperty( proper_part_of )
(UC#5) |
Nothing can be proper_part of itself. |
| IrreflexiveProperty( boundedBy )
(UC#1) |
Nothing can be bounded by itself. |
| IrreflexiveProperty( flowsInto
)(UC#6) |
Nothing can flow into itself. |
Note: the given examples corresponds to the statements about
mereological and topological properties anatomicalPartOf
boundedBy in the given Use Cases, e.g.; Use Case #1. But other applications may use these
terms for properties with different characteristics.
2.2.3.3 Asymmetric
Property
An assymetry axiom asserts that a given property is assymetric
that is, if the property holds between individuals x and y, then it cannot
hold between y and x, or in mathematical notation, this is:
∀x ∀y (x R y) ⇒ ¬ (y R
x)
[Syntax]
[Semantics]
AsymmetricObjectProperty :=
'AsymmetricProperty' '(' { Annotation } ObjectPropertyExpression ')'
Examples
| AsymmetricProperty( proper_part_of
)(UC#8) |
The property proper_part_of is asymmetric. |
see F4 Theoretical Perspective above
- Implementation Perspective
This was similar to the approach taken to support local
reflexivity, and was relatively straight forward. Implementation of
the algorithms for irreflexive and asymmetric properties is based
on the previously implemented extensions for local reflexivity and
disjoint properties, and essentially 'came for free'.
[TOOLS]
- Use cases
Use Case #5 Use Case #6 Use Case #8
While OWL 1 provides means to state the disjointness of classes,
it is impossible to state that properties are disjoint, that is OWL
1 does not provide means to assert that if the same pair of
individuals is related by two different properties among a given
set of properties, then the ontology is inconsistent.
- Feature
OWL 2 provides the new construct DisjointProperties for
asserting that several properties are incompatible (exclusive).
A disjoint properties axiom takes a set of object properties and
states that all properties from the set are pair-wise disjoint;
that is, no pair of individuals can at the same time be connected
by two different properties of the set. [Syntax]
[Semantics]
DisjointObjectProperties :=
'DisjointProperties' '(' { Annotation } ObjectPropertyExpression ObjectPropertyExpression { ObjectPropertyExpression } ')'
Examples
| DisjointProperties( connectedTo
contiguousTo ) (UC#1) |
connectedTo and contiguousTo properties are
exclusive |
Note: According to the definition of these properties in
Use Case #1, when two anatomical entities are linked
via an actual third anatomical entity, they are stated to be
connected. On the opposite, when they are not related by an actual
entity but are adjacent via a conventional entity,
they are said to be contiguous. Consequently, two parts
cannot be at the same time connected and contiguous.
- Theoretical Perspective
see F4 Theoretical Perspective above
- Implementation Perspective
In FACT++, the processing of disjoint properties was split into
static and dynamic parts. A dynamic analysis is applied to nodes
that are merged during the reasoning process, and all other cases
are handled by static analysis [TOOLS].
- Use cases
Use Case #1 Use Case #2 Use Case #3
OWL 1 does not provide means to define properties as a
composition of other properties. OWL 1 enables only the propagation
of values via one property in asserting it transitive, but does not
provide means to propagate a property (e.g.; isLocatedIn)
along another property (e.g.; partOf), which is a very
common requirement, specially in Life Sciences. Users cannot define
properties as a chain of relations (as hasUncle).
- Feature
OWL 2 allows to chain several object properties by means of the
new construct PropertyChain.
A propertyExpressionChain
expression defines a chain between several object properties by
means of PropertyChain. [Syntax]
[Semantics]
propertyExpressionChain :=
'PropertyChain' '(' ObjectPropertyExpression ObjectPropertyExpression { ObjectPropertyExpression } ')'
When used together with SubPropertyOf,
an expression defined by PropertyChain
provides a means to represent some types of rules. It allows in
particular to express the propagation of one property along another
property, e.g.; the propagation of a property from parts to whole,
which is a very common requirement, specially in Life Sciences.
However, the ontology set of axioms (involving SubObjectPropertyOf
axioms with Property Chains) must satisfy some
"Global Restrictions" in order to prevent cyclic definitions
and to keep the language decidable.
In short, an axiom SubPropertyOf(
PropertyChain( p1 ... pn ) p ) states
that if an individual x is connected with
an individual y by a chain of object
properties p1, ...,
pn, then x is also connected with y
by the object property p. Such axioms are
also known as complex role inclusions [SROIQ]. The full exact syntax of
Property
chain inclusion axioms is more precisely the following:
propertyExpressionChain :=
'PropertyChain' '(' ObjectPropertyExpression ObjectPropertyExpression { ObjectPropertyExpression } ')'
subObjectPropertyExpression :=
ObjectPropertyExpression |
propertyExpressionChain
SubObjectPropertyOf :=
'SubPropertyOf' '(' { Annotation }
SubObjectPropertyExpression
ObjectPropertyExpression ')'
Examples
| SubPropertyOf( PropertyChain( locatedIn
partOf ) locatedIn ) (Ax26) |
If x is locatedIn y, and y is partOf
z, then x is
locatedIn z; for example a disease
located in a part is located in the whole. |
- Theoretical Perspective
OWL 2 is based on SROIQ which offers complex role inclusion
axioms that include axioms of the form R ◦ S < R or S ◦ R < R
to express propagation of one property along another one, which
have proven to be very useful in particular for biomedical
ontologies(see R8:
Property chain inclusion). SROIQ allows also complex axioms of
the form S1 ◦ S2 ◦ ,..., ◦ Sn < R under a certain condition of
Regularity that prevents a role hierarchy from containing
cyclic dependencies.
An OWL 2 PropertyChain expression used
within a SubPropertyOf axiom provides a
means to represent some types of rules while remaining decidable
under special restrictions that is, provided that the
Global Restrictions on Axioms given Section 11 of the Syntax document
are respected by the properties defined in the ontology.
- Implementation Perspective
The most challenging aspect of implementing an OWL 2 reasoner,
was the implementation of property chain inclusion axioms. Several
optimisations were necessary to ensure acceptable reasoner
performance [TOOLS].
To conclude: Current versions of tools under development for OWL
2, e.g.; Protégé 4, FACT++, PELLET, RACER, deals with all the
features above [TOOLS] [OWL
API]. In terms of extending existing OWL 1.0 reasoners
and editing tools to cope with OWL 2, it has been found that the
effort required to implement such extensions was perfectly
acceptable, and minimal in comparison to the task of developing
such tools from scratch [TOOLS].
- Use Cases
Use Case #1 Use Case #5 Use Case #7 Use Case #8
OWL 1 does not provide means to define keys. However, keys, aka
inverse functional datatype properties (but limited to named
individuals), are clearly of vital importance to many applications
in order to uniquely identify individuals of a given class by
values of (a set of) key properties.
- Feature
OWL 2 allows to define Database style keys for a given class by
means of the new construct HasKey. A HasKey axiom states that each named instance
of a class is uniquely identified by a (data or object) property or
a set of properties that is, if two (named) instances of the class
coincide on all the values of key properties, then these two
individuals are the same. [Syntax]
[Semantics]
HasKey := 'HasKey' '(' {
Annotation } ClassExpression ObjectPropertyExpression | DataPropertyExpression { ObjectPropertyExpression | DataPropertyExpression } ')'
| HasKey( a:RegisteredPatient
a:hasWaitingListN ) |
Each registered patient [on the
ABM national organ waiting list], is uniquely identified by his
waiting list number (UC#9) |
| ClassAssertion( a:RegisteredPatient
a:ThisPatient ) |
a:ThisPatient is an instance of
a:RegisteredPatient. |
| PropertyAssertion( a:hasWaitingListN
a:ThisPatient "123-45-6789" ) |
a:ThisPatient has the number "123-45-6789" on the
waiting list. |
In this example, since a:hasWaitingListN is the key for
the class a:RegisteredPatient, the number "123-45-6789"
uniquely identifies a:ThisPatient. The axiom HasKey(
a:RegisteredPatient a:hasWaitingListN ) does not
state that each registered patient has at least one value of
a:hasWaitingListN, but only that two different patients who
have got a number assigned cannot have the same number on the
waiting list: if the values of a:hasWaitingListN were the
same for two instances of RegisteredPatient, these two individuals
would be equal.
| HasKey( a:Transplantation a:donorId
a:recepientId a: ofOrgan ) |
Each Transplantation is uniquely identified by a donor, a
recipient, and an organ (UC#9) |
A set of several properties is needed to identify a
transplantation: a donor may provide several organs, e.g., a kidney
and a liver, to a single person, or the same organ, e.g., a kidney,
to two recipients, or different organs to different recipients.
- Theoretical Perspective
Keys in general have the following properties [Easy
Keys]:
- Missing key values raise an error (optional)
- Functionality constraints on keys (optional)
- If X and Y have the same key values, then X=Y.
The first feature is not expressible directly in first order
logic. The second feature, Functionality, can be expressed
in OWL (both for data and object properties). The third feature, in
its general form, can lead to unfeasibly difficult reasoning in OWL
(given what is currently known and anticipated). However, a more
restricted form limited to named individuals, can be expressed in
first order logics as a DL Safe rule e.g., the following DL safe
rule expresses that keyProperty (whatever data or object
property) is a key property:
keyProperty(X, Z), keyProperty(Y, Z) implies X = Y.
(for more details see
Semantics for Key)
- Implementation Perspective
DL-safe rules can be added to description logic reasoners
without major problems. This, for example, has been done in KAON2,
and KAON2 has been successfully applied to a number of practical
problems. Furthermore, DL-safe rules can be easily added to the
hypertableau reasoning approach implemented in the HermiT reasoner.
Since keys can be expressed as DL-safe rules, they can, as a
consequence, be easily implemented in the main-stream OWL
reasoners.
- Use cases
Use Case #2 Use Case #7 Use Case #9
2.3 Extended datatypes
capabilities
2.3.1 F10: Unary Datatype
- OWL 1 provides very limited expressive power for concrete
values, such as integers and strings. The datatypes are modeled
after XML Schema, which provides a rich set of datatypes; however,
only xsd:string and xsd:integer are normative (in OWL DL), which is
often not sufficient for applications.
- Furthermore, in OWL 1 it is possible to express restrictions on
datatype properties qualified by a unary datatype. For example, one
could state that every French citizen has a Passeport Number which
is an xsd:string. But it is not possible to restrain the range of a
datatype. For example, one could not say that adults have an age
greater than 18 years, that pressure is in the range of 1030mb to
1035mb. As illustrated by the use cases below, datatype
restrictions have been required by many users to allow such
statements.
- Feature
OWL 2 provides new capabilities for unary datatypes, supporting
a richer set of datatypes and also facets for restricting the range
of built-in datatypes:
- OWL 2 datatypes allow representing a) various kinds of numbers, e.g.,
integer, real, double, float, decimal, both adding support of a
wider range of XML Schema Datatypes (double, float, decimal,
positiveInteger etc.) and providing special datatypes e.g.,
owl:real b) strings with
(or without) a Language Tag (using the rdf:text datatype) c)
Boolean values, Binary Data, URIs, Time Instants, etc. Syntax
- It is possible to specify restrictions on datatypes by means of
facets that restrain the range of values allowed for a given
unary datataype. Constraining facets used in a
DatatypeRestriction are one of the allowed facets defined in
the Datatype
Maps section, e.g., length, minLength, maxLength, pattern,
minInclusive, minExclusive, maxInclusive, maxExclusive. They are
denoted by an URI. The restriction value used in a
DatatypeRestriction is a literal listed in the Datatype
Maps section. Syntax
Semantics.
DatatypeRestriction :=
'DatatypeRestriction' '(' Datatype
constrainingFacet restrictionValue { constrainingFacet restrictionValue } ')'
Examples
| DatatypeRestriction(xsd:integer minInclusive 18)
(UC#9) |
new datatype with a lower bound of 18 on the XML Schema
datatype xsd:integer |
This datatype is needed for example to define patients under 18
(child) who depend on pediatric services at hospital while over 18
(adult) depend on adult services.
- Theoretical Perspective
See OWL Datatypes: Design and Implementation [Datatype].
- Use Cases
Use Case #9 Use Case #11 Use Case #12 Use Case #18 Use Case #19
Editor's Note:
Status of N-ary is not yet decided -should be updated according to
WG decisions
2.3.2 F11: N-ary datatype
In OWL 1 it is not possible to represent relationships between
values for one object, e.g., a square is a rectangle whose length
equals width (nor relationships between values for different
objects e.g., people who are older than their boss); N-ary
datatypes have been required by users to allow such statements, for
example in the use cases listed below.
- Feature
OWL 2 extends the unary datatypes of OWL 1 to n-ary datatypes,
allowing to compare values of data properties for a given object,
for example the admisssion temperature of a patient to his current
temperature. It allows more generally to use n-ary datatypes such
as those built from linear expressions.
Examples
| AllValuesFrom( admissionTemperature
currentTemperature inferior) (UC#11) |
individuals whose admissionTemperature is inferior to
currentTemperature. |
N-ary can be used to compare values of data properties for a
single given object e.g., in any patient, the systolic blood
pressure is always greater or equal than the diastolic blood
pressure. They cannot be used to compare values of data properties
for different objects (e.g., defining the class of
individuals whose body weight is superior than their mother's)
which leads to undecidability.
- Implementation Perspective
These features are already supported by popular existing tools,
e.g. facets were already supported by Protégé editor supported
before, and e.g., Pellet reasoner supports reasoning with all the
built-in datatypes defined in XML Schema plus any user-defined data
ranges that extend numeric or date/time derived types.
- Use Cases
Use Case #10 Use Case #11
2.4 Simple metamodeling
capabilities
2.4.1 F12: Punning
For a class Eagle of individuals it might be wanted to represent
the two following different statements:
- Metadata (metalogical information) about the class Eagle that
would say that class Eagle was created by "C. Welty" in 1994, ID.
This was already possible in OWL 1 and is still possible in OWL 2
by means of entity annotation (annotating the entity Eagle using
annotationProperties creator with value C. Welty, and
year with value 1994).
- Statement about the Eagle specy as a whole, expressing that
"eagles are listed in the IUCN Red List that is, Eagle denoting an
individual of the RedListSpecies class. RedListSpecies is then a
metaclass. Modeling with metaclasses is commonly called
metamodelling.
In some applications, one would simply like to use the same term
(name) for a class (e.g., Eagle viewed as a class) and for an
instance (e.g., Eagle viewed as an individual of the Red List of
species), whithout needing to have whole the inferences power of
metamodelling. For example, a biomedical application may simply
like to have a colummn in a database which data are names of gene
classes, another one which data are molecular functions, e.g.;
imported from the Gene Ontology. Such simple metamodelling
capabilities is a common requirement in applications.
- Feature
OWL 2 provides a simple form of metamodelling based on punning,
that is the same name can be used for different types of entities,
with certain restrictions, more percisely:
- the name used for an individual can also be used for a class,
datatype, object property, data property or annotation
property
- the name used for a class or a datatype can also be used for an
individual, object property, data property or annotation
property
- the name used for an object property or data property or
annotation property can also be used for an individual, class or
datatype
The same name cannot be used for an ObjectProperty and an
DatatypeProperty or for a Class and a Datatype.
Examples
| Declaration( Class( a:Person ) )
(UC#13) (1) |
a:Person is declared to be a class |
| ClassAssertion( a:Service a:s1 )
(2) |
a:s1 is an individual of a:Service. |
| PropertyAssertion( a:hasInput a:s1
a:Person )(3) |
the individual a:s1 is connected by a:hasInput to
the individual a:Person. |
The same term 'Person' denotes both a class in (1) and an
individual in (3). This is possible in OWL 2 thanks to
punning (Class ↔ Individual).
- Collaborative environment (Wiki)
| Declaration( Class( a:Deprecated_Properties
) ) (UC#14)(1) |
a:Deprecated_Properties is declared to be a
Class |
| Declaration( ObjectProperty(
a:is_located_in ) ) (2) |
a:is_located_in is declared to be an
ObjectProperty |
| ClassAssertion( a:Deprecated_Properties
a:is_located_in ) (3) |
a:is_located_in is an individual of
a:Deprecated_Properties. |
The same term 'is_located_in' denotes both a property (2) and an
individual (3). This is possible in OWL 2 thanks to punning
(Property ↔ Individual).
Use Case #14 should also have been represented without
metamodelling, with an annotation deprecated property on the
property a:is_located_in.
| Declaration( Class( a:Person ) )
Declaration( Class( a:Company ) ) (UC#15) (1) |
a:Person and a:Company are declared to be
classes. |
| SubClassOf ( a:PersonCompany a:
Association) )(2) |
a:PersonCompany denotes a subclass of an a:
Association associating Person and Company. |
| PropertyDomain( a:PersonCompany
a:Person )(3) |
The domain of the property a:PersonCompany is
a:Person. |
| PropertyRange( a:PersonCompany
a:Company )(4) |
The range of the property a:PersonCompany is
a:Company. |
The same term a:PersonCompany denotes both a class (2)
and an ObjectProperty(3 ; 4). This is possible in OWL 2 thanks
to punning (Class ↔ObjectProperty).
- Theoretical Perspective
According to OWL 1 Direct
Model-Theoretic Semantics:
- (i) the vocabulary VC of classes names and VD of datatypes
names are disjoint that is, the same name (URI) cannot be used for
a class and a datatype;
- (ii) the vocabularies VDP of data property names, VIP of object
property names, VAP of annotation property names, (plus VOP the set
of URI references for the built-in OWL ontology properties) are
pairwise disjoint thats is, the same name cannot be used for a data
property, an object property and an annotation property.
Besides, in order to retain decidability OWL DL imposed
additional conditions on the vocabulary:
- (iii) the sets VC of classes names and VIP of object property
names and the set of individuals names are disjoint that is, the
same name cannot be used for a property or a class and an
individual.
In other words, metamodelling was not supported by OWL DL. On
the opposite, OWL full did not impose this resctriction, but the
style of metamodelling adopted in OWL full led to
undecidability.
In OWL 2, following the proposal of simple [Metamodelling] based on punning,
conditions (iii) have been relaxed while retaining decidability.
Below the list of punning (at this time) allowed in OWL 2.
In the following
X | Y
Z | W
should be interpreted as "a URI u used as an object of type X or
Y can also be used as an object of type Z or W"
class | datatype | object property | data property | annotation
property
individual | object property | data property | annotation
property
- object property | data property | annotation
property:
individual | class | datatype
Punning ObjectProperty ↔ DatatypeProperty and Class ↔ Datatype
is forbidden, that is the same name cannot be used for and
ObjectProperty and a DatatypeProperty or for a Class and a
Datatype.
- Implementation Perspective
Punning presents absolutely no problem for reasoning algorithms
and can be implemented with minimal effort.
- Use Cases
Use Case #12 Use
Case #13 Use Case #14 Use
Case #15
2.5 Extended annotations
OWL 1 allows to associate (metalogical) information, such as a
label or a comment, like a textual description of the entity, to
each ontology entity. But it is also useful to associate
metalogical information to axioms. For example, one might want to
keep information about who asserted an axiom or when. Therefore, it
has been required to have extended annotations that allow for the
annotation of both entities and axioms.
- Feature
- OWL 2 provides for annotations on ontologies, entities (such as
a class or individual, including anonymous individuals), and
axioms. Even annotations of annotations are possible. Annotations
however, have no semantic meaning in OWL 2.
- An annotation consists of an annotation property and a value
for the annotation. The value of an annotation can be either a
literal (e.g., string, integer, or any other OWL datatype), an URI,
or an anonymous individual.
- There are only three axioms that can be used on annotation
properties: AnnotationPropertyDomain, AnnotationPropertyRange, and
SubAnnotationPropertyOf axioms. These special annotation axioms
have no semantics in OWL DL, but the normal semantics in OWL Full
via their mapping to the standard RDF vocabulary. Syntax
Below extracts of the syntax used for the annotation of URIs and
of SubClassOf axioms respectively as exemplified in the following
examples (for the complete syntax see Annotations
in the Syntax document):
Annotation := AnnotationByLiteral | AnnotationByURI | AnnotationByAnonymousIndividual
uriAnnotations :=
Annotation { Annotation }
URIAnnotation :=
'URIAnnotation' '(' axiomAnnotations URI uriAnnotations ')'
subClassExpression :=
classExpression
superClassExpression :=
classExpression
axiomAnnotations := {
Annotation }
SubClassOf := 'SubClassOf'
'(' axiomAnnotations subClassExpression superClassExpression ')'