!

On Jan 07, 2004, at 19:33, ext Eric Prud'hommeaux wrote:

> Perhaps a paragraph in the scope section espousing the virtues of
> modularity will do. As a challenge to this, I see provenance issues
> poking into all three modules:
>
>   query language: subgraph selection
>     - expressivity
>       - provenance identification ?
>       - individual statement identification ?
>     - syntax
>
>   result encoding: reporting the subgraph
>     - sets of bindings &&|| statements
>     - provenance identification ?
>     - individual statement identification ?
>
>   protocol: manipulate stores,

I'm happy with Eric's outline except for this. I think that the WG
should restrict it self to pull only, and leave push operations
and the whole collaborative/distributed knowledge management problem
out of scope.

What is acutely required at the moment, IMMHO, is a standardized
means of requesting/accessing knowledge, irrespective of how that
knowledge is organized and managed, and manipulation of stores
opens a pandoras box of issues that will slow the WG down and
prohibit a fast, max-one-year schedule.

KM extensions can be addressed in a second round by the WG, if
so decided, once the core QL and pull protocol(s) are in place.

> convey queries and results
>     - provenance identification ?
>     - individual statement identification ?

I would like to see in the charter some indication that the
conveyance of results, whether subgraph and/or bindings, be
in RDF/XML -- i.e. that we eat our own dog food, and also,
having the results as RDF/XML minimizes the infrastructure
required to process results (parsers, APIs, etc.) and allows
query execution to be pipelined, with the results of one
query serving as the kb for subsequent queries, etc.

I also strongly support an approach such as ResultsSet for
capturing binding information in RDF, providing for the
submitting agent to specify subgraph, bindings, or even both
to be included in the returned RDF/XML.

>> I am concerned that requiring the WG to produce a translation for RDF 
>> data
>> access query language abstract syntax to XML Query may requiring the 
>> WG to
>> take on a task that is not essential to its principal task and may 
>> thus slow
>> down its completion of that task.
>
> Earlier criticisms of this requirement were that it was a not
> necessarily possible task. In response to this, I added TreeHugger [1]
> and XQueryFA [2] to the query survey. You, however, call into question
> whether it is essential.
>
> W3C membership has invested on the order of 100 man years in the
> XQuery specification, and more than that on implementation. There is a
> rift between the RDF community and the XML community stemming from not
> only different data models, but a clash of attitudes.
>
> Practically, we can give the XQuery user access to RDF data in the
> same manner that they have access to relational data via XQuery-SQL
> mappings. This opens up RDF to a much larger set of clients and
> reduces the "RDF or XML" question.
>
> One could argue that the XQuery working group should do this work
> instead, but I think that the somewhat separatist RDF community will
> have to do the work because the DAWG starts after XQuery finishes (and
> the gesture would probably be welcome).

One concern that I have is the extent to which one might have to
think "differently" when composing RDF queries using XQuery. I've
not played around with XQueryFA yet, but when looking at TreeHugger,
I kept having an underlying feeling that it was forcing me to
think differently than in terms of the "pure" RDF abstract model.
Maybe that's not such a big deal, and maybe the win for having
compatability with XQuery is worth it, but I also am uncomfortable
with the way the draft charter suggests (to me at least) that an
XQuery mapping is a requirement, rather than just a desirable end
that has yet to be justified as either required or even optimal.

There's also the feeling that, even though XQuery might be made
to work for alot of RDF expressed knowledge, there are numerous
issues that will preclude the use of generic XQuery or XPath
tools (and hence substantially undermine the utility of an XQuery
mapping to arbitrary RDF knowledge stores) such as RDF datatyping,
(future) support for named graphs, contexts, etc. and we should be
very cautious that we don't box ourselves in too severely.

For the sake of not having too many tools in the toolbox, an XQuery
binding is seductive, but my gut feeling is that in the long run
it will turn out to be both more complex and more limiting than
a "native" RDF-tailored solution.

I myself would prefer to see a "native" RDF Query solution produced
by this WG, along with some form of XQuery-RDF binding (produced by
another WG, or by interested parties as a W3C Note, or during some
later iteration of the WG, for whatever utility it may offer).
I expect that the XQuery-SQL binding covers only a subset of what can
be done with SQL over arbitrary relational databases, yet still offers
utility, even though RDBMS folks will probably opt for more "native"
solutions most of the time (SQL folks, correct me if I'm wrong here).
I see no reason why RDF shouldn't have an optimally tuned native
solution, even if other mappings/bindings exist to promote broader
interchange and collaboration with other communities.

Cheers,

Patrick


--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Thursday, 8 January 2004 02:48:47 UTC