W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2004

Re: ACTION: elaborate on 4.4

From: Kendall Clark <kendall@monkeyfist.com>
Date: Thu, 24 Jun 2004 13:21:57 -0500
Message-ID: <20040624132157.B26327@monkeyfist.com>
To: Rob Shearer <Rob.Shearer@networkinference.com>, Jim Hendler <hendler@cs.umd.edu>, RDF Data Access Working Group <public-rdf-dawg@w3.org>

On Thu, Jun 24, 2004 at 11:01:36AM -0700, Rob Shearer muttered something about:

> If the WG wishes to define a network protocol, then I guess that's fine.

We are *chartered* to do such a thing; by a reasonable reading of our
charter, we *have* to do such a thing. I read it as positive a obligation.

> But we should be under no delusions that everybody will actually want to
> use it, and I do think it's quite silly to bind the process of defining
> a query language to that independent process.

Two things:

1. Where is your "we can't impose this on others" reticence when it comes to
the query language? You seem to have no qualms about telling *existing*
communities that their query languages should be thrown away in favor of
*ours*; and, oh, by the way, we don't support features A, B, and C that you
really care about.

2. This is in reality a very silly debate. Why? 

Because as soon as someone puts a DAWG processor into an Apache mod, for
example, the game is over. Accept: already lets you do content negotiation
for resource representations. There already are lots of different
representations for "RDF graphs".

Making URIs that identify resources which are dynamically built from DAWG
queries will be the 2nd or 3rd thing I do with DAWG software. It's so
insanely obviously and inevitable it's not worth discussing. The next thing
I will do is to use ordinary HTTP content negotiation to tell the origin
server about my preferred types of representation for these resources.

But it will happen far cleanly, reliably, and sanely if we do a bit of actual
standardization work here.

Kendall Clark
You're one in a million
You've got to burn to shine
Received on Thursday, 24 June 2004 14:21:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:27 UTC