EPrints Technical Mailing List Archive

Message: #08571

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

Re: [EP-tech] OAI2 deleted vs destroyed records

CAUTION: This e-mail originated outside the University of Southampton.

Thanks David,

Unfortunately, it looks like historically the destroy option has been available to the repository admins alongside the delete option, so we have quite a few where that option has been taken, though I think mostly they are not records that have ever been live, which is probably okay.  I have a feeling I might be changing the permissions on the destroy option in the near future…

 

I’ll check with our folks who deal with Primo as to whether they can do anything at their end of things with regards to how Primo treats those records (if it even sees them – it might not see the destroyed record if it’s harvesting a specific set).

 

Alan

 

From: <eprints-tech-bounces@ecs.soton.ac.uk> on behalf of "eprints-tech@ecs.soton.ac.uk" <eprints-tech@ecs.soton.ac.uk>
Reply to: "eprints-tech@ecs.soton.ac.uk" <eprints-tech@ecs.soton.ac.uk>, David R Newman <drn@ecs.soton.ac.uk>
Date: Thursday, 15 April 2021 at 16:04
To: "eprints-tech@ecs.soton.ac.uk" <eprints-tech@ecs.soton.ac.uk>, "Alan. Stiles" <alan.stiles@open.ac.uk>
Subject: Re: [EP-tech] OAI2 deleted vs destroyed records

 

CAUTION: This mail comes from outside the University. Please consider this before opening attachments, clicking links, or acting on the content.

Hi Alan,

If previously live records have been completely removed rather than retired then you can expect bad things to happen.  If there is a specific privacy issue that means the record cannot even been retained in a restricted form (retired), then removing may be the only option.  However, the need for this should be vanishingly small and therefore issues like you describe with Primo should be few a far between and may require manual intervention.

The error code idDoesNotExist is deliberately returned by EPrints OAI interface when a record is removed, as in effect the record never existed.  All I can suggest is that Primo should treat getting back idDoesNotExist the same as getting back an item that is marked as deleted.  Obviously, you may want to be a bit more careful about what to do when getting back idDoesNotExist, in case there is some error in the request that mangles the ID so it cannot be found.  I have no idea how Primo could be configured to do this but as far as I can tell EPrints is behaving as it should; reporting completely removed items as not existing whereas retired items are reported as 'Deleted'.

Regards

David Newman

On 15/04/2021 15:27, Alan.Stiles via Eprints-tech wrote:

CAUTION: This e-mail originated outside the University of Southampton.

Hi all,

I feel like there was a discussion about this here a year or two ago but I can’t find it now.

 

Records in our repository that get flagged as deleted show up in the OAI feed as ‘Deleted’, but records that get completely removed (destroyed) show up as error code ‘idDoesNotExist’.

 

It appears that Primo (our library search product) isn’t doing anything about updating records from the feed (configured within Primo to explicitly harvest our repository), at least where it’s getting the error response.

 

Any clues as to whether this is a Primo problem or my problem to sort out?

 

Cheers,

Alan



*** 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/