doms:ContentModel_File

Extends [:DataModel/ContentModel_DOMS: doms:ContentModel_DOMS]

In DOMS, we have found it beneficial to separate the abstract concept of "Image" or "Audio" from the concrete implementations such as "jpeg" and "mp3". The descriptive metadata about the image will be relevant no matter the manifestation of the image, and as such should not reside along with the technical metadata about the manifestation. To support this separation, we have introduced the concept of File objects. For more details see DomsFileHandling.

A File object is an object, that contains a link to the file (in Bitstorage), and the technical metadata about this file. Only File objects are allowed to reference a file in Bitstorage. File objects must all have a Content Model that extends ContentModel_File.

Objects of ContentModel_File can have "doms-relations:hasOriginal" relations to other objects of "doms:ContentModel_File". If a file A is the result of a migration of file B and both are in Doms, the File A data object will have a "doms-relations:hasOriginal" relation to the data object for File B.

Objects of doms:ContentModel_File must have the datastreams "CHARACTERISATION", "CONTENTS" and "ORIGIN". Each of these deserve some description.

CONTENTS

"CONTENTS" is where the actual file is. It will always have the the "E" controlgroup, meaning that the file is externally referenced. The reference must always be to a File in Bitstorage, and only this datastream is ever allowed to reference files. The datastream itself is just an URL, but if you access it through [:Fedora_3.0_API#anchor_getDatastreamDissemination:"getDatastreamDissemination"] in the Fedora API-A, you get the contents of the file.

The CONTENTS datastream must contain a "<foxml:ContentDigest type="MD5" value=""/> element, with the correct checksum for the referenced file. Given that, we can ensure that the referenced file has not been altered by some other means.

Format URI

In order to perform proper digital preservation, we need to store the exact format of each file somehow. The National Archives, Great Britain, have developed the PRONOM scheme, http://www.nationalarchives.gov.uk/pronom For each file format, or version thereof, in the registry, they have a signature file, that enables their tool (DROID) to identify files of this type.

We selected PRONOM because they are currently able to identify all the relevant preservation file formats used in DOMS, and was the closest we could find to an uniformly accepted standard.

Fedora provide a way to store the format uri of datastream contents in the datastream header, in a tag called "formatURI". There exist, of course, a URI version of the pronom IDs, described in [http://www.nationalarchives.gov.uk/aboutapps/pronom/puid.htm] and [http://info-uri.info/registry/OAIHandler?verb=GetRecord&metadataPrefix=reg&identifier=info:pronom/].

As for validation, in the DS-COMPOSITE datastream, described in more detail in FedoraTypeChecking, you can place a number of <form FORMAT_URI="uri"/> tags. The validator requires that the datastream will have one of the thus specified format uris.

ORIGIN

This section depends on input from Elsebeth, so it is intentionally left blank.

CHARACTERISATION

When a file is uploaded to Bitstorage (see Bitstorage_API), it is automatically subjected to a series of characterisation tools. Aside from extraction the PRONOM ID, which should be stored in the "PRONOMID" datastream, they also extract a lot of other metadata. This metadata is highly dependant on the type of file in question, so parsing it in a general context is not feasable. Instead, a datastream has been made to hold it, so that it can be parsed at a later date, if the particular file becomes interesting.

There is no schema for the actual metadata. We have defined a schema for the containing structure. The metadata must be valid xml, but it does not need to be schema validated.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            targetNamespace="http://doms.statsbiblioteket.dk/types/characterisation/0/2/#"
            xmlns="http://doms.statsbiblioteket.dk/types/characterisation/0/2/#"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified">

    <xsd:element name="characterisation" type="characterisationType"/>

    <xsd:complexType name="characterisationType">
        <xsd:sequence>
            <xsd:element name="characterisationRun"
                         minOccurs="1"
                         maxOccurs="unbounded"
                         type="characterisationRunType"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="characterisationRunType">
        <xsd:sequence>
            <xsd:element name="tool" type="xsd:string" maxOccurs="1" minOccurs="1"/>
            <xsd:element name="formatURI" type="xsd:anyURI" maxOccurs="1" minOccurs="1"/>
            <xsd:element name="valid" type="xsd:boolean" maxOccurs="1" minOccurs="1"/>
            <xsd:element name="output" type="outputType" minOccurs="0" maxOccurs="1"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:complexType name="outputType">
        <xsd:sequence>
            <xsd:any namespace="##any" processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
        </xsd:sequence>
    </xsd:complexType>

</xsd:schema>

The characterisation datastream should look like this.

<c:characterisation xmlns:c="http://doms.statsbiblioteket.dk/types/characterisation/0/2/#">
    <c:characterisationRun>
        <c:tool>JHove</c:tool>
        <c:formatURI>info:pronom/fmt/42</c:formatURI>
        <c:valid>true</c:valid>
        <c:output></c:output>
    </c:characterisationRun>
</c:characterisation>

This datastream declares that the file has been characterized by the tool JHove, that the format of the file is info:pronom/fmt/42, and that the file is valid in regards to this format. In addition, there is an empty block of output from the characterisation program.