Abstract

SPARQL is a query language for data that is stored natively
as RDF or viewed as RDF via middleware. What the correct answers
to a SPARQL query are, depends on the used entailment regime
and the vocabulary from which the resulting answers can be
taken. SPARQL 1.1 Query [SPARQL 1.1 Query] defines basic
graph pattern matching only for simple
entailment, but it defines a set of conditions that have
to be met when defining what correct results are for SPARQL
queries under different entailment regimes. The goal of this
document is to specify conditions such that SPARQL can be used
with some other entailment regimes beyond simple entailment.

Change Summary

The first public working draft defined the semantics of SPARQL queries under
RDF and
RDFS entailment.
In the second public working draft the RDF and RDFS entailment regimes have been changed to use a Skolemized version of the queried RDF triples to limit the
possible answers to a finite set of answers. This prevents non-local effects that caused additional results for existing triples from unrelated newly added
triples that contain new blank nodes. Further, an entailment regime for OWL Direct Semantics was added, which covers the OWL 2 DL, EL,
and QL Profiles.

The current working draft also includes entailment regimes for
D-entailment, OWL with RDF-Based Semantics including the
OWL 2 RL Profile, and an entailment regime for the (safe) core dialect of the rule interchange
format RIF. All regimes now take answers from the vocabulary of the queried graph and a vocabulary for the
regime. As a consequence, very few entailed triples are omitted from the answers, while finiteness is preserved even under inconsistencies. The OWL Direct
Semantics regime has been revised to make the mapping from triples in the basic graph pattern to OWL objects more precise. A grammar is used to define
well-formed queries for the regime, which simplifies the conditions on answers. The OWL RL profile has also been added for the OWL 2 Direct Semantics
entailment regimes. The previous modifications to the OWL Direct Semantics entailment relation have been removed. Queries for annotations might be added in
a future version of the specification in a regime that extends the OWL 2 Direct Semantics regime.

Status of this Document

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/.

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.

1 Introduction

The SPARQL 1.1 Query specification [SPARQL 1.1 Query] defines only simple entailment, which allows for finding answers by matching the triple
pattern of the query onto the RDF graph of the queried data. Other entailment regimes, such as RDFS entailment, allow for finding answers to a query
that are not directly specified in the queried graph, but can be inferred using a set of inference rules. In this document, we specify how SPARQL can be
used with some other entailment regimes beyond simple entailment.

SPARQL Entailment Regimes is closely related to the following specifications:

References to RDF or RDFS entailment rules from the RDF Semantics
specification are in some places used in an informative way and implementations are not expected to implement these rules as they are used here.

1.1 Document Conventions

Throughout the document, certain conventions are used, which are outlined below.

1.1.1 Graph Syntax

This document uses the Turtle [TURTLE] data format to show triples explicitly. This notation uses a node identifier (nodeID)
convention to indicate blank nodes in the triples of a graph. While node identifiers such as _:xxx serve to identify blank nodes in
the surface syntax, these expressions are not considered to be the label of the graph node they identify; they are not names, and do not occur
in the actual graph. In particular, the RDF graphs described by two Turtle documents which differ only by re-naming their blank node
identifiers will be understood to be equivalent. This re-naming convention should be understood as applying only to whole documents, since
re-naming the node identifiers in part of a document may result in a document describing a different RDF graph. A generated blank node may also
be denoted with [].

IRIs are written enclosed in < and > and may be absolute RDF IRI References or relative to the current base
IRI. IRIs may also be abbreviated by using Turtle's @prefix directive that allows declaring a short prefix name for a long prefix
of repeated IRIs. Once a prefix such as @prefix foo: <http://example.org/ns#> is defined, any mention of an IRI later in the
document may use a qualified name that starts foo: to stand for the longer IRI. For example, the qualified name foo:bar is a
shorthand for the IRI <http://example.org/ns#bar>.

For example, the following triples use prefixes and abbreviated IRIs and also the non-abbreviated IRI <book2>, which
is relative to the base IRI of the document.

Standard Turtle abbreviatens are taken to be expanded into their full form in
the queried graph and the query. Since the entailment regimes use the vocabulary of the queried graph to constrain the solutions, this means that,
e.g., when a is used in a predicate position it is considered to be expanded to rdf:type before the query is answered.
Similarly, abbreviations for lists etc. in the queried graph are considered to be expanded into their full form. E.g., if a Turtle document contains
a list of the form ( ex:a ex:b ), it is assumed that vocabulary of the queried graph contains rdf:first,
rdf:rest, and rdf:nil because the expanded form of the list is
[ rdf:first ex:a; rdf:rest [ rdf:first ex:b; rdf:rest rdf:nil ] ].

In the interests of brevity, the prefix ex: is also used in the examples. The prefix is assumed to be bound to an imaginary IRI
such as <http://www.example.org/>.

1.1.3 Preliminary Definitions

This document uses the same definitions as the
SPARQL Query Language specification. Important terms are recaptured below for clarity.
In the case of any differences, the SPARQL Query Language definitions are the normative ones.

The term I denotes the set of all IRIs, RDF-L the set of all RDF Literals, and RDF-B the set of all blank nodes in RDF graphs.

The set of RDF Terms, RDF-T, is I ∪ RDF-L ∪ RDF-B.

The set of query variables is denoted as V and V is assumed to be countable, infinite, and disjoint from RDF-T.
A triple pattern is member of the set:

(RDF-T ∪ V) x (I ∪ V) x (RDF-T ∪ V),

A basic graph pattern (BGP) is a set of triple patterns.

1.1.4 Result Descriptions

Result sets are illustrated in tabular form.

x

y

z

"Alice"

<http://example/a>

A 'binding' is a pair (variable, RDF term). In this result set, there are three
variables: x, y, and z (shown as column headers). Each solution is shown as one row in the body of the
table. Here, there is a single solution, in which variable x is bound to "Alice", variable y is
bound to <http://example/a>, and variable z is not bound to an RDF term. Variables are not required to be bound
in a solution.

Sometimes solutions are annotated with the name of a solution mapping so that the explanatory text can refer to the solution mapping and
explain or justify certain solutions. For example, in the results table below, the only solution is given by the solution mapping
μ1:

x

y

z

μ1

"Alice"

<http://example/a>

1.2 Effects of Different Entailment Regimes

The SPARQL Query specification already envisages that SPARQL can be used with entailment regimes other than simple entailment. To illustrate the
differences between simple, RDF, and RDFS entailment, consider the following data:

Clearly, ex:book1 is an answer due to triple (1). Intuitively, we can expect that ex:book2 is also a publication
because it is an article (2) and all articles are publications (3). Even ex:book3 is a publication because it is published by MIT Press
(5) and everything that is published is a publication (4). Under simple and RDF entailment, ex:book1 is the only answer because a
system that uses simple entailment will not perform any of the reasoning steps that were required to find that ex:book2 and
ex:book3 are publications. Under simple entailment, the basic graph pattern ?pub a ex:Publication is
mapped to the queried graph and variables act as a kind of wild-card, e.g., by mapping ?pub to ex:book1 the BGP matches.
RDF already supports a few inferences, but not those that are required to derive that ex:book2 and ex:book3 are
publications. In order to retrieve ex:book2 and ex:book3, one would need a system that supports RDFS entailment.
RDFS entailment rules can be used to
illustrate which new consequences can be derived from the given data. E.g., the rule rdfs9 can be applied to the triples (3) and (2) to
derive

(6) ex:book2 a ex:Publication .

The rule rdfs3 can be applied to (4) and (5) to derive

(7) ex:book3 a ex:Publication .

The triples (6) and (7) can then be used to find that ex:book2 and ex:book3 are also answers to the query under an RDFS
entailment regime. The difference between RDF and simple entailment is less significant since RDF supports only few inferences. Consider, for
example, the following query:

SELECT ?prop WHERE { ?prop a rdf:Property }

Under simple entailment the query has an empty answer when querying the above graph. Under RDF entailment, the
RDF rulerdf1 can be used on (5) to
derive the triple ex:publishes a rdf:Property which means that ex:publishes is a valid binding for
?prop and will be returned as an answer for the query from a system that uses RDF entailment. The OWL 2 Web Ontology Language allows for even more inferences. The remainder of this document specifies
what correct answers are for the different entailment regimes.

1.3 Extensions to Basic Graph Pattern Matching

The SPARQL Query specification [SPARQL 1.1 Query] gives a set of conditions that have to be met
when extending the basic graph pattern matching to other entailment regimes:

An entailment regime specifies

A subset of RDF graphs called well-formed for the regime

An entailment relation between subsets of well-formed graphs and well-formed graphs.

Since the OWL 2 Direct Semantics is, for example, only defined for certain well-formed of RDF graphs, the first condition can be used to define
an OWL 2 Direct Semantics entailment regime only over those RDF graphs that represent an OWL 2 DL ontology. For the entailment relations mentioned
in the second condition, this specification uses entailment relations that are already specified and used on the Semantic Web such as RDF(S)
entailment or OWL Direct Semantics entailment.

SPARQL Query further defines a set of conditions for extensions of the basic
graph pattern matching. These conditions do not cover the case of inconsistent graphs. The effect of a query on an inconsistent graph has to be
covered by the particular entailment regimes. The relevant details for each of the specified entailment regimes can be found in the corresponding
section for that entailment regime. The SPARQL Query conditions for consistent active graphs are repeated below for clarity and are followed by an
overview of how the different entailment regimes satisfy them.

The scoping graph, SG, corresponding to any
consistent active graph AG is uniquely specified up to RDF graph equivalence and is E-equivalent to AG.

For any basic graph pattern BGP and pattern instance mapping P, P(BGP) is well-formed for E.

For any scoping graph SG and answer set
{P1 ... Pn} for a basic graph pattern BGP, and where {BGP1 .... BGPn} is a set of basic graph
patterns all equivalent to BGP, none of which share any blank nodes with any other or with SG

SG E-entails (SG union P1(BGP1) union ... union Pn(BGPn))

These conditions do not fully determine the set of possible answers, since RDF allows unlimited amounts of redundancy. In addition, therefore,
the following must hold.

Each SPARQL extension MUST provide conditions on answer sets which guarantee that the set of
triples obtained by instantiating BGP with each solution μ is uniquely specified up to RDF graph equivalence, and SHOULD
provide further conditions to prevent trivial infinite answers as appropriate to the regime.

