Descriptive metadata Clause Samples
The Descriptive Metadata clause defines the requirements for providing detailed information about a product, service, or data set to facilitate its identification and understanding. Typically, this clause specifies the types of metadata that must be included, such as titles, authors, dates, formats, or subject classifications, and may outline standards or formats to be used. By mandating clear and consistent metadata, the clause ensures that users can efficiently locate, interpret, and utilize the described item, thereby improving discoverability and reducing confusion or misinterpretation.
POPULAR SAMPLE Copied 1 times
Descriptive metadata. The descriptive metadata section (<dmdSec>) references descriptive metadata contained in the AIP. Mul- tiple <dmdSec> elements are allowed so that descriptive metadata can be referenced for each separate item within the METS object. Descriptive metadata is referenced by means of the <mdRef> element as part of the descriptive metadata element <dmdSec>. Listing 4 shows an example linking to an EAD XML metadata file. <dmdSec ID="ID550e8400-e29b-41d4-a716-44665544000a"> <mdRef LOCTYPE="URL" MDTYPE="EAD" MIMETYPE="text/xml" CREATED="2015-04-26T12:00:00+01:00" xlink:type="simple" xlink:href="file://./metadata/EAD.xml" CHECKSUMTYPE="SHA-256" CHECKSUM="..." SIZE="2321"/> </dmdSec>
Descriptive metadata. The METS descriptive metadata element <dmdSec> references to archival description metadata (EAD, EAC- CPF, etc.) as seen in Figure 6. May contain <dmdSec> Archival information can be included in the METS package. For the core interest groups in E-ARK – archival institutions – this information is delivered to the recipient in EAD and EAC-CPF formats. To include EAD and EAC-CPF in a METS profile the use of <dmdSec> is to be preferred according to the METS implementation guide referenced above. The complete rules for all elements and attributes in the <dmdSec> are stated in the profile, the specific elements used when referencing and embedding is shown below. Other metadata standards for description and administrative purposes can be used and referencing or embedding32 them must adhere to the <amdSec> and <dmdSec> rules stated in the profile. EAD metadata file Metadata file in EAD format referenced in the METS document Metadata file in EAD format when it is referenced in the METS document. Its needs to be stated in the submission agreement if referencing or embedding are used. 0..* <dmdSec> <mdRef: MDTYPE=”EAD” xlink:href=”file:/// 33[EAD-metadata file]” xlink:type=”simple ”> EAD metadata Metadata in EAD format embedded in the METS document Metadata in EAD format when it is embedded34 in the METS document. Its needs to be stated in the submission agreement if referencing or embedding are used. 0..* <dmdSec> <mdWrap: MDTYPE=”EAD”> <xmlData> [EAD metadata in XML-format] EAC-CPF metadata file Metadata file in EAC-CPF format referenced in the METS document Metadata file in EAC-CPF format when it is referenced in the METS document. Its needs to be stated in the submission agreement if referencing or embedding are used. 0..* <mdSec> <mdRef: MDTYPE= ”EAC-CPF” xlink:href=”file:///[ EAC-CPF metadata file]” xlink:type=”simple 32 The Common Specification recommends to avoid embedding. 33 The coice of using ”///” or ”//” depends on implementations. For example, a Windows file path could be file://C:/somefile.txt and file:///somefile.txt would be the corresponding Unix path in case of absolute paths. 34Usually if EAD metadata has been embedded in the METS document once, it will be not referenced as EAD file again.
Descriptive metadata. The package must include a simple EAD file which uses the mandatory elements as defined for the general DIP format. In short, EAD metadata must use the tags set out in the E-ARK DIP Pilot Specification D5.3, among others the following mandatory elements need to be used: • The title for each descriptive unit within the package (element did/unittitle); • The creation date of the record or descriptive unit (one of the elements did/unitdate or • The relative path to the file or folder within the \representations\[repID]\Data folder of the DIP (element did/dao with the href attribute referring to the relative location of the file, other attributes used according to the official EAD3 standard). If the record includes multiple computer files the additional use of the element did/daoset is needed102. The use of all other elements is optional. Example: … <c02 level="record"> <did> <unittitle>Circular no 25</unittitle> <unitdate type="single" normal="20010324">March 24, 2001</unitdate> … <daoset label="Computer Files" coverage="whole"> <dao daotype="borndigital" linktitle="Circular no 25 body" href="/representations/ID0023dfc33/Circular_no_25/C25_main.pdf"> </dao> <dao daotype="borndigital" linktitle="Circular no 25 Annex I" href="/representations/ID0023dfc33/Circular_no_25/AnnexI.pdf"> </dao> </daoset> </did> </c02> … 102 Like mentioned before, the final linking method is yet to be established. For scenario b) above the package is also expected to include further metadata taken from the extended EAD set as described in Appendix 1 of the E-ARK SMURF Profile (D3.3). The mandatory elements which need to be included: • archival aggregation level(s) to which the records belong (using the @level attribute on the archdesc, c, c01 etc element); • and archival history of the record (using the custodhist element); • if applicable, EAD metadata must also include information about any access restrictions to the records (using the accessrestrict element).