N-Triples MIME type should not be text/plain -- comment on RDF Test Cases.

[Tim Berners-Lee]

Comment on "RDF Test Cases".
W3C Recommendation 10 February 2004
  In http://www.w3.org/TR/rdf-testcases/#ntriples it says,

The Internet media type / MIME type of N-Triples is text/plain and  
the character encoding is 7-bit US-ASCII.

This is a bug, I think.   It  prevents crawlers from absorbing the  
file and indexing it proerly, it will prevent the file from being  
dispatched inside a data browser to a data-handling view, and so on.

I would suggest   text/rdf+n3   if the assumption is correct that  
NTriples is a subset of N3.
Otherwise I suppose text/rdf+nt or something would be logical.  
Anotehr possibility would be
text/rdf=n3; level=nt
introducing a level parameter to explain what level of N3 was being  
used.

Tim BL

[Graham Klyne-2]

Two comments, agreeing text/plain is not ideal...

1. My recollection of the IETF discussions around introducing the +xml
convention for MIME content types were focused on applications that might
recognize the suffix and be able to pass the content to some application that
could exploit the common framework of XML.  I don't think that applies here.

2. The intent of text/... is that the content can be displayed to human readers
on text display devices and still be reasonably easy to interpret.  It has been
commented that, for example, HTML fails on this score, and application/ would be
a better choice.

Which considerations suggest to me application/n3 as an appropriate MIME content
type.

#g
--

Tim Berners-Lee wrote:

>
> Comment on "RDF Test Cases".
> W3C Recommendation 10 February 2004
>  In http://www.w3.org/TR/rdf-testcases/#ntriples it says,
>
> The Internet media type / MIME type of N-Triples is text/plain and the
> character encoding is 7-bit US-ASCII.
>
> This is a bug, I think.   It  prevents crawlers from absorbing the file
> and indexing it proerly, it will prevent the file from being dispatched
> inside a data browser to a data-handling view, and so on.
>
> I would suggest   text/rdf+n3   if the assumption is correct that
> NTriples is a subset of N3.
> Otherwise I suppose text/rdf+nt or something would be logical. Anotehr
> possibility would be
> text/rdf=n3; level=nt
> introducing a level parameter to explain what level of N3 was being used.
>
> Tim BL
>

--
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

[Garret Wilson]

When I originally saw that TBL had recommended text/rdf+n3 as the N3
MIME type, I was surprised. JSON uses application/json [RFC 4627]. XHTML
uses application/xhtml+xml [RFC 3236]. text/javascript and
text/ecmascript are now marked "obsolete" in favor of
application/javascript and application/ecmascript, respectively, noting
that, "The use of the 'text' top-level type for this type of content is
known to be problematic." [RFC 4329]

Looking further on the web, it appears that one of the major concerns is
that the character set for "text" content types would default to
US_ASCII during HTTP content type negotiation if no "charset" parameter
were supplied. However, I read RFC 2046 to say that this only applies to
text/plain, and that any future "text" subtypes may specify default
character sets other than US_ASCII. But how this is handled in the wild
by browsers, I don't know.

