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 <[email protected]>
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.
