W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > October 2006

Re: Why not application/json?

From: Elias Torres <elias@torrez.us>
Date: Wed, 04 Oct 2006 21:29:13 -0400
Message-ID: <45245FE9.7060708@torrez.us>
To: Mark Baker <distobj@acm.org>
CC: public-rdf-dawg-comments@w3.org

Mark Baker wrote:
> Hi,
> I checked out the just published SPARQL-results-in-JSON draft and
> noted that the media type was still application/sparql-results+json.
> Thinking I'd commented on this before, I went to the archives and
> found a response intended for me that wasn't actually sent to me;
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Jun/0047
> It gave the following reasoning for the use of that media type, which
> I'll respond to below;
> "Sorry it took me long to answer, but I wanted to run my answer by the WG
> so I could speak on its behalf. Although we know application/json could
> suffice, we felt that it'd be important to distinguish between JSON
> encoded graphs and SPARQL results format. Admittedly, JSON is a data
> model, but unfortunately, there are no conventions to specify the model
> type. This the same reason why we didn't use application/xml for SPARQL
> Results XML Format to be able to distinguish it from RDF/XML."
> I'm not sure what you mean by "model type".  Can you explain?

I was trying to say that the JSON format does not provide any
standard/best practice for content to be self-describing. If I parse a
document of type application/json there's no way for me to find out the
nature of the object structure I'm dealing within my application.

> I agree application/xml is insufficient for SPARQL results (and any
> specific XML vocabulary in fact, for the reasons in the TAG finding on
> authoritative metadata).  I don't agree that the same reasoning can be
> applied to application/json though.

I don't understand why the same reasoning doesn't apply to
application/json. Could you give me any specific reasons for your

In authoritative metadata:

"Superset media types being used when a more specific media type is
intended, such as the use of "application/xml" when there exists a more
specific media type corresponding to the root element."

I would take this as a sign that more is better.

> And as I mentioned in my initial comment, the WG used
> application/rdf+xml for SPARQL results in RDF/XML, and rightly so IMO.

RDF/XML is a beast of a serialization format. RDF by nature can't be
contained to specific shapes/structures. An RDF document/file can
contain a large finite set of disjoint triples. If we were to try to
create a mime type for each one of them we'd never finish. On the other
hand, we have defined a specific XML schema/Relax NG structure for our
results format and we have done so as well for JSON (there's no JSON
Schema). Therefore just as the Atom WG registers a mime-type for Atom
XML, we submitted a registration for our equivalent structure.

> FWIW, I've never used JSON so perhaps I'm missing something.

JSON is very lightweight and people's light bulbs go on when they use
it, but after a while they recognize that it's best suited for
situations when you control both ends of the wire. In our case we don't
so by using authoritative metadata we can be assured that the consumer
knows how to deal with our structure. For example, if I were to consume
any external JSON output on the web today, there's nothing that would
help me detect changes in the structure unless I coded it defensively or
inspected the contents of the response document. Both of these seem a
lot more work than registering a new mime type.


> Mark.
Received on Thursday, 5 October 2006 01:29:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:07 UTC