- From: Elias Torres <elias@torrez.us>
- Date: Wed, 04 Oct 2006 21:29:13 -0400
- 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 disagreement? 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. -Elias > > Mark. > >
Received on Thursday, 5 October 2006 01:29:37 UTC