This page is volatile. We have agreed on the basic concepts for this model, but implementation may force changes. This content model will be fleshed out and refined based on ongoing work with the Indiana Magazine of History.
Journals will be stored with Fedora objects at the following levels:
- Collection (the entire run of the journal)
- Follows the Collection Content Model
- including a METADATA datastream for the METS Navigator to find out how many volumes there are
- METADATA datastream containing with a simple structMap pointing to the issues in this volume. This is going to be used by METS Navigator.
- No formal content model is defined for "volumes". This is the first example.
- cModel field in Fedora will be VOLUME
- Normal METADATA datastream stores issue-level metadata, with a simple structmap for all pages in the issue. This is used for Fedora's normal object tracking and preservation activities.
- A METSNAV datastream stores a METS document that is optimized for METS Navigator, combining structural information from the METADATA datastream with descriptive information from all articles that belong to this issue.
- May have some child page objects, which are not associated with any particular article (e.g., the front cover)
- Will be very similar to Paged Document Content Model, with the cModel field in Fedora set to ISSUE. The issue plays the part of a "paged document". Both articles and (issue-level) pages play the role of "page", as both are sub-parts of the issue.
- Follows the Paged Document Content Model
- Stores article-level metadata, suitable for article-level searching and OAI distribution.
- In addition to MODS and DC we store with objects, a TEI Independent Header should also be stored if it exists. The datastream is tentatively called INDEP_HEADER.
- May store a METS structmap describing the pages that make up this article. It wouldn't be used frequently, but could be useful for working with the article outside the context of the issue.
- A simple page image, as in the Paged Document Content Model
It's been decided that a Volume level might be needed to group issues together. Such groupings are needed by the rendering layer to show hierarchical displays. See a graphical depiction of this content model.
Note on use of the Paged Document Content Model for issue-level objects
We may eventually need an issue-level disseminator that differs from the basic paged document disseminator, because issue-level objects may have children that are pages and articles. Article-Issue relationship will be represented by the fedora:isMemberOf verb and Page-Article and Page-Issue relationships will be represented by isPartOf. Current relationship disseminators (those that query and find child objects) will continue to work at the Article and the Issue levels.