[sword-app-tech] Multiple deposit / reference deposit.

[Jim D. <jim...@po...>]

Hi all,

A number of the SWORD project folks attended a JISC repository
infrastructure workshop yesterday. A couple of the use cases that kept
cropping up as important were a) multiple deposit of a package b)
deposit of package to one repository and deposit of metadata /
reference in other repositories. Richard J and myself started to
wonder whether SWORD supports these use cases well enough.

There are two parts of the spec that are pertinent here. Firstly
there's the URL of the member entry returned from a creating post as
described in SWORD section 5.3. As we concluded in Tuesday's
discussion, the /atom:entry/atom:content/@src URL is also essential,
and I think we consequently need to review SWORD section 9.6,
particularly:

"According to APP, The Media Link Entry MUST contain an <atom:content>
element with a src attribute containing a URI for the deposited Media
Resource (the deposited package). For SWORD implementations, this URI
SHOULD identify the original deposited package. It MAY dereference to
the package. "

The reason this is important is in the use case where you want to
deposit a package and then pass a reference to the data to other
repositories. In the case where deposited data goes through a workflow
(e.g. editorial review), it is unlikely that the URI reported at point
of deposit will be the 'official' URI. I  suggest that the content
source URL should resolve (perhaps through redirection) to a
representation of the data. This allows systems to support this
reference mechanisms without having to repackage the data.

The second issue revolves around the idea of giving the deposit
process (rather than the deposited data) an identifier. Let's say it's
a urn:uuid for the sake of argument just now. The point of this is to
enable de-duplication or association of equivalent content at a later
date. At the moment, we use the Slug header for this purpose (section
9.7), and suggest that the value should be used as the atom-id. On
reflection, I'm not sure I like this much - it contradicts the AtomPub
stated purpose of the Slug header, and using it in this way would
break atom:id, which is required to be universally unique identifier
for the *entry* (one unique deposit process might result in several
atom entries in different systems).

A potential solution is to invent another new HTTP header to contain
it, and an isomorphic XML element the value should be put in. It would
be possible to avoid the use of such a header using the recent AtomPub
multipart RFC. In addition, we might specify an RDF predicate and a DC
metadata field that should be used to store the deposit UUID.

Thoughts on any of this?

Best regards,
jim