Re: application/rdf+xml Media Type Registration [DRAFT]

At 01:59 PM 3/22/02 -0600, Aaron Swartz wrote:
>Here's a first draft (in plain text and XML) of the Internet-Draft
>(RFC-to-be) for registering the application/rdf+xml media type.
>  - Aaron

Looks good... some comments.


>               application/rdf+xml Media Type Registration
>                    draft-swartz-rdfxml-mediatype-00

Suggest use:  draft-w3c-rdfcore-rdfxml-mediatype-xx.txt

(I'm thinking this may get higher IESG/IANA/RFC-editor attention when going 
for publication/registration.)


>Table of Contents
>
>    1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   3
>    2. application/rdf+xml Registration . . . . . . . . . . . . . . .   4
>    3. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . .   6
>    4. Historical Considerations  . . . . . . . . . . . . . . . . . .   7

Suggest include an IANA considerations, along the lines of:

x. IANA considerations

This document calls for registration of a new MIME content-type, according 
to the registration template in section 2.

>    5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .   8
>       References . . . . . . . . . . . . . . . . . . . . . . . . . .   9
>       Author's Address . . . . . . . . . . . . . . . . . . . . . . .   9
>       Full Copyright Statement . . . . . . . . . . . . . . . . . . .  10



>1. Introduction
>
>    RDF is a language designed to support the Semantic Web, by
>    facilitating resource description and data exchange on the Web.  RDF
>    provides common structures that can be used for interoperable data
>    exchange and follows the W3C design principles of interoperability,
>    evolution, and decentralization.
>
>    While the RDF data model can be serialized in many ways, the W3C has
>    defined the RDF/XML syntax [1] to allow RDF to be serialized in an
>    XML format.  The application/rdf+xml media type allows RDF consumers
>    to identify RDF/XML documents so that they can be processed properly.
>
>    It is important to note that RDF language is used to transmit
>    meaningful information, and thus has the same legal status as
>    assertions, in say, English would.

I strongly suggest dropping this last paragraph.  If there's anything 
likely to snarl up approval through IETF/IESG/IANA processes, I think this 
is it.  And it's not necessary to make this point for registering the 
content type.


>2. application/rdf+xml Registration
>
>    This is a media type registration as defined in Multipurpose Internet
>    Mail Extensions (MIME) Part Four: Registration Procedures [3]
>
>       MIME media type name: text

Don't you mean "application" ?

(I really think text is wrong here:  that media type is meant to be for 
human readable text -- it is now generally felt in MIME circles that 
text/html is an error.  RDF is an order of magnitide less readable to 
(non-technical) people)

>       MIME subtype name: rdf+xml
>
>       Required parameters: none
>
>       Optional parameters: charset
>
>          Same as charset parameter of application/xml as specified in
>          [5].
>
>       Encoding considerations:
>
>          Same as charset parameter of application/xml as specified in
>          [5].
>
>       Security considerations:
>
>          Security considerations include many of those described in
>          section 10 of [5] and more, due to the semantic nature of RDF.
>          RDF documents may make assertions about anything, and thus RDF-
>          based systems want to be certain that they can trust the
>          document.  It is expected that future work with Digital
>          Signature and "Web of Trust" will make it more clear how to
>          build secure RDF systems.
>
>       Interoperability considerations:
>
>          For maximum interoperability it is recommend that RDF files use
>          the Basic (un-abbreviated) RDF Syntax, since this is most
>          likely to be understood by RDF parsers and remain stable
>          through future RDF specifications.  It is also recommended that
>          RDF documents do not use processing instructions, as RDF
>          parsers give no meaning to them.

I don't recall the distinction between basic and abbreviated RDF syntax 
surviving into the latest syntax draft.  Further, I think it would be a 
mistake to propagate this preference, as the abbreviated syntax is, IMO, a 
bridge between "traditional" XML and RDF and makes it much easier to 
achieve deployment of RDF use in real-world applications.

>       Published specification: see [1]
>
>       Applications which use this media type:
>
>          RDF is device-, platform-, and vendor-neutral and is supported
>          by a wide range of Web user agents and authoring tools.
---------------^^^^

The anti-marketeer in me thinks that "wide" should be dropped.


>       Additional information:
>
>          Magic number(s): none
>
>             Although no byte sequences can be counted on to consistently
>             identify RDF, RDF documents will have the sequence "http://
>             www.w3.org/1999/02/22-rdf-syntax-ns#" to identify the RDF
>             namespace.  This will usually be towards the top of the
>             document.
>
>          File extension(s): .xrdf, .rdf
>
>          Macintosh File Type Code(s): "TEXT"

Do you mean "text"?  (I don't know, just checking.)

>       Person & email address for further information:
>
>          Aaron Swartz <me@aaronsw.com>
>
>          @@ some w3t person? danbri?

I think a w3t contact might be appropriate here.

>       Intended usage: COMMON
>
>       Author/Change controller:
>
>          The RDF specification is a work product of the World Wide Web
>          Consortium.  The W3C and the W3C RDF Core Working Group have
>          change control over the specification.

Hmmm... for longevity, I'm wondering about the appropriateness of saying 
RDFcore WG here.  Just commenting.


>3. Fragment Identifiers
>
>    Section 4.1 of the URI specification [4] notes that the semantics of
>    a fragment identifier (part of a URI after a "#") is a property of
>    the data resulting from a retrieval action, and that the format and
>    interpretation of fragment identifiers is dependent on the media type
>    of the retrieval result.
>
>    However, in RDF, the thing identified by a URI with fragment
>    identifier does not bear any particular relationship to the thing
>    identified by the URI alone.  This contradicts some readings of the
>    URI specification [4], so caution is recommended when creating new
>    RDF terms which use fragment identifiers.

s/contradicts/differs from/
s/caution/attention/

(just a reprise of a previous debate ;-)

>    The rdf:ID and rdf:about attributes can be used to define fragments
>    in an RDF document.


>4. Historical Considerations
>
>    This media type was reserved in [5], saying:
>
>       RDF documents identified using this MIME type are XML documents
>       whose content describes metadata, as defined by [RDF].  As a
>       format based on XML, RDF documents SHOULD use the '+xml' suffix
>       convention in their MIME content-type identifier.  However, no
>       content type has yet been registered for RDF and so this media
>       type should not be used until such registration has been
>       completed.


>    [6]  <http://www.w3.org/2001/03mr/rdf_mt>

In due course, I think this reference should be expanded to include author, 
title, etc.

>    [7]  <http://xml.resource.org/>
>
>
>Author's Address
>
>    Aaron Swartz
>    AaronSw.com
>    349 Marshman
>    Highland Park, IL  60035
>    USA

It's normal for people not to put personal addresses as part of their 
contact details:  name, optional organization and email address is 
enough.  (I mention this because it may not be wise to put a personal 
postal address in a very visible public document.)  (I'm assuming that is a 
personal address.)

>    Phone: +1 847 432 8857
>    EMail: me@aaronsw.com

....

And finally, I'd suggest we go for an initial Internet-draft publication of 
this as soon as the WG is happy with it.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Saturday, 23 March 2002 05:25:10 UTC