- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Mon, 7 Jun 2004 13:17:39 -0400
- To: Dan Connolly <connolly@w3.org>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Mon, Jun 07, 2004 at 12:01:40PM -0500, Dan Connolly wrote: > -- 4.4 User-specifiable Serialization > > ACTION: KendellC to elaborate on 4.4 -sigh-... I'll know DAWG is finished when Dan spells my name correctly two times in a row. :> Okay, to discharge this action item... I proposed 4.4 because there are now, by my count, several exchange serializations of RDF graphs, with varying statuses: de jure standards, de facto standards, dead-end proposals, v. promising proposals, wild-ass ideas: 1. canonical RDF-XML (with a couple of well-known variants) 2. Notation3 3. NTriples 4. TRiX 5. Turtle 6. RXR 7. YAML (I'm working on this one; it has some nice features) And probably a few others I'v forgotten or never heard of. These all have different properties, different advantages and disadvantages; some are more widely implemented, some are good for resource-constrained use cases, and so on. But what seems clear to me is that no one of these is going to crowd out the others. Thus, I think we should recognize that fact -- if it is a fact -- and act accordingly. So I want to be able to request or negotiate for -- and I'm *today* agnostic as to where, in the protocol or in the QL -- my preferred exchange serialization. That was the point of my proposal. Open design issues (many of which I expect can be analogized to content negotiation in HTTP) include: - how to request one's preferred exchange serialization; - whether it's a request or a negotiation; - whether to identify exchange serializations by Internet Media Type, by URI, or by canonical short name; - which format should be the default? (Ok, that one is easy!) Also, is this requirement totally parasitic on 3.4? In other words, if 3.4 is rejected, should we still be able to specify which kind of exchange serialization one prefers for variable binding results? I don't see why not, and, in fact, I think that this design objective is applicable to both 3.2 and 3.4 is an indication of its utility. I hope this discharges my action item to expand on my reasons for 4.4. Best, Kendall Clark
Received on Monday, 7 June 2004 13:19:28 UTC