RE: [TF-ENT] redundant blank nodes

Birte,

Could you explain further?  This could be a way forward but I can't see how the existing text works for this.

The only entailment relationship in the matching step is between G and P(BGP) and does not consider SG.

SG is related to G but after that it is just a graph. The way it is related isn't mentioned and does not appear at the point of entailment between G and P(BGP). In the matching step, only the vocabulary of SG is considered, not the way it is e-equivalence to G.  Maybe we can add that in some way.

 Andy


> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
> On Behalf Of Birte Glimm
> Sent: 08 October 2009 12:22
> To: SPARQL Working Group
> Subject: Re: [TF-ENT] redundant blank nodes
> 
> 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 Friday, 9 October 2009 17:02:22 UTC