Re: Final text for Basic Graph Patterns

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