METS_Profile:
@xsi:schemaLocation="//www.loc.gov/METS_Profile/ //www.loc.gov/standards/mets/profile_docs/mets.profile.v1-2.xsd"
title:Australian METS 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 content in Australian digital repositories. It is a generic
profile not specific to a particular system or implementation.
Repositories will need to develop and register sub-profiles that detail
implementation-specific requirements.
related_profile:
@RELATIONSHIP="Inherited by"
@URI="TBA"
Australian METS Journal Profile 1.0
extension_schema:
note:Support
for MODS is required in this profile. When additional extension schema
are also used for encoding descriptive metadata these should be
recorded in a sub-profile.
extension_schema:
context:mets/amdSec/techMD/mdWrap/xmlData/premis and/or
mets/amdSec/sourceMD/mdWrap/xmlData/premis
note:Support
for PREMIS to encode technical metadata is required in this profile.
When additional data elements are needed to record technical metadata
for specific file types the extension schema listed below can be used.
Users are encouraged to recommend additional elements for these schema
and additional schema for inclusion in this profile.
extension_schema:
context:mets/amdSec/rightsMD/mdWrap/xmlData/premis
note:Rights
metadata, if included in the <amdSec> element, must be encoded in
either the METS Rights or PREMIS Rights or XACML Policy schema.
extension_schema:
context:mets/amdSec/rightsMD/mdWrap/xmlData/premis
note:Rights
metadata, if included in the <amdSec> element, must be encoded in
either the METS Rights or PREMIS Rights or XACML Policy schema.
extension_schema:
context:mets/amdSec/rightsMD/mdWrap/xmlData/premis
note:Rights
metadata, if included in the <amdSec> element, must be encoded in
either the METS Rights or PREMIS Rights or XACML Policy schema.
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 content in Australian digital repositories. It is a generic
profile not specific to a particular system or implementation, and
therefore does not, for example, contain any detail in the Technical
Requirements section. It is intended that repositories will develop and
register sub-profiles that detail the implementation-specific
requirements.
Saying that a particular element or attribute
in this profile is not supported does not imply that it is prohibited.
However, it does imply that it may be ignored. In general,
implementations processing METS documents that conform to this profile
should attempt to preserve any undefined elements or attributes.
A
conforming METS document represents a discrete object of interest for
the purposes of collection, preservation or access. An object will be
completely described in a conforming METS document, therefore in the
case of a composite object, the components will be described within the
document as well.
An object (whether it is a single or
composite object) may be a component of another object. A conforming
METS document may therefore represent a whole object or a component, as
long as the component is a discrete object of interest with its own
descriptive metadata.
Where an object is a component of
another object, a conforming METS document should express that
relationship through appropriate elements in the descriptive metadata
extension schema, i.e. self-referencing, either fully described in the
primary MODS, or in separate <dmdSec> elements.
An
object or component described in a conforming METS document may be a
physical object that has not yet have been digitised or it may be a
digital object stored on a physical carrier.
The amount of
data included in a conforming METS document will depend on the purpose
of the document. If the purpose is to submit an object to a repository
as an OAIS Submission Information Package (SIP), then a conforming METS
document must contain the files comprising the archival copy of the
object and its components. If the purpose is to transfer custody of an
object from one repository to another as an OAIS Archival Information
Package (AIP), it must also contain the supporting files and metadata
necessary for the object's long term preservation and access. If the
purpose is to deliver an object as an OAIS Dissemination Information
Package (DIP), a conforming METS document may contain only derivative
files or pointers to derivative files, along with sufficient metadata
to render or execute these files properly. In the case of complex
hierarchical objects, components may be represented by another METS
document and just referenced in the parent METS document.
The first example appended to this profile shows a submission
information package for a digitised still image with two files
comprising the archival copy of the object (master and co-master). The
<dmdSec> contains only identifiers for the still image and its
host collection as these can be used by the repository to retrieve a
full cataloguing record on ingest. There is no technical metadata for
the images themselves as this can be generated on ingest. However,
PREMIS <object>, <event> and <agent> metadata
elements are included because of the need to record the derivation
relationship, the hardware and software used in the creation events and
the type of manipulation used to create the co-master.
The
second example appended to this profile shows a dissemination
information package that could be used to transfer a digitised still
image from the same collection from one repository to another. The
package includes a derivative master and two derivative files created
on ingest as well as the master and co-master. Seven events are
recorded, the creation events for each file and the ingestion events
for the master and co-master.
Information encoded using the
extension schema listed in this profile should follow the appropriate
guidelines recommended by the extension schema's maintenance agencies.
For example, MODS encoded descriptive metadata should follow the MODS
Users Guidelines published by the Library of Congress' Network
Development and MARC Standards Office. Users of additional schema
should list these as extension schema in a sub-profile and follow the
appropriate guidelines.
All available metadata should be
included for the archival copy of an object when custody is being
transferred. If no suitable extension schema covers all the metadata,
the extra elements can be encoded using a local extension schema.
Controlled
vocabularies for elements that are mandatory in this profile and that
are not already included in METS or the registered extension schema are
listed in the Controlled Vocabularies section. Users of additional
elements constrained by controlled vocabularies should list these in
the Controlled Vocabularies section of a sub-profile.
Values of "not applicable" and "unknown" are permitted for mandatory elements and attributes where data cannot be supplied.
controlled_vocabularies:
vocabulary:
name:Australian METS Profile Preservation Level for Files
values:
value:supported = fully supported
value:known = not supported yet but high priority to try and fully support
value:unsupported = known or unknown format, preserve bitstream as is, but low priority for support
value:not applicable = not a preservation copy of the item
vocabulary:
name:Australian METS Profile Preservation Level for Representations
values:
value:level
[N] = where [N] is any number; "level 1" must represent the highest
level preservation action that may be applied to an object
value:pending = preservation level is yet to be determined
vocabulary:
name:Australian METS Profile Storage Medium
values:
value:computer card = card containing digitally encoded data designed for use with a computer
value:computer chip cartridge = cartridge containing a miniaturized electronic circuit on a small wafer of semiconductor silicon
value:computer disc = disc containing digitally encoded data, magnetically or optically recorded, designed for use with a computer
value:computer disc cartridge = cartridge containing one or more computer discs
value:computer tape cartridge = cartridge containing a computer tape
value:computer tape cassette = cassette containing a computer tape
value:computer tape reel = open reel holding a length of computer tape to be used with a computer tape drive
value:online resource = digital resource accessed by means of hardware and software connections to a communications network
description:These values are based on the Resource Description and Access controlled vocabulary for carrier type.
vocabulary:
name:Australian METS Profile Event Type
values:
value:capture = the process whereby a repository actively obtains an object
value:compression = the process of coding data to save storage space or transmission time
value:creation = the act of creating a new object
value:deaccession = the process of removing an object from the inventory of a repository
value:decompression = the process of reversing the effects of compression
value:decryption = the process of converting encrypted data to plaintext
value:deletion = the process of removing an object from repository storage
value:digital signature validation = the process of determining that a decrypted digital signature matches an expected value
value:dissemination = the process of retrieving an object from repository storage and making it available to users
value:fixity check = the process of verifying that an object has not been changed in a given period
value:ingestion = the process of adding objects to a preservation repository
value:message digest calculation = the process by which a message digest ("hash") is created
value:migration = a transformation of an object creating a version in a more contemporary format
value:normalization = a transformation of an object creating a version more conducive to preservation
value:replication = the process of creating a copy of an object that is, bit-wise, identical to the original
value:validation = the process of comparing an object with a standard and noting compliance or exceptions
value:virus check = the process of scanning a file for malicious programs
description:These values are based on the PREMIS Data Dictionary starter list for eventType.
vocabulary:
name:Australian METS Profile Identifier Type
values:
value:internal = form of identifier that is known by the repository
value:URI = form of identifier that is a unique resource identifier
vocabulary:
name:Australian METS Profile <fileGrp> USE Attribute
values:
value:co-master = copies of original or master files that have been edited where this is required for delivery purposes
value:derivative
= copies of original, master, co-master or derivative master files that
have been created to enable the delivery of an object through an
application or service
value:derivative
master = copies of original, master or co-master files that have been
migrated to a format suitable for the generation of derivatives
value:finding aid = files that describe the content of a collection of objects
value:master = preservation copies of a digitised object
value:original = preservation copies of a born-digital object
value:preview = files that enable users to sample the content of an object before requesting access and meeting any access obligations
value:print = files that deliver a version of an object in a form capable of being printed
value:related metadata = files containing metadata about an object that has been stored as part of the Archival Information Package
value:structural
map = files that describe the structure of an object and the
relationships between the components making up the object
value:transcript = files that render in text the content of an audio, video or still image object
vocabulary:
name:Australian METS Profile <structMap> TYPE Attribute
values:
value:logical
= a way of arranging the components of an object based on their
intellectual structure, e.g. a digitised photographic album containing
twelve photographs
value:physical
= a way of arranging the components of an object based on their
physical characteristics, e.g. a digitised photographic album
containing a front cover, an inside front cover, a sequence of four
pages each containing a sequence of three photographs, then an inside
back cover, and a back cover
value:spatial = a way of arranging the components of an object based on place
value:temporal = a way of arranging the components of an object based on time
vocabulary:
name:Australian METS Profile <div> TYPE Attribute
description:Values
for the <div> TYPE attribute are available from the Australian
METS Profile Agency's website. This vocabulary is being maintained
through a separate process so that new content models can be added
without changing the core profile.
structural_requirements:
metsRootElement:
requirement:
@ID="metsRoot1"
The <mets> root element must contain a PROFILE attribute with the value "//www.loc.gov/mets/profiles/00000018.xml".
requirement:
@ID="metsRoot2"
The <mets> root element must contain an OBJID
attribute. If the METS document is being used as a Submission
Information Package (SIP) it does not need to be globally unique. If
the METS document is being used as a Dissemination Information Package
(DIP) it must be a persistent, globally unique and locally resolvable
identifier for the METS document.
requirement:
@ID="metsRoot3"
The <mets> root element must contain a TYPE
attribute. TYPE values must be taken from the Australian METS Profile
<div> TYPE attribute controlled vocabulary.
requirement:
@ID="metsRoot4"
The <mets> root element must contain a <metsHdr> element.
requirement:
@ID="metsRoot5"
Use of the <mets> root element attributes of ID and LABEL is not supported by this profile.
metsHdr:
requirement:
@ID="metsHdr1"
The <metsHdr> element must contain a CREATEDATE
attribute specifying when the METS document was created and a
LASTMODDATE attribute specifying when the METS document was last
modified. If the METS document is being used as a Submission
Information Package (SIP) both the CREATEDATE and LASTMODDATE must be
the date it was submitted. If the METS document is being used as a
Dissemination Information Package (DIP) the CREATEDATE must be the date
the persistent identifier in mets OBJID was assigned and the
LASTMODDATE must be the most recent date modified of any element or
attribute in the METS document.
requirement:
@ID="metsHdr2"
Use of the <metsHdr> ID and RECORDSTATUS attributes is not supported by this profile.
requirement:
@ID="metsHdr3"
Use of the <altRecordID> element within the <metsHdr> element is not supported by this profile.
requirement:
@ID="metsHdr4"
The <metsHdr> element must contain an <agent>
element with a ROLE of "disseminator" and a TYPE of either
"organization" or "individual". This <agent> element must contain
a <name> element with the name of the organisation or individual
responsible for publishing or disseminating the METS document.
requirement:
@ID="metsHdr5"
The <metsHdr> element must also contain an
<agent> element with a ROLE of "creator" and a TYPE of "other".
This <agent> element must contain a <name> element with the
name of the software and version used to produce the METS document.
requirement:
@ID="metsHdr6"
If the first required <agent> element has a
TYPE="organization", an optional <agent> element may be used to
encode the name of an individual responsible for publishing or
disseminating the METS document. If used, this optional <agent>
element must have a ROLE attribute with a value of "creator", and a
TYPE attribute with a value of "individual".
requirement:
@ID="metsHdr7"
Use of the <agent> ID, OTHERROLE and OTHERTYPE attributes and the <note> element is not supported by this profile.
dmdSec:
requirement:
@ID="dmdSec1"
The <dmdSec> is reserved for bibliographic
description and subject analysis of the object represented by the METS
document. There must be at least one <dmdSec> for the object
conforming to the MODS descriptive metadata extension schema.
requirement:
@ID="dmdSec2"
In the case of a composite object, include a separate
<dmdSec> for each component needing to be described, unless the
structMap provides a sufficient level of bibliographic description at
the component level.
requirement:
@ID="dmdSec3"
Where multiple metadata records describing the same object
or component using different schema are included in the METS document,
these must be captured in separate <dmdSec> elements and linked
via the GROUPID attribute.
requirement:
@ID="dmdSec4"
Each <dmdSec> must contain an <mdWrap>.
requirement:
@ID="dmdSec5"
Each <dmdSec> must contain a unique ID within the context of the document.
requirement:
@ID="dmdSec6"
Use of the <dmdSec> ADMID, CREATED and STATUS attributes is not supported by this profile.
amdSec:
requirement:
@ID="amdSec1"
There must be one and only one <amdSec> which may
contain repeatable <techMD>, <sourceMD>, <digiprovMD>
and <rightsMD> elements containing metadata records conforming to
the relevant PREMIS extension schema or other relevant extension
schema.
requirement:
@ID="amdSec2"
Some PREMIS elements identified as mandatory in this
profile are conditional or optional in the relevant PREMIS schema. For
example, <preservationLevel> is mandatory in this profile.
requirement:
@ID="amdSec3"
Use of the <amdSec> ID attribute is not supported by
this profile. However, each <techMD>, <sourceMD>,
<digiprovMD> and <rightsMD> element must contain a unique
ID attribute within the context of the document.
requirement:
@ID="amdSec4"
Use of the GROUPID, ADMID, CREATED and STATUS attributes
for the <techMD>, <sourceMD>, <digiprovMD> and
<rightsMD> elements is not supported by this profile.
requirement:
@ID="amdSec5"
For the primary object described in the first level
<div> in the <structMap> there must be at least one
<techMD> in the <amdSec> containing a metadata record in
<mdWrap> <xmlData> conforming to the PREMIS Object schema
with <objectCategory> set to "representation" and values encoded
for all elements mandatory for this <objectCategory>
(<objectIdentifier>, <preservationLevel>,
<objectCategory>). This <objectIdentifier> must be the same
as the OBJID assigned to the <mets> root element.
requirement:
@ID="amdSec6"
If the METS document is being used as a Dissemination
Information Package, there must be at least one <techMD> in the
<amdSec> element containing a metadata record in <mdWrap>
<xmlData> conforming to the PREMIS Object schema, with
<objectCategory> set to "file" and values encoded for all
elements mandatory for this <objectCategory>
(<objectIdentifier>, <preservationLevel>,
<objectCategory>, <compositionLevel>, <format>,
<storage>).
requirement:
@ID="amdSec7"
For PREMIS <objectIdentifierType> use values from the Australian METS Identifier Type controlled vocabulary.
requirement:
@ID="amdSec8"
For PREMIS <preservationLevel> when
<objectCategory> is set to "file" use values from the Australian
METS Profile Preservation Level for Files controlled vocabulary. When
<objectCategory> is set to "representation" use values from the
Australian METS Profile Preservation Level for Representations
controlled vocabulary.
requirement:
@ID="amdSec9"
For PREMIS <formatName> use MIMETYPE or an
appropriate external registry identifier. Also include
<formatVersion> if known.
requirement:
@ID="amdSec10"
For PREMIS <storageMedium> use values from the Australian METS Profile Storage Medium controlled vocabulary.
requirement:
@ID="amdSec11"
Use of optional PREMIS metadata elements is not supported
by this profile but may be included if data is available. SIZE,
CHECKSUM and CHECKSUMTYPE are mandatory attributes for the METS
<file> element and so there is no need to include PREMIS
<messageDigestAlgorithm>, <messageDigest> or <size>
in the <techMD>. Where optional elements are required by a
sub-profile and values are supported by a controlled vocabulary this
information must be included in the sub-profile.
requirement:
@ID="amdSec12"
A PREMIS relationship element must be included in the
<techMD> where the object has been derived from another object
included in the information package. In this case set
<relationshipType> to "derivation" and
<relationshipSubtype> to "derived from". (Note that there is no
need in this profile to specify the relationship in both directions.)
requirement:
@ID="amdSec13"
Use of the PREMIS relationship element to describe the
relationship of an object to the intellectual entity it instantiates or
to describe hierarchical relationships is not supported by this
profile. The METS <dmdSec> and <structMap> should be
sufficient for this purpose.
requirement:
@ID="amdSec14"
For files, additional <techMD> elements may be
included with data encoded using an appropriate extension schema to
capture metadata not covered by PREMIS.
requirement:
@ID="amdSec15"
<rightsMD> is optional. If rights metadata is
already stored in the <dmdSec>, for example, it may not be
necessary to repeat this metadata in the <rightsMD>. Where
present, however, <rightsMD> must contain an <mdWrap>
<xmlData> element encoded using either the METS Rights, PREMIS
Rights or XACML extension schema.
requirement:
@ID="amdSec16"
<sourceMD> may be used but is not required if the
<dmdSec> describes the original source material used to create
the METS object e.g. if the METS object is a digital surrogate for a
physical item. <sourceMD> may be used to describe source
materials between the original and current object where the source
materials are not digital objects.
requirement:
@ID="amdSec17"
<sourceMD> must be used if <digiprovMD>
includes PREMIS Event metadata which has a
<linkingObjectIdentifier> to an object which is not being
transferred as part of this METS document. In this case
<sourceMD> <mdWrap> must contain a <premisObject>.
For example, if a PDF was created from a Word document and the PDF is
being transferred but the Word document is not (the Word document may
have already been discarded by the transferring repository), the Word
document would be described in <sourceMD> as a PREMIS Object.
requirement:
@ID="amdSec18"
If an object is being transferred from an existing
repository, there must be at least one <digiprovMD> for the
current archival or master copy, describing the ingest event into the
transferring repository. <digiprovMD> is optional for objects
which are not the master copy or for objects being submitted to a
repository for the first time. Where <digiprovMD> is included
there must be one <digiprovMD> for each event or agent.
requirement:
@ID="amdSec19"
As complete a provenance history as possible should be
provided for 'master' or archival objects, describing events (in
separate <digiprovMD> elements) which led to the creation of the
current object and its ingest in the transferring repository. This
includes changes to the object originally deposited (note that in
PREMIS, an object cannot be modified: an event which modifies an object
creates a new object) and changes of custody.
requirement:
@ID="amdSec20"
Each PREMIS Event must have values encoded for all
mandatory elements (<eventIdentifier>, <eventType>,
<eventDateTime>). For PREMIS <eventType> use values from
the Australian METS Profile Event Type controlled vocabulary.
requirement:
@ID="amdSec21"
If the event is one which changes an object, information
about the hardware / software used must be included in the PREMIS
<linkingAgentIdentifier> element. The value in
<linkingAgentIdentifierValue> may be a unique identifier within
the registry or transferring repository if the agent has one, or else
simply a unique identifier to this agent within the METS document. For
<linkingAgentIdentifierType> use values from the Australian METS
Profile Identifier Type controlled vocabulary.
requirement:
@ID="amdSec22"
If an organisation other than the transferring repository
was responsible for an event, that organisation must also be noted in
an instance of PREMIS <linkingAgentIdentifier>.
requirement:
@ID="amdSec23"
If there is a PREMIS <linkingAgentIdentifier>, a
<digiprovMD> element containing PREMIS Agent metadata for the
agent should be present with values encoded for
<agentIdentifier>, <agentName> and <agentType>. For
<agentIdentifierType> use values from the Australian METS Profile
Identifier Type controlled vocabulary. For <agentType> use values
from the Australian METS Profile Agent Type controlled vocabulary.
requirement:
@ID="amdSec24"
Other types of events occurring after ingest of the
current object into the transferring repository may be recorded in
additional <digiprovMD> elements (e.g. format validation,
checksum checking, generation of derivatives).
requirement:
@ID="amdSec25"
If the object is related to another digital object through
an event and the related object is described in a <techMD> in the
METS document, the event should contain a <premisEvent>
<linkingObjectIdentifier> which matches the related object's
<premisObject> <objectIdentifier> in the related object's
<amdSec> <techMD> element.
requirement:
@ID="amdSec26"
If the object is related to another digital object through
an event and the related object is not described in a <techMD> in
the METS document, the event should contain a <premisEvent>
<linkingObjectIdentifier> which matches a <premisObject>
<objectIdentifier> in a <premisObject> in <sourceMD>.
For example, a Word document may have been transformed into an RTF then
to PDF. If only the PDF is being transferred, each event should be
described in a separate PREMIS Event with
<linkingObjectIdentifier> matching the <objectIdentifier>
in a <premisObject> under <sourceMD>. The Word and RTF
files would each be described (even if they no longer exist) in a
<premisObject> element under separate <sourceMD> elements.
requirement:
@ID="amdSec27"
Additional <digiprovMD> elements describing the same
events and agents in other schema may be included. If other schema are
used, these schema must be listed as extension schema in a sub-profile.
fileSec:
requirement:
@ID="fileSec1"
A <fileSec> element containing at least one
<fileGrp> must be used if there are data files associated with
the object described by the METS document that need to be referenced
for the implementation workflow being supported by the document.
requirement:
@ID="fileSec2"
Use of the <fileSec> ID attribute is not supported by this profile.
requirement:
@ID="fileSec3"
Each <fileGrp> must have a USE attribute with a
value from the Australian METS Profile <fileGrp> USE attribute
controlled vocabulary, which is a list of values that may be used to
sort files associated with a particular representation into groups
based on their purpose. Each <fileGrp> must contain at least one
<file> belonging to that USE category. Values have not been
included in this vocabulary for services that deliver access to an
object because it is assumed that these would not be included in a
Submission Information Package or Dissemination Information Package.
Such a service may be archived as an object in its own right, in which
case the <fileGrp> would have a USE attribute of "original". This
decision may be reviewed if a use case emerges that requires a service
USE attribute.
requirement:
@ID="fileSec4"
There may be a variety of different types of derivative
(thumbnail, view, examination, streaming, special delivery). Within
each of these types there may be multiple sub-types, e.g., two
different-sized thumbnails, one for result sets, one for display with
the descriptive metadata. At this stage it is assumed that the
derivative <fileGrp> will contain all of the derivative files
needed for the successful delivery of an object. Within the derivative
<fileGrp>, the <file> USE attribute may be used in order to
distinguish between the different types of derivatives. Values for the
<file> USE attribute must be drawn from a controlled vocabulary,
which must be specified in a sub-profile. The Behaviors section of the
sub-profile must also detail the different types of derivatives
included in the <fileGrp>, and associate them with appropriate
behaviours for each <structMap> <div> TYPE.
requirement:
@ID="fileSec5"
If the purpose of the document is to transfer files
constituting a digital object to a repository, <fileSec> must
contain one <fileGrp> with a USE attribute of "original" if the
object is a born-digital object or at least one <fileGrp> with a
USE attribute of "master" if the object is a digital surrogate.
<fileSec> may also contain <fileGrp> elements for files
with other USE attributes.
requirement:
@ID="fileSec6"
If used, there must not be more than one <fileGrp>
element with a USE attribute of "original". All other <fileGrp>
USE attributes may occur more than once. Where there is more than one
<fileGrp> with the same USE attribute, however, it must be
distinguished from other <fileGrp> instances with the same USE
attribute through the use of the <fileGrp> VERSDATE attribute.
requirement:
@ID="fileSec7"
Nested <fileGrp> elements are not supported by this profile.
requirement:
@ID="fileSec8"
Use of <fileGrp> ID and ADMID attributes is not supported by this profile.
requirement:
@ID="fileSec9"
<file> must contain ID, MIMETYPE, SIZE, CHECKSUM and
CHECKSUMTYPE attributes and either a single <FLocat> or
<FContent> element. The <file> ID attribute is for internal
use within the METS document (it pairs with IDREF in the <fptr>
FILEID attribute) but may be based on a repository identifier. The
<file> CHECKSUMTYPE attributes must contain values from the
controlled vocabulary specified in METS. This profile requires
MIMETYPE, SIZE, CHECKSUM and CHECKSUMTYPE to be recorded as METS
<file> attributes rather than as equivalent elements in a
<techMD> <premisObject> instance because providing this
information at the packaging level enables processing decisions to be
made without having to parse the package payload, and potentially
allows for a more modular design of processors.
requirement:
@ID="fileSec10"
The <file> ADMID attribute must be used to provide a
link to the file's administrative metadata. ID values must be inserted
in the ADMID attribute for all <techMD>, <sourceMD>,
<digiprovMD> and <rightsMD> elements related to this file
included in the <amdSec> element. Each ID value must be separated
by a space.
requirement:
@ID="fileSec11"
Use of <file> SEQ, CREATED, DMDID and GROUPID attributes is not supported by this profile.
requirement:
@ID="fileSec12"
Within the <file> element, use of the
<stream>, <transformFile> and any nested <file>
elements is not supported by this profile.
requirement:
@ID="fileSec13"
<file> may contain an OWNERID attribute to provide a
unique identifier (including a URI) assigned to the file which may
differ from the URI used to retrieve the file. This will often be the
filename as known by the submitter. Use of OWNERID is strongly
recommended for files which may be used by a 'root' file to reconstruct
or render an object.
requirement:
@ID="fileSec14"
<FLocat> is not repeatable in this profile. A
<FLocat> must be provided for each file if the content of the
file is not embedded in <FContent>. <FLocat> must only be
used if and only if the URL can be guaranteed under normal conditions
(i.e. excluding network /connectivity issues) to be accessible. Any URL
either needs to point directly to a file or to a service which exposes
the file content to the requesting party.
requirement:
@ID="fileSec15"
<FLocat> must contain a LOCTYPE attribute with
values from the controlled vocabulary specified in METS. However, the
LOCTYPE value "other" and the OTHERLOCTYPE attribute must not be used
in this profile. The location of the resource pointed to must be stored
in the XLINK:HREF attribute as specified in METS.
requirement:
@ID="fileSec16"
<FContent> must be present if there is no
<FLocat>. As specified in METS, the content file must be either
Base 64 encoded and contained within the subsidiary <binData>
wrapper element, or consist of XML information and be contained within
the subsidiary <xmlData> wrapper element. The XLINK attribute is
mandatory but this profile has no recommendations.
requirement:
@ID="fileSec17"
Use of the ID and USE attributes for the <FLocat> and <FContent> elements is not supported by this profile.
structMap:
requirement:
@ID="structMap1"
The structural map is the heart of a METS document,
defining the hierarchical arrangement of a primary source document
which has been digitized. This profile regards the purpose of this
element group as facilitating the deconstruction of a digital object
for ingest or the reconstitution of a digital object for delivery or
presentation.
requirement:
@ID="structMap2"
There must be at least one <structMap> element that
describes the structure of the whole object represented by the METS
document. For an object consisting of a single file there will be a
single <div> element. For an object whose structure is
hierarchical the structure should be encoded as a tree of nested
<div> elements. The first level <div> element must
represent the whole object. Lower level <div> elements must
represent parts of the object.
requirement:
@ID="structMap3"
If there is more than one <structMap>, the
<structMap> TYPE attribute is mandatory, and values must be taken
from the Australian METS Profile <structMap> TYPE controlled
vocabulary. Use of <structMap> ID attribute is mandatory if you
have more than one <structMap> of the same TYPE.
requirement:
@ID="structMap4"
This profile supports the use of the optional <structMap> LABEL attributes but makes no recommendations.
requirement:
@ID="structMap5"
The <div> TYPE attribute is mandatory and values
must be taken from the Australian METS Profile <div> TYPE
controlled vocabulary.
requirement:
@ID="structMap6"
This profile supports the use of the optional <div>
LABEL and ORDERLABEL attributes, which may be used to represent the
relationship between components and the whole object.
requirement:
@ID="structMap7"
The <div> DMDID attribute must be present for the
first level <div> representing the whole object and must be
present for the lower level <div> elements if there is a
corresponding <dmdSec> for that part of the object.
requirement:
@ID="structMap8"
The <div> ADMID attribute must be present for the
first level <div> representing the whole object and must be
present for the lower level <div> elements if there is any
corresponding administrative metadata for the representation described.
ID values must be inserted separated by a space for all <techMD>,
<sourceMD>, <digiprovMD> and <rightsMD> elements
related to this representation included in the <amdSec> element.
requirement:
@ID="structMap9"
Use of the <div> ID, ORDER and CONTENTIDS attributes is not supported by this profile.
requirement:
@ID="structMap10"
There must be at least one <fptr> in each
<div> that references a <premisObject> of TYPE="file". Each
<fptr> must contain a FILEID to point to a file in the METS
document.
requirement:
@ID="structMap11"
Use of the <fptr> ID and CONTENTIDS attributes and
the child elements <par>, <seq> and <area> is not
supported by this profile.
requirement:
@ID="structMap12"
<mptr> may be used to reference any child object or component that has its own METS document.
requirement:
@ID="structMap13"
Use of the <mptr> ID and CONTENTIDS attributes is not supported by this profile.
requirement:
@ID="structMap14"
Use of the <structLink> and <behaviorSec> element groups is not supported by this profile.
multiSection:
requirement:
@ID="multiSection1"
All date values must be xsd:dateTime compliant, as specified in XML Schema: Datatypes at http://www.w3.org/TR/xmlschema-2.
requirement:
@ID="multiSection2"
There must be only one <mdWrap> element in each
parent element. All <mdWrap> elements must contain an MDTYPE
attribute with a value from the controlled list prescribed by METS. If
the value of MDTYPE is "other", the <mdWrap> element must also
contain an OTHERMDTYPE attribute. Any schema identified in MDTYPE or
OTHERMDTYPE must be included as an extension schema in this profile or
a sub-profile conformant with this profile. The <mdWrap> element
must also include data encoded in the specified schema in the
<xmlData> element.
requirement:
@ID="multiSection3"
Use of the <mdRef> element is not supported by this profile.
tool:
note:
Specific tools and applications should be recorded in sub-profiles.
|