Whatever the case, there seems to be a trend away from "text" content
types (for anything other than text/plain, it seems, which makes me
question the usefulness of the entire "text" top-level type, but that's
another issue). Are these fears warranted, and should text/* be
abandoned in favor of application/*, as Graham suggests? Or will using
text/* allow browsers to display the N3 (which seems useful to me) if
there is no plugin for N3?

Garret

Graham Klyne wrote:

> Two comments, agreeing text/plain is not ideal...
>
> 1. My recollection of the IETF discussions around introducing the +xml
> convention for MIME content types were focused on applications that might
> recognize the suffix and be able to pass the content to some application that
> could exploit the common framework of XML.  I don't think that applies here.
>
> 2. The intent of text/... is that the content can be displayed to human readers
> on text display devices and still be reasonably easy to interpret.  It has been
> commented that, for example, HTML fails on this score, and application/ would be
> a better choice.
>
> Which considerations suggest to me application/n3 as an appropriate MIME content
> type.
>
> #g
> --
>
> Tim Berners-Lee wrote:
>  
>> Comment on "RDF Test Cases".
>> W3C Recommendation 10 February 2004
>>  In http://www.w3.org/TR/rdf-testcases/#ntriples it says,
>>
>> The Internet media type / MIME type of N-Triples is text/plain and the
>> character encoding is 7-bit US-ASCII.
>>
>> This is a bug, I think.   It  prevents crawlers from absorbing the file
>> and indexing it proerly, it will prevent the file from being dispatched
>> inside a data browser to a data-handling view, and so on.
>>
>> I would suggest   text/rdf+n3   if the assumption is correct that
>> NTriples is a subset of N3.
>> Otherwise I suppose text/rdf+nt or something would be logical. Anotehr
>> possibility would be
>> text/rdf=n3; level=nt
>> introducing a level parameter to explain what level of N3 was being used.
>>
>> Tim BL
>>
>>    
>
>  

[Garret Wilson]

The following messages seems to be a good overview of some of the
perceived problems with a text top-level MIME type:

http://www1.ietf.org/mail-archive/web/ietf/current/msg36105.html
http://www1.ietf.org/mail-archive/web/ietf/current/msg36149.html

Of particular interest is the RFC 2046 requirement that all line breaks
be CRLF, and that CR and LF not appear outside a line break sequence.
This doesn't worry me so much---after all, "text/xml" seems to ignore
this requirement (XML allows arbitrary CRs and LSs; see
<http://www.w3.org/TR/REC-xml/#sec-line-ends>).

What seems most important to me, however, is that RFC 2046 describes the
"text" top-level type thus: "Possible subtypes of 'text' thus include
any word processor format that can be read without resorting to software
that understands the format" (3.1). This seems to be the defining
question: can you open and edit the format in a word processor? For N3,
the answer is yes.

This would lead to the conclusion of "plain N3" using a MIME type of
text/rdf+n3, as TBL suggested. I would imagine some specific application
of N3 to use application/app+rdf+n3, where "app" is the name of the
application that is uses N3 as its underlying format.

Garret

Garret Wilson wrote:

>
> When I originally saw that TBL had recommended text/rdf+n3 as the N3
> MIME type, I was surprised. JSON uses application/json [RFC 4627].
> XHTML uses application/xhtml+xml [RFC 3236]. text/javascript and
> text/ecmascript are now marked "obsolete" in favor of
> application/javascript and application/ecmascript, respectively,
> noting that, "The use of the 'text' top-level type for this type of
> content is known to be problematic." [RFC 4329]
>
> Looking further on the web, it appears that one of the major concerns
> is that the character set for "text" content types would default to
> US_ASCII during HTTP content type negotiation if no "charset"
> parameter were supplied. However, I read RFC 2046 to say that this
> only applies to text/plain, and that any future "text" subtypes may
> specify default character sets other than US_ASCII. But how this is
> handled in the wild by browsers, I don't know.
>
> Whatever the case, there seems to be a trend away from "text" content
> types (for anything other than text/plain, it seems, which makes me
> question the usefulness of the entire "text" top-level type, but
> that's another issue). Are these fears warranted, and should text/* be
> abandoned in favor of application/*, as Graham suggests? Or will using
> text/* allow browsers to display the N3 (which seems useful to me) if
> there is no plugin for N3?
>
> Garret
>
> Graham Klyne wrote:
>> Two comments, agreeing text/plain is not ideal...
>>
>> 1. My recollection of the IETF discussions around introducing the +xml
>> convention for MIME content types were focused on applications that
>> might
>> recognize the suffix and be able to pass the content to some
>> application that
>> could exploit the common framework of XML.  I don't think that
>> applies here.
>>
>> 2. The intent of text/... is that the content can be displayed to
>> human readers
>> on text display devices and still be reasonably easy to interpret.  
>> It has been
>> commented that, for example, HTML fails on this score, and
>> application/ would be
>> a better choice.
>>
>> Which considerations suggest to me application/n3 as an appropriate
>> MIME content
>> type.
>>
>> #g
>> --
>>
>> Tim Berners-Lee wrote:
>>  
>>> Comment on "RDF Test Cases".
>>> W3C Recommendation 10 February 2004
>>>  In http://www.w3.org/TR/rdf-testcases/#ntriples it says,
>>>
>>> The Internet media type / MIME type of N-Triples is text/plain and the
>>> character encoding is 7-bit US-ASCII.
>>>
>>> This is a bug, I think.   It  prevents crawlers from absorbing the file
>>> and indexing it proerly, it will prevent the file from being dispatched
>>> inside a data browser to a data-handling view, and so on.
>>>
>>> I would suggest   text/rdf+n3   if the assumption is correct that
>>> NTriples is a subset of N3.
>>> Otherwise I suppose text/rdf+nt or something would be logical. Anotehr
>>> possibility would be
>>> text/rdf=n3; level=nt
>>> introducing a level parameter to explain what level of N3 was being
>>> used.
>>>
>>> Tim BL
>>>
>>>    
>>
>>  
>

[Graham Klyne-2]

Garret,

The person to ask for a more definitive view would be Ned Freed (co-author of
RFC2046).  I have read him argue quite compellingly in a public forum that the
adoption of text/html was a mistake, because for non-technical users displaying
the uninterpreted text is just a source of confusion (e.g.
http://osdir.com/ml/ietf.xml-mime/2000-10/msg00049.html).

Also, look to the mailing list which produced RFC 3023
(http://www.ietf.org/rfc/rfc3023.txt) for the discussion of +xml being something
of a special case.  (I think that discussion was also part of the thread I cite
above, but I don't have time to dig deeper right now.)

Also, from RFC 3023 (section 1):
[[
   Similarly, XML will be used as a foundation for other media types,
   including types in every branch of the IETF media types tree.  To
   facilitate the processing of such types, media types based on XML,
   but that are not identified using text/xml or application/xml, SHOULD
   be named using a suffix of '+xml' as described in Section 7.  This
   will allow XML-based tools -- browsers, editors, search engines, and
   other processors -- to work with all XML-based media types.
]]
-- http://www.ietf.org/rfc/rfc3023.txt

I don't think a similar case can be made for either RDF or N3 (for different
reasons).

#g
--

Garret Wilson wrote:

> The following messages seems to be a good overview of some of the
> perceived problems with a text top-level MIME type:
>
> http://www1.ietf.org/mail-archive/web/ietf/current/msg36105.html
> http://www1.ietf.org/mail-archive/web/ietf/current/msg36149.html
>
> Of particular interest is the RFC 2046 requirement that all line breaks
> be CRLF, and that CR and LF not appear outside a line break sequence.
> This doesn't worry me so much---after all, "text/xml" seems to ignore
> this requirement (XML allows arbitrary CRs and LSs; see
> <http://www.w3.org/TR/REC-xml/#sec-line-ends>).
>
> What seems most important to me, however, is that RFC 2046 describes the
> "text" top-level type thus: "Possible subtypes of 'text' thus include
> any word processor format that can be read without resorting to software
> that understands the format" (3.1). This seems to be the defining
> question: can you open and edit the format in a word processor? For N3,
> the answer is yes.
>
> This would lead to the conclusion of "plain N3" using a MIME type of
> text/rdf+n3, as TBL suggested. I would imagine some specific application
> of N3 to use application/app+rdf+n3, where "app" is the name of the
> application that is uses N3 as its underlying format.
>
> Garret
>
> Garret Wilson wrote:
>>
>> When I originally saw that TBL had recommended text/rdf+n3 as the N3
>> MIME type, I was surprised. JSON uses application/json [RFC 4627].
>> XHTML uses application/xhtml+xml [RFC 3236]. text/javascript and
>> text/ecmascript are now marked "obsolete" in favor of
>> application/javascript and application/ecmascript, respectively,
>> noting that, "The use of the 'text' top-level type for this type of
>> content is known to be problematic." [RFC 4329]
>>
>> Looking further on the web, it appears that one of the major concerns
>> is that the character set for "text" content types would default to
>> US_ASCII during HTTP content type negotiation if no "charset"
>> parameter were supplied. However, I read RFC 2046 to say that this
>> only applies to text/plain, and that any future "text" subtypes may
>> specify default character sets other than US_ASCII. But how this is
>> handled in the wild by browsers, I don't know.
>>
>> Whatever the case, there seems to be a trend away from "text" content
>> types (for anything other than text/plain, it seems, which makes me
>> question the usefulness of the entire "text" top-level type, but
>> that's another issue). Are these fears warranted, and should text/* be
>> abandoned in favor of application/*, as Graham suggests? Or will using
>> text/* allow browsers to display the N3 (which seems useful to me) if
>> there is no plugin for N3?
>>
>> Garret
>>
>> Graham Klyne wrote:
>>> Two comments, agreeing text/plain is not ideal...
>>>
>>> 1. My recollection of the IETF discussions around introducing the +xml
>>> convention for MIME content types were focused on applications that
>>> might
>>> recognize the suffix and be able to pass the content to some
>>> application that
>>> could exploit the common framework of XML.  I don't think that
>>> applies here.
>>>
>>> 2. The intent of text/... is that the content can be displayed to
>>> human readers
>>> on text display devices and still be reasonably easy to interpret.
>>> It has been
>>> commented that, for example, HTML fails on this score, and
>>> application/ would be
>>> a better choice.
>>>
>>> Which considerations suggest to me application/n3 as an appropriate
>>> MIME content
>>> type.
>>>
>>> #g
>>> --
>>>
>>> Tim Berners-Lee wrote:
>>>  
>>>> Comment on "RDF Test Cases".
>>>> W3C Recommendation 10 February 2004
>>>>  In http://www.w3.org/TR/rdf-testcases/#ntriples it says,
>>>>
>>>> The Internet media type / MIME type of N-Triples is text/plain and the
>>>> character encoding is 7-bit US-ASCII.
>>>>
>>>> This is a bug, I think.   It  prevents crawlers from absorbing the file
>>>> and indexing it proerly, it will prevent the file from being dispatched
>>>> inside a data browser to a data-handling view, and so on.
>>>>
>>>> I would suggest   text/rdf+n3   if the assumption is correct that
>>>> NTriples is a subset of N3.
>>>> Otherwise I suppose text/rdf+nt or something would be logical. Anotehr
>>>> possibility would be
>>>> text/rdf=n3; level=nt
>>>> introducing a level parameter to explain what level of N3 was being
>>>> used.
>>>>
>>>> Tim BL
>>>>
>>>>    
>>>
>>>  
>>
>

--
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

[Garret Wilson]

Graham Klyne wrote:

> Also, from RFC 3023 (section 1):
> [[
>    Similarly, XML will be used as a foundation for other media types,
>    including types in every branch of the IETF media types tree.  To
>    facilitate the processing of such types, media types based on XML,
>    but that are not identified using text/xml or application/xml, SHOULD
>    be named using a suffix of '+xml' as described in Section 7.  This
>    will allow XML-based tools -- browsers, editors, search engines, and
>    other processors -- to work with all XML-based media types.
> ]]
> -- http://www.ietf.org/rfc/rfc3023.txt
>
> I don't think a similar case can be made for either RDF or N3 (for different
> reasons).
>  

Funny, I thought that a similar line of reasoning was obvious for
RDF/N3. Let's say that I have a "recipe" format that stores recipes for
my recipe application. Or maybe I have a configuration file type for my
operating system. If they were to have content types of
application/recipe+rdf+n3 and application/config+rdf+n3, respectively,
couldn't I edit them in a general RDF editor that could read N3, even if
I didn't have MyRecipeApplication or MyOSConfigEditor handy?

Garret

[Garret Wilson]

Graham Klyne wrote:
> The person to ask for a more definitive view would be Ned Freed (co-author of
> RFC2046).  I have read him argue quite compellingly in a public forum that the
> adoption of text/html was a mistake, because for non-technical users displaying
> the uninterpreted text is just a source of confusion (e.g.
> http://osdir.com/ml/ietf.xml-mime/2000-10/msg00049.html).
>  
One of the big issues seems to be the default browser behavior: whether
it should be displayed to the user if no application supports that
content type <http://osdir.com/ml/ietf.xml-mime/2000-10/msg00021.html>.
I can see the arguments on both sides, and it's a tough call. Out of
personal experience, it would irritate me if I were to try to browse to
a DTD file or an RDF/XML file and my browsers tries to download it, when
*I* know that I just wanted to view it on the screen. (Worse still is IE
thinking it can parse the stuff, and then choking because IE isn't
compliant with the specifications, but that's not the fault of the
content type.)

It seems to me that, if you don't have a plugin for N3, then why not
show it on the screen? It's better than nothing, and it doesn't help you
any more if the browser pops up a download dialog. text/rdf+n3 is thus
the lowest common denominator. If it is something that should never be
displayed to the user, then an application/specific+rdf+n3 should be
created, which could still be edited by a general RDF plugin, but would
never be displayed to the user. That's what I'm leaning towards on this,
but it's not an easy call by any means.

Garret

[Graham Klyne-2]

Garret Wilson wrote:

> Graham Klyne wrote:
>> Also, from RFC 3023 (section 1):
>> [[
>>    Similarly, XML will be used as a foundation for other media types,
>>    including types in every branch of the IETF media types tree.  To
>>    facilitate the processing of such types, media types based on XML,
>>    but that are not identified using text/xml or application/xml, SHOULD
>>    be named using a suffix of '+xml' as described in Section 7.  This
>>    will allow XML-based tools -- browsers, editors, search engines, and
>>    other processors -- to work with all XML-based media types.
>> ]]
>> -- http://www.ietf.org/rfc/rfc3023.txt
>>
>> I don't think a similar case can be made for either RDF or N3 (for
>> different
>> reasons).
>>  
>
> Funny, I thought that a similar line of reasoning was obvious for
> RDF/N3. Let's say that I have a "recipe" format that stores recipes for
> my recipe application. Or maybe I have a configuration file type for my
> operating system. If they were to have content types of
> application/recipe+rdf+n3 and application/config+rdf+n3, respectively,
> couldn't I edit them in a general RDF editor that could read N3, even if
> I didn't have MyRecipeApplication or MyOSConfigEditor handy?

Many years ago, my mathematical analysis tutor would say that if a statement was
"obvious", then either it could be proven in three lines, or it was an
assumption...   ;)

I can see that you might adopt the position you present above, but I don't think
it's useful to distinguish different uses of RDF in the way that it is for XML.
Different uses of XML, in general, are constrained by different syntactic rules
within the overall framework of XML, and an XML application cannot, in general,
do anything with any XML-based markup language that it hasn't been specifically
constructed to process.  Consider: the XML specification itself distinguishes
between "well-formed" and "valid" documents - the "+xml" convention entitles an
application to assume/require a well-formed document and no more but, in some
cases, the full MIME content-type may also dictate validity according to some
schema or DTD.

With RDF, the distinction between different uses isn't crystalized in the same
way.  You may choose to keep your recipes in a separate RDF file from, say, the
wine selections that might accompany them.  But another application may choose
to write them all into one RDF file -- it's the same RDF language at work here,
not different RDF languages for recipes and wine selection.  Thus, I say, just
use application/rdf+xml for both, or if it's not the XML form of RDF you're
using, then use application/n3, or whatever.  You could even (legitimately, if
not helpfully) put your OS configuration in the same RDF file as your recipes.

(One might argue that it's possible to define a notion of validity for RDF based
on some additional conditions on vocabulary usage (e.g. a recipe must have both
ingredients and a method of preparation), but such a notion isn't part of RDF.
In the Semantic Web arena, we can use OWL to describe the conditions that allow
for a resource to qualify as a recipe, if one wants a way to express such
constraints, and these apply at the level of the described resource rather than
the data entity containing the description.)

Introducing the +xml convention involved a fair amount of discussion, and I
don't see the point in doing a similar amount of work again unless there's a
clear and obvious (sic) benefit.

#g

--
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

[Garret Wilson]

Graham Klyne wrote:

> Garret Wilson wrote:
>  
>>> Funny, I thought that a similar line of reasoning was obvious for
>>> RDF/N3. Let's say that I have a "recipe" format that stores recipes for
>>> my recipe application. Or maybe I have a configuration file type for my
>>> operating system. If they were to have content types of
>>> application/recipe+rdf+n3 and application/config+rdf+n3, respectively,
>>> couldn't I edit them in a general RDF editor that could read N3, even if
>>> I didn't have MyRecipeApplication or MyOSConfigEditor handy?
>>>      
>
> Many years ago, my mathematical analysis tutor would say that if a statement was
> "obvious", then either it could be proven in three lines, or it was an
> assumption...   ;)
>  

I meant "obvious" in a similar light-hearted sense.

> With RDF, the distinction between different uses isn't crystalized in the same
> way.

I'm not sure I follow all the subtle distinctions you're trying to find
between the usability of +xml and +rdf+n3. RDF is more structured and
more self-consistent than XML will ever be; all I know is that I can
take any URF (a framework analogous to RDF) example from
<http://www.urf.name/> and dump it into
<http://www.guiseframework.com/demo/urfprocess> and explore its
structure using a dynamic tree control, regardless of the "different
uses" it might have. If I get an application/recipe+rdf+n3 file, and I
don't have the recipe plugin, it seems "obviously" :) useful to me to be
able to explore its structure. I can always download it if I want to.

Anyway, just an opinion.

Cheers,

Garret

[Dan Brickley-2]

Garret Wilson wrote:

>
> The following messages seems to be a good overview of some of the
> perceived problems with a text top-level MIME type:
>
> http://www1.ietf.org/mail-archive/web/ietf/current/msg36105.html
> http://www1.ietf.org/mail-archive/web/ietf/current/msg36149.html
>
> Of particular interest is the RFC 2046 requirement that all line breaks
> be CRLF, and that CR and LF not appear outside a line break sequence.
> This doesn't worry me so much---after all, "text/xml" seems to ignore
> this requirement (XML allows arbitrary CRs and LSs; see
> <http://www.w3.org/TR/REC-xml/#sec-line-ends>).

My understanding is that text/xml is widely considered problematic,
eg. http://annevankesteren.nl/2005/03/text-xml
http://www.w3.org/TR/xhtml-media-types/ quoting from
http://www.rfc-editor.org/rfc/rfc3023.txt

Dan

[Garret Wilson]

Dan Brickley wrote:
>
> My understanding is that text/xml is widely considered problematic,
> eg. http://annevankesteren.nl/2005/03/text-xml
> http://www.w3.org/TR/xhtml-media-types/ quoting from
> http://www.rfc-editor.org/rfc/rfc3023.txt

Tracking down exactly *why* text/* is considered problematic has been
difficult, at least for me, but I think it comes down to 1 ) default
interpretation by the browser, and 2 ) allowed/default encoding, which
you reference above.

 From RFC 3023 Section 3:

   The top-level media type "text" has some restrictions on MIME
   entities and they are described in [RFC2045] and [RFC2046].  In
   particular, the UTF-16 family, UCS-4, and UTF-32 are not allowed
   (except over HTTP[RFC2616], which uses a MIME-like mechanism).  Thus,
   if an XML document or external parsed entity is encoded in such
   character encoding schemes, it cannot be labeled as text/xml or
   text/xml-external-parsed-entity (except for HTTP).


Others (including your first reference above) have also mentioned that
the character set of all text/* entries defaults to US-ASCII if the
charset parameter is not supplied.

Now, if the quoted paragraph from RFC 3023 is true, then there's no more
argument---under no conditions should N3 use a text/* content type. But
I have trouble finding this explicitly in RFC 2045 or RFC 2046. RFC 2046
Section 4.1.2. *does* say that the default for charset "for 'text/plain'
data" is US-ASCII, but to me it is ambiguous whether this applies to
text/* subtypes as well.

I suppose that, with the popular understanding that RFC 2046 requires a
default character set of US-ASCII if there is no charset parameter, then
it's almost as true as if RFC 2046 said so explicitly. But that leads to
uncomfortable conclusions: if nothing but unadorned text should use a
text/* top-level type, and if all text/* top-level types default to
US-ASCII, then I can't think of a single use for the text/* top-level
type---not even for plain text, which should probably be
application/plaintext.

Can't someone just put out another RFC saying that text/* subtypes
besides text/plain may specify default encodings other than US-ASCII, or
something similar? Are we really stuck for the rest of computing
eternity with a specification decision that doesn't even support
Norwegian, much less Mandarin?

You and Graham are making a good argument (well, I guess I brought them
up too on this thread) that old specifications bring gotchas that would
prevent us from using a text/* top-level type for N3. But those reasons
have some larger ramifications which make me uncomfortable.

Garret

P.S. Arg---why do simple decisions have to be so difficult? Damn you,
US-ASCII!

P.P.S. I want a byte to be 32-bits too, while you're at it. ;)