Abstract Syntax for OWL

Abstract Syntax for OWL
previous
next
top
contents
OWL Web Ontology Language
Semantics and Abstract Syntax
Section 2. Abstract Syntax
Editors:
Peter F. Patel-Schneider
Bell Labs Research, Lucent Technologies
Ian Horrocks
Department of Computer Science, University of Manchester
Please refer to the
errata
for this document, which may include some normative corrections.
See also
translations
© 2004
W3C
®
MIT
ERCIM
Keio
), All Rights Reserved. W3C
liability
trademark
document
use
and
software
licensing
rules apply.
Contents
2.1
Ontologies
2.2
Facts
2.3
Axioms
2.3.1
OWL Lite Axioms
2.3.1.1
OWL Lite Class Axioms
2.3.1.2
OWL Lite Restrictions
2.3.1.3
OWL Lite Property Axioms
2.3.2
OWL DL Axioms
2.3.2.1
OWL DL Class Axioms
2.3.2.2
OWL DL Descriptions
2.3.2.3
OWL DL Restrictions
2.3.2.4
OWL DL Property Axioms
2. Abstract Syntax (Normative)
The syntax for OWL in this section abstracts from exchange syntax for OWL and
thus facilitates access to and evaluation of the language. This
particular syntax has a frame-like style, where a collection of information
about a class or property is given in one large syntactic construct,
instead of being divided into a number of atomic chunks (as in most
Description Logics) or even being divided into even more triples (as when
writing OWL as
RDF
graphs
RDF Concepts
]).
The syntax used here is rather informal, even
for an abstract syntax - in general the arguments of a construct should be
considered to be unordered wherever the order would not affect the meaning
of the construct.
The abstract syntax is specified here by means of a version of Extended
BNF, very similar to the
EBNF notation
used for XML [
XML
].
Terminals are quoted; non-terminals are bold and not quoted.
Alternatives are either separated
by vertical bars (|) or are given in different productions. Components that
can occur at most once are enclosed in square brackets ([…]);
components that can occur any number of times (including zero) are enclosed
in braces ({…}).
Whitespace is ignored in the productions here.
Names in the abstract syntax are
RDF URI references
RDF Concepts
].
Often these names will be abbreviated into qualified names, using one of
the following namespace names:
Namespace name
Namespace
rdf
rdfs
xsd
owl
The meaning of each construct in the abstract syntax is informally described when
it is introduced.
The formal meaning of these constructs is given in
Section 3
via a model-theoretic semantics.
While it is widely appreciated that all of the features in expressive
languages such as OWL are important to some users, it
is also understood that such languages may be daunting to some groups
who are trying to support a tool suite for the entire language. In
order to provide a simpler target for implementation, a
smaller language has been defined, called
OWL Lite
OWL Overview
]. This
smaller language was designed to provide functionality that is important in
order to support Web applications, but that is missing in
RDF Schema [
RDF Schema
].
(Note, however, that both OWL DL and OWL Lite do not provide all of the
feature of RDF Schema.)
The abstract syntax is expressed both for this smaller language,
called the OWL Lite abstract syntax here,
and also for a fuller style of OWL,
called the
OWL DL
abstract syntax here.
The abstract syntax here is less general than the exchange syntax for OWL. In
particular, it does not permit the construction of self-referential
syntactic constructs. It is also intended for use in cases where classes,
properties, and individuals form disjoint collections. These are roughly
the limitations required to make reasoning in OWL be decidable, and thus
this abstract syntax should be thought of a syntax for OWL DL.
NOTE:
OWL Lite and OWL DL closely correspond to the
description logics known as SHIF(D) and SHION(D), with some limitation
on how datatypes are treated. The abstract syntax for OWL Lite doesn't
contain many of the common explicit constructors associated with
SHIF(D), but the expressivity remains.
2.1. Ontologies
An OWL ontology in the abstract syntax contains a sequence of
annotations,
axioms, and facts.
OWL ontologies can have a name.
Annotations on OWL ontologies
can be used to record authorship and other
information associated with an ontology, including
imports references to other ontologies.
The main content of an OWL ontology is carried in its
axioms and facts, which provide information about classes, properties,
and individuals in the ontology.
ontology
::= '
Ontology
' [
ontologyID
] {
directive
} '
directive
::= '
Annotation(
ontologyPropertyID
ontologyID
| '
Annotation(
annotationPropertyID
URIreference
| '
Annotation(
annotationPropertyID
dataLiteral
| '
Annotation(
annotationPropertyID
individual
axiom
fact
Names of ontologies are used in the abstract syntax to carry the meaning
associated with publishing an ontology on the Web.
Names of ontologies are used in the abstract syntax to carry the meaning
associated with publishing an ontology on the Web.
It is thus intended that the name of an ontology in the abstract syntax
would be the URI where it could be found, although this is not part of the
formal meaning of OWL.
Imports annotations, in
effect, are directives to retrieve a Web document and treat it as an OWL
ontology.
However, most aspects of the Web, including missing, unavailable, and
time-varying documents, reside outside the OWL specification; all that is
carried here is that a URI can be ``dereferenced'' into an OWL ontology.
In several places in this document, therefore, idealizations of this
operational meaning for imports are used.
Ontologies incorporate information about classes, properties, and
individuals, each of which can have an identifier which is a URI reference.
Some of these identifiers need to be given axioms, as detailed in
Section 2.3
datatypeID
::=
URIreference
classID
::=
URIreference
individualID
::=
URIreference
ontologyID
::=
URIreference
datavaluedPropertyID
::=
URIreference
individualvaluedPropertyID
::=
URIreference
annotationPropertyID
::=
URIreference
ontologyPropertyID
::=
URIreference
A URI reference cannot be both a
datatypeID
and a
classID
in an ontology.
A URI reference also cannot be more than one of an
datavaluedPropertyID
an
individualvaluedPropertyID
an
annotationPropertyID
or an
ontologyPropertyID
in an ontology.
However, a URI reference can be the identifier of a class or datatype
as well as the identifier of a property as well as the identifier of
an individual, although the ontology cannot then be translated
into an OWL DL RDF graph.
In OWL a datatype denotes the set of data values that is
the value space for the datatype.
Classes denote sets of individuals.
Properties relate individuals to other information, and are divided
into four disjoint groups,
data-valued properties, individual-valued properties, annotation properties, and ontology properties.
Data-valued properties relate individuals to data values.
Individual-valued properties relate individuals to other individuals.
Annotation properties are used to place annotations on individuals, class
names, property names, and ontology names.
Ontology properties relate ontologies to other ontologies, in particular
being used for importing information from other ontologies.
Individual identifiers are used to refer to resources,
and data literals are used to refer to data values.
There are two
built-in classes in OWL, they both use URI references in the
OWL namespace, i.e., names starting with
, for which
the namespace name
owl
is used here.
(Throughout this document qualified names will be used as abbreviations for URI references.)
The class with identifier
owl:Thing
is the class of all individuals.
The class with identifier
owl:Nothing
is
the empty class.
Both classes are part of OWL Lite.
The following XML Schema datatypes
XML Schema Datatypes
can be used in OWL as built-in datatypes by means of the XML Schema
canonical URI reference for the datatype,
name,
where name is the local name of the datatype:
xsd:string
xsd:boolean
xsd:decimal
xsd:float
xsd:double
xsd:dateTime
xsd:time
xsd:date
xsd:gYearMonth
xsd:gYear
xsd:gMonthDay
xsd:gDay
xsd:gMonth
xsd:hexBinary
xsd:base64Binary
xsd:anyURI
xsd:normalizedString
xsd:token
xsd:language
xsd:NMTOKEN
xsd:Name
xsd:NCName
xsd:integer
xsd:nonPositiveInteger
xsd:negativeInteger
xsd:long
xsd:int
xsd:short
xsd:byte
xsd:nonNegativeInteger
xsd:unsignedLong
xsd:unsignedInt
xsd:unsignedShort
xsd:unsignedByte
and
xsd:positiveInteger
The other built-in
XML
Schema datatypes are problematic for OWL, as
discussed in
Section
5.1
of RDF Semantics
RDF Semantics
].
The built-in RDF datatype,
rdf:XMLLiteral
, is also an OWL built-in datatype.
Because there is no standard way to go from a URI reference to an XML
Schema datatype in an XML Schema, there is no standard way to use
user-defined XML Schema datatypes in OWL.
There are several
built-in annotation properties
in
OWL, namely
owl:versionInfo
rdfs:label
rdfs:comment
rdfs:seeAlso
and
rdfs:isDefinedBy
In keeping with their definition in RDF,
rdfs:label
and
rdfs:comment
can only be used with data literals.
There are also several
built-in ontology properties
they are
owl:imports
owl:priorVersion
owl:backwardCompatibleWith
and
owl:incompatibleWith
Ontology annotations that use
owl:imports
have
the extra effect of importing the target ontology.
Many OWL constructs use
annotations, which,
just like annotation directives, are used to record information associated
with some portion of the construct.
annotation
::= '
annotation(
annotationPropertyID
URIreference
| '
annotation(
annotationPropertyID
dataLiteral
| '
annotation(
annotationPropertyID
individual
2.2. Facts
There are two kinds of facts in the OWL abstract syntax.
The first kind of fact states information about a particular individual,
in the form of
classes that the individual belongs
to plus properties and values of that individual.
An individual can be given an
individualID
that will denote that
individual, and can be used to refer to that individual.
However, an individual need not be given an
individualID
such individuals are anonymous (blank in RDF terms) and cannot be
directly referred to elsewhere.
The syntax here is set up to somewhat mirror RDF/XML syntax
RDF Syntax
without the use
of
rdf:nodeID
fact
::=
individual
individual
::= '
Individual(
' [
individualID
] {
annotation
} { '
type
type
' } {
value
} '
value
::= '
value(
individualvaluedPropertyID
individualID
)'
| '
value(
individualvaluedPropertyID
individual
| '
value(
datavaluedPropertyID
dataLiteral
Facts are the same in the OWL Lite and OWL DL abstract syntaxes, except for
what can be a type. In OWL Lite, types can be class IDs or
OWL Lite restrictions, see
Section 2.3.1.2
type
::=
classID
restriction
In the OWL DL abstract syntax types can be general
descriptions
, which include class IDs and OWL Lite
restrictions as well as other constructs
type
::=
description
Data literals in the abstract syntax are either plain literals or typed
literals.
Plain literals consist of a Unicode string in Normal Form C and an optional
language tag, as in
RDF plain literals
RDF Concepts
].
Typed literals consist of a lexical representation and a URI reference, as in
RDF typed literals
RDF Concepts
].
dataLiteral
::=
typedLiteral
plainLiteral
typedLiteral
::=
lexicalForm
^^
URIreference
plainLiteral
::=
lexicalForm
lexicalForm
languageTag
lexicalForm
::=
as in RDF, a unicode string in normal form C
languageTag
::=
as in RDF, an XML language tag
The second kind of fact is used to make individual identifiers be the same
or pairwise distinct.
fact
::= '
SameIndividual
individualID
individualID
individualID
} '
| '
DifferentIndividuals
individualID
individualID
individualID
} '
2.3. Axioms
The biggest differences between the OWL Lite and OWL DL abstract
syntaxes show up in the axioms,
which are used to provide information about classes and properties.
As it is the smaller language,
OWL Lite axioms are given first,
in
Section 2.3.1
The OWL DL axioms are given
in
Section 2.3.2
OWL DL axioms include OWL Lite axioms as special cases.
Axioms are used to associate class and property identifiers with either
partial or complete specifications of their characteristics, and to give
other information about classes and properties. Axioms used to be
called definitions, but they are not all definitions in the common sense of
the term
and
thus a more neutral name has been chosen.
The syntax used here is meant to look somewhat like
the syntax used in some frame systems.
Each class axiom in OWL Lite contains
a collection of more-general classes
and
a collection of local property restrictions in the form of restriction constructs.
The restriction construct gives the local range of a property, how many
values are permitted, and/or a collection of required values.
The class is made either equivalent to or a subset of the intersection of
these more-general classes and restrictions.
In the OWL DL abstract syntax a class axiom contains a collection of descriptions,
which can be more-general classes, restrictions, sets of individuals,
and boolean combinations of descriptions.
Classes can also be specified by enumeration or be made equivalent or disjoint.
Properties can be equivalent to or sub-properties of others;
can be made functional, inverse functional, symmetric, or transitive;
and can be given global domains and ranges.
However,
most information concerning
properties
is more naturally expressed in
restrictions, which allow local range and cardinality information to be
specified.
URI references used as class IDs or datatype IDs have to be differentiated,
and so need an axiom, except for the built-in OWL
classes
and
datatypes
and
rdfs:Literal
There can be more than one axiom for a class or datatype.
Properties used in an abstract syntax ontology have to be
categorized as either data-valued or individual-valued or annotation
properties.
Properties thus also need an axiom for this purpose, at least.
If an ontology imports another ontology, the axioms in the imported
ontology (and any ontologies it imports, and so on) can be used for these
purposes.
2.3.1. OWL Lite Axioms
2.3.1.1. OWL Lite Class Axioms
In OWL Lite class axioms are used to state that a class is
exactly equivalent to, for the modality
complete
, or a subclass of,
for the modality
partial
, the conjunction of a collection of
superclasses and
OWL Lite Restrictions
It is also possible to indicate that the use of a class is deprecated.
axiom
::= '
Class
classID
['
Deprecated
']
modality
annotation
} {
super
} '
modality
::= '
complete
' | '
partial
super
::=
classID
restriction
In OWL Lite it is possible to state that two or more classes are equivalent.
axiom
::= '
EquivalentClasses(
classID
classID
classID
} '
Datatype axioms are simpler, only serving to say that a datatype ID is the
ID of a datatype and to give annotations for the datatype.
axiom
::= '
Datatype
datatypeID
['
Deprecated
']
annotation
2.3.1.2. OWL Lite Restrictions
Restrictions
are used in OWL Lite class
axioms to provide
local constraints on
properties
in the class.
Each
allValuesFrom
part of a restriction makes the constraint that all values
of the property for individuals in the class must belong to the specified class
or datatype.
Each
someValuesFrom
part makes the constraint that there must be at least one
value for the property that belongs to the specified class or datatype.
The
cardinality
part says how many distinct values there are for the
property for each individual in the class. In OWL Lite the only
cardinalities allowed are 0 and 1.
See
Section 2.3.1.3
for a limitation
on which properties can have cardinality parts in restrictions.
restriction
::= '
restriction(
datavaluedPropertyID
dataRestrictionComponent
| '
restriction(
individualvaluedPropertyID
individualRestrictionComponent
dataRestrictionComponent
::= '
allValuesFrom(
dataRange
| '
someValuesFrom(
dataRange
cardinality
individualRestrictionComponent
::= '
allValuesFrom(
classID
| '
someValuesFrom(
classID
cardinality
cardinality
::=
minCardinality(0)
' | '
minCardinality(1)
maxCardinality(0)
' | '
maxCardinality(1)
cardinality(0)
' | '
cardinality(1)
2.3.1.3. OWL Lite Property Axioms
Properties are also specified using a frame-like syntax.
Data-valued properties relate individuals to data values, like integers.
Individual-valued properties relate individuals to other individuals.
These two kinds of properties can be given super-properties, allowing the construction of
a property hierarchy. It does not make sense to have an individual-valued
property be a super-property of
a data-valued property, or vice versa.
Data-valued and individual-valued properties can also be given
domains
and
ranges
. A domain for a property
specifies which individuals are potential subjects of statements
that have the property as predicate,
just as in RDFS. In OWL Lite the domains of properties are classes.
There can be multiple domains, in which case only individuals that belong to
all of the domains are potential subjects.
A range for a property specifies which individuals or data values can be
objects of statements that have the property as predicate. Again, there
can be multiple ranges, in
which case only individuals or data values that belong to all of the ranges
are potential objects.
In OWL Lite ranges for individual-valued properties are classes; ranges for
data-valued properties are datatypes.
Data-valued properties can be specified as (partial) functional, i.e.,
given an individual, there can be at most one relationship to a data value
for that individual in the property.
Individual-valued properties can be specified to be the inverse of another
property.
Individual-valued properties can also be specified to be symmetric as well
as partial functional, partial inverse-functional, or transitive.
To preserve decidability of reasoning in OWL Lite, not all
properties can have cardinality restrictions placed on them or be specified
as functional or inverse-functional.
An
individual-valued
property is
complex
if
1/ it is specified as being functional or inverse-functional,
2/ there is some cardinality restriction that uses it,
3/ it has an inverse that is complex, or
4/ it has a super-property that is complex.
Complex properties cannot be specified as being transitive.
Annotation
and ontology properties
are much simpler than data-valued and
individual-valued
properties. The only information in axioms for them is
annotations.
axiom
::= '
DatatypeProperty(
datavaluedPropertyID
Deprecated'
] {
annotation
{ '
super(
datavaluedPropertyID
' } ['
Functional
']
{ '
domain(
classID'
' } { '
range(
dataRange
' } '
| '
ObjectProperty
individualvaluedPropertyID
['
Deprecated'
] {
annotation
{ '
super(
individualvaluedPropertyID
' }
[ '
inverseOf
individualvaluedPropertyID
' ] [ '
Symmetric
' ]
[ '
Functional
| '
InverseFunctional
| '
Functional
' '
InverseFunctional
' | '
Transitive
{ '
domain(
classID
' } { '
range(
classID
' } '
| '
AnnotationProperty
annotationPropertyID
annotation
} '
| '
OntologyProperty
ontologyPropertyID
annotation
} '
dataRange
::=
datatypeID
| '
rdfs:Literal
The following axioms make several properties be equivalent, or make
one property be a sub-property of another.
axiom
::=
EquivalentProperties(
datavaluedPropertyID
datavaluedPropertyID
datavaluedPropertyID
} '
SubPropertyOf(
datavaluedPropertyID
datavaluedPropertyID
| '
EquivalentProperties(
individualvaluedPropertyID
individualvaluedPropertyID
individualvaluedPropertyID
} '
| '
SubPropertyOf(
individualvaluedPropertyID
individualvaluedPropertyID
2.3.2. OWL DL Axioms
2.3.2.1. OWL DL Class Axioms
The OWL DL abstract syntax has more-general versions of the OWL Lite class
axioms where
superclasses, more-general restrictions, and boolean combinations of
these are allowed. Together, these constructs are called
descriptions
axiom
::= '
Class
classID
['
Deprecated
']
modality
annotation
} {
description
} '
modality
::= '
complete
' | '
partial
In the OWL DL abstract syntax it is also possible to make a class exactly consist of a certain
set of individuals, as follows.
axiom
::= '
EnumeratedClass(
classID
['
Deprecated
'] {
annotation
} {
individualID
} '
Finally, in the OWL DL abstract syntax it is possible to require that a collection of descriptions
be pairwise disjoint, or have the same instances, or
that one description is a subclass of another. Note that the last two
of these axioms generalize, except for lack of annotation, the first kind
of class axiom just above.
axiom
::= '
DisjointClasses
description
description
description
} '
| '
EquivalentClasses(
description
description
} '
| '
SubClassOf(
description
description
In OWL DL it is
possible
to have only one description in an
EquivalentClasses
construct.
This allows ontologies to include descriptions that are not connected to
anything, which is not semantically useful, but makes allowances for
less-than-optimal editing of ontologies.
Datatype axioms are the same as in OWL Lite.
axiom
::= '
Datatype
datatypeID
['
Deprecated
']
annotation
2.3.2.2. OWL DL Descriptions
Descriptions in the OWL DL abstract syntax
include class identifiers and restrictions
Descriptions can also be boolean combinations of other descriptions, and
sets of individuals.
description
::=
classID
restriction
| '
unionOf
' {
description
} '
| '
intersectionOf
' {
description
} '
| '
complementOf
description
| '
oneOf
' {
individualID
} '
2.3.2.3. OWL DL Restrictions
Restrictions
in the OWL DL abstract syntax generalize OWL Lite restrictions by allowing
descriptions where classes are allowed in OWL Lite and allowing sets
of data values as well as datatypes. The combination of datatypes and
sets of data values is called a data range.
In the OWL DL abstract syntax, values can also be given for properties in classes.
In addition, cardinalities are not restricted to only 0 and 1.
restriction
::= '
restriction(
datavaluedPropertyID
dataRestrictionComponent
dataRestrictionComponent
} '
| '
restriction(
individualvaluedPropertyID
individualRestrictionComponent
individualRestrictionComponent
} '
dataRestrictionComponent
::= '
allValuesFrom
dataRange
| '
someValuesFrom
dataRange
| '
value
dataLiteral
cardinality
individualRestrictionComponent
::= '
allValuesFrom(
description
| '
someValuesFrom(
description
| '
value(
individualID
cardinality
cardinality
::= '
minCardinality(
non-negative-integer
| '
maxCardinality(
non-negative-integer
| '
cardinality(
non-negative-integer
A data range, used as the range of a data-valued property and in other
places in the OWL DL abstract syntax, is either a datatype or a set of data values.
dataRange
::=
datatypeID
| '
rdfs:Literal
| '
oneOf(
' {
dataLiteral
} '
The
OWL Lite limitations on which
properties can have cardinality components in their restrictions
are also present in OWL DL.
2.3.2.4. OWL DL Property Axioms
Property axioms in the OWL DL abstract syntax generalize OWL Lite property
axioms by allowing
descriptions in place of classes and data ranges in place of datatypes
in domains and ranges.
axiom
::= '
DatatypeProperty
datavaluedPropertyID
['
Deprecated
'] {
annotation
{ '
super(
datavaluedPropertyID
'} ['
Functional
']
{ '
domain
description
' } { '
range
dataRange
' } '
| '
ObjectProperty
individualvaluedPropertyID
['
Deprecated
'] {
annotation
{ '
super(
individualvaluedPropertyID
' }
[ '
inverseOf
individualvaluedPropertyID
' ] [ '
Symmetric
' ]
[ '
Functional
' | '
InverseFunctional
' | '
Functional
' '
InverseFunctional
' | '
Transitive
' ]
{ '
domain(
description
' } { '
range(
description
' } '
| '
AnnotationProperty
annotationPropertyID
annotation
} '
| '
OntologyProperty
ontologyPropertyID
annotation
} '
The
limitations on which
properties can be specified to be functional or inverse-functional
are
also present in OWL DL.
As in OWL Lite, the following axioms make several properties be equivalent,
or make one property be a sub-property of another.
axiom
::= '
EquivalentProperties(
datavaluedPropertyID
datavaluedPropertyID
datavaluedPropertyID
} '
| '
SubPropertyOf(
datavaluedPropertyID
datavaluedPropertyID
| '
EquivalentProperties(
individualvaluedPropertyID
individualvaluedPropertyID
individualvaluedPropertyID
} '
| '
SubPropertyOf(
individualvaluedPropertyID
individualvaluedPropertyID
previous
next
top
contents