- From: Pat Hayes <phayes@ihmc.us>
- Date: Tue, 24 Jan 2006 11:19:45 -0600
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
>Pat, > >There seems to have been some email change (Your name on the email was >"Pat Hayes" andis now "Patrick J. Hayes") and the formatting makes it >hard/imposible to work out who said what. The meesage below contains >quotes from different messages but they aren't highlighted in anyway. Sorry, I had to use a grungy web mailer last night. Here it is for the record with proper formatting, and Ive added speaker IDs. Pat ------ >On 23 Jan 2006, at 22:49, Pat Hayes wrote: >>>[Enrico:] 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. >> >>[Pat:] 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. > >[Enrico:] And in fact, in the current version of the document, >edited by Andy himself, there is no mention whatsoever to any SPARQL >extension. In the spirit of what I was saying in the above paragraph >- that you fail to understand - the SPARQL spec is specifying >*only* the simple entailment, but using the framework that can be >used somewhere else to define *smoothly* the SPARQL extensions. I do *understand* this, but I don't *agree* that the current format is the best way to go. I think the result is neither appropriate nor effective for the SPARQL standard document, that it will produce enormous confusion and give rise to extended questions about why all this stuff is in the spec when it is not actually used anywhere. One man's smoothly is another man's total mystification. This is purely a matter of exposition, not of any disagreement about formal content. It should be possible for someone who wants to read and understand the actual SPARQL specification to read just that, and not be burdened with trying to make sense of elaborate definitions which have no actual content unless given flesh by examples, and which do not impinge on the actual spec. Putting the fully general definition in the heart of the SPARQL document is like requiring the reader to go on a long detour and work hard for no purpose. This is purely a matter of style, but I think style can be important. I agree that the more elaborate extended definitions should be published by this WG somewhere, and should be citable by those, like yourself, who wish to deal with SPARQL extensions, and maybe even given normative weight if we can do that reasonably. But the bulk of our intended audience will be most interested in SPARQL itself. And to repeat, we cannot give two different normative definitions of SPARQL basic query graph matching. If we state the general definition then we must immediately qualify it by imposing the particular case, and declare that to be normative, rendering the more general definition otiose and pointless. If I were reading the resulting text, I would wonder why the hell the definition was phrased in such a grossly misleading way, to no apparent purpose. The point becomes clear only when the other cases are discussed, or at least mentioned; but these other cases, to repeat, cannot actually be SPARQL. We can only define one language in the spec. >>[Pat:] 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. > >[Enrico:] I thought that Andy is in fact doing this: > >On 20 Jan 2006, at 12:58, Seaborne, Andy wrote: >>After considering what material to put in rq23 and how to record >>the discussions and conclusions in all the email, I propose that >>the interested parties prepare a separate WG note (or, >>alternatively, a member submission). >>I will include some text that explains SPARQL at the level of >>simple entailment because the point of rq23 is to say what SPARQL/Q >>is, not what it might be. It is confusing to have all the possible >>options outline when they don't apply to this version of SPARQL. > >and in fact this is what happens in the current version of the >document. I agree with Andy's point of view of not having in the >spec any mention of the extensions, and this is what can be seen in >the current document. > >On 20 Jan 2006, at 12:58, Seaborne, Andy wrote: >>The only other thing I think we might consider is an appendix that >>expands on the definitions section but again I think it should >>stick to what this SPARQL is. > >And we also agree here. > >Look, Pat: your "simplified wording" is indeed very similar to what >we have already in the current document (try to read the current >version with the option **). And, according to your complaint about >the current document, your "simplified wording" also contains a lot >of useless material for just defining what happens in the case of >subgraph matching. What useless material? The only formal addition is the requirement that the scoping graph contain no bnode in BGP, which can be expressed using six extra words in the definition. In exchange, one avoids the need to define "ordered merging", and relieves the reader of the burden of trying to understand why it is necessary. I drafted some extra explanatory prose about bnode scopes, which is up to Andy to use or not, his call: but I havn't yet seen a convincing explanation of the rationale for the other definition written by anyone, including yourself. Maybe I am unusually dense, but if you read through the email thread I think you will find that it took you and Sergio four cleverly constructed examples to make all the necessary points in a full explanation that I could follow. >[Enrico:] So, from this point of view your wording is no better than >the current one. It may be true that your wording could be easier to >understand, and that's why I proposed to have it as *explanation* in >the current document; and in fact it *is* there, and of course it is >waiting for you to make the explanation better. >And most importantly, I am saying that your "simplified wording" is >less accurate because it will not scale up smoothly to any extension. Wrong. It is not in any way inaccurate, and it scales up smoothly to all the extensions we have contemplated in this thread. But perhaps we are talking past each other. The issue I am talking about is the distinction between the definition using "entails S(G' orderedmerge BGP)" as its core, and that using "entails (G' union S(BGP))". Call this difference in wording the first issue. The other issue is whether or not the SPARQL document should give the fully general form of the definition which mentions E-entailment and refers to a scoping set B, or the simplified version of it which mentions only simple entailment and does not bother with the scoping set because that is entirely irrelevant for any entailment below your restricted version of OWL-DL. Call that the second issue. It is important to see that these issues are orthogonal. The first issue is just about how to best describe the bnode-scoping restrictions on answers with respect to the dataset and the query. This applies uniformly to all notions of RDF entailment; and the 'union' style of wording, with the appropriate restriction on the bnodes in the scoping graph, works with all entailment forms uniformly, and can be used in the general (E- plus B) case quite correctly. (It does not conflate query bnodes with variables, so handles the 'true existential' case for OWL in the way you prefer, even though this is irrelevant for SPARQL itself.) When I have been referring to the "simplified wording" I was referring to that first issue. Since (barring told bnodes, which we have rejected) the two wording forms define exactly the same actual mathematics, equally precisely and unambiguously, the choice between them should be based purely on expositional clarity. Given that we now have the freedom to define the scoping graph bnode vocabulary to be disjoint from BGP without loss of generality, there is simply no motivation to use the more elaborate and obscure ordered-merge construction: it has become obsolete and unnecessary. Now, the more recent debate concerns the second issue. Here I agree that we should publish the fully general (E- plus B) definition *somewhere*, and give examples and so on. The only issue is, where. If the main SPARQL document is not going to use this elaborate machinery, I suggest that it should not be in that document, is all; particularly not as an intrusion in the first, basic, definitions in section 2. The appropriate strategy I suggest is to mention the more general framework in section 2, and refer to its full description elsewhere, perhaps later in the document, where it is stated exactly and where more space can be devoted to explaining it without intruding into the SPARQL definitions themselves. >[Enrico:] To sum up, your proposed "simplified wording" will leave >the issue rdfSemantics and owlDisjunction wide open No, it would leave it in exactly the same state as if we used the other wording, since they express the same actual formal content. I do not suggest leaving either of these issues open. Pat >, which is what FUB (and I guess Dan :-) would like to avoid. > >cheers >--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 Tuesday, 24 January 2006 17:19:56 UTC