Re: !

> [On XQuery...]
>
>> > 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.
>
> Yes, I believe the jury is still out on this. We just don't know
> to what extent XQuery (the language) and XQuery tools can be usefully
> applied to RDF data. There are reasons for optimism: XQuery can be
> understood as a general programming language, albeit one which
> privileges  XML-oriented concepts); tools such as TreeHugger show
> certain amount  of tech sharing is possible; many XQuery systems are
> back-ending to  SQL data stores, and could perhaps do likewise with RDF
> stores. But  there are reasons for pessimism too: XQuery is a huge
> spec; it
> is fundamentally concerned with a data model alien to RDF's; it is
> "joined at the hip" with XML Schema; and even though basic RDF triples
> can be queried with XQuery, it is far from clear that XQuery engines
> will be able to optimise their query strategy based on info from RDFS
> and OWL, which raises a big concern about scalability and tool re-use.
>
> To my mind, the issue is not so much a technical or engineering issue
> as a social one. And one that we shouldn't dismiss as "politics". It's
> more like civility, I think --- a lot of smart, hardworking folks in
> the  Web/XML community have worked for a long time on XQuery. And a lot
> of  people invest in W3C standards because there is a valuable level of
>  cross-cutting architectural coherence between our specs, and a concern
> to  avoid re-inventing rather than re-using wheels. Given that XQuery
> exists, is getting a certain amount of traction, I believe we owe it
> to those folks to take a good look at what they've produced, and at
> what  they've learned. If at the end of the day we decide it doesn't
> meet  RDF querying use cases and fit with the SW technology stack
> (incl.  RDFS/OWL, future work on rules, etc.), that should be an
> informed  decision based on a study of what the XQuery effort produced,
> and (perhaps  more importantly) a dialog with the folks who produced
> it.

I would like to add another argument to Dan's comments. It is clear, as
everybody that has seen query systems around the world, in different
fields, that there is a lot of common ground in the query word.
In our case, there is some preliminary evidence that this common
ground between XQuery and a possible-RDFquery-whatever-will-be-designed
could be significative.
Now the real question to ask is: how large is this overlap? Can we
profitably fill the gap with reasonable effort, or this is not worth?
Filling the gap with reasonable effort would be of course a plus
for everbody, as it would:
+ get closer the so-far rather distinct communities of XML and Semantic Web
+ get the SW an increased momentum by this bridge
+ get users with a more integrated sets of Web solutions, narrowing
the number of languages one has to use
+ promote delopyment and interoperability
+ give reasonable comfort that W3C technologies are proceeding as far as
possible united, and that there is overall technological consistency

Now, this doesn't mean at all the gap can be filled with a reasonable
effort. In order to answer this question, one has to do some serious
thinking. There has been some people already starting to think about
this; I myself, right now, don't have a clear answer to that, and have
given three (!) Master Theses projects just to better study the various
approaches on how this integration could work out well, as I feel
that without serious trying, I won't be able to give a definitive
answer to this question.
So, to know the answer, we need to carefully have a look at the problem.
Avoiding the problem altogether (XQuery is complex, who cares,
native solutions are easier) is tempting, but still doesn't
give an answer to the question: can we fill the gap in a reasonable way,
where the cost/benefit is well worth and superior to other solutions?

Now, the ways to get to the answer can be various, and the precise
charter wording can be discussed and modeled, but the bottom-line is
that, eventually, there must be a clear (grounded) answer to this.
Lacking, any RDF-query spec will have to face this critique at last
call. And with no reasonable answer, I think this will likely be
a problematic showstopper.

-M

Received on Thursday, 8 January 2004 12:12:13 UTC