RE: !

-------- Original Message --------
> From: Patrick Stickler <mailto:patrick.stickler@nokia.com>
> Date: 8 January 2004 07:49
> 
> 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.

I agree - the WG should restrict itself to read access to remote RDF
repositories.  The manipulate/update case is much more complex and brings in
issues of concurrency, transactionality, and event notification (the latter
is why I would avoid the push/pull terms here).  Experience in this area is
more isolated than query access.

> 
> 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 agree.  Results should be in RDF/XML - I would hope this would come out in
the requirments stage so I would not mandate it as the only format but it
should be the default one.  Also, the subgraph extraction mode may be more
significant than in the local case because of this compositionality:
extrcting the graph for further local fine-grained processing and access.

> 
> 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

Received on Thursday, 8 January 2004 06:06:30 UTC