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

Re: Editorial thread for BGP matching

From: Enrico Franconi <franconi@inf.unibz.it>
Date: Tue, 24 Jan 2006 00:02:48 +0100
Message-Id: <25D83C24-75F5-48F2-AECC-8BC4255297C8@inf.unibz.it>
Cc: "Seaborne, Andy" <andy.seaborne@hp.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
To: Pat Hayes <phayes@ihmc.us>

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.

Received on Monday, 23 January 2006 23:03:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:50 UTC