- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Tue, 3 Oct 2006 16:11:21 +0200
- To: Bijan Parsia <bparsia@cs.man.ac.uk>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Mon, Oct 02, 2006 at 10:14:14AM +0100, Bijan Parsia wrote: > I think the status part should point to the issues list. > > """Costs: Tableau-based reasoners (at least, the Pellet Demo example > 7) rely on the current, more expressive semantics to match > implications that are not in a materializable RDF graph.""" > > No. Pellet uses BNodes as syntax for non-distinguished variables, as > that's what we were told was the likely syntax for non-distinguished > variables in SPARQL/DL. The semantics of *all* variables in SPARQL/ > RDF is semi-distinguished. But we need to explain to the community, in simple terms, why we non-distinguished variables. > I thought the alternative proposal (e.g., from conversation with > Jeen, Jorge and others) was to *drop* BNodes in triple patterns. That > does solve all the problems of scope, meaning etc., but it means that > certain combinations of the axes of distinguishedness will be harder > to specify (but heck, we can always introduce syntax later). The majority of the deployed SPARQL and RDQL implementations follow the subgraph semantics of [LC1] so I am trying to explain why we have a different semantics. This includes why we were motivated to use the E-entailment semantics of [LC2] and test cases [DIF] to show how they might differ. Not having BNodes at all seems like a last resort, if we discover that a large fraction of the community is specifically dis-served by us keeping them in. [LC1] http://www.w3.org/TR/2005/WD-rdf-sparql-query-20050721/#BasicGraphPatternMatching [LC2] http://www.w3.org/TR/2006/WD-rdf-sparql-query-20060220/#BasicGraphPatternMatching [DIF] http://www.w3.org/mid/20060919134330.GC30275@w3.org -- -eric home-office: +1.617.395.1213 (usually 900-2300 CET) +33.1.45.35.62.14 cell: +33.6.73.84.87.26 (eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.
Received on Tuesday, 3 October 2006 14:10:22 UTC