RE: ACTION: elaborate on 4.4

One alternative serialization that I am very interested in is XML topic
maps.  Unlike RDF, the XTM model has a coherent approach to provenence --
something that is probably on the necessary growth path for the RDF data
model.

So I also strongly favor the ability to negotiation for any interchange
representation using its Internet MIME Type.

-bryan

-----Original Message-----
From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
On Behalf Of Seaborne, Andy
Sent: Friday, June 18, 2004 12:36 PM
To: kendall@monkeyfist.com
Cc: RDF Data Access Working Group
Subject: 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:43:35 UTC