This specification does not change any of the existing entailment relations, but rather defines the vocabulary from which possible answers can be
taken and which answers are legal answers in order to guarantee that query answers are always finite. The set of legal graphs, i.e., graphs that can
be queried, is also unrestricted apart from the restriction to graphs that are legal under the entailment regime in question. E.g., under the RDFS
entailment regime, one can query all legal RDF graphs, while under OWL 2 Direct Semantics, one can query all graphs that correspond to legal OWL 2
DL ontologies. Further, it is defined which queries are legal and how illegal queries, illegal graphs, and inconsistencies are handled. All defined
entailment regimes satisfy the above conditions as follows:

Only mappings that, when applied to the BGP, yield a set of RDF triples that are well-formed for E are legal solution mappings and
included in the answer. For example, under RDFS entailment, any SPARQL query is legal, but queries that require literals as a binding for a
variable in a subject position have no answer because all mappings that result in a set of RDFS entailed triples are not well-formed RDF since
RDF forbids literals in the subject position. Similarly, for OWL 2 DL entailment, a query might have no answer because all possible bindings
might result in RDF triples that are not well-formed for OWL 2 DL.

This condition prevents the reuse of blank nodes between query answers unless those blank nodes are really the same in the queried
graph. Under this restriction no accidental co-references among blank nodes are introduced. All entailment regimes use the same definition of a
scoping graph as simple entailment. The condition is satisfied since a form
of Skolemization is used to restrict the answers containing blank nodes.

This point is very important since infinite answers are easily possible under all the considered regimes. For example, already under RDF and
RDFS entailment, even the empty graph entails an infinite number of axiomatic triples such as
rdf:_1 a rdf:Property, rdf:_2 a rdf:Property, ... Thus, a query with BGP { ?x a
rdf:Property . } would, without further restrictions, have infinitely many answers. Such answers are to be understood as trivial infinite
answers. Other sources of trivial infinite answers are answers that only differ in blank node labels. In order to exclude such sources of
infinity, the entailment regimes will define a (finite) vocabulary from which bindings can be taken. We explain these restrictions in greater
detail in the following sections.

2 RDF Entailment Regime

RDF entailment is closest to simple entailment in that it provides only few additional answers and RDF is not expressive enough to express
inconsistencies. RDF does, however, entail an infinite set of axiomatic triples and the entailment regime specifies conditions that address the
forth condition on extensions of basic graph pattern matching.

Name

RDF

URI

http://www.w3.org/ns/entailment/RDF

Legal Graphs

Any legal RDF graph.

Legal Queries

Any legal SPARQL query.

Illegal handling

In case the query is illegal (syntax errors), the system MUST raise a
MalformedQuery fault. In case the queried graph is illegal
(syntax errors), the system MUST raise a QueryRequestRefused fault.

RDF graphs are always RDF consistent and no inconsistency handling is required.

Query Answers

Let G be the queried RDF graph, BGP be a basic graph pattern, V(BGP) the set of variables in BGP, B(BGP) the set of blank nodes in BGP, SG
the scoping graph for G and BGP, sk(SG) a
Skolemization of SG with respect to a vocabulary disjoint from the vocabulary of SG
and BGP, and P=(μ, σ) a pattern instance mapping.
Let P(BGP) denote the result of replacing each variable v from V(BGP) for which μ is defined with μ(v) and each blank
node b from B(BGP) for which σ is defined with σ(b). Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t
otherwise. Let sk(P(BGP)) denote the result of replacing each blank node b in P(BGP) for which sk is defined with sk(b). The term
rdfV refers to the RDF vocabulary and rdfV-Minus is the set of URI
references in rdfV minus URI references of the form rdf:_n with n in {1, 2, ... }.

A solution mapping μ is a possible solution for BGP from G under RDF entailment if dom(μ) = V(BGP) and there is an RDF
instance mapping σ from B(BGP) to RDF-T such that dom(σ)=B(BGP) and the pattern instance mapping P=(μ, σ) is such that
P(BGP) are well-formed RDF triples that are RDF entailed by SG.

A possible solution μ is a solution for BGP from SG under RDF entailment if:

(C1) The RDF triples sk(P(BGP)) are ground and RDF entailed by sk(SG).

(C2) For each variable x in V(BGP), sk(μ(x)) occurs in sk(SG) or in rdfV-Minus.

Please note that legal answers under RDF entailment are defined in a two-stage process. Intuitively, the possible answers are all
answers that one would expect under RDF entailment, i.e., all mappings such that instantiating the basic graph patterns with them results in RDF
triples that are RDF entailed by the queried graph. The set of possible answers is, however, not necessarily finite. The next step defines which of the
possible answers are actually returned as answers to the query. In this step, we restrict answers to those that correspond to ground triples that are
entailed by the Skolemized scoping graph (C1). This limits infinite answers from blank nodes, while still preserving most users' expectations of the
cardinality of the answers. Condition C2 further makes sure that the query answer contains only finitely many of the axiomatic triples. The two
restrictions are further explained below.

2.1 Blank Nodes in the Queried Graph (Informative)

The following example illustrates the use of condition C1. Consider the query

SELECT ?s ?o WHERE { ?s ex:b ?o }

against a (scoping) graph containing only the triples

ex:a1 ex:b _:c1 .
ex:a1 ex:b _:c2 .
ex:a2 ex:b _:c3 .

Simple entailment would give the solutions

s

o

μ1

ex:a1

_:c1

μ2

ex:a1

_:c2

μ3

ex:a2

_:c3

Since blank nodes only denote the existence of something and the actual blank node names do not matter, the following solution mappings are also
possible solutions under RDF entailment (simple entailment restricts solutions to subgraphs of the queried graph):

s

o

μ4

ex:a1

_:c3

μ5

ex:a1

_:whatever

ex:a1

...

Observe that, for instance, the inclusion of solution μ4 invalidates condition 3 from the SPARQL Query
specification. This condition requires that SG entails the union of SG with all possible instantiations of BGP. Since BGP does not contain blank
nodes, the blank node renaming as required by the condition is obsolete. Furthermore, we can use the empty RDF instance mapping σ to obtain the
pattern instance mappings P3=(μ3, σ) and P4=(μ4, σ), which applied to BGP yield:
P3(BGP) = ex:a2 ex:b _:c3 . and P4(BGP) = ex:a1 ex:b _:c3 .

The union of the two triples is not entailed by SG and adding further triples does not change that. This is because the reuse of the same blank
node in different solutions has introduced an unintended co-reference, whereas the queried graph does not support the fact that both
ex:a1 and ex:a2 are related to the same element.

Furthermore, the set of possible solutions is clearly infinite in this case, which is problematic with respect to condition 4 from the SPARQL Query specification since the use of different blank node labels is considered a trivial source
of infinie answers. For a possible solution to actually be a solution, however, the two additional conditions C1 and C2 have to be met:

(C1) The RDF triples sk(P(BGP)) are ground and RDF entailed by sk(SG).

(C2) For each variable x in V(BGP), sk(μ(x)) occurs in sk(SG) or in rdfV-Minus.

In this case, condition C1 limits the answers by checking entailments against a Skolemization of SG. Thus, let skol be a prefix
that denotes a fresh IRI not occurring in the triples for SG and sk(SG) the following (Skolemized) graph:

ex:a1 ex:b skol:c1 .
ex:a1 ex:b skol:c2 .
ex:a2 ex:b skol:c3 .

The Skolem function maps _:c1 to skol:c1, _:c2 to skol:c2, and _:c3 to
skol:c3.
Consider the pattern instance mapping P1=(μ1, σ1) with μ1 as given above and
σ1 an empty RDF instance mapping. In this case, P1(BGP) = ex:a1 ex:b _:c1. Since sk(P(BGP)) =
ex:a1 ex:b skol:c1 is a ground triple that is RDF entailed by the Skolemized scoping graph, C1 is satisfied. Since both
sk(μ1(?s)) = sk(ex:a1) = ex:a1 and sk(μ1(?o)) =
sk(_:c1) = skol:c1 occur in the Skolemized scoping graph, C2 is satisfied too and μ1 is a solution.
Similarly, it can be shown that μ2 and μ3 are solutions.
The other possible solutions are, however, not returned as solutions.
For example, consider the pattern instance mapping P4=(μ4, σ4) for an empty RDF instance mapping
σ4. In this case P4(BGP) = ex:a1 ex:b _:c3 and although sk(P(BGP)) = ex:a1 ex:b skol:c3 is
ground, it is not RDF entailed by the Skolemized scoping graph.
The pattern instance mapping P5=(μ5, σ5) for an empty RDF instance mapping σ5 leads
to P5(BGP) = ex:a1 ex:b _:whatever. Since sk is not defined for _:whatever, sk(P(BGP)) =
ex:a1 ex:b _:whatever is not a ground triple, which violates C1.

In fact, we could have directly used a Skolemized version of the scoping graph to define the answers under RDF entailment. Since the
Skolemized scoping graph sk(SG) is, however, not RDF-equivalent to SG, this violates the first condition that the SPARQL
Query specification places on extensions of the basic graph pattern matching.

2.2 Answers from Axiomatic Triples (Informative)

The following example mainly illustrates the use of condition C2. Consider the query

There are even more possible answers since ex:b a rdf:Property RDF entails _:exb1 a rdf:Property for
some blank node _:exb1allocated to ex:b, i.e.,
_:exb1 is a possible solution. As shown above, condition C1 prevents such possible solutions from newly introduced blank nodes to be
returned as solutions. To limit the answers from the axiomatic triples condition C2 is used:

(C2) For each variable x in V(BGP), sk(μ(x)) occurs in sk(SG) or in rdfV-Minus.

The possible answers μ2 to μ5 are considered here in greater detail. Since all these solution mappings
lead to (ground) axiomatic triples when instantiating the BGP, C1 is trivially satisfied. Since the queried graph contains no blank nodes,
sk(SG) = SG and sk(μi(?x)) = μi(?x) for any solution mapping μi, which is used to simplify the
checking of C2 below.

For the possible solution μ2, take an empty RDF instance mapping σ2 to obtain a pattern instance
mapping P2=(μ2, σ2) with P2(BGP) = rdf:type a rdf:Property. Since
μ2(?x)=rdf:type occurs in SG (and also in rdfV-Minus), condition C2 is also satisfied and this solution
mapping is a solution.

