- From: Pat Hayes <phayes@ihmc.us>
- Date: Mon, 7 Aug 2006 11:51:58 -0700
- To: Bijan Parsia <bparsia@cs.man.ac.uk>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
(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