@xsi:schemaLocation="http://www.loc.gov/METS_Profile/ http://www.loc.gov/standards/mets/profile_docs/mets.profile.v1-2.xsd"
description_rules:
This profile describes the rules and requirements
for using METS as an exchange format to support the collection and preservation
of and access to journal publications. It is a sub-profile of the Australian
METS Profile 1.0 and adheres to the Journals content model specified in the
<div> TYPE attribute vocabulary therein.
A METS document conforming to this profile may
have been created for use as a Submission Information Package (SIP) or a
Dissemination Information Package (DIP). The example in Appendix 1 is a conforming METS
document representing a published journal issue with a cover image and six
articles. This document was created as a SIP to enable a copy of the issue to be archived in a repository. The Example in Appendix 2 is a conforming METS document representing another issue from the same journal that has already been archived in a repository. This document was created as a DIP to enable a delivery system to provide access to the archived copy.
Journal issues and tables of content
In accordance with the Australian METS Profile, a
conforming METS document must include descriptive metadata encoded in MODS for
the primary object represented by the METS document and each of its structural
components, unless <structMap><div> attributes provide a sufficient
level of bibliographic description.
In the example in Appendix 1 each of the articles in the issue has its own descriptive metadata
but the cover image and sections�are only represented in the structural map because they
can be fully described using the <div> TYPE and LABEL attributes.�
To aid discovery and navigation, implementers may also
choose to include section headings as <subject><topic> elements in
article descriptive metadata, with the �authority� attribute set to �local�.
However, this profile still requires the headings to be included in the
<structMap>. This will allow a system to reproduce the table of content without
having to parse the descriptive metadata or to understand local business rules.
Mandatory elements and persistent identifiers
Where a journal or article is being described in
a conforming METS document, title is mandatory. Otherwise it need only be
included if the component has its own distinctive title. Additional metadata,
including use of controlled vocabularies and reference to authority lists, are
encouraged within descriptive metadata but are not mandatory. However, if the
METS document is being used as a DIP, each MODS record must include an
identifier element containing a persistent, globally unique and locally
resolvable identifier for the object or component being described.
The example in Appendix 1 includes identifiers of type URI that resolve to the publisher's copy of the issue. The example in Appendix 2 includes the persistent identifiers assigned by the repository to the primary object and its components on ingest. This document also includes a full set of administrative metadata recording the ingest event for each file.
Fully self-describing metadata
In accordance with the Australian METS Profile, the
descriptive metadata must contain sufficient information for the component and
its relationship to the host journal to be completely self-describing. MODS
supports two ways of doing this: the hierarchy can be fully represented within
a single relatedItem instance using repeatable part subelements; or each level
of the hierarchy can be nested in its own relatedItem element. This profile
requires a separate relatedItem element for each level in the hierarchy that
plays a significant role in the delivery of access to the journal and its
components.� In addition, if the METS document is being used as a DIP, an identifier
element must be included for each relatedItem as described in the section
above.
In both examples, the issue-level
<dmdSec> has one relatedItem for the host journal. Although the issue is
part of an annual volume, this has not been given its own nested
<relatedItem> because volume does not play a significant role in the
delivery of access to the journal. This is manifested by the fact that volumes do
not have their own separate URI in the published copy of the journal.
In both examples, article-level <dmdSec>s
have a relatedItem for the issue which itself has a relatedItem for the host
journal. This enables the identifiers to be recorded that will support navigation
from the article to the issue or to the journal when the metadata is unpacked
and deployed in other contexts such as a federated discovery service.
The archived copy includes a relatedItem for the published copy. This may be the preferred version while it remains available online. However, the DIP for the archived copy can also be used to generate a fully navigable version of the journal issue.
Mappings
Mappings from� MARC21 and Dublin Core
(unqualified) to MODS are given on the MODS website at http://www.loc.gov/standards/mods/dcsimple-mods.html.
Note that this profile requires the extent of an article to be recorded under
relatedItem/part/extent in MODS, although one could see this as being a
property of the article, not the host. The main reason for this is that MODS
does not yet support the use of the unit attribute when extent is used as a
sub-element of physicalDescription. However, there is also a benefit in terms
of processing of including all extent metadata in the same place. The start and
end data elements in MODS are properties of the host.