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

Re: [TF-ENT] redundant blank nodes

From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Date: Thu, 8 Oct 2009 12:21:40 +0100
Message-ID: <492f2b0b0910080421n13dca27bkd93e6c8a17958153@mail.gmail.com>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
Actually, I don't think any more we have a problem here because (x,
_:sg2) is not an entailed triple. I should have seen that earlier and
apologise for the confusion. I explain below:

We assumed the scoping graph SG is:
_:sg1 :p :z.
_:sg2 :q :y.
and the BGP of the query is
?x :p [] .
We assumed that (unfortunately) (x, _:sg2) would be an answer, but it
is not. Clearly _:sg2 :p [] is a well-formed RDF triple, but it is NOT
RDF(S) entailed by SG or G because you cannot just exchange blank
nodes. You can introduce fresh blank nodes, but you have to keep track
of which of your fresh blank nodes is allocated to which existing
node. You can validly derive:
_:sg1_1 :p :z.       for _:sg1_1 allocated to _:sg1
_:sg1_2 :p :z.       for _:sg1_2 allocated to _:sg1_1
_:sg1 :p _:z_1.     for _:z_1 allocated to :z
_:sg1_1 :p _:z_1.
etc
There is no legal way to get
_:sg2 :p :z.
This would say that :z has both a :p and a :q predecessor and that
there exists a node (_:sg2) that has both a :p and a :p sucessor. This
does not follow from the given graph. The given graph just says there
exists a node that has :z has :p successor (_:sg1) and there exists a
node that as :y as :q successor (_:sg2). They could be the same, but
they do not have to be the same and entailment considers only what is
true in all models.
Thus, you cannot arbitrarily use blank nodes from the scoping graph.
You can only use them in consequences if they stand for the same node.
You can introduce (arbitrarily many) fresh blank nodes, but you still
have to keep track of which fresh node represents which original node
(called allocated to in the RDF spec). We will not return this fresh
blank nodes in the query answers (could be infinitely many), but they
can of course be used in the derivation process.

Birte


2009/10/7 Birte Glimm <birte.glimm@comlab.ox.ac.uk>:
> 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
>



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529
Received on Thursday, 8 October 2009 11:38:19 GMT

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