EAD Clause Samples
EAD. EAD metadata is the main tool for understanding and using the content of the SMURF ERMS DIP. In general EAD metadata must follow the rules set out in the core DIP specification (see Chapter 3 The DIP) and the core SMURF specification (D3.4 E-ARK SIP Specification: ▇▇▇▇://▇▇▇.▇▇▇▇-▇▇▇▇▇▇▇.▇▇▇/resources/project- deliverables/93-d34-1). For the development of appropriate access tools (viewers) we expect that the following EAD elements are available and filled with appropriate information: ● 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 ● Each descriptive unit which has a physical counterpart as a folder or computer file(s) within the package’s folder structure must use the element did/dao along with the @href attribute referring to the relative location of the folder or file. In case the reference is to a record which includes multiple computer files, the use of the element did/daoset is required ● Identification of aggregation level(s) and records (using the @level attribute on the archdesc or c element) ● 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) ● the original classification schema in full or in part (using the fileplan element); ● full ERMS originated metadata about the aggregation level(s) and records (embedded into EAD using the odd element at the appropriate c-level); ● relevant metadata about the actors and events as exported from the source ERMS and recorded in the extended EAD (sub-elements of the EAD element odd as described in D3.3 SMURF specification, for example information about signatures, opening and closing of the file, etc.) Full example: <?xml version="1.0" encoding="utf-8"?> <ead xmlns="▇▇▇▇://▇▇▇▇.▇▇▇▇▇▇▇▇▇▇.▇▇▇/schema/" xmlns:xsi="▇▇▇▇://▇▇▇.▇▇.▇▇▇/2001/XMLSchema- instance" xsi:schemaLocation="▇▇▇▇://▇▇▇▇.▇▇▇▇▇▇▇▇▇▇.▇▇▇/schema/ ../../schemas/ead3.xsd"> <control> <recordid>f323992d-bfa0-4586-bc1b-090d06ec6a72</recordid> <filedesc> <titlestmt> <titleproper>University of Utopia</titleproper> </titlestmt> </filedesc> <maintenanceagency> <agencyname>University of Utopia</agencyname> </maintenanceagency> <maintenancehistory> <maintenanceevent> <eventtype value="created"></eventtype> <eventdatetime>2016-07-08T08:50:52.1200000</eventdatetime> <agenttype value="human...
EAD. 3.3.3.3.1 EAD files ▇▇▇▇▇://▇▇▇▇▇▇.▇▇▇/DLMArchivalStandardsBoard/E-ARK-DIP/tree/master/examples/OLAP
EAD. The necessary prerequisite for the application of the SMURF SFSB profile is that a simple archival description has been created using EAD. In the most common scenario this EAD description would include a few aggregations (possibly following the original folder structure) and simple descriptions of the content itself. There are a few EAD elements which are deemed mandatory in order to allow for the development of common access tools: ● The title for each aggregation (element did/unittitle) ● The creation date of the record or aggregation (one of the elements did/unitdate or ● Each descriptive unit which has a physical counterpart as a folder or computer file(s) within the package’s folder structure must use the element did/dao along with the @href attribute referring to the relative location of the folder or file. In case the reference is to a record which includes multiple computer files, the use of the element did/daoset is required Besides these elements the rules for EAD as highlighted above for the core DIP and within the core SMURF SFSB specification need to be followed. Full example: <?xml version="1.0" encoding="utf-8"?> <ead xmlns="▇▇▇▇://▇▇▇▇.▇▇▇▇▇▇▇▇▇▇.▇▇▇/schema/" xmlns:xsi="▇▇▇▇://▇▇▇.▇▇.▇▇▇/2001/XMLSchema- instance" xsi:schemaLocation="▇▇▇▇://▇▇▇▇.▇▇▇▇▇▇▇▇▇▇.▇▇▇/schema/ ../../schemas/ead3.xsd"> <control> <recordid>f323992d-bfa0-4586-bc1b-090d06ec6a72</recordid> <filedesc> <titlestmt> <titleproper>Personal letters of Mr Private Person</titleproper> </titlestmt> </filedesc> <maintenanceagency> <agencyname>National Archives of Utopia</agencyname> </maintenanceagency> <maintenancehistory> <maintenanceevent> <eventtype value="created"></eventtype> <eventdatetime>2016-07-08T08:50:52.1200000</eventdatetime> <agenttype value="human">text</agenttype> <agent>Utopian Recordsmanager</agent> </maintenanceevent> </maintenancehistory> </control> <archdesc level="series"> <did> <unitid label="current">FNS.11-2</unitid> <abstract>Personal letters of Mr Private Person</abstract> <origination label="Creator"> <name> <part>Mr Private Person</part> </did> <dsc> <c level="item"> <did> <unitid localtype="current">FNS.112-2-1</unitid> <unittitle>Report 01</unittitle> <unitdate datechar="created">20.01.2008</unitdate> <abstract>Report No. 3</abstract> <physdescstructured coverage="whole" physdescstructuredtype="spaceoccupied"> <quantity>0.0138</quantity> <unittype>MB</unittype> </physdescstructured> <dao id="c90fc089-1986-4473-8a9f-55d6a73ee9dc" daotype="borndigital" ...
EAD. Since geodata IP’s are in general a subtype of a SMURF SFSB, all the requirements for EAD metadata are equal to the specifications mentioned in the chapter 3.5.
EAD. Descriptive metadata are used to describe the intellectual contents of archival holdings, and they support finding and understanding individual information packages. The E-ARK project allows for the inclusion of any kind of descriptive metadata in the E-ARK IP54. These go into the ‘descriptive/’ folder as seen in the example below, Figure 3 (cf. EAD.xml). The METS descriptive metadata element <dmdSec> references descriptive metadata as seen in Figure 4 below and as such descriptive metadata are not to be included into the METS file. The EAD file has three main inputs (Figure 5 below): ● Archival descriptions. Contains main archival descriptions (including metadata about aggregations and classification). 54 For E-ARK pilots, most of the Access Software used the EAD3 standard. They can however be tweaked to use other descriptive metadata. ● Content. Contains links to computer files and folders as <dao> elements and @base attributes respectively. ● Additional metadata. Specific information that does not fit into the EAD3 standard elements can be saved as <odd> elements or localtype attributes in EAD3 elements (see localtype example below in section ‘Search’).
EAD. In order to describe a database in EAD it is suggested that the value of the attribute level should be set to “otherlevel” and that the value in the following otherlevel attribute should be set to “database”, see the following example where a database description is at the highest hierarchical level: <archdesc level="otherlevel" otherlevel="database" lang="eng"> <did> <unittitle>Northwind database</unittitle> <dao daotype="borndigital" href="/representations/AVID.SA.18006_rep0/data/northwind.siard"></dao> <unitdate>2000-2008</unitdate> <abstract lang="eng">Northwind Traders Access database is a sample database from Microsoft Office suite. The Northwind database contains the sales data for a fictitious company called Northwind Traders, which imports and exports specialty foods from around the world. The database contains 13 tables and also includes pictures of foods and employees. </abstract>