> I don't think you can ever get away from a degree of content negotiation, > but it doesn't necessarily need to be as complex as the scenarios outlined > depending on what agreements you can have for common formats in common > cases.
I agree with Graham and Scott. Please can we step back and clearly and completely define the scope of the issue. My understanding is as follows: There are two dimensions of content type -- packaging (eg zip, bagit, tar, mets,...) and metadata (dc, mets, ore, ead, ...) and it is not feasible to specify all of the combinations as unique keys. These combinations are used to both deposit and retrieve content packages. Client to Server (Deposit): * There is a recommended packaging format (Zip + DC in Atom) * There is a header to inform the server which packaging format is actually being sent, as well as the metadata format * There is information available as to the types of format the server will accept (in the Svc Desc) Server to Client (Retrieve): * There SHOULD be the same recommended packaging format. If a client can construct it, then it can likely read it back again. Requiring a different format just doubles the work. * There is a header to inform the client which packaging format is being sent, as well as the metadata format * There is information available as to the types of format the server can send (in Svc Desc) which may not be the same as the set of formats it will accept for deposit. * There SHOULD be a header to request a particular format. Now, call me a heretic, but I think Packaging is the wrong way round. The outermost layer is the top level content type, and hence should be in the Accept and Content-Type headers. If you download a zip file containing 5 plain text files, Content-Type is application/zip. So what is really needed is Accept-Metadata and Content-Metadata, to request the format of the metadata in the response package. If the server can't deliver the combination, then it won't do that. The same way that if you ask for Accept-Language: fr and the server can't deliver French then it won't. I disagree with Ed that there MUST be only a single format. That's never going to fly with current workflows, and would result in the "interoperability" of OAI-PMH's use of simple DC ... to wit, that there is syntactic interoperability, but the semantics are completely worthless due to people stuffing random content into fields because they can't say what they really mean. The Linked Data effort has shown us that even in an open world of infinite vocabularies, people *will* self-organize into support of useful relationships, and the same should apply here. Rob
