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
