- From: Pat Hayes <phayes@ihmc.us>
- Date: Mon, 23 Jan 2006 15:49:14 -0600
- To: Enrico Franconi <franconi@inf.unibz.it>
- Cc: "Seaborne, Andy" <andy.seaborne@hp.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
>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