<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Semantics of SPARQL under OWL 2 Entailment Regimes</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Egor V. Kostylev</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Bernardo Cuenca Grau</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Department of Computer Science, University of Oxford</institution>
        </aff>
      </contrib-group>
      <abstract>
        <p>We study the semantics of SPARQL queries with optional matching features under entailment regimes. We argue that the normative semantics may lead to answers that are in con ict with the intuitive meaning of optional matching, where unbound variables naturally represent unknown information. We propose an extension of the SPARQL algebra that addresses these issues and is compatible with any entailment regime satisfying the minimal requirements given in the normative speci cation. We then study the complexity of query evaluation and show that our extension comes at no cost for regimes with an entailment relation of reasonable complexity. Finally, we show that our semantics preserves the known properties of optional matching that are commonly exploited for static analysis and optimisation.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>
        SPARQL became the standard language for querying RDF in 2008 [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. Since
then, the theoretical properties of SPARQL have been the subject of intensive
research e orts and are by now relatively well-understood [2{7]. At the same
time, SPARQL has become a core technology in practice, and most RDF-based
applications rely on SPARQL endpoints for query formulation and processing.
      </p>
      <p>
        The functionality of many such applications is enhanced by OWL 2
ontologies [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ], which are used to provide background knowledge about the application
domain, and to enrich query answers with implicit information. A new version of
SPARQL, called SPARQL 1.1, was released in 2013 [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]. This new version captures
the capabilities of OWL 2 by means of the so-called entailment regimes [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ]: a
exible mechanism for extending SPARQL query answering to the W3C
standards layered on top of RDF. A regime speci es which RDF graphs and SPARQL
queries are legal (i.e., admissible) for the regime, as well as an entailment relation
that unambiguously de nes query answers for all legal queries and graphs.
      </p>
      <p>The semantics of SPARQL under entailment regimes is speci ed for the
conjunctive fragment, where queries are represented as basic graph patterns (i.e.,
sets of RDF triples with variables) and query answers are directly provided by
the entailment relation of the regime. Roughly speaking, to check whether a
mapping from variables of the query to nodes in the RDF graph is an answer to
the query, one rst transforms the query itself into an RDF graph by substituting
each variable with the corresponding value, and then checks whether this graph
is entailed in the regime by the original data graph [10{12].</p>
      <p>
        When one goes beyond the basic fragment of SPARQL the language becomes
considerably more complicated, but the e ect of entailment regimes on the query
semantics remains circumscribed to basic graph patterns [
        <xref ref-type="bibr" rid="ref13 ref14">13, 14</xref>
        ]. To evaluate a
query one must rst evaluate its component basic patterns using the relevant
regime and then compose the results by means of the SPARQL algebra operations.
      </p>
      <p>Of particular interest from both a theoretical and a practical perspective
is the extension of the basic fragment of SPARQL with the optional matching
feature, which is realised in the language by means of the OPTIONAL operator
(abbreviated by OPT in this paper). This feature allows the optional information
to be added to query answers only when the information is available in the RDF
data graph: if the optional part of the query does not match the data, then the
relevant variables are left unbounded in query answers.</p>
      <p>
        One of the main motivations behind optional matching in SPARQL is to deal
with the \lack of regular, complete structures in RDF graphs" (see [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ] Section 6)
and hence with the inherent incompleteness of information in RDF data sources
where only partial information about the relevant Web resources is typically
available. In this setting, an unbound variable in an answer mapping is naturally
interpreted as a \null" value, meaning that there might exist a binding for this
variable if we consider other information elsewhere on the Web, but none is
currently available in the RDF graph at hand. Another (and slightly di erent)
motivation for optional matching was to introduce a mechanism for \not rejecting
solutions because some part of the query pattern does not match" [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]; in this
sense, one would naturally expect optional matching to either extend solutions
with the optional information, or to leave solutions unchanged. Both readings
of optional matching coincide if we focus just on RDF, and they are faithfully
captured by the normative semantics. In this paper we argue that they naturally
diverge once we consider more sophisticated entailment regimes. Furthermore,
the di erences that arise can have a major impact on expected answers.
      </p>
      <p>To make this discussion concrete, let us brie y discuss a simple example of
an RDF graph representing the direct train lines between UK cities as well as
ferry boat transfers from UK cities to international destinations. Let this graph
be exhaustive in its description of rail connections, but much less so in what
concerns ferry transfers. We may exploit optional matching to retrieve all direct
train connections between cities X and Y, extended with ferry transfers from Y
to other cities Z whenever possible. Under the normative semantics of SPARQL
we may obtain answers (London; Oxford ; ) and (London; Holyhead ; ) provided
the graph has information about direct train lines from London to both Oxford
and Holyhead , but no matching can be found in the graph for ferry connections
starting from Oxford or Holyhead to other cities. Suppose next that the data
graph is extended to a graph corresponding to an OWL 2 ontology in which
it is stated that inland cities do not have ferry connections, and that Oxford
is an inland city. The ontology establishes a clear distinction between Oxford
and Holyhead : whereas the former is inland and cannot have ferry connections,
the latter may still well be (and indeed is) a coastal city o ering a number of
transfers to international destinations. The normative OWL 2 direct semantics
entailment regime, however, does not distinguish between the case of Holyhead
(where the information about ferry connections is still unknown) and Oxford
(where the information is certain), and both answers would be returned. In this
way, the normative semantics adopts the reading of optional matching where the
optional information is used to complete (but never discard) query answers. In
contrast, under the reading of unbounded variables as placeholders for unknown
information, one would naturally expect the answer on Oxford to be ruled out.
Indeed, if our goal were to nd rail to ferry transfers starting from London and
terminating in Dublin by rst querying this graph and then looking for the
missing information elsewhere on the Web, discarding cities like Oxford on the
rst stage would signi cantly facilitate our task.</p>
      <p>
        In this paper, we propose an alternative semantics for the OPT operator which
adopts the aforementioned reading of optional matching as an incomplete \null".
We call our semantics strict, which re ects the fact that it rules out those answers
in which unbound variables in the optional part cannot be matched to any
consistent extension of the input graph. Our semantics is given as an extension of
the SPARQL algebra and hence satis es the expected compositionality properties
of algebraic query languages. Furthermore, it is backwards-compatible with the
normative semantics for regimes in which all legal graphs are consistent, such
as the RDF regime [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ]. We also study the complexity of query evaluation and
show that our extension comes at no cost for regimes in which entailment is not
harder than query evaluation under normative semantics for the RDF regime.
Finally, we show that our semantics preserves the known properties of optional
matching that are commonly exploited for static analysis and optimisation.
      </p>
      <p>
        This paper is an updated version of the work [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ].
2
      </p>
    </sec>
    <sec id="sec-2">
      <title>SPARQL 1.1 under Entailment Regimes</title>
      <p>
        In this section, we formalise the syntax and normative semantics of a core
fragment of SPARQL 1.1 with optional matching under entailment regimes. Our
formalisation is based on the normative speci cation documents [9{11] and builds
on the well-known foundational works on SPARQL [
        <xref ref-type="bibr" rid="ref2 ref3 ref6">2, 3, 6</xref>
        ].
2.1
      </p>
      <sec id="sec-2-1">
        <title>Syntax</title>
        <p>Let I, L, and B be in nite sets of IRIs, literals, and blank nodes, respectively.
The set of RDF terms T is I [ L [ B. An RDF triple is a triple (s p o) from</p>
        <sec id="sec-2-1-1">
          <title>T I T, with s called subject, p predicate, and o object. An (RDF) graph is</title>
          <p>a nite set of RDF triples. Assume additionally the existence of a countably
in nite set V of variables disjoint from T. A triple pattern is a tuple from
(T [ V) (I [ V) (T [ V). A basic graph pattern (BGP) is a nite set of triple
patterns. Built-in conditions are conditions of the form bound(?X), ?X = c, and
?X =?Y for ?X; ?Y 2 V and c 2 T, and their Boolean combinations.</p>
          <p>
            Complex graph patterns are constructed from BGPs using a range of available
operators that are applicable to graph patterns and built-in conditions. We
focus on the AND-OPT-FILTER fragment (i.e., we consider neither union nor
projection), which is widely accepted to be the fundamental core of SPARQL [
            <xref ref-type="bibr" rid="ref2">2</xref>
            ].
In this setting, graph patterns are inductively de ned as follows (e.g., see [
            <xref ref-type="bibr" rid="ref11">11</xref>
            ]):
1. every BGP is a graph pattern;
2. if P1 and P2 are graph patterns that share no blank nodes then (P1 AND P2)
and (P1 OPT P2) are graph patterns (called AND and OPT patterns); and
3. if P is a graph pattern and R is a built-in condition, then (P FILTER R) is a
graph pattern (called FILTER pattern).
          </p>
          <p>In what follows vars(P ) (respectively triples(P )) denotes all the variables from V
(respectively all triple patterns) that appear in a graph pattern P .</p>
          <p>
            We conclude with the de nition of a special class of graph patterns with
intuitive behaviour [
            <xref ref-type="bibr" rid="ref2">2</xref>
            ]. A graph pattern is well-designed if and only if for each
of its OPT subpatterns (P1 OPT P2) the pattern P1 mentions all the variables
of P2 which appear outside this subpattern. Note that all graph patterns in the
examples of this paper are well-designed.
2.2
          </p>
        </sec>
      </sec>
      <sec id="sec-2-2">
        <title>Semantics of BGPs under Entailment Regimes</title>
        <p>The semantics of graph patterns is de ned in terms of mappings ; that is, partial
functions from variables V to terms T. The domain dom( ) of a mapping is
the set of variables on which is de ned. The set of triples obtained from a BGP
P by replacing each ?X from dom( ) by (?X) is denoted by (P ).</p>
        <p>Two mappings 1 and 2 are compatible (written as 1 2) if 1(?X) =
2(?X) for all variables ?X which are in both dom( 1) and dom( 2). If 1 2,
then we write 1 [ 2 for the mapping obtained by extending 1 with 2 on
variables unde ned in 1. A mapping 1 is subsumed by a mapping 2 (written
1 v 2) i 1 2 and dom( 1) dom( 2). Finally, a set of mappings 1 is
subsumed by a set of mappings 2 (written 1 v 2) i for each 1 2 1 there
exists 2 2 2 such that 1 v 2.</p>
        <p>
          Based on [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ], an (entailment) regime R is a tuple (R; G; P; C; J K), where
1. R is a set of reserved IRIs from I;
2. G is the set of legal graphs;
3. P is the set of legal BGPs;
4. C is the set of consistent graphs, such that C G; and
5. J K is the query answering function, that takes a graph G from G and a
BGP P from P and returns either a set JP KG of mappings such that
dom( ) = vars(P ), if P 2 C; or Err, otherwise.
        </p>
        <p>
          As in most theoretical works on SPARQL [
          <xref ref-type="bibr" rid="ref16 ref2 ref3 ref6">2, 3, 6, 16</xref>
          ], we assume that the query
answering function returns a set of mappings, rather than a multiset.
        </p>
        <p>
          The de nitions of query answering and consistency in a regime are based on
an entailment relation [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ], which is also speci ed as part of the regime. We do not
model the entailment relation explicitly, but assume two conditions that capture
the e ects of any reasonable entailment relation on legality and consistency. All
regimes mentioned in the normative speci cation satisfy these properties and in
this paper we consider only regimes that do so.
(C1) If graphs G, G1 and G2 are legal, and there is h : T ! T, preserving R,
such that h(G1 [ G2) G then G1 [ G2 is legal; if, in addition, G is in C
then G1 [ G2 is also in C.
(C2) If a BGP P is in P then (P ) is in G for any (total) : V ! (T n R), such
that (P ) is a graph; if also (P ) is in C then
2 JP K (P ).
        </p>
        <p>Condition (C1) formalises (a weak form of) the monotonicity of legality and
consistency: an illegal graph that is a union of legal ones cannot be made legal by
identifying and renaming of non-reserved terms or adding triples to it; moreover, a
similar property holds for consistency. Condition (C2) guarantees, that \freezing"
variables of a legal BGP to non-reserved terms gives us a legal graph, and,
moreover, if such a graph is consistent, then the answer of the BGP on this graph
contains the mapping corresponding to the \freezing".</p>
        <p>The notions introduced in the remainder of this paper are parameterised with
a regime R, which is not mentioned explicitly for brevity.
2.3</p>
      </sec>
      <sec id="sec-2-3">
        <title>Normative Semantics under Entailment Regimes</title>
        <p>
          Following [
          <xref ref-type="bibr" rid="ref2">2</xref>
          ], now we show how the query answering function J K extends to
complex graph patterns (we refer to [
          <xref ref-type="bibr" rid="ref2">2</xref>
          ] for details). A mapping satis es a
built-in condition R, denoted j= R, if one of the following holds:
1. R is bound(?X) and ?X 2 dom( ); or
2. R is ?X = c, ?X 2 dom( ), and (?X) = c; or
3. R is ?X =?Y , ?X 2 dom( ), ?Y 2 dom( ), and (?X) = (?Y ); or
4. R is an evaluating to true Boolean combination of other built-in conditions.
The join, di erence, and left outer join of sets of mappings 1, 2 are as follows:
1 on 2 = f 1 [ 2 j 1 2 1 and 2 2 2 such that 1
1 n 2 = f 1 j 1 2 1; there is no 2 2 2 such that 1
1 on 2 = ( 1 on 2) [ ( 1 n 2):
2g;
2g;
A graph pattern is legal for a regime R if all the BGPs it contains are legal. The
normative query answering function J Kn is inductively de ned for all legal graph
patterns P on the base of J K as follows. For graphs G from C we have:
1. if P is a BGP then JP KnG = JP KG;
2. if P is (P1 AND P2) then JP KnG = JP1KnG on JP2KnG;
3. if P is (P1 OPT P2) then JP KPnGKnG==JPf1KnGj on JP2KnG; and
4. if P is (P 0 FILTER R) then J 2 JP 0KnG and j= Rg.
If G 62 C then JP KnG = Err for any graph pattern P (which again coincides with
JP KG when P is a BGP). Note, that by these de nitions 2 JP KnG implies that
dom( ) vars(P ), but this inclusion may be strict if P contains OPT operator.
        </p>
        <sec id="sec-2-3-1">
          <title>Two legal patterns P1 and P2 are equivalent (under normative semantics),</title>
          <p>denoted by P1 n P2, if JP1KnG = JP2KnG for every RDF graph G 2 G.
3</p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>On Optional Matching Under the Normative Semantics</title>
      <p>
        One of the main motivations for optional matching in SPARQL was to deal with
the \lack of regular, complete structures in RDF graphs" [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]. Indeed, RDF data
is loosely structured, and in many applications it is not satisfactory to reject an
answer if some relevant information is missing. For example, if we are interested
in retrieving the names, emails, and websites of employees, we may not want to
discard a partial answer involving the name and email address of an employee
merely because the information on the employee's website is not available in the
graph. The normative semantics was designed to deal with such situations: the
optional information is included in query answers only when the information
is available; otherwise, the relevant variables are left unbounded. An unbound
variable in an answer is thus a manifestation of inherent incompleteness of RDF
data sources, and the missing information is interpreted as unknown.
      </p>
      <p>
        This natural interpretation of query results, however, no longer holds if the
query is evaluated under certain entailment regimes, as we illustrate next by
means of examples. In these and all other examples given later on, we focus on
the OWL 2 direct semantics regime. In order for an RDF graph to be legal for
this regime, it must correspond to an OWL 2 ontology; similarly, legal BGPs
must correspond to an extended ontology in which variables are allowed [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ].
Thus, in the examples we express RDF graphs and BGPs in (extended) OWL 2
functional syntax, and use words \ontology" and \graph" interchangeably (we
also omit declaration axioms in ontologies and BGPs to avoid clatter).
Example 1. Consider the OWL 2 ontology O1 consisting of the axioms
      </p>
      <sec id="sec-3-1">
        <title>ClassAssertion(InlandCity Oxford ); PropertyAssertion(train London Oxford );</title>
      </sec>
      <sec id="sec-3-2">
        <title>ClassAssertion(CoastalCity Holyhead ); PropertyAssertion(train London Holyhead );</title>
      </sec>
      <sec id="sec-3-3">
        <title>PropertyDomain(ferry CoastalCity );</title>
      </sec>
      <sec id="sec-3-4">
        <title>DisjointClasses(CoastalCity InlandCity ):</title>
        <p>Consider also the following graph pattern P1, which we wish to evaluate over O1:
PropertyAssertion(train ?X
?Y ) OPT PropertyAssertion(ferry ?Y
?Z):
Intuitively, solutions to P1 provide direct train lines from city X to city Y as well
as, optionally, the ferry transfers from Y to other cities Z. Under the normative
semantics, the BGPs in P1 are evaluated separately. In particular, the optional
BGP is evaluated to the empty set, and JP1KnO1 = f 1; 2g, where
1 = f?X 7! London; ?Y 7! Oxford g and 2 = f?X 7! London; ?Y 7! Holyhead g:
In both answers, variable ?Z is unbounded and hence we conclude that O1
contains no relevant information about ferry connections starting from Oxford or
Holyhead . However, the nature of the lack of such information is fundamentally
di erent. On the one hand, the connections from Holyhead (e.g., to Dublin) are
missing from O1 just by the incompleteness of the information in the graph,
which is usual in (and also a feature of) Semantic Web applications. On the other
hand, Oxford cannot have a ferry connection because it is a landlocked city, and
hence the information about its (lack of) ferry connections is certain. Thus, the
normative semantics cannot distinguish between unknown and non-existent ferry
connections. However, if we adhere to the reading of unbounded variables as
incomplete information or \nulls", then 1 should not be returned as an answer.</p>
        <p>The issues described in this example become even more apparent in cases
where the optional part alone cannot be satis ed, as in the following example.
Example 2. Consider the ontology O2 with the axioms</p>
        <p>ClassAssertion(Person Peter );</p>
        <p>DisjointProperties(hasFather hasMother ):
Furthermore, consider the following pattern P2:
ClassAssertion(Person ?X) OPT (f</p>
        <p>PropertyAssertion(hasFather ?X ?Y ); PropertyAssertion(hasMother ?X ?Y )g):
The optional BGP does not match to anything, so JP2KnO2 consists of f?X 7!
Peter g. However, this BGP is in contradiction with the disjointness axiom: under
the OWL 2 regime, no solution to P2 exists for any ontology with this axiom.</p>
        <p>As these examples suggest, if we interpret unbound variables in answers to
queries with optional parts as an indication of unknown information in the data
graph, then the normative semantics may yield counter-intuitive answers. At
the core of this issue is the inability of the normative semantics to distinguish
between answers in which it is possible to assign values to the missing optional
part (a natural re ection of incompleteness in the data), and those where this is
impossible (a re ection that the missing information is incompatible with the
answer). This distinction is immaterial for regimes without inconsistencies, but it
becomes apparent in more sophisticated regimes, such as those based on OWL 2.
4</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Semantics of Strict Optional Matching</title>
      <p>In this section, we propose our novel semantics for optional matching under
regimes. In a nutshell, our semantics addresses the issues described in Section 3
by ruling out those answer mappings where unbound variables in the optional
part cannot be matched to any consistent extension of the input graph. Our
semantics is therefore strict, in the sense that only answers in which unbound
variables are genuine manifestations of incompleteness in the data are returned.
4.1</p>
      <sec id="sec-4-1">
        <title>De nition of Strict Semantics</title>
        <p>We start by introducing the notion of a frozen RDF graph for a pattern P and
a mapping . Roughly speaking, this graph is obtained by taking all the triple
patterns in P and transforming them into RDF triples by applying the extension
of where unbounded variables are \frozen" to arbitrary fresh constants.
De nition 1. Let R = (R; G; P; C; J K) be an entailment regime. Let P be a legal
graph pattern, and let be a mapping from variables V to RDF terms T. Then,
the freezing GP of P under is the RDF graph (triples(P )), where is the
mapping that extends by assigning each variable in vars(P ), which is not in
dom( ), to a globally fresh IRI from I not belonging to R.</p>
        <p>The freezing GP depends only on the candidate mapping and the triple
patterns occurring in P ; thus, it does not depend either on the speci c operators
used in P , or on the RDF graph over which the query pattern is to be evaluated.
Example 3. For pattern P1 and mappings 1, 2 from Example 1 the freezings
GP11 and GP21 have the following form, for fresh IRIs k and `:
fPropertyAssertion(train London Oxford ); PropertyAssertion(ferry Oxford k)g;
fPropertyAssertion(train London Holyhead );PropertyAssertion(ferry Holyhead `)g:</p>
        <p>Intuitively, the freezing represents the simplest and most general RDF graph
over which all the unde ned variables in a given solution mapping could be
bounded to concrete values. Thus, if GP together with the input graph G is not
a consistent graph for the relevant regime, we can conclude, using condition (C1)
of the regime, that the unde ned variables in will never be matched to concrete
values in any consistent extension of G and hence should be ruled out as an
answer. On the other hand, if G [ GP is consistent, then such an extension exists
and, by condition (C2), the unde ned variables can be mapped in this extension.
De nition 2. Let R = (R; G; P; C; J K) be an entailment regime. A mapping
is R-admissible for a graph G 2 C and legal graph pattern P if G [ GP is a graph
belonging to C. The set of all R-admissible mappings for a consistent graph G
and a legal graph pattern P is denoted as Adm(G; P ).</p>
        <p>Example 4. Clearly, O1 [GP11 is inconsistent since ferries only depart from coastal
cities, but Oxford is an inland city. In contrast, O1 [ GP21 is consistent. Thus, we
have 1 2= Adm(O1; P ), but 2 2 Adm(O1; P ).</p>
        <p>We are now ready to formalise our semantics.</p>
        <p>De nition 3. Given an entailment regime R = (R; G; P; C; J K), the strict query
answering function J Ks is de ned for legal graph patterns P and G 2 C as follows:
1. if P is a BGP then JP KsG = JP KG;
2. if P is P1 AND P2 then JP KsG = (JP1KsG on JP2KsG) \ Adm(G; P );
3. if P is P1 OPT P2 then JP KsG = (JP1KsG on J s ) \ Adm(G; P ); and
4. if P is P 0 FILTER R then JP KsG = f j 2 JPP2K0KGsG and j= Rg,
where \ denotes the standard set-theoretic intersection. If G 62 C then JP KsG = Err
for any graph pattern P . Finally, legal patterns P1 and P2 are equivalent (under
strict semantics), written P1 s P2, if JP1KsG = JP2KsG for any legal G.
Example 5. The strict semantics behaves as expected for our examples: JP1KsO1 =
s
f 1g holds for O1 and P1 from Example 1, while JP2KO2 = ; holds for Example 2.</p>
        <p>
          The strict and normative semantics coincide in two limit cases. First, if the
entailment regime does not allow for inconsistent graphs (i.e., if C = G) as is
the case for the RDF regime [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ], then JP KsG = JP KnG for every legal pattern P
and graph G. Second, if the relevant pattern P is OPT-free then the freezing for
every candidate answer mapping contains no fresh IRIs and is R-entailed by G;
thus, we again have JP KsG = JP KnG for every legal graph G.
        </p>
        <p>Thus, the di erence between the normative semantics J Kn and strict semantics
J Ks manifests only for regimes that admit inconsistency, and is circumscribed
to the presence of OPT in graph patterns, where non-admissible mappings are
excluded in the case of the strict semantics. Note, however, that even if a mapping
1 (respectively 2) is admissible for a subpattern P1 (respectively P2) containing
OPT, it is possible for 1 [ 2 not to be admissible for the joined pattern
P = P1 AND P2. Thus, the admissibility restriction is also explicitly re ected in
the semantics of AND given in De nition 3. This is illustrated in the example
given next.</p>
        <p>Example 6. Consider ontology O3, consisting of the axioms
SubClassOf(</p>
        <p>IntersectionOf(SomeValuesFrom(husband Thing) SomeValuesFrom(wife Thing))
Nothing);
ClassAssertion(Person Mary ):
The rst axiom establishes that a person cannot have both a husband and a wife.
Consider also the following well-designed graph pattern P3:
(ClassAssertion(Person ?X) OPT (PropertyAssertion(husband ?X ?Y ))) AND
(ClassAssertion(Person ?X) OPT (PropertyAssertion(wife ?X ?Z))):
Clearly, = f?X 7! Mary g belongs to the strict answer to each of the OPT
subpatterns of P3 since each of them independently can match to a consistent
extension of O3. However, is not admissible for P3 since Mary has both a
husband and a wife in GP3 , and hence O3 [ GP3 is inconsistent. Thus, JP3KO3 = ;.
s
4.2</p>
      </sec>
      <sec id="sec-4-2">
        <title>Comparing the Normative and Strict Semantics</title>
        <p>Our previous examples support the expected behaviour of our semantics, namely
that its e ect is circumscribed to ltering out problematic answers returned under
the normative semantics. We next formally show that our semantics behaves as
expected in general, provided that we restrict ourselves to well-designed patterns
and negation-free FILTER expressions (which are rather mild restrictions).</p>
        <p>
          It is known that patterns which are not well-designed easily lead to unexpected
answers, even under the normative semantics (we refer to [
          <xref ref-type="bibr" rid="ref2">2</xref>
          ] for a detailed
discussion). Therefore, it comes at no surprise that the intuitive behaviour of our
semantics is only guaranteed under this assumption.
        </p>
        <p>Theorem 1. Let R = (R; G; P; C; J K) be an entailment regime. The inclusion
JP KsG v JP KnG holds for any graph G from C and any legal well-designed graph
pattern P which does not use negation in FILTER expressions.</p>
        <p>Note that Theorem 1 is formulated in terms of subsumption, instead of
set-theoretic containment. The rationale behind this formulation is clari ed next.
Example 7. Consider the ontology O10, which is obtained from O1 in Example 1
by removing all axioms involving Holyhead , and adding the axiom</p>
        <sec id="sec-4-2-1">
          <title>PropertyAssertion(bus Canterbury London):</title>
          <p>Consider also the following graph pattern P10:</p>
          <p>PropertyAssertion(bus ?U ?X) OPT</p>
          <p>(PropertyAssertion(train ?X ?Y ) OPT PropertyAssertion(ferry ?Y ?Z)):
The mapping = f?U 7! Canterbury; ?X 7! London; ?Y 7! Oxford g is returned
by the normative semantics. As already discussed, Oxford is an inland city and
hence cannot have ferry connections; thus, is not returned under strict semantics.
However, it may be possible to reach a ferry connection from London (although
none is given), and hence the answer 0 = f?U 7! Canterbury; ?X 7! Londong
is returned instead of under strict semantics. Clearly, 0 is not a normative
answer and JP10KsO10 6 JP10KnO10 ; however, 0 v and JP10KsO10 v JP10KnO10 .
5</p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>Computational Properties and Static Optimisation</title>
      <p>In this section we rst study the computational properties of our semantics. We
show that the complexity of graph pattern evaluation under strict and normative
semantics coincide, provided that consistency checking is feasible in PSPACE for
the regime at hand. Then we focus on static query analysis, and in particular on
pattern equivalence. We show that the key equivalence-preserving transformation
rules that have been proposed for static optimisation of SPARQL queries continue
to hold if we consider equivalence under strict semantics.
5.1</p>
      <sec id="sec-5-1">
        <title>Complexity of Strict Graph Pattern Evaluation</title>
        <p>Recall that the graph pattern evaluation is the key problem in SPARQL. In the
context of entailment regimes, it is de ned as follows, where x is either n or s.</p>
        <p>Graph Pattern Evaluation
Input : Regime R, legal graph G, legal graph pattern P , and mapping .</p>
        <p>Question: Is 2 JP KxG under the regime R?
Here, when we say that regime R is a part of the input, we mean that it includes
two oracle functions checking consistency of legal graphs and evaluating legal
BGPs over legal graphs, respectively. In what follows, we refer to the problem as
Normative if x = n, and as Strict if x = s.</p>
        <p>
          It is known that the normative graph pattern evaluation problem is in
PSPACE for the RDF regime [
          <xref ref-type="bibr" rid="ref2">2</xref>
          ]. We next argue that membership in PSPACE
holds in general for any regime satisfying the basic properties discussed in
Section 2 and for both normative and strict versions of the problem, provided that
the complexity of both oracles of the regime is in PSPACE.
        </p>
        <p>Theorem 2. Normative and Strict Graph Pattern Evaluation problems
are in PSPACE, provided the oracles associated to input regimes are in PSPACE.</p>
        <p>
          Consequently, the use of our strict semantics does not increase the
computational complexity for reasonable regimes. In particular, it follows directly from
Theorem 2 that the evaluation problem is in PSPACE under both semantics for
the tractable entailment regimes associated to the OWL 2 pro les [
          <xref ref-type="bibr" rid="ref17">17</xref>
          ].
        </p>
        <p>
          It is also known that graph pattern evaluation under normative semantics is
PSPACE-hard for the RDF regime [
          <xref ref-type="bibr" rid="ref2">2</xref>
          ]. To formulate a general hardness result
that holds for any regime we would need to require additional properties for
a regime to qualify as \reasonable". In order not to unnecessarily complicate
the presentation, we simply point out that PSPACE-hardness holds for all the
regimes in the speci cation under both normative and strict semantics [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ].
5.2
        </p>
      </sec>
      <sec id="sec-5-2">
        <title>Static Analysis and Optimisation</title>
        <p>
          Static analysis and optimisation of SPARQL queries has received signi cant
attention in recent years [4, 6, 18{20]. A key ingredient for optimisation is the
availability of a comprehensive catalog of equivalence-preserving transformation
rules for SPARQL patterns. A rich set of such equivalences for normative semantics
and RDF regime is established in [
          <xref ref-type="bibr" rid="ref2">2</xref>
          ] and [
          <xref ref-type="bibr" rid="ref4">4</xref>
          ]. Some of these equivalences, such as
idempotence, commutativity, and associativity of the AND operator, hold without
any restrictions (for our core fragment of SPARQL). However, those that involve
OPT are more intricate and hold only for well-designed patterns. The claim of
this section is that these equivalences continue to hold for any entailment regime,
under both normative and strict semantics.
        </p>
        <sec id="sec-5-2-1">
          <title>Theorem 3. The following equivalences hold for any entailment regime, provided</title>
          <p>the graph patterns on both sides are legal and well-designed, for x 2 fn; sg:
(P1 OPT P2) FILTER R</p>
          <p>P1 AND (P2 OPT P3)
(P1 OPT P2) OPT P3
x (P1 FILTER R) OPT P2;
x (P1 AND P2) OPT P3;
x (P1 OPT P3) OPT P2:
6</p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-6">
      <title>Conclusion</title>
      <p>
        In this paper, we have proposed a novel semantics for optional matching in
SPARQL under entailment regimes where unbound variables in answer mappings
are naturally interpreted as \null" values. Our strict semantics has been designed
to deal in a faithful way with the \lack of regular, complete structures in RDF
graphs" and hence with the fundamental incompleteness of information on the
Semantic Web [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. We believe that both strict and normative semantics are valid,
but one may be more appropriate than the other in certain applications. Both
semantics are compatible at a fundamental level and it would be possible to
exploit them in the same application by letting users commit to one or the other
explicitly when posing queries. Integrating them in a clean way from a syntactic
point of view is more tricky, and it is something we leave for future investigation.
      </p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Prud'hommeaux</surname>
          </string-name>
          , E.,
          <string-name>
            <surname>Seaborne</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>SPARQL query language for RDF</article-title>
          .
          <source>W3C Recommendation</source>
          (
          <year>2008</year>
          ) Available at http://www.w3.org/TR/rdf-sparql-query/.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Perez</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Arenas</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gutierrez</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>Semantics and complexity of SPARQL</article-title>
          .
          <source>ACM Trans. Database Syst</source>
          .
          <volume>34</volume>
          (
          <issue>3</issue>
          ) (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Angles</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gutierrez</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>The expressive power of SPARQL</article-title>
          . In: ISWC. (
          <year>2008</year>
          )
          <volume>114</volume>
          {
          <fpage>129</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Schmidt</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Meier</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lausen</surname>
          </string-name>
          , G.:
          <article-title>Foundations of SPARQL query optimization</article-title>
          .
          <source>In: ICDT</source>
          . (
          <year>2010</year>
          )
          <volume>4</volume>
          {
          <fpage>33</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Arenas</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Perez</surname>
          </string-name>
          , J.:
          <article-title>Querying semantic web data with SPARQL</article-title>
          . In: PODS. (
          <year>2011</year>
          )
          <volume>305</volume>
          {
          <fpage>316</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Letelier</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Perez</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Pichler</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Skritek</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Static analysis and optimization of semantic web queries</article-title>
          .
          <source>ACM Trans. Database Syst</source>
          .
          <volume>38</volume>
          (
          <issue>4</issue>
          ) (
          <year>2013</year>
          )
          <fpage>25</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Polleres</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>From SPARQL to rules (and back)</article-title>
          .
          <source>In: WWW</source>
          . (
          <year>2007</year>
          )
          <volume>787</volume>
          {
          <fpage>796</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Motik</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Patel-Schneider</surname>
            ,
            <given-names>P.F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Parsia</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          :
          <article-title>OWL 2 Web Ontology Language Structural Speci cation and Functional-style Syntax</article-title>
          .
          <source>W3C Recommendation</source>
          (
          <year>2012</year>
          ) Available at http://www.w3.org/TR/owl2-syntax/.
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9. W3C SPARQL Working Group:
          <article-title>SPARQL 1.1 Query language</article-title>
          .
          <source>W3C Recommendation</source>
          (
          <year>2013</year>
          ) Available at http://www.w3.org/TR/sparql11-query/.
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Glimm</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ogbuji</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>SPARQL 1.1 Entailment Regimes</article-title>
          .
          <source>W3C Recommendation</source>
          (
          <year>2013</year>
          ) Available at http://www.w3.org/TR/sparql11-entailment/.
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Glimm</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          , Krotzsch, M.:
          <article-title>SPARQL beyond subgraph matching</article-title>
          .
          <source>In: ISWC</source>
          . (
          <year>2010</year>
          )
          <volume>241</volume>
          {
          <fpage>256</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Kollia</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Glimm</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          :
          <article-title>Optimizing SPARQL query answering over OWL ontologies</article-title>
          .
          <source>J. Artif. Intell. Res</source>
          .
          <volume>48</volume>
          (
          <year>2013</year>
          )
          <volume>253</volume>
          {
          <fpage>303</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Kontchakov</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rezk</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rodriguez-Muro</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Xiao</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Zakharyaschev</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Answering SPARQL queries over databases under OWL 2 QL entailment regime</article-title>
          .
          <source>In: ISWC</source>
          . (
          <year>2014</year>
          )
          <volume>552</volume>
          {
          <fpage>567</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Arenas</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gottlob</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Pieris</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Expressive languages for querying the semantic web</article-title>
          .
          <source>In: PODS</source>
          . (
          <year>2014</year>
          )
          <volume>14</volume>
          {
          <fpage>26</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Kostylev</surname>
            ,
            <given-names>E.V.</given-names>
          </string-name>
          ,
          <string-name>
            <given-names>Cuenca</given-names>
            <surname>Grau</surname>
          </string-name>
          ,
          <string-name>
            <surname>B.</surname>
          </string-name>
          :
          <article-title>On the semantics of SPARQL queries with optional matching under entailment regimes</article-title>
          .
          <source>In: ISWC</source>
          . (
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Perez</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Arenas</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gutierrez</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>Semantics and complexity of SPARQL</article-title>
          . In: ISWC. (
          <year>2006</year>
          )
          <volume>30</volume>
          {
          <fpage>43</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Motik</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Cuenca Grau</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Horrocks</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wu</surname>
            ,
            <given-names>Z.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fokoue</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lutz</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          : OWL 2
          <string-name>
            <given-names>Web</given-names>
            <surname>Ontology</surname>
          </string-name>
          <string-name>
            <surname>Language</surname>
          </string-name>
          : Pro les (
          <issue>27 October 2009</issue>
          ) Available at http://www. w3.org/TR/owl2-profiles/.
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18.
          <string-name>
            <surname>Chekol</surname>
            ,
            <given-names>M.W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Euzenat</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Geneves</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          , Layada, N.:
          <article-title>SPARQL query containment under RDFS entailment regime</article-title>
          .
          <source>In: IJCAR</source>
          . (
          <year>2012</year>
          )
          <volume>134</volume>
          {
          <fpage>148</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          19.
          <string-name>
            <surname>Chekol</surname>
            ,
            <given-names>M.W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Euzenat</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Geneves</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          , Layada, N.:
          <article-title>SPARQL query containment under SHI axioms</article-title>
          . In: AAAI. (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          20.
          <string-name>
            <surname>Chekol</surname>
            ,
            <given-names>M.W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Euzenat</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Geneves</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          , Layada, N.:
          <article-title>Evaluating and benchmarking SPARQL query containment solvers</article-title>
          .
          <source>In: ISWC</source>
          . (
          <year>2013</year>
          )
          <volume>408</volume>
          {
          <fpage>423</fpage>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>