Re: review of rq23 1.377

Section 3, 4, 5, 6
cc: www-archive removed.  This list is archived.

Comments accepted unless noted below:

See CVS log for things accepted that aren't purely editorial.

 Andy

Kendall Clark wrote:
> Andy & Eric,
> 
> I'm attaching my review of 1.377 of rq23. It's an annotated copy of the spec
> itself. That seemed a bit easier for me and, hopefully, for you guys to
> process. I'm hoping that the W3 list archiver turns HTML attachments into
> links.
> 
> Anyway, I'm happy to discuss any of the comments in the review. FYI, I
> stopped the review around section 11.1. I made nearly 300 <strike> or <ins>
> annotations, and then I got really tired of doing that. :>
> 
> All in all, good show on the spec!
> 
> Kendall Clark
> 
> 
> ------------------------------------------------------------------------
...

>     3 Working with RDF Literals
. . .
> 
>     *
> 
>       Open: whether to allow "foo"@?v or ?v@fr or ?v^^xsd:integer or
>       "foo"^^?v
>       One way to address this is to allow expressions in SELECT
> 
>       [Is this still an open issue?]

Removed.  To getthis in, someone wants to argue for this quite strongly (e.g. a 
use case or signficiance that can not be solved otherwise).  Noet that the 
required information can be passed back wven if not broken down into the literal 
components.

>     4 Graph Patterns

>     5 Including Optional Values
> 
> Basic graph patterns allow applications to make queries where the whole 
> of theentire query pattern must match for there to be a solution. For 
> every solution of the query, every variable is bound to an RDF Term in a 
> pattern solution. But RDF is semi-structured: so a regular, complete 
> structure can notcannot be assumed. and iIt is useful to be able to have 
> queries that allow information to be added to the solution where the 
> information is available, but not to have the solution rejected just 
> because that part [Which part? Strike "that"?]

"some part"

 > of the query pattern does
> not match. Optional matching provides this facility; if the optional 
> part does not lead to any solutions, variables can be left unbound.
> 
> 
>       5.1 Optional Pattern Matching
. . .
> This query finds the names of people in the data., and, iIf there is a 
> triple with predicate |mbox| and same subject, it retrieves ["binds" or 
> "matches" better than "retrieves" here?] the object of that triple as 
> well.

"a solution will contain"

> In the example, only a single triple pattern is given in the 
> optional match part of the query but, in general, it is any graph 
> pattern. The whole graph pattern of an optional graph pattern must match 
> for the optional graph pattern to add to the query solution.
> 
> 


>       5.4 Optional Matching: – Formal Definition

Something went wrong with your version (charset problems?)

> In an optional match, either an additional graph pattern matches a graph 
> and so defines one or more pattern solutions,  or gives an empty pattern 
> solution but does not cause matching to fail overall, leaving existing 
> solutions in the query results.In an optional match, either an 
> additional graph pattern matches a graph, thereby defining one or more 
> pattern solutions; or it gives an empty pattern solution, leaving 
> existing solutions in the query results, but does not thereby cause 
> matching to fail overall.
> 
> *Definition:* Optional Graph Pattern
> 
> An optional graph pattern is a graph pattern that can create new 
> solutions, but will always match.

"""
In an optional match, either an additional graph pattern matches a graph, 
thereby defining one or more pattern solutions; or it passes any solutions 
without adding any additional bindings.
"""
> 
> Given graph pattern P, the optional graph pattern Opt(P) matches with 
> solution S if S is a solution for a match of GP, or S is not a solution 
> for P.
> 
. . .
> 
> 
>       5.5 Nested Optional Graph Patterns
> 
. . .


> By nesting the optional access [I don't understand this use of 
> "access".] to |vcard:Family,|

"By nesting the optional pattern involving vcard:Family,"

> the query only reaches these if there is a 
> |vcard:N| predicate. It is possible to expand out optional graph 
> patterns to remove nesting at the cost of duplication of expressions. [I 
> don't understand the point of this sentence here; is it implementation 
> advice? Or is it a suggestion for how a user might write equivalent 
> queries without nesting?]

Removed.

 > Here, the expression is a simple triple
> pattern on |vcard:N| but it could be a complex graph pattern with value 
> constraints.
> 
> 
>     6 Matching Alternatives
. . .

>     7 RDF Dataset

Received on Monday, 13 June 2005 10:12:16 UTC