1. MODS will be the native descriptive metadata scheme.

2. The Workflow Management System (WMS) will map MODS to other identified schema which will include Dublin Core, Marc, MPEG-7 and others.

3. Dublin Core (DC) will remain an integral part of our architecture, and, in fact, is mandatory to be a compliant OAI data provider. (This capability is built in as part of Fedora and as a result, Rutgers records could be exposed via OAI-PMH at any time).

4. The Dublin Core type vocabulary will be used to describe the high level behavior of a digital object. Although this vocabulary is not perfect, it comes close to what is needed and can be locally augmented. From a standards perspective, the vocabulary consists of the following terms: collection, dataset, event, image, interactive resource, service, software, sound, text, physical object, still image, and moving image.

5. In addition to MODS, the Dublin Core unqualified descriptive metadata will be maintained as part of the architecture, primarily for OAI harvesting, however, it may be needed for other projects.

6. The WMS will provide the mapping between metadata schemes. However, the initial efforts will be focused on getting MODS and DC working.

7. The administrative data can be common to all of the descriptive schema and does not need to be mapped. METS is being used as the wrapper architecture which includes Rights, Technical, Source, and Digital Provenance administrative metadata.

8. Digital provenance includes data about the digital object. At this point, the digital provenance metadata includes digital signatures for each data stream and which are generated automatically. This section also includes migration metadata which is empty until the first migration occurs. Digital object versions and audit trails will be captured in the migration metadata.

9. Rights. Rutgers will use the proposed LOC draft rights schema as a starting point (see http://www.loc.gov/standards/mets/news080503.html ). At this point, one extension has been suggested for permissions which is a "download" permission and appeared to not be covered by the LOC draft. Also proposed is a "begindate" and "expirationdate" for rights.

10. Source. Source metadata should provide information about the non-digital artifact such as the location of the master (from which a scan is taken), condition, units, and dimensions. At this point, for operational simplicity, the source metadata should be a part of the descriptive metadata and the source segment in the METS wrapper will be null (although at a later time it may be used).

11. Technical. Technical metadata will include information on the files that are ingested as part of the digital object. This data includes mime types, file sizes, compression algorithms, etc.

12. With the above assumptions, the WMS can generate the technical, source, and digital provenance sections automatically, leaving the user to provide the descriptive metadata (including source) and the rights metadata. The following indicates that this object is a member of the NJDH and the Seabrook Farms collection:

    <mods:relatedItem type="host" xlink="http://www.njdigitalhighway.org">
         <mods:titleInfo>
         <mods:title>New Jersey Digital Highway</mods:title>
         <mods:identifier type="local">NJDH</mods:identifier>
         </mods:titleInfo>
    </mods:relatedItem>

    <mods:relatedItem type="host" xlink="">
         <mods:titleInfo>
         <mods:title>Seabrook Farms</mods:title>
         <mods:identifier type="local">SBFarms</mods:identifier>
         </mods:titleInfo>
    </mods:relatedItem>

13. Collections. Any object can be a member of as many collections as need be. An object identifies itself as a member of the collection by using the related item field as follows:
    <relatedItem type="host" xlink="xxxxx">
    <titleInfo>New Jersey Digital Highway</titleInfo>
    </relatedItem>

    There will also be a collection object which can aggregate all metadata that is common to all members of the collection.

14. The agent type and role will become a part of the Rights metadata section. Normally this information is found in the METS header but, for now at least, Fedora does not allow the use of the Header (it is preempted by the system). Here again, it has been necessary to extend the roles that are proposed by METS as follows:

    Type=individual, role= scanner, MD creator, object creator
    Type=organization, role = owner

    Organization roles such as disseminator, custodian, and archivist are not needed at the object level, but they may be used at the collection level. For example, in the collection object for NJDH, we may show RUL as the "disseminator."

Reviewed by DAWG January 21, 2004
Revised January 23, 2004, January 28, 2004