Re: Editorial changes in Section 2.5

>On 30 Jan 2006, at 19:29, Pat Hayes wrote:
>
>>  But I am getting tired of arguing with you. Go ahead and insert in the
>SPARQL spec what is likely to be the most inelegant, incomprehensible
>and irrelevant definition yet included in any W3C document. I am fairly
>sure it is also, in its present form, subtly wrong; but frankly, at this
>stage, whether it is wrong or right is of relatively minor importance.
>
>Facts, that may help you to understand betterthe current definition and
>decrease your offensive (to everybody, but mainly to the chair and the
>editor) bitterness:

I apologize for the perceived tone, but it was genuine exhaustion, 
not bitterness. And speaking now quite objectively, I do feel that 
this entire semantics business has made the spec worse rather than 
better, and that it is getting worse with every iteration. (There is 
an elegant, simple, robust definition based on entailment, which I 
suspect is probably what the original comments deploring the old 
instance/subgraph definition had in mind; but this is not that.)

>Let me compare 3 different semantic definitions of e-matching. The first
>is "Pat's" definition

For the record, this is the definition that we all agreed on 
informally after extended email discussions, and which you modified, 
unilaterally and without discussion, between the final group-CCd 
email and the telecon vote. If you had suggested it in email, with 
the justification you propose below, I would have had time to point 
out the error in your reasoning.

>, with G' not sharing bnodes with BGP, and with
>union; the second is the "orderedMerge" definition, with arbitrary G',
>and with orderedMerge; the third is the "current" definitions, with
>arbitrary G', with arbitrary BGP', with G' and BGP' not sharing any
>bonode, and with union.
>
>1) The current definition is equivalent to the orderedMerge definition,
>and which are more general (less constrained, and therefore more
>desirable to have as a SPARQL definition) than Pat's definition. Why?
>See (2) and (3).

See my comments below explaining why not. Basically, you are mixing 
up the RDF graph abstract syntax with scoping rules for names in 
surface lexicalizations.

>
>2) The orderedMerge and the current definitions allow to have really
>arbitrary bnode names in the answerset, stressing the fact that they
>are pure existential variables and that they are *only* scoped within
>the answer itself.

This is true for "Pat's" definition also. Bear in mind that we are 
arguing about the definition of answer binding (or of matching), not 
of a CONSTRUCT graph. The bnodes in an answer binding can only come 
from G', in any of the definitions. Even this requirement could be 
relaxed, if y'all feel it would be desireable, by allowing bnodes 
from G' or BGP itself. I suggested this already, but got no response. 
It would for example allow this case:

_:z :p _:z

SELECT ?x WHERE {?x :p _:y}

with answer binding x/_:y (rather than, say, _:uu), so that it points 
into the query itself. This only makes sense if we assume that the 
answer set and the query pattern share a bnode scope, however (for 
example, this would be the case if we said the answer document was 
considered to have a virtual copy of the query in it, playing much 
the same role there that the G' does in the entailment conclusion.)

>3) Pat's definition disallows to have bnode names in the answerset that
>may be clashing with bnodes in the query.

It disallows the query and the scoping graph to share bnodes. It says 
nothing about bnode names. The scope of names is determined by the 
scoping conventions used in the surface lexicalization, which we 
specify elsewhere.

>So, the scope of the bnodes
>in the answerset includes explicitly the query. This is clearly an
>un-intended effect.

It is an intended effect, to avoid what might otherwise be a false 
result. In fact, the spec already assumes this: the scopes of the 
answer set and the query are defined to be distinct, by the scoping 
rules for the answer set documents (which you, Enrico, agreed to in a 
recent email comment on Andy's editorial thread). So this seems to 
not be an issue.

>  Pat's definition is a special case of the other two
>definitions, since it disallows some renaming in the answerset.
>
>4) An implementation that arbitrarily renames bnodes in the answerset
>will not be SPARQL compliant. Or, in other words, how the labels of
>bnodes in the final answerset are chosen is significative to decide
>whether an implementation is SPARQL compliant.

No. You are confusing bnodes with bnodeIDs. Blank nodes are defined 
in the RDF graph syntax, which is an abstract syntax, not a lexical 
syntax, see http://www.w3.org/TR/rdf-mt/#graphsyntax. For a 
lexical-syntactic analogy, think of a bnode as a pair consisting of a 
bnodeID and a lexical scope. The definitions which mention entailment 
and graph equivalence and merging/unioning all refer to the RDF graph 
syntax (which the RDF semantics is defined over) so they mention 
bnodes themselves, not bnodeIDs.

If we say that bnodeIDs in an answer document are scoped to that 
document, then if it uses a bnodeID which is identical to a bnodeID 
in the query, this is merely a lexical coincidence: they do not 
identify the same bnode, by virtue of the lexical scoping rules for 
bnodeIDs in answer documents. But on the other hand, if we were to 
allow the possibility that the answer set and the query can share 
bnodes, then we would need to specify more delicate rules for 
determining the scopes of bnodeIDs in the answer-set result document.

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 Tuesday, 31 January 2006 18:00:56 UTC