- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Thu, 25 Jan 2007 01:57:44 +0100
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: public-rdf-dawg@w3.org
- Message-ID: <20070125005743.GL5137@w3.org>
* Seaborne, Andy <andy.seaborne@hp.com> [2007-01-24 20:15+0000] > > > 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. yeah, that. > > > > > >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? some conundrum where GP1 binds ?x if !bound(?y) and GP2 binds ?y if !bound(?x) i don't recall it exactly, but i want to make sure it's reflected back into the spec and if not here, there should at least be a forward ref here so folks know there are more details. > Is there some better wording you can suggest? nope. just flagging this as something i want to check on. > > > > > >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. ahh, if not the full-outer-join then i don't really get it and will defer to your judgement. > > > >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. ok, i hacked at the UNION text: Query results of GP1 <code>UNION</code> GP2 are all of the solutions from GP1 and the solutions from GP2, in any order. Still not ideal as it leaves the possibility that the results are either GP1a GP1b GP1c GP2a GP2b GP2c or GP2a GP2b GP2c GP1a GP1b GP1c vs GP2b GP2c GP1a GP1c GP2a GP1b but perhaps good enough as there is nothing saying that there is any order to the constituent results. > > > > > >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! yup. > > > >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. huh, lookit that. could add BASE <http://example.org/movie/> PREFIX book: <../book/> <book1> book:book1 to 4.1.1, i guess. > 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 -- -eric office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA cell: +1.857.222.5741 (eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.
Received on Thursday, 25 January 2007 00:58:27 UTC