On 19/01/2011 17:26, Richard Jones wrote:
Hi Ed,
On 19/01/11 13:27, Ed Summers wrote:
On Wed, Jan 19, 2011 at 6:28 AM, Richard
Jones<rich...@oneoverzero.com> wrote:
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).
Would it be too restrictive to require SWORD collections to only
support one package format? This would mean that there MUST be
one and only one sword:acceptPackaging per app:collection in the
service document. I think this would simplify matters significantly
for implementors since:
1) there would no longer be any need for the q attribute on
sword:acceptPackaging, and the requirement to interpret them.
2) X-Packaging header registration, and the need for clients to send
it would go away
2) a client could only retrieve a package in the format it was
deposited in. Does anyone really have an appetite for dynamically
rewriting package formats as part of an HTTP request cycle?
I think that would be overly restrictive, while the above gains are
relatively minimal in the scheme of things.
Also, as per my earlier comment about export plugins in EPrints, you
could easily imagine throwing a known package format into the
repository, and then asking it to give you it back in a variety of
formats that you don't know how to generate yourself.
I guess a better question is: do we have many SWORD implementations
that support POSTing multiple package flavors to the same collection?
Also, I am -1 on SWORD requiring a standard package format. I think it
would be fine to list some preferences, and light-weight, community
driven mechanisms for identifying them, but that's as far as SWORD
should go IMHO.
It's been a long standing complaint against SWORD that despite it
being an "interoperability" standard, you can't even deposit the same
package into DSpace, EPrints and Fedora, let alone other
implementations that weren't funded as part of the original project.
From both a practical point of view and a community perception point
of view this has to be addressed.
We have tried to work around the "standard" package format issue by
adopting an Atom Multipart [1] deposit of an Atom Entry with optional
embedded metadata plus a binary payload which may either be a single
file or if given the Content-Type of application/zip a plain old zip
file with no prescribed internal content. This ought to be
satisfactory because it is not only about the most simple format you
could come up with, but it also leverages the existing semantics of
AtomPub, so adding it is of minimal effort.
http://tools.ietf.org/html/draft-gregorio-atompub-multipart-04
I might be talking nonsense here, but is this something that could
support 'graceful' behaviour ... one thing I noticed in testing was that
EPrints will accept a METS package with epdcx but the deposit fails if
there is any other metadata instead of or in addition to the epdcx
embedded in the METS doc. I'm not criticising EPrints or advocating METS
but it struck me that if there is a package that could be deposited
knowing that it will succeed and that you could stuff all kinds of
things into it which the repository will either know what to do with and
do that (unpack etc.) or simply accept and store? ... so for the EPrints
case, you might need a new export plug, but in the meantime you could
still be making deposits.
Julie
Cheers,
Richard
--
Julie Allinson<julie.allin...@york.ac.uk>
Digital Library Manager
University Library& Archives, J.B. Morrell Library
University of York, Heslington, York, YO10 5DD, UK
tel: ++44 (0) 1904 324083 skype: j.allinson
web: http://tinyurl.com/dcd6a5
disclaimer: http://www.york.ac.uk/docs/disclaimer/email.htm
--
