- From: Enrico Franconi <franconi@inf.unibz.it>
- Date: Tue, 24 Jan 2006 00:02:48 +0100
- To: Pat Hayes <phayes@ihmc.us>
- Cc: "Seaborne, Andy" <andy.seaborne@hp.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
On 23 Jan 2006, at 22:49, Pat Hayes wrote: >> 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. 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'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. 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. 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. To sum up, your proposed "simplified wording" will leave the issue rdfSemantics and owlDisjunction wide open, which is what FUB (and I guess Dan :-) would like to avoid. cheers --e.
Received on Monday, 23 January 2006 23:03:00 UTC