For the possible solution μ3: take again an empty RDF instance mapping σ3 to obtain a pattern
instance mapping P3=(μ3, σ3) with P3(BGP) =
rdf:subject a rdf:Property. Although μ3(?x)=rdf:subject does not occur in SG, it occurs in rdf-Minus
and this possible solution mapping is, therefore, also returned as an answer.

For the possible solution μ4: take again an empty RDF instance mapping σ4 to obtain a pattern
instance mapping P4=(μ4, σ4) with P4(BGP) = rdf:_1 a rdf:Property.
Since μ4(?x)=rdf:_1 occurs in SG, this is a solution.

For the possible solution μ5: take again an empty RDF instance mapping σ5 to obtain a pattern
instance mapping P5=(μ5, σ5) with P5(BGP) = rdf:_2 a rdf:Property.
Since μ5(?x)=rdf:_2 occurs neither in SG nor in rdf-Minus, this solution mapping is not a solution.

Similar arguments as for rdf:_2 can be used for rdf:_n with n > 2. Thus the query answer contains ex:b,
rdf:_1, and the subjects of RDF axiomatic triples of the form X rdf:type rdf:Property with X in rdfV-Minus.

2.3 Literals in the Subject Position (Informative)

Please note that solution mappings that map variables that occur in the subject position of the basic graph pattern BGP to literals will not be
returned as solutions. Indeed, although there might be a pattern instance mapping P for the solution mapping such that P(BGP) is RDF entailed by the
queried graph, but P(BGP) is not well-formed as required (see also the SPARQL triple patterns definition). E.g., given a query

SELECT ?x WHERE { ?x a rdf:XMLLiteral }

even the empty graph would RDF entail all statements

xxx a rdf:XMLLiteral

for xxx a well-formed RDF XML
literal, but any solution that maps x to an XML literal such as "<a>abc</a>"^^rdf:XMLLiteral would result
in a triple that is not a valid RDF triple.

Please note that triples with literals in the subject positions are currently not considered well-formed RDF, but this might be
changed in the future. If literals were allowed in the subject position, condition C2 would still guarantee finite answers.

2.4 Boolean Queries (Informative)

The two conditions C1 and C2 also have an effect on the answers to Boolean queries. For Boolean queries that contain variables, e.g.,

ASK { ?x a rdf:Property }

The query answer is yes (true) if there is at least one solution mapping (i.e., a solution that satisfies also conditions C1
and C2) and it is no (false) otherwise. For example, if the queried graph is the empty graph, the query has no solution since even if a
pattern instance mapping yields an axiomatic triple, condition C2 cannot be satisfied.

For Boolean queries without variables the situation is slightly different. Consider, for example, the query

ASK { rdf:type a rdf:Property }

against the empty graph. Since rdf:type a rdf:Property is an axiomatic triple, even the empty graph RDF entails the triple. We have
two possible outcomes for such a Boolean query: there is a solution sequence containing a mapping ( μ ) where μ has an empty domain (it
does not map any variable to anything) or there is only an empty solution sequence ( ). In the first case, the query answer is
yes (true), whereas in the second case the query answer is no (false). Since C2 only operates on the variables in the
query, only C1 is relevant in this case. Since neither the BGP nor the queried (empty) graph contains a blank node, also C1 holds and the query
answer is yes (true).

Note that even though rdf:_n is not in rdfV-Minus for any n, this means that queries such as
ASK { rdf:_n a rdf:Property } will always be answered with yes (true) even if rdf:_n does not occur in the
scoping graph.

Editorial note

14/10/2009

Other possible design choices for finite answers under RDF and the following RDFS entailment regime are:

Instead of also allowing bindings from rdfV-Minus, condition C2 could be modified to only allow bindings to terms that occur in the (Skolemized)
scoping graph. This would exclude more answers that involve terms from the RDF(S) vocabulary. For example, an RDF graph containing the triple

ex:s ex:p ex:o

RDF entails

ex:p a rdf:Property

but under the modified conditions, the query

SELECT ?t WHERE { ex:p a ?t }

against that graph would have an empty answer. This is because a solution mapping μ that maps
?t to rdf:Property would violate the condition because rdf:Property does not occur in the scoping graph and
Skolemization has no effect in this example. If the modified condition would only apply to variables hat occur in subject position, the query would
have an answer, but an inconsistent active graph could result in infinite answers for the RDFS and OWL RDF-Based entailment regimes.

Instead of using the vocabulary of the graph plus the rdfV-Minus vocabulary to limit the number of axiomatic triples, axiomatic triples could
simply be excluded from the query answers. Inconsistencies could, however, still cause infinite answers for example from datatypes since an
inconsistent graph trivially entails any triple, e.g., rdf:type rdf:type "<a>x</a>"^^rdf:XMLLiteral,
rdf:type rdf:type "<a>xx</a>"^^rdf:XMLLiteral, etc.

Since, as long as literals are not allowed in subject positions, only subjects of the form rdf:_1, rdf:_2, ...
can cause infinite answers, we could also look at what the largest n is in elements of the form rdf:_n and return axiomatic triples
such as rdf:_m a rdf:Property only if m<=n. This falls apart, however, if literals are allowed in the subject position, since in
that case

xxx a rdf:XMLLiteral

is an answer to the query

SELECT ?x WHERE { ?x a rdf:XMLLiteral }

for xxx a well-formed RDF XML literal. Further, this solution still has to define a suitable behavior for inconsistent graphs.

3 RDFS Entailment Regime

Under RDFS entailment there are not only more entailments than with just RDF, which result in possibly more query answers, but RDF graphs can also be
inconsistent under RDFS interpretations. Without any restrictions, this can result in infinite answer sets since an inconsistent graph RDFS entails any
consequence. The restrictions to guarantee finite query answers are the same as for RDF and they are repeated here so that the description of the
entailment regime is self-contained. The definition of the scoping graph is, however, extended to also cover the case when the queried graph is
RDFS-inconsistent.

Name

RDFS

URI

http://www.w3.org/ns/entailment/RDFS

Legal Graphs

Any legal RDF graph.

Legal Queries

Any legal SPARQL query.

Illegal handling

In case the query is illegal (syntax errors), the system MUST raise a
MalformedQuery fault. In case the queried graph is illegal
(syntax errors), the system MUST raise a QueryRequestRefused fault.

The scoping graph is graph-equivalent to the active graph even if the active graph is
RDFS-inconsistent. If the active graph is
RDFS-inconsistent, an implementation MAY raise a QueryRequestRefused fault or issue a warning and it
SHOULD generate such a fault or warning if, in the course of processing, it determines that the data or query is not compatible
with the request. In the presence of an inconsistency the conditions on solutions still guarantee that answers are finite.

Query Answers

Let G be the queried RDF graph, BGP be a basic graph pattern, V(BGP) the set of variables in BGP, B(BGP) the set of blank nodes in BGP, SG
the scoping graph for G and BGP, sk(SG) a
Skolemization of SG with respect to a vocabulary disjoint from the vocabulary of SG
and BGP, and P=(μ, σ) a pattern instance mapping.
Let P(BGP) denote the result of replacing each variable v from V(BGP) for which μ is defined with μ(v) and each blank
node b from B(BGP) for which σ is defined with σ(b). Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t
otherwise. Let sk(P(BGP)) denote the result of replacing each blank node b in P(BGP) for which sk is defined with sk(b). The term
rdfsV refers to the RDFS vocabulary and rdfsV-Minus is the set of URI
references in rdfsV minus URI references of the form rdf:_n with n in {1, 2, ... }.

A solution mapping μ is a possible solution for BGP from G under RDFS entailment if dom(μ) = V(BGP) and there is an RDF
instance mapping σ from B(BGP) to RDF-T such that dom(σ)=B(BGP) and the pattern instance mapping P=(μ, σ) is such that
P(BGP) are well-formed RDF triples that are RDFS entailed by SG.

A possible solution μ is a solution for BGP from SG under RDFS entailment if:

(C1) The RDF triples sk(P(BGP)) are ground and RDF entailed by sk(SG).

(C2) For each variable x in V(BGP), sk(μ(x)) occurs in sk(SG) or in rdfsV-Minus.

As under RDF entailment, answers under RDFS entailment are defined in a two-stage process. Possible answers are all answers that one would expect
under RDFS entailment, i.e., all mappings such that instantiating the basic graph patterns with them results in RDF triples that are RDFS entailed
by the queried graph. To obtain always a finite set of answers, the same conditions C1 and C2 as for the RDF entailment regime are used.

3.1 Inconsistencies (Informative)

An RDFS-inconsistent graph RDFS entails any graph, but there are limited possibilities to express an inconsistency
in RDFS. Every inconsistency is due to a literal of type rdf:XMLLiteral, where the lexical form is a malformed XML string, e.g.,

ex:a ex:b "<"^^rdf:XMLLiteral .

in combination with a range restriction on the property, e.g.,

ex:b rdfs:range rdf:XMLLiteral .

The first triple alone does not cause an inconsistency. It only requires that the literal "<"^^rdf:XMLLiteral is interpreted
as something that is not in the extension of rdfs:Literal. Since rdfs:Literal contains rdf:XMLLiteral,
the second triple together with the first one results in an inconsistency. The following example illustrates that an inconsistency is not always
as directly visible as in the example above and one might need to apply some inference rules to detect it. E.g., consider the following triples
(numbers are only given to explain the inferences later):

At this point, the inconsistency can be detected since "<" is not a valid lexical form for an RDF XML literal and has to be
interpreted as some element that is NOT in rdfs:Literal, but at the same time it should be of type rdfs:Literal. The
triple derived last is characteristic for an RDFS inconsistency.

3.1.1 Effects of Unchecked Inconsistencies

Please note that the above definition of the RDFS entailment regimes does not require that systems MUST generate an
error or a warning in the case of an inconsistency, but systems MAY generate an error or warning. A system
SHOULD generate such an error or warning if, in the course of processing, it determines that the data or query is not
compatible with the request.

