W3C home > Mailing lists > Public > www-rdf-comments@w3.org > October to December 2007

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

From: Graham Klyne <GK@ninebynine.org>
Date: Sun, 04 Nov 2007 23:50:19 +0000
Message-ID: <472E5ABB.4060508@ninebynine.org>
To: Garret Wilson <garret@globalmentor.com>
CC: www-rdf-comments@w3.org

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
Received on Sunday, 4 November 2007 23:52:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 September 2012 14:16:34 GMT