Re: issues in rq25

Eric Prud'hommeaux wrote:
> I am happy to be working with Andy's new draft, rq25. I've done an
> editing pass through the end of chapter 7. I have put my
> characteristic pink issue hilighter on a few points which I am
> describing here.
> 
> 
> 4.1.4 Syntax for Blank Nodes
> 
>   Blank nodes in query patterns act as *existential* variables.
> 
> I thought they acted as regular variables, i.e. one gets solutions for
> each way the bnode could match a different term in the graph.
> [TST] (below) tests this.
> 
>   The scope of the label is the basic graph pattern; if the same label
>   is used in another basic graph pattern graph pattern, it is not the
>   same blank node.
> 
> Is there really (still? again?) no correlation in the _:who variables
> in this query?
> 
> Data:
>   [ foaf:nick "ericP";
>     foaf:mboxMD5 "A2BA23432B434443D45DF655A6C6E6E" ].
>   [ foaf:name "Bob Smith";
>     foaf:mbox <mailto:bob@example.com> ].
> 
> Query:
>   SELECT ?nick ?mbox
>    WHERE { ?who foaf:mboxMD5 "A2BA23432B434443D45DF655A6C6E6E";
> 		foaf:nick ?nick
> 	   OPTIONAL { ?who foaf:mbox ?mbox } }
> 
> Results:
>   ?name  ?mbox
>   ericP  <mailto:bob@example.com>

Eric covered the telecon discussion in
http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0043.html

where the two ?who are both _:who.

> 
> 
> 5.1 Group Graph Pattern
> 
>   For any solution, the same variable is given the same value
>   everywhere in the set of graph patterns making up the group graph
>   pattern.
> 
> We had a WG decision on this and I want to make sure the spec lines up
> with that.

I'm sorry - I'm not sure what the comment is.
Which WG decision are you referring to?

Is there some better wording you can suggest?

> 
> 
> 5.3 Order of Evaluation
> 
>   There is no implied order of graph patterns within a Group Graph
>   Pattern
> 
> This is the full-outer-join issue. How did this get resolved?

It's not the full-outer-join issue really.  It's become wrong because the text 
refers to syntax form and is no longer correct - a group is not just a bunch 
of inner joins.  Needs to be changed - remove the section seems to be the 
obvious way as it says nothing now.

> 
> 
> 7 Matching Alternatives
> 
>   Query results involving a pattern containing GP1 and GP2 will
>   include separate solutions for each match where GP1 and GP2 give
>   rise to *different* sets of bindings.
> 
> We talked about this some, too. Can't remember where we got. I prefer
> to not have an implicit DISTINCT on UNION (something the SQL folks
> regret).


See the algebra:
http://www.w3.org/2001/sw/DataAccess/rq23/rq25-algebra.html#defn_algUnion

The cardinality in union is the sum of left and right cardinalities.

> 
> 
> I have some notes to add examples:
>   empty graph patterns:
>     WHERE { OPTIONAL { <mumble> <foo> ?bar } }
>   FILTERs outside of the binding OPTIONAL:
>     OPTIONAL { <mumble> <foo> ?bar } FILTER (!BOUND(?bar) || ?bar < 5) }

That's an offer to add them?  Great!

> 
> I'd like to clarify whether qname expansion occurs *before* relative
> IRI resolution. Does
>   BASE <http://example.org/services/SPARQL>
>   PREFIX foo: <../namespaces/foo#>
>   ... WERE { ... foo:barw ... }
> mean
>   <http://example.org/namespaces/foo#bar>
> ?
> 

Strictly, <../namespaces/foo#> is just syntax for a absolute URI using a base.

foo: is bound to a URI, all URIs have the resolution rules applied so it is 
the first case below.


When does it matter?

case 1:
Expand foo: when encountered => <http://example.org/namespaces/foo#>
foo:bar => <http://example.org/namespaces/foo#bar>

case 2:
Keep foo as is, <../namespaces/foo#>
foo:bar ==> <../namespaces/foo#bar>
which is resolved to
<http://example.org/namespaces/foo#bar>

so I get the same output.

I can't think of way of turning <xxx/.> into <xxx/../yyy> because the local 
part of a prefixed name must start with a letter so .. can't be split.

> 
> I'm not convinced that 4.1.4 Syntax for Blank Nodes needs to go into
> such detail on the [ :p :o ] syntax, which is later described in
> 4.2.1. It's tough, you kinda need to teach these things in parallel,
> and it's tedious to teach them non-exhaustively and later define them
> exhaustively. I don't have any better ideas.

Does seem to be a bit of duplication but I don't see how to break the cycle 
either.  Putting ";" first is the wrong order for other reasons.

	Andy

> 
> 
> Tx a zillion for all the fab work, AndyS!
> 
> 
> [TST] http://www.w3.org/2001/sw/DataAccess/tests/#rdfsemantics-bnode-type-var

Received on Wednesday, 24 January 2007 20:15:21 UTC