- From: Danny Ayers <danny666@virgilio.it>
- Date: Thu, 20 Nov 2003 19:39:26 +0100
- To: "Patrick Stickler" <patrick.stickler@nokia.com>
- Cc: <www-rdf-interest-request@w3.org>, "Graham Klyne" <GK@ninebynine.org>, "Jim Hendler" <hendler@cs.umd.edu>, "Dan Brickley" <danbri@w3.org>, <www-rdf-rules@w3.org>, <www-rdf-interest@w3.org>
> Well, what happens when that description is available in RDF/XML, > N3, N-Triples, XTM, HTML, etc.??? > > Do we have a parallel set of mime types, such that for any mime type > x/y we have x/y-description? > > Or do we just forbid any other encoding than RDF/XML? > > I don't find either option the least bit appealing. It would only be needed for the description in RDF, so that only means around 3 extra mime types. This has to be weighed against reconfiguring the web. > It's really just a variant of the URI-suffix approach. E.g. append > _META or such to the end of any URI to get the URI that denotes its > metadata description. Yes, as is MGET, except there the switch is shunted even further back into the machinery. I agree this looks on the surface a more elegant approach, but if the current web can be used without breaking anything, then I think that should be the preferred approach. (I don't think anything gets broken with the mimetype approach, the description can be considered just another representation of the identified resource). > > I'd be grateful for an example of how this is different with MGET, it > > sounds > > like there's something I'm not grokking here. > > > > See above. I.e. a description can have multiple representations... Ok, so perhaps the mimetype approach isn't the best, but I still hold out hope for an approach that doesn't need lowish-level rewiring. > Maybe the above comments, then, were useful to that end. I'm certainly clearer about the issues, so thanks for that. Cheers, Danny.
Received on Thursday, 20 November 2003 13:47:22 UTC