 |
 |
So this happend when trying to ingest a file to the longterm archive from a repository: The repository's bitstream URL for a PDF file did not end on .pdf, but the mimetype was sent correctly. So the URL looked like https://test/bitstream/id/123456 The preservation system (a commercial product) did not accept this bitstream URL as part of an OAI harvesting response. The error message was that the bitstream URL must contain a valid file name and must end with an extension according to its mime type. So the expected URL would need to look like https://test/bitstream/123456.pdf This would mean that using this preservation system, we will not be able to harvest from a repository that uses service endpoints, not regular file links to deliver bitstreams. I'm trying to find out whether it is common behaviour for preservation systems to require file URLs rather than service URLs to ingest bitstreams. Any experience on how preservation software you use handles this detail would be appreciated! Thanks! Benedikt Am 21.04.2017 um 18:46 schrieb Cary Gordon: > Could you be a bit more specific about the issue you encountered? > > Thanks, > > Cary > > Cary Gordon > The Cherry Hill Company > http://chillco.com > >> On Apr 21, 2017, at 12:53 AM, Benedikt Kroll <[log in to unmask]> wrote: >> >> We run into a situation where this occured, and I'm trying to find out what other preservation software also do this – and if so, maybe also get to know why this check is done.