- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Wed, 24 Jan 2007 20:15:08 +0000
- To: Eric Prud'hommeaux <eric@w3.org>
- Cc: public-rdf-dawg@w3.org
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