[RESEND] Media types for RDF languages N3 and Turtle

Eric Prud'hommeaux eric at w3.org
Thu Dec 20 22:11:22 CET 2007


* 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?

>                                                               I don't think that
> *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.

> #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
> 

-- 
-eric

office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

(eric at w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20071220/c1c3fb0e/attachment-0001.bin


More information about the Ietf-types mailing list