W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

[TF-ENT] redundant blank nodes

From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Date: Wed, 7 Oct 2009 17:28:21 +0100
Message-ID: <492f2b0b0910070928h19661be1o3dc514ee111f1c37@mail.gmail.com>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
Hi all,
I am working my way through the open questions/issues, so the next on
my list is something that Andy mentioned. At the moment, we have the 2
conditions C1 and C2 that restrict the set of possible answers to a
finite set of answers for RDF(S) entailment regimes. What these
conditions don't cover is redundant answers that use different blank
nodes. E.g.,
suppose G is
_:b1 :p :z.
_:b2 :q :y.
SG is:
_:sg1 :p :z.
_:sg2 :q :y.
and the BGP of the query is
?x :p [] .
We would get the two solutions
(x, _:sg1)
(x, _:sg2)
because both _:sg1 :p [] and _:sg2 :p [] are well-formed RDF triples
that are RDF(S) entailed by G (C1) each subject is in the set of terms
used by the scoping graph and (C2) μ(?x) is a blank node occurring in
SG. This always results in a finite answer sequence, but the more
blank nodes we have origianlly, the more redundant answers we get.

Now what I would rather have only (x, _:sg1) as an answer. This could
be defined by a notion of derivability I think. E.g.,
Let R be a set of entailment rules for the entailment regime E, then,
for each triple (s, p, o) in P(BGP), there must be a derivation of (s,
p, o) from SG by means of R.
Now I could use, for example, the RDFS entailment rules as suggested
by ter Horst, and I get what I want because _:sg2 :p [] has no
derivation.

What I am quite unhappy about is the use of "a set of entailment
rules" because different systems might want to use different ways of
deriving consequences and this might be too specific. Any opinions on
that? Any better suggestion?

Birte




-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529
Received on Wednesday, 7 October 2009 16:28:54 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:40 GMT