On 20/01/11 18:11, Julie Allinson wrote:
I might be talking nonsense here, but is this something that could
support 'graceful' behaviour ... one thing I noticed in testing was that
EPrints will accept a METS package with epdcx but the deposit fails if
there is any other metadata instead of or in addition to the epdcx
embedded in the METS doc. I'm not criticising EPrints or advocating METS
but it struck me that if there is a package that could be deposited
knowing that it will succeed and that you could stuff all kinds of
things into it which the repository will either know what to do with and
do that (unpack etc.) or simply accept and store? ... so for the EPrints
case, you might need a new export plug, but in the meantime you could
still be making deposits.
EPrints does, indeed, expect epcdx in the <xmlData> section of the METS
data, however I have also found that EPints is much more relaxed about
the structure of METS/epcdx that DPspace is.... I've yet to find a
Fedora volunteer to try imports with ;-)
It is certainly possible to write an Importer for EPrints that will
accept whatever format you care to specify... and my experience is that
this is easier in EPrints than DSpace (but then again, I'm a Perl Monkey
:chuckle: )
Whilst on the subject of epcdx: I am swinging away from it now - there
are just so many things it doesn't do well, or misses out all together.
Perhaps this is an opportunity to get people from L&T, Data, Article,
and various other data-store types together, and try to come up with an
extensible core schema that can be both cross-platform as well as
cross-type?
--
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.
