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

Re: draft for my action item

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Tue, 05 Dec 2006 12:10:14 +0000
Message-ID: <457561A6.8030305@hp.com>
To: Pat Hayes <phayes@ihmc.us>
CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>

Pat Hayes wrote:
>> Pat Hayes wrote:
>>> First very rough draft visible at
>>> http://www.ihmc.us/users/phayes/SPARQL-BGP-semantics.html
>>> I havnt yet tried to fit this elegantly into your algebra document, 
>>> Im afraid, or linked it to the test cases.
>>> The missing proof at the end is elementary but tedious to write 
>>> out, maybe should be in an appendix somewhere. In fact, I'd be 
>>> happy to put the whole of the first section into an appendix, if we 
>>> can make an appendix be normative.
>>> Feedback welcome.
>>> Pat
>> Pat,
>> Para 2 defines various possibilities for GQ for SPARQL.  I think we 
>> need to be more definite and specify one
> Para 2 is about extensions of SPARQL. We do specify one for SPARQL 
> itself in the next section. We have to allow the DL folk freedom to 
> refuse to handle bnode bindings when dealing with OWL-DL, they insist 
> on it.
> Maybe the first part should all be in an appendix somewhere.

Certainly have a section that is specifically for SPARQL and a section for 
extensions, keeping them more separate than the text currently feels, would be 
good.   I can do that as part of editing the material into rq24.

>>  The skolemized version is a bit unusual
> Well, we did consider it at one point seriously, and you could 
> interpret Enrico's definitions this way.
>> so I see the decision as how accepting of told bnodes we are.  I'd 
>> guess implementations make G = GQ
> Really? So all bnode bindings are told bnodes? That doesnt align with 
> our test cases.

Yes and no :-)  It was my intention there because the result set (graph or SRX 
file) also has an equivalence mapping by serializing bnodes with 
document-scoped labels.  The test cases are safe.

Another use is in API work where the query is results are not serialized : 
applications are directly working with the graph and doing things like adding 
triples with a found bnode subject.

So the making G = GQ is for finding the simplest expression of SPARQL for 
simple entailment and also to be honest about applications are actually doing.

Saying "any graph that is bnode-isomorphic to G" would work because it could 
be G.  I am trying to find the most direct statement here.

>> What about defining it so that Q does not share any bnodes with G, 
>> putting the burden on Q, not GQ?
> It has to share no bnodes with Q or with G to get it right.

"it"?  Isn't that Q?  So the condition is Q and G do not share bnodes if G = GQ.

>>  As we have to talk about SPARQL query strings so we can impose the 
>> condition that parsing does not generate a bnode shared with G.
> Yes, but there are 2 issues. Bnodes in Q aren't shared with G, sure. 
> But bnode bindings to variables in Q, returned in answers: are these 
> the actual bnodes from G itself? If so they are told bnodes, because 
> they are the same over multiple queries.

Serialization, either a result set or in the returning query will split bnodes 
because on parsing separate bnodes would be allocated - unless extra 
information is available.  Like the app/server telling which ever parser it is 
that that really are labels with wider scope :-)

I agree this is a bit indirect and saying GQ is any fixed bnode-isomorphic 
graph and that Q and GQ do not share bnodes would not rely on the indirection 
that any serialization step introduces.

>> Cardinality for SPARQL: the definition is for a binding of query 
>> variables then there is the answer set.  There is no conditions on 
>> the cardinality unless we take it to be implicitly one, which was 
>> contrary to the decision last week.
> NOt sure I follow this. I thought I had phrased it to match the 
> decision we took last week.
>> Oneway woudl be to map the bnodes in the Q as well, then restricting 
>> the mapping just to named variables
> Thats how I do it, right?
>> , it seems cleaner to have a mapping, for SPARQL for simple 
>> entailement, from bnodes in the query to terms of G/GQ, then a 
>> separate mapping of the named variables.
> You have to do it the other way round, is the problem.

Sorry I don't understand that - why can't the bnodes in the Q be mapped first, 
then the named variables?  making sure that the mapping does not mix bnodes of 
course.  Maybe that makes the one step method clearer anyway.


> Then you have 
> to show that the second bnode mapping doesn't screw up any of the 
> bnodes introduced by the variable instantiation. This is why Enrico 
> was forced into using one-way merging and other complications. Im 
> trying to avoid going into that swamp.
>>  Then the binding is the second mapping.
> We could do it that way. Then we need to show that the two mappings 
> commute, but I guess we have to show that anyway.
> Pat
>> 	Andy
Received on Tuesday, 5 December 2006 12:10:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:52 UTC