Eric Prud'hommeaux wrote:
* Graham Klyne <GK@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 lineage ;)
*any* rendering of RDF is really primarily constructed for direct human interpretation.
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.
Thus: application/rdf+xml application/octet-stream (ntriples) application/rdf-turtle application/rdf-n3
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) semantics here. 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? #g --
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 http://www.dajobe.org/2004/01/turtle/#sec-mime http://www.w3.org/DesignIssues/Notation3
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 with [[ 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: http://www.ninebynine.org/#Contact
-- Graham Klyne For email: http://www.ninebynine.org/#Contact