Re: A neat, but impractical, solution

On Aug 7, 2006, at 5:40 AM, Pat Hayes wrote:

>> It occurs to me that one way to manage the distinguished/ 
>> semidistinguished/nondistinguished mechanism a bit more neatly  
>> would be to dispense with the distinction between BNodes and query  
>> variables (except for spelling and syntactic restrictions on  
>> placements) in queries, and force the range of the variables to  
>> depend on the query form. That is, SELECT forces distinguished  
>> variables, and ASK the rest.
>
> So there are no bnodes in SELECT patterns, if I follow you (?) That  
> seems like a big handicap.

You could have them or not. You could let them be nondistinguished or  
not. This is the not neat part. Either you let them be distinguished,  
which is a bit weird, or you no longer have the nice divide betwen  
ASK and SELECT.

>>  We could then allow variables to be listed in the "head" of the  
>> ASK clause (as in the SELECT clause), so that the distinction  
>> between semi and nondistinguished variables is merely projection/ 
>> listing in the head.
>
> This sounds very like one of the options we used in DQL, where an  
> ASK was basically a SELECT with nothing selected.

I don't see how that relates, exactly.

>> You could list BNodes in the head just like other query variables,  
>> or dispense with them altogether, or allow them to have their  
>> present form, to wit, being dedicately non-distinguished.
>
> Actually I don't think that is their current role in SPARQL, if I  
> understand what you mean by non-distinguished.

Hmm, I thought that they are non-distinguished. They can never appear  
in the head of the query (the pure datalog sense) and they can, in  
RDF terms, be bound to arbitrary entities. Hmm. The reason we treat  
them as non-distinguished in Pellet is because I remember Enrico  
telling me that they were :) Can I derived this from the framework?

Ah yes, I can. The bit is that only query variables are restricted by  
the scoping set. So, I do think no matter how you see  
nondistinguished variables, that they are always nondistinguished.

>> Unfortunately, while rather neat, it's not very practical, as  
>> people are used to using SELECT as their query form (a la SQL)  
>> and, especially in the RDF case, likely to want semi-distinguished  
>> variables by default.
>
> Right. I would strongly oppose restricting variable bindings in RDF  
> SPARQL: there is no computational need to do so,

Well, there are issues for when you want to supply non-redundant  
answers, as I've pointed out before. Also, I think there are  
questions about how to interpret results when you *aren't* non- 
redundant.

OTOH, I'm not talking about *always* restricting the bindings, just  
in the SELECT form. I think it's semantically a bit more natural to  
make the SELECT a bit more restricted (i.e., to me, it seems like  
SELECT is weaker than ASK), I did point out that it's probably not a  
great idea for the RDF case just on what people "want" to use. Of  
course, we could make the ASK more restricted, or come up with a new  
name altogether.

> and it would make the answers incomplete for no good reason.

Well, there is a couple of good reasons, since I think that such  
restrictions can be helpful and it would make the framework more  
homogeneous. It is probable, as I already pointed out, that these  
reasons aren't good enough.

Received on Monday, 7 August 2006 07:07:15 UTC