...
Section | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Each <file> segment will be a the basis of a separate DOR/Hypatia Digital Object. This is an example where the atomistic model adds overhead (separate metadata and content objects) and an integrated object combining commonMetadata and genericContent could be considered.
Collection and Series objects
...
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. The following information is also contained in a CMnnn.txt file describing a specific disk image:
Note that a Media object has characteristics of
- an "item" -- it represents a unit of meaning and has content "parts" as separate objects
- a "set" -- it has object related to it as members ... should we consider a specialized relationship for this?
Sample of the starting lines of the .txt file describing the media object.
...
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 |
File objects
File objects are the node objects representing individual files. The atomistic model has these objects constructed as a parent (metadata) object and a child (content) object. Do we want to consider an integrated object combining commonMetadata and genericContent models instead?
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="20b8166b62b09740-57c36785-41d444fb-8b0586b7-d7b8bc44b8668d3a162add26"><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 | <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, e.g.,
...