---------- Forwarded message ---------- From: Richard Jones <rich...@oneoverzero.com> Date: 20 January 2011 00:28 Subject: Re: content negotiating for package formats To: Scott Wilson <scott.bradley.wil...@gmail.com> Cc: Ian Stuart <ian.stu...@ed.ac.uk>, techadvisorypa...@swordapp.org
On 19/01/11 10:16, Scott Wilson wrote: > > On 19 Jan 2011, at 10:05, Ian Stuart wrote: > >> On 19/01/11 09:49, Scott Wilson wrote: >>> >>> I would suggest SWORD is completely agnostic on the subject of >>> packaged content formats, but that the SWORD implementation community >>> make a concerted effort to identify and support a common core of >>> packaging and metadata formats so that there is practical >>> on-the-ground interoperability with a reliable default format for >>> client implementations to support out-of-the-box. >> >> Bearing in mind that I have my tongue embedded firmly in my cheek here... > > Oh good! > >> I have an excellent content package that will either work with binary data >> directly included or passed-by-reference, and I am working on Importers for >> DSpace& EPrints as we speak... as outputs of the OA-RJ Broker work. > > I suggest we standardise on a really crappy packaging format with almost zero > features, combined with a totally inadequate metadata schema. At least that > way it might actually work.* > I think we're talking slightly cross-purposes here. The problem with the content negotiation is in when the client /retrieves/ its content from the sword server, not when it deposits it. >From a deposit point of view we have the acceptPackaging field in the service document, which tells the client what formats the server will support the deposit of, and there is the (X-)Packaging header which tells the server what the client has given them. The default (standard?) format that we're recommending for SWORD is a plain old zip file, optionally augmented with dc embedded in an atom entry sent along with it, which is very much in-line with the AtomPub spec (and also fits your criteria above :) ) The problem is when the client is trying to retrieve content from the server, and wants to ask for it in a particular format via content negotiation. At the moment, there is no provision in HTTP Accept- headers to ask the server for a METS package. We've had a few discussions in the past about "supporting" some formats, and they always end up pretty divisive. So SWORD is aiming to be totally agnostic on the point, but it does need to provide the client and server a mechanism to negotiate over what format they are interchanging. If we can achieve that, that will be relatively useful in an interoperability setting, I think, particularly as many SWORD servers (particularly repositories) are able to create dissemination packages in a large number of formats (see EPrints export plugins for example). I don't want us to decide, therefore, on a package format, but on a mechanism by which a client and server can get together and negotiate one for themselves. Cheers, Richard >> On a serious note: yes - the transport mechanism should be agnostic to the >> content... unless one wants to define a content transfer mechanism rather >> than a transport mechanism :) >> >> -- >> >> Ian Stuart. >> Developer: Open Access Repository Junction and OpenDepot.org >> Bibliographics and Multimedia Service Delivery team, >> EDINA, >> The University of Edinburgh. >> >> http://edina.ac.uk/ >> >> This email was sent via the University of Edinburgh. >> >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> > > > * http://en.wikipedia.org/wiki/Worse_is_better ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
