...
| Code Block |
|---|
| xml |
|---|
| xml |
|---|
| title | descMetadata for HypatiaFtkItem |
|---|
|
<mods:mods xmlns:mods="http://www.loc.gov/mods/v3">
<mods:titleInfo>
<mods:title>The Burgess Shale and the Nature of History</mods:title>
</mods:titleInfo>
<mods:location>
<mods:physicalLocation type="disk">CM005</mods:physicalLocation>
<mods:physicalLocation type="filepath">CM005.001/NONAME \[FAT12\]/\[root\]/BURCH2</mods:physicalLocation>
</mods:location>
<mods:originInfo>
<mods:dateCreated>n/a</mods:dateCreated>
<mods:dateOther type="last_accessed">n/a</mods:dateOther>
<mods:dateOther type="last_modified">10/20/1988 10:44:46 AM (1988-10-20 17:44:46 UTC)</mods:dateOther>
</mods:originInfo>
<mods:typeOfResource></mods:typeOfResource>
<mods:physicalDescription>
<mods:form></mods:form>
</mods:physicalDescription>
</mods:mods>
|
Mark Matienzo pointed me toward a good MODS reference (http://library.princeton.edu/departments/tsd/metadoc/mods
Image Removed) and I used that to include file created / accessed / modified dates, but there is no mods authority for "last_accessed" or "last_modified," I made those up. Is it worth establishing some controlled vocabulary here? (Maybe something like what Princeton did in the reference I've been using here: http://library.princeton.edu/departments/tsd/metadoc/mods/dates.htmlImage Removed) Is there a better place to include these?
| Code Block |
|---|
| xml |
|---|
| xml |
|---|
| title | contentMetadata for HypatiaFtkItem |
|---|
|
<contentMetadata objectId="hypatia:423" type="born-digital">
<resource data="metadata" id="analysis-text" objectId="hypatia:424" type="analysis">
<file format="WordPerfect 4.2" id="BURCH2" size="58715 B">
<location type="filesystem">files/BURCH2</location>
<checksum type="md5">0DDF3CB211DECC768500E008BD181949</checksum>
<checksum type="sha1">F93D649ED1DA6D3EDE0679DB1EF39490C6FDA4BE</checksum>
</file>
</resource>
</contentMetadata>
|
...
| Code Block |
|---|
| xml |
|---|
| xml |
|---|
| title | RELS-EXT for HypatiaFtkItem |
|---|
|
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="info:fedora/hypatia:423">
<isMemberOf xmlns="info:fedora/fedora-system:def/relations-external#" rdf:resource="info:fedora/hypatia:165"></isMemberOf>
<hasModel xmlns="info:fedora/fedora-system:def/model#" rdf:resource="info:fedora/afmodel:HypatiaFtkItem"></hasModel>
</rdf:Description>
</rdf:RDF> |
...
| Code Block |
|---|
| xml |
|---|
| xml |
|---|
| title | descMetadata for HypatiaDiskImageItem hypatia:165 |
|---|
|
<mods:mods xmlns:mods="http://www.loc.gov/mods/v3">
<mods:titleInfo>
<mods:title>CM005</mods:title>
</mods:titleInfo>
<mods:physicalDescription>
<mods:extent>5.25 inch Floppy Disk</mods:extent>
<mods:digitalOrigin>Born Digital</mods:digitalOrigin>
</mods:physicalDescription>
<mods:identifier type="local">CM005</mods:identifier>
</mods:mods> |
...
A HypatiaDiskImageItem has a payload file that we store in the "content" datastream of a FileAsset object. However, it also has several other files. Here you can see a datastream called "front" that contains a photo of the disk in question. If the back of the disk had also been photographed, there would also be a datastream called "back." I'm also planning to put the .csv and .txt files that FTK generates as datastreams here. That seems more appropriate (and easier) to me than handling them as separate FileAssets, but we may want to re-examine this in later phases of the project. 
Image Added
Image Added