- From: Graham Klyne <GK@ninebynine.org>
- Date: Sun, 04 Nov 2007 23:50:19 +0000
- 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 UTC