Assessment of file format testing tools - Jisc

More documents

Recommendations

Info

Digital Asset Assessment Tool – File Format Testing Tools -Version 1.2 – 2006-12-13 It recursively traverses a file directory and: • Associates external metadata with files • Calculates checksums automatically • Identifies the file format • Analyses the file content • Discovers relationships between files • Builds a METS 8 picture of the collection • Creates structural metadata for the collection The tool then goes on to create five types of ‘Empirical’ metadata – presumably, this means metadata associated with each individual digital object it finds. These types include things like fixity and MIME-types. It also uses JHOVE functionality, for example to perform validation. 4.4 Scoring with Empirical Walker To get results from the tool, you need to load it with the pre-determined information about the organisation and collection, as mentioned above. This includes information derived from the preservation policy; and a format-scoring matrix, which was used to help determine preferred file formats. The tool takes all the empirical metadata it has gathered from the directory, and compares it with the pre-loaded information, which enables it to give a score to each individual file. This is probably based on a comparison of ‘desired best practice’ for files and formats with a ‘snapshot’ of what’s actually in the drives. From a sophisticated comparison and calculation process, it arrives at a tiered scorecard which, when interpreted correctly, enables the organisation to identify its preservation needs. Moreover, these results would help identify levels of service appropriate to certain classes of objects, because Stanford’s extant evaluations had showed them that not all digital objects are the same, and some of them may require a level of service over and above simple bit preservation. 4.5 Conclusions Empirical Walker, if we can believe the claims made for it, seems to be a far superior tool to DROID or JHOVE, even though it uses JHOVE for some of its results. Our reasons for assuming this superiority: • It does more things – like calculating checksums and analysing file content • It understands the whole structure of a collection, and relations between files, are important too (this would appear to be a massive improvement on DROID, which works exclusively on a file-by-file basis, regardless of context or location) • It extracts / generates more metadata than either DROID or JHOVE The Stanford methodology may also be superior to D-PAS, in that: • It assumes that there is a workflow, not a static collection of digital objects • It integrates the automation of the assessment process with questions about the organisation and institutional policies, and does this more successfully than D-PAS • It delivers scored results based on the analysis of thousands of objects (not 400), compared against fixed matrix systems, which in turn are derived from hard facts about the nature of preferred file formats and local preservation strategies 8 METS: Metadata Encoding and Transmission Standard. See http://www.loc.gov/standards/mets/. 10
Digital Asset Assessment Tool – File Format Testing Tools -Version 1.2 – 2006-12-13 5. Using DROID, JHOVE or Empirical Walker as part of a D- PAS tool 5.1 Overview In theory, a D-PAS tool might be able to integrate with any of these file format analysis tools. If our project’s hierarchy model proves workable, then a file format analysis tool could integrate its results at the level we have determined as 'item'level. In particular, the way the D-PAS tool is currently built, a tool such as DROID or JHOVE would come into play at our ‘Level 5’, and its results would be applicable to Sections 8-11 of the questionnaire. This assumes that there are two parallel surveys going on: the D-PAS tool collecting the toplevel profile information about the organisation and its collections, with the file format tool gathering profile information on individual assets. At some point, the results from a top-down survey and bottom-up survey would have to find some connectivity to make such an exercise work. There are some fields in D-PAS Sections 8-11 where an overlap, if not an exact correlation, with DROID / JHOVE type information can be clearly seen. For example, the following D-PAS questions from Section 8: • ‘File format type and version’ • ‘Application (and version) used to create the asset’ • ‘Location metadata’ There remains a question as to how to automate the integration of the tools; whether results from DROID or JHOVE can be extracted and automatically imported into a D-PAS database, and have specific scores assigned to the results, thus adding to the final D-PAS score. The specific D-PAS questions on in Section 10 (File Formats) and Section 11 (Software) are slightly more complex. They are asking questions about the stability of formats, and the reliability of software, but phrased in such ways that DROID or JHOVE can’t really answer. If this integrated approach were to succeed, D-PAS would need a certain amount of reworking. 5.2 DROID integration with D-PAS In terms of adding an automated 'crawl and assess'feature to a D-PAS tool, we think DROID leaves a lot to be desired. DROID will do an automated crawl of all file formats in a drive, but it will only provide 'static'information on its format, based on whatever information is currently stored in PRONOM. Importantly, DROID isn't really looking 'inside'a file, just reporting on the extension. To put it bluntly, for all your files which end in .TXT, DROID will tell you exactly the same thing for all of them. In ULCC’s test, the sample of files included ‘non asset’ files with the extensions of, for example, HLP, BAK, INI, EXE. The reason for doing this is that these files may be used to access and read the digital data. The hardware environment also may be dependent on these files. If these files are missing or not safe, the asset is at risk. Unfortunately, DROID does not even recognise any of these system file types. Wherever possible we have commented on why we think they ought to be included in any tool used for risk assessment. DROID does not extract metadata from a file. This lack of metadata extraction may not be a problem for D-PAS. Metadata is useful overall for preservation, but it's not particularly germane to the risk assessment that D-PAS is meant to do. However, it is relevant to a risk assessment if there is no metadata available at all. In terms of output, DROID is capable of generating a .CSV file, so the results of a DROID survey could conceivably be integrated with a D-PAS-type database. 11
Page 1 and 2: Digital Asset Assessment Tool - Fil
Page 9: Digital Asset Assessment Tool - Fil
Page 13 and 14: File Format Assessment: DROID test
Page 15 and 16: Status File Comments Warning PUID P
Page 17 and 18: Status File Comments Warning PUID n
Page 23: Digital Asset Assessment Tool - Fil

Assessment of file format testing tools - Jisc

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?