Re: draft for my action item

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.

	Andy


> 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