Born-digital collections present a challenge to traditional ways of describing content and making it discoverable. Disks, drives, directories, etc. may contain many thousands of files which would be difficult to describe in detail in an EAD. The approach described here starts with an EAD that contains only a single reference to the born-digital portion of a collection, expressed as a specific Series within the larger collection. The Forensic Toolkit (FTK) software is used to produce both disk images and related analysis files, plus detailed technical information about individual files on the media. The output of this process is augmented, transformed, and eventually translated into a set of digital objects in DOR (Stanford's Fedora-based Digital Object Registry) and shared objects for Hypatia. A separate process is used for converting the Collection EAD into metadata objects representing the full context of the born-digital and other materials, with links made between the containers and the detailed objects. |
|
Each <file> segment will be a the basis of a separate DOR or Hypatia Digital Object. The differences are:
The Collection and Born-Digital Series objects themselves are created first, ahead of FTK processing. All FTK processed materials for a collection are processed together and are members of the Born-Digial Series set. Media objects must be linked to the appropriate series via an isMemberOf relationship.
The FTK processing must first create a set of media objects representing the physical media (hard drive, diskette, etc) on which the files were found. This has been described as a view of the "unprocessed" collection, meaning it has not been processed down to the individual units of content, the separate files.
Note that a Media object has characteristics of
Sample of the starting lines of the .txt file describing the media object.
Created By AccessData® FTK® Imager 3.0.1.1467 110406 Case Information: |
Note that some of this information is repeated as header information in the file-level FTK report below.
From: Disk Image // CMnnn.001.txt |
maps to |
notes |
---|---|---|
Evidence Number: CM004 |
descMetadata |
Would correspond to EAD <c><unittitle> |
Evidence Number: CM004 |
descMetadata |
Would correspond to EAD <c><unitid> |
Notes: 5.25 inch Floppy Disks |
descmetadata |
Would correspond to EAD <physdesc> in a node describing the media. |
(implied) |
RELS-EXT |
A link to the Collection object |
(implied) |
RELS-EXT |
A link to the Series object |
identityMetadata – label = colleciton context...
File objects are the node objects representing individual files. The atomistic model would have these objects constructed as a parent (metadata) object and a child (content) object. For simplicity, we will create these File objects as a single object, combining the Hydra commonMetadata and genericContent models.
Sample of transformed FTK file available as input:
|
Information from: FTK xml // Report_transformed.xml |
maps to (within item objects) |
notes |
||
---|---|---|---|---|
<filename>BU3A5</filename> |
n/a |
this is the original file name as it appeared on the original media. |
||
<Item_Number>1004</Item_Number> |
n/a |
internal FTK reference only, to disambiguate references in the FTK report |
||
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="9a6c893d-9765-407e-bd38-1b861a15f0ed"><ac:plain-text-body><![CDATA[ |
<filepath>CM006.001/NONAME [FAT12]/[root]/BU3A5</filepath> |
|
location of file on original media |
]]></ac:plain-text-body></ac:structured-macro> |
<disk_image_no>CM006</disk_image_no> |
descMetadata |
This token, taken from the head of the <filepath>, is the only data link between the FTK output for a file object and the corresponding media object. We want a data link in descriptive metadata as well as an RDF link to the corresponding object. |
||
<filesize>35654</filesize> |
|
Could be used by conversion to compare against the file size as computed locally, a quick check prior to checksum validation? |
||
<filesize_unit>B</filesize_unit> |
|
Needed to correctly interpret <filesize>, if used |
||
<file_creation_date>n/a</file_creation_date> |
note? |
|
||
<file_accessed_date>n/a</file_accessed_date> |
note? |
|
||
<file_modified_date>12/8/1988 6:48:48 AM (1988-12-08 14:48:48 UTC)</file_modified_date> |
note? |
|
||
<MD5_Hash>976EDB782AE48FE0A84761BB608B1880</MD5_Hash> |
|
Used for checksum validation of a file during processing. This value will eventually be part of contentMetadata, but probably not as a value transferred from here. |
||
<restricted>False</Restricted> |
|
true=visible staff only, not discoverable .... Hypatia only |
||
<type>Books</type> |
descMetadata |
<typeOfResource>? <topic? or <genre>? authority? |
||
<title>The Burgess Shale and the Nature of History</title> |
descMetadata |
|
||
<filetype>WordPerfect 4.2</filetype> |
descMetadata |
|
||
<Duplicate_File> </Duplicate_File> |
|
* blank, null value or empty string - file is unique in collection, no duplicates |
||
<export_path>files\BU3A5.wp</export_path> |
|
The file as saved by FTK for further processing. |
||
(implied) |
RELS-EXT |
A link to the Media object |
(1) Location/container information -- for every file object created, create a <mods:location> description that places the resource in the context of the collection by combining collection name, intermediate series/group/etc name(s), and the ID+description of the media on which the file resides:
<location>collection-title - series-title - media-title (media-description)</location
e.g.,
<location>Stephen J. Gould Papers - Series 6: Born Digital Materials - CM006 (5.25 inch Floppy Disks)
Use this concept for objectLabel?