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: Fri, 18 Jun 2004 08:22:59 -0400
To: "Eric Prud'hommeaux" <eric@w3.org>
Cc: public-rdf-dawg@w3.org
Message-ID: <20040618122259.GA18696@monkeyfist.com>

On Fri, Jun 11, 2004 at 01:21:50PM +0900, Eric Prud'hommeaux wrote:
> There are three tiers in the xml subtrees as specified by RFC 3023.
> It specifies (or maybe just references) a bunch of popular media types:

Eek! I just noticed this fine message from Eric; sorry, I've been
swamped and not paying enough attention to INBOX.

> One feature of using media type selection is that it allows us to take
> advantage of the notion that the semantic content should be consistent
> from one serialization to another. Thus, you can get the URL for a
> query and give the URL to different clients which prefer different
> result formats.

That's what's motivating my proposal of this design objective. At
least that's clear to one other person. :>

This points out, however, a kind of implicit confusion -- which is to
say, something we haven't made clear, yet -- in our
discussions. What's the *semantic* relationship between our query
languae and our data access protocol?

Does Accept: foo merely serialize some semantic bit of the query
language or is it *the only* representation of that bit, which
suggests that the sum total of a query is the query plus the
protocol. That's not v. clear, but I hope it gestures in the right

> I can see this working to select between N3 and RDF, even RDF and TRiX
>   application/rdf+xml vs application/trix+xml
> but not between tuple and graph responses. Those seem like they'd
> require different URLs.

Yes, I think *that* distinction has to be reflected in the query
language itself. (And, I'll add:  between tuple, graph, and boolean
responses, ideally.)

> On the downside, whatever mime types we need have to be registered
> through IETF which puts a dependancy on another orgnanization.

Yes, that's the other practical problem. And: Accept: is the obvious
header to use. Can we get away with putting a URI into it rather than
an IMT?

> 3023 does not deal with compound document, but I don't think we need
> that for our purposes. Even if we do, and we have to do something
> that's known only to DAWG-QL (or DAWG-TP), we'd have to do that if
> we rolled our own format selection protocol.


Well, Long Tall Sally, she's built for speed
She got everything that Uncle John need!
				-- Little Richard
Received on Friday, 18 June 2004 08:25:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:44 UTC