If a system did not raise an error for an inconsistent active graph, it will most likely just return answers that would be answers from a
consistent sub-graph of the active graph. Since the scoping graph is taken to be equivalent to the active graph irrespective of inconsistencies,
a query could still have infinitely many possible answers because an inconsistent graph (trivially) entails any RDF triple. Conditions C1
and C2 guarantee, however, finiteness even when a system tries to generate all answers without checking for consistency. In particular condition
C2 restricts query answers such that only answers over the (finite) vocabulary of the queried graph plus the finite subset of the RDFS
vocabulary in rdfsV-Minus are returned.

The above definition of the RDFS entailment regime is chosen such that it can be implemented efficiently. Consider, for example, a
default graph containing the following triples

which requires a join operation in the query processor. This graph is RDFS-inconsistent due to the last two triples, but the query processor
might know (after parsing) that there is no ex:r property at all in the graph. Thus, the processor knows that it does not have to
evaluate the query. However, if a consistency check was required, the processor would have to parse and process the query nevertheless and
return an error. Such a test could be very costly (there could be more than 10,000 ex:b ex:s ex:yn tuples).

Another motivation comes from queries that require a union. For example, the query

SELECT * WHERE { {BGP1} UNION {BGP2} }

can be executed by dispatching BGP1 and BGP2 in parallel to some processing element, streaming results back to the caller from either
side of the UNION as they become available. The use of HTTP for streaming results places some constraints on what can be done, e.g., the error
or success code must be transmitted before starting streaming the results. However, discoverning the inconsistency from the dispatched
processors might be too late for the main processor to communicate the error back to the client in a conformant manner.

Editorial note

14/10/2009

The current understanding of the working group is that the first condition on extensions of basic graph pattern matching:

The scoping graph, SG, corresponding to any consistent active graph AG is uniquely specified and is E-equivalent to AG.

does not apply to inconsistent active graphs. This condition does, thus, not restrict how we define the scoping graph in case of an
E-inconsistent active graph and at current we just define the scoping graph in the same way as for consistent graphs.

One alternative way would be to define the scoping graph only if the active graph is consistent. If the active graph is inconsistent, one
then has to specify conditions independent of the scoping graph that prevent infinite answers (an inconsistent graph trivially RDFS entails any
RDF triple).
Another possibility would be to specify an entailment regime for a subset of RDFS that cannot express inconsistencies, e.g., by defining
well-formed graphs for the regime as those that contain only syntactically valid rdf XML literals.
The scoping graph could also be defined as graph equivalent to a "repaired" active graph in which malformed XML literals are
replaced with well-formed ones. This would allow systems to more or less ignore inconsistencies and the behavior of systems is well-defined in any
case since malformed XML literals are the only cause for inconsistencies in RDFS interpretations. This definition does, however, not extend to
more expressive entailment relations such as OWL with RDF-Based Semantics.
Several other alternatives, including different, implementation-dependent behaviors for systems that do/do not check consistency are currently
being under discussion in the working group.

3.2 Aggregates and Blank Nodes (Informative)

SPARQL 1.1 Query allows for aggregates in queries such as COUNT, MIN, etc. Aggregates apply expressions over groups of
solutions, e.g., by counting the number of solutions. Thus, aggregation is layered on top of basic graph pattern matching and all solutions computed
for the basic graph pattern of the query and the entailment regime in use are passed on to the algebra functions. For the RDF (and RDFS) entailment
regime this means that since blank nodes are treated as Skolem constants due to condition C1, each blank node contributes one value for the
aggregates. Assume, for example, the query

The results are then grouped and aggregated by algebra operators. In this case, there is
only one group for ex:book1 and the authors for the group are counted due to the COUNT aggregate over
?author resulting in the query answer:

publication

numAuthors

ex:book1

2

RDFS further gives semantics to rdfs:subPropertyOf and the basic graph pattern matching under RDFS entailment finds five solution
mappings:

author

publication

μ1

_:a1

ex:book1

μ2

ex:author2

ex:book1

μ3

_:a1

ex:book2

μ4

ex:author3

ex:book2

μ5

_:a4

ex:book2

These solutions are then processed by the algebra operators. Again, the authors for each book (now there are two groups) are counted due to the
COUNT aggregate over ?author, which leads to the following result for the query under RDFS entailment:

publication

numAuthors

ex:book1

2

ex:book2

3

Note that the algebra operator just takes the solutions returned by the basic graph pattern matching mechanism. If, for example, blank nodes
should not be counted or counted only once, this would mean that in general the entailment regimes must be modified to return no blank nodes or
collapse blank nodes in results. A consequence of this would be that under entailment regimes such as RDF(S) one could get less results than with
simple entailment. E.g., if no blank nodes were to be returned, then the books would have just one author under non-simple entailment.

4 D-Entailment Regime

The D-entailment regime assumes that queries are answered with respect to a (finite) datatype
map D. The entailment regime is a straightforward extension of the RDF and RDFS entailment regimes and the same conditions are used to guarantee the
finiteness of the result set, only adapted such that the vocabulary also includes the datatype URIs from the datatype map. The use of D-entailment means
that further inconsistencies could arise due to datatype clashes and the same mechanisms as for handling inconsistencies as in the RDFS entailment
regime are applied.

Name

D-Entailment

URI

http://www.w3.org/ns/entailment/D

Legal Graphs

Any legal RDF graph.

Legal Queries

Any legal SPARQL query.

Illegal handling

In case the query is illegal (syntax errors), the system MUST raise a
MalformedQuery fault. In case the queried graph is illegal
(syntax errors), the system MUST raise a QueryRequestRefused fault.

The scoping graph is graph-equivalent to the active graph even if the active graph is
D-inconsistent. If the active graph is
D-inconsistent with respect to the datatype map D, an implementation
MAY raise a QueryRequestRefused fault or
issue a warning and it SHOULD generate such a fault or warning if, in the course of processing, it determines that the data or
query is not compatible with the request. In the presence of an inconsistency the conditions on solutions still guarantee that answers are finite.

Query Answers

Let D be a finite datatype map, G the queried RDF graph, BGP be a basic graph pattern,
V(BGP) the set of variables in BGP, B(BGP) the set of blank nodes in BGP, SG the
scoping graph for G and BGP, sk(SG) a
Skolemization of SG with respect to a vocabulary disjoint from the vocabulary of SG
and BGP, and P=(μ, σ) a pattern instance mapping.
Let P(BGP) denote the result of replacing each variable v from V(BGP) for which μ is defined with μ(v) and each blank
node b from B(BGP) for which σ is defined with σ(b). Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t
otherwise. Let sk(P(BGP)) denote the result of replacing each blank node b in P(BGP) for which sk is defined with sk(b). The term
dV refers to the RDFS vocabulary plus the datatype names, i.e., the URI
references, for the datatypes in D; dV-Minus is the set of URI references in dV minus URI references of the form rdf:_n with
n in {1, 2, ... }.

A solution mapping μ is a possible solution for BGP from G under D-entailment if dom(μ) = V(BGP) and there is an RDF instance
mapping σ from B(BGP) to RDF-T such that dom(σ)=B(BGP) and the pattern instance mapping P=(μ, σ) is such that P(BGP) are
well-formed RDF triples that are D-entailed by SG.

A possible solution μ is a solution for BGP from SG under D-entailment if:

(C1) The RDF triples sk(P(BGP)) are ground and D-entailed by sk(SG).

(C2) For each variable x in V(BGP), sk(μ(x)) occurs in sk(SG) or in dV-Minus.

4.1 Canonical Lexical Representations (Informative)

Depending on the datatype map D, it can happen that a datatype from D allows for infinitely many lexical forms that denote the same data value.
E.g., if D includes the decimal datatye from the XML Schema Datatypes [XSD], then all of the following lexical forms represent the same value:

100

+100.0

0100.0

100.0

100.00

100.000

SPARQL queries are answered with respect to a graph and any triple serialization format such as RDF/XML or Turtle has to be parsed into a graph
representation. During this parsing process systems may or may not transform the lexical forms of data values into a canonicalized form. E.g., for
the above data value, the canonical lexical form is: 100.0.

Whether or not a parser performs canonicalization can have an effect on query answers. Consider the query

SELECT ?x WHERE { ex:s ex:p ?x }

over the graph obtained from the triples

ex:s ex:p "100.0"ˆˆxsd:decimal .
ex:s ex:p "100.00"ˆˆxsd:decimal .

If the parsing process involves canonicalization, then the obtained graph will contain just two nodes (one for ex:s and one for the
data value 100.0) connected by one edge (for ex:p), whereas without canonicalization, the graph contains one extra node
for 100.00 and an extra edge connecting the node for ex:s with the node for the data value 100.00. In the
first case, the query has one answer, whereas in the second case, the query has two answers.

Whether or not canonicalization takes place depends on the parsing process, which is not part of this specification. Thus, the answers of systems
that use the D-Entailment regimes can vary according to how parsing is implemented and canonicalization during parsing is encouraged in order to
obtain more intuitive answers.

The scoping graph is graph-equivalent to the active graph even if the active graph is
OWL 2 RDF-Based inconsistent. If the active graph is
OWL 2 RDF-Based inconsistent with respect to D, an implementation
MAY raise a QueryRequestRefused fault or
issue a warning and it SHOULD generate such a fault or warning if, in the course of processing, it determines that the data or
query is not compatible with the request. In the presence of an inconsistency the conditions on solutions still guarantee that answers are finite.

Query Answers

Let D be a finite OWL 2 RDF-Based datatype map, G the queried
RDF graph, BGP be a basic graph pattern, V(BGP) the set of variables in BGP, B(BGP) the set of blank nodes in BGP, SG the
scoping graph for G and BGP, sk(SG) a
Skolemization of SG with respect to a vocabulary disjoint from the vocabulary of SG
and BGP, and P=(μ, σ) a pattern instance mapping.
Let P(BGP) denote the result of replacing each variable v from V(BGP) for which μ is defined with μ(v) and each blank
node b from B(BGP) for which σ is defined with σ(b). Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t
otherwise. Let sk(P(BGP)) denote the result of replacing each blank node b in P(BGP) for which sk is defined with sk(b). The term
owl2V refers to the OWL 2 RDF-based vocabulary, which is taken to
include the RDF and RDFS vocabularies and the OWL 2 datatype names and
facet names; owl2V-Minus is
the set of URI references in owl2V minus URI references of the form rdf:_n with n in {1, 2, ... }.

