 |
 |
Quality digital preservation software will ignore file extensions and file names for file type identification and use JHOVE or similar. Cheers Stuart On Tuesday, April 25, 2017, Benedikt Kroll <[log in to unmask]> wrote: > That would work, but I'm rather trying to find out whether digital > preservation softwares have problems with service-style URLs for bitstreams > in general. Because if that is the case, it could be relevant for the > further development of the (open source) repository software we are using. > > > > Am 24.04.2017 um 13:15 schrieb Andreas Orphanides: > >> Here's a silly idea that maybe runs the risk of rushing to a solution >> without actually addressing the core question... could you set up a proxy >> that provides a URL ending in the correct filename? >> >> On Mon, Apr 24, 2017 at 4:28 AM, Benedikt Kroll < >> [log in to unmask]> wrote: >> >> 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. >>>>> >>>>> >>>> -- -- ...let us be heard from red core to black sky