Re: Editorial thread for BGP matching

>On 20 Jan 2006, at 20:26, Pat Hayes wrote:
>>If its any consolation to anyone, I'm now the one who is feeling overwhelmed.
>
>Our version is basically stable since three months :-)
>
>>PS. I agree with the separate document idea for the non-SPARQL 
>>stuff. We could also discuss things like told-bnodes in there as 
>>SPARQL variations.
>
>This makes sense.
>
>>but I'll do you a version with the simplified definitions before 
>>Tuesday, for comparison.
>>
>>But then the SPARQL definitions should not even mention the scoping 
>>set B: all we need is the scoping graph being a bnode variant of G 
>>which should be standardized apart from all the BGPs and which 
>>defines the scope of the answer set.
>
>I can't believe that now you are still changing your mind from your 
>proposal of two days ago!

GIVEN the editorial decision to only put the SPARQL-specific 
definitions in the actual document and to put all the extensions in a 
separate document - which changes the discussion rules slightly - 
this seems appropriate. The use of B only confuses the exposition 
when we are limited to the SPARQL case.

>As I already noticed several times, I don't see how this could be 
>smoothly extended to languages with implicit existentials: I like 
>the scoping set B.

So do I, for the general case. But the general case isn't going to be 
covered in the SAPRQL document itself, as I understand Andy's 
editorial decision.

>If we go with a separate document, we have to have the normative 
>definitions applied only to simple entailment, but containing *all* 
>the ingredients to be parametrised

No, we describe SPARQL normatively in the SPARQL document itself, and 
we describe a generalization of SPARQL, stated as generally as 
possible and with several particular cases describe and analysed in 
detail, in a separate document. That is how I read Andy's proposal, 
in any case, and I think it is an excellent one.

>  - BTW this is the current version by Andy which I like a lot. In 
>the non normative part we should show how the various normative 
>parameters can be utilised to capture different extensions 
>(told-bnodes, rdf/rdfs entailment, owl-dl (data) entailment, etc).
>
>It seems to me *arbitrary* to have a normative document that works 
>only for simple entailment by leaving crucial ingredients apart 
>necessary for defining the extensions (your 'simplified' 
>definitions), and to have those ingredients in only the separate 
>part.

There are two issues that we must adequately capture and explain. One 
is how to properly handle bnode scopes between the dataset, query and 
answer documents. I think we all understand this issue and differ 
only on the aesthetics of how to best express it, and the solution 
applies equally well to all cases, right up to OWL, and will be 
incorporated in the normative definitions. The other is how to 
delimit or restrict the set of answer bindings, and this varies 
dramatically from case to case. The only fully general framework is 
to refer to an arbitrary parameter - the B set - which in effect says 
nothing, since there are no general constraints on B. But I see no 
purpose in having a normative definition which (by itself) says 
nothing, and which is not used anywhere in the normative 
specification documents themselves. We could get the same 'legal' 
effect simply by remarking in the text that SPARQL extensions [may] 
restrict the set of legal answer bindings in various ways. The 
introduction of the 'blank' parameter B says exactly as little as 
that, and unless B is mentioned elsewhere in the text, it is just an 
example of a notoriously bad expositional style, in which some entity 
is given a 'mathematical-sounding' name for no reason other than to 
seem 'mathematical', as when someone writes "Suppose there is a set, 
S, of foodles..." and then never mention S ever again.

Actually, is it reasonable to require in ALL cases that B at least 
contain the non-bnode IDs in G'? A possible reason why not: suppose 
we are using OWL-DL version of SPARQL to query a 
non-OWL-DL-well-formed dataset. Should the server deliver 
DL-incorrect bindings, if they are present in the dataset? Or should 
the entailment type impose wellformedness conditions on the dataset 
as well as the query, so that servers should be obliged to deliver 
errors under such a condition?

>Note that in a sense already the LC design (fixed in minor parts) 
>would be a correct and simple normative definition of BGP matching: 
>of course, there would be not even a mention of entailment.

Well, at least we have now (thanks to your efforts) got the bnode 
scoping handled properly. Seriously, this was a big step forward.

Pat
-- 
---------------------------------------------------------------------
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, 23 January 2006 16:55:27 UTC