Re: FW: Some more rq25 comments

Seaborne, Andy wrote:
>  
> 
> -----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

Done.

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

Done

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

Done

> 
> "...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."

Changed to:
[[
A label can be used in only a single basic graph pattern in any query; 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?

Good question - no - it's the query pattern.  The CONSTRUCT template (which is 
not a basic graph pattern) is independent of the labels in the query pattern

10.2.1 says
[[
The blank node labels are scoped to the template for each solution. If the 
same label occurs twice in a template, then there will be one blank node 
created for each query solution but there will be different blank nodes across 
triples generated by different query solutions.
]]

> 
> §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.
> ]]

The spec only covers simple entailment - we describe how to extend that but 
the spec is formally only covering simple entailment.  We provide some 
conditions for extension but not a complete definition.

In particular, with OWL disjunction, there is no model of implicit triples 
that works (no unique logical closure).

> 
> §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.

Agreed.  I think this is a relic of earlier times and the point, while true, 
modulo blank node labels, it is unhelpful.

@@ noted to be fixed.

> 
> §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.

Yuk - so they do.
@@ noted to be fixed.


> 
> §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".

It is not true in SPARQL by intent.  Proposition 2 requires the 
"well-designed" criterion which is not part of SPARQL.

"Find me a string to display for a person, choosing the FOAF information, 
othewise the VCARD information otherwise the rdfs:label.

SELECT
{
    ?x foaf:mbox <mailto:afs> .
    OPTIONAL { ?x foaf:name ?displayLabel }
    OPTIONAL { ?x vcard:FN ?displayLabel }
    OPTIONAL { ?x rdfs:label ?displayLabel }
}

SPARQL evaluation defines what this does.

LeftJoin is not commutative.  It isn't in SQL either.

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

Corrected the prefixes.

http://dublincore.org/documents/dces/

There is no such property dc:author.  It is dc:creator (which includes 
anything creating the work - like a machine).

> 
> 
> (And a few random forward references I hit while checking back and  
> forth....)
> 
> §12.6
> 
> s/D-entailement/D-entailment

Done

> 
> §A.8
> 
> "[2] Prolog ::== ..."
> s/Prolog/Prologue

Will do if (when) there is a grammar update.

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


	Thanks for the comments
	Andy

Received on Tuesday, 27 February 2007 11:19:19 UTC