W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2006

Re: Editorial changes in Section 2.5

From: Enrico Franconi <franconi@inf.unibz.it>
Date: Tue, 31 Jan 2006 13:00:46 +0100
Message-ID: <1138708846.43df516e34422@www.inf.unibz.it>
To: Pat Hayes <phayes@ihmc.us>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>

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:

Let me compare 3 different semantic definitions of e-matching. The first
is "Pat's" definition, 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).

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.

3) Pat's definition disallows to have bnode names in the answerset that
may be clashing with bnodes in the query. So, the scope of the bnodes
in the answerset includes explicitly the query. This is clearly an
un-intended effect. 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.

--e.
Received on Tuesday, 31 January 2006 12:00:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:25 GMT