- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Fri, 18 Jun 2004 12:45:56 -0400
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Fri, Jun 18, 2004 at 05:34:23PM +0100, Seaborne, Andy wrote: > That really only makes sense if the non-XML serializations are common. Well, how high is up? All of our (UMD) tools take N3 as input. Is that common enough? > Otherwise, the set up client/server has a dependency in assuming some format > is available. I suppose use(abuse? not sur eit is correct use) of OPTIONS > is possible. I think it's a use, not an abuse, but then I support it, so I would think that. :> > > Sorry, but "one ring to bind them"-style arguments fall super flat > > with me. Standardization != restriction of choices to 1 only. > > We would, I presume, require that at least RDF/XML is supported as a > serialization format for reasons of maximum interoperability. I totally agree with this. No one would be *required* to support anything other than RDF-XML. I just want to enable clients & servers that want to support something else to do so cleanly. As I've said, if there can be only one XML serialization, RDF-XML is the one. I just haven't yet heard a convincing argument for that premise. Appeals to "standardization" are neither convincing nor useful, IMO. > Where > additional features (e.g. named graphs) are needed then fine. Additional features: 1. non-XML formats (NTriples, YAML) 2. human factors (N3, Turtle) No one makes up new serialization formats for *no* reason -- well, except Dave Beckett. He's crazy! :> > It's > encouraging the alternative serializations of core RDF where I don't > understand the need for a requirement. Well, this is a design objective. And I'm not encouraging them. I'm trying to recognize and accomodate *existing practice* on the ground. That is a perfectly legitimate role of standardization work, one of many such goals. > Generally, I don't expect people to look at the results of a DAWG query > directly - the output is consumed by some client-side application - so I > don't put much weight on the need for alternative serializations. But, Andy, that assumes a premise I have no reason to believe, namely: "The only reason for an alternative serialization format is to enable human consumption". That's just wrong as a reading of the factual reasons that people offer for alternative serializations. Best, Kendall PS--Sorry if this sounds harsh; I'm feeling sick today and generally malaiseful.
Received on Friday, 18 June 2004 12:48:03 UTC