- From: Pat Hayes <phayes@ihmc.us>
- Date: Tue, 31 Jan 2006 11:31:24 -0600
- To: Enrico Franconi <franconi@inf.unibz.it>
- 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: 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