I definitely did have the EasyDeposit client working at a basic level at one point - I can see the ePrint items where I was getting Title, Creators, Abstract to insert correctly.  Unfortunately I can't reconstruct the state of the system at that point.  I can see the atom manifest that was sent, but not what the headers were.

As far as I understand it the atom was being handled initially by AtomMultipart.pm, and at the time I couldn't work out were it went from there, because I never spotted Atom.xsl lurking in XSLT/ - now it makes slightly more sense.  Do you perhaps need to be invoking AtomMultipart first? 

Sorry to be a bit vague, but this was my first attempt at Eprints internals, and it's a comfort to know that it wasn't just me being a newb - it's dark in there!

Andy

>>> Richard Jones <richard@cottagelabs.com> 08 September 2015 09:21 >>>

Hi Andy,

Thanks for your email, very useful.

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.

So, did you manage to get the sword endpoint to take generic atom, even with just those basic fields? This is the bit that I'm currently stuck at, but if I could get it working, I'd be in a good position.

Right now I'm sending an atom entry document with both generic atom and embedded dc metadata, and I can see that there's an XSL file here that should deal with it:

perl_lib/EPrints/Plugin/Import/XSLT/Atom.xsl

Problem seems to be, though, that this XSL file isn't being picked up as a viable import plugin for my deposit, and I can't tell why. If you were able to import some basic atom metadata, that means there's hope for me here :) Do you recall having to set any configuration to get this to work?

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.

When you say the "right interpreter", do you mean the EPrints import plugin? I guess that's the same problem I'm having. If the Atom.xsl can be run over the incoming XML, then actually it would be easy in EPrints to customise that file for supporting arbitrary embedded metadata.

Perhaps there's an EPrints dev on the list who can tell us a bit more about how the XSLT import plugins work/get loaded?

Not sure if this will help with your problem, Richard, but it might give some help to somebody. Here's a basic test rig that works for me (unless I've broken it while tidying it up for public consumption )...

Just snipping the key bits...

$pkgheader=Array('X-Packaging: http://eprints.org/ep2/data/2.0',
'Content-Type: text/xml',
'Metadata-Relevant: true',
'X-Verbose: true' ,
'In-Progress: true');

So you found you had to specify both the Packaging and the Content-Type to get the right importer to load?

As I say, this might not be quite the problem you're trying to solve, but it was the only way I could get it working for a similar situation. It suited me because I already had the code to generate the EPXML.

Looks like you're battling with similar things, thanks for the input. I feel hopeful that if we can figure out how the default Atom importer can work, that would be a bonus for everyone wanting to use Sword/EasyDeposit against EPrints.

Cheers,

Richard

>>> Richard Jones <richard@cottagelabs.com> 29 August 2015 12:09 >>>

Just a little more information ...

I've found an Atom.xsl stylesheet in EPrints/Plugins/Import/XSLT which seems to imply that there /is/ a default atom import plugin. My sword deposit contains atom metadata, so this stylesheet should work nicely to create a new eprint with the relevant metadata. The only thing is, it doesn't appear to get called during deposit. In Eprints/Apache/CRUD.pm, there's this code (Line 762 in sub import_plugins):

my @plugins = $self->repository->get_plugins(

type => "Import",

can_produce => $self->accept_type,

%params,

);

In this code can_produce actuall gets dataobj/eprint, which I think is correct, but I can't work out what %params contains. It ought to contain application/atom+xml; type=entry I'm finding it difficult to trace this through the code to find out where it is set and what it should contain.

Cheers,

Richard

and it's being called with an accept_type of "application/atom+xml; type=entry". My guess is that the Atom.xsl stylesheet is not being understood as the plugin which can handle this format.

I read through this documentation:

http://wiki.eprints.org/w/Import_and_Export_Plug-ins

And it appears to suggest that the XSLT plugins need a wrapper around them for the specific mimetype that they need to work with - is this right? Or is there some way to get the XSLT import plugin to run as is?

If there's some other documentation that I've overlooked so far, any links much appreciated!

Cheers,

Richard

On 28 August 2015 at 09:50, Richard Jones <richard@cottagelabs.com> wrote:

Actually, I see an AtomMultipart.pm in the EPrints/Plugin directory, and it in turn tries to load a plugin which supports application/atom+xml, but I can't find a plugin that supports that particular format. I think this is probably the same issue, then, as my (1) below - there doesn't appear to be a default atom plugin - is that right?

Cheers,

Richard

On 28 August 2015 at 09:32, Richard Jones <richard@cottagelabs.com> wrote:

Hi Folks,

We're currently working on a new version of the Jisc Publications Router, and am looking into how best to put the content into an EPrints via SWORDv2. I'm encountering a few oddities, though, and I wonder if someone can clarify how that endpoint works for me?

1/ Posting an atom entry document to /id/content should result in the creation of a new eprint populated with the metadata from that document, but instead it creates an eprint with no metadata and the atom xml attached as a file called "main.bin". Perhaps I'm missing some crosswalk configuration?

http://swordapp.github.io/SWORDv2-Profile/SWORDProfile.html#protocoloperations_creatingresource_entry

2/ My service document says:

<acceptPackaging>http://purl.org/net/sword/package/Binary</acceptPackaging>

But when I PUT a file of this format tot he media resource I get a "package format not supported" error.

Also, it does not say that it supports SimpleZip, but if I PUT a SimpleZip it works fine. Is there a place that I can customise the accept/acceptPackaging entries in the service document?

3/ Completing deposit doesn't appear to work. When I POST to the eprint's Edit-IRI, I get a 405 Method Not Allowed, but it should update the eprint

http://swordapp.github.io/SWORDv2-Profile/SWORDProfile.html#continueddeposit_complete

Looking at the code, with my limited Perl skills, it looks like the full SWORDv2 protocol is not supported - is there some documentation that will tell me what features are supported? For example, does multipart deposit work? http://swordapp.github.io/SWORDv2-Profile/SWORDProfile.html#protocoloperations_creatingresource_multipart

Any tips/pointers much appreciated.

Cheers,

Richard

--

Richard Jones,

Founder, Cottage Labs

t: @richard_d_jones, @cottagelabs

w: http://cottagelabs.com

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/

--

Richard Jones,

Founder, Cottage Labs

t: @richard_d_jones, @cottagelabs

w: http://cottagelabs.com

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/

--

Richard Jones,

Founder, Cottage Labs

t: @richard_d_jones, @cottagelabs

w: http://cottagelabs.com

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/

--

Richard Jones,

Founder, Cottage Labs

t: @richard_d_jones, @cottagelabs

w: http://cottagelabs.com

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/

--

Richard Jones,

Founder, Cottage Labs

t: @richard_d_jones, @cottagelabs

w: http://cottagelabs.com

*** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
*** Archive: http://www.eprints.org/tech.php/
*** EPrints community wiki: http://wiki.eprints.org/
*** EPrints developers Forum: http://forum.eprints.org/