EPrints Technical Mailing List Archive

Message: #04666

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

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

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.

Cheers,

Richard

--

Richard Jones, 

Founder, Cottage Labs 
t: @richard_d_jones, @cottagelabs