- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Fri, 20 Jan 2006 01:25:50 -0500
- To: Pat Hayes <phayes@ihmc.us>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Jan 19, 2006, at 3:15 PM, Pat Hayes wrote: >> On Jan 19, 2006, at 9:10 AM, Bijan Parsia wrote: >> [snip] >>> (To see this compare: >>> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> >>> PREFIX ns: <http://www.mindswap.org/ontologies/oedipus#> >>> >>> SELECT ?x >>> FROM <http://www.mindswap.org/ontologies/oedipus> >>> WHERE { ?x ns:hasChild ?y . >>> ?y rdf:type ns:Patricide . >>> ?y ns:hasChild ?z . >>> ?z rdf:type ns:NotPatricide } >>> >>> and the same query where ?Y is in the select clause. Frankly, what I >>> *like* about this error is that it's easy to explore >>> (non)distinguishedness without having to go through the GP replacing >>> variables right and left. Oh well.) >> >> Thinking about this a bit more, is there any reason *other* than >> performance, given bnodes in bindings, to have distinguished >> variables? > > IMO, no. But we would still need something in the language to indicate > the ordering of the bindings in the answer set, even if we didn't call > it SELECT. Er...my current understanding is that the SELECT isn't for ordering per se, but for indicating which bindings get reported back. > And if we have to have it, and all variables are SELECTed by > definition, Sergio pointed out that SELECT doesn't necessarily indicate distinguishedness. That is, on some folks understanding, *ALL* query variables are distinguished all the time, but only sometimes projected (which is what the listing of vars in the SELECT clause means on this reading). > then omitting a variable from the ordering is a new kind of syntax > error. Not clear this buys you anything. I'm not getting that. >> I.e., why not have this query give the same number of answers >> regardless of whether you are using ?y or _:y? And allow projection >> of the bnode. > > If we say that bindings must be to terms in some restricted set, and > don't allow that set to have too many bnodeIDs in it, then ?x might > fail to have a binding when _:x was true, according to Sergio. This is > the argument that he used against the proposal to treat pattern bnodes > as blank variables. My favorite reply is to say there are always > enough bnodeIDs, but admittedly it is tricky to say that precisely > without also incurring the risk of allowing silly bnode redundancy > into the answer set. > > FWIW, I think this bnode/variable issue isn't worth tinkering with at > this stage. Its irrelevant up through RDFS, and OWL-A isn't going to > allow any bnode bindings, so the cases that would matter aren't going > to come up at all in this round. I don't know what to say here :) I'm fine not tinkering, though. Cheers, Bijan.
Received on Friday, 20 January 2006 06:25:55 UTC