RE: ACTION: elaborate on 4.4

-------- Original Message --------
> From: Kendall Clark <mailto:kendall@monkeyfist.com>
> Date: 18 June 2004 13:27
> 
> On Fri, Jun 11, 2004 at 11:55:25AM +0100, Seaborne, Andy wrote:
> 
> > There is one, defined recommendation for serializing RDF graphs - its
> > RDF/XML [1].  The one point of having a recommendation is so everyone
> > can implement one thing, and not many.
> 
> And yet people keep making new ways to serialize RDF graphs. This
> suggests to me what people have been saying about RDF-XML forever: it
> has some warts and doesn't fit some (many?) situations. I happen to
> think -- the layer cake be damned (eaten?) -- that non-XML
> serializations of RDF are (or can be) a very good thing. I don't want
> to give those communities *no way* to use DAWG compliantly.

That really only makes sense if the non-XML serializations are common.
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.

> 
> 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.  Where
additional features (e.g. named graphs) are needed then fine.  It's
encouraging the alternative serializations of core RDF where I don't
understand the need for a requirement.

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.

	Andy

> 
> > Alternative serialization that encode more information (TriX for the
> > named graphs, some way of using N3 with formulae) is one thing:
> > promoting alternative serialises of RDF just negates the value to
> > clients (samll and large) of having one serialization to deal with.
> 
> Tell that to Sir TBL! :>
> 
> Best,
> Kendall

Received on Friday, 18 June 2004 12:35:40 UTC