- From: Pat Hayes <phayes@ihmc.us>
- Date: Mon, 4 Dec 2006 11:26:09 -0600
- 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 >> >>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. > 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. Pat > > 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