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: Sat, 21 Jan 2006 15:35:28 +0100
Message-Id: <2889B1FE-B2ED-4786-8E92-BA69A0EF8277@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 20 Jan 2006, at 20:26, Pat Hayes wrote:
> If its any consolation to anyone, I'm now the one who is feeling  
> overwhelmed.

Our version is basically stable since three months :-)

> PS. I agree with the separate document idea for the non-SPARQL  
> stuff. We could also discuss things like told-bnodes in there as  
> SPARQL variations.

This makes sense.

> but I'll do you a version with the simplified definitions before  
> Tuesday, for comparison.
> But then the SPARQL definitions should not even mention the scoping  
> set B: all we need is the scoping graph being a bnode variant of G  
> which should be standardized apart from all the BGPs and which  
> defines the scope of the answer set.

I can't believe that now you are still changing your mind from your  
proposal of two days ago!

As I already noticed several times, I don't see how this could be  
smoothly extended to languages with implicit existentials: I like the  
scoping set B.

If we go with a separate document, we have to have the normative  
definitions applied only to simple entailment, but containing *all*  
the ingredients to be parametrised - BTW this is the current version  
by Andy which I like a lot. In the non normative part we should show  
how the various normative parameters can be utilised to capture  
different extensions (told-bnodes, rdf/rdfs entailment, owl-dl (data)  
entailment, etc).

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. Note that in a sense already the LC design (fixed in minor  
parts) would be a correct and simple normative definition of BGP  
matching: of course, there would be not even a mention of entailment.

Received on Saturday, 21 January 2006 14:35:38 UTC

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