> 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
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:45 UTC