The Web Rule Language WRL is a rule-based ontology language
for the Semantic Web. The language is located in the Semantic Web
stack next to the Description Logic based Ontology language OWL.
WRL defines three
variants, namely Core, Flight and Full. The Core variant marks
the common fragment between WRL and OWL. WRL-Flight is a Datalog-based
rule language. WRL-Full is a full-fledged rule language with
function symbols and negation under the Well-Founded
Semantics.
This document is a part of the WRL Submission.
By publishing this document, W3C acknowledges that DERI Innsbruck at the
Leopold-Franzens-Universität Innsbruck, Austria, DERI Galway at the
National University of Ireland, Galway, Ireland, The Open University,
Software AG, Forschungszentrum Informatik (FZI), BT, and National Research Council Canada have made a formal
submission to W3C for discussion. Publication of this document by W3C
indicates no endorsement of its content by W3C, nor that W3C has, is, or
will be allocating any resources to the issues addressed by it. This
document is not the product of a chartered W3C group, but is published as
potential input to the W3C
Process. Publication of acknowledged Member Submissions at the W3C site
is one of the benefits of W3C Membership.
Please consult the requirements associated with Member Submissions of section
3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member
Submissions.
1. Introduction
2. WRL Syntax
3. WRL Semantics
4. XML Syntax for WRL
5. RDF Syntax for WRL
6. Mapping to OWL
7. Conclusions
Acknowledgments
References
Appendix A. Built-ins in WRL
Appendix B. Human-Readable Syntax
The Web Rule Language WRL is derived from the ontology
component of the Web Service Modeling Language WSML [WSML].
WRL is a rule-based [Lloyd, 1987] ontology language, whereas OWL [OWL] is a Description Logic based ontology
language. WRL adheres to a conceptual model for ontologies, developed in the WSMO effort, which is independent of any
logical language paradigm. The basic ontology meta-model of WRL consists of
concepts, relations, instances, and axioms.
WRL has an XML exchange syntax which is based on RuleML [Boley et al., 2001]. It is expected that WRL, WSML, SWSL and RuleML will
converge on the XML syntax.
Figure 1: WRL positioned in the Semantic Web Layer
Cake
Figure 1 depicts the location of the Web Rule Language WRL in
the Semantic Web language layer cake.[1] This layer cake differs
slightly from the Semantic Web layer cake originally
presented at XML2000. Namely, we refine the "Ontology
vocabulary" layer. The Ontology vocabulary can be specified using
WRL or OWL, or using their common semantic subset, denoted by the
WRL-Core subset of WRL and the OWL-DLP subset
of OWL [Grosof et al.,
2003]. With common semantic subset we mean in this context that
every WRL-Core has a corresponding OWL-DLP ontology (and
vice versa), where both ontologies entail exactly the same set of
ground facts. In this new layer cake, WRL is a rules-based ontology
language, where OWL is a Description Logic based ontology
language. The common superset of WRL and OWL, here called "FOL++",
might be a First-Order Logic with particular extensions to
incorporate the nonmonotonic features. This language, going
beyond FOL RuleML [Boley et al., 2005] is a
possible development and is not addressed in this document. We
feel that it would be overambitious at this point in time to
try to specify FOL++; it is too early to standardize such an
expressive language, which is in fact an open research topic.
WRL itself consists of three variants, namely Core, Flight and
Full. WRL-Core marks the common core between OWL and WRL and is
thus the basic interoperability layer with OWL. WRL-Flight is
based on the Datalog subset of F-Logic [Kifer et al.,
1995], with negation-as-failure
under the Perfect Model Semantics [Przymusinski, 1989]. WRL-Full is based on full Horn with
negation-as-failure under the Well-Founded Semantics [van Gelder et al., 1991].
This document is further structured as follows. Chapter 2 defines the WRL
language along with the (normative) surface syntax. Chapter 3
specifies the WRL semantics through a mapping to existing
logical formalisms. Chapters 4 and 5 defined the XML and RDF
syntaxes of WRL, respectively. Chapter 6 specified the
mapping between WRL-Core and OWL for interoperability with OWL
ontologies. Finally, Chapter 7 presents conclusions.
In this chapter we introduce the WRL syntax. The WRL syntax
consists of two major parts: the conceptual syntax and the
logical expression syntax. The conceptual syntax is used for the
modeling of ontologies. Logical
expressions are used to refine these definitions using arbitrary
rules.
We use fragments of the WRL grammar in order to show the
syntax of the WRL elements. The grammar is specified using a
dialect of Extended BNF which can be used directly in the SableCC
compiler compiler [SableCC]. Terminals are
delimited with single quotes, non-terminals are underlined and
refer to the corresponding productions. Alternatives are
separated using vertical bars '|'; optional elements are appended
with a question mark '?'; elements that may occur zero or more
times are appended with an asterisk '*'; elements that may occur
one or more times are appended with a plus '+'. In the case of
multiple references to the same non-terminal in a production, the
non-terminals are disambiguated by using labels of the form
'[label]:'. In order to keep the descriptions in this chapter
concise, we do not fully describe all non-terminals.
Throughout the WRL examples in the following sections, we use
boldfaced text to distinguish WRL keywords.
This chapter is structured as follows. The WRL syntax basics,
such as the use of namespaces, identifiers, etc., are described
in Section 2.1. The elements in
common between all WRL specifications are described in Section
2.2. WRL ontologies are described
in Section 2.3.
Finally, the WRL logical expression syntax is specified in
Section 2.4.
The conceptual syntax for WRL has a frame-like style. The
information about a class and its attributes, a relation and its
parameters and an instance and its attribute values is specified
in one large syntactic construct, instead of being divided into a
number of atomic chunks. It is possible to spread the information
about a particular class, relation, instance or axiom over
several constructs, but we do not recommend this. In fact, in
this respect, WRL is similar to OIL [Fensel
et al., 2001], which also offers the possibility of either
grouping descriptions together in frames or spreading the
descriptions throughout the document. One important difference
with OIL (and OWL) is that attributes in WRL are only defined in the
context of the class to which the attribute
belongs. Attributes are part of a concept definition.
Nonetheless, attribute names are global and it is possible to
specify global behavior of attributes through logical
expressions. However, we do not expect this to be necessary in
the general case and we strongly advise against it. In case
one needs to model a property which is independent of the
concept definition, this property is most likely a relation
rather than an attribute and thus should be modeled as a relation.
It is often possible to specify a list of arguments, for
example for attributes. Such argument lists in WRL are
comma-separated and delimited by curly brackets. Statements in
WRL start with a keyword and can be spread over multiple
lines.
A WRL ontology is separated into two parts. The first part
provides meta-information about the ontology, which consists of
such things as WRL variant identification, namespace references,
non-functional properties (annotations), import of ontologies,
and the type of the specification.
This meta-information block is strictly ordered. The second part
of the specification, consisting of elements such as concepts,
attributes, relations, etc., is not ordered.
The remainder of this section explains the WRL MIME type and
the use of namespaces, identifiers and datatypes in WRL.
When accessing resources over the Web, the MIME type indicates
the type of the resource. For example, plain text documents have
the MIME type text/plain and XML documents have the MIME type
application/xml.
When exchanging WRL documents written in the normative syntax,
it is necessary to use the appropriate MIME type so that
automated agents can detect the type of content. The MIME type to
be used for WRL documents is:
application/x-wrl
WRL/XML documents should have the MIME type:
application/x-wrl+xml
WRL/RDF documents in the XML serialization of RDF should have the
usual MIME type: application/rdf+xml
Namespaces were first introduced in XML [XMLNamespaces] for the purpose of
qualifying names which originate from different XML documents. In
XML, each qualified name consists of a tuple <namespace,
localname>. RDF adopts the mechanism of namespaces from XML
with the difference that qualified names are not treated as
tuples, but rather as abbreviations for full URIs.
WRL adopts the namespace mechanism of RDF. A namespace can be
seen as part of an IRI (see the next Section). The WRL keywords
themselves belong to the the namespace
http://www.wsml.org/wsml/wrl-syntax# (commonly abbreviated as
'wrl').
Namespaces can be used to syntactically distinguish elements
of multiple WRL specifications and, more generally, resources on
the Web. A namespace denotes a syntactical domain for naming
resources.
Whenever a WRL specification has a specific identifier which
corresponds to a Web address, it is good practice to have a
relevant document on the location pointed to by the identifier.
This can either be the WRL document itself or a natural language
document related to the WRL document. Note that the identifier of
an ontology does not have to coincide with the location of the
ontology. It is good practice, however, to include a related
document, possibly pointing to the WRL specification itself, at
the location pointed to by the identifier.
An identifier in WRL is either a data value, an IRI [IRI], or an anonymous
ID.
WRL has direct support for different types of concrete data,
namely, strings, integers and decimals, which correspond to the
XML Schema [XMLSchemaDatatypes]
primitive datatypes string, integer and
decimal. These concrete values can then be used to
construct more complex datatypes, corresponding to other XML
Schema primitive and derived datatypes, using datatype
constructor functions. See also Appendix
C.
WRL uses datatype wrappers to construct data values based on
XML Schema datatypes. The use of datatype wrappers gives more
control over the structure of the data values than the lexical
representation of XML. For example, the date: 3rd of February,
2005, which can be written in XML as: '2005-02-03', is written in
WRL as: _date(2005,2,3). The arguments of such a term can be
either strings, decimals, integers or variables. No other
arguments are allowed for such data terms. Each conforming WRL
implementation is required to support at least the
string, integer and decimal
datatypes.
Datatype identifiers manifest themselves in WRL in two
distinct ways, namely, as concept identifiers and as datatype
wrappers. A datatype wrapper is used as a data structure for
capturing the different components of data values. Datatype
identifiers can also be used directly as concept identifiers.
Note however that the domain of interpretation of any datatype is
finite and that asserting membership of a datatype for a value
which does not in fact belong to this datatype, leads to an
inconsistency in the knowledge base.
Examples of data values:
_date(2005,3,12)
_sqname("http://www.wsml.org/wsml/wrl-syntax#", "ontology")
_boolean("true")
The following are example attribute definitions which restrict
the range of the attribute to a particular datatype:
age ofType _integer
location ofType _iri
hasChildren ofType _boolean
WRL allows the following syntactical shortcuts for particular
datatypes:
- Data values of type string can be written between
double quotes ‘"’. Double quotes inside a string
should be escaped using the backslash (‘\’)
character: \".
- Integer values can simply be written as such. Thus an
integer of the form
integer is a shortcut
for _integer("integer"). For example,
4 is a shortcut for
_integer("4")
- Decimal values can simply be written as such, using the '.'
as decimal symbols. Thus a literal of the form
decimal is a shortcut for
_decimal("decimal"). For example,
4.2 is a shortcut for
_decimal("4.2").
Appendix A lists the built-in
predicates which any conforming WRL application must be able to
support, as well as the infix notation which serves as a shortcut
for the built-ins.
Furthermore, WRL also allows shortcut syntax for IRI and
sQName data values, as described below.
The IRI (Internationalized Resource Identifier)
[IRI] mechanism
provides a way to identify resources. IRIs may point to resources
on the Web (in which case the IRI can start with 'http://'), but
this is not necessary (e.g., books can be identified through IRIs
starting with 'urn:isbn:'). The IRI proposed standard is a
successor to the popular URI standard. In fact, every URI is an
IRI.
An IRI can be abbreviated to an sQName. Note that the term
'QName' has been used, after its introduction in XML [XMLNamespaces], with different meanings. The
meaning of the term 'QName' as defined in XML got blurred after
the adoption of the term in RDF. In XML, QNames are simply used
to qualify local names and thus every name is a tuple
<namespace, localname>. In RDF, QNames have become
abbreviations for URIs, which is different from the meaning in
XML. WRL adopts a view similar to the RDF-like version of QNames,
but due to its deviation from the original definition in XML we
call them sQNames which is short for 'serialized QName'.
An sQName consists of two parts, namely, the namespace prefix
and the local part. WRL allows two distinct ways to write
sQNames. sQName can be seen as a datatype and thus it has an
associated datatype wrapper, namely, _sqname (see
also Appendix A), which has two
arguments: namespace and localname. Because sQNames are very
common in WRL specifications, WRL allows a short syntax for
sQNames. An sQName can simply be written using a namespace prefix
and a localname, separated by a hash ('#'):
namespace_prefix#localname. It is also
possible to omit the namespace prefix and the hash symbol. In
this case, the name is defined in the default namespace.
An sQName is equivalent to the IRI which is obtained by
concatenating the namespace IRI (to which the prefix refers) with
the local part of the sQName. Therefore, an sQName can be seen as
an abbreviation for an IRI which enhances the legibility of the
specification. If an sQName has no prefix, the namespace of the
sQName is the default namespace of the document.
IRI is a datatype in WRL and has the associated datatype
wrapper _iri with one argument (the IRI). For
convenience, WRL also allows a short form with the delimiters '
_" ' and ' " '. For convenience, an sQName does not require
special delimiters. However, sQNames may not coincide with any
WRL keywords. The characters '.' and '-' in an sQName need to be
escaped using the backslash (‘\’) character.
Examples of full IRIs in WRL:
_"http://example.org/PersonOntology#Human"
_"http://www.uibk.ac.at/"
Examples of sQNames in WRL (with corresponding full IRIs; dc
stands for http://purl.org/dc/elements/1.1#, foaf stands for
http://xmlns.com/foaf/0.1/ and xsd stands for
http://www.w3.org/2001/XMLSchema#; we assume the default
namespace http://example.org/#):
- dc#title (http://purl.org/dc/elements/1.1#title)
- foaf#name (http://xmlns.com/foaf/0.1/name)
- xsd#string (http://www.w3.org/2001/XMLSchema#string)
- Person (http://example.org/#Person)
- hasChild (http://example.org/#hasChild)
WRL defines the following two IRIs:
http://www.wsmo.org/wsml/wrl-syntax#true and
http://www.wsmo.org/wsml/wrl-syntax#false, which
stand for universal truth and universal falsehood, respectively.
Note that for convenience we typically use the abbreviated sQName
form (where wrl stands for the default WRL namespace
http://www.wsmo.org/wsml/wrl-syntax#): wrl#true, wrl#false.
Additionally, WRL allows the keywords 'true' and 'false' in the
human-readable syntax.
Please note that the IRI of a resource does not necessarily
correspond to a document on the Web. Therefore, we distinguish
between the identifier and the locator of a
resource. The locator of a resource is an IRI which can be mapped
to a location from which the (information about the) resource can
be retrieved.
An anonymous identifier represents an IRI which is meant to be
globally unique. Global uniqueness is to be ensured by the system
interpreting the WRL description (instead of the author of the
specification). It can be used whenever the concrete identifier
to be used to denote an object is not relevant, but when we
require the identifier to be new (i.e., not used anywhere else in
the WRL description).
Anonymous identifiers in WRL follow the naming convention for
anonymous IDs presented in [Yang & Kifer,
2003]. Unnumbered anonymous IDs are denoted with
‘_#’. Each occurrence of ‘_#’ denotes a
new anonymous ID and different occurrences of ‘_#’
are unrelated. Thus each occurrence of an unnumbered anonymous ID
can be seen as a new unique identifier.
Numbered anonymous IDs are denoted with
‘_#n’ where n stands for an integer
denoting the number of the anonymous ID. The use of numbered
anonymous IDs is limited to logical expressions and can therefore
not be used to denote entities in the conceptual syntax. Multiple
occurrences of the same numbered anonymous ID within the same
logical expression are interpreted as denoting the same
object.
Take as an example the following logical expressions:
_#[a hasValue _#1] and _#1 memberOf b.
_#1[a hasValue _#] and _# memberOf _#.
There are in total three occurrences of the unnumbered
anonymous ID. All occurrences are unrelated. Thus, the second
logical expression does not state that an object is a
member of itself, but rather that some anonymous object is a
member of some other anonymous object. The two occurrences of _#1
in the first logical expression denote the same object. Thus the
value of attribute a is a member of b.
The occurrence of _#1 in the second logical expression is,
however, not related to the occurrence of _#1 in the first
logical expression.
The use of an identifier in the specification of WRL elements
is optional. If no identifier is specified, the following default
rules apply:
- In case the identifier of an ontology is omitted or denoted by an anonymous ID, the
identifier is assumed to be the same as the locator of the
specification, i.e., the location where the specification was
found.
- In case the identifier of a WRL element (e.g., concept,
relation, postcondition) has been omitted, the unnumbered
anonymous identifier '_#' is used to identify the element.
If the same identifier is used for different definitions, it
is interpreted differently, depending on the context. In a
concept definition, an identifier is interpreted as a concept; in
a relation definition this same identifier is interpreted as a
relation. If, however, the same identifier is used in separate
definitions, but with the same context, then the interpretation
of the identifier has to conform to both definitions and thus the
definitions are interpreted conjunctively. For example, if there
are two concept definitions which are concerned with the same
concept identifier, the resulting concept definition includes all
attributes of the original definitions and if the same attribute
is defined in both definitions, the range of the resulting
attribute will be equivalent to the conjunction of the original
attributes.
A WRL file may at any place contain a comment. A single line
comment starts with comment or
// and ends with a line break.
Comments can also range over multiple lines, in which they need
to be delimited by /* and
*/.
It is recommended to use non-functional properties for any
information related to the actual WRL descriptions; comments
should be only used for meta-data about the WRL file itself.
Comments are disregarded when parsing the WRL document and when
converting to different syntaxes (e.g., XML, RDF).
Examples:
/* Illustrating a multi line
* comment
*/
// a one-line comment
comment another one-line comment
This section describes the elements of a WRL document. A WRL
document has the following structure:
Every WRL specification document may start with the
wrlVariant keyword, followed by an
identifier for the WRL variant which is used in the document.
WRL-Core is identified with
http://www.wsmo.org/wsml/wrl-syntax/wrl-core and
WRL-Flight is identified with
http://www.wsmo.org/wsml/wrl-syntax/wrl-flight and
WRL-Full is identified with
http://www.wsmo.org/wsml/wrl-syntax/wrl-full.
The specification of the wrlVariant is optional. In case the variant is
omitted, no guarantee can be given as to which WRL variant is
used.
The following illustrates the WRL variant reference for a
WRL-Flight specification:
wrlVariant _"http://www.wsml.org/wsml/wrl-syntax/wrl-flight"
When the intended WRL variant is explicitly stated, tools can
immediately recognize the intention of the author and return an
exception if the specification does not conform to the
syntactical restrictions imposed by the intended variant. This
kind of sublanguage variation, pioneered by RuleML [Boley,
2001], generally helps developers of WRL specifications to stay within
desired limits of complexity and to communicate their desires to
others.
At the top of a WRL document, below the identification of the
WRL variant, there is an optional block of namespace references,
which is preceded by the namespace
keyword. The namespace keyword is
followed by a number of namespace references. Each namespace
reference, except for the default namespace, consists of the
chosen prefix and the IRI which identifies the namespace. Note
that, like any argument list in WRL, the list of namespace
references is delimited with curly brackets ‘{’
‘}’. In case only a default namespace is declared,
the curly brackets are not required.
Two examples are given below, one with a number of namespace
declarations and one with only a default namespace:
namespace {_"http://www.example.org/ontologies/example#",
dc _"http://purl.org/dc/elements/1.1#",
foaf _"http://xmlns.com/foaf/0.1/",
wrl _"http://www.wsmo.org/wsml/wrl-syntax#",
loc _"http://www.wsmo.org/ontologies/location#" }
namespace _"http://www.example.org/ontologies/example#"
A WRL ontology specification is identified by the ontology keyword optionally followed by an IRI
which serves as the identifier of the ontology. If no identifier
is specified for the ontology, the locator of the ontology serves
as identifier.
Example:
ontology family
An ontology specification document in WRL consists of:
In this section we explain the ontology modeling elements in
the WRL language. The modeling elements are based on the WSMO
conceptual model of ontologies [Roman et
al., 2005].
Any WRL specification may have non-functional properties and
may import ontologies:
Non-functional properties may be used for the WRL document as
a whole but also for each element in the specification.
Non-functional property blocks are delimited with the keywords
nonFunctionalProperties and
endNonFunctionalProperties or the
short forms nfp and endnfp. Following the keyword is a list of
attribute values, which consists of the attribute identifier, the
keyword hasValue and the value for the attribute, which
may be any identifier and can thus be an IRI, a data value, an
anonymous identifier or a comma-separated list of the former,
delimited with curly brackets. The recommended properties are the
properties of the Dublin Core [DublinCore], but the list of properties is extensible and thus
the user can choose to use properties coming from different
sources. Following the WRL convention, if a property has multiple
values, these are separated by commas and the list of values is
delimited by curly brackets.
Example:
nonFunctionalProperties
dc#title hasValue "WRL example ontology"
dc#subject hasValue "family"
dc#description hasValue "fragments of a family ontology to provide WRL examples"
dc#contributor hasValue { _"http://homepage.uibk.ac.at/~c703240/foaf.rdf",
_"http://homepage.uibk.ac.at/~csaa5569/",
_"http://homepage.uibk.ac.at/~c703239/foaf.rdf",
_"http://homepage.uibk.ac.at/homepage/~c703319/foaf.rdf" }
dc#date hasValue _date("2004-11-22")
dc#format hasValue "text/html"
dc#language hasValue "en-US"
dc#rights hasValue _"http://www.deri.org/privacy.html"
wrl#version hasValue "$Revision: 1.2 $"
endNonFunctionalProperties
Non-functional properties in WRL are not part of the logical
language; programmatic access to these properties can be provided
through an API.
Ontologies may be imported in any WRL specification through
the import ontologies block, identified by the keyword
importsOntology. Following the
keyword is a list of IRIs identifying the ontologies being
imported. An importsOntology
definition serves to merge ontologies, similar to the
owl:import annotation property in
OWL. This means the resulting ontology is the union of all axioms
and definitions in the importing and imported ontologies. Please
note that recursive import of ontologies is also supported. This
means that if an imported ontology has any imported ontologies of
its own, these ontologies are also imported.
Example:
importsOntology {_"http://www.wsmo.org/ontologies/location",
_"http://xmlns.com/foaf/0.1"}
If the imported ontology is of a different WRL variant than
the importing specification, the resulting ontology is of the
most expressive of the two variants. For example, if a WRL-Core
ontology imports a WRL-Full ontology, the result of the import
will be a WRL-Full ontology.
A concept definition starts with the concept keyword, which is optionally followed by
the identifier of the concept. This is optionally followed by a
superconcept definition which consists of the keyword
subConceptOf followed by one or more concept
identifiers (as usual, if there is more than one, the list is
comma-separated and delimited by curly brackets). This is
followed by an optional nonFunctionalProperties block and zero or more
attribute definitions.
Note that WRL allows inheritance of attribute definitions,
which means that a concept inherits all attribute definitions of
its superconcepts. If two superconcepts have a definition for the
same attribute a, but with a different range, these
attribute definitions are interpreted conjunctively. This means
that the resulting range of the attribute a in the
subconcept is the conjunction (intersection) of the ranges of the
attribute definitions in the superconcepts.
Example:
concept Human subConceptOf {Primate, LegalAgent}
nonFunctionalProperties
dc#description hasValue "concept of a human being"
dc#relation hasValue humanDefinition
endNonFunctionalProperties
hasName ofType foaf#name
hasParent impliesType Human
hasChild impliesType Human
hasAncestor impliesType Human
hasWeight ofType _float
hasWeightInKG ofType _float
hasBirthdate ofType _date
hasObit ofType _date
hasBirthplace ofType loc#location
isMarriedTo impliesType Human
hasCitizenship ofType oo#country
WRL allows creation of axioms in order to refine the
definition already given in the conceptual syntax, i.e., the
subconcept and attribute definitions. It is advised in the WRL
specification to include the relation between the concept and the
axioms related to the concept in the non-functional properties
through the property dc#relation. In the example
above we refer to an axiom with the identifier
humanDefinition (see Section 2.3.5 for the
axiom).
Different knowledge representation languages, such as
Description Logics, allow for the specification of defined
concepts (called "complete classes" in OWL). The definition of a
defined concept is not only necessary, but also sufficient. A
necessary definition, such as the concept specification in the
example above, specifies implications of membership of the
concept for all instances of this concept. The concept
description above specifies that each instance of
Human is also an instance of Primate
and LegalAgent. Furthermore, all values for the
attributes hasName, hasParent,
hasWeight etc. must be of specific types. A necessary and
sufficient definition also works the other way around, which
means that if certain properties hold for the instance, the
instance is inferred to be a member of this concept.
WRL supports defined concepts through the use of axioms (see
Section 2.3.5). The logical expression contained in the axiom
should reflect an equivalence relation between a class membership
expression on one side and a conjunction of class membership
expressions on the other side, each with the same variable. Thus,
such a definition should be of the form:
?x memberOf A equivalent ?x memberOf B1 and ... and ?x memberOf Bn
With A and
B1,...,Bn concept
identifiers.
For example, in order to define the class Human
as the intersection of the classes Primate and
LegalAgent, the following definition is used:
axiom humanDefinition
definedBy
?x memberOf Human equivalent ?x memberOf Primate and ?x memberOf LegalAgent.
Two important features of attribute modeling which set WRL apart
from OWL are cardinality
constraints and attribute range constraints.
OWL offers cardinality and range restrictions on attributes which
serve to create additional (monotonic) inferences
such as existence or equality of objects or membership in a certain
class. For many users these restrictions
show unintuitive behavior from the viewpoint of classical rule
languages and databases [de Bruijn et al.,
2005]: Means to actually
check the data in your knowledge base with respect to
integrity constraints are missing in OWL. WRL allows the
specification of cardinality and range
constraints which are defined like integrity constraints in databases,
i.e., in the case of violation of a constraint, a given ontology
is inconsistent. This additional feature allows to check the integrity
of a closed set of data, implicitly the modeler to express
a local a closed world view on her/his published data.
WRL allows two kinds of attribute definitions, namely,
constraining definitions with the keyword ofType and
inferring definitions with the keyword impliesType. We
expect that inferring attribute definitions will not be used very
often if constraining definitions are allowed. However, WRL-Core
does not allow constraining attribute definitions. In order to
facilitate conceptual modeling in these language variants, we
allow the use of impliesType in WRL.
An attribute definition of the form A
ofType D, where A is
an attribute identifier and D is a concept
identifier, is a constraint on the values for attribute
A. If the value for the attribute A is not
known to be of type D, the constraint is violated and
the attribute value is inconsistent with respect to the ontology.
This notion of constraints corresponds to the usual
database-style constraints.
The keyword impliesType can be used for inferring the
type of a particular attribute value. An attribute definition of
the form A impliesType D,
where A is an attribute identifier and
D is a concept identifier, implies
membership of the concept D for all values
of the attribute A. Please note that if the range of the
attribute is a datatype, the semantics of ofType and
impliesType coincide, because datatypes have a known
domain and thus values need not be inferred to be of a certain
datatype.
Attributes which have a datatype as a range can be
distinguished from regular attributes through the meta-concept
_datatype. Each datatype used in WRL is a member of this
meta-concept.
Attributes which do not have a datatype range can be specified
as being reflexive, transitive, symmetric, or being the inverse
of another attribute, using the reflexive,
transitive, symmetric and inverseOf
keywords, respectively. Notice that these keywords do not enforce
a constraint on the attribute, but are used to infer additional
information about the attribute. The keyword inverseOf
must be followed by an identifier of the attribute, enclosed in
parentheses, of which this attribute is the inverse.
The cardinality constraints for a single attribute are
specified by including two numbers between parentheses '(' ')',
indicating the minimal and maximal cardinality, after the
ofType (or impliesType) keyword. The first number
indicates the minimal cardinality. The second number indicates
the maximal cardinality, where '*' stands for unlimited maximal
cardinality (and is not allowed for minimal cardinality). It is
possible to write down just one number instead of two, which is
interpreted as both a minimal and a maximal cardinality
constraint. When the cardinality is omitted, then it is assumed
that there are no constraints on the cardinality, which is
equivalent to (0 *). Note that a maximal cardinality
of 1 makes an attribute functional.
When an attribute is specified as being transitive, this means
that if three individuals a, b and c are
related via a transitive attribute att in such a way:
a att b att c then c is
also a value for the attribute att at a: a
att c.
When an attribute is specified as being symmetric, this means
that if an individual a has a symmetric attribute
att with value b, then b also has attribute
att with value a.
When an attribute is specified as being the inverse of another
attribute, this means that if an individual a has an
attribute att1 with value b and att1 is the
inverse of a certain attribute att2, then it is inferred
that b has an attribute att2 with value
a.
Below is an example of a concept definition with attribute
definitions:
concept Human
nonFunctionalProperties
dc#description hasValue "concept of a human being"
endNonFunctionalProperties
hasName ofType foaf#name
hasParent inverseOf(hasChild) impliesType Human
hasChild impliesType Human
hasAncestor transitive impliesType Human
hasWeight ofType (1) _float
hasWeightInKG ofType (1) _float
hasBirthdate ofType (1) _date
hasObit ofType (0 1) _date
hasBirthplace ofType (1) loc#location
isMarriedTo symmetric impliesType (0 1) Human
hasCitizenship ofType oo#country
WRL-Core poses a number of restrictions on attribute
definitions. Most of these restrictions stem from the fact that
it is not possible to express constraints in WRL-Core, other
than for datatypes.
- WRL-Core does not allow for the specification of the
attribute features reflexive, transitive,
symmetric and inverseOf. This restriction stems
from the fact that reflexivity, transitivity, symmetry and
inverse of attributes are defined locally to a concept in WRL as
opposed to Description Logics or OWL. You can however define
global transitivity, symmetry and inverse of attributes
just like in DLs or OWL by defining respective axioms (cf.
Definition 3.3
below).
- Cardinality constraints are not allowed and thus it is not
possible to specify functional properties.
- One may not specify constraining attribute definitions, other
than for datatype ranges. In other words, attribute definitions
of the form:
A ofType D are
not allowed, unless D is a datatype
identifier.
A relation definition starts with the relation keyword, which is optionally followed
by the identifier of the relation. WRL allows the specification
of relations with arbitrary arity. The domain of the parameters
can be optionally specified using the keyword impliesType or ofType. Note that parameters of a relation are
strictly ordered. A relation definition is optionally completed
by the keyword subRelationOf
followed by one or more identifiers of super-relations. Finally an
optional nonFunctionalProperties
block can be specified.
Relations in WRL can have an arbitrary arity and values for
the parameters can be constrained using parameter type
definitions of the form ( ofType type-name ) and (
impliesType type-name). In case a parameter type
definition is present, the arity is not required, because
it can be derived from the parameter type specification;
otherwise, the arity is required. The usage of ofType and impliesType
correspond with the usage in attribute definitions. Namely,
parameter definitions with the ofType keyword are used to
constrain the allowed parameter values, whereas parameter
definitions with the impliesType keyword are used to infer
concept membership of parameter values.
Below are two examples, one with parameter definitions and one
with an arity definition:
relation distance (ofType City, ofType City, impliesType _decimal) subRelationOf measurement
relation distance/3
As for concepts, the exact meaning of a relation can be
defined using axioms. For example one could axiomatize the
transitive closure for a property or further restrict the domain
of one of the parameters. As with concepts, it is recommended
that related axioms are indicated using the non-functional
property dc#relation.
In WRL-Core, the arity of relations is restricted to two. The
domain of the two parameters may be given using the keyword
impliesType or ofType. However, the ofType keyword is
only allowed in combination with a datatype and only the second
parameter may have a datatype as its range.
An instance definition starts with the instance keyword, (optionally) followed by the
identifier of the instance, the memberOf keyword and the name of the concept to
which the instance belongs. The memberOf keyword identifies the concept to which
the instance belongs. This definition is followed by the
attribute values associated with the instance. Each property
filler consists of the property identifier, the keyword
hasValue and the value(s) for the
attribute.
Example:
instance Mary memberOf {Parent, Woman}
hasName hasValue "Maria Smith"
hasBirthdate hasValue _date(1949,9,12)
hasChild hasValue {Paul, Susan}
Instances explicitly specified in an ontology are those which
are shared together as part of the ontology. However, most
instance data exists outside the ontology in private data stores.
Access to these instances, as described in [Roman et al., 2005], is achieved by providing a
link to an instance store. Instance stores contain large numbers
of instances and they are linked to the ontology. We do not
restrict the user in the way an instance store is linked to a WRL
ontology. This would be done outside the ontology definition,
since an ontology is shared and can thus be used in combination
with different instance stores.
Besides specifying instances of concepts, it is also possible
to specify instances of relations. Such a relation instance
definition starts with the relationInstance keyword, (optionally) followed
by the identifier of the relationInstance, the memberOf keyword and the name of the relation to
which the instance belongs. This is followed by an optional
nonFunctionalProperties block,
followed by the values of the parameters associated with the
instance.
Below is an example of an instance of a ternary relation
(remember that the identifier is optional, see also Section 2.1.2):
relationInstance distance(Innsbruck, Munich, 234)
WRL-Core does not impose restrictions on the specification of
instances for concepts. Relation instances are only allowed for
binary relations. Both values of the relation have to be
specified and have to correspond to its signature. This includes
the restriction that the first value may not be a data
value.
An axiom definition starts with the axiom keyword, followed by the name (identifier)
of the axiom. This is followed by an optional nonFunctionalProperties block and a logical
expression preceded by the definedBy
keyword. The logical expression must be followed by either a
blank or a new line. The language allowed for the logical
expression is explained in Section 2.4.
Example of a defining axiom:
axiom humanDefinition
definedBy
?x memberOf Human equivalent
?x memberOf Animal and
?x memberOf LegalAgent.
WRL allows the specification of database-style integrity
constraints. Below is an example of a constraining axiom:
axiom humanBMIConstraint
definedBy
!- naf bodyMassIndex(bmi hasValue ?b, length hasValue ?l, weight hasValue ?w)
and ?x memberOf Human and
?x[length hasValue ?l,
weight hasValue ?w,
bmi hasValue ?b].
Logical expressions occur within axioms of ontologies. In the
following, we give a syntax specification for general logical
expressions in WRL.
In order to specify the WRL logical expressions, we introduce
a new kind of identifier: variables.
Variable names start with an initial question mark, "?".
Variables may occur in place of concepts, attributes, instances,
relation arguments or attribute values. A variable may not,
however, replace a WRL keyword. Furthermore, variables may only
be used inside logical expressions.
The scope of a variable is always defined by its
quantification. If a variable is not quantified inside a formula,
the variable is implicitly universally quantified outside the
formula.
Examples of variables are: ?x, ?y1, ?myVariable
The syntax specified in the following is inspired by
First-Order Logic [Enderton, 2002]
and F-Logic [Kifer et al., 1995]. We
define first the notation of a WRL vocabulary in Definition
2.1.
Definition
2.1. A WRL vocabulary V of a language L(V)
consists of the following:
- A set of identifiers VID.
- A set of object constructors VO ⊆
VID.
- A set of function symbols VF ⊆
VO.
- A set of datatype wrappers VD ⊆
VO.
- A set of data values VDV ⊆
VO which encompasses all string, integer
and decimal values.
- A set of anonymous identifiers VA ⊆
VO of the form _#, _#1, _#2, etc....
- A set of relation identifiers VR ⊆
VID.
- A set of variable identifiers VV ⊆
VID of the form ?alpanum*.
In the following subsections we define the logical expression
syntax for the different WRL variants.
WRL-Core allows only a restricted form of logical
expressions. There are two sources for these restrictions [Grosof et al.,
2003].
Namely, the restriction of the language to a subset of
Description Logics restricts the kind of formulas which can be
written in the two-variable fragment of first-order logic.
Furthermore, it disallows the use of function symbols,
restricts the arity of predicates to binary and
chaining variables over predicates. The restriction of the
language to a subset of Datalog (without equality) disallows the
use of the equality symbol, disjunction in the head of a rule and
existentially quantified variables in the head of the rule.
Definition 2.2. A WRL-Core
vocabulary V is a WRL vocabulary with the following
restrictions:
- VC, VD,
VR, VI and
VNFP are the sets of concept, datatype,
relation, instance and non-functional property identifiers.
These sets are all subsets of the set of IRIs and are pairwise
disjoint.
- The set of attribute names is equivalent to
VR
- The set of relation identifiers VR is
split into two disjoint sets, VRA and
VRC, which correspond to relations with an
abstract and relations with a concrete range,
respectively.
Let V be a WRL-Core vocabulary. Let further γ
∈ VC, Γ be either an identifier in
VC or a list of identifiers in VC, Δ
be either an identifier in VD or a list of identifiers
in VD, φ ∈ VI, ψ be either an
identifier in VI or a list of identifiers in
VI, p,q ∈ VRA, s,t
∈ VRC, and Val be either a data value or a
list of data values.
Definition 2.3. The set of
atomic formulae (also called molecules) in L(V) is defined as follows:
- γ subConceptOf Γ is an atomic formula in
L(V)
- φ memberOf Γ is an atomic formula in
L(V)
- φ[ p ofType Δ ] is an atomic
formula in L(V)
- φ[ s impliesType Δ ] is an atomic
formula in L(V)
- φ[ s impliesType Γ ] is an atomic
formula in L(V)
- φ[ p hasValue ψ ] is an atomic
formula in L(V)
- φ[ s hasValue Val ] is an atomic
formula in L(V)
These are the only atomic formulae allowed in WRL Core, i.e.,
compared with general logical expressions, WRL core only allows
ground facts.
Let Var1, Var2, ... be
arbitrary WRL variables. We call molecules of the form
Vari memberOf Γ
a-molecules, and molecules of the forms ,
Vari[ p hasValue
Vark ] and Vari[ p
hasValue {Vark1,
Varkl} ] b-molecules, respectively.
In the following, F stands for an lhs-formula, with the
set of lhs-formulae defined as follows:
- Any b-molecule is an lhs-formula
- if F1 and F2 are
lhs-formulae, then F1 and
F2 is an lhs-formula
- if F1 and F2 are
lhs-formulae, then F1 or
F2 is an lhs-formula
In the following, G,H stand for rhs-formulae, with the
set of rhs-formulae defined as follows:
- Any a-molecule is an rhs-formula
- if G and H are rhs-formulae, then G
and H is an rhs-formula
Definition 2.4. The set
of WRL-Core formulae is defined as follows:
- Any atomic formula is a formula in L(V).
- If F1,...Fn are atomic
formulae, then F1 and ... and
Fn is a formula in L(V).
- Var1[ p hasValue
Var2 ] impliedBy
Var1[ p hasValue
Var3 ] and Var3[
p hasValue Var2 ] (globally
transitive attribute/relation) is a formula in
L(V).
- Var1[ p hasValue
Var2 ] impliedBy
Var2[ p hasValue
Var1 ] (globally symmetric
attribute/relation) is a formula in L(V).
- Var1[ p hasValue
Var2 ] impliedBy
Var1[ q hasValue
Var2 ] (globally
sub-attribute/relation)) is a formula in
L(V).
- Var1[ p hasValue
Var2 ] impliedBy
Var2[ q hasValue
Var1 ] (globally inverse
attribute/relation)) is a formula in L(V).
- G equivalent H is a formula in
L(V) if it contains only one WRL variable.
- H impliedBy F is a formula in
L(V) if all the WRL variables occurring in H occur in F
as well and the variable graph of F is connected
and acyclic.
- If, for WRL-Core formulae D and E,
D impliedBy E is a formula in
L(V), then Body implies
Head is a
formula in L(V) .
- Any occurrence of a molecule of the form
Var1[ p hasValue
Var2 ] in a WRL-Core clause can be
interchanged with
p(Var1,Var2) (i.e.,
these two forms can be used interchangeably in WRL
Core).
Any WRL-Core formula together with a period '.' is
a logical expression in WRL-Core.
Here, the variable graph of a formula E,
defined as the undirected graph having all variables in E as
nodes and an edge between Var2 and
Var2 for every molecule
Var1[p hasValue
Var2], or
p(Var1,Var2),
respectively, then E is an admissible WRL-Core
formula.
Note that wherever an a-molecule (or b-molecule) is allowed in
a WRL-Core clause, compound molecules abbreviating conjunctions
of a-molecules (or b-molecules, respectively), as mentioned at
the end of this section.
The following are examples of WRL-Core logical expressions:
The attribute 'hasAncestor' is transitive:
?x[hasAncestor hasValue ?z] impliedBy ?x[hasAncestor hasValue ?y] and ?y[hasAncestor hasValue ?z].
A female person is a woman:
?x memberOf Woman impliedBy ?x memberOf
Person and ?x memberOf Female
A student is a person:
Student subConceptOf Person.
WRL-Flight is a rule language based on the Datalog subset of
F-Logic, extended with locally stratified default negation, the
inequality symbol '!=' and the unification operator '='.
Furthermore, WRL-Flight allows monotonic Lloyd-Topor [Lloyd and Topor, 1984], which means that we
allow classical implication and conjunction in the head of a rule
and we allow disjunction in the body of a rule.
The head and the body of a rule are separated using the Logic
Programming implication symbol ':-'. This additional
symbol is required because negation-as-failure (naf) is
not defined for classical implication (implies,
impliedBy). WRL-Flight allows classical implication in the
head of the rule. Consequently, every WRL-Core logical
expression is a WRL-Flight rule with an empty body.
We define the notion of
a WRL-Flight vocabulary in Definition 2.5.
Definition 2.5.
Any WRL vocabulary (see Definition
2.1) is a WRL-Flight vocabulary.
Definition 2.6
defines the set of WRL-Flight terms
TermFlight(V) for a given vocabulary
V.
Definition 2.6. Given
a vocabulary V, the set of terms
TermFlight(V) in WRL-Flight is defined as
follows:
- Any f ∈ VO is a term.
- Any v ∈ VV is a term
- If d ∈ VD and
dv1, ..., dvn are in
VDV ∪ VV, then
d(dv1, ..., dvn) is a
term.
As usual, the set of ground terms
GroundTermFlight(V) is the greatest subset of
TermFlight(V) in which no variables occur.
Definition 2.7. Given a
set of WRL-Flight terms TermFlight(V), an
atomic formula in L(V) is defined by:
- If r ∈ VR and
t1, ..., tn are terms, then
r(t1, ..., tn) is an atomic
formula in L(V).
- If α, β ∈
TermFlight(V) then α =
β, and α != β are
atomic formulae in L(V).
- If α, β ∈
TermFlight(V) and γ ∈
Term(V) or γ is of the form {
γ1,...,γn }
with γ1,...,γn
∈ TermFlight(V), then:
- α subConceptOf γ is an atomic
formula in L(V)
- α memberOf γ is an
atomic formula in L(V)
- α[β ofType
γ] is an atomic formula in
L(V)
- α[β impliesType
γ] is an atomic formula in
L(V)
- α[β hasValue
γ] is an atomic formula in
L(V)
A ground atomic formula is an atomic formula with no
variables.
Definition 2.8.
Given a WRL-Flight vocabulary V, the set of formulae in
L(V) is recursively defined as follows:
- We define the set of admissible head formulae
Head(V) as follows:
- Any atomic formula α which does not contain the
inequality symbol (!=) or the unification operator (=) is
in Head(V).
- Let α,β ∈ Head(V),
then α and β is in
Head(V).
- α implies β is in
Head(V) .
- α impliedBy β is in
Head(V).
- α equivalent β is in
Head(V).
- Any variable-free admissible head formula in Head(V) is a formula
in L(V).
- We define the set of admissible body formulae
Body(V) as follows:
- Any atomic formula α is in
Body(V)
- For α ∈ Body(V), naf
α is in Body(V).
- For α,β ∈ Body(V),
α and β is in
Body(V).
- For α,β ∈ Body(V),
α or β is in
Body(V).
- Given a head-formula β ∈ Head(V)
and a body-formula α ∈ Body(V),
β :- α is a formula. Here we
call α the body and β the
head of the formula. The formula is admissible if (1)
α is an admissible body formula, (2) β
is an admissible head formula, and (3) the safety
condition holds.
- Any formula of the form !- α with
α ∈ Body(V) is an admissible formula
and is called a constraint.
Any WRL-Flight admissible formula together with a period '.' is
a logical expression in WRL-Core.
In order to check the safety condition for a
WRL-Flight rule, the following transformations should be applied
until no transformation rule is applicable:
- Rules of the form A1 and ...
and An :- B are split
into n different rules:
- Rules of the form A1 equivalent
A2 :- B are split into 2 rules:
- A1 implies
A2 :- B
- A1 impliedBy
A2 :- B
- Rules of the form A1 impliedBy
A2 :- B are transformed to:
- Rules of the form A1 implies
A2 :- B are transformed to:
- Rules of the form A :- B1
or ... or Bn are split into
n different rules:
Application of these transformation rules yields a set of
WRL-Flight rules with only one atomic formula in the head and a
conjunction of literals in the body.
The safety condition holds for a WRL-Flight rule if every
variable which occurs in the rule occurs in a positive body
literal which does not correspond to a built-in predicate. For
example, the following rules are not safe and thus not allowed in
WRL-Flight:
p(?x) :- q(?y).
a[b hasValue ?x] :- ?x > 25.
?x[gender hasValue male] :- naf ?x[gender hasValue female].
We require each WRL-Flight knowledge base to be locally
stratified. Appendix A of [Kifer et
al., 1995] explains local stratification for a frame-based
logical language.
The following are examples of WRL-Flight logical expressions
(note that variables are implicitly universally quantified):
No human can be both male and female:
!- ?x[gender hasValue {?y, ?z}] memberOf Human and ?y = Male and ?z = Female.
The brother of a parent is an uncle:
?x[uncle hasValue ?z] impliedBy ?x[parent hasValue ?y] and ?y[brother hasValue ?z].
Do not trust strangers:
?x[distrust hasValue ?y] :- naf ?x[knows hasValue ?y].
The WRL-Full logical expression syntax extends WRL-Flight by
allowing unsafe rules, full Lloyd-Topor (i.e., arbitrary
first-order formulas in the body of a rule), and unstratified
negation (under the Well-Founded Semantics).
We start with the definition of the basic vocabulary for
building logical expressions. Then, we define how the elements of
the basic vocabulary can be composed in order to obtain
admissible logical expressions. Definition 2.1 defines
the notion of a vocabulary V of a WRL language
L.
WRL allows the following connectives: and,
or, implies, impliedBy, equivalent,
naf, forall and exists and the following
auxiliary symbols: '(', ')', '[', ']', ',', '=',
'!=', memberOf, hasValue,
subConceptOf, ofType, and impliesType.
Furthermore, WRL allows use of the symbol ':-' for Logic
Programming rules and the use of the symbol '!-' for
database-style constraints.
Definition 2.9
defines the set of terms Term(V) for a given vocabulary
V.
Definition 2.9. Given
a vocabulary V, the set of terms Term(V) in
WRL-Full is defined as follows:
- Any f ∈ VO is a term.
- Any v ∈ VV is a term
- If f ∈ VF and
t1, ..., tn are terms, then
f(t1, ..., tn) is a
term.
- If f ∈ VD and
dv1, ..., dvn are in
VDV ∪ VV, then
f(dv1, ..., dvn) is a
term.
As usual, the set of ground terms
GroundTerm(V) is the greatest subset of
Term(V) in which no variables occur.
Based on the basic constructs of logical expressions, the
terms, we can now define formulae. In WRL, we have atomic
formulae and complex formulae. A logical expression consists of a
formula terminated by a period.
Definition 2.10. Given a
set of WRL-Full terms Term(V), an atomic formula in
L(V) is defined by:
- If r ∈ VR and
t1, ..., tn are terms, then
r(t1, ..., tn) is an atomic
formula in L(V).
- If α, β ∈
TermRule(V) then α =
β, and α != β are
atomic formulae in L(V).
- If α, β ∈
TermRule(V) and γ ∈
Term(V) or γ is of the form {
γ1,...,γn }
with γ1,...,γn
∈ TermRule(V), then:
- α subConceptOf γ is an atomic
formula in L(V)
- α memberOf γ is an
atomic formula in L(V)
- α[β ofType
γ] is an atomic formula in
L(V)
- α[β impliesType
γ] is an atomic formula in
L(V)
- α[β hasValue
γ] is an atomic formula in
L(V)
A ground atomic formula is an atomic formula with no
variables.
Definition 2.11.
Given a WRL-Full vocabulary V, the set of formulae in
L(V) is recursively defined as follows:
- We define the set of admissible head formulae
Head(V) as follows:
- Any atomic formula α which does not contain the
inequality symbol (!=) or the unification operator (=) is
in Head(V).
- Let α,β ∈ Head(V),
then α and β is in
Head(V).
- α implies β is in
Head(V) .
- α impliedBy β is in
Head(V).
- α equivalent β is in
Head(V).
- Any admissible head formula in Head(V) is a formula
in L(V).
- We define the set of admissible body formulae
Body(V) as follows:
- Any atomic formula α is in
Body(V)
- For α ∈ Body(V), naf
α is in Body(V).
- For α,β ∈ Body(V),
α and β is in
Body(V).
- For α,β ∈ Body(V),
α or β is in
Body(V).
- For α,β ∈ Body(V),
α implies β is in
Body(V).
- For α,β ∈ Body(V),
α impliedBy β is in
Body(V).
- For α,β ∈ Body(V),
α equivalent β is in
Body(V).
- For variables ?x1,...,?xn and
α ∈ Body(V),
forall ?x1,...,?xn
(α) is in
Body(V).
- For variables ?x1,...,?xn and
α ∈ Body(V),
exists ?x1,...,?xn
(α) is in
Body(V).
- Given a head-formula β ∈ Head(V)
and a body-formula α ∈ Body(V),
β :- α is a formula. Here we
call α the body and β the
head of the formula. The formula is admissible if (1)
α is an admissible body formula, (2) β
is an admissible head formula.
- Any formula of the form !- α with
α ∈ Body(V) is an admissible formula
and is called a constraint.
Any WRL-Full admissible formula followed by a dot '.' is a WRL logical
expression.
The precedence of the operators is as follows: implies,
equivalent, impliedBy < or, and < naf. Here,
op1 < op2 means that
operator op2 binds stronger than operator
op1. The precedence prevents extensive use of
parentheses and thus helps to achieve a better readability of
logical expressions.
To enhance the readability of logical expressions it is
possible to abbreviate a conjunction of several molecules with the
same subject as one compound molecule. E.g., the three
molecules
Human subConceptOf Mammal
and Human[hasName ofType foaf#name] and Human[hasChild impliesType Human]
can be written as
Human[hasName ofType foaf#name, hasChild impliesType Human] subConceptOf Mammal
The following are examples of WRL-Full logical expressions:
Both the father and the mother are parents:
?x[parent hasValue ?y] :- ?x[father hasValue ?y] or ?x[mother hasValue ?y].
Every person has a father:
?x[father hasValue f(?x)] :- ?x memberOf Person.
There may only be one distance between two locations, and
the distance between locations A and B is
the same as the distance between B and A:
!- distance(?location1,?location2,?distance1) and
distance(?location1,?location2,?distance2) and ?distance1 != distance2.
distance(?B,?A,?distance) :-
distance(?A,?B,?distance).
In the previous chapter we have defined the conceptual and
logical expression syntax for different WRL variants. We have
mentioned several characteristics of the semantics of different
variants, but we have not defined the semantics itself. This
chapter specifies the formal semantics for the WRL variants.
In the following we provide first a mapping between the
conceptual syntax for ontologies and the logical expression
syntax for that part of the conceptual syntax which has a meaning
in the logical language. We then provide a semantics for
WRL-Core, WRL-Flight and WRL-Full through mappings to existing
logical formalisms.
In order to be able to specify the WRL semantics in a concise
and understandable way, we first translate the conceptual syntax
to the logical expression syntax.
Before we translate the conceptual syntax to the logical
expression syntax, we perform the following pre-processing
steps:
- Introduce unnumbered anonymous identifiers (see
Section 2.1.3) for missing
identifiers.
- Remove all non-functional properties from the conceptual
model.
- Replace idlists with single ids for
subRelationOf.
E.g., "P subRelationOf {Q, R}" is
substituted by "P subRelationOf Q" and
"P subRelationOf R".
- Expand all sQNames to full IRIs using the namespace
declarations.
Table 3.1 contains the mapping between the WRL conceptual
syntax for ontologies and the logical expression syntax through
the mapping function τ (X and Y are
meta-variables and are replaced by actual identifiers or
variables during the translation itself; pnew
is a newly introduced predicate). In the table, italic keywords
refer to productions in the WRL grammar (as explained in the
previous chapter) and boldfaced keywords refer to keywords in the
WRL language.
Table 3.1: Mapping WRL conceptual syntax to logical
expression syntax.
| WRL Conceptual Syntax |
WRL Logical Expression Syntax |
| τ(ontology) |
τ(ontology_element1)
... τ(ontology_elementn) |
| τ(concept id superconcept attribute1 ...
attributen) |
τ(superconcept, id) τ(attribute1,
id) ... τ(attributen,
id) |
| τ(subConceptOf idlist, X) |
X subConceptOf idlist. |
| τ(attribute_id
attributefeature
impliesType cardinality range_idlist, X) |
?x memberOf X and ?x[attribute_id hasValue ?y] implies ?y
memberOf range_idlist.
τ(cardinality, X,
attribute_id)
τ(attributefeature,
X, attribute_id) |
| τ(attribute_id
attributefeature
ofType cardinality range_idlist, X) |
!- ?x memberOf X and
?x[attribute_id
hasValue ?y] and naf ?y memberOf range_idlist.
τ(cardinality, X,
attribute_id)
τ(attributefeature,
X, attribute_id) |
| τ(transitive, X, Y) |
?x memberOf X and ?y memberOf
X and ?x[Y hasValue ?y] and
?y[Y hasValue ?z] implies ?x[Y
hasValue ?z]. |
| τ(symmetric, X, Y) |
?x memberOf X and ?y memberOf
X and ?x[Y hasValue ?y] implies
?y[Y hasValue ?x]. |
| τ(reflexive, X, Y) |
?x memberOf X implies ?x[Y
hasValue ?x]. |
| τ(inverseOf(att_id), X, Y) |
?x memberOf X and ?x[Y
hasValue ?y] implies ?y[att_id hasValue ?x].
?y memberOf X and ?x[att_id hasValue ?y] implies
?y[Y hasValue ?x]. |
| τ((n), X,
Y) |
τ((n n), X,
Y) |
| τ((n m), X,
Y) |
τ((n *), X,
Y)
τ((0 m), X, Y) |
| τ((n *), X,
Y) |
pnew(?x) :- ?x memberOf
X and ?x[Y hasValue
?y1, ...,Y hasValue
?yn] and ?y1 != ?y2 and
?y1 != ?y3 and ... and
?yn-1 != ?yn.
!- ?x memberOf x and naf
pnew(?x). |
| τ((0 m), X,
Y) |
!- ?x memberOf X and ?x[Y
hasValue ?y1, ...,Y hasValue
?ym+1] and ?y1 != ?y2 and
?y1 != ?y3 and ... and ?ym
!= ?ym+1. |
| τ(relation id/arity superrelation) |
τ(superrelation, id, arity) |
| τ(subRelationOf id, X, Y) |
X(?x1,...,?xY)
implies id(?x1,...,?xY). |
| τ(instance id memberof attributevalue1
... attributevaluen) |
τ(memberof,
id) τ(attributevalue1,
id) τ(attributevaluen,
id) |
| τ(memberOf idlist, X) |
X memberOf idlist. |
| τ(att_id
hasValue valuelist, X) |
X[att_id
hasValue valuelist]. |
| τ(axiom id
log_expr) |
log_expr |
As an example, we translate the following WRL ontology:
namespace {_"http://www.example.org/ontologies/example#",
dc _"http://purl.org/dc/elements/1.1#",
foaf _"http://xmlns.com/foaf/0.1/",
xsd _"http://www.w3.org/2001/XMLSchema#",
wrl _"http://www.wsml.org/wsml/wrl-syntax#",
loc _"http://www.wsmo.org/ontologies/location#"}
ontology Family
nfp
dc#title hasValue "WRL example ontology"
endnfp
concept Human subConceptOf { Primate, LegalAgent }
nonFunctionalProperties
dc#description hasValue "concept of a human being"
endNonFunctionalProperties
hasName ofType foaf#name
relation ageOfHuman/2 (ofType Human, ofType _integer)
nonFunctionalProperties
dc#relation hasValue FunctionalDependencyAge
endNonFunctionalProperties
axiom FunctionalDependencyAge
definedBy
!- ageOfHuman(?x,?y1) and
ageOfHuman(?x,?y2) and wrl#numericInequal(?y1,?y2).
To the following logical expressions:
_"http://www.example.org/ontologies/example#Human"[_"http://www.example.org/ontologies/example#hasName" ofType
_"http://xmlns.com/foaf/0.1/name"].
_"http://www.example.org/ontologies/example#Human" subConceptOf
{ _"http://www.example.org/ontologies/example#Primate",
_"http://www.example.org/ontologies/example#LegalAgent" }.
!- naf ?x memberOf_"http://www.example.org/ontologies/example#Human" and
_"http://www.example.org/ontologies/example#ageOfHuman"(?x,?y).
!- naf ?y memberOf _integer and _"http://www.example.org/ontologies/example#ageOfHuman"(?x,?y).
!- _"http://www.example.org/ontologies/example#ageOfHuman"(?x,?y1) and
_"http://www.example.org/ontologies/example#ageOfHuman"(?x,?y2) and _"http://www.wsml.org/wsml/wrl-syntax#numericInequal"(?y1,?y2).
In order to make the definition of the WRL semantics more
straightforward, we define a number of preprocessing steps to be
applied to the WRL logical expressions. We identify the following
preprocessing steps in order to obtain a suitable set of logical
expressions which can be readily mapped to a logical
formalism:
- Replacing idlists with multiple statements
- Statements involving argument lists of the form
A op
{v1,...,vn}, with op
∈ {hasValue, ofType, impliesType},
are replaced by multiple statements in the following way:
A op v1, ...,
A op vn.
Statements involving argument lists of the form A
is-a {c1,...,cn},
with is-a ∈ {memberOf, subConceptOf},
are replaced by a conjunction of statements in the following
way: A op c1
and ... and A op
cn.
- Reducing composed molecules to single molecules
-
Composed molecules are split into singular molecules in two
steps:
- Molecules of the form a is-a
b[c1 op1
d1,..., cn
opn dn], with
is-a ∈ {memberOf, subConceptOf}
and opi ∈ {hasValue,
ofType, impliesType} are transformed to:
a is-a b and
a[c1 opn
d1,..., cn
opn dn]
- Then, attributes of the form
a[c1 op1
d1,..., cn
opn dn], with
opi ∈ {hasValue,
ofType, impliesType}, are translated to:
a[c1 op1
d1] and ... and
a[cn opn
dn]
- Rewriting data term shortcuts
- The shortcuts for writing strings, integers and decimals
are rewritten to their full form:
"string" := _string("string") (unless
"string" already occurs in the _string datatype
wrapper)
integer := _integer("integer")
decimal := _decimal("decimal")
- Rewrite data terms to predicates
- Data terms occur as functions in WRL. However, Datalog does
not allow the use of function symbols. Thus, we rewrite the
datatype wrappers to built-in predicates as follows:
Each datatype wrapper with arity n has a corresponding
built-in predicate with the same name as the datatype wrapper
(cf. Appendix A). This built-in
predicate always has an arity n+1. Each occurrence of
a datatype wrapper δ in a statement φ is replaced
with a new variable ?x and the datatype predicate
corresponding to the wrapper δ is conjoined with the
resulting statement φ': (φ' and
δ(X1,...,X1,?x)).
- Rewrite built-in functions to predicates
- Built-in functions are replaced with predicates similar to
datatype wrappers. Each of the built-in predicates
corresponding to built-in functions mentioned in Appendix A contains one argument which is
the result. The occurrence of the function is replaced with a
variable and the statement is replaced with the conjunction of
that statement and the built-in predicate.
- Unfolding sQNames to full IRIs
- Finally, all sQNames in the syntax are replaced with full
IRIs, according to the rules defined in Section 2.2.
The resulting set of logical expressions does not contain any
syntactical shortcuts and can be used directly for the definition
of the semantics of the respective WRL variants.
In order to define the semantics of WRL-Core, we first define
the notion of a WRL-Core knowledge base in Definition 3.1.
Definition 3.1. We define a WRL-Core knowledge base
KB as a collection of formulas written in the WRL
logical expression language which are the result of application
of the translation function τ of Table 3.1 and the
preprocessing steps defined in Section 3.2 to a WRL-Core
ontology.
We define the semantics of WRL-Core through a mapping to
Datalog (under minimal Herbrand mod