A solution mapping μ is a possible solution for BGP from G under OWL 2 RDF-Based entailment if dom(μ) = V(BGP) and there is an
RDF instance mapping σ from B(BGP) to RDF-T such that dom(σ)=B(BGP) and the pattern instance mapping P=(μ, σ) is such that
P(BGP) are well-formed RDF triples that are OWL 2 RDF-Based entailed by SG with respect to owl2V and D.

A possible solution μ is a solution for BGP from SG under OWL 2 RDF-Based entailment with respect owl2V and D if:

(C1) The RDF triples sk(P(BGP)) are ground and OWL 2 RDF-Based entailed by sk(SG) with respect to D.

(C2) For each variable x in V(BGP), sk(μ(x)) occurs in sk(SG) or in owl2V-Minus.

The OWL 2 RDF-Based entailment regime is a straightforward extension of the RDF and RDFS entailment regimes and the same conditions (adapted to work
with the a finite subset of the OWL 2 RDF-Based vocabulary) are used to guarantee the finiteness of the result set.

5.1 Restriction on Solutions

In this section the restrictions on solutions are explained. As the previously defined regimes, a Skolemization of the queried graph and the BGP
is used to limit answers that just differ in blank node labels (C1). An explanation for this restriction is given in the RDF entailment regime section. Under OWL 2 RDF-Based Semantics the axiomatic triples are not included and owl2V-Minus
could equally be replaced by owl2V. Without C2, infinite answers can, however, easily occur due to the powerful OWL 2 datatype reasoning. Since the
datatype literals are not part of the vocabulary owl2V-Minus, only the values explicitly present in the queried ontology have to be considered,
which again guarantees finite answers. Consider, for example, an ontology containing an axiom that states that all the data values to which Peter is
related with the property ex:dp are in the singleton set containing the interger 5:

A query, which asks for all data values to which ex:Peter cannot be related with the ex:dp property, has infinitely
many answers since any literal different from 5 will satisfy these constraints. This can be formulated by the following query:

The answer to this query consists of all datatypes of the datatype map that are disjoint from xsd:integer, e.g.,
xsd:string, xsd:double, etc. Note that complex data ranges, which are derived from datatypes by applying facet restrictions
to them, are not valid bindings. E.g., the data range

With C2, only the literals and datatypes that occur in the queried graph can be used as bindings. In order to drop C2, one would have to
precisely characterize which queries can cause infinite answers, e.g, by analysing which variables bind to literals and occur under negation. Such
queries could then be excluded. Condition C2 is, however, easier to understand and it is easy to see that it achieves finiteness.

The standard reasoning problems in OWL under the OWL 2 RDF-Based Semantics are undecidable, which means that although the query answers are
guaranteed to be finite, it cannot be guaranteed that the computation of the query results will finish in a finite amount of time. Guaranteed
termination might be achieved by returning an incomplete solution sequence for certain queries.

5.3 The OWL 2 RL Profile

OWL 2 RL defines a syntactic subset of OWL 2, which is amenable to
implementation using rule-based technologies. The OWL 2 RL specification
presents a partial axiomatization of the OWL 2
RDF-Based Semantics in the form of first-order implications for this purpose. For RDF graphs that can be mapped into OWL 2 RL ontologies, a
suitable rule-based implementation has desirable computational properties. For RDF graphs that cannot be mapped into an OWL 2 RL ontology, the
proposed rule set can still be used to compute query answers, but the result set might not contain all query answers that are entailed under the
RDF-Based Semantics.

Endpoints that implement the OWL 2 RL profile can use the URI http://www.w3.org/ns/owl-profile/RL to describe this in their service
description.

For the OWL 2 RL profile, the OWL 2 RL/RDF rules can be used to compute the answers to a query. In this case, the above definition of query
answers can be simplified:

Let G be the queried RDF graph, BGP a basic graph pattern, SG the scoping graph for G and BGP, R the OWL 2 RL/RDF rules
[OWL 2 Profiles], and FO(SG) the translation of SG into a first-order theory according to the OWL 2 Profiles specification
[OWL 2 Profiles], i.e., each triple s p o in SG is represented by a predicate T(s, p, o) in FO(SG). Let
P=(μ, σ) a pattern instance mapping. The solution mapping μ is a possible solution for BGP from G if dom(μ) = V(BGP),
dom(σ)=B(BGP) and FO(SG) union R entails FO(P(BGP)) under the standard first-order semantics.

Condition C1 does not need to be applied in this case because blank nodes are treated as constants under the first-order semantics anyway.
OWL 2 RL implementations are not required to include the axiomatic triples of RDF and RDFS, but they may do so. Thus, in most cases, condition C2
does not have to be applied. Imposing C2 does not, however, do any harm and guarantees finiteness should the problematic axiomatic triples be
inferred and also guards the behavior on inconsistent ontologies.

The fact that C2 also takes the OWL 2 RDF-Based vocabulary into account means that query answers that use terms not present in the scoping graph
may be returned, too. Consider, for example, an ontology containing only the triples:

The first three triples are required for a valid OWL 2 RL ontology and introduce an identifier for the ontology (_:o1) and
typing information (ex:C and ex:D are classes). The ontology entails ex:C owl:equivalentClass ex:D and the
OWL RL rulescm-eqc2 derives
this consequence from the ontology. Since owl:equivalentClass is in owl2V-Minus, the query

SELECT ?rel WHERE { ex:C ?rel ex:D . }

has the answers:

rel

rdfs:subClassOf

owl:equivalentClass

6 OWL 2 Direct Semantics Entailment Regime

Intuitively, in the OWL 2 Direct Semantics entailment regime the queried graph must correspond to an OWL 2 DL ontology. The basic graph pattern of
the query must correspond to an extended OWL 2 DL ontology, allowing variables in place of class names, object property names, datatype property names,
individual names, or literals. Solutions are mappings of variables into IRIs, blank nodes, or literals for which the instantiated basic graph pattern
corresponds to a set of OWL 2 DL axioms or an OWL 2 DL ontology that is compatible with the queried ontology and also entailed by it under the OWL 2
Direct Semantics.

An OWL 2 DL ontology contains a set of axioms. In this section, OWL axioms are stated both in Turtle and in the functional-style syntax (FSS) that is
used in the OWL 2 structural specification [OWL 2 Structural Specification]. A FSS axiom can correspond to several RDF triples, and the RDF triples might contain
auxiliary blank nodes that are not part of the corresponding OWL objects and are not visible in the corresponding FSS axiom. E.g., the triples

The FSS may still contain blank nodes, but these correspond to OWL individuals
that have no explicit names and are called anonymous
individuals. For example, the triple

ex:Peter ex:hasBrother _:y .

corresponds to the FSS axiom

ObjectPropertyAssertion(ex:hasBrother ex:Peter _:y)

While parsing an input document (containing RDF triples) into an OWL ontology, it can be necessary to rename
blank nodes/anonymous individuals and there is no guarantee that the blank node identifier _:y from the above triple is used as an
identifier for Peter's brother in the ontology structure. Thus, the above RDF triple could also be represented by the OWL axiom

ObjectPropertyAssertion(ex:hasBrother ex:Peter _:somethingelse)

Some RDF triples that are well-formed for OWL 2 DL, are mapped to OWL 2 DL axioms that carry no semantics. Axioms (triples) that carry no semantics
are

Annotations,

Entity Declarations,

Ontology Properties (imports, ontology IRIs).

Such axioms are called non-logical axioms, whereas axioms that do carry semantics under OWL 2 Direct Semantics are called logical
axioms.

6.1.1 OWL Import Directives

OWL provides an import directive, which allows one ontology to incorporate axioms from another ontology. Thus, if the queried RDF graph G contains
a triple of the form

ont owl:imports imported .

where ont is the ontology IRI or a blank node that identifies the ontology, and imported is the IRI of the imported
ontology, then the canonical parsing
process defined for OWL 2 ontologies makes sure that the axioms from directly and indirectly imported ontologies are taken into account.

As said above, an import directive is a non-logical statement under the OWL 2 Direct Semantics, i.e., whether the statement is present in the
ontology obtained by the parsing process or not has no effect on the logical consequences of the ontology. The statement does, however, influence the
outcome of mapping an RDF graph into an OWL ontology. In the process of mapping a graph G into the ontology structure O(G) the directly and
indirectly imported axioms are taken into account.

6.1.2 Extended Grammar for OWL 2 Direct Semantics BGPs

SPARQL 1.1 Query [SPARQL 1.1 Query] is only defined for basic graph patterns using a triple-based syntax. For OWL 2 Direct Semantics, an
alternative syntax for BGPs based on the functional-style syntax or other popular OWL syntaxes seems natural, but is not part of this
specification.

Since the OWL 2 Direct Semantics is defined in terms of OWL objects, it is necessary to map from the triple-based BGP representation into an OWL
object representation that additionally allows for variables. The appendix precisely specifies how the OWL 2 mapping
from RDF graphs [OWL 2 Mapping to RDF Graphs] can be extended to basic graph patterns. The
result of this mapping is an instance of an extended OWL 2 DL grammar, where the productions for Class, ObjectProperty,
DataProperty, Individual, and Literal of the OWL 2
functional-style syntax grammar[OWL 2 Structural Specification] are extended to alternatively produce variables, i.e., instances of the Var production from the SPARQL
grammar.

6.1.3 Variable Typing

The Direct Semantics entailment regime requires extra triples in a basic graph pattern that give typing information for the variables. Let
?x be a variable from BGP. If BGP contains a triple ?x rdf:type TYPE, where TYPE is one of
owl:Class, owl:ObjectProperty, owl:DatatypeProperty, or owl:NamedIndividual, ?x is
declared to be of type TYPE. BGP satisfies the typing constraints of the entailment regime if no variable is declared as being
of more than one type. Without the required type declarations for variables, parsing a BGP into ontology structures would be very difficult.
Consider the following query

SELECT ?s ?p ?o WHERE { ?s ?p ?o }

Without any restrictions this query could be a query for

declarations, i.e., the BGP maps to a declaration such as Declaration(Class(?s)) where ?p binds to
rdf:type, ?o to owl:Class, and bindings for ?s have to be computed or
Declaration(ObjectProperty(?s)) where ?p binds to rdf:type and ?o to
owl:ObjectProperty, or any other type of declaration,

