- From: Dan Connolly <connolly@w3.org>
- Date: Thu, 10 May 2001 10:04:14 -0500
- To: Graham Klyne <Graham.Klyne@Baltimore.com>
- CC: w3c-rdfcore-wg@w3.org
Graham Klyne wrote: > > At 05:07 AM 5/3/01 -0500, Dan Connolly wrote: > >In those cases, one option is to use application/xml or > >application/octet-stream or whatever. > >[...] > Interesting idea, but... > > I'm not absolutely sure about this, but I think this goes against the > spirit of the MIME spec. (I.e. using the MIME type to actually modify the > semantics of the content; I know this happens in practice to some extent, > but my understanding of the MIME content-type design was that it is > intended to be used at the level of choosing a suitable processor for the > content, and that the MIME type information would not necessarily be passed > to the receiving application.) _Modify_ the semantics? The media type *tells* you the semantics, no? After all, "choosing a suitable processor for the content" provides the "real-world connection" ala... [[[ The semantics of anything on the SW are then defined either in terms of more stuff on the SW, or in terms of the connection with these real-world connections. ]]] -- Interpretation and Semantics on the Semantic Web http://www.w3.org/DesignIssues/Interpretation Tue, 18 Jan 2000 20:03:25 GMT > If you want to pursue this, I could ping > one of the MIME authors and get a view on this. I certainly do want to persue this. But the MIME spec has been around long enough that its meaning is as much defined by the way it's understood and practiced in the community as by what the MIME authors think. But I'm happy to have their view on this issue if it's convenient. > [Later] > > I just realized that this "MIME-dependent semantics" is already with > us... in the fragment identifier interpretation, so I guess this isn't > really an issue. I'll think about it. for backlinks: http://www.w3.org/2000/03/rdf-tracking/#mime-types-for-rdf-docs -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Thursday, 10 May 2001 11:04:27 UTC