- 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
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 direction. > 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. Yes. Kendall -- 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