- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Wed, 9 Jun 2004 21:24:38 -0400
- To: Rob Shearer <Rob.Shearer@networkinference.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
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