- From: Dirk-Willem van Gulik <dirkx@webweaving.org>
- Date: Tue, 31 Aug 2004 06:38:36 -0700 (PDT)
- To: Kendall Clark <kendall@monkeyfist.com>
- cc: "Seaborne, Andy" <andy.seaborne@hp.com>, Alberto Reggiori <alberto@asemantics.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Tue, 31 Aug 2004, Kendall Clark wrote: > Third, it might not cost us, WG members, anything but it imposes a > cost on others. What cost ? We have no legacy at all - we have little deployed code out there; and just a few docs. > Not every triple store or query processor is backed by SQL, and few SW That is -not- what I mean (nor care too much about; as @semantics uses the Berkely DB by and large as a backing store). Right now -> virtually every langauge has for virtually every database backend a JDBC, ODBC, ADO, whatver interface over which you send SQL to the backend. -> On the language/client side assumptions about the meaning of ? - wired deep in the language; and because of the bad design of, say, ODBC, in myrad of client side code libraries (rather than on the server). -> A large body of SQL folks which we want to 'get' our language as soon as possible. We want to instantly levarage that infrastructure and capitalize on all those people. In the ideal world we should be able to use the semqeb query langauge everywhere where there is now sql over a *DBC used without having to change the clients, their IDE's, their toolchains or their setup. But just by just installing a Semweb query backend -and- a quick course in the language to the developers. I.e. swap out that dinosaur SQL database; plug in a SemWeb QL and you are ready for the future. Dw
Received on Tuesday, 31 August 2004 13:50:37 UTC