[RESEND] Media types for RDF languages N3 and Turtle
GK at ninebynine.org
Fri Dec 21 00:03:40 CET 2007
Eric Prud'hommeaux wrote:
> * Graham Klyne <GK at ninebynine.org> [2007-12-19 16:10+0000]
>> I've not read the latest emergence of this thread with a fine tooth comb, but I
>> would suggest:
>> (1) use application/(something) rather than text/(something) in *all* cases
>> where the content is not primarily for human consumption - i.e. if you expect to
>> do anything other than display as-is on a character display.
> By that metric, I agree that they should be application/ , but I'm not
> confident that said metric is consistent with the rest of the text/
> mime tree. Anyone else care to back up or contradict one or both of us?
The guy to talk to would be Ned Freed. I've heard him say, for example, he
believes that text/html was a mistake, because in practice it's not helpful to
display HTML to users as raw text (except, maybe, to babies and grandmas in your
>> *any* rendering of RDF is really primarily constructed for direct human
> Oh pshaw. RDF is meant for babies and grandmothers alike; and its text formats
> read like a romance novel, only less racey.
>> (2) rather than use the +suffix for cases other than +xml, use -suffix. Or, at
>> least, provide a compelling example of two different media types with +foo
>> suffix that might fall back to being processed by a common software package
>> associated with that suffix.
>> application/octet-stream (ntriples)
> Ahh, cool. Could you tell me what are the semantics of foo-bar? I know only
> octet-stream, and never considered separating the words before.
There are none... in this context, '-' is just another letter (like '_' in other
contexts). That's my point: we don't need any additional (machine processable)
As I recall, the introduction of '+xml' followed fairly extensive debate in the
IETF about the value (or not) of making it possible for dispatchers to recognize
any xml-based format without necessarily knowing about the particular language
variant being presented. XML was recognized as an exceptional case, in that
there were very many XML based formats for which some common handling of XML
syntactic framework elements might be valuable, leading to the +xml convention.
My view is that if this convention is overworked, it may lose its power to
discriminate (or to be effectively employed) in such exceptional cases.
Further I would say that, in the case of RDF, the whole point is that we do
*not* end up with a family of syntactically related languages with inconsistent
semantics - we just have RDF, and while there may be different syntactic
variations that need different first-line processing, the semantics they
represent are essentially compatible. Isn't that, after all, one of the big
reasons for using RDF in the first place?
>> Eric Prud'hommeaux wrote:
>>> [resent, correcting typos and thinkos]
>>> Hi all, there are a couple languages that have been used for a while,
>>> turtle and n3, and I am trying work out the right media types to
>>> register for them.
>>> == Cast of Characters
>>> ║ name ║ role ║ current media type ║
>>> ║ RDF │ data model │ N/A ║
>>> ║ RDFXML │ XML serialization of RDF │ application/rdf+xml ║
>>> ║ ntriples │ simple serialization of RDF │ text/plain ║
>>> ║ turtle │ textual serialization of RDF │ application/x-turtle ║
>>> ║ n3 │ extension¹of turtle language │ text/rdf+n3 (not ║
>>> ║ │ expressing a superset of RDF │ registered) ║
>>> ¹ The origins of turtle and n3 are complicated, but this is the
>>> most practical model for media type consideration.
>>> These languages will be published under http://www.w3.org/TR/
>>> (which implies certain persistance and update policy) as soon
>>> as I work out what to include in the media type registration.
>>> In the mean time, see
>>> Neither the turtle nor n3 media types are registered. I seek advice
>>> from the community on exactly how to register them, as I will have
>>> to beat out some sort of consensus in order to register them.
>>> == Issues
>>> • subsumption relationshop — n3 subsumes turtle in both data model and
>>> grammar. To that end, text/n3; and text/n3; profile=turtle have been
>>> suggested. Another suggestion has been text/rdf+n3 and
>>> text/rdf+turtle , in somewhat the spirit of XML (where the +xml
>>> indecates the that it's the XML encoding of the preceding datatype).
>>> • subtree — turtle and n3 are certainly more human-readable than
>>> ntriples (as they are basically extensions of ntriples, with
>>> namespace prefixes and abbreviations for some atoms). The default
>>> character encoding of us-ascii is certainly outdated, and doesn't
>>> make sense for any of these languages. Garret Wilson (Cc'd) raised
>>> the question of whether a text/ registration may force the charset
>>> to be, say, utf-8². Both n3 and turtle, as well as related langs
>>> like SPARQL, are explcitly utf-8. Can the registration include text
>>> like "The encoding is always UTF-8"? Would that mean that the
>>> media type would not need a constant charset parameter?
>>> ² http://lists.w3.org/Archives/Public/www-rdf-comments/2007OctDec/0017
>>> == Strawman
>>> Let me propose:
>>> n3: text/rdf+n3
>>> turtle: text/rdf+turtle
>>> Encoding considerations: The encoding is always UTF-8
>>> and the expectation that
>>> Content-type: text/rdf+n3
>>> (or +turtle) fully specifies the media type and the
>>> character encoding.
>>> A plea to all: bear in mind that this consensus bit is a hard job,
>>> and that the world will be much better off if we can reach a timely
>>> compromise. We've suffered for five years without these media types
>>> so let's keep our mission reallistic.
>> Graham Klyne
>> For email:
More information about the Ietf-types