Re: REX evaluation

On Wed, Jun 09, 2004 at 02:25:15PM -0700, Rob Shearer wrote:

> This is because "provenance" isn't well-defined for me. 

Yes; as I said, it's very overloaded. But, contra what you say below,
there are lots of core use cases where *who* made assertion A is as
important as the content of assertion A. When they made it and in what
context -- say, in which web resource identified by a URI -- are
equally crucial. Many of our use cases involving the Intelligence
Community are *very* provenance-centric apps.

I don't know how or whether to really build support for this use case
into the design of the query language and/or protocol; I do know,
however, that this is a *common* use case (consider, for example,
writing an RDF spider where the original source of the assertion is
vital...)

> I see an RDF
> repository as an RDF repository; I thought the whole point of RDF was
> that it made absolutely no difference who said something or where that
> information was stored so long as somebody said it somewhere,

Hmm, no, with all due respect, Rob, I think that's wrong. :>

> XQuery FLWOR statements have extremely robust capabilities for
> formatting results. Effectively, the result is a sequence, each element
> of which is the result of evaluation of an XQuery expression with a set
> of variables bound to a particular set of values.
> In the absolute simplest case, you can write any XML expression (known
> in XQuery as a "direct constructor"), and then plug in variable names
> somewhere in the XML which will be substituted for that variable's
> binding.

But doesn't this require the client to know the details of a
particular serialization, such that it can construct a query template
(a "direct constructor") of the proper form? That's not what I had in
mind when I proposed this. If I'm being honest, I'm a bit obsessed --
especially since I'm not the Nokia employee -- with the tiny client
deployment scenario, in which it's far more realistic to be able to
say:

SELECT...WHERE...AND...AS http://trix-serialization-uri

than expecting every client, including small devices, to know the
details of various formats.

I think this could be a case where our experiences with the technology
don't overlap very much. Which is one reason I'm not pushing 4.4 as a
critical path requirement.

> This requirement has always confused me, because it doesn't strike me as
> something that a query language dictates. 

Well, the folks who designed iTQL disagree, as do other query language
designers which let you do source selection in the language. I think
source selection in the language together with Bryan Thompson's
server-side XPointer is an *uber-powerful* combo. That being said, I
don't think it should be critical path. But I do think it's an
objective we should seriously consider.

> It would be perfectly sensible
> to write a REX implementation which collected data from multiple sources
> in order to answer a query, but that's the implementation doing that,
> not the query language.

Fine; but the debate, at least in my view, is about whether the query
language *should* do that. REX doesn't. No biggie, but that seems to
be the facts on the ground. Hell, Rob, we have to find *something* REX
doesn't do to prevent you from suggesting that we just adopt it and
declare victory. Where's the fun in that?! :>

Best,
Kendall Clark

Received on Wednesday, 9 June 2004 21:26:35 UTC