Re: bnodes as answer bindings

>It turns out that DQL in fact has the standard 
>distinguished/non-distinguished variable distinction (though it 
>doesn't call it that must-/may-bind vs. don't-bind, where "may" bind 
>are a kind of optional thingy), does not allow for 
>semi-distinguished variables, and requires non-redundancy.
>
>From <http://www.daml.org/2003/04/dql/dql>:
>
>"""   An answer pattern instance that is the answer pattern with 
>each of the must-bind variables and zero or more of the may-bind 
>variables (and none of any other variables that occur in the answer 
>pattern) replaced by a URIref or literal."""
>
>That's the restriction to the active domain.

If by 'domain' you mean the universe of an interpretation, no it 
isn't. This is a purely syntactic restriction, not a semantic one. 
But OK, perhaps "domain" in this context isn't intended to have a 
model-theoretic interpretation, which prompted my earlier reaction.

>Since the values of a don't-bind variable aren't part of the answer 
>pattern instance, they are not part of the answer.
>
>"""5.      Suppose Q is the query pattern for the query of which 
>this is an answer, and B is the subset of the binding set consisting 
>of all the bindings to variables in Q.  We write B(Q) to refer to 
>the KB obtained by applying the bindings B to Q, i.e., by 
>substituting the URIref or literal that is associated with v for 
>every variable v that has a binding in B.  B(Q) may contain some 
>variables from Q that are not replaced by B; we refer to these 
>variables as remaining variables."""
>
>*Remaining*! But, they are *just variables*!

They are 'remaining' because they remain in the instance after the 
binding instantiations are applied. This isn't a different type of 
variable, only a way to refer to a subset of the variables in the 
pattern.
...

>"""The answer set of a query is the largest set of query answers 
>that are entailed by the answer KB such that no answer in the set is 
>entailed by any other answer in the set."""
>
>Non-redundancy.

Indeed, and one of the reasons why I think we should be relaxed about 
redundancy is exactly because this aspect of DQL was a major 
implementation hurdle that was immediately noted by critics. In other 
words, IMO we got this wrong in DQL, for exactly the reasons (elegant 
solution, wanting the set to be unique) that I think are now being 
used to justify making the same mistake in SPARQL. Which is why I am 
stubbornly resisting on this point.

>Pat  Hayes is listed as an editor, but, of course, it shouldn't be 
>construed that he endorsed these distinctions and approaches, or 
>that he wordsmithed these passages.

The final wordsmithing was done mostly by Richard, although we all 
had a hand in it and signed off on it.

No more from me about DQL, which is now of only historical interest anyway.

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 19:22:43 UTC