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

Re: draft for my action item

From: Pat Hayes <phayes@ihmc.us>
Date: Mon, 4 Dec 2006 11:26:09 -0600
Message-Id: <p06230902c19a08a8f4f7@[]>
To: "Seaborne, Andy" <andy.seaborne@hp.com>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>

>Pat Hayes wrote:
>>First very rough draft visible at
>>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.
>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.

>  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.

>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.

>  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.

>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. 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.


>	Andy

IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Monday, 4 December 2006 17:26:23 UTC

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