when considering RDFS semantics (i.e., sub-
property semantics) should retrieve pairs of cities con-
nected by a property that is not a transport (not
prefixed by transport) or any of its sub-properties.
Implementing this query in SPARQL 1.1 (as the fol-
lowing one) may retrieve pairs of cities connected by
a property that is a sub-property of transport (e.g.,
bus). Besides, there is no clear method on how to deal
with this in SPARQL 1.0 and SPARQL 1.1 while we
provide in Section 4.2 a detailed discussion and ex-
amples on how to use wild-card and negation to deal
with sub-property matching.
SELECT ?city1, ?city2
FROM ...
WHERE {
?city1 ?newVar ?city2 .
Filter (NOT(fn:strstarts(str(?newVar),
"transport")))
}
This case is even worse if one wants to retrieve
pairs of cities connected by a sequence of flights be-
longing to airfrance company. This query could be
expressed using wild-card as follows:
h?city1 (airfrance:#)
∗
?city2i
where * is the closure operator used in path ex-
pressions (e.g., regular expressions) to match a se-
quence of predicates (c.f. (Alkhateeb et al., 2009;
P
´
erez et al., 2010)).
Nonetheless, without using wild-cards, a variable
must be introduced with the closure operator to ex-
press the query and the evaluation of such queries
could be intractable for large graphs in particular
for finding simple paths (i.e., paths without loops)
(Mendelzon and Wood, 1995; Arenas et al., 2012) .
The wild-card could be combined with the nega-
tion operator to provide more interesting queries as in
the following simple one:
h?city1 !(airfrance:#) ?city2i
that retrieves pairs of cities connected by any
property that is not belonging to airfrance com-
pany.
4.2 Querying RDFS Graphs
Evaluating SPARQL queries over RDF graphs con-
sidering RDFS semantics needs additional treatment
either for the RDF graph to be queried (e.g., calcu-
lating the closure graph) or transforming the input
query to some form of path queries (see (Alkhateeb
et al., 2009; P
´
erez et al., 2010; Alkhateeb and Eu-
zenat, 2014) for querying a core fragment of RDFS
{sc, sp, type, domain, range}).
In this section, we propose a novel approach for
evaluating SPARQL queries over RDFS graphs with-
out the need to the closure operator *. In this ap-
proach, we rely on the fact that RDF Schema have
usually small size with respect to the RDF data graph.
The proposed approach consists of several steps that
are presented in the following.
1. We first build an index (hash table) for the RDF
Schema terms. Each entry in the index contains an
RDFS term t (i.e., RDFS terms that are appearing
in the RDF Schema of the RDF data graph) and
the corresponding ancestor terms represented as
a path from the root term to the parent term of t
denoted by PA
t
. Table 1 represents the index table
for the RDF Schema terms of Figure 1. It contains
two columns: one for the RDF Schema term and
the other for the path ancestor term in the RDF
Schema. For instance, the term tag has the path
ancestor term transport/bus since there exists a
path from tag to transport (i.e., htag sp busi
and hbus sp transporti).
2. Given an RDF data graph G, we construct an RDF
graph G
0
in the following way; for every triple hs,
p, oi ∈ G:
– add hs, PA
p
/p, oi to G
0
, if p is a term ap-
pearing in the RDF Schema and p /∈ {sc, sp,
type, domain, range}.
– add hs, p, oi to G
0
, otherwise;
Graph G
0
in Figure 2 corresponds to
the RDF graph of Figure 1, where hc
3
transport/bus/tag c
4
i ∈ G
0
since hc
3
tag
c
4
i ∈ G and transport/bus is the path ancestor
of tag.
It should be noticed that G
0
is constructed one
time and not for each query. It can be updated
once the original RDF G is modified.
3. Given a SPARQL triple t = hs p oi, t is trans-
formed to t
0
= hs PA
p
/p:# oi.
According to this step, the following SPARQL
query:
h?city1 transport ?city2i
is transformed to the following one t
0
using the
index structure in Table 1:
h?city1 transport:# ?city2i
Note that transport has no path of ances-
tor terms since it is a root term in the RDF
Schema. Therefore, we just append the term with
the wild-card operator. However, the SPARQL
triple h?city1 bus ?city2i will be converted
h?city1 transport/bus:# ?city2i
4. Evaluate the triple t
0
over G
0
.
The same approach can be applied when using the
negation operator ! in the triple patterns by applying
Introducing Wild-card and Negation for Optimizing SPARQL Queries based on Rewriting RDF Graph and SPARQL Queries
185