Re: A neat, but impractical, solution

(I may not be following your thinking, and I think its because Im not 
sure of the exact meaning you are assuming for this 'distinguished' 
terminology. Definitions??)

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

?? If we dispense with the distinction between bnodes and variables, 
then there is only one category, lets call them variables. Now, if 
SELECT forces these variables to be distinguished, then they aren't 
bnodes, right? Because bnodes can't possibly be distinguished (can 
they?) So taking this together, there aren't any bnodes in a SELECT.

What am I not getting?

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

My understanding of this difference was basically that ASK doesn't 
(need to) return any answer bindings, which I thought was motivated 
largely to keep down internet traffic when asking simple questions 
against large KBs.

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

Maybe Im not following you (again), but what in SPARQL are you 
assuming is analogous to the head? Ive been assuming it was the query 
pattern. But this can contain bnodes.

>(the pure datalog sense) and they can, in RDF terms, be bound to 
>arbitrary entities.

To terms in the KB. Why does that make them non-distinguished?

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

Are we talking RDF or OWL? The general definitions let the scoping 
set be arbitrary, so this isn't in itself a restriction of any kind. 
(It becomes one when you specify the scoping set for a particular 
entailment regime, but Im not sure which one you have in mind here.)

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

Of course, but I would prefer to relax the requirement of 
non-redundancy (which is trickier than it seems, particularly if you 
want to be able to use told bnodes scoped between multiple queries. 
Then it is impossible to detect redundancy just by examining the 
answers themselves.)

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

I don't agree that they are helpful, and there are other ways to make 
the framework more homogenous (like, have OWL-DL-RDF querying include 
RDF querying.)

>  It is probable, as I already pointed out, that these reasons aren't 
>good enough.

I think the homogeneity point is well taken, but I draw different 
conclusions from it.

Pat



-- 
---------------------------------------------------------------------
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 Monday, 7 August 2006 18:52:13 UTC