Re: Final text for Basic Graph Patterns

>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. And if we have to have it, and all variables 
are SELECTed by definition, then omitting a variable from the 
ordering is a new kind of syntax error. Not clear this buys you 
anything.

>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.

Pat

>
>I don't know what's the more desirable default. (You could use a 
>filter isURI or something like K to recover distinguished variables).
>
>Cheers,
>Bijan.


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Thursday, 19 January 2006 20:15:47 UTC