Semantic Web, Web

Discussion about mime types: changing RSS 1.0 mime type and other considerations

Recently I serialized the SIOC and FOAF RDF documents generated by Talk Digger using N3. I also enabled Ping the Semantic Web to detecting and archiving pings of RDF documents serialized using N3.

These two modifications to these systems make me thinking about some things:


  • Why I wasn’t using the “application/rdf+xml” mime type to describe the RSS 1.0 web feeds generated by Talk Digger?
  • Why I was not serializing the RSS 1.0 RDF documents using N3 too?
  • Why the mime type for the N3 serialization is “text/rdf+n3” instead of “application/rdf+n3”?


Why not using the “application/rdf+xml” mime type to describe the RSS 1.0 web feeds?

To try to answer to this question I had to re-read the RSS 1.0 specification last modified the 30 May 2001. I can read from the “section 5: Core Syntax” of the document:

Mime Type
The current mime-type recommendation for an RSS 1.0 document is application/xml. However, work is currently being done to register a mime-type for RDF (and possibly RSS). The RDF (or preferably RSS) mime-type should be used once it has been registered.

Then I was thinking: the application/rdf+xml mime type has been accepted in September 2004 by the IANA.

So I propose to change the specification accordingly to this fact. RSS 1.0 files are RDF documents, so we should reflect that fact in the specification by using the good mime type.

Also, if other developers, like me, use the application/xml type instead of the application/rdf+xml, web services like Ping the Semantic Web will only ignore these precious pieces document.


Why not serializing the RSS 1.0 RDF documents using N3 too?

It is a good question that I don’t know the answer right now.

It is because it is because N3 is unsuitable for RSS 1.0? Is it because N3 is not enough popular among developers? Is it because the RSS 1.0 specification is too old?
Personally I think that RSS 1.0 could benefit by adding a reference to the possibility to serialize RSS 1.0 documents using N3 and not only XML.

So I would propose to add the fact that people could have the possibility serialize RSS 1.0 documents using N3 with the mime type “text/rdf+n3” (even if I would certainly prefer “application/rdf+n3” but I will come back to this issue with the next question).


Why the mime type for the N3 serialization is “text/rdf+n3” instead of “application/rdf+n3”?

I checked the Notation 3 design issue document to answer to that question. The reason is:

The type application/n3 was applied for at one point (2002?) but I have no trace of any correspondence. It should not be used, as part of the point of N3 is to be human readable, and so the text tree is indicated. The application for text/rdf+n3 with the IANA registry is pending as of 2006-02 as IANA #5004. While registration is pending, applications should use the proposed type in anticipation of registration, not an x- type.

In the Notation 3 Primer document I can read:

The world of the semantic web, as based on RDF, is really simple at the base. This article shows you how to get started. It uses a simplified teaching language — Notation 3 or N3 — which is basically equivalent to RDF in its XML syntax, but easier to scribble when getting started.

If this notation is simpler for teaching purposes, this notation is probably also simpler for development purposes too (at least I found so). For that later fact, I think it would be important to consider it when we think about mime types.

In fact, it seems that the N3 document have been designed for teaching purposes because it is simpler to express RDF relations using N3 than XML. I agree.

However, I think that the semantic web community will benefit from that fact not for teaching, but for developing purposes (so spreading the use of RDF as a way to describe resources).

But I see a paradox in the use of “text/rdf+n3” mime type instead of “application/rdf+n3”. The reason is that “N3 is to be human readable”. If we extend that reasoning, we could certainly say that XML is to be human readable too (at least I am able to read and understand some).

My question is: are RDF documents at the intention of the human or the machine? I always saw RDF documents as a document at the intention of machines. In that case, for me, both serializations are at the intention of the machine, and not really at the intention of human. In fact, I think that the question we have to ask is “Who will consume that document?” instead of “Is the document human readable?” So yeah the content is human readable but it is to be used by machines.

If one agrees with that fact, we should certainly think about using the “application/rdf+n3” mime type instead of “text/rdf+n3”, no? After all, are mime types at the intention of humans or machines?



Finally I suggest updating the RSS 1.0 spec with the “application/rdf+xml” mime type and I suggest adding a reference to the possibility to use N3 to serialize RDF 1.0 RDF documents. Also I (re?)-open the discussion about the use of “text/rdf+n3” mime type (instead of application/rdf+n3).

Please tell me if I missed something while thinking about these things, if there are considerations that I am not aware of, or anything else.


Technorati: | | | | | | | | | |

6 thoughts on “Discussion about mime types: changing RSS 1.0 mime type and other considerations

  1. on a URI i recently dereferenced in firefox, i see this:

    “This document is content-negotiated, so if you request it with Accept-Types: application/x-turtle for example you will get the description in RDF/Turtle”

    here we have it offering the contents in Turtle, which was certainly designed for human readability, compared to RDF/XML, and still referring it to under application/ instead of text/ . but then billions of webpages are text/html, and i dont see people reading the source code, so much as the machine-rendered output..

  2. Hi Carmen,

    exactly. Dave Beckett choose to use application instead of text to describe its N3 Turtle language and you are right about HTML pages too 😉

    In fact, the rendered result of such a file is at the intention of humans, but the file in itself, the code, is at the intention of machines.

    I talked about all that stuff with Uldis Bojar yesterday and the result was: the mimes for N3 is a mess, one web crawler should support many to be sure to find all of them.

    Thanks for your comment!

    Take care,


  3. Hi Richard,

    Thanks for this reference 🙂

    However: who is supporting this new version 1.1? Would a revision would not be more adequate than a new verison with a new namespace? I ask the question 🙂

    Take care,


  4. regarding the “text/rdf+n3 or application/rdf+n3” issue.

    afaik the trouble with the text/* mime-types is that they should not contain any charset-related information internally. that’s why application/xml is better than text/xml.

    but for N3 the spec says it must be UTF-8, so i think in this case, text/rdf+n3 might make sense.

Leave a Reply