inverse object properties, i.e., the BGP maps to ObjectInverseOf(?o) where ?s maps to a blank node and
?p to owl:inverseOf,

In order to answer the query without any restrictions, all possible ways of mapping the BGP into ontology structures have to be considered.
Even if variables can only occur in the position of function parameters of the functional-style syntax, the BGP from the above query can still be
mapped to ObjectPropertyAssertion(?p ?s ?o), DataPropertyAssertion(?p ?s ?o), or
AnnotationAssertion(?p ?s ?o) without variable typing information.

The inclusion of type declarations from the queried ontology means that at least the non-variable terms in the query can be disambiguated
without additional typing information in the query. E.g., the BGP of the query

SELECT ?x WHERE { ?x ex:p ?y }

is parsed into

ObjectPropertyAssertion(ex:p ?x ?y)

if ex:p is declared as an object property in the queried ontology and into

DataPropertyAssertion(ex:p ?x ?y)

if ex:p is declared as a data property.

6.2 The OWL 2 Direct Semantics Entailment Regime

Let Q be a legal SPARQL query, BGP a basic graph pattern in Q, G the queried graph, and O(G) the ontology for G. A basic graph pattern is legal
for O(G) if it satisfies the typing constraints of the entailment regime and can be mapped into an OWL ontology or a
set of OWL axioms from the extended OWL structural specification using the declarations from O(G). The query Q
is legal for the regime and O(G) if all basic graph patterns in Q are legal for O(G).

Illegal handling

In case the query is illegal due to syntax errors, the system MUST raise a
MalformedQuery fault. In case the queried graph is illegal
due to syntax errors, the system MUST raise a QueryRequestRefused fault. If the queried ontology is not an OWL
2 DL ontology or the query is not legal for the ontology, the system MAY refuse the query and raise a
QueryRequestRefused error or the system MAY
use only a subset of the triples in the ontology or query.

If the queried ontology is inconsistent under OWL 2 Direct Semantics, the system MUST raise an
error.

Query Answers

Let G be a legal RDF graph for the entailment regime, BGP a legal basic graph pattern, V(BGP) the set of variables in BGP, SG the scoping graph for G and BGP, O(SG) the ontology for SG, sk a total mapping from
anonymous individuals in O(SG) to IRIs from a vocabulary disjoint from the vocabulary of O(SG) and BGP, sk(O(SG)) the resulting
Skolemization of O(SG), and P=(μ, σ) a pattern instance mapping.

Let OE(BGP) be the ontology obtained by mapping BGP into the extension of the OWL 2
structural specification. Let Ax be a function that takes an ontology O from the extended structural specification and
returns all axioms in O. Let Ax(BGP) be the axioms in OE(BGP), and AI(BGP) the set of anonymous individuals in OE(BGP). Let
P(BGP) denote the result of replacing each variable v from V(BGP) for which μ is defined with μ(v) and each anonymous
individual i from AI(BGP) for which σ is defined with σ(i). Let sk(P(BGP)) denote the result of replacing each anonymous individual i in
AI(BGP) for which sk is defined with sk(i). The term owl2V refers to the OWL 2 RDF-based vocabulary, which is taken to include the RDF and RDFS
vocabularies and the OWL 2 datatype names and facet names; owl2V-Minus is the set of URI references in owl2V minus URI
references of the form rdf:_n with n in {1, 2, ... }.

A solution mapping μ is a possible solution for BGP from G under the OWL 2 Direct Semantics if dom(μ) = V(BGP) and there is
an RDF instance mapping σ from AI(BGP) to RDF-T such that dom(σ)=AI(BGP) and the pattern instance mapping P=(μ, σ) is such
that P(BGP) are well-formed RDF triples that are legal for the regime (i.e., P(BGP) is a variable-free and legal basic graph pattern for O(SG))
and OWL 2 Direct Semantics entailed by O(SG).

A possible solution μ is a solution for BGP from SG under OWL 2 Direct Semantics if:

(C1) Each logical axiom ax in OE(sk(P(BGP))) is ground and entailed by sk(O(SG)) under the OWL 2 Direct Semantics.

(C2) For each variable x in V(BGP), sk(μ(x)) occurs in sk(O(SG)) or in owl2V-Minus.

(C3) Adding all axioms in OE(P(BGP)) to O(SG) results in a valid OWL 2 DL ontology.

An implementation of the OWL 2 Direct Semantics entailment regime MAY impose the additional restriction

(C4) Each axiom ax in OE(BGP) with a variable ?x that occurs in the position of a datatype literal, is either of the
form

DataPropertyAssertion(DP I ?x) with DP a data property or a variable and I an individual or a
variable, or

ClassAssertion(C I) with I an individual or a variable and C a concept of the form
DataOneOf(?x).

Implementations that impose this additional restriction MUST provide a means to determine this – they could, for
example, list this in their supporting documentation.

6.3 Restrictions on Solutions (Informative)

In this section the restrictions on solutions are explained. As the previously defined regimes, a Skolemization of the queried graph and the BGP
is used to limit answers that just differ in blank node labels (C1). An explanation for this restriction is given in the RDF
entailment regime section.

Condition C2 is also applied as in the previously defined regimes and guarantees finite answers. Due to the absence of the RDF(S) axiomatic
triples, owl2V-Minus could equally be replaced by owl2V. As under the OWL 2 RDF-Based Semantics, C2 prevents infinite answers that could otherwise
come from the very powerful datatype reasoning. An example that illustrates this is given in the OWL 2 RDF-Based
Semantics entailment regime section.

6.3.1 BGP Constraints for OWL 2 DL

Condition C3 requires that the axioms from the instantiated BGP satisfy the restrictions for OWL 2 DL ontologies, i.e., if they where added to
the queried ontology, then the resulting ontology satisfies the restrictions of OWL 2 DL. These restrictions are in place to guarantee that the
key reasoning tasks in OWL 2 with Direct Semantics are decidable. E.g., for owl:topDataProperty, the following requirement has to be met in OWL 2 DL:

The owl:topDataProperty property occurs in Ax only in the superDataPropertyExpression part of SubDataPropertyOf
axioms.

C3 guarantees that the restrictions that are applied to the queried ontology are also equally applied to the query.

6.3.2 Restriction on Data Property Assertions

Individuals can be related to a data value although this is not explicitly stated and the actual value might not occur in any axiom of the
ontology. The optional condition C4 will exclude such inferred solutions. For example, consider an ontology with a data property
ex:dp containing the axiom

The axiom states that Peter has exactly 2 ex:dp successors and these successors have to be integers greater than 5 and less than 8,
which means that one successor must have the value 6 and the other one the value 7. This axiom can be expressed in Turtle as

Under OWL 2 Direct Semantics, an ontology containing the above axiom entails DataPropertyAssertion(ex:dp ex:Peter "6"^^xsd:int)
and DataPropertyAssertion(ex:dp ex:Peter "7"^^xsd:int), which is ex:Peter ex:dp "6"^^xsd:int and
ex:Peter ex:dp "7"^^xsd:int in Turtle, respectively. Restriction C2 prevents such possible answers from actually being part of the
solutions since the values occur neither in the ontology nor in the vocabulary owl2V-Minus. Consider, for example, the following query against
the above ontology:

SELECT ?s ?d WHERE { ?s ex:dp ?d }

where the BGP is mapped to the following FSS element:

DataPropertyAssertion(ex:dp ?s ?d)

This query has an empty answer. Assume now, that the ontology is extended with the assertion:

DataPropertyAssertion(ex:dp ex:Mary "6"^^xsd:int)

in Turtle:

ex:Mary ex:dp "6"^^xsd:int .

The same query without C4 has now two answers:

s

d

ex:Peter

"6"^^xsd:int

ex:Mary

"6"^^xsd:int

Adding an assertion that is not related to the assertion regarding ex:Peter, causes ex:Peter to also appears among
the answers since "6"^^xsd:int occurs now in the queried ontology and C2 is satisfied for both answers. Systems that also use C4
will only return one answer:

s

d

ex:Mary

"6"^^xsd:int

With C4, only asserted data values are considered, which prevents these non-local effects, but further limits the inferences used to retrieve
the query answers.

Since there are infinitely many data values, C2 and the optional C4 have the additional advantage that a SPARQL endpoint can compute the
answers to a query with BGP ex:Peter ex:dp ?x by replacing all possible data values for ?x with values that occur in
the ontology. Testing all possible values no matter whether they occur in the ontology or not is not feasible given that there are infinitely
many possible data values to choose from and terminating query answering procedures without such restrictions are not readily available.

6.4 Higher Order Queries (Informative)

The Direct Semantics entailment regime allows for certain (but not all) forms of higher order queries. For example, one can use the BGP
?x rdfs:subClassOf ?y to query for pairs of sub- and super-class. I.e., variables can bind to classes (representing sets of
individuals) and not just to individuals or data values. Queries in which variables are used in positions of a First-Order Logic quantifier, will,
however, be illegal since such queries cannot be mapped to OWL objects as required. For example, the following (illegal) query
asks whether some or all brothers of Peter are persons:

In functional-style syntax the BGP of the query corresponds to the axiom

ClassAssertion( ?x(ex:hasBrother ex:Person) ex:Peter )

Here the variable occurs in the position of a quantifier and not just in the position of OWL entities such as class names or individual names.

6.5 OWL 2 Profiles for Direct Semantics

OWL 2 Direct Semantics is not defined for arbitrary RDF graphs and the OWL 2 QL and EL profiles further restrict the allowed inputs. Thus, SPARQL
endpoints that use Direct Semantics can further describe what input they can process.

6.5.1 OWL 2 DL

OWL 2 DL describes the largest subset of RDF graphs for which the OWL 2 Direct Semantics is defined. Systems that support OWL 2 DL can also
handle ontologies that satisfy the restrictions of the OWL 2 EL and QL profiles because these profiles are even more restrictive. Endpoints that
use the OWL 2 Direct Semantics entailment regime and that can handle all of OWL 2 DL but not RDF graphs outside of the OWL 2 DL fragment can use
the URI http://www.w3.org/ns/owl-profile/DL to describe this in their service description.

6.5.2 The OWL 2 EL Profile

