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.

We need the scoping graph to make sense of the bnode scopes, even in 
the simple case. But indeed, seems to me that SPARQL extensions and 
E-entailment should not be discussed in the normative SPARQL spec, 
unless that spec is going to at least mention some examples (if only 
informatively).

>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.

Well, I hate to point this out at this late stage, but that was 
indeed the decision we had come to several months ago, and I was 
quite happy with. But let us agree not to dream about going back to 
those simple, happy days of yore, now that we have come this far.

>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 didn't suggest that. By point was only that to introduce a formal 
definition that does not actually constrain anything, and is never 
used or even mentioned again in the document that defines it, is poor 
style. If I were reading such a document and found something like 
this, it wouldn't help me understand the spec, but it would leave me 
with a rather negative opinion about the authors.

>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.

Fair enough, but then what we should to is (a) define SPARQL, as 
directly as possible (b) define "SPARQL extension", using E- and B, 
and require the future specs to specify E- and B suitably, and 
perhaps (c) show briefly how SPARQL itself fits that definition by 
suitable choice of E and B. But if, as I had understood - perhaps 
wrongly - from Andy's emails, such extensions weren't even going to 
be mentioned in this document, then I see no reason to include (b) in 
it. I'm not meaning to suggest that it shouldn't be written up and 
published, I was only following what I thought was Andy's suggestion 
for how to assign material to various documents. But this should 
probably be decided by the WG. I'd be happy either way, as long as 
each document (if there are more than one) makes internal sense.

Pat

>
>--e.


-- 
---------------------------------------------------------------------
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 21:49:26 UTC