Powered by OPF
OPF WIKI STATIC ARCHIVE
2,681 pages · 153 spaces · 776 tags · 4,025 history records · 96.2% of the original wiki recovered
Archived copy. This page was recovered from the Internet Archive snapshot of /pages/viewpage.action?pageId=36012145 taken on 2021-05-09. The original wiki at wiki.opf-labs.org is being decommissioned.

Hadoop-based Identification and Characterisation

Added by Sven Schlarb · last edited by Carl Wilson · on Dec 03, 2013

Goals

To make some of the most commonly used digital preservation format identification and characterisation tools Hadoop friendly. The aim is not to re-invent the wheel, existing code will be used where possible, but some of these existing projects would benefit from better documentation and working used cases on a public continuous integration service.

The starting tool list is:

One of the more general problems the group aims to address is the inefficiency of spawning native shell processes from Java. This has traditionally been the means of calling tools like file. This doesn't scale well for Hadoop processing, and existing mitigation strategies such as trying to batch shell processing, i.e. one call processed many files, aren't entirely satisfactory. The group will look at making JNA calls instead to make the process more efficient.

Another general issue is the lack of stream based processing for some tools. DROID, file, and ExifTool in particular require a file on which to operate rather than a stream. Again this is not efficient for many characterisation in situations where the content to be characterised is held within some kind of container format, e.g. zip or WARC files. In these cases it is more efficient to be able to read the stream from the container and characterise the stream, rather than having to serialise it to a new file.

A list of specific goals for each tool is presented below:

DROID

Performing DROID format identification on single streams is not always easy. Look at the nanite code, which addresses some these difficulties, document the use of nanite and provide an exemplar.

File

File suffers from two inefficiency issues, the need to create a shell sub-process and the requirement to operate on a file instance.

Tika

Tika is pure Java and provides a stream based API, shouldn't require additional work.

Exiftool

Commandline invocation (called from FITS) and requires a file instance.

FITS

Makes multiple command line calls on individual files, though is a Java application. Make more efficient by patching in fixes to the above tools.

Working plan