W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2004

Re: ACTION: elaborate on 4.4

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>
Message-ID: <20040618164556.GA20409@monkeyfist.com>

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.


PS--Sorry if this sounds harsh; I'm feeling sick today and generally
Received on Friday, 18 June 2004 12:48:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:27 UTC