FW: Some more rq25 comments

 

-----Original Message-----
From: Simon Raboczi [mailto:raboczi@itee.uq.edu.au] 
Sent: 26 February 2007 12:09
To: Seaborne, Andy
Cc: Eric Prud'hommeaux
Subject: Some more rq25 comments

A little bit more as I work though rq25.
As before, I'm pretty sure I need someone else to repost this to the list on my behalf.

Comments on rq25 rev 1.20 §5-7
http://www.w3.org/2001/sw/DataAccess/rq23/rq25.html

§5.1

"Basic graph patterns are sequences of triple patterns."
s/sequences/sets

"SPARQL pattern matching is defined in terms matching..."
s/terms matching/terms of matching

§5.1.1

"When using blank nodes of the form _:abc, Labels..."
s/Labels/labels

"...reuse of a label across basic graph patterns is an syntax error."
s/an/a
Perhaps it would be a little bit clearer as follows:
"Reuse of a label in another basic graph pattern within the same query is a syntax error."

Does "in the same query" include the graph template of the CONSTRUCT clause?

§5.1.2

"SPARQL is defined for matching RDF graphs with simple entailment."

I'm a little bit surprised to find that we commit to a particular E- entailment, given that being able to accommodate query processors of  
varying inferential power ought to be one of SPARQL's key features.   
Perhaps a less partisan alternative:
[[
SPARQL may be used to query RDF graphs which contain implicit (E-
entailed) triples in addition to explicit (ground) triples.  The query processor determines the entailment regime used to interpret any particular RDF graph, which in turn influences the matches it obtains for basic graph patterns.

Throughout this document and in its companion test cases [LINK], examples are processed using simple entailment.  Section 12.6 [LINK] discusses entailment regimes other than simple entailment.
]]

§5.2

"The same solutions would be obtained from a query that grouped the triple patterns into two separate basic graph patterns as below even though the structure of the query is different:"

This text gives the impression that it is necessarily the case that  
GGPs are equivalent to the catenation of their component BGPs.   
Reused bnode labels (§5.1.1) break this syntactically, and non-simple entailment breaks this semantically.  GGPs should be defined intensionally as conjunction, rather than as having the same extension as the combined BGP.

§5.5

"A constraint, expressed by the syntax keyword FILTER, is a restriction on solution over the while group..."
s/while/whole

OPTIONAL clauses appear in examples before being introduced in the following section.

§6.3

Ought to point out that the order of OPTIONAL clauses doesn't matter:  
{A OPTIONAL {B} OPTIONAL {C}} = {A OPTIONAL {C} OPTIONAL {B}} would follow from Proposition 2 in the ISWC'06 "Semantics and Complexity of SPARQL".

§7

In the third example the PREFIX declarations are backwards.  Also, s/ dc10:creator/dc10:author


(And a few random forward references I hit while checking back and  
forth....)

§12.6

s/D-entailement/D-entailment

§A.8

"[2] Prolog ::== ..."
s/Prolog/Prologue

"[3] WhereClause  ::= 'WHERE'? ..."
Is the WHERE keyword really intended to be optional here?

Received on Monday, 26 February 2007 12:30:47 UTC