title:
Australian METS Conference Profile 1.0

abstract:
This profile describes the rules and requirements for using METS as an exchange format to support the collection and preservation of and access to conference publications. It is a sub-profile of the Australian METS Profile 1.0 and adheres to the conference content model specified in the <div> TYPE Attribute vocabulary therein.

date:
2007-12-04T15:31:00

contact:

related_profile: @URI="//www.loc.gov/mets/profiles/00000018.xml" @RELATIONSHIP="inherits"
Australian METS Profile 1.0

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 conference publications. It is a sub-profile of the Australian METS Profile 1.0 and adheres to the Conference 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 conference instance in physical form (i.e. structured to reflect the conference program) with five papers across two tracks. This document was created as a SIP to enable a copy of the conference in its original form to be archived in a repository. The Example in Appendix 2 is the same conference but with the conference viewed as a logical entity composed of a set of submissions. The form in Appendix 2 would be used where the packaging agent is unable to obtain the necessary information to recreate the conference in its original form or the receiving party only requires the conference output. Appendix 3 shows the same logical form created as a DIP to enable a delivery system to provide access to the archived copy. The examples are based on a cut-down semi-fictional version of the Open Repositories 2008 conference, an instance of the Open Repositories Conference series.

Conference instances and conference series

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.

Mandatory elements and persistent identifiers

Where a conference submission 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 examples in Appendix 1 and Appendix 2 include identifiers of type URI that resolve to the publisher's copy of the issue. The example in Appendix 3 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 conference series 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 conference 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, submission <dmdSec>s have a relatedItem for the conference instance which itself has a relatedItem for the conference series. This enables the identifiers to be recorded that will support navigation from the more abstract conference concept to the scheduled instances when the metadata is unpacked and deployed in other contexts such as a federated discovery service.

The archived copy could include 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 conference instance.

Mappings

Mappings from  MARC21 and Dublin Core (unqualified) to MODS are given on the MODS website at //www.loc.gov/standards/mods/dcsimple-mods.html. Note that this profile requires the extent of a submission to be recorded under relatedItem/part/extent in MODS, although one could see this as being a property of the submission, 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 any component. For example a scheduled conference will have start and end information, and individual sessions, tracks and submissions (presentations) may also have this information available.

controlled_vocabularies:

structural_requirements:

technical_requirements:

tool: