Re: Editorial thread for BGP matching

On 23 Jan 2006, at 17:54, Pat Hayes wrote:
>> 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.

To be honest, this is true for E-entailment, for the scoping graph, etc.
In fact, the above applies to the current spec as a whole.
It is enough to have the subgraph matching in the normative part, and  
nothing else.
So, if you insist in your argument, in order to be taken seriously  
there will be no entailment in the normative spec: is the  
introduction of entailment useful if we use it only for simple  
entailment?

I don't believe we have to go back and not to have entailment in the  
definition!

I don't see the scoping set B having a different role than, say, the  
E-entailment.
Both allow us to introduce in the spec a terminology that future user  
have to refer to in order to make their choices - if they want to say  
that they are (backward) compatible with SPARQL. Future implementors  
have to declare, for example, what is their kind of entailment *and*  
their scoping set B, since they are in the spec.

--e.

Received on Monday, 23 January 2006 17:07:15 UTC