W3C home > Mailing lists > Public > www-rdf-rules@w3.org > January 2004

Re: !

From: Dan Brickley <danbri@w3.org>
Date: Thu, 8 Jan 2004 07:07:42 -0500
To: "Seaborne, Andy" <Andy_Seaborne@hplb.hpl.hp.com>
Cc: 'Patrick Stickler' <patrick.stickler@nokia.com>, ext Eric Prud'hommeaux <eric@w3.org>, Brian McBride <brian.mcbride@hp.com>, www-rdf-rules@w3.org
Message-ID: <20040108120742.GC19144@w3.org>

* Seaborne, Andy <Andy_Seaborne@hplb.hpl.hp.com> [2004-01-08 11:01-0000]
> -------- 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.

I very much agree. Even the read-only case is hard, when we start
dealing with massive result-sets, or thinking about representing bnodes
in anything other than a totally stateless interaction. (hmm I need to 
re-read draft, does it say anything re statefulness. time passes. seems

The one hook I think we need for layering on manipulate/update facilities
subsequently is access to a (potentially rich) service description; 
presumably in RDF/XML or WSDL or WSDL-in-RDF, ie. we want a way of
finding out whether some service _does_ have a write interface, even if 
we don't in first specs define classes of write/update/etc interface.

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

imho etc.,

Received on Thursday, 8 January 2004 07:07:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:46:17 UTC