EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #08569

< 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

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/