
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EP-tech] Merging two eprints using 'succeeds'



Hi,
I'm trying to work out how to thread two eprints so that I can merge the Accepted Manuscript record with Final published version, given that I have two separate systems feeding into the repository -  one feeding Manuscripts, one harvesting published metadata from PubMed etc.  I've looked at what happens when you create a linked new version of a record, with the <succeeds> set on the new record, and <metadata_visibility> set to no-search  on the old one. I'm in the slightly different position of wanting to merge two records once they are in the repository, but it seems like those are the fields I need to tweak.  I've looked at the code in https://github.com/eprints/eprints/blob/3.3/perl_lib/EPrints/DataObj/EPrint.pm 
to see the various in_thread manipulation functions, and can just about follow them.  

What I can't find is an admin utility that says 'Merge these two records, making this one the version of record, and retaining that one as an earlier version.'  Am I not looking hard enough?

What I might also want to do is to trigger this from the external systems, via SWORD, sending a couple of minimal XML packages to modify each of the records:

<?xml version="1.0" encoding="UTF-8"?>
<eprints xmlns="http://eprints.org/ep2/data/2.0";>
( file:///C:/Users/EADMAREI/Downloads/lshtmtest-eprint-991329.xml#) <eprint id="http://blah.ac.uk/id/eprint/991329";><eprintid>991329</eprintid><succeeds>		 991328</succeeds></eprint></eprints>
and likewise for the <metadata-visiblility> on the old record**
Does that seem like it ought to work?  It seems too easy.  Am I missing deeper layers of subtlety that are going to get corrupted by my naive approach.
Also, the eprint id is given twice in a standard eprint XML export, as per the edited code above.  Is it necessary to have both to trigger an update correctly?
Andy Reid
** (I say 'old record' but in reality the published versions may arrive before the manuscript versions, which depend on the authors sending them and us having the resources to process them ;-/ )

Andy Reid
Research Information Manager
Room G43, Executive Office
London School of Hygiene & Tropical Medicine
Keppel St
LONDON WC1E 7HT
+44 020-7927-2618
http://orcid.org/0000-0002-2500-2980


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20150921/b65354ad/attachment-0001.html
https://www.eprints.org/eptech/msg05187.html
www.eprints.org
crawl=CC-MAIN-2021-39
5700
application/http; msgtype=response
sha1:7SVUG3GTNO5ZX4FO647SDNCSVNYH4QKR
<urn:uuid:06ddb411-aa78-49c5-84c0-9400fc24c6d4>
2021-09-22T00:03:31Z
46.22.140.106
text/html
sha1:YF34PLTUUESGVST3SGJZFJ5GTU3YH6JE
<urn:uuid:149fa6c2-59df-45d4-a4c5-4ebd07e7fa63>
https://www.eprints.org/eptech/msg05187.html
response
<urn:uuid:54534103-611e-4c9e-b06a-5fbc95956257>
isPartOf: CC-MAIN-2021-39
publisher: Common Crawl
description: Wide crawl of the web for September 2021
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-22
software: Apache Nutch 1.18 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.2-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/