[EP-tech] Re: Some questions about SWORDv2/CRUD endpoint

Richard Jones richard at cottagelabs.com
Tue Sep 8 09:33:33 BST 2015

Hi Ian,

Thanks for the response ...

> > My sympathies: I spent about a month trying figure something like this
> > out, and just about got it working before I went on holiday for two
> > weeks... Now I'm back I'm struggling to recall the details.  I was
> > trying to push eprints XML and attached files into eprints via SWORD,
> > and kept running up against similar problems.  What I found was that
> > AtomPub only seemed to support minimal metadata - title, creator,
> > summary - but nothing else e.g. Journal.  I can imagine that in your
> > position as the Router, you don't want to have to be generating Eprints
> > XML - presumably you want to be sending generic Atom, and not having to
> > write native eprints XML?   Most of the documentation I found around
> > SWORD tended to be dSpace-centric, using DCTERMS for the extended
> > metadata.  I spent ages trying to adapt the EasyDeposit client , but
> > could never get it to pass the XML to the right interpreter.  In the end
> > I started from scratch with PHP-CURL and solved it quite quickly.
> Like Andy, I created my own importer for the Broker, and effectively did
> a SWORD 1.3-like import under the EPrints CRUD interface.
> The importer's in the EPrints Bazzar.... but being bespoke, isn't
> actually of any use.

I've taken a look at your plugin, and got some tips on how EPrints plugins
get loaded, thank you!  I'm separating the zip file deposit from the
metadata deposit so that the code will work on a generic repository (both
vanilla DSpace/EPrints - and anyone else supporting swordv2), so the key
sticking point is just how to load the Atom.xsl import plugin when a
deposit of content-type "application/atom+xml; type=entry" gets deposited.
All the bits look like they're in place in EPrints, but I'm clearly missing
a key connection somewhere in the code :)

Any tips on how to do that?  Basically, do you know how the XSLT import
plugin works?

> (I also considered that the multiple pushes needed for an average
> document wasn't going to scale - hence not following any rabbits down
> the CRUD hole..)

We're going down an intermediate route, with a metadata deposit followed by
a zip deposit, which deals with the scalability of not having to send every
file independently that you identified, but also enables metadata-only
deposit and allows us to get around having to make and maintain a plugin
for each repo.




Richard Jones,

Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20150908/76a089cd/attachment.html 

More information about the Eprints-tech mailing list