 The
Library of Congress >> Standards |
|
 |
|
 |
|
| |
|
|
|
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. date:
2007-10-19T17:31:00 contact:
institution:
National Library of Australia address:
Canberra, ACT, 2600, Australia phone:
+61 2 6262 1111 related_profile:
@RELATIONSHIP="Inherited by"
@URI="TBA"
Australian METS Journal Profile 1.0 extension_schema:
name:
MODS context:
mets/dmdSec/mdWrap/xmlData/mods 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:
name:
PREMIS OBJECT 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:
name:
MIX context:
mets/amdSec/techMD/mdWrap/xmlData/mix note:
Extensions to the METS schema specific to still-image technical metadata. extension_schema:
name:
TEXTMD context:
mets/amdSec/techMD/mdWrap/xmlData/textmd note:
Extensions to the METS schema specific to text technical metadata. extension_schema:
name:
AUDIOMD context:
mets/amdSec/techMD/mdWrap/xmlData/audiomd note:
Extensions to the METS schema specific to audio technical metadata. extension_schema:
name:
VIDEOMD context:
mets/amdSec/techMD/mdWrap/xmlData/videomd note:
Extensions to the METS schema specific to video technical metadata. extension_schema:
name:
METS RIGHTS 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:
name:
PREMIS RIGHTS 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:
name:
XACML 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:
name:
PREMIS AGENT context:
mets/amdSec/digiprovMD/mdWrap/xmlData/premis note:
Extensions to the METS schema specific to agents. extension_schema:
name:
PREMIS EVENT context:
mets/amdSec/digiprovMD/mdWrap/xmlData/premis note:
Extensions to the METS schema specific to events. 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 maintenance_agency:
Australian METS Profile Agency vocabulary:
name:
Australian METS Profile Preservation Level for Representations maintenance_agency:
Australian METS Profile Agency vocabulary:
name:
Australian METS Profile Storage Medium maintenance_agency:
Australian METS Profile Agency 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 maintenance_agency:
Australian METS Profile Agency 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 vocabulary:
name:
Australian METS Profile Agent Type maintenance_agency:
Australian METS Profile Agency vocabulary:
name:
Australian METS Profile Identifier Type maintenance_agency:
Australian METS Profile Agency vocabulary:
name:
Australian METS Profile <fileGrp> USE Attribute maintenance_agency:
Australian METS Profile Agency 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 maintenance_agency:
Australian METS Profile Agency 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 maintenance_agency:
Australian METS Profile Agency 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="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="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="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="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. technical_requirements:
content_files:
requirement:
@ID="content1"
Specific technical requirements for content files should be recorded in sub-profiles. behavior_files:
requirement:
@ID="behavior1"
Specific technical requirements for behavior files should be recorded in sub-profiles. metadata_files:
requirement:
@ID="metadata1"
Specific technical requirements for metadata files should be recorded in sub-profiles. |
 Top
of Page |
||||
| |
|
|||
|
|
|||
|
||||