- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 04 Dec 2006 13:50:25 +0000
- To: Pat Hayes <phayes@ihmc.us>
- 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. The skolemized version is a bit unusual so I see the decision as how accepting of told bnodes we are. I'd guess implementations make G = GQ What about defining it so that Q does not share any bnodes with G, putting the burden on Q, not 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. 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. Oneway woudl be to map the bnodes in the Q as well, then restricting the mapping just to named variables, 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. Then the binding is the second mapping. Andy
Received on Monday, 4 December 2006 13:50:57 UTC