OWL 2 EL is particularly useful in applications employing ontologies that contain very large numbers of properties and/or classes. The profile
captures the expressive power used by many ontologies and is a subset of OWL 2 DL for which the basic reasoning problems can be performed in
time that is polynomial with respect to the size of the ontology. Endpoints that use the OWL 2 Direct Semantics entailment regime and that support
the OWL 2 EL profile can use the URI http://www.w3.org/ns/owl-profile/EL to describe this in their service description.

6.5.3 The OWL 2 QL Profile

OWL 2 QL is aimed at applications that use very large volumes of instance data, and where query answering is the most important reasoning task.
In OWL 2 QL, conjunctive query answering can be implemented using conventional relational database systems. Using a suitable reasoning technique,
sound and complete conjunctive query answering can be performed in LOGSPACE with respect to the size of the data (assertions). As in OWL 2 EL,
polynomial time algorithms can be used to implement the ontology consistency and class expression subsumption reasoning problems. Endpoints that
use the OWL 2 Direct Semantics entailment regime and that support the OWL 2 QL profile can use the URI
http://www.w3.org/ns/owl-profile/QL to describe this in their service description.

6.5.4 The OWL 2 RL Profile

OWL 2 RL defines a syntactic subset of OWL 2, which is amenable to
implementation using rule-based technologies. For RDF graphs that can be
mapped into OWL 2 RL ontologies, the OWL 2 Direct Semantics can also be applied.

Endpoints that use the OWL 2 Direct Semantics entailment regime and that support the OWL 2 RL profile can use the URI
http://www.w3.org/ns/owl-profile/RL to describe this in their service description.

7 RIF Core Entailment

The RIF RDF Compatibility document [RIF-RDF] specifies the interoperation between RIF and the data and ontology languages RDF, RDF Schema, and OWL. Interoperation is defined with respect to the semantics of RIF-RDF combinations. RIF-RDF combinations (or simply combinations) consist of a RIF document and a set of RDF graphs. For the purpose of RIF Core entailment, we will only be concerned with combinations involving a single RDF graph, the Skolemization of the scoping graph. The semantics of combinations are defined in terms of pairs of RIF and RDF interpretations. Each pairing is governed by a number of conditions that maintain a correspondence between RIF semantic structures (interpretations) and RDF interpretations. This maintained correspondence ensures the proper interpretation of names and between RDF triples of the form s p o, RIF frames of the form s[p->o], and their respective terms.

These conditions are enforced on a common RIF-RDF interpretation that is the basis for the standard model-theoretic notions of satisfiability and entailment, each of which define how a common RIF-RDF interpretation is a model of a combination. A common RIF-RDF interpretation satisfies a combination if the semantic multi-structure (the first component of the common interpretation) is a RIF BLD model of the RIF document and the simple interpretation satisfies the RDF graph(s) in the combination. Such a common RIF-RDF interpretation can also be said to satisfy generalized RDF graphs that are (intuitively) those RDF graphs satisfied by the simple interpretation modified to correspond with the interpretation of the RIF document. The RIF-Simple-entails relationship builds on this and is the basis for the semantics of answers to queries using this entailment regime.

The compatibility document defines 3 additional notions of RIF satisfiability with respect to a combination that builds on simple entailment: RIF-RDF, RIF-RDFS, and RIF-D satisfiability. We define answers with respect to RDF graphs that are RIF-Simple-entailed by the combination formed from the (skolemized) scoping graph and a referenced RIF-Core[RIF-Core] document. These additional notions of RIF satisfiability can similarly be used as the basis for more expressive RIF Core entailment regimes.

7.1 Referencing a RIF Core document

The RIF RDF Compatibility document provides a way to import an RDF graph (into a RIF document) and specify a profile
that determines which model theoretic notion of satisfiability and entailment should be used to interpret the combination.
However, for our scenario, the inverse of such a reference is needed and a specific IRI is designated:
http://www.w3.org/ns/rif#imports. In the subsequent text, we will refer to this IRI as rif:imports.
In the RDF triple with this predicate, the object (a URI reference) MUST be considered the location
of the safe RIF Core document to use to form the RIF-RDF combination that entails the answers. Combinations used in this SPARQL entailment
regime MUST be interpreted using the semantics specified in the Simple profile (http://www.w3.org/ns/entailment/Simple)

Editorial note

05/19/2010

The namespace and URI used for rif:imports is still under discussion within the group

7.2 (Simple) RIF Core Entailment Regime

Name

(Simple) RIF Core Entailment Regime

URI

http://www.w3.org/ns/entailment/RDF-RIF-Core

Legal Graphs

RDF graphs with exactly one triple with a rif:imports as a predicate (see 7.1) and
where the imported RIF document is safe and does not include a binary Import statement with a profile other than Simple.

Legal Queries

Any legal SPARQL query.

Illegal handling

In case the query is illegal (syntax errors), the system MUST raise a
MalformedQuery fault. In case the queried graph is illegal
(syntax errors), the system MUST raise a QueryRequestRefused fault.

As with the RDF entailment regime, any legal RDF graph (by itself) is satisfiable, no explicit inconsistency handling is required.

Query Answers

Let G be the queried RDF graph, BGP be a basic graph pattern, V(BGP) the set of variables in BGP, B(BGP) the set of blank nodes in BGP, SG the
scoping graph for G and BGP, sk(SG) a Skolemization of SG with respect to a vocabulary disjoint from the vocabulary of SG and BGP, and P=(μ, σ) a pattern instance mapping.
We write P(BGP) to denote the result of replacing each variable v from V(BGP) for which μ is defined with μ(v) and each blank
node b from B(BGP) for which σ is defined with σ(b). Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t
otherwise. With sk(P(BGP)) we denote the result of replacing each blank node b in P(BGP) for which sk is defined with sk(b).

A solution mapping μ is a solution for BGP from G under RIF-Simple entailment if dom(μ) = V(BGP) and there is an RDF
instance mapping σ from B(BGP) to RDF-T such that dom(σ)=B(BGP) and the pattern instance mapping P=(μ, σ) is such
that sk(P(BGP)) are ground, well-formed RDF triples that are RIF-Simple entailed by the
RIF-RDF combination formed with
the safe RIF core document referenced from SG via the rif:imports predicate.

Editorial note

05/19/2010

It is unclear whether safe RIF-Core rules used to form combinations for this entailment regime guarantee uniqueness
(up to RDF graph equivalence) on answer sets. Safeness by itself is known
to not guarantee that it is possible to construct a finite grounding without additional (stronger) safety conditions.

Intuitively, the grounding of a rule is the set of all possible ways ground versions of its atomic formulae and external predicates
can be obtained by replacing variables with referents from the domain [ANSWERSET-SW]. Variable subsititutions
essentially correspond to SPARQL solution mapping,
so an infinite grounding corresponds to a infinite solution set. If the solution mappings in such a set differred only by blank node renaming,
then safeness would be sufficient for condition 4. However, it is not clear if this is
the case for all combinations formed from safe RIF-Core rules.

Without strongly safe restrictions, there may be
interoperability issues with Datalog engines (for instance) that can only process rules
that can be finitely grounded.

However, strong safety restrictions are only defined in the informative sections of the RIF-Core specification

Editorial note

21/05/2010

Should that entailment URI be http://www.w3.org/ns/entailment/RIF instead, since
the choice between Core, BLD, or PLD does not mean a difference in entailment semantics but rather
a difference in syntactic subsets of RIF?

RIF-Core conformance is defined with respect to safe rules and so this entailment regime is defined with respect to combinations formed from safe RIF documents.

RDF vocabulary such as RDFS and OWL2-RL can be interpreted within this entailment regime through the use of custom
rulesets. For example, RDFS entailment can be implemented by using the RRDFS ruleset specified in [RIF-RDF].
Similarly, the RIF Core rules in [OWL2-RL-RIF] can be used to capture an axiomatization of OWL2-RL.

7.4 Finite Answer Set Conditions (Informative)

Traditionally, one of the ways to ensure that the underlying decision problems associated with a Horn clause
knowledge representation are decidable is to prevent the use of function symbols. RIF-Core's
syntax permits built-in functions and (with possibly infinite) predicates in the body of
a rule. A Horn Clause query is said to be safe it it has a finite set of answers. In order to ensure
that a Horn Clause logic programming language is complete (i.e., it guarantees all answers to a query)
it is necessary to test whether a given query is safe [SAFETY].

Without strong safety conditions, cyclic references
can rule out the existence of a unique, minimal Herbrand model of
the combination. With strong safety conditions, even in the face of a cycle,
the output of a built-in predicate cannot grow infinitely, since the size of
its input is fixed prior to entering the cycle [ANSWERSET-SW] and the evaluation of a built-in
predicate with a possibly infinite extension (such as pred:numeric-less-than or pred:dateTime-greater-than) is determined
only by the terms from a collection of finite predicates. Restrictions such as these are
traditionally enforced through the use of a dependency graph [STABLEMODEL] to determine if a
ruleset is stratified. Stratification is typically applied to logic programs with negated literals and
RIF-Core does not allow negated literals. However, logic programs restricted in this way permit the use
of built-in function symbols such that the truth of a predicate is well-defined by an external procedure.
RIF-Core's notion of strong safety facilitates the ability to construct a
finite grounding which addresses both components of the forth requirement of SPARQL extensions on their answer sets:
uniqueness and finiteness.

Consider the following strongly safe RIF Core document, scoping graph, and query, for which an answer set can be determined from the unique, minimal, and finite RIF-RDF model of the combination (despite the use of a built-in predicate). In this query, the user asks for all hospital episodes (or visits) and the various health care events they subsume (as indicated by the ex:hasHospitalization predicate). The ex:hasHospitalization predicate is defined (in the strongly safe RIF core document) as a relation between a health care event with the larger hospital encounter event it is a part of based on the ordering of the dates associated with the events. The ordering constraint is enforced through the use of the pred:dateTime-greater-than and pred:dateTime-less-than external built-in predicates.

This should result in the following bindings as a result of the rules and the triples (2)-(7) from a SPARQL service that implements the RIF Core entailment regime:

EVT

HOSP

ex:Operation1

ex:Episode1

8 Entailment Regimes and Data Sets (Informative)

Many RDF data stores hold multiple RDF graphs and applications can make queries that involve information from more than one graph. This section
clarifies how entailment regimes behave in the presence of named graphs.

As defined in the SPARQL specification, a SPARQL query is executed against an RDF
Dataset which represents a collection of graphs. An RDF Dataset comprises one graph, the default graph, which does not have a name, and zero or more
named graphs, where each named graph is identified by an IRI. The graph that is used for matching a basic graph pattern is the active graph. Under an
entailment regime E other than simple entailment, we do not only consider the triples that are in the graph, but also triples that are E-entailed by the
graph. The entailed triples must, however, be E-entailed by the active graph and not by a merge of the triples in all graphs. This follows from
conditions 1 and 3 of the conditions on extensions for basic graph matching.

For an example, we consider a data set with consists of an empty default graph, a named graph graphA with IRI http://example.org/a.rdf,
and a named graph graphB with IRI http://example.org/b.rdf. The named graphs contain the following data:

http://example.org/a.rdf:

ex:p rdfs:domain ex:A .

http://example.org/b.rdf:

ex:x ex:p ex:y .

If we ask the following query under RDFS entailment

SELECT ?g WHERE { GRAPH ?g { ex:x a ?type } }

the answer sequence is empty because neither the default graph, nor the named graphs on their own entail a triple that would provide the required
binding for ?type.

In order to evaluate a query over the merge of the triples in the named graphs, one can use several FROM clauses, which result in the
creation of a fresh default graph for the query that contains a merge of the triples, e.g.,

SELECT ?t FROM <http://example.org/a.rdf> FROM <http://example.org/b.rdf> WHERE { ex:x a ?t }

has the answer { (t, ex:A) }. One can not merge triples from several sources into a named graph (they will always be merged into a fresh
default graph) and such an extension would require changes to the conditions for extensions of basic graph pattern matching in the existing SPARQL query
language specification.

9 Entailment Regimes and Updates (Informative)

SPARQL 1.1 also describes an update language (see SPARQL 1.1/Update and
SPARQL 1.1/HTTP RDF Update), which can be used to add, modify, or delete data in an RDF
graph. Support for SPARQL 1.1/Update and SPARQL 1.1/HTTP RDF Update is optional. SPARQL endpoints that use an entailment regime other than simple
entailment may support update queries, but the exact behavior of the system for such queries is not covered by this specification. SPARQL endpoints
that use an entailment regime other than simple entailment and that do support update queries should describe the system behavior in the system's documentation.

This appendix specifies how a legal basic graph pattern BGP of a SPARQL query can be parsed into the extension of the OWL 2 Structural
specification [OWL 2 Structural Specification]. Let ?x be a variable from BGP. If BGP contains a triple ?x rdf:type TYPE, where TYPE is one of
owl:Class, owl:ObjectProperty, owl:DatatypeProperty, or
owl:NamedIndividual, ?x is declared to be of type TYPE. BGP satisfies the typing constraints of
the entailment regime if no variable is declared as being of more than one type.

For the purpose of this parsing process, we assume that BGP is seen as an RDF graph G which may also contain variables in any
position. A tool MAY implement these steps in any way it chooses; however, the results MUST be structurally equivalent to the ones defined in the following sections, where
structural equivalence is taken to be extended in the natural way to also allow for variables, i.e., the definition of structural equivalence is
as follows:

Objects o1 and o2 from the extended structural specification are structurally
equivalent if the following conditions hold:

If o1 and o2 are atomic values, such as strings or integers, they are structurally equivalent if they are equal according to the notion of equality of the respective UML type.

If o1 and o2 are variables, they are structurally equivalent if they are equal according to the notion of string equality.

If o1 and o2 are unordered associations without repetitions, they are structurally equivalent if each element of o1 is structurally equivalent to some element of o2 and vice versa.

If o1 and o2 are ordered associations with repetitions, they are structurally equivalent if they contain the same number of elements and each element of o1 is structurally equivalent to the element of o2 with the same index.

If o1 and o2 are instances of UML classes from the structural specification, they are structurally equivalent if

both o1 and o2 are instances of the same UML class, and

each association of o1 is structurally equivalent to the corresponding association of o2 and vice versa.

The following table defines the steps that are involved in the mapping process from basic graph patterns to extended OWL objects.

CP 1

Initialize AllDecl(BGP) to contain all declarations from O(SG) including the declarations for the OWL 2 built-in entities.

CP 2

If BGP contains no triple of the form x rdf:type owl:Ontology for x an IRI or a blank node, then extend BGP with
_:x rdf:type owl:Ontology for _:x a fresh blank node not occurring in BGP and SG.

CP 3

Create an instance OE(BGP) that corresponds to an instance of the Ontology class from the extended grammar for OWL 2 Direct Semantics. I.e., the UML
classes are taken to be extended such that entities can also be variables.

CP 4

Analyze BGP and populate OE(BGP) by instantiating appropriate classes from the extended structural specification. Use the
declarations in AllDecl(D) and the variable types to disambiguate IRIs and variables if needed. It MUST be possible to
disambiguate all IRIs and variables. Variables that are not declared as being of some type occur either only in individual positions or only in
literal positions; otherwise BGP is not legal for the regime.

A canonical definition for Step CP 4 is given in the following section.

Parsing BGPs into OWL objects as required in CP 4 follows closely the parsing process described in the Mapping to RDF graphs section of
OWL 2 [OWL 2 Mapping to RDF Graphs]. This document only states where the parsing differs from the mapping as defined by OWL 2. The main
difference is that IRIs, anonymous individuals, and literals can also be variables. An IRI that denotes a class name can only be replaced by a
variable ?x such that type(?x)=owl:Class, an IRI that denotes an object property can only be replaced by a variable
?x such that type(?x)=owl:ObjectProperty, etc.

The functions CE(x), DR(x), OPE(x), and DPE(x) extend the respective functions in the
section Mapping to
RDF graphs[OWL 2 Mapping to RDF Graphs] to map into instances of the extended grammar for OWL 2 Direct Semantics BGPs, i.e.,
the functions also take variables as input and they map to objects that correspond to the extended structural specification for BGPs. Note that
the mapping for annotation properties is left unchanged, since annotations are non-logical and using variables in an annotation or in place of
an annotation property does not make sense under Direct Semantics. The functions are initialized as in Table 9 of [OWL 2 Mapping to RDF Graphs]
and extended as follows:

Parsing then continues as described in [OWL 2 Mapping to RDF Graphs] with the modification that objects can contain variables. In
particular, the notation is extended as follows:

*:x denotes an IRI or a variable;

_:x denotes a blank node;

x denotes a blank node, an IRI or a variable;

lt denotes a literal or a variable; and

xlt denotes a blank node, an IRI, a literal, or a variable.

Note that as for the OWL 2 mapping, variations of the above scheme are also taken to be defined as above, e.g., *:y or
*:xi instead of *:x also denote an IRIs or a variables. Further, _:x remains unchanged and
does not represent a variable.

Variables are not allowed in the mapping for facet restrictions in the last column of Table 12 for *:wi and
lti, and they are not allowed in the mapping for negative data property assertions for lt of
Table 16. Further, the n that denotes a non-negative
integer in cardinality restrictions is not redefined, i.e., it cannot be replaced by a variable.

D Appendix: Proofs

The SPARQL Query specification [SPARQL 1.1 Query] lists four conditions that entailment regimes that extend the standard simple entailment must
satisfy. The different conditions are considered below for all entailment regimes in this document.

1 -- The scoping graph, SG, corresponding to any consistent active graph AG is
uniquely specified up to RDF graph equivalence and is E-equivalent to AG.

All entailment regimes use the same definition of scoping graph as simple entailment, i.e., the scoping graph is graph-equivalent to the active graph
AG of the data set DS for the query but shares no blank nodes with DS or with the basic graph pattern of the query. The same scoping graph is used for
all solutions to a single query. Thus, E-equivalence to AG up to RDF graph equivalence is immediate. In case AG is inconsistent, it is not required that
a scoping graph is defined and although most of the regimes define SG also in the presence of an inconsistency, it is not required that the above
condition is satisfied.

Editorial note

11/03/2010

The RIF regime might need careful consideration here since the scoping graph should not be taken to include the
rules from the imported rule sets unless this preserves E-equivalence.

BGPs that can only be instantiated into malformed triples, e.g., because they require a literal in the subject position, do not have a valid pattern
instance mapping and the condition is satisfied. Only the OWL 2 Direct Semantics regimes restricts the well-formedness of the queried graph and the
basic graph patterns further. Since graphs and queries that are malformed for OWL 2 Direct Semantics are rejected with errors and, thus, do not have
pattern instance mappings, the condition is satisfied.

3 -- For any scoping graph SG and answer set {P1 ... Pn}
for a basic graph pattern BGP, and where {BGP1 .... BGPn} is a set of basic graph patterns all equivalent to BGP, none of
which share any blank nodes with any other or with SG

SG E-entails (SG union P1(BGP1) union ... union Pn(BGPn))

Before giving a proof, the following example illustrates how this condition could be violated. Assume SG contains the triples:

ex:s ex:p _:b1 .
_:b2 ex:p ex:o

and the BGP of the query is

?x ex:p ?y

The graph (even simply) entails the triple ex:s ex:p _:1 and also the triple _:1 ex:p ex:o. If we were to take
P1: ?x/ex:s, ?y/_:1 and P2: ?x/_:1, ?y/ex:o, then, since BGP does not contain
blank nodes, we can take any two copies BGP1, BGP2 of BGP and we would have to show (only considering the two example solutions):

This is clearly not the case because SG does not entail ex:s ex:p _:1 . _:1 ex:p ex:o. The use of the same blank node identifier across
several solutions is only valid if also the corresponding blank nodes in SG are identical.

All the entailment regimes satisfy this restriction since blank nodes are treated as Skolem constants, i.e., although both of the triples in the
above example are possible solutions, these are not part of the actual solutions.

4 -- Each SPARQL extension MUST provide conditions on answer sets which guarantee that the set of triples obtained by
instantiating BGP with each solution μ is uniquely specified up to RDF graph equivalence, and SHOULD provide further
conditions to prevent trivial infinite answers as appropriate to the regime.

All regimes require that bindings are only taken from a vocabulary defined for the regime. Since the defined vocabularies are finite, it is immediate
that any BGP over any AG results in finite answers. The answer set is unique up to RDF graph equivalence since the entailed answers can only vary in
their blank node identifiers, which still preserves graph equivalence.