No description rules are specified by this profile.
All date / time information must be stored according to ISO 8601.
The attribute OBJID must be the internal ID (internal ID’s are only unequivocal within the same archiving system) if it is an export object (DIP) from an archive.
The attribute CREATEDATE must contain a valid date that states the creation or last update of the present metadata in the file mets.xml.
The element agent must be existent with the attributes ROLE and TYPE as well as the sub-element name. That provides information about the creating institution (in case of a SIP) or the archiving system (in case of a DIP). In the latter case, the internal ID in OBJID can be interpreted within the context.
A conforming METS document can contain one or more dmdSec elements.
Every dmdSec must have an ID attribute which must be referenced in the Structural Map of the type "ASSET"
In general there is no limitation about the metadata formats used.
The administrative metadata section contains all technical and digital provenance metadata section for the object and its files. There mustn't be any other technical or digital provenance metadata outside of this section.
A conforming METS document must contain at least one techMD section for metadata on the whole archive object and one techMD section for each file belonging to the object.
The techMD section for the whole archive object must include elements from LMER-Object. Mandatory is only persistentIdentifier that names the external ID. groupIdentifier can be used repeatedly. objectVersion defines the state as original or migration and should be „1“ for an original. If startFile exists, that element contains the value of the ID attribute of the corresponding file of the File Section of METS. If existent, numberOfFiles must correspond to the number of files listed in the File Section of METS.
The respective techMD section of each file must include elements from LMER-File. Only format with an appropriate attribute REGISTRYNAME to identify the used namespace is mandatory. linkedTo is repeatable and, like in startFile, names the corresponding file elements of METS. The following elements from LMER-File should be left out, because they already appear mandatory in the File Section of METS: fileIdentifier, path, name, size, fileDateTime, fileChecksum and mimeType.
In the LMER-File element xmlData, further technical metadata in an arbitrary XML schema can be stated for each file (e. g. MIX, TechMD, JHOVE output). The element is repeatable.
A conforming METS document may contain digiprovMD sections for the whole object and for each file.
The digiprovMD sections must include elements from LMER-Process. The elements oldMetadataRecordCreator, oldObjectIdentifier and oldOb-jectVersion can only exist when referring to the object. oldObjectIdentifier states the internal ID of the predecessor of the described migration. oldMeta-dataRecordCreator provides the context within which the internal ID is valid.
All techMD and digiprovMD sections must have the ID attribute so that they can be referenced in the File section.
A conforming METS document must contain exactly one fileGrp element within which for each file a file element exists that in turn has one Flocat element each. This results in references named by xlink:href that have to be LOCTYPE=“URL“ and have to start with „file://./“ since they are relative links.
The following attributes of file are mandatory: ID, MIMETYPE, CREATED, SIZE, CHECKSUM, CHECKSUMTYPE
In the attribute ADMID of fileGrp, the ID of the techMD section that contains metadata on the whole object must be referenced. Additionally, the ID’s of the digiprovMD sections that describe migrations of the whole object are stated there. Accordingly, in the attribute ADMID of file the ID of the corresponding techMD section with the metadata on the certain file and the ID’s of file related digiprovMD sections have to be stated. As for the order of each listing of the ID’s in ADMID, the following regulation applies: At first, the ID’s of digiprovMD sections are being listed in descending order, starting with the last migration; in the end, the ID of the techMD section (for each file or in fileGrp, exactly one techMD section can be assigned to only).
In a conforming METS document there can be an arbitrary number of Structural Maps. However, there must exist exactly one Structural Map with the attribute TYPE=“ASSET“ that has the following composition: Only one div element with the attribute TYPE=“ASSET“ exists, and this encloses a list of fptr elements for each file of the object. In the respective attribute FILEID, the corresponding ID from the File Section is being referenced. In the attribute DMDID of the div element, the ID’s of all existing dmdSec sections have to be stated.
Besides the mandatory fptr elements, ASSET div also can list mptr elements relating to external ID’s of other archive objects that are linked technically to the present object (e.g., an XML schema that is being referenced by XML files of the present object). This mechanism should not cover content related correlations (e.g., journals); metadata in the dmdSec sections are more suitable for that purpose.
All metadata must be included using mdWrap. mdRef is not allowed.
There are no restrictions on content files.
There are no restrictions on behavior files
It is not allowed to reference metadata files. All metadata must be inline.
The kopal Library for Retrival and Ingest (koLibRI) represents a library of Java tools that have been developed for the interaction with the DIAS system of IBM within the kopal project. It has been design by intention to be re-usable as a whole or in parts within other contexts, too.