Report on Standards

Charles Riondet, Laurent Romary, Annelies van Nispen, Kepa Joseba

Rodriguez, Mike Bryant

<figure><img src="image_1.png" /></figure>

To cite this version:

Charles Riondet, Laurent Romary, Annelies van Nispen, Kepa Joseba Rodriguez, Mike Bryant. Report on Standards. [Contract] D.11.4, Inria Paris. 2017. hal-01503235

HAL Id: hal-01503235

https://inria.hal.science/hal-01503235

Submitted on 6 Apr 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>
European Holocaust Research Infrastructure
H2020-INFRAIA-2014-2015
GA no. 654164

D.11.4

Report on Standards

Charles Riondet, Laurent Romary
(Inria)

Annelies Van Nispen

(NIOD Institute for War, Holocaust and Genocide Studies)

Kepa Rodriguez
(Yad Vashem)

Mike Bryant
(King's College)

Due: M24

Actual: M23

<figure><img src="image_3.png" /></figure>
## Document Information

<table><tr><td>Project URL</td><td>www.ehri-project.eu</td></tr><tr><td>Document URL</td><td></td></tr><tr><td>Deliverable</td><td>D.11.4 : Report on standards</td></tr><tr><td>Work Package</td><td>WP11</td></tr><tr><td>Lead Beneficiary</td><td>17 Inria</td></tr><tr><td>Relevant Milestones</td><td></td></tr><tr><td>Dissemination level</td><td>Public</td></tr><tr><td>Contact Person</td><td>Charles Riondet (charles.riondet@inria.fr)<br/>Laurent Romary (laurent.romary@inria.fr)</td></tr><tr><td>Abstract<br/>(for dissemination)</td><td>This document addresses the role of standards as a means to facilitate the integration of heterogeneous sources in the context of the EHRI project. More precisely the problem at hand is to combine data coming from a network of archives in order to create an interoperable data environment where it is possible to search, retrieve and disseminate its content in the general of archival based research. The scholarly purpose has specific consequences on our task. First, it presupposes that the information made available to the researcher is as close as possible to the originating source in order to guarantee that the ensuing analysis can be judged reliable. Second, it is important to be able to quote any source of information that has been used for a given analysis, which implies the data sets are properly traced and second that anyone can refer back to it by means of a stable and univocal referring mechanism.</td></tr><tr><td>Management Summary</td><td>This document describes mechanisms where interoperability of data is ensured with the use of standards. The standards we covered are both domain related, the archival standards in XML formats such as EAD, EAC-CPF and EAG, and transversal standards, whose use is recommended in the context of any digital project, in particular the ISO standards for the representation of language, script and countries.<br/>Interoperability of archival descriptions expressed in EAD is made possible with the specification of a specific EAD profile for EHRI. This profile is built and maintained using the TEI-ODD framework,</td></tr></table>
which is explained of the first section of the report.

Interoperability and reusability of EHRI resources is also ensured with the design of more consistent URLs, composed with standardised methods and using ISO reference codes. This design has to be seen as a first step through a persistent identifier system.

The work initiated in WP11 and presented in this document will be continued, enhanced and developed by other EHRI work packages, WP7 Virtual Access to EHRI Virtual Observatory, WP10 Resource Identification and Integration Workflows and WP13 Research Data Infrastructures for Holocaust Material.
# Table of Contents

1. Introduction 5

2. EHRI-EAD: Contribution to the mapping and the validation of archival descriptions 7

2.1 Customizing and maintaining EAD with TEI-ODD 7

2.1.1 EAD maintenance issues 7

2.1.2 Archive portals and EAD: use cases 8

2.1.3 Project-oriented EAD schemas with TEI-ODD 10

2.2 The EAD specification in ODD 11

2.2.1 The ODD syntax 11

2.2.2 Describing the EAD format in TEI-ODD : overview 15

2.3 Creating an EHRI-EAD schema 18

2.3.1 Typology of the constraints 18

2.3.2 Creating the customized EAD schema 21

2.4 Use of the schema in the mapping and validation workflow 31

2.4.1 Technical validation: conformance with EAD 31

2.4.2 Qualitative validation: conformance with EHRI-EAD 32

3. EHRI-EAC and EHRI-EAG: work in progress 34

4. Contribution to the design of consistent URLs in EHRI 34

4.1 Introduction 34

4.2 Rationale for using consistent URLs in EHRI 35

4.2.1 Principles 35

4.3 Proposals summary 37

4.4 Implementation issues 38

5. Summary 39

6. Bibliography 40

7. Annex: Full documentation of the EHRI_EAD schema (version 1, March 2017) 41
# 1. Introduction

This document addresses the role of standards as a means to facilitate the integration of heterogeneous sources in the context of the EHRI project. More precisely the problem at hand is to combine data coming from a network of archives in order to create an interoperable data environment where it is possible to search, retrieve and disseminate its content in the general of archival based research. The scholarly purpose has specific consequences on our task. First, it presupposes that the information made available to the researcher is as close as possible to the originating source in order to guarantee that the ensuing analysis can be judged reliable. Second, it is important to be able to quote any source of information that has been used for a given analysis, which implies the data sets are properly traced and second that anyone can refer back to it by means of a stable and univocal referring mechanism.

In the EHRI network of archives, as already observed in the EU Cendari project before, one cannot but face heterogeneity by nature. EHRI's mission is to support Holocaust research by providing online access to information on dispersed sources relating to the Holocaust through its online portal (http://portal.ehri-project.eu). This portal puts together descriptions from more than 1900 institutions. Each archive comes with a whole range of idiosyncrasies corresponding to the way they have been set up and have evolved over time. Cataloging practices may differ. Even the degree of digitization may range from the absence of a digital catalogue to the provision of a full fledged online catalogue with all the necessary APIs for anyone to query and extract content. There is indeed a contrast here with the global endeavour at international level to develop and promote standards for the description of archival content at large.

Still in a project like EHRI, standards should play a central role. They are necessary for many task related to the integration and exploitation of the aggregated content, namely:

* The possibility to compare the content of the various sources, thus being able to develop quality-checking processes;

* The definition of an integrated repository infrastructure where the content of the various archival sources can be reliably hosted;

* The capacity to query and re-use content in a seamless way;

* The deployment of tools that have been developed independently of the specificities of the information sources, for instance in order to visualise or mine the resulting pool of information.

One central aspect of the work described in this document is the assessment of the role of the EAD (Encodeed Archival Description) standard as the basis for achieving the tasks described above. The development of EAD was initiated in 1993 at the Library of Berkeley, with the idea of building a non proprietary format for finding aids, reflecting the hierarchical structuration of archival fonds. If preliminary attempts were expressed in SGML, the first version of EAD used XML, and was released in 1998. A second version were soon released in 2002, EAD2002, which is still widely used. It is maintained by the Library of Congress and the Society of American Archivists. In 2010, a global revision process was initiated, in order
to make EAD more connected to the Linked Data technologies, and to reach a better
integration with the others XML archival formats: EAC-CPF and EAG.

Still, we have tried to go further the simple application of one or the other version of EAD, we
have devised how we could have a real strategy of defining specific customisation of EAD
that could be used at various stages of the process of integrating heterogeneous sources.
While doing so, we have developed a methodology based on a specification and
customisation method inspired from the long lasting experience of the Text Encoding
Initiative (TEI) community. In the TEI framework, as we show in Section 2.1, one has the
possibility of model specific subset or extensions of the TEI guidelines while maintaining both
the technical (XML schemas) and editorial (documentation) content within a single
framework. This work has lead us quite far in anticipating that the method we have
developed may be of a wider interest within similar environments, but also, as we imagine it,
for the future maintenance of the EAD standard.

Finally this work can be seen as part of the wider endeavour of research infrastructures in the
humanities such as CLARIN and DARIAH to provide support for researchers to integrate the
use of standards in their scholarly practices. This is the reason why the general workflow
studied here has been introduced as a use case in the umbrella infrastructure project
Parthenos which aims, among other things, at disseminating information and resources
about methodological and technical standards in the humanities.
## 2. EHRI-EAD: Contribution to the mapping and the validation of archival descriptions

### 2.1 Customizing and maintaining EAD with TEI-ODD<fnref n="1" />

#### 2.1.1 EAD maintenance issues

*Developing international consensus on a standard for archival description is a daunting challenge. Cultural differences and established and differing theories and practices are at the core of the challenge. [EGAD ICA, 2016]*

The challenge expressed by the Experts group on archival description has been tackled since 1993 with the development of the Encoded Archival Description (EAD) [Library of Congress, 2013, which has successfully developed a standard format usable by a wide range of archives and archivists worldwide, making possible the transcription of printed finding aids, as well as the description of archival records according to diverging national or institutional practices. However, the limit of such an approach is that EAD is a very permissive standard, where each institution (each archivist), and each piece of software can have their own way of creating EAD, and the same material can be described in totally different ways. The first example that comes to mind is the choice to let the archivist use <c> or <c01>, <c02>, ... to describe sub-components. Documenting guidelines used by an institution, or a group of institutions, or in a particular context (a thematic portal for example). Therefore, it is important to document specific guidelines by institutions or from specific contexts.

The agencies responsible for the maintenance of archival standards developed several important initiatives in order to gain interoperability. EAD3, developed by the Library of Congress<fnref n="2" /> and the Society of American Archivists<fnref n="3" /> with the cooperation of many archivists worldwide, is a big step towards interoperability even though many archives consider the change towards EAD3 as a mid-term perspective. On the other hand, since 2012, the International Council on Archives is building the content model *Records in Context*, a descriptive standard that reconciles, integrates, and builds on its four existing standards: General International Standard Archival Description (ISAD(G)), International Standard Archival Authority Records - Corporate Bodies, Persons, and Families (ISAAR(CPF)), International Standard for Describing Functions (ISDF) and International Standard for Describing Institutions with Archival Holdings (ISDIAH). This initiative will also contribute to provide a solid framework for exchanging archival data more easily.

The maintenance issue of EAD, assumed by the Society of American Archivists and the Library of Congress, is still a big issue. The maintenance of a standard requires in any case discussions to achieve consensus, and any major revision should undergo a precise and

<footnote n="1">¹ for clarification purposes, the code samples presented in this article come with prefixes : "rgn" for RelaxNG elements, "tei" for TEI(ODD) and "ead" for EAD.</footnote>

<footnote n="2">² http://www.loc.gov/ead/</footnote>

<footnote n="3">³ http://www2.archivists.org/groups/technical-subcommittee-on-encoded-archival-description-ead/encoded-archival-description-ead</footnote>
complete process, but some little corrections and adjustments are sometimes welcome in the
meantime. Between EAD 2002 and EAD3, more than ten years passed and some features
introduced in 2015 had been requested by the community many years before, even minor
changes. For example, some users asked for a typing attribute for the
<ead:addressline> element, a child of <ead:address> [EAD working group AFNOR].
This small modification was introduced in EAD3, as a part of the general revision process,
that lasted five years. Maybe we could imagine a smoother evolution of the standard, based
on continuous maintenance, on the model of the TEI consortium that updates its standard
continuously on GitHub. In this respect, the fact that the development of EAD3 took actually
place on GitHub opens the way to this more continuous maintenance.

## 2.1.2 Archive portals and EAD: use cases

The experience gained from concrete use cases showed how strong the need is to build
interoperability solutions between heterogeneous archival descriptions in EAD.

The Archives Portal Europe project (https://www.archivesportaleurope.net/) gathers archival
descriptions from all the European countries and have made a first effort to implement
common European profiles of EAD, EAC-CPF (Encoded Archival Context – Corporate
Bodies, Persons and Families), EAG (Encoded Archival Guide) and METS (Metadata
Encoding and Transmission Standard). Specific schemas were created, in particular
apeEAD, a subset of EAD2002, which "was drafted on the basis of a comparison of EAD
profiles and practices of the National Archives participating in the project"<fnref n="4" />.

European funded research infrastructures tackled this issue of interoperability of archival
descriptions as well, with an additional focus on specific research communities, with specific
needs.

In the context of two H2020 Research infrastructures projects which manipulate archival
data, Cendari (Collaborative European Digital Archival Research Infrastructure)<fnref n="5" /> on medieval
and modern European history and EHRI, different solutions were proposed. In the Cendari
virtual research environment, where researchers have the possibility to select descriptions
originating from various sources and create their own collections, EAD was customized with
the addition of elements dedicated to the researchers uses. For instance, it was important to
give access to a more complex structuration of bibliographic sources [Medves, Romary,
2013].

For the EHRI project, on which we will focus, the problem is slightly different. Researchers
are not (yet) allowed to create their own descriptions, but the heterogeneity of the archival
descriptions which have to be collected in a single pool, and processed uniformly, make it
necessary to create a straightforward workflow for the ingestion of archival data in the portal
database. EHRI coordinates the activity of 24 institutions (among which research bodies,
archives, libraries, ...), but its archival portal hosts descriptions from 1 922 institutions. An
extra challenge for EHRI is that Holocaust archives are hidden, often dispersed in several
institutions or several fonds. Moreover, EHRI wants to focus on Eastern Europe, where few
archives are digitally advanced, due to the lack of funding or technical infrastructures. These

<footnote n="4">⁴ http://apex-project.eu/index.php/en/outcomes/standards/apeead</footnote>

<footnote n="5">⁵ cendari.eu</footnote>
descriptions can be manually entered by EHRI staff, but the preferred method is
semi-automatic ingestion of XML files in the database. Due to the variety of institutions
providing data, EHRI has to deal with a great heterogeneity of data formats and of EAD
flavours. EHRI uses EAD2002 since the beginning of the project in 2011. In 2015, a
discussion arose about the opportunity to move towards EAD3, that was just released, but
the lack of visibility on its spread in the archival community during the four years of the
project made this choice too risky.

The use of EAD in EHRI takes place at the two sides of the workflow: the ingestion and the export of archival descriptions. EAD2002 is the pivot format for semi-automatically ingestion of data in EHRI database, which is built with GraphDB, its data model is based on the ICA standards – ISAD(G) and ISAAR-CPF, combined with extra administration fields. It is also used as an exchange format, with the ability given to the users of the portal to download any content of the portal in XML-EAD (or EAC and EAG for authorities and institutions). Therefore, there is a strong need for both valid and customized EAD (and EAC-CPF) schemes, for two kind of tasks : The first one is the possible mapping of the data to XML-EAD if the descriptions are not provided in this format. The second one is a validity check to be sure the EAD is in conformity with EHRI requirements.

<figure><img src="image_4.png" /></figure>

Source archives

The scheme above present the workflow of archival data in the EHRI portal. The archival
materials provided by the institutions can be processed in two different ways. If they are not
described in EAD2002, they are directly mapped to the customized EHRI EAD format. If they
are in EAD2002, we automatically check if the EAD flavour in input is compatible with the
customized EHRI EAD format. If some adjustments are necessary, they can either be made by the provider himself of by the same EHRI mapping mechanism mentioned before. Then, the formatted XML document can be processed again in order to populate EHRI database.

### 2.1.3 Project-oriented EAD schemas with TEI-ODD

There are several methods to create project-oriented schemas. The most immediately obvious method is to modify the DTD or the schema by hand to narrow down the possibilities in a given context. This solution is however rejected because it is too restrictive and creates other complications: It's harder to keep the history of changes, and schema validation errors provide a technical message, but not an archivist oriented message.

The solution we propose is based on a flexible and customizable methodology: It combines the complete description of the specifications in a machine-readable way, and customization facilities, easy to understand for the end-user. More important, this solution doesn't change the core EAD schema, but add more specific rules in a comprehensive and human-readable format, by combining the EAD schema (expressed in RelaxNG) with ISO Schematron rules. Schematron is an ISO/IEC Standard (ISO/IEC 19757-3:2016) that parses XML documents and makes "assertions about the presence or absence of patterns"<fnref n="6" />. It can be used in conjunction with a lot of grammar languages such as DTD, relaxNG, ...

In our case, this combination is made using the Text Encoding Initiative (TEI). This format is broadly recognized as the *de facto* standard for the representation of text in digital form, but TEI can be used to represent almost any digital resource. For instance, the TEI XML schema and the associated guidelines are maintained with the TEI format, more precisely, with a subset called "One Document Does it all" (ODD) which, as the name indicates, is a description language that "includes the schema fragments, prose documentation, and reference documentation [...] in a single document"<fnref n="7" />, based on the principles of literate programming. Literate programming is a programming and documentation methodology whose "central tenet is that documentation is more important than source code and should be the focus of a programmer's activity"[Walsh 2002]. With ODD, semantic and structural consistency is ensured as we encode and document best practices in both machine and human-readable format. ODD was created at first to give TEI users a straightforward way to customize the TEI schema according to their own practices and document this customization. But it is possible to describe a schema and the associated documentation of any XML format. More, if ODD is a description language, it can be processed to generate an actual schema (a DTD, an RelaxNG XML or compact schema and an XML schema), and documentation in various formats (XHTML, PDF, EPUB, docx, odt). We used ODD to encode completely the EAD standard, as well as the guidelines provided by the Library of Congress<fnref n="8" />.

<footnote n="6">⁶ http://www.schematron.com/, accessed on November 2d, 2016.</footnote>

<footnote n="7">⁷ http://www.tei-c.org/Guidelines/Customization/odds.xml</footnote>

<footnote n="8">⁸ http://loc.gov/ead</footnote>
## 2.2 The EAD specification in ODD<fnref n="9" />

### 2.2.1 The ODD syntax

The EAD ODD is a XML-TEI document made up of three main parts. The first one is, like any other TEI document, the `<tei:teiHeader>`, that comprises the metadata of the specification document. Here we state, among others pieces of information, the sources used to create the specification document in a `<tei:sourceDesc>` element. Our two sources are the EAD Tag Library<fnref n="10" /> and the RelaxNG XML schema<fnref n="11" />, both published on the Library of Congress website. The second part of the document is a presentation of our method (the foreword) with an introduction to the EAD standard and a description of the structure of the document. This part contains some text extracted from the introduction of the EAD Tag Library.

The third part is the schema specification itself: the list of EAD elements and attributes and the way they relate to each others. The most important elements to understand the way ODD works are the following:

* Schema specification: `<tei:schemaSpec>`

The top-level ODD element is `<tei:schemaSpec>`. Its attributes are @start, which state "which patterns may be used as the root of documents conforming to it"<fnref n="12" /> and @ns, for the namespace of the document.

* Element specification: `<tei:elementSpec>`

Each EAD element is described in a `<tei:elementSpec>` element, where the encoded information combines the element documentation in textual and machine interpretable form. These element declarations are connected to classes declarations. In TEI, elements are members of one or more classes.

* Class specification: `<tei:classSpec>`

A class is "a group of elements which appear together in content models, or which share some common attribute, or both"<fnref n="13" />. Classes are defined by the `<tei:classSpec>` element.

<footnote n="9">⁹ The EAD guidelines and schema encoded with ODD can be found here: https://github.com/ParthenosWP4/standardsLibrary/blob/master/archivalDescription/EAD/odd/EADSpec.xml, accessed on March 28th, 2017</footnote>

<footnote n="10">¹⁰ http://www.loc.gov/ead/tglib/index.html</footnote>

<footnote n="11">¹¹ http://www.loc.gov/ead/ead.rng</footnote>

<footnote n="12">¹² TEI Guidelines Version 3.1.0, element schemaSpec (schema specification), http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-schemaSpec.html (accessed on January 12th, 2017)</footnote>

<footnote n="13">¹³ TEI Guidelines Version 3.1.0, element classSpec (class specification), http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-classSpec.html (accessed on January 12th, 2017)</footnote>
In our ODD specification, we encoded as classes the modules defined in the EAD RelaxNG schema. But RelaxNG modules and TEI classes enact differently. In RelaxNG, the module contains a pattern giving the possible descendant nodes (elements, attributes, modules), whereas the `<tei:classSpec>` element declares its membership to upper modules. In other words, RelaxNG has a top-down behaviour (modules lists their members) and TEI ODD has a bottom-up behaviour (each element or class lists their membership to a class). For instance, the module called `"m.phrase.basicConfig"` which contains the elements `<ead:abbr>` and `<ead:expan>`, and the module `"m.phrase.bare"` becomes the class `"model.phrase.basicConfig"` have different contents:

<table><thead><tr><th>RelaxNG</th><th>ODD</th></tr></thead><tbody><tr><td><pre><code>&lt;rgn:define name="m.phrase.basicConfig">&lt;rgn:choice&gt; &lt;rgn:ref name="m.phrase.bare"/&gt; &lt;rgn:ref name="abbr"/&gt; &lt;rgn:ref name="expan"/&gt; &lt;/rgn:choice&gt; &lt;/rgn:define&gt;</code></pre></td><td><pre><code>&lt;tei:classSpec ident="model.phrase.basicConfig" type="model" module="EAD"&gt; &lt;tei:classes&gt; &lt;tei:memberOf key="model para content.nrefs"/&gt; &lt;tei:memberOf key="model.phrase.Plus"/&gt; &lt;tei:memberOf key="model.phrase.Basic"/&gt; &lt;/tei:classes&gt; &lt;/tei:classSpec&gt;</code></pre></td></tr></tbody></table>

The information contained in `<rgn:define name="m.phrase.basicConfig">` is encoded in the element specification of `<ead:abbr>` and `<ead:expan>` and in the class specification of the class corresponding to the RelaxNG module `"m.phrase.bare"`:

`<tei:elementSpec ident="abbr" module="EAD">`

`...`

`<tei:classes>`

`&lt;tei:memberOf key="att.EADGlobal"/&gt;`

`&lt;tei:memberOf key="model.phrase.basicConfig"/&gt;`

`</tei:classes>`

`...`

`</tei:elementSpec>`

`<tei:elementSpec ident="expan" module="EAD">`

`...`

`<tei:classes>`

`&lt;tei:memberOf key="att.EADGlobal"/&gt;`

`&lt;tei:memberOf key="model.phrase.basicConfig"/&gt;`

`</tei:classes>`

`...`

`</tei:elementSpec>`

`<tei:classSpec`

`ident="model.phrase.bare"`

`type="model"`

`module="EAD">`

`<tei:classes>`
```xml
<tei:memberOf key="model.phrase.basicConfig"/>
</tei:classes>
</tei:classSpec>
```

### Content declaration: `<tei:content>`

`<content>` contains the machine-readable schema declaration of the content of the described element. It may be defined with a set of TEI ODD elements, or by using RelaxNG patterns (the solution we use in this particular case). In that case, some patterns contained in the RelaxNG `<rang:element>` are copied and declared in the RelaxNG namespace. It's the case for the patterns declaring which nodes are accepted as child of a given element.

Taking for example the element `<ead:unittitle>`, we can see that most of the element declaration sequence is the same in the RelaxNG schema and in the EAD ODD :

<table><thead><tr><th>RelaxNG</th><th>ODD</th></tr></thead><tbody><tr><td><pre><element name="unittitle" <ref name="a.common"/><optional><attribute name="label"/></</optional><optional><attribute name="encodinganalog"/></</optional><optional><attribute name="type"/></</optional><zeroOrMore><choice><text/><ref name="m.phrase.basicConfig"/><ref name="m.access"/><ref name="unitdate"/><ref name="num"/><ref name="date"/><ref name="bibseries"/><ref name="edition"/><ref name="imprint"/><</choice><</zeroOrMore></element></pre></td><td><pre><elementSpec ident="unittitle" module="EAD" <!-- <tei:gloss> and <tei:desc> --> <classes> <memberOf key="att.EADGlobal"/><memberOf key="att.typed"/><memberOf key="att.labeled"/><memberOf key="model.data"/><memberOf key="model did"/></</classes><content> <rang:zeroOrMore> <rang:choice> <rang text/><rang ref name="model.phrase.basicConfig"/><rang ref name="model.access"/><rang ref name="unitdate"/><rang ref name="num"/><rang ref name="date"/><rang ref name="bibseries"/><rang ref name="edition"/><rang ref name="imprint"/><</choice><</rang:zeroOrMore></content> <!-- <tei:exemplum> and <tei:remarks> elements --> </elementSpec></pre></td></tr></tbody></table>
## Attributes definition

The available attributes for a given element are specified in a different way in ODD and in RelaxNG. In ODD, the attributes definition are always part of a list - `<tei:attList>` – that contains elements for each attribute – `<tei:attDef>`. However, ODD and RelaxNG share the same use of data types declaration for attributes, ODD borrows some RelaxNG elements, for instance `<rang: data>`:

<table><thead><tr><th>RelaxNG</th><th>ODD</th></tr></thead><tbody><tr><td><attribute name="otherlevel"><data type="NMTOKEN"/></attribute></td><td><attList><attDef ident="level"/><attDef ident="otherlevel"><desc>...</desc><datatype><rang: data type="NMTOKEN"/></datatype><remarks>...</remarks></attDef></attList></td></tr></tbody></table>

In the EAD RelaxNG schema, attributes used by more than one element can be defined independently, and are then referenced with the element `<rang: attribute>` or `<rang: ref>` in the case where a group of attributes are defined together. In the EAD ODD, we created extra attributes classes for attributes that are used by more than one element, and uses the class membership method to add attributes to an element. Following with `<ead: unittitle>`, we have:

<table><tr><td><rang:ref name="a.common"/><rang:optional><rang:attribute name="label"/></rang:optional><rang:optional><rang:attribute name="encodinganalog"/></rang:optional><rang:optional><rang:attribute name="type"/></rang:optional></td><td><tei:classes><tei:memberOf key="att.EADGlobal"/><!-- the class "att.EADGlobal" is similar to the RelaxNG attribute module "a.common" + contains also the attribute @encodinganalog --><tei:memberOf key="att.typed"/><!-- class for the attribute @type --><tei:memberOf key="att.labeled"/><!-- class for the attribute @label -->...<tei:classes></td></tr></table>
### 2.2.2 Describing the EAD format in TEI-ODD : overview

The table below presents an overview of the main elements described above, with an explanation of their particular use in the EAD-ODD.

<table><thead><tr><td>ODD element or attribute</td><td>Definition (taken from the TEI guidelines)</td><td>Use in EAD ODD</td><td>Examples</td></tr></thead><tbody><tr><td>elementSpec/@ident (identifier)</td><td>supplies the identifier by which this element may be referenced.</td><td></td><td>&lt;elementSpec ident="archdesc" ...&gt;</td></tr><tr><td>elementSpec/@module</td><td>supplies a name for the module in which this object is to be declared.</td><td>In our case, we have only one module, which is EAD.</td><td>&lt;elementSpec module="EAD" ...&gt;</td></tr><tr><td>gloss</td><td>a phrase or word used to provide a gloss or definition for some other word or phrase.</td><td>&lt;gloss&gt; contains the complete name of the element, as stated in the tag library</td><td>&lt;gloss&gt;Appraisal Information&lt;/gloss&gt;</td></tr><tr><td>desc (description)</td><td>a brief description of the object documented by its parent element, typically a documentation element or an entity</td><td>In the EAD ODD, the value of &lt;desc&gt; is the first half of the tag LIbrary description, which gives a formal definition of the element and which kind of information it must contain. (see also the &lt;remarks&gt; element</td><td>&lt;desc&gt;A &lt;gi&gt;physdesc&lt;/gi&gt; subelement for information about the quantity of the materials being described or an expression of the physical space they occupy. Includes such traditional archival measurements as cubic and linear feet and meters; also includes counts of microfilm reels, photographs, or other special formats, the number of logical records in a database, or the volume of a data file in bytes.&lt;/desc&gt;</td></tr><tr><td>classes/memberOf/@key</td><td>specifies all the classes of which the documented element or class is a member or subclass.</td><td></td><td>&lt;classes&gt;<br/>&lt;memberOf key="model.phrase.xml"/&gt;<br/>&lt;/classes&gt;</td></tr></tbody></table>
<table><tr><td>content (content model)</td><td>contains the text of a declaration for the schema documented</td><td>We copy the RelaxNG schema, but in the case where elements are defined as descendants of others elements (for instance, an XPath such as : <code>rng:define/rng:element /rang:element</code>), we create and independent <code>tei:elementSpec</code>, and we link put a corresponding <code>rng:ref</code> in the first element definition</td></tr><tr><td>attList/attDef</td><td>contains documentation for all the attributes associated with this element</td><td>In <code>attDef</code>, documentation elements such as <code>&lt;desc&gt;</code> are also used, as well as specification ones, in particular the <code>&lt;datatype&gt;</code> element which define the value the attribute can have.<br/><code>&lt;attList&gt;</code><br/><code>&lt;attDef ident="mainagencycode">&lt;desc&gt;</code> A code compliant with ISO/DIS 15511 Information and Documentation International Standard Identifier for Libraries and Related Organizations (ISIL).&lt;/desc&gt;<br/><code>&lt;datatype&gt;</code><br/><code>&lt;rang(text)/&gt;</code><br/><code>&lt;/datatype&gt;</code><br/><code>&lt;remarks&gt;</code><br/><code>&lt;p&gt;Values should be supplied without the country code, which should be placed instead in the COUNTRYCODE attribute.&lt;/p&gt;</code><br/><code>&lt;/remarks&gt;</code><br/><code>&lt;/attDef&gt;</code><br/><code>&lt;attDef ident="url">&lt;desc&gt;An absolute (http://www.loc.gov/ead/ms99999.xml) or relative (ms99999.xml) Uniform Resource Locator.&lt;/desc&gt;</code><br/><code>&lt;datatype&gt;</code><br/><code>&lt;rang(text)/&gt;</code><br/><code>&lt;/datatype&gt;</code><br/><code>&lt;/attDef&gt;</code><br/>...</code>&lt;/attList&gt;</td></tr><tr><td>exemplum</td><td>groups an example demonstrating the use of an element</td><td><code>&lt;exemplum&gt;</code><br/><code>&lt;teix:egXML&gt;</code><br/><code>&lt;eadheader langencoding="iso639-2b" xmlns="urn:ibn:1-931666-22-9"&gt;</code><br/><code>&lt;eadid&gt;[...]&lt;/eadid&gt;</code></td></tr></table>
<table><caption>Table 1: Sub elements of ODD <elementSpec> used in the EAD ODD</caption><tr><td></td><td>along with optional paragraphs of commentary.</td><td><filedesc>[...]</filedesc><br/><profiledesc>< creation>[...]</creation>< langusage>Bilingual finding aid written in <language langcode="fre">French</language> and <language langcode="eng">English.</language>< langusage>< /langusage>< /profiledesc>< eadheader>< /teix:egXML></exemplum></td></tr><tr><td>remarks</td><td>contains any commentary or discussion about the usage of an element, attribute, class, or entity not otherwise documented within the containing element.</td><td><remarks>< p>The <gi>physdesc</gi> element is comparable to ISAD(G) data element 3.1.5 and MARC field 300.</p>< /remarks></td></tr></table>
## 2.3 Creating an EHRI-EAD schema

As we said, the power of ODD lies on its abilities of customization. It is possible and straightforward to create and document specific profiles (or EAD flavours) for an institution, a group of institutions (in a given country for example) or a portal. For EHRI, we created another ODD to document the specific rules and constraints of the EHRI data model.

In this new ODD file, called EHRI_EAD.odd, the generic EAD specification is imported and serves the baseline of specification. The additional constraints are added only to the elements that they refer to. Therefore, the EHRI_EAD.odd file only contains the `<tei:elementSpec>` and `<tei:classSpec>` that are modified. The merge of the two ODD files – the EAD generic and the EHRI specific – is made when we apply a transformation<fnref n="14" />.

### 2.3.1 Typology of the constraints

The constraints that we need to add to EAD in order to ensure a smooth ingestion of descriptions in the database are of two types. First, some EAD elements are required for the good functioning of the database, for instance unique identifiers for all the descriptions (contained in `<ead:eadid>`). Second, some elements are made mandatory for more qualitative reasons: for instance, to ease the discoverability of its resources, EHRI wants that a minimal description in English is provided with each description unit. Another example is the fact that EHRI encourage the use of ISO standards for the representation of languages, scripts, dates, etc, as well as the interlinkage of entities, via the use of authority lists.

Many Schematron rules were already used in EHRI, so we integrated them directly in the EHRI-EAD ODD<fnref n="15" />. They are extensively listed in section 2.3.2. The table below lists additional constraints spotted in the EHRI guidelines.

<table><thead><tr><td>ISAD(G) field concerned by the constraint</td><td>Corresponding EAD elements or paths</td><td>Expression of the constraint</td></tr></thead><tbody><tr><td>Reference codes<br/>ISAD(G) 3.1.1</td><td>ead:eadid<br/>ead:unitid</td><td>Copy the reference number given by the collection-holding institution</td></tr><tr><td>Other forms of title</td><td>ead:proper<br/>ead:unititle</td><td>It is an EHRI requirement to provide English translations of non-English language titles</td></tr><tr><td>Dates<br/>ISAD(G) 3.1.3 for dates of the descriptions units</td><td>ead:-date<br/>ead:unitdate</td><td>Follow the ISO 8601 standard (Data elements and interchange formats -- Information interchange</td></tr></tbody></table>

<footnote n="14">¹⁴ http://www.tei-c.org/Guidelines/Customization/odds.xml#body.1_div.2_div.7</footnote>

<footnote n="15">¹⁵ https://github.com/EHRI/data-validations/blob/master/schematron/ehri_ead.sch</footnote>
<table><tr><td></td><td></td><td>-- Representation of dates and times.)<br/>The standardized form is YYYY-MM-DD</td></tr><tr><td>Level of description<br/>ISAD(G) 3.1.4</td><td>ead:archdesc/@level<br/>ead:c{01-06}/@level</td><td>ISAD(G) 3.1.4 has a predefined list of units. As EHRI works with archives and collections that have not been arranged according to traditional rules, the terms used for the levels of description might also deviate. It is therefore chosen that this list should be flexible and expandable.</td></tr><tr><td>Archival history</td><td>ead:custodhist<br/>ead:acqinfo</td><td>3.2.4 "Immediate source of acquisition or transfer" has been included in this element.</td></tr><tr><td>Access points</td><td>ead:controlaccess/ead:subject<br/>ead:controlaccess/ead:placement<br/>ead:controlaccess/ead:person<br/>ead:controlaccess/ead:famname<br/>ead:controlaccess/ead:corpname<br/>ead:controlaccess/ead:geogname</td><td>Wish to support linkage with EHRI authorities lists, thesauri or international recognized gazetteers (like Geonames for plan names).</td></tr><tr><td>Languages of materials<br/>ISAD(G) 3.4.3</td><td>ead:language/@langcode</td><td>Mandatory in EHRI<br/>Its value must be in the ISO 639-1 or ISO 639-2 lists (International Standards for Language Codes).</td></tr><tr><td>Scripts of materials<br/>ISAD(G) 3.4.3</td><td>ead:langmaterial/ead:language/@scriptcode</td><td>Mandatory in EHRI<br/>Its value must be in the ISO 15924 list (International Standard for Names of Scripts).</td></tr><tr><td>Existence and locations of originals<br/>ISAD(G) 3.5.1</td><td>ead:originalsloc</td><td>The link to Repository Authority list and the request for extra information is specific to EHRI</td></tr></table>
<table><caption>**Table 2 : Constraints expressed in the EHRI guidelines**</caption><tr><td>Existence and locations of copies</td><td>ead:altformavail</td><td>The link to Repository Authority list is specific to EHRI</td></tr><tr><td>Publication note</td><td>ead:bibliography</td><td>Combination of guidelines from ISAD(G) and ISBD and Guidelines created by EHRI for describing personalities and corporate bodies.</td></tr><tr><td>Institution Identifier To identify the agency(ies) responsible for the description</td><td>ead:titlestmt/ead:author</td><td>Mandatory in EHRI</td></tr><tr><td>Language of description</td><td>ead:langusage/ead:language/@ langcode</td><td>Mandatory in EHRI Its value must be in the ISO 639-1 or ISO 639-2 lists (International Standards for Language Codes).</td></tr><tr><td>Script of description</td><td>ead:langusage/ead:language/@ scriptcode</td><td>Mandatory in EHRI Its value must be in the ISO 15924 list (International Standard for Names of Scripts).</td></tr><tr><td>Sources To identify providers of metadata descriptions, other than collection holding institutions</td><td>ead:titlestmt/ead:author</td><td>Mandatory in EHRI</td></tr><tr><td>EHRI scope To identify the extent of Holocaust related material within the total collection</td><td>ead:odd[ type="EHRI-scope"]</td><td>Desirable in EHRI</td></tr><tr><td>EHRI copyright</td><td>ead:publisher</td><td>Mandatory in EHRI</td></tr><tr><td>Rules or conventions ISAD(G) 3.7.2</td><td>ead:descrules</td><td>Mandatory in EHRI</td></tr><tr><td>Date(s) of description ISAD(G) 3/7.3</td><td>ead:processinfo/ead:p/ead:da te</td><td>Mandatory in EHRI Use of ISO 8601 standard.</td></tr></table>

Other constraints were spotted by EHRI database managers to ease the process of importing EAD documents into the database or were gathered by analysing samples from collections holding institutions (CHI). This approach will permit at the end to have a very good quality of the EAD files, based on the very specific remarks made on relevant sample files.
For instance, an emphasis has been put on the respect of basic ISO standards for such information as dates, country codes, language and script codes. This good practice, followed by the EHRI database, and for some parts by EAD, is therefore implemented as schematron rules that test the content of some elements or attributes with regular expressions. For the country codes, the language codes and the script codes, we went a beyond the use of regular expressions, and the schematron rules tests the codes found in the input description against an up-to-date list of these codes, maintained by the Parthenos projet<fnref n="16" />.

All the constraints were sorted in categories, that we call roles. The different roles are:

* MUST: mandatory for import process or according to the EAD (in case we want to particularly highlight a requirement)

* SHOULD: mandatory for description process, i.e. in terms of archival description. The SHOULD rules are not technically mandatory, but if they are not respected in the input description, it would be considered as incomplete, with potential comprehension issues

* COULD: Non mandatory rules. This role gathers the rules that would enhance the general quality of the description, without any obligation for the provider to follow the recommendation. They focus on the content based element of `<ead:archdesc>`, pointing that they could be added in the description, if they are not present in the input file:

* `<ead:custodhist>`

* `<ead:otherfindaid>`

* `<ead:originalsloc>`

* `<ead:altformavail>`

* `<ead:bibliography>`

* `<ead:odd>`

* `<ead:note>`

* `<ead:controlaccess>`

This categorization is taken from the work previously done in EHRI around the preprocess of the EAD descriptions with the help of schematron rules<fnref n="17" />.

### 2.3.2 Creating the customized EAD schema

Specific profiles are derived from the ODD master source described above (the generic EAD ODD). For each new EAD profile, a new ODD must be created. It must claim its inheritance to the master source, and modify the specifications elements needed, i.e. the `<tei:elementSpec>` and `<tei:classSpec>` that have a different behaviour. To change these behaviours, there are several solutions. The first one, the simplest, is the modification of schema declaration elements: it means that the `<tei:content>`, the `<tei:attList>` or the `<tei:memberOf>` are directly modified.

Another solution, the one we favours, is the use of additional schematron rules, because it doesn't change the EAD schema and allow us to provide to the user a comprehensive feedback. We created so far 70 rules that follow the constraints expressed above, but it is

<footnote n="16">¹⁶ https://github.com/ParthenosWP4/standardsLibrary/tree/master/ISO</footnote>

<footnote n="17">¹⁷ https://cdnrawgit.com/EHRI/data-validations/master/schematron/rules.html</footnote>
very likely that new rules will be added in the next months, as long as new descriptions are ingested in the portal. There are more schematron rules than there are expressed constraints, because some rules need to be applied to more than one element.

The rules are built with the element `<sch:assert>`, which means that the error message will be displayed when the pattern is not found.

All the rules are listed in the following table, whose columns contain :

* the identifier of the rule

* The context in which the rule is applied

* The description of the rule in human-readable form, i.e. the message that the end user will get if the rule is applied

* The role, i.e. the category of the rule, as stated above (MUST, SHOULD, COULD)

* The actual pattern searched in the document by the schematron engine.

<table><thead><tr><td>identifier</td><td>context</td><td>description</td><td>role</td><td>Pattern searched</td></tr></thead><tbody><tr><td>levelRequired</td><td>ead:archdesc</td><td>&lt;ead:archdesc&gt; MUST have a @level attribute.</td><td>MUST</td><td>@level</td></tr><tr><td>levelRequired</td><td>ead:c01</td><td>&lt;ead:c01&gt; MUST have a @level attribute.</td><td>MUST</td><td>@level</td></tr><tr><td>levelRequired</td><td>ead:c02</td><td>&lt;ead:c02&gt; MUST have a @level attribute.</td><td>MUST</td><td>@level</td></tr><tr><td>levelRequired</td><td>ead:c03</td><td>&lt;ead:c03&gt; MUST have a @level attribute.</td><td>MUST</td><td>@level</td></tr><tr><td>levelRequired</td><td>ead:c04</td><td>&lt;ead:c04&gt; MUST have a @level attribute.</td><td>MUST</td><td>@level</td></tr><tr><td>levelRequired</td><td>ead:c05</td><td>&lt;ead:c05&gt; MUST have a @level attribute.</td><td>MUST</td><td>@level</td></tr><tr><td>levelRequired</td><td>ead:c06</td><td>&lt;ead:c06&gt; MUST have a @level attribute.</td><td>MUST</td><td>@level</td></tr><tr><td>dateNormal</td><td>ead:-date</td><td>All the &lt;ead:-date&gt; elements MUST have a @normal attribute whose pattern respects the ISO8601 standard and take the following form: YYYY-MM-DD</td><td>MUST</td><td>matches(@normal, '^[([0-9][1-9][0-9][1-9][0-9]{2}][1-9][0-9]{3})-(0[1-9][1[012]]-(0[1-9][12][0-9][3[01]]))$')</td></tr><tr><td>unitidRequired</td><td>ead:did</td><td>&lt;ead:did&gt; elements MUST contain &lt;ead:unitid&gt;</td><td>MUST</td><td>ead:unitid</td></tr></tbody></table>
<table><tr><td>unittitleRequired</td><td>ead:did</td><td>ead:did elements MUST contain &lt;ead:unittittle&gt;</td><td>MUST</td><td>ead:unittitle</td></tr><tr><td>unittitleNotEmpty</td><td>ead:did</td><td>a &lt;ead:did&gt; MUST have at least one non-empty &lt;ead:unittitle&gt;</td><td>MUST</td><td>count(ead:unittitle[text()]) &gt; 0</td></tr><tr><td>dscType</td><td>ead:dsc</td><td>&lt;ead:dsc&gt; MUST have a @type attribute</td><td>MUST</td><td>@type</td></tr><tr><td>dscothertype</td><td>ead:dsc</td><td>if &lt;ead:dsc&gt;'s type attribute has "othertype" for value, &lt;ead:dsc&gt; MUST have a not empty @othertype attribute</td><td>MUST</td><td>not(@type = 'othertype') or (@othertype and not(@othertype=""))</td></tr><tr><td>profiledescRequired</td><td>ead:eadheader</td><td>&lt;ead:eadheader&gt; MUST contain a &lt;ead:profiledesc&gt; element</td><td>MUST</td><td>ead:profiledesc</td></tr><tr><td>mustContainText</td><td>ead:eadid</td><td>the &lt;ead:eadid&gt; element MUST contain text. Most of the time, it is automatically generated by the archival tool.</td><td>MUST</td><td>normalize-space(.)</td></tr><tr><td>langcodeRequired</td><td>ead:language</td><td>&lt;ead:language&gt; MUST have a @langcode attribute. See also the rule on @langcode and ISO 639:</td><td>MUST</td><td>@langcode</td></tr><tr><td>langusageRequired</td><td>ead:profiledesc</td><td>&lt;ead:profiledesc&gt; MUST contain information on the language used in the EAD document, in a &lt;ead:langusage&gt; containing a &lt;ead:language&gt; element</td><td>MUST</td><td>ead:langusage/ead:language</td></tr><tr><td>normalRegex</td><td>ead:unitdate</td><td>The @normal attribute of &lt;ead:unitdate&gt; must respect the ISO8601 pattern = YYYY-MM-DD</td><td>MUST</td><td>$end-date castable as xs date</td></tr><tr><td>uniqueId</td><td>ead:unitid</td><td>In a given EAD document, all</td><td>MUST</td><td>count(//ead:unitid[@l)</td></tr></table>
<table><tr><td></td><td></td><td>the &lt;ead:unitid&gt; elements MUST be unique</td><td></td><td>abel = 'ehri_main_identifier'] ) = count(distinct-values( //unitid[@label = 'ehri_main_identifier'] ))</td></tr><tr><td>otherlevel</td><td>ead:ead</td><td>If the attribute @level has the value 'otherlevel', an attribute @otherlevel MUST be added</td><td>MUST</td><td>not(@level = 'otherlevel') or (@otherlevel and not(@otherlevel = ""))</td></tr><tr><td>descrules</td><td>ead:profiledesc</td><td>&lt;ead:descrules&gt; has a default value added automatically by EHRI. Therefore, the content of &lt;ead:descrules&gt; will be overwritten</td><td>MUST</td><td>not(normalize-space(ead:descrules))</td></tr><tr><td>familynameComma Givenname</td><td>ead:controlacc ess/ead:persna me</td><td>In the access points, person names SHOULD be structured like this : Family name, given name</td><td>SHOULD</td><td>[0-9a-zA-Z]+([0-9a-zA-Z]+)*</td></tr><tr><td>originationDesirable</td><td>ead:archdesc</td><td>&lt;ead:archdesc&gt; SHOULD contain a non-empty ead:origination element.</td><td>SHOULD</td><td>ead:did/ead:originati on and normalize-space(ead :did/ead:origination)</td></tr><tr><td>archdescProcessinf oDesirable</td><td>ead:archdesc</td><td>&lt;ead:archdesc&gt; should contain a non-empty &lt;ead:processinfo&gt; element.</td><td>SHOULD</td><td>normalize-space(ead :processinfo)</td></tr><tr><td>archdescProcessinf oDateDesirable</td><td>ead:archdesc</td><td>The &lt;ead:processinfo&gt; element SHOULD contain a &lt;ead date&gt; element as descendant.</td><td>SHOULD</td><td>normalize-space(ead :processinfo/ead:p/e ad date)</td></tr><tr><td>noc07c12</td><td>ead:c06</td><td>The component elements SHOULD be numbered components between &lt;ead:c01&gt; and &lt;ead:c06&gt;</td><td>SHOULD</td><td>ead:c07</td></tr></table>
<table><tr><td>noc07c12</td><td>ead:c07</td><td>The component elements SHOULD be numbered components between &lt;ead:c01&gt; and &lt;ead:c06&gt;</td><td>SHOULD</td><td>ead:c08</td></tr><tr><td>noc07c12</td><td>ead:c08</td><td>The component elements SHOULD be numbered components between &lt;ead:c01&gt; and &lt;ead:c06&gt;</td><td>SHOULD</td><td>ead:c09</td></tr><tr><td>noc07c12</td><td>ead:c09</td><td>The component elements SHOULD be numbered components between &lt;ead:c01&gt; and &lt;ead:c06&gt;</td><td>SHOULD</td><td>ead:c10</td></tr><tr><td>noc07c12</td><td>ead:c10</td><td>The component elements SHOULD be numbered components between &lt;ead:c01&gt; and &lt;ead:c06&gt;</td><td>SHOULD</td><td>ead:c11</td></tr><tr><td>noc07c12</td><td>ead:c11</td><td>The component elements SHOULD be numbered components between &lt;ead:c01&gt; and &lt;ead:c06&gt;</td><td>SHOULD</td><td>ead:c12</td></tr><tr><td>dateNotEmpty</td><td>ead:change</td><td>The &lt;ead: date&gt; element for each change in &lt;ead:revisiondesc&gt; SHOULD not be empty</td><td>SHOULD</td><td>normalize-space(ead date)</td></tr><tr><td>parallelTitleEnglish</td><td>ead:eadheader</td><td>If the language of the description is not English, a parallel form of the title in English SHOULD be added. For instance, using another &lt;ead: unittitle&gt; element with a @type attribute</td><td>SHOULD</td><td>ead:profiledesc/ead:langusage/@langcode = 'eng'</td></tr><tr><td>creationDesirable</td><td>ead:eadid</td><td>&lt;ead:eadid&gt; SHOULD contain a @mainagencycode</td><td>SHOULD</td><td>@mainagencycode</td></tr></table>
<table><tr><td></td><td></td><td>attribute, which provides (if applicable) the ISO 15511 code for the institution that maintains the finding aid.</td><td></td><td></td></tr><tr><td>scriptcodeRequired</td><td>ead:language</td><td>&lt;ead:language&gt; MUST have a @scriptcode attribute. See also the rule on @scriptcode and ISO 15924:</td><td>SHOULD</td><td>@scriptcode</td></tr><tr><td>nonemptyPhysdesc Desirable</td><td>ead:physdesc</td><td>In the &lt;ead:did&gt; element, &lt;ead:physdesc&gt; SHOULD come with a non-empty &lt;ead:extent&gt;</td><td>SHOULD</td><td>normalize-space(ead:extent[1])</td></tr><tr><td>creationDesirable</td><td>ead:profiledesc</td><td>&lt;ead:eadheader&gt; SHOULD contain a &lt;ead:creation&gt; element</td><td>SHOULD</td><td>ead:creation</td></tr><tr><td>notempty</td><td>ead:publication stmt</td><td>&lt;ead:eadheader&gt; SHOULD specify a &lt;ead:publisher&gt;</td><td>SHOULD</td><td>ead:publisher</td></tr><tr><td>normalNotEmtpy</td><td>ead:unitdate</td><td>&lt;ead:unitdate&gt; SHOULD have a non-empty normal @attribute</td><td>SHOULD</td><td>normalize-space(@normal)</td></tr><tr><td>notEmpty</td><td>ead:unitid</td><td>Each unit of description SHOULD have an identifier in the element &lt;ead:unitid&gt;.</td><td>SHOULD</td><td>normalize-space(.)</td></tr><tr><td>Regexrepositorycode</td><td>*[@repositorycode][preceding: :ead:eadHeaderr/@repository encoding = 'iso15511']</td><td>If the @repositoryencoding is set to "iso15511", the format of the value of the @repositorycode attribute is constrained according to the International Standard Identifier for Libraries and Related Organizations (ISIL: ISO 15511): a prefix, a dash, and an identifier.</td><td>SHOULD</td><td>matches(@repository code, $iso15511Pattern)</td></tr><tr><td>levelFonds</td><td>ead:ead</td><td>The &lt;ead:archdesc&gt; element can have for</td><td>SHOULD</td><td>not(@level = 'fonds') or name(.) =</td></tr></table>
<table><thead><tr><th></th><th></th><th></th><th></th><th></th></tr></thead><tbody><tr><td></td><td></td><td>@level the value 'fonds', not the subcomponents, &lt;ead:c01&gt; to &lt;ead:c06&gt;</td><td>'archdesc'</td><td></td></tr><tr><td>recordgrplevel</td><td>ead:ead</td><td>A component with @level="recordgrp" SHOULD be a child of another component with @level="recordgrp"</td><td>SHOULD</td><td>not(@level = 'recordgrp') or (parent::*[@level = 'recordgrp'] or (name(.) = 'archdesc') or (name(.) = 'c01') and ancestor::*[@level = 'recordgrp'])</td></tr><tr><td>subgrpLevel</td><td>ead:ead</td><td>A component with @level="subgrp" SHOULD be a child of another component with @level="subgrp" or "recordgrp"</td><td>SHOULD</td><td>not(@level = 'subgrp') or ((parent::*[@level = 'recordgrp' or @level = 'subgrp']) or (name(.) = 'c01') and ancestor::*[@level = 'recordgrp'])</td></tr><tr><td>subseriesLevel</td><td>ead:ead</td><td>A component with @level="subseries" SHOULD be a child of another component with @level="subseries" or "series"</td><td>SHOULD</td><td>not(@level = 'subseries') or parent::*[@level = 'subseries' or @level = 'series']</td></tr><tr><td>scopecontentInArch descOrC</td><td>ead:archdesc</td><td>A &lt;ead:scopecontent&gt; element SHOULD be present in the description at least in &lt;ead:archdesc&gt;, if not in the &lt;ead:c01&gt; to &lt;ead:c06&gt; elements.</td><td>SHOULD</td><td>ead:scopecontent or ead:dsc/ead:c01/descendant-or-self::ead: scopecontent</td></tr><tr><td>change-date-item</td><td>ead:change</td><td>In &lt;ead:revisiondesc&gt;, each &lt;ead:change&gt; element SHOULD contain a &lt;ead date&gt; element and a &lt;ead item&gt; element.</td><td>SHOULD</td><td>.[ead date and eaditem]</td></tr><tr><td>unNumberedC</td><td>ead:dsc | ead:c01 | ead:c02</td><td>the ead:dsc components SHOULD numbered, from &lt;ead:c01&gt; to &lt;ead:c06&gt;</td><td>SHOULD</td><td>not(ead:c)</td></tr></tbody></table>
<table><tr><td>copyLinking</td><td>ead:altformavail/ead:p</td><td>If the element &lt;ead:altformavail&gt; is not empty, you COULD try to identify if the originals are present in the EHRI portal and make a link between the two descriptions.</td><td>COULD</td><td>not(normalize-space(.))</td></tr><tr><td>archdescLevelValues</td><td>ead:archdesc</td><td>The value of the &lt;ead:archdesc&gt; @level attribute SHOULD be limited to four values: 'fonds', 'recordGrp', 'collection', 'otherlevel'</td><td>COULD</td><td>@level = 'fonds' or @level = 'recordGrp' or @level = 'collection' or @level='otherlevel'</td></tr><tr><td>langmaterialPossible</td><td>ead:archdesc</td><td>The &lt;ead:archdesc&gt; element COULD contain a @langmaterial element.</td><td>COULD</td><td>ead:did/ead:langmaterial</td></tr><tr><td>custodhistPossible</td><td>ead:archdesc</td><td>The &lt;ead:archdesc&gt; element COULD contain a &lt;ead:custodhist&gt; element.</td><td>COULD</td><td>ead:custodhist</td></tr><tr><td>otherfindaidPossible</td><td>ead:archdesc</td><td>The &lt;ead:archdesc&gt; element COULD contain a &lt;ead:otherfindaid&gt; element.</td><td>COULD</td><td>ead:otherfindaid</td></tr><tr><td>originalslocPossible</td><td>ead:archdesc</td><td>The &lt;ead:archdesc&gt; element COULD contain a &lt;ead:originalsloc&gt; element.</td><td>COULD</td><td>ead:originalsloc</td></tr><tr><td>altformavailPossible</td><td>ead:archdesc</td><td>The &lt;ead:archdesc&gt; element COULD contain a &lt;ead:altformavail&gt; element.</td><td>COULD</td><td>ead:altformavail</td></tr><tr><td>bibliographyPossible</td><td>ead:archdesc</td><td>The &lt;ead:archdesc&gt; element COULD contain a &lt;ead:bibliography&gt; element.</td><td>COULD</td><td>ead:bibliography</td></tr></table>
<table><tr><td></td><td></td><td>element.</td><td></td><td></td></tr><tr><td>oddPossible</td><td>ead:archdesc</td><td>The &lt;ead:archdesc&gt; element COULD contain a &lt;ead:odd&gt; element</td><td>COULD</td><td>ead:odd</td></tr><tr><td>notePossible</td><td>ead:archdesc</td><td>The &lt;ead:archdesc&gt; element COULD contain a &lt;ead:note&gt; element.</td><td>COULD</td><td>ead:note</td></tr><tr><td>controlaccessPossible</td><td>ead:archdesc</td><td>The &lt;ead:archdesc&gt; element COULD contain a &lt;ead:controlaccess&gt; element.</td><td>COULD</td><td>ead:controlaccess</td></tr><tr><td>controlaccessSubjectPossible</td><td>ead:controlaccess</td><td>In ead:controlaccess, EHRI welcomes any access points types: &lt;ead:subject&gt;, &lt;ead:geogname&gt;, &lt;ead:persname&gt;, &lt;ead:orgname&gt;.</td><td>COULD</td><td>ead:subject | ead:geogname | ead:persname | ead:orgname</td></tr><tr><td>authfilenumberPossible</td><td>ead:controlaccess</td><td>Access points COULD be chosen in authority lists. The list is declared with a @source attribute. The related id of this authority should be declared in an @authfilenumber attribute. Note that EHRI provides URLs for vocabularies and authorities. Check the EHRI website for more information</td><td>COULD</td><td>[@authfilenumber and @source]</td></tr><tr><td>creationDateNotTemp</td><td>ead:eadheader</td><td>A date of creation for the finding aid is welcome. The relevant element is &lt;ead:date&gt;, child of &lt;ead:creation&gt;</td><td>COULD</td><td>ead:creation/ead:-date and normalize-space(ead:creation/ead:date)</td></tr><tr><td>langmaterialLanguage</td><td>ead:langmaterial</td><td>&lt;ead:langmaterial&gt; COULD contain a ead:language element.</td><td>COULD</td><td>ead:language</td></tr></table>
<table><caption>Table 3: Overview of the schematron rules</caption><tr><td>originalsLinking</td><td>ead:originalsloc/ead:p</td><td>If the element &lt;ead:originalsloc&gt; is not empty, you COULD try to identify if copies are present in the EHRI portal and make a link between the two descriptions.</td><td>COULD</td><td>not(normalize-space(.))</td></tr><tr><td>labelDesirable</td><td>ead:unitdate</td><td>&lt;ead:unitdates&gt; COULD have a @label attribute or an @encodinganalog attribute, describing the type of date</td><td>COULD</td><td>normalize-space(@label) or normalize-space(@encodinganalog)</td></tr><tr><td>regexLangcode</td><td>*[exists(@langcode)]</td><td>The @langcode attribute SHOULD contain a code from the ISO 639 code list.</td><td>COULD</td><td>$langcodes//tei:f[@name='subType']/tei:symbol/@value = $code</td></tr><tr><td>ISOcode-Scriptcode</td><td>*[exists(@scriptcode)]</td><td>The @scriptcode attribute SHOULD contain a code from the ISO 15924 code list.</td><td>COULD</td><td>$scriptcodes//tei:f[@name='code']/tei:symbol/@value = $code</td></tr><tr><td>ISO-countrycode</td><td>*[exists(@countrycode)]</td><td>The @countrycode attribute SHOULD contain a code from the ISO 3166-1 code list.</td><td>COULD</td><td>$countrycodes//tei:f[@name='a2code']/tei:symbol/@value = $code</td></tr></table>

## 2.4 Use of the schema in the mapping and validation workflow

The schema created from the ODD file is used for the mapping and the validation process of archival descriptions in EHRI database. This process will be designed and implemented by EHRI WP10 on Resource Identification and Integration Workflows. As we showed above, the EHRI-EAD schema is a RelaxNG schema with embedded schematron rules. These combined languages are used for different parts of the process, in a two-steps validation.

### 2.4.1 Technical validation: conformance with EAD

If the input descriptions are not expressed in EAD2002, the conversion tool transform them in this format, using the RelaxNG part of the schema, which is simply an instance of the EAD2002 RelaxNG schema. The potential error messages generated by the conversion tool are based on the generic EAD schema without the EHRI additional rules.

Two examples with an EAD1 file from CEGESOMA show typical validation error messages. The element <ead:organization> and <ead:admininfo>, available in EAD1 but deprecated in EAD2002, are highlighted. These errors are easily solved by the conversion
tool (``<ead:organization>`` is merged with ``<ead:arrangement>``), (``<ead:admininfo>`` is simply removed), and the error message is shown for documentation purposes, both for the CHI, which are then able to preprocess his descriptions before ingesting, based on this feedback, and the responsible of the conversion, as a log.

The two screenshots above shows how the error message are rendered in the conversion tool.

<figure><img src="image_5.png" /></figure>

EAD validation errors in the Conversion tool.

### 2.4.2 Qualitative validation: conformance with EHRI-EAD

The second step is the validation against the schematron rules. This is not yet implemented in the conversion tool. The protocol will be quite similar to the first validation process, apart from the display of the feedback messages.

The schematron rules embedded in the EHRI-EAD schema are meant to be presented as a diagnostic to the content providers. This diagnostic will point to elements of the EAD that, even if they are in valid EAD, are not in line with the EHRI requirements. As we stated above, they are of three types:

* Some messages emphasize EAD validation errors by giving extra information,

* Some messages asks for modification in order to make the description compliant with the specific EHRI constraints,

* Some messages highlight some description elements that could be improved, but without any obligation to do so.

In the future implementation in the conversion tool, these three recommendation levels will correspond to three blocks of validation results, in order to show to the users the elements they need to update in priority.
Continuing the process of the above-mentioned CEGESOMA EAD1 file, the validation against schematron returns a log containing the location (line and character in the line) of the error and a description (the message created in the ODD specification). We show below a sample for each error severity. The first rule asks that the `<ead:-date>` elements contains a `@normal` attribute whose content respect the ISO8601 standard on representation of dates and time. This is a technical requirement for all the dates ingested in EHRI's database.

<figure><img src="image_6.png" /></figure>

## Date normalisation rule

The second rule is also a requirement, but for different reasons. For the sake of comprehension of the archival description, EHRI requires that a `<ead:scopecontent>` element should be present somewhere. The choice is left to the provider to write on general paragraph and put it at the highest level (`<ead:archdesc>`) or add a more precise `<ead:scopecontent>` for each subcomponents, from `<ead:c01>` to `<ead:c06>.` Here, the rule is called at the `<ead:archdesc>` level, because it is more likely that the CHI provides a global `<ead:scopecontent>` if it didn't exist before.

<figure><img src="image_7.png" /></figure>

## Scope and content absence rule

The last rule showed is the lowest level of constraint. It presents some possibilities to make the description more complete. In particular, these rules focuses on the content related elements of `<ead:archdesc>`. Therefore, these messages are not considered as real errors, but as pieces of advice that the providers can follow or not.

<figure><img src="image_8.png" /></figure>

## bibliography suggestion rule
A full description of the expected content (i.e. HTML "tag library") is generated from the ODD file (see it in annex). The conversion tool will display to the user the error message and a link to the relevant section of the documentation. This will be implemented in Schematron with an extra attribute (that would likely be @see), and a stable URL template in which to interpolate this ID.

Another implementation possibility would be, in some case, to modify the input file on the fly, based on the results of the schematron validation. This solution is made possible by the framework Schematron Quickfix, that allow us to define fixes for the schematron errors<fnref n="18" />.

<footnote n="18">¹⁸ http://www.schematron-quickfix.com/ accessed on March 28th 2017</footnote>
### 3. EHRI-EAC and EHRI-EAG: work in progress

A similar work is initiated with other entities potentially ingested in the EHRI database, the authorities (persons and corporate bodies) and the archival institutions, that can be described in EAC-CPF for the former, and EAG for the latter.

The ingestion of a significant amount of authorities in the portal is a real possibility, even if it is far less likely than the ingesting of EAD files. In particular, the use of EAG to describe archival institutions is not well spread yet and EHRI did a major work by manually entering the descriptions of 1922 institutions so far.

For the authorities, it is very likely that an institution has created relevant datasets that could be imported in the EHRI portal. For instance, CDEC has a large database of 10624 persons that are related to their archives. If the decision is taken to ingest all or a part of these data in EHRI portal, an automatic processing should be put in place.

Like for EHRI-EAD, the idea is to create an EHRI-EAC-CPF and a EHRI-EAG schema, based on generic ODD files that are currently being created by the Parthenos project<fnref n="19" />. However, we need to wait for stable versions of these ODD specifications before considering the implementation for EHRI. The release of these stable versions is scheduled by the end of the summer 2017.

### 4. Contribution to the design of consistent URLs in EHRI

#### 4.1 Introduction

It is recommended to employ Universal Resource Identifiers (URIs) for EHRI data resources such as archives and units of archival material. Wherever possible, existing published URIs should be used and so these recommendations cover those components of the EHRI metadata infrastructure which are not already addressed by the work of others. There are many important reasons for employing PIDs in a system such as EHRI. The primary rationale is the long-term functional viability of the EHRI portal and its preservation. The use of IDs which are not persistent, such as URLs which can change as resources are moved around the EHRI architecture or between servers, is likely rapidly to cause problems of dead links and difficult-to-find data. The work done in this task focuses on building of consistent URLs. Implementing and design of persistent identifiers will be outside WP11. This will be part of T13.4 Integrating Information Architecture and T13.2 Secure Long-term Access Infrastructure for the preservation of Holocaust Research Objects.

<footnote n="19">¹⁹ https://github.com/ParthenosWP4/standardsLibrary/tree/master/archivalDescription/EAC and https://github.com/ParthenosWP4/standardsLibrary/tree/master/archivalDescription/EAG (accessed on March 27th 2017)</footnote>
## 4.2 Rationale for using consistent URLs in EHRI

### 4.2.1 Principles

As a research resource, it is important that EHRI resources are referenceable and citable in a permanent format. The two main principles to be followed are the uniqueness (one resource = one unique URL) and durability (URLs are not likely to change). Before EHRI tackles the issue of creating persistent identifiers, a preliminary work is needed on the URLs to make them more consistent.

However, the needs of designing a good URI scheme don't conflict with those of designing a navigable website. A way to tackle the challenges of consistency and persistency is to build a URI scheme independently from the portal URLs, which have different purposes and functionalities. The URI scheme will be used to identify each individual resource present in EHRI database, as well as each dataset. Of course, the website URLs and the URIs should at some point be built on the same schema.

The datasets of the EHRI portal which will benefit from consistent URLs include:

* vocabularies

* authorities

* documentary units

* archival institutions

* countries

* research guides

In this list, a focus should be put on the vocabularies. Creating consistent URLs for the different vocabularies and authority lists is crucial for EHRI. These vocabularies could be seen as reference for Archival and scholarly communities working on Holocaust related materials. The central vocabularies and authority lists that require URLs are

* Concepts/Terms

* Ghettos

* Camps

* Administrative Districts

* Events

* Corporate Bodies

* Personalities

### 4.2.2 URIs construction

In the approach we suggest, each type of URI includes a *prefix*, a reference to the dataset the resource belongs to, and a *reference* to the identifier of the resource.

The URLs structure in often a combination of several reference. For instance, a documentary unit URL combines the reference of the documentary unit itself, its potential ancestors in the archival fonds hierarchy, the institution that holds it, and the country in which this institution is based. To separate the different parts of the URLs, we favour the slash instead of the
hyphen, to show the hierarchical relations between the components.

* **Prefix**

The prefix `data.ehri-project.eu/` is already used to reference the available vocabularies and ontologies used by EHRI (Administrative districts, Nazi concentration camps, Ghettos, events, thesaurus, lists of persons). We recommend to extend this use to all the EHRI resources that need to be identified with a consistent URI, as listed above.

The prefix `portal.ehri-project.eu/` is used to navigate through the website, and shouldn't be used to reference a resource.

* **Dataset reference**

In EHRI semantic ecosystem, each resource is part of a dataset, as listed above. the identification of the datasets are presented in lowercase, with words separated by hyphens if necessary, and in the plural. For the datasets identified, we propose:

* Vocabularies → vocabularies

* Authorities → authorities

* Documentary units → units

* Archival institutions → institutions

* Countries → countries

* Research guides → guides

* **Entity Reference**

The reference is the string that is used to identify an individual entity of a given dataset. There are two approaches for the format of the URIs reference part. One would be to use a reference component of each URI translated to legal IRI format (lower case, spaces replaced by hyphens) [Duerst, 2005]. The other is to use codes or notation for the references. Using codes may be less prone to error and to changes in name, so it is the solution we recommend, which is by the way already implemented.

We advocate the use of ISO code lists when it's relevant. To identify the countries (by country, we mean a present country where are based archival institutions holding Holocaust related material), the use of ISO 3166 country codes list is already a good practice followed by EHRI. Ideally, we would have welcomed the use of the International standard identifier for libraries and related organisations (ISO 15511), that provide a code (called SIL) for each cultural heritage institution. However, code lists are maintained on a national basis, and so far, only 29 countries in the world have a stable SIL list.

For the documentary units, the question remains open and two approaches are still considered. The first one is to construct the URL of the description unit through concatenation of the identifiers of the description units following the hierarchy path of the imported EAD description. This ensures the uniqueness of the identifier, but this approach has a backside : if a description unit changes position in the hierarchy, its URL will change too (given that the URLs are automatically generated from the hierarchy of the archival descriptions in the database).

The second approach consists on assigning an identifier to each metadata record regardless its position in the hierarchy. It has a clear advantage: if the archival material is reorganized in
a institution and the hierarchy of the archival collections changes, the URL of the description unit won't change if it has been identified though a persistent identifier. But the weak side is that some institutions don't provide unique identifiers, especially for the lowest levels of the hierarchy (as file or document), and they can be disambiguated only using contextual information.

This stated, the path-dependent solution is favoured, as long as a global persistent and unique identifier system is not put in place.

### 4.2.3 Challenge of assessing persistence

EHRI can only assess the persistence of the URLs for the data that is directly produced by the research infrastructure:

* Descriptions of CHIs,

* Vocabularies

* Country reports

* Authority lists

To assess persistence to the URLs of imported data is a quite more complex task, since it doesn't depend only of persistence policies in the EHRI project. If the CHIs don't provide persistent identifiers to their metadata records, EHRI cannot provide a sustainable way to identify the records in a persistent way after updates of the material imported into the portal.

## 4.3 Proposals summary

<table><tr><td>vocabulary set</td><td>http://data.ehri-project.eu/vocabularies/concepts<br>http://data.ehri-project.eu/vocabularies/ghettos<br>http://data.ehri-project.eu/vocabularies/camps<br>http://data.ehri-project.eu/vocabularies/districts<br>http://data.ehri-project.eu/vocabularies/events</td></tr><tr><td>vocabulary term</td><td>http://data.ehri-project.eu/vocabularies/{concepts,districts,ghettos,camps,events}/{numericID}</td></tr><tr><td>authority list</td><td>http://data.ehri-project.eu/authorities/corporate-bodies<br>http://data.ehri-project.eu/authorities/persons</td></tr><tr><td>authority instance<br>corporate body</td><td>http://data.ehri-project.eu/authorities/corporate-bodies/{numericID}</td></tr><tr><td>authority instance person</td><td>http://data.ehri-project.eu/authorities/persons/{numericID}</td></tr><tr><td>country reports</td><td>https://portal.ehri-project.eu/countries/{ISO3166_code}</td></tr></table>
<table><tr><td>archival institution</td><td>https://data.ehri-project.eu/institutions/{ISO3166_code}/{numericID}</td></tr><tr><td>documentary unit</td><td>https://data.ehri-project.eu/units/{ISO3166_code}/{numericID}/{DocumentUnitID and or Hierarchy}</td></tr><tr><td>research guides</td><td>https://portal.ehri-project.eu/guides/terezin/vocabularies/{term}<br>https://portal.ehri-project.eu/guides/terezin/authorities/victims/{victim}<br>https://portal.ehri-project.eu/guides/jewishcouncil/vocabularies/places/{place}</td></tr></table>

## 4.4 Implementation issues

There are various technical issues that need to be considered and resolved before a new permalink URI structure can be implemented. The EHRI portal has an existing URL scheme that is similar, but not identical, to that proposed above. Since the portal has been running for several years, it would not be practical to migrate the URLs of several hundred thousand items to new URLs. This implies that the legacy URLs would have to exist alongside those with the new scheme, increasing the overall maintenance overhead of the EHRI Infrastructure.

Moreover, the existing legacy URLs serve a somewhat different purpose to that of the permalinks proposed here in that they primarily support functionality in the portal website, rather than just providing canonical global identifiers. Notably, there is a richer vocabulary of website-specific actions such as:

* https://portal.ehri-project.eu/units/sk-003276-22523 <- main item page

* https://portal.ehri-project.eu/units/sk-003276-22523/search <- search page

* https://portal.ehri-project.eu/units/sk-003276-22523/export <- item export page

There action-specific variation substantially increase the total number of resolvable URLs on the portal website relative to the number of canonical URIs that would exist and has the potential to cause confusion.

Since EHRI does not at present use URIs internally, an additional technical issue involves the mapping of URIs to item identifiers. At present, item identifiers in EHRI are global and hierarchical, with hyphens delimiting levels of hierarchy. Using URIs with slashes delimiting path sections would add an additional translation step before items can be internally resolved. In many cases, a simple translation of forward-slashes to hyphens may suffice, assuming a fixed prefix.

Given these constraints, implementation of URIs will need to proceed carefully and with coordination across several work-packages which rely on EHRI's portal and surrounding infrastructure (notably WP7, WP12, and WP13). However, there are relatively few purely technical issues that should hinder technical delivery aside from those enumerated above.
## 5. Summary

This document describes mechanisms where interoperability of data is ensured with the use of standards. The standards we covered are both domain related, the archival standards in XML formats such as EAD, EAC-CPF and EAG, and transversal standards, whose use is recommended in the context of any digital project, in particular the ISO standards for the representation of language, script and countries.

Interoperability of archival descriptions expressed in EAD is made possible with the specification of a specific EAD profile for EHRI. This profile is built and maintained using the TEI-ODD framework, which is explained of the first section of the report.

Interoperability and reusability of EHRI resources is also ensured with the design of more consistent URLs, composed with standardised methods and using ISO reference codes. This design has to be seen as a first step through a persistent identifier system.

The work initiated in WP11 and presented in this document will be continued, enhanced and developed by other EHRI work packages, WP7 Virtual Access to EHRI Virtual Observatory, WP10 Resource Identification and Integration Workflows and WP13 Research Data Infrastructures for Holocaust Material.
# 6. Bibliography

Archives Portal Europe network of excellence, D6.1 First Analysis report: Applying Web 2.0 solutions in archival applications, http://apex-project.eu/images/docs/D61_Web20_In_Archival_Applications.pdf, accessed on March 23rd 2017

Archives Portal Europe network of excellence D6.6 Second analysis report: Applying Web 2.0 solutions in archival applications, 2014, http://apex-project.eu/images/docs/D66_Web20_In_Archival_Applications_final.pdf, accessed on March 23rd 2017

Chief Technology Officer Council. Designing URI sets for the UK public sector. A report from the Public Sector Information Domain of the CTO Council's cross-Government Enterprise Architecture, 2009
https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/60975/designing-URI-sets-uk-public-sector.pdf, accessed on March 28th 2017

Duerst, M., & Suignard, M. Internationalized Resource Identifiers (IRIs), January 2005. RFC3987 on http://www.ietf.org/rfc/rfc3987.txt, accessed on March 27th 2017

EAD and EAC-CPF working groups, AFNOR, *Proposals for evolution of EAD*, http://www2.archivists.org/sites/all/files/France_Proposals%20for%20evolution%20of%20EA_D_0.rtf

Experts group on archival description (ICA). "Records in Contexts, a Conceptual Model for Archival Description. Consultation Draft v0.1." Conseil international des Archives, September 2016. http://www.ica.org/sites/default/files/RiC-CM-0.1.pdf, accessed on March 12th 2017

Gartner, Richard. "An XML Schema for Enhancing the Semantic Interoperability of Archival Description." *Archival Science* 15, no. 3 (September 1, 2015): 295-313. doi:10.1007/s10502-014-9225-1.

Library of Congress, Development of the Encoded Archival Description DTD, 2013, http://www.loc.gov/ead/eaddev.html (accessed on March 22d 2017)

Medves, Maud, and Romary, Laurent. "EAG(CENDARI): Customising EAG for Research Purposes," 2013. https://hal.inria.fr/hal-00959841/document.

Norman Walsh, Literate Programming in XML, 2002, http://nwalsh.com/docs/articles/xml2002/lp/paper.html, accessed on January 10th, 2017
# 7. Annex: Full documentation of the EHRI_EAD schema
(version 1, March 2017)

## Guidelines

In the context of the EHRI project, we created an ODD base on the EAD ODD maintained by the Parthenos project, to document the specific rules and constraints of the EHRI data model for archival descriptions. In this new ODD file, called EHRI_EAD.odd, the generic EAD specification is imported and serves the baseline of specification. The additional constraints are added only to the elements that they refer to.

The constraints added to EAD ensures a smooth ingestion of external data in the EHRI's database.

First, some EAD elements are required for the good functioning of the database, for instance unique identifiers for all the descriptions (contained in <eadid>).

Second, some elements are made mandatory for more qualitative reasons: for instance to ease the discoverability of its resources, EHRI wants that a minimal description in English is provided with each description unit. We encourage the use of ISO standards for the representation of languages, scripts, dates, etc, as well as the interlinkage of entities, via the use of authority lists.

Schematron rules were already used in EHRI, so we integrated them directly in this EHRI-EAD ODD.

## Specification

### Elements

#### <abbr>

**<abbr>** (Abbreviation) A generic element for a shortened form of a word, including an acronym.

**Module** EAD

**Attributes**
*   **att.EADGlobal** (`@id`, `@altrender`, `@audience`, `@encodinganalog`)
*   **expan** The **expan** attribute can be used to supply the full form of an abbreviated word for indexing or searching purposes.

**Status** Optional

**Datatype**

**Member of** model.phrase.basicConfig

**Contained by** EAD: abstract archref bibref creation descrules dimensions emph entry event extrefloc item label langmaterial language materialspec origination p physdesc physfacet physloc ref refloc repository subtitle titleproper unitdate unitid unittitle

**May contain** Character data only

**Note** See also related element Expansion <expan>.

**Example**
```xml
<note xmlns="urn:isbn:1-931666-22-9">
  <p>
    <abbr expan="Autograph Letter Signed">ALS</abbr>
  </p>
</note>
```

**Content model**
```xml
<content>
</content>
```
Schema

Declaration element abbr { att.EADGlobal_attributes, attribute expan { text }?, text }

<abstract>

<abstract> (Abstract) A very brief summary of the materials being described, used primarily to encode bits of biographical or historical information about the creator and abridged statements about the scope, content, arrangement, or other descriptive details about the archival unit or one of its components.

Module EAD

Attributes att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att.typed (@type) att.langcode (@langcode) att.labeled (@label)

Member of model.did

Contained by EAD: archref did

May contain EAD: abbr archref bibref emph expan extptr extref lb linkgrp ptr ref subtitle title

Note

Within the <archdesc><did>, the <abstract> is often extracted from the longer
descriptions found in <bioghist> and <scopecontent>. Its purpose is to help
readers identify quickly those materials they need to explore at greater length.
Within the <c><did>, the <abstract> may describe unique characteristics of an
individual Component. This information may have aspects of <arrangement>,
<bioghist>, <physdesc>, and <scopecontent>, which are not substantive enough
to tag individually under those elements. Use of the TYPE and
ENCODINGANALOG attributes on <abstract> may assist in extracting information
for such MARC equivalents as summary note (520$a) and biographical or
historical data (545$a). The LANGCODE attribute can be used when abstracts are
provided in more than one language.

Example

<archdesc xmlns="urn:isbn:1-931666-22-9" level="fonds">
  <did>
    <head>Descriptive Summary</head>
    <unititle label="Title">Richard Egan manuscript maps of Orange County</unititle>
    <unitdate type="inclusive" normal="1878/1879">Circa 1878-1879</unitdate>
    <unitid countrycode="us" repositorycode="cu-i" label="Collection number">MS-R72</unitid>
    <origination label="Creator">
      <persname rules="aacr2">Egan, Richard, 1842-1923</persname>
    </origination>
    <physdesc label="Extent">
      <extent>1 linear foot (1 box)</extent>
    </physdesc>
    <repository label="Repository">
      <corpname rules="aacr2">University of California, Irvine. Library. Special Collections and Archives.</corpname>
    </repository>
  </did>
  <abstract label="Abstract">Four manuscript survey maps and one plat map depicting areas of Orange County and attributed to the noted surveyor and judge Richard Egan.</abstract>
One map is dated 1878 and 1879 by Egan. The other maps are undated and unsigned but it is likely that he drew them during these years. These maps primarily depict subdivisions of non-rancho tracts of land occupying what is now Orange County, with the addition of some topographical details.</abstract>

</did>

</archdesc>

## Content model

<content>

</content>

## Schema

### Declaration

element abstract

{
  att.EADGlobal_attributes,
  att.typed_attributes,
  att.langcode_attributes,
  att.labeled_attributes,
  (text | model.phrase.basicConfig)
}

## <accessrestrict>

<accessrestrict> (Conditions Governing Access) Information about conditions that affect the availability of the materials being described. May indicate the need for an appointment or the nature of restrictions imposed by the donor, legal statute, repository, or other agency. May also indicate the lack of restrictions.

**Module** EAD

**Attributes**
att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att.typed (@type)

**Member of** model desc base

**Contained by** EAD: accessrestrict archdesc archdescgrp c c01 c02 c03 c04 c05 c06 c07 c08 c09 c10 c11 c12 descgrp

**May contain** EAD: accessrestrict address blockquote chronlist head legalstatus list note p table

**Note**

Do not confuse with Conditions Governing Use <userestrict>, which designates information about limitations on the use of the described materials after access has been granted. In EAD Version 1.0 <accessrestrict> was a subelement of Administrative Information <admininfo>, which has been deprecated in EAD 2002 (see Appendix B). The new Description Group <descgrp> element, which can group any of the <did>-level elements (except the Description of Subordinate Components <dsc>), may be used to wrap elements where a group heading is desirable. The <descgrp> element can be used to replace <admininfo> where it has been used as a wrapper when converting finding aids encoded in EAD V1.0 to EAD 2002.

The <accessrestrict> element is comparable to ISAD(G) data element 3.4.1 and MARC field 506.

**Example**
<accessrestrict xmlns="urn:isl:1-931666-22-9">
<p>There are no access restrictions on this collection.</p>
</accessrestrict>

**Example**
<accessrestrict xmlns="urn:isl:1-931666-22-9">
<p>University records are public records and once fully
processed are generally open to research use. Records that contain personally identifiable information will be closed to protect individual privacy. The closure of university records is subject to compliance with applicable laws.</p>
</accessrestrict>

### Example

```xml
<p xmlns="urn:isl:1-931666-22-9">
  <c02 level="file">
    <did>
      <container type="box" label="Box">104</container>
      <container type="folder">
        <label="Folder(s)">6578-6579</label>
      </container>
      <unittitle>
        <title render="italic">Technics and Civilization</title>
        <title render="italic">Form and Personality</title>
        <title render="italic">Form and Civilization</title>
      </title>
    </did>
    <unitdate type="inclusive" normal="1931/1933">1931-1933</unitdate>
  </c02>
</p>
```

### Content model

```xml
<content>
</content>
```

### Schema

#### Declaration

```xml
element accessrestrict
{
    att.EADGlobal_attributes,
    att.typed_attributes,
    head?,
    (model_blocks | legalstatus | accessrestrict) +
}
```

### <accruals>

#### <accruals>
(Accruals) Information about anticipated additions to the materials being described. Can indicate quantity and frequency. Can also be used to indicate that no additions are expected.

**Module** EAD

**Attributes** att.EADGlobal (@id, @altrender, @audience, @encodinganalog)

**Member of** model desc base

**Contained by** EAD: accruals archdesc archdescgrp c c01 c02 c03 c04 c05 c06 c07 c08 c09 c10 c11 c12 descgrp

**May contain** EAD: accruals address blockquote chronlist head list note p table

**Note** In EAD Version 1.0 <accruals> was a subelement of Administrative Information
<admininfo>, which has been deprecated in EAD 2002 (see Appendix B). The new Description Group <descgrp> element, which can group any of the <did>-level elements (except the Description of Subordinate Components <dsc>), may be used to wrap elements where a group heading is desirable. The <descgrp> element can be used to replace <admininfo> where it has been used as a wrapper when converting finding aids encoded in EAD V1.0 to EAD 2002. The <accruals> element is comparable to ISAD(G) data element 3.3.3 and MARC field 584.

<table><tr><td>Example</td><td><accruals xmlns="urn:isl:1-931666-22-9"><p>No further materials are expected for this collection.</p></accruals></td></tr><tr><td>Example</td><td><accruals xmlns="urn:isl:1-931666-22-9"><p>Noncurrent additions to this Record Group are transferred from the Development Department annually at the end of the fiscal year in June.</p></accruals></td></tr></table>

### Content model

<content>
</content>

### Schema Declaration

<table><tr><td>Declaration</td><td>element accruals<br/>{<br/>att.EADGlobal_attributes,<br/>head?,<br/>(model_blocks | accruals)+<br/>}</td></tr></table>

## <acqinfo>

<acqinfo> (Acquisition Information) The immediate source of the materials being described and the circumstances under which they were received. Includes donations, transfers, purchases, and deposits.

**Module** EAD

**Attributes** att.EADGlobal (@id, @altrender, @audience, @encodinganalog)

**Member of** model desc base

**Contained by** EAD: acqinfo archdesc archdescgrp c c01 c02 c03 c04 c05 c06 c07 c08 c09 c10 c11 c12 custodhist descgrp

**May contain** EAD: acqinfo address blockquote chronlist head list note p table

**Note** After opening a Paragraph <p> within <acqinfo>, optional subelements may be used to tag separately such common acquisition information as the name of the source, e.g., <persname> or <corpname>; the <date> the materials were received; or the accession number <num> assigned to them. The <address> element could be used to document the address of the source, and the audience attribute could be set to "internal," if the address information should only be available to authorized staff. Note that the accession number may also serve as the <unitid> and be encoded as such within a <did>. For detailed information about items acquired and then subsequently alienated from the materials being described, the Separated Material <separatedmaterial> element can be used. It designates items related by provenance that have been physically removed from the materials being described.

The Custodial History <custodhist> element can be used for information about the chain of ownership before the materials reached the immediate source of
acquisition.

In EAD Version 1.0 <acqinfo> was a subelement of Administrative Information
<admininfo>, which has been deprecated in EAD 2002 (see Appendix B). The new
Description Group <descgrp> element, which can group any of the <did>-level
elements (except the Description of Subordinate Components <dsc>), may be
used to wrap elements where a group heading is desirable. The <descgrp>
element can be used to replace <admininfo> where it has been used as a wrapper
when converting finding aids encoded in EAD V1.0 to EAD 2002.

The <acqinfo> element is comparable to ISAD(G) data element 3.2.4 and MARC
field 541.

Example
<acqinfo xmlns="urn:isl:1-931666-22-9">
  <p>Transfer from <corpname>National Park Service, </corpname>
  <date type="accession">1945</date>. Accession number <num type="accession"
  >45.22</num>.</p>
</acqinfo>

Example
<acqinfo xmlns="urn:isl:1-931666-22-9">
  <p>Source unknown. Originally deposited in University Library,
  transferred to Department of Palaeography, <date normal="19580424">24 April 1
  958</date>.</p>
</acqinfo>

Content model

<content>
</content>

Schema

Declaration element acqinfo
{
  att.EADGlobal_attributes,
  head?,
  ( model_blocks | acqinfo )+
}

<address>

<address> (Address) A generic element for information about the place where someone or something is located and may be reached. Examples include a postal address for a repository, or the electronic mail address and phone number of the party granting publication permission.

Module EAD

Attributes att.EADGlobal (@id, @altrender, @audience, @encodinganalog)

Member of model.inter.noquote

Contained by EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement bibliography bioghist blockquote controlaccess custodhist daodesc descgrp div dsc dscgroup entry event extrefloc index item note odd originalsloc otherfindaid p phystech prefercite processinfo publicationstmt ref refloc relatedmaterial repository scopecontent separatedmaterial userestrict

May contain EAD: addressline

Note
Consider using an entity reference to store address information that occurs in many
finding aids, as it is easier to update the information when located in a single,
shared file. The entity reference can contain both the EAD elements and their
content. A style sheet can also be used to supply this kind of information.

Example
<publicationstmt xmlns="urn:isl:1-931666-22-9">
  <publisher>The Bancroft Library.</ publisher>
<address>
<addressline>University of California,
Berkeley.</addressline>
<addressline>Berkeley, California 94720-6000</addressline>
<addressline>Phone: 510/642-6481</addressline>
<addressline>Fax: 510/642-7589</addressline>
<addressline>Email:
bancref@library.berkeley.edu</addressline>
</address>
</publicationstmt>

Content
model

<content>
</content>

Schema

Declaration element address { att.EADGlobal_attributes, addressline+ }

<addressline>

<addressline> (Address Line) A generic element for one line of a postal or other address. May be
repeated as many times as necessary to enter all available lines of an address.

Module EAD

Attributes att.EADGlobal (@id, @altrender, @audience, @encodinganalog)

Contained by EAD: address

May contain EAD: emph extptr lb ptr

Example
<publicationstmt xmlns="urn:isl:1-931666-22-9">
  <publisher>Special Collections and Archives</publisher>
  <address>
    <addressline>The UCI Libraries</addressline>
    <addressline>P.O. Box 19557</addressline>
    <addressline>University of California</addressline>
    <addressline>Irvine, California 92623-9557</addressline>
    <addressline>Phone: (949) 824-7227</addressline>
    <addressline>Fax: (949) 824-2472</addressline>
    <addressline>Email: spcoll@uci.edu</addressline>
    <addressline>URL:http://www.lib.uci.edu/rrsc/speccoll.html</addressline>
  </address>
  <date>© 2000</date>
  <p>The Regents of the University of California. All rights reserved.</p>
</publicationstmt>

Content
model

<content>
</content>

Schema

Declaration element addressline { att.EADGlobal_attributes, ( text | model.phrase.bare )* }

<altformavail>

<altformavail> (Alternative Form Available) Information about copies of the materials being described, including the type of alternative form, significant control numbers, location, and source
for ordering if applicable. The additional formats are typically microforms, photocopies, or digital reproductions.

**Module** EAD

**Attributes** att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att.typed (@type)

**Member of** model desc base

**Contained by** EAD: altformavail archdesc archdescgrp c c01 c02 c03 c04 c05 c06 c07 c08 c09 c10 c11 c12 descgrp

**May contain** EAD: address altformavail blockquote chronlist head list note p table

**Note** Do not confuse with Location of Originals <originalsloc>, which is used to encode information about the existence, location, and availability of originals where the unit described consists of copies. In EAD Version 1.0 <altformavail> was a subelement of Administrative Information <admininfo>, which has been deprecated in EAD 2002 (see Appendix B). The new Description Group <descgrp> element, which can group any of the <did>-level elements (except the Description of Subordinate Components <dsc>), may be used to wrap elements where a group heading is desirable. The <descgrp> element can be used to replace <admininfo> where it has been used as a wrapper when converting finding aids encoded in EAD V1.0 to EAD 2002.

The <altformavail> element is comparable to ISAD(G) data element 3.5.2 and MARC field 530.

**Example**
```xml
<altformavail xmlns="urn:isl:1-931666-22-9">
  <p>This collection has been microfilmed and is available on
    three reels MF1993-034:1 to MF1993-034:3.</p>
  <p>Researchers interested in purchasing microfilm copies should
    contact the repository.</p>
</altformavail>
```
**Example**
```xml
<altformavail xmlns="urn:isl:1-931666-22-9">
  <head>Alternate Form of Material</head>
  <p>Microfilm copy available (<num type="microfilm reel"> M-5030/1</num>).</p>
</altformavail>
```

**Example**
```xml
<c02 xmlns="urn:isl:1-931666-22-9" level="file">
  <did>
    <container type="reel"
      label="Film Storage">1</container>
    <unittitle>
      <title render="italic">The Man Who Hated
        Children</title>
    </unittitle>
    <unitdate normal="1972">1972</unitdate>
    <physdesc>16 mm. film</physdesc>
  </did>
  <altformavail>
    <p>A VHS Videocassette version is available for viewing.
      Video tape is located in Video Storage.</p>
  </altformavail>
</c02>
```

**Schematron** If the element <altformavail> is not empty, you COULD try to identify if the originals are present in the EHRI portal and make a link between the two descriptions.
```xml
<s:rule context="ead:altformavail/ead:p"> <s:assert role="COULD"
  test="not(normalize-space(.))"> If the element altformavail is not empty, you
  COULD try to identify if the originals are present in the EHRI portal and make a link
  between the two descriptions</s:assert> </s:rule>
```
## Content model

`<content/>`

## Schema Declaration

element `altformavail`
{
    att.EADGlobal_attributes,
    att.typed_attributes,
    head?,
    ( model blocks | altformavail )+
}

## <appraisal>

`<appraisal>` (Appraisal Information) Information about the process of determining the archival value and thus the disposition of records based upon their current administrative, legal, and fiscal use; their evidential, intrinsic, and informational value; their arrangement and condition; and their relationship to other records.

**Module** EAD

**Attributes** `att.EADGlobal` (`@id`, `@altrender`, `@audience`, `@encodinganalog`)

**Member of** `model desc base`

**Contained by** EAD: appraisal archdesc archdescgrp `c01 c02 c03 c04 c05 c06 c07 c08 c09 c10 c11 c12 descgrp`

**May contain** EAD: address appraisal blockquote chronlist head list note p table

**Note** In EAD Version 1.0 `<appraisal>` was a subelement of Administrative Information `<admininfo>`, which has been deprecated in EAD 2002 (see Appendix B). The new Description Group `<descgrp>` element, which can group any of the `<did>`-level elements (except the Description of Subordinate Components `<dsc>`), may be used to wrap elements where a group heading is desirable. The `<descgrp>` element can be used to replace `<admininfo>` where it has been used as a wrapper when converting finding aids encoded in EAD V1.0 to EAD 2002. The `<appraisal>` element is comparable to ISAD(G) data element 3.3.2 and MARC field 583.

**Example**

`<appraisal xmlns="urn:islbn:1-931666-22-9"> <p>The records of the Mid-Ocean Dynamics Experiment came to the Institute Archives in two accessions in 1980 and 1982. During processing the collection was reduced from fifteen cubic feet to four by discarding duplicate materials, financial records, and publications not authored by MODE participants. Forty charts and six inches of raw data presented the primary appraisal issues. The raw data consisted of bulletins and reports referring to float positions, moorings, isotherms, geostrophic velocity calculations, ships' summaries, and work proposed and work carried out during the MODE-I experiment. As this raw data was recapitulated in weekly <title render="underline">MODE Hot Line Bulletins</title>, only a sampling was retained in the collection. Also discarded were ten charts for which there were no descriptions of indicated data points, nor were dates or test site locations provided.</p> <p>Six inches of materials pertaining to the POLYMODE project, 1973-1980, were added to the Institute Archives POLYMODE collection.</p>`
<p>The appraisal of this collection was carried out in consultation with Robert Heinmiller, a research associate at Woods Hole Oceanographic Institution during MODE.</p>

</appraisal>

## Content model

<content>

</content>

## Schema

### Declaration

element appraisal
{
  att.EADGlobal_attributes,
  head?,
  ( model_blocks | appraisal )+
}

## <arc/>

<arc/> (Arc) Specifies the rules for traversal among the participating resources in an extended link. Arc uses the attributes to and from to define the traversal between named pairs of resources.

**Module** EAD

**Attributes**
att.xlink (@label, @href, @type, @title, @from, @to, @role, @actuate, @show, @arcrole, @xpointer, @entityref, @target, @parent)

**Member of** model.extended.els

**Contained by** EAD: daogrp linkgrp

**May contain** Empty element

**Note**
While XML Linking Language (XLink) Version 1.0, which is the basis for EAD linking elements, is a stable document, examples of EAD usage are hypothetical and have not been tested in real XLink-based applications. Those wishing to use XLink are encouraged to consult the specification available online at http://www.w3.org/TR/xlink/.

## Example

<c02 xmlns="urn:isl:1-931666-22-9" level="file">
  <did>
    <unititle>Photographs of John Smith and family members</unititle>
    <unitdate type="inclusive" normal="1895/1928">1895-1928</unitdate>
    <daogrp linktype="extended">
      <daodesc>
        <p>Sample digitized image from this file: John Smith graduation portrait, <date normal="18950528">28 May 1895</date>.</p>
      </daodesc>
      <resource linktype="resource" label="start"/>
      <daoloc entityref="f0042_1tmb" linktype="locator" label="thumb"/>
      <daoloc entityref="f0042_1ref" linktype="locator" label="reference"/>
      <arc linktype="arc" show="embed" actuate="onload" from="start" to="thumb"/>
      <arc linktype="arc" show="new"/>
    </resource>
  </unititle>
</did>
actuate="onrequest" from="thumb" to="reference"/>
</daogrp>
</did>
</c02>

## Content model

<content>
</content>

## Schema

**Declaration** element arc { att.xlink_attributes, empty }

## <archdesc>

<archdesc> (Archival Description) A wrapper element for the bulk of an EAD document instance, which describes the content, context, and extent of a body of archival materials, including administrative and supplemental information that facilitates use of the materials. Information is organized in unfolding, hierarchical levels that allow for a descriptive overview of the whole to be followed by more detailed views of the parts, designated by the element Description of Subordinate Components <dsc>. Data elements available at the <archdesc> level are repeated at the various component levels within <dsc>, and information is inherited from one hierarchical level to the next.

**Module** EAD

**Attributes**
att.EADGlobal (@id, @altrender, @audience, @encodinganalog)
att-relatedencoding (@relatedencoding) att desc.c (level, @otherlevel)

level The hierarchical level of the materials being described by the element.

**Derived from** att desc.c

**Status** Required

**Schematron**
If the attribute level has the value 'otherlevel', an attribute otherlevel MUST be added
<s:rule context="ead:ead"> <s:assert role="MUST" test="not(@level = 'otherlevel') or (@otherlevel and not(@otherlevel = ""))">If the attribute level has the value 'otherlevel', an attribute otherlevel MUST be added</s:assert> </s:rule>

**Schematron**
The <archdesc> element can have for level the value 'fonds', not the subcomponents, <c01> to <c06>
<s:rule context="ead:ead"> <s:assert role="SHOULD" test="not(@level = 'fonds') or name(.) = 'archdesc'">The archdesc can have for level the value 'fonds', not the subcomponents.</s:assert> </s:rule>

**Schematron**
A component with level="recordgrp" SHOULD be a child of another component with level="recordgrp"
<s:rule context="ead:ead"> <s:assert role="SHOULD" test="not(@level = 'recordgrp') or (parent::*[@level = 'recordgrp'] or (name(.) = 'archdesc') or (name(.) = 'c01') and ancestor::*[@level = 'recordgrp'])">recordgrp SHOULD be a child of another recordgrp</s:assert> </s:rule>

**Schematron**
A component with level="subgrp" SHOULD be a child of another component with level="subgrp" or "recordgrp"
<s:rule context="ead:ead"> <s:assert role="SHOULD" test="not(@level = 'subgrp') or ((parent::*[@level = 'subgrp'] or @level = 'subgrp']) or (name(.) = 'c01') and
ancestor::*[@level = 'recordgrp')]">subgrp SHOULD be a child of another subgrp or a recordgrp</s:assert>
</s:rule>

**Schematron**
A component with *level*="subseries" SHOULD be a child of another component with *level*="subseries" or "series" <s:rule context="ead:ead"> <s:assert role="SHOULD" test="not(@level = 'subseries' or parent::*[@level = 'subseries' or @level = 'series')]">subseries SHOULD be a child of another subseries or a series</s:assert>
</s:rule>

**Datatype**

Legal values are: class

collection

fonds

item

otherlevel

recordgrp

series

subfonds

subgrp

subseries

file

type can be used to categorize the finding aid as an inventory, register, or other format.

Derived from att.typed

Status Optional

Datatype

**Contained by** EAD:ead

**May contain** EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement bibliography bioghist controlaccess custodhist dao daogrp descgrp did dsc fileplan note odd originalsfloc otherfindaid phystech prefercite processinfo relatedmaterial runner scopecontent separatedmaterial userestrict

**Note** The Descriptive Identification <did> element is required to appear in <archdesc> before presenting more detailed descriptions in <bioghist>, <scopecontent>, and <dsc>, in order to provide first a basic description of the archival materials.

**Schematron** This constraint exists only for technical reasons. Without the declaration of the EAD namespace, the transformation in relaxNG wouldn't work.

<s:ns prefix="ead" uri="urn:isl:1-931666-22-9"/>

**Schematron** This constraint exists only for technical reasons. Without the declaration of the TEI namespace, the transformation in relaxNG wouldn't work.

<s:ns prefix="tei" uri="http://www.tei-c.org/ns/1.0"/>
<table>
  <tr>
    <td>Schematron</td>
    <td>&lt;archdesc&gt; MUST have a level attribute.<br/>&lt;s:rule context="ead:archdesc"&gt; &lt;s:assert role="MUST" test="@level"&gt;archdesc<br/>MUST have a level-attribute&lt;/s:assert&gt; &lt;/s:rule&gt;</td>
  </tr>
  <tr>
    <td>Schematron</td>
    <td>The value of the &lt;archdesc&gt; level attribute SHOULD be limited to four values:<br/>&lt;s:rule context="ead:archdesc"&gt; &lt;s:assert role="COULD" test="@level = 'fonds' or<br/>@level = 'recordGrp' or @level = 'collection' or @level='otherlevel'"&gt;The value of the<br/>archdesc level attribute SHOULD be 'fonds', 'recordGrp', 'collection' or<br/>'otherlevel'.&lt;/s:assert&gt; &lt;/s:rule&gt;</td>
  </tr>
  <tr>
    <td>Schematron</td>
    <td>&lt;archdesc&gt;should contain a non-empty &lt;origination&gt; element.<br/>&lt;s:rule context="ead:archdesc"&gt; &lt;s:assert role="SHOULD"<br/>test="ead:did/ead:origination and normalize-<br/>space(ead:did/ead:origination)&gt;archdesc SHOULD have a non-empty<br/>origination&lt;/s:assert&gt; &lt;/s:rule&gt;</td>
  </tr>
  <tr>
    <td>Schematron</td>
    <td>If &lt;archdesc&gt; should contain a non-empty &lt;processinfo&gt; element.<br/>&lt;s:rule context="ead:archdesc"&gt; &lt;s:assert role="SHOULD" test="normalize-<br/>space(ead:processinfo)&gt;archdesc-processinfo SHOULD not be empty&lt;/s:assert&gt;<br/>&lt;/s:rule&gt;</td>
  </tr>
  <tr>
    <td>Schematron</td>
    <td>The &lt;processinfo&gt; element SHOULD contain a &lt;date&gt; element as descendant.<br/>&lt;s:rule context="ead:archdesc"&gt; &lt;s:assert role="SHOULD" test="normalize-<br/>space(ead:processinfo/ead:p/ead:-date)&gt;archdesc-processinfo SHOULD have a<br/>non empty date&lt;/s:assert&gt; &lt;/s:rule&gt;</td>
  </tr>
  <tr>
    <td>Schematron</td>
    <td>The &lt;archdesc&gt; element COULD contain a &lt;langmaterial&gt; element.<br/>&lt;s:rule context="ead:archdesc"&gt; &lt;s:assert role="COULD"<br/>test="ead:did/ead:langmaterial&gt;archdesc COULD have a langmaterial&lt;/s:assert&gt;<br/>&lt;/s:rule&gt;</td>
  </tr>
  <tr>
    <td>Schematron</td>
    <td>The &lt;archdesc&gt; element COULD contain a &lt;custodhist&gt; element.<br/>&lt;s:rule context="ead:archdesc"&gt;<br/>&lt;s:assert role="COULD" test="ead:custodhist&gt;archdesc COULD have a<br/>custodhist&lt;/s:assert&gt; &lt;/s:rule&gt;</td>
  </tr>
  <tr>
    <td>Schematron</td>
    <td>The &lt;archdesc&gt; element COULD contain a &lt;otherfindaid&gt; element.<br/>&lt;s:rule context="ead:archdesc"&gt; &lt;s:assert role="COULD"<br/>test="ead:otherfindaid"&gt;archdesc COULD have an otherfindaid&lt;/s:assert&gt; &lt;/s:rule&gt;</td>
  </tr>
  <tr>
    <td>Schematron</td>
    <td>The &lt;archdesc&gt; element COULD contain a &lt;originalsloc&gt; element.<br/>&lt;s:rule context="ead:archdesc"&gt; &lt;s:assert role="COULD"<br/>test="ead:originalsloc"&gt;archdesc COULD have an originalsloc&lt;/s:assert&gt; &lt;/s:rule&gt;</td>
  </tr>
  <tr>
    <td>Schematron</td>
    <td>The &lt;archdesc&gt; element COULD contain a &lt;altformavail&gt; element.<br/>&lt;s:rule context="ead:archdesc"&gt; &lt;s:assert role="COULD"<br/>test="ead:altformavail"&gt;archdesc COULD have an altformavail&lt;/s:assert&gt; &lt;/s:rule&gt;</td>
  </tr>
  <tr>
    <td>Schematron</td>
    <td>The &lt;archdesc&gt; element COULD contain a &lt;bibliography&gt; element.<br/>&lt;s:rule context="ead:archdesc"&gt; &lt;s:assert role="COULD"<br/>test="ead:bibliography"&gt;archdesc COULD have a bibliography&lt;/s:assert&gt; &lt;/s:rule&gt;</td>
  </tr>
  <tr>
    <td>Schematron</td>
    <td>The &lt;archdesc&gt; element COULD contain a &lt;odd&gt; element<br/>&lt;s:rule context="ead:archdesc"&gt; &lt;s:assert role="COULD" test="ead:odd"&gt;archdesc<br/>COULD have an odd&lt;/s:assert&gt; &lt;/s:rule&gt;</td>
  </tr>
  <tr>
    <td>Schematron</td>
    <td>The &lt;archdesc&gt; element COULD contain a &lt;note&gt; element.<br/>&lt;s:rule context="ead:archdesc"&gt; &lt;s:assert role="COULD" test="ead:note"&gt;archdesc<br/>COULD have a note&lt;/s:assert&gt; &lt;/s:rule&gt;</td>
  </tr>
  <tr>
    <td>Schematron</td>
    <td>The &lt;archdesc&gt; element COULD contain a &lt;controlaccess&gt; element.<br/>&lt;s:rule context="ead:archdesc"&gt; &lt;s:assert role="COULD"<br/>test="ead:controlaccess"&gt;archdesc COULD have a controlaccess&lt;/s:assert&gt;<br/>&lt;/s:rule&gt;</td>
  </tr>
  <tr>
    <td>Schematron</td>
    <td>A &lt;scopecontent&gt; element SHOULD be present in the description at least in</td>
  </tr>
</table>
<archdesc>, if not in the <c> elements.

<s:rule context="ead:archdesc" role="SHOULD"> <s:assert test="ead:scopecontent or ead:dsc/ead:c01/descendant-or-self::ead:scopecontent">a scopecontent element SHOULD be present at least in archdesc if not in the c elements</s:assert> </s:rule>

## Content model

<content/>

## Schema Declaration

element archdesc
{
    att.EADGlobal_attributes,
    att relatedencoding_attributes,
    att desc.c.attribute.otherlevel,
    attribute level
    {
        "class"
        | "collection"
        | "fonds"
        | "item"
        | "otherlevel"
        | "recordgrp"
        | "series"
        | "subfonds"
        | "subgrp"
        | "subseries"
        | "file"
    }
}

>>

tei:constraintSpec
[
    ident = "otherlevel"
    scheme = "isoschematron"
    type = "EHRI"
    mode = "add"
    "If the attribute " level"
    """ has the value 'otherlevel', an attribute """
    "otherlevel"
    " MUST be added"
    """If the attribute level has the value 'otherlevel', an attribute otherlevel MUST be a dded""
]

>>

tei:constraintSpec
[
    ident = "levelFonds"
    scheme = "isoschematron"
    type = "EHRI"
    mode = "add"
    "The " <archdesc>"
" element can have for "
"level"
""" the value 'fonds', not the subcomponents, """
"<c01>"
" to "
"<c06>"
"""The archdesc can have for level the value 'fonds', not the subcomponents."""
]
>>
tei:constraintSpec
[
ident = "recordgrplevel"
scheme = "isoschematron"
type = "EHRI"
mode = "add"
"A component with "
"level"
"""="recordgrp" SHOULD be a child of another component with """
"level"
"""="recordgrp""
"recordgrp SHOULD be a child of another recordgrp"
]
>>
tei:constraintSpec
[
ident = "subgrpLevel"
scheme = "isoschematron"
type = "EHRI"
mode = "add"
"A component with "
"level"
"""="subgrp" SHOULD be a child of another component with """
"level"
"""="subgrp" or "recordgrp""
"subgrp SHOULD be a child of another subgrp or a recordgrp"
]
>>
tei:constraintSpec
[
ident = "subseriesLevel"
scheme = "isoschematron"
type = "EHRI"
mode = "add"
"A component with "
"level"
"""="subseries" SHOULD be a child of another component with """
"level"
"""="subseries" or "series""
"subseries SHOULD be a child of another subseries or a series"
],
attribute type { data.enumerated }?,
 runners*, did, model desc full* )
}

## <archdescgrp>

### <archdescgrp>
(Archival Description Group) A wrapper element used only within <eadgrp> in the EAD Group Document Type Definition. The <archdescgrp> summarizes the content, context, and extent of the archival materials described in separate EAD documents bundled within the <dscgrp> subelement. The <archdescgrp> may contain all data elements available in <archdesc>, except for <dsc>; the <dscgrp> subelement fills the role of <dsc>. As with <archdesc>, a Descriptive Identification <did> element is required to appear in <archdescgrp> before presenting more detailed descriptions in such elements as <bioghist>.

**Module** EAD

**Attributes**
* att.EADGlobal (@id, @altrender, @audience, @encodinganalog)
* att relatedencoding (@relatedencoding) att desc.c (@level, @otherlevel)

**Contained by** —

**May contain**
EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement
bibliography bioghist controlaccess custodhist dao daogrp descgrp did dsc fileplan
note odd originalsloc otherfindaid phystech prefercite processinfo relatedmaterial
runner scopecontent separatedmaterial userestrict

**Note**
See also the <eadgrp> element.

**Content model**

<content>
</content>

**Schema Declaration**

element archdescgrp
{
  att.EADGlobal_attributes,
  att-relatedencoding_attributes,
  att desc.c_attributes,
  ( runner*, did, model desc full*, dscgrp )
}

## <archref>

### <archref>
(Archival Reference) A reference element that provides a citation and/or an electronic link to separately described archival materials of special interest. Examples of such materials include a record group and one of its large series (which might have separate EAD-encoded finding aids) and a general reference to a collection with similar content.

**Module** EAD

**Attributes**
* att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att.roled (@role)
* att.xlink (@label, @href, @type, @title, @from, @to, @role, @actuate, @show, @arcrole, @xpointer, @entityref, @target, @parent)

**Member of** model refs

**Contained by**
EAD: abstract bibliography bibref creation descrules dimensions emph entry event extref item label langmaterial langusage materialspec origination otherfindaid p physdesc physfacet physloc ref relatedmaterial repository separatedmaterial unitdate unitid unittitle

**May contain**
EAD: abbr abstract bibref container dao daogrp emph expan extptr extref
langmaterial lb materialspec note origination physdesc physloc ptr ref repository title
unitdate unitid unittitle

**Note**
The <archref> element can be helpful in several situations. It can be used, with the
**Declaration** element archref
{
  att.EADGlobal_attributes,
  att.roled_attributes,
  att.xlink_attributes,
  (
    text
    | model.phrase.basicConfig
    | bibref
    | ref
    | title
    | extref
    | model.did
  )*
}

## <arrangement>

<arrangement> (Arrangement) Information on how the described materials have been subdivided into smaller units, e.g., record groups into series, identifying the logical or physical groupings within a hierarchical structure. Can also be used to express the filing sequence of the described materials, such as the principle characteristics of the internal structure, or the physical or logical ordering of materials, including alphabetical, chronological, geographical, office of origin, and other schemes. Identifying logical groupings and the arrangement pattern may enhance retrieval by researchers.

**Module** EAD

**Attributes** att.EADGlobal (@id, @altrender, @audience, @encodinganalog)

**Member of** model desc base

**Contained by** EAD: archdesc archdescgrp arrangement c c01 c02 c03 c04 c05 c06 c07 c08 c09 c10 c11 c12 descgrp scopecontent

**May contain** EAD: address arrangement blockquote chronlist head list note p table

**Note** The <arrangement> element may occur within <archdesc> and <c> or as a subelement of <scopecontent>. The <arrangement> element is comparable to ISAD(G) data element 3.3.4 and MARC field 351. The ENCODINGANALOG attribute may be used to differentiate between the 351 subfield a (organization) and subfield b (arrangement).

**Example**
<arrangement xmlns="urn:isl:1-931666-22-9">
  <head>Arrangement of the Collection</head>
  <p>The filing system for the Braman Collection has been kept substantially in its original form. That is, original folders and their titles have been retained. The processor devised the basic organization scheme for the collection and, where necessary, reorganized the papers within the various component groups.</p>
</arrangement>

**Example**
<c01 xmlns="urn:isl:1-931666-22-9" level="series">
  <did>
    <unittitle>Research files</unittitle>
    <unitdate type="inclusive"
      normal="1887/1995">1887-1995</unitdate>
    <physdesc>
      <extent>3.5 linear feet (4 boxes)</extent>
    </physdesc>
  </did>
```xml
</physdesc>
</did>
<scopecontent>
<p>This series consists of newspaper clippings and research
notes of Fred Reed, pertaining to the Champlain
Transportation Company, its vessels, and the vessels'
crew members. Several of the folders of chronological
clippings include subjects, such as the move of the
Ticonderoga (1954-1955) and the sale of the Champlain
Transportation Company (1966). A number of clippings
under "Persons" are obituaries. Two folders under the
subseries "Notes" contain handwritten notes by Fred Reed
broadly pertaining to the history of the Champlain
Transportation Company, including a chronology, a list
of crew members, and information about the Company's
vessels.</p>
<arrangement>
<p>Organized into three subseries: <list type="simple">
  <item>Clippings--chronological</item>
  <item>Clippings--persons</item>
  <item>Notes</item>
</list>
</p>
</arrangement>
</scopecontent>
</c01>
```

### Example

```xml
<c03 xmlns="urn:isl:1-931666-22-9" level="file">
```

```xml
<did>
```

```xml
<unititle id="bruce.A.2.3">Letters from various
  correspondents to Craufurd Bruce</unititle>
```

```xml
<unitdate normal="1807/1819">1807-19</unitdate>
```

```xml
<unitid>MS. Eng. c. 5746</unitid>
```

```xml
<physdesc>
```

```xml
<extent>126 leaves</extent>
```

```xml
</physdesc>
```

```xml
</did>
```

```xml
<arrangement>
```

```xml
<p>Alphabetical, Grey - Peterkin</p>
```

```xml
</arrangement>
```

```xml
<scopecontent>
```

```xml
<p>Mainly relating to Michael Bruce, with drafts of a few
  letters from Craufurd Bruce.</p>
```

```xml
</scopecontent>
```

```xml
</c03>
```

### Content model

```xml
<content>
```

```xml
</content>
```

### Schema Declaration

element arrangement
```json
{
    att.EADGlobal_attributes,
    head?,
    (model_blocks | arrangement)+
}
```

## <author>

<author> (Author) Name(s) of institution(s) or individual(s) responsible for compiling the intellectual content of the finding aid. May include a brief statement indicating the nature of the responsibility, for example, archivist, collections processor, or records manager. Because acknowledgment of such individuals or institutions often appears on the title page of a finding aid, the <author> element is available in both the required <titlestmt> portion of the <eadheader> and the optional <titlepage> element in <frontmatter>.

<table><tr><td>Module</td><td>EAD</td></tr><tr><td>Attributes</td><td>att.EADGlobal (@id, @altrender, @audience, @encodinganalog)</td></tr><tr><td>Contained by</td><td>EAD: titlepage titlestmt</td></tr><tr><td>May contain</td><td>EAD: emph extptr lb ptr</td></tr><tr><td>Note</td><td>Use the &lt;creation&gt; element found under &lt;profiledesc&gt; to designate the encoder of the finding aid. Use the &lt;persname&gt; or &lt;corpname&gt; element with the ROLE attribute to designate the author in a Bibliographic Reference &lt;bibref&gt; citation. Use the &lt;origination&gt; element to designate the compiler, collector, or creator of the materials being described.</td></tr><tr><td>Example</td><td><filedesc xmlns="urn:islbn:1-931666-22-9"><titlestmt><titleproper>Register of the Rhea Higbee Wakeling Collection</titleproper><author>The print and machine readable finding aids for this collection were created by the Special Collections staff, Gerald R. Sherratt Library.</author></titlestmt><</filedesc></td></tr><tr><td>Example</td><td><frontmatter xmlns="urn:islbn:1-931666-22-9"><titlepage><titleproper>Indians Overseas</titleproper><subtitle>A guide to source materials in the India Office Records for the study of Indian emigration, 1830-1950</subtitle><author>Timothy N. Thomas</author><publisher>THE BRITISH LIBRARY</publisher><date>1985</date><titlepage></titlepage></frontmatter></td></tr><tr><td>Content model</td><td><content></content></td></tr><tr><td>Schema Declaration</td><td>element author { att.EADGlobal_attributes, ( text | model.phrase.bare )* }</td></tr></table>
<bibliography>

<bibliography> (Bibliography) Citations to works that are based on, about, or of special value when using the materials being described, or works in which a citation to or brief description of the materials is available. The works could be books, articles, television programs, unpublished reports, web sites, or other forms of information. The <bibliography> may be a simple <list>, a list of both Bibliographic References <bibref> and Archival References <archref>, or a series of Paragraphs <p>.

<table><tr><td>Module</td><td>EAD</td></tr><tr><td>Attributes</td><td>att.EADGlobal (@id, @altrender, @audience, @encodinganalog)</td></tr><tr><td>Member of</td><td>model desc base</td></tr><tr><td>Contained by</td><td>EAD: archdesc archdescgrp bibliography c c01 c02 c03 c04 c05 c06 c07 c08 c09 c10 c11 c12 descgrp</td></tr><tr><td>May contain</td><td>EAD: address archref bibliography bibref blockquote chronlist extref head linkgrp list note p ref subtitle table title</td></tr><tr><td>Note</td><td>The <bibref> element may be used to designate single citations within Paragraphs <p> without opening the <bibliography> element. In EAD Version 1.0 <bibliography> was a subelement of Adjunct Descriptive Data <add>, which has been deprecated in EAD 2002 (see Appendix B). The new Description Group <descgrp> element, which can group any of the <did>-level elements (except the Description of Subordinate Components <dsc>), may be used to wrap elements where a group heading is desirable. The <descgrp> element can be used to replace <add> when converting finding aids encoded in EAD V1.0 to EAD 2002. The <bibliography> element is comparable to ISAD(G) data element 3.5.4 and MARC fields 510 and 581.</td></tr><tr><td>Example</td><td><bibliography xmlns="urn:isl:1-931666-22-9"><head>Bibliography</head><p>Sources consulted by John Kobler.</p><bibliography><head>Monographs</head><bibref><title render="italic">Affiches americaines</title><San Domingo: Imprimerie royale du Cap, 1782. Nos. 30, 35.</bibref><bibref>Ardouin, Charles Nicholas Celigny. <title render="italic">Essais sur l'histoire d'Haiti</title>. Port-au-Prince, 1865.</bibref><bibref>Bastien, Remy. <title render="italic">Anthologie du folklore haitien</title>, <title render="doublequote">Proverbes</title>. Mexico, 1946. pp.83-91.</bibref><bibref>Bellegarde, Dantes. <title render="italic">Dessalines a parle</title>. Port-au-Prince, 1948. Chap. IV: pp. 47-54.</bibref></bibliography><bibliography><head>Serial publications</head>...</bibliography></bibliography><content></content></table>
<table><tr><td>Schema Declaration</td><td>element bibliography<br/>{<br/>att.EADGlobal_attributes,<br/>( head?, ( model_blocks | model_refs | bibliography )+ )<br/>}</td></tr></table>

# <bibref>

<bibref> (Bibliographic Reference) A reference element that provides a citation and/or electronic link for a published work such as a book, article, dissertation, motion picture, or sound recording. The <bibref> may contain just text or some of the content-specific elements such as <title>, <imprint>, or <edition>, although the latter two elements are unlikely to be used for unpublished works.

<table><tr><td>Module Attributes</td><td>EAD<br/>att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att.roled (@role) att.xlink (@label, @href, @type, @title, @from, @to, @role, @actuate, @show, @arcrole, @xpointer, @entityref, @target, @parent) modelkol<br/>Member of Contained by model.kols<br/>May contain EAD: abstract archref bibliography creation descrules dimensions emph entry event extref item label langmaterial langusage materialspec origination otherfindaid p physdesc physfacet physloc ref relatedmaterial repository separatedmaterial unitdate unitid unittitle<br/>Note A list of <bibref>s may be gathered into a <bibliography>. A single <bibref> may be part of a Paragraph <p>. Use the HREF or ENTITYREF attribute to point to an electronic bibliographic work. Use the more specific <archref> element to cite or link to separately described archival materials. Do not confuse with the Reference <ref> element, which is an internal link from one place in a finding aid to another place in the same finding aid. While XML Linking Language (XLink) Version 1.0, which is the basis for EAD linking elements, is a stable document, examples of EAD usage are hypothetical and have not been tested in real XLink-based applications. Those wishing to use XLink are encouraged to consult the specification available online at http://www.w3.org/TR/xlink.</td></tr></table>

<table><tr><td>Example</td><td>&lt;p xmlns="urn:isl:1-931666-22-9"&gt;The Archibald MacLeish Papers are described in &lt;bibref&gt;<br/>&lt;title render="italic"&gt;Library of Congress Acquisitions: Manuscript Division, 1982, &lt;/title&gt; p. 29. &lt;/bibref&gt;<br/>&lt;/p&gt;</td></tr><tr><td>Example</td><td>&lt;bibliography xmlns="urn:isl:1-931666-22-9"&gt;<br/>&lt;head&gt;Bibliography&lt;/head&gt;<br/>&lt;p&gt;Sources consulted by John Kobler.&lt;/p&gt;<br/>&lt;bibref&gt;<br/>&lt;title render="italic"&gt;Affiches americaines&lt;/title&gt;. San Domingo: Imprimerie royale du Cap, 1782. Nos. 30, 35.&lt;/bibref&gt;<br/>&lt;bibref&gt>Ardouin, Charles Nicholas Celigny. &lt;title render="italic"&gt;Essais sur l'histoire d'Haiti&lt;/title&gt;.<br/>Port-au-Prince, 1865.&lt;/bibref&gt;</td></tr></table>
<bibref>Bastien, Remy. <title render="italic">Anthologie du folklore haitien</title>, <title render="doublequote">Proverbes</title>. Mexi co, 1946. pp.83-91.</bibref>
<bibref>Bellegarde, Dantes. <title render="italic">Dessalines a parle</title>. Port-au-Prince, 1948. Chap. IV: pp. 47-54.</bibref> ... </bibliography>

## Content model

<content>
</content>

## Schema

### Declaration

element bibref
{
  att.EADGlobal_attributes,
  att.roled_attributes,
  att.xlink_attributes,
  (
    text
    | model.phrase.basicConfig
    | edition
    | imprint
    | name
    | num
    | bibseries
    | ref
    | title
    | famname
    | persname
    | corpname
    | extref
    | archref
  )*
}

## <bibseries>

<bibseries> (Bibliographic Series) Information about the published series in which a book, encoded finding aid, or other published work has appeared. Refers to monographic series only. Not to be used for archival series.

**Module** EAD

**Attributes** att.EADGlobal (@id, @altrender, @audience, @encodinganalog)

**Contained by** EAD: bibref titlepage unittitle

**May contain** EAD: emph extptr lb num ptr title

**Example** <frontmatter xmlns="urn:isl:1-931666-22-9">
<titlepage>
</titlepage>

<bibseries>Guides to Special Collections in the Music Division of the Library of Congress</bibseries>

<titleproper>Irving Fine Collection</titleproper>

**Example** <bibliography xmlns="urn:isl:1-931666-22-9">
<head>Selected Bibliography of History of the Harvard University</head>
Department of Physics</head>
<bibref>
<persname>Morton, Charles</persname>. <title>Compendium Physicae</title>. <imprint> [<geogname>Boston
</geogname>: <publisher>Colonial Society of Massachusetts, </publisher>
<date normal="1940">1940</date>].</imprint>
<bibseries>Colonial Society of Massachusetts. Publications ;
</num>v. 33</num>.</bibseries>
</bibref>
</bibliography>

Content model

<content>
</content>

Schema

Declaration element bibseries
{
  att.EADGlobal_attributes,
  ( text | model.phrase.bare | title | num )*
}

<bioghist>

<bioghist> (Biography or History) A concise essay or chronology that places the archival materials in context by providing information about their creator(s). Includes significant information about the life of an individual or family, or the administrative history of a corporate body. The <bioghist> may contain just text in a series of Paragraphs <p>, and/or a Chronology List <chronlist> that matches dates and date ranges with associated events. Additional <bioghist> elements may be nested inside one another when a complex body of materials, such as a collection of family papers, is being described, and separately headed sections are desired. The <bioghist> element may also be nested to designate a portion of the essay or chronology that might be extracted as a MARC 545 subfield.

Module EAD

Attributes att.EADGlobal (@id, @altrender, @audience, @encodinganalog)

Member of model desc base

Contained by EAD: archdesc archdescgrp bioghist c c01 c02 c03 c04 c05 c06 c07 c08 c09 c10 c11 c12 descgrp

May contain EAD: address bioghist blockquote chronlist dao daogrp head list note p table

Note

Many elements, such as <bioghist> are recursive (i.e., the elements are
available within themselves) to facilitate the use of multiple headings with
subdivided descriptions for complex collections, and to enable EAD markup to
be used for a variety of output. In Example 1 below, <bioghist> is repeated
within itself to enable the extraction of a brief biographical note for a MARC
record. The <bioghist> element is comparable to ISAD(G) data element 3.2.2
and MARC field 545.

Example

<bioghist xmlns="urn:isl:1-931666-22-9">
  <head>Administrative History</head>
  <bioghist encodinganalog="545$a">
    <p id="PRO123">In October 1964 the incoming Labour government created new office of Secretary of State for Economic Affairs (combined with First Secretary of
State) and set up the Department of Economic Affairs under the Ministers of the Crown Act 1964 to carry primary responsibility for long term economic planning.</p>

</bioghist>

<p>Under the Act the posts of Economic Secretary to the Treasury and Secretary of State for Industry, Trade and Regional Development were abolished.</p>

<p>George Brown was appointed as First Secretary of State and Secretary of</p>

<p>Composition of DEA: most of Treasury's National Economy Group (excluding the short term forecasting team); economic planning staff from the National Economic Development Office (NEDO); the regional policy divisions from the Board of Trade; a team of industrial experts.</p>

<p>DEA charged with duty of formulating, with both sides of industry, a National Plan (published in September 1965), co-ordinating the work of other departments in implementing policies of economic growth, particularly in the fields of industry, the regions, and prices and incomes.</p>

</bioghist>

## Example

<bioghist xmlns="urn:isl:1-931666-22-9">

<head>Chronology</head>

<chronlist>

<chronitem>

<date normal="18401012">1840</date>

<event>Born Helena Opid in Krakow, Poland on October 12th.</event>

<chronitem>

<chronitem>

<date normal="1861">1861</date>

<event>Made stage debut as Helena Modrzejewska in charity fair production of <title>The White Camellia</title>, in Bochnia, Poland.</event>

<chronitem> . . . <chronitem>

<date normal="19090409">1909</date>

<event>Died April 8th at her home on Bay Island. Funeral services held at St. Vibiana's Cathedral in Los Angeles, and Modjeska was later buried in her native Krakow.</event>

<chronitem>

<</chronlist>

</bioghist>

## Content model

<content>

</content>

## Schema Declaration

element bioghist

{ att.EADGlobal_attributes, head?,
( model Approximate blocks | bioghost | dao | daogrp )+

<blockquote>

<blockquote> (Block Quote) A formatting element that designates an extended quotation. The quotation is set off from the text by spacing or other typographic distinction.

<table><tr><td>Module</td><td>EAD</td></tr><tr><td>Attributes</td><td>att.EADGlobal (@id, @altrender, @audience, @encodinganalog)</td></tr><tr><td>Member of</td><td>model.inter</td></tr><tr><td>Contained by</td><td>EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement bibliography bioghost controlaccess custodhist daodesc descgrp div dsc dscgroup event extrefloc index item note odd originalsloc otherfindaid p phystech prefercite processinfo ref refloc relatedmaterial scopecontent separatedmaterial userestrict</td></tr><tr><td>May contain</td><td>EAD: address chronlist list note p table</td></tr><tr><td>Note</td><td>Use the Emphasis &lt;emph&gt; element, not &lt;blockquote&gt;, to tag words that are set off with quotations for emphasis or as a small quoted phrase that occurs, "as these words do," in the line of text.</td></tr><tr><td>Example</td><td>&lt;bioghost xmlns="urn:isbn:1-931666-22-9"&gt;<br/>&lt;head&gt;Administrative History&lt;/head&gt;<br/>&lt;p&gt;The Brewster presidential administration's primary objective was to raise academic standards comprehensively throughout Yale University. This required the substantial revision of certain existing policies and disciplines, as well as the development of new programs, schools, and departments.&lt;/p&gt;<br/>&lt;p&gt;President Brewster began this process in the 1960s by significantly increasing the size of the faculty and by actively recruiting renowned non-Yale scholars to fill the positions. According to Brewster, previous Yale administrations tended to overlook high caliber academicians who graduated and specialized outside the university. . .&lt;/p&gt;<br/>&lt;p&gt;As the size of the Yale faculty increased, Brewster's new admissions policies caused the make up of the undergraduate body to shift. By the early 1960s, most undergraduates had prepared at private schools, and many were sons of Yale alumni. As with the faculty, Brewster felt that Yale was consistently overlooking some of the best intellectual student talent necessary to maintain the highest levels of academic excellence. In a 1965 speech to alumni, Brewster summarized his administration's revised recruitment policy by stating that Yale would only seek students &lt;blockquote&gt;&lt;p&gt;whose capacity for intellectual achievement is outstanding and who also have the motivation to put their intellectual capacities to creatively influential use, in thought, in art, in science, or in the exercise of public or private or professional responsibility.&lt;/p&gt;<br/>&lt;/blockquote&gt;<br/>&lt;/p&gt; . . . &lt;/bioghost&gt;</td></tr></table>

Content model
<content>

</content>

## Schema

## Declaration

element blockquote { att.EADGlobal_attributes, ( model.inter.noquote | p )+ }

## <c>

<c> (Component (Unnumbered)) A wrapper element that designates a subordinate part of the materials being described. A Component <c> provides information about the content, context, and extent of a subordinate body of materials. It is always nested within a Description of Subordinate Components <dsc> and often within another <c> element. Each <c> element identifies an intellectually logical section of the described materials. The physical filing separations between components do not always coincide with the intellectual separations. For example, a <c> that designates dramatic works might end in the same box in which the next <c> begins with short stories. Also, not every <c> directly corresponds to a folder or other physical entity. Some <c> elements simply represent a stage within a hierarchical description.

**Module** EAD

**Attributes**
att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att desc.c (@level, @otherlevel)

**Contained by** EAD: c dsc

**May contain**
EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement bibliography bioghist c controlaccess custodhist dao daogrp descgrp did dsc fileplan head note odd originalsloc otherfindaid phystech prefercite processinfo relatedmaterial scopecontent separatedmaterial thead userestrict

**Note**
Components may be subdivided into smaller and smaller components and may eventually reach the level of a single item. For example, the components of a collection may be series, components of series may be subseries, components of subseries may be files, and components of files may be items. A component may be either an unnumbered <c> or a numbered <c01>, <c02>, etc. The numbered components <c01> to <c12> assist a finding aid encoder in nesting up to twelve component levels accurately. Use the LEVEL attribute to identify the descriptive character of the component, for example, "series," "subseries," "subfonds," "subgrp," "file," or "item." Assigning a LEVEL attribute for the highest <c> is recommended; thereafter the attribute may be used when the repository deems it useful.

**Example**

```xml
dsc xmlns="urn:isbn:1-931666-22-9" type="combined">
  <c level="series">
    <did>
      <unitid>Series 1</unitid>
      <unititle>Correspondence</unititle>
    </did>
    <scopecontent>[...]</scopecontent>
    <c level="subseries">
      <did>
        <unitid>Subseries 1.1</unitid>
        <unititle>Outgoing Correspondence</unititle>
      </did>
      <c level="file">
        <did>
          <unititle>Abbinger-Aldrich</unititle>
        </did>
      </c>
    </did>
  </c>
</dsc>
```
## Content model

```xml
<content>
</content>
```

## Schema Declaration

```xml
element c
{
    att.EADGlobal_attributes,
    att desc.c_attributes,
    head?,
    did,
    model desc.full*,
    ( thead?, c+ )*
}
```

## <c01>

<c01> (Component (First Level)) A wrapper element that designates the top or first-level subordinate part of the materials being described. Components may be either unnumbered <c> or numbered <c01>, <c02>, etc. The numbered components <c01> to <c12> assist a finding aid encoder in nesting up to twelve component levels accurately.

**Module** EAD

**Attributes**
att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att desc.c (@level, @otherlevel)

**Contained by** EAD: dsc

**May contain**
EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement bibliography bioghist c02 controlaccess custodhist dao daogrp descgrp did dsc fileplan head note odd originalsloc otherfindaid phystech prefercite processinfo relatedmaterial scopecontent separatedmaterial thead userestrict

**Note**
The LEVEL attribute is used to identify which level of description the <c01> covers, e.g., "series," "subseries," "file," or "item." Do not expect that all elements at the same numbered component designation represent the same level of description. The <c01> element can start at different levels of description in different finding aids, and, the quantity of hierarchical components can vary between, for example, a "series" and a "file." For example, a <c03> element could represent a "file" in one part of a finding aid, and in another part of the finding aid, a file might be a <c05> element because additional hierarchical groupings were needed to categorize the materials being described. See the description under Component <c> for additional
<table>
  <tr>
    <td>Example</td>
    <td>
      <pre><code>information.
&lt;dsc xmlns="urn:isbn:1-931666-22-9" type="combined"&gt;
&lt;c01 level="series"&gt;
&lt;did&gt;
&lt;unittitle&gt;Topical Files&lt;/unittitle&gt;
&lt;unitdate normal="1918/1945">1918-1945&lt;/unitdate&gt;
&lt;/did&gt;
&lt;scopecontent>[...]</scopecontent>
&lt;c02 level="file"&gt;
&lt;did&gt;
&lt;unittitle&gt;California Dining Club&lt;/unittitle&gt;
&lt;/did&gt;
&lt;c03 level="file"&gt;
&lt;did&gt;
&lt;unittitle&gt;Annual financial statements&lt;/unittitle&gt;
&lt;unitdate type="inclusive" normal="1923/1929">1923-1929&lt;/unitdate&gt;
&lt;/did&gt;
&lt;/c03&gt;
&lt;c03 level="file"&gt;
&lt;did&gt;
&lt;unittitle&gt;Membership rosters&lt;/unittitle&gt;
&lt;unitdate type="inclusive" normal="1918/1932">1918-1932&lt;/unitdate&gt;
&lt;/did&gt;
&lt;/c03&gt;
&lt;c03 level="file"&gt;
&lt;did&gt;
&lt;unittitle&gt;Minutes&lt;/unittitle&gt;
&lt;unitdate type="inclusive" normal="1925/1930">1925-1930&lt;/unitdate&gt;
&lt;/did&gt;
&lt;/c03&gt;
&lt;c03 level="file"&gt;
&lt;did&gt;
&lt;unittitle&gt;Newsletters&lt;/unittitle&gt;
&lt;unitdate type="inclusive" normal="1919/1932">1919-1932&lt;/unitdate&gt;
&lt;/did&gt;
&lt;/c03&gt;
&lt;/c02> ... &lt;/c01&gt;
&lt;/dsc&gt;
</code></pre>
    </td>
  </tr>
  <tr>
    <td>Schematron</td>
    <td>
      <pre><code>&lt;c01&gt; MUST have a level attribute.
&lt;s:rule context="ead:c01"> &lt;s:assert role="MUST" test="@level">c01 MUST have a level-attribute&lt;/s:assert&gt; &lt;/s:rule&gt;
</code></pre>
    </td>
  </tr>
  <tr>
    <td>Content model</td>
    <td>
      <pre><code>&lt;content/&gt;</code></pre>
    </td>
  </tr>
  <tr>
    <td>Schema Declaration</td>
    <td>
      <pre><code>element c01
{
  att.EADGlobal_attributes,
</code></pre>
    </td>
  </tr>
</table>
att desc c attributes,
head?,
did,
model desc full*,
( thread?, c02+ )*
}

<c02>

<c02> (Component (Second Level)) A wrapper element that designates a second-level subordinate part of the materials being described. Components may be either unnumbered <c> or numbered <c01>, <c02>, etc. The numbered components <c01> to <c12> assist a finding aid encoder in nesting up to twelve component levels accurately.

**Module** EAD

**Attributes**
att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att desc c
(@level, @otherlevel)

**Contained by** EAD: c01

**May contain**
EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement
bibliography bioghist c03 controlaccess custodhist dao daogrp descgrp did
dsc fileplan head note odd originalsloc otherfindaid phystech prefercite
processinfo relatedmaterial scopecontent separatedmaterial thead userestrict
See the description under Component (Unnumbered) <c> and Component
(First Level) <c01> for additional information. See examples under <c01>
Component (First Level) and in fully encoded examples in Appendix C.

**Schematron**
<c02> MUST have a level attribute.
<s:rule context="ead:c02"> <s:assert role="MUST" test="@level">c02 MUST
have a level-attribute</s:assert> </s:rule>

**Content model**
<content/>

**Schema Declaration**

element c02
{
  att.EADGlobal_attributes,
  att desc c attributes,
  head?,
  did,
  model desc full*,
  ( thread?, c03+ )*
}

<c03>

<c03> (Component (Third Level)) A wrapper element that designates a third-level subordinate part of the materials being described. Components may be either unnumbered <c> or numbered <c01>, <c02>, etc. The numbered components <c01> to <c12> assist a finding aid encoder in nesting up to twelve component levels accurately.

**Module** EAD

**Attributes**
att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att desc c
(@level, @otherlevel)

**Contained by** EAD: c02

**May contain**
EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement
bibliography bioghist c04 controlaccess custodhist dao daogrp descgrp did dsc fileplan head note odd originalsloc otherfindaid phystech prefercite processinfo relatedmaterial scopecontent separatedmaterial thead userestrict

**Note**
See the description under Component (Unnumbered) <c> and Component (First Level) <c01> for additional information. See examples under <c01> Component (First Level) and in fully encoded examples in Appendix C.

**Schematron**
<c03> MUST have a level attribute.
<s:rule context="ead:c03"> <s:assert role="MUST" test="@level">c03 MUST have a level-attribute</s:assert> </s:rule>

**Content model**
<content/>

**Schema Declaration**

element c03
{
  att.EADGlobal_attributes,
  att desc.c attributes,
  head?,
  did,
  model desc. full*,
  ( thread?, c04+ )*
}

<c04>

<c04> (Component (Fourth Level)) A wrapper element that designates a fourth-level subordinate part of the materials being described. Components may be either unnumbered <c> or numbered <c01>, <c02>, etc. The numbered components <c01> to <c12> assist a finding aid encoder in nesting up to twelve component levels accurately.

**Module** EAD
**Attributes**
att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att desc.c (@level, @otherlevel)

**Contained by** EAD: c03

**May contain**
EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement
bibliography bioghist c05 controlaccess custodhist dao daogrp descgrp did dsc fileplan head note odd originalsloc otherfindaid phystech prefercite processinfo relatedmaterial scopecontent separatedmaterial thead userestrict

**Note**
See the description under Component (Unnumbered) <c> and Component (First Level) <c01> for additional information. See examples under <c01> Component (First Level) and in fully encoded examples in Appendix C.

**Schematron**
<c04> MUST have a level attribute.
<s:rule context="ead:c04"> <s:assert role="MUST" test="@level">c04 MUST have a level-attribute</s:assert> </s:rule>

**Content model**
<content/>

**Schema Declaration**

element c04
{
  att.EADGlobal_attributes,
  att desc.c attributes,
  head?,
did,
model desc full*,
( thread?, c05+ )*
}

<c05>

<c05> (Component (Fifth Level)) A wrapper element that designates a fifth-level subordinate part of the materials being described. Components may be either unnumbered <c> or numbered <c01>, <c02>, etc. The numbered components <c01> to <c12> assist a finding aid encoder in nesting up to twelve component levels accurately.

<table><tr><td>Module</td><td>EAD</td></tr><tr><td>Attributes</td><td>att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att desc c (@level, @otherlevel)</td></tr><tr><td>Contained by</td><td>EAD: c04</td></tr><tr><td>May contain</td><td>EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement bibliography bioghist c06 controlaccess custodhist dao daogrp descgrp did dsc fileplan head note odd originalsloc otherfindaid phystech prefercite processinfo relatedmaterial scopecontent separatedmaterial thead userestrict</td></tr><tr><td>Note</td><td>See the description under Component (Unnumbered) &lt;c&gt; and Component (First Level) &lt;c01&gt; for additional information. See examples under &lt;c01&gt; Component (First Level) and in fully encoded examples in Appendix C.</td></tr><tr><td>Schematron</td><td>&lt;c05&gt; MUST have a level attribute.<br/>&lt;s:rule context="ead:c05"&gt; &lt;s:assert role="MUST" test="@level"&gt;c05 MUST have a level-attribute&lt;/s:assert&gt; &lt;/s:rule&gt;</td></tr><tr><td>Content model</td><td>&lt;content/&gt;</td></tr></table>

<table><tr><td>Schema Declaration</td><td>element c05<br/>{<br/>att.EADGlobal_attributes,<br/>att desc c_attributes,<br/>head?,<br/>did,<br/>model desc full*,<br/>( thread?, c06+ )*<br/>}</td></tr></table>

<c06>

<c06> (Component (Sixth Level)) A wrapper element that designates a sixth-level subordinate part of the materials being described. Components may be either unnumbered <c> or numbered <c01>, <c02>, etc. The numbered components <c01> to <c12> assist a finding aid encoder in nesting up to twelve component levels accurately.

<table><tr><td>Module</td><td>EAD</td></tr><tr><td>Attributes</td><td>att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att desc c (@level, @otherlevel)</td></tr><tr><td>Contained by</td><td>EAD: c05</td></tr><tr><td>May contain</td><td>EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement bibliography bioghist c07 controlaccess custodhist dao daogrp descgrp did dsc fileplan head note odd originalsloc otherfindaid phystech prefercite processinfo</td></tr></table>
<table><tr><td>Note</td><td>relatedmaterial scopecontent separatedmaterial thead userestrict<br/>See the description under Component (Unnumbered) &lt;c&gt; and Component (First Level) &lt;c01&gt; for additional information. See examples under &lt;c01&gt; Component (First Level) and in fully encoded examples in Appendix C.<br/>
Schematron
<br/>&lt;c06&gt; MUST have a level attribute.<br/>&lt;s:rule context="ead:c06"&gt; &lt;s:assert role="MUST" test="@level"&gt;c06 MUST have a level-attribute&lt;/s:assert&gt; &lt;/s:rule&gt;<br/>
Schematron
<br/>The component elements SHOULD be numbered components between &lt;c01&gt; and &lt;c06&gt;<br/>&lt;s:rule context="not(ead:c06)"&gt; &lt;s:assert role="SHOULD" test="ead:c07"&gt;c subelements SHOULD be between c01 and c06&lt;/s:assert&gt; &lt;/s:rule&gt;</td></tr><tr><td>Content model</td><td>&lt;content/&gt;</td></tr></table>

## Schema

<table><tr><td>Declaration</td><td>element c06<br/>{<br/>att.EADGlobal_attributes,<br/>att desc.c attributes,<br/>head?,<br/>did,<br/>model desc. full*,<br/>( thread?, c07+ )*<br/>}</td></tr></table>

## &lt;c07&gt;

&lt;c07&gt; (Component (Seventh Level)) A wrapper element that designates a seventh-level subordinate part of the materials being described. Components may be either unnumbered &lt;c&gt; or numbered &lt;c01&gt;, &lt;c02&gt;, etc. The numbered components &lt;c01&gt; to &lt;c12&gt; assist a finding aid encoder in nesting up to twelve component levels accurately.

**Module** EAD

**Attributes**
att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att desc.c (@level, @otherlevel)

**Contained by** EAD: c06

**May contain**
EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement bibliography bioghist c08 controlaccess custodhist dao daogrp descgrp did dsc fileplan head note odd originalsloc otherfindaid phystech prefercite processinfo relatedmaterial scopecontent separatedmaterial thead userestrict

**Note**

See the description under Component (Unnumbered) &lt;c&gt; and Component (First Level) &lt;c01&gt; for additional information. See examples under &lt;c01&gt; Component (First Level) and in fully encoded examples in Appendix C.

**Schematron**
The component elements SHOULD be numbered components between &lt;c01&gt; and &lt;c06&gt;
&lt;s:rule context="not(ead:c07)"&gt; &lt;s:assert role="SHOULD" test="ead:c08"&gt;c subelements SHOULD be between c01 and c06&lt;/s:assert&gt; &lt;/s:rule&gt;

**Content model**

&lt;content/&gt;

## Schema

<table><tr><td>Declaration</td><td>element c07<br/>{</td></tr></table>
att.EADGlobal_attributes,
att desc.c attributes,
head?,
did,
model desc. full*,
( thread?, c08+ )*
}

<c08>

<c08> (Component (Eighth Level)) A wrapper element that designates a eighth-level subordinate part of the materials being described. Components may be either unnumbered <c> or numbered <c01>, <c02>, etc. The numbered components <c01> to <c12> assist a finding aid encoder in nesting up to twelve component levels accurately.

**Module** EAD

**Attributes**
att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att desc.c (@level, @otherlevel)

**Contained by** EAD: c07

**May contain**
EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement bibliography bioghist c09 controlaccess custodhist dao daogrp descgrp did dsc fileplan head note odd originalsloc otherfindaid phystech prefercite processinfo relatedmaterial scopecontent separatedmaterial thead userestrict

**Note**
See the description under Component (Unnumbered) <c> and Component (First Level) <c01> for additional information. See examples under <c01> Component (First Level) and in fully encoded examples in Appendix C.

**Schematron**
The component elements SHOULD be numbered components between <c01> and <c06>
<s:rule context="not(ead:c08)"><s:assert role="SHOULD" test="ead:c09">c subelements SHOULD be between c01 and c06</s:assert> </s:rule>

**Content model**
<content/>

**Schema Declaration**

element c08
{
  att.EADGlobal_attributes,
  att desc.c attributes,
  head?,
  did,
  model desc. full*,
  ( thread?, c09+ )*
}

<c09>

<c09> (Component (Ninth Level)) A wrapper element that designates a ninth-level subordinate part of the materials being described. Components may be either unnumbered <c> or numbered <c01>, <c02>, etc. The numbered components <c01> to <c12> assist a finding aid encoder in nesting up to twelve component levels accurately.

**Module** EAD

**Attributes**
att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att desc.c (@level, @otherlevel)
<table><tr><td>Contained by</td><td>EAD: c08</td></tr><tr><td>May contain</td><td>EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement bibliography bioghist c10 controlaccess custodhist dao daogrp descgrp did dsc fileplan head note odd originalsloc otherfindaid phystech prefercite processinfo relatedmaterial scopecontent separatedmaterial thead userestrict</td></tr><tr><td>Note</td><td>See the description under Component (Unnumbered) &lt;c&gt; and Component (First Level) &lt;c01&gt; for additional information. See examples under &lt;c01&gt; Component (First Level) and in fully encoded examples in Appendix C.</td></tr><tr><td>Schematron</td><td>The component elements SHOULD be numbered components between &lt;c01&gt; and &lt;c06&gt;<br/>&lt;s:rule context="not(ead:c09)"&gt; &lt;s:assert role="SHOULD" test="ead:c10"&gt;c subelements SHOULD be between c01 and c06&lt;/s:assert&gt; &lt;/s:rule&gt;</td></tr><tr><td>Content model</td><td>&lt;content/&gt;</td></tr></table>

<table><tr><td>Schema Declaration</td><td>element c09<br/>{<br/>att.EADGlobal_attributes,<br/>att desc.c attributes,<br/>head?,<br/>did,<br/>model desc. full*,<br/>( thread?, c10+ )*<br/>}</td></tr></table>

## &lt;c10&gt;

### &lt;c10&gt; (Component (Tenth Level))
A wrapper element that designates a tenth-level subordinate part of the materials being described. Components may be either unnumbered &lt;c&gt; or numbered &lt;c01&gt;, &lt;c02&gt;, etc. The numbered components &lt;c01&gt; to &lt;c12&gt; assist a finding aid encoder in nesting up to twelve component levels accurately.

<table><tr><td>Module</td><td>EAD</td></tr><tr><td>Attributes</td><td>att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att desc.c (@level, @otherlevel)</td></tr><tr><td>Contained by</td><td>EAD: c09</td></tr><tr><td>May contain</td><td>EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement bibliography bioghist c11 controlaccess custodhist dao daogrp descgrp did dsc fileplan head note odd originalsloc otherfindaid phystech prefercite processinfo relatedmaterial scopecontent separatedmaterial thead userestrict</td></tr><tr><td>Note</td><td>See the description under Component (Unnumbered) &lt;c&gt; and Component (First Level) &lt;c01&gt; for additional information. See examples under &lt;c01&gt; Component (First Level) and in fully encoded examples in Appendix C.</td></tr><tr><td>Schematron</td><td>The component elements SHOULD be numbered components between &lt;c01&gt; and &lt;c06&gt;<br/>&lt;s:rule context="not(ead:c10)"&gt; &lt;s:assert role="SHOULD" test="ead:c11"&gt;c subelements SHOULD be between c01 and c06&lt;/s:assert&gt; &lt;/s:rule&gt;</td></tr><tr><td>Content model</td><td>&lt;content/&gt;</td></tr></table>

<table><tr><td>Schema Declaration</td><td>element c10</td></tr></table>
```json
{
    att.EADGlobal_attributes,
    att desc.c_attributes,
    head?,
    did,
    model desc.full*,
    ( thread?, c11+ )*
}
```

## <c11>

### <c11> (Component (Eleventh Level))
A wrapper element that designates an eleventh-level subordinate part of the materials being described. Components may be either unnumbered <c> or numbered <c01>, <c02>, etc. The numbered components <c01> to <c12> assist a finding aid encoder in nesting up to twelve component levels accurately.

**Module** EAD

**Attributes**
att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att desc.c (@level, @otherlevel)

**Contained by** EAD: c10

**May contain**
EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement bibliography bioghist c12 controlaccess custodhist dao daogrp descgrp did dsc fileplan head note odd originalsloc otherfindaid phystech prefercite processinfo relatedmaterial scopecontent separatedmaterial thead userestrict

**Note**
See the description under Component (Unnumbered) <c> and Component (First Level) <c01> for additional information. See examples under <c01> Component (First Level) and in fully encoded examples in Appendix C.

**Schematron**
The component elements SHOULD be numbered components between <c01> and <c06>
<s:rule context="not(ead:c11)"><s:assert role="SHOULD" test="ead:c12">c subelements SHOULD be between c01 and c06</s:assert></s:rule>

**Content model**
<content/>

**Schema Declaration**

element c11
```json
{
    att.EADGlobal_attributes,
    att desc.c_attributes,
    head?,
    did,
    model desc.full*,
    ( thread?, c12+ )*
}
```

## <c12>

### <c12> (Component (Twelfth Level))
A wrapper element that designates a twelfth-level subordinate part of the materials being described. Components may be either unnumbered <c> or numbered <c01>, <c02>, etc. The numbered components <c01> to <c12> assist a finding aid encoder in nesting up to twelve component levels accurately.

**Module** EAD

**Attributes**
att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att desc.c
<table><tr><td>Contained by</td><td>EAD: c11</td></tr><tr><td>May contain</td><td>EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement bibliography bioghist controlaccess custodhist dao daogrp descgrp did dsc fileplan head note odd originalsloc otherfindaid phystech prefercite processinfo relatedmaterial scopecontent separatedmaterial userestrict</td></tr><tr><td>Note</td><td>See the description under Component (Unnumbered) &lt;c&gt; and Component (First Level) &lt;c01&gt; for additional information. See examples under &lt;c01&gt; Component (First Level) and in fully encoded examples in Appendix C.</td></tr><tr><td>Content model</td><td>&lt;content&gt;<br/>&lt;/content&gt;</td></tr></table>

<table><tr><td>Schema Declaration</td><td>element c12<br/>{<br/>att.EADGlobal_attributes,<br/>att desc.c_attributes,<br/>head?,<br/>did,<br/>model desc full*<br/>}</td></tr></table>

## &lt;change&gt;

### &lt;change&gt; (Change)
An optional subelement in the <revisiondesc> portion of <eadheader> used for a brief description of an update made to an EAD document. Additions to a finding aid or significant recoding should be noted, but not correction of a few typographical errors. The <change> element is modeled on a header element in the Text Encoding Initiative (TEI) DTD. The TEI recommends that revisions be entered and numbered in reverse chronological order, with the most recent <change> first.

**Module** EAD

**Attributes** att.EADGlobal (@id, @altrender, @audience, @encodinganalog)

**Contained by** EAD: revisiondesc

**May contain** EAD: date item

**Note** The <edition> element can be used to designate a finding aid that has been so substantively changed that it constitutes a new version and supersedes earlier versions of the finding aid.

**Example**

```xml
<eadheader xmlns="urn:islb:1-931666-22-9" langencoding="iso639-2b"> ... <revisiondesc>
  <change>
    <date normal="19970505">May 5, 1997</date>
    <item>This electronic finding aid was updated to current markup standards by Sarah Taylor using a perl script. Updates included: eadheader, eadid, and arrangement of did elements and their labels.</item>
  </change>
</revisiondesc>
</eadheader>
```

**Schematron** In <revisiondesc>, each <change> element SHOULD contain a <date> element and a <item> element. [This rule has been taken from]

```xml
<s:rule context="ead:change" role="SHOULD"> <s:assert test=".[ead:-date and
```
ead:item"> 'revisiondesc/change' element SHOULD contain both a date and an item subelement. </s:assert> </s:rule>

**Schematron**
The <date> element for each <change> in <revisiondesc> SHOULD not be empty
<s:rule context="ead:change"> <s:assert role="SHOULD" test="normalize-space(ead date)">a revisiondesc/change SHOULD have a not empty date</s:assert> </s:rule>

**Content model**
<content/>

**Schema Declaration**
element change { att.EADGlobal_attributes, date, item+ }

**<chronitem>**

**<chronitem>** (Chronology List Item) A formatting element that keeps a date paired with an associated event or group of events within a Chronology List <chronlist>. Each <chronitem> contains a <date> (either a single date or date range) coupled with an <event> or description of what occurred during that time. When multiple <event>s are associated with a single <date>, the <event>s are bundled in an <eventgrp> tag, which is then easily paired with the appropriate <date>.

<table><tr><td>Module</td><td>EAD</td></tr><tr><td>Attributes</td><td>att.EADGlobal (@id, @altrender, @audience, @encodinganalog)</td></tr><tr><td>Contained by</td><td>EAD: chronlist</td></tr><tr><td>May contain</td><td>EAD: date event eventgrp</td></tr><tr><td>Example</td><td><bioghist xmlns="urn:isl:1-931666-22-9"><head>Chronology</head><chronlist><chronitem><date normal="18401012">1840</date><event>Born Helena Opid in Krakow, Poland on October 12th.</event></chronitem><chronitem><date normal="1861">1861</date><event>Made stage debut as Helena Modrzejewska in charity fair production of <title>The White Camellia</title>, in Bochnia, Poland.</event></chronitem> . . . <chronitem><date normal="19090409">1909</date><event>Died April 8th at her home on Bay Island. Funeral services held at St. Vibiana's Cathedral in Los Angeles, and Modjeska was later buried in her native Krakow.</event></chronitem></chronlist></bioghist></td></tr></table>

**Schema**
**Declaration** element chronitem { att.EADGlobal_attributes, date, ( event | eventgrp ) }

<chronlist>

<chronlist> (Chronology List) A formatting element that designates information about the sequence in which significant past events, associated with the described materials, occurred. The <chronlist> also provides a structured display to list these dates and events. Each <chronlist> contains Chronology Items <chronitem>s that pair a <date> or date range with a brief description of an associated <event> or events <eventgrp>.

<table><tr><td>Module</td><td>EAD</td></tr><tr><td>Attributes</td><td>att.EADGlobal (@id, @altrender, @audience, @encodinganalog)</td></tr><tr><td>Member of</td><td>model.inter.noquote</td></tr><tr><td>Contained by</td><td>EAD: accessrestrict accruals acqinfo altformavail appraisal arrangement bibliography bioghist blockquote controlaccess custodhist daodesc descgrp div dsc dscgroup event extrefloc index item note odd originalsloc otherfindaid p phystech prefercite processinfo ref refloc relatedmaterial scopecontent separatedmaterial userestrict</td></tr><tr><td>May contain</td><td>EAD: chronitem head listhead</td></tr><tr><td>Note</td><td>A <chronlist> most often appears in finding aids as part of the Biography or History <bioghist> element, but <chronlist> is also available for use in other elements that might need to present historical dates and events in a multicolumn list.</td></tr><tr><td>Example</td><td><bioghist xmlns="urn:isl:1-931666-22-9"><head>Biographical Note</head><chronlist><chronitem><date>1820, Dec. 20</date><event>Born eighth of ten children of Taylor and Dicey (Jones) Duke; Little River, Orange Co., N.C.</event></chronitem><chronitem><date>1842</date><event>Married Mary Caroline Clinton</event></chronitem><chronitem><date>1844</date><event>Sidney Taylor Duke born</event></chronitem> . . . </chronlist></bioghist></td></tr><tr><td>Content model</td><td><content></content></td></tr><tr><td>Schema Declaration</td><td>element chronlist { att.EADGlobal_attributes, head?, listhead?, chronitem+ }</td></tr></table>

<colspec/>

<colspec/> (Table Column Specification) An empty formatting element that designates the position and size of a single column in a Table <table>. Attributes specify the unique name of the column, its unique number within the table, its width and rules, and the horizontal alignment of text within the column. The quantity of columns in a <table> is determined by the COLS attribute of the
`<tgroup>` element, not by the number of `<colspec/>`s defined. The values set for `<colspec/>` override any values implied from `<tgroup>` or `<thead>` elements.

**Module** EAD
**Attributes** att.EADGlobal (@id, @altrender, @audience, @encodinganalog)

<table><tr><td>colnum</td><td>Status Datatype</td><td>Optional</td></tr><tr><td>colname</td><td>Status Datatype</td><td>Optional</td></tr><tr><td>colwidth</td><td>Status Datatype</td><td>Optional</td></tr><tr><td>colsep</td><td>Status Datatype</td><td>Optional</td></tr><tr><td></td><td>Legal values are: 1</td><td></td></tr></table>

O

<table><tr><td>rowsep</td><td>Status Datatype</td><td>Optional</td></tr><tr><td></td><td>Legal values are: 1</td><td></td></tr></table>

O

<table><tr><td>align</td><td>Status Datatype</td><td>Optional</td></tr><tr><td></td><td>Legal values are: left</td><td></td></tr><tr><td></td><td></td><td>right</td></tr><tr><td></td><td></td><td>center</td></tr><tr><td></td><td></td><td>justify</td></tr><tr><td></td><td></td><td>char</td></tr></table>

<table><tr><td>char</td><td>Status Datatype</td><td>Optional</td></tr><tr><td>charoff</td><td>Status Datatype</td><td>Optional</td></tr></table>

**Contained by** EAD: `tgroup`

**May contain** Empty element

**Note** See also related elements `<table>` and `<tgroup>`.

**Example**
```xml
<table xmlns="urn:ibn:1-931666-22-9" frame="none">
  <tgroup cols="3">
    <colspec colnum="1" colname="1" align="left" colwidth="50pt"/>
    <colspec colnum="2" colname="2" align="left" colwidth="50pt"/>
    <colspec colnum="3" colname="3" align="left" colwidth="50pt"/>
  </tgroup>
  <thead>
    <tr>
      <th>Major Family Members</th>
    </tr>
  </thead>
</table>
```
<entry colname="2">Spouses</entry>

<entry colname="3">Children</entry>

</row>

</thead>

<tbody>

<row>

<entry colname="1">John Albemarle

(1760-1806)</entry>

<entry colname="2">Mary Frances Delaney

(1769-1835)</entry>

<entry colname="3">John Delaney Albemarle

(1787-1848)</entry>

</row> . . . </tbody>

</tgroup>

</table>

## Content model

<content>

</content>

## Schema Declaration

element colspec

{ att.EADGlobal_attributes, attribute colnum { xsd:NMTOKEN }?, attribute colname { xsd:NMTOKEN }?, attribute colwidth { text }?, attribute colsep { "1" | "0" }?, attribute rowsep { "1" | "0" }?, attribute align { "left" | "right" | "center" | "justify" | "char" }?, attribute char { text }?, attribute charoff { xsd:NMTOKEN }?, empty }

## <container>

<container> (Container) A <did> subelement for information that contributes to locating the described materials by indicating the kinds of devices that hold the materials and identifying any sequential numbers assigned to those devices. The <container> element is used most frequently at the component level, i.e., once a Description of Subordinate Components <dsc> has been opened. This storage information can help researchers understand how extensive the material is, especially in the absence of a specific physical <extent> statement at the component level.

### Module

EAD

### Attributes

att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att.typed (@type) att.labeled (@label)

parent

Status

Optional

Datatype

### Member of

model.did

### Contained by

EAD: archref did

### May contain

EAD: emph extptr lb ptr

### Note

Use of the TYPE attribute is strongly recommended to clarify the nature of the storage device. Use any useful designations, such as "box," "folder," and
"reel." The Physical Location `<physloc>` element can be used to designate the shelves, stacks, rooms, buildings, or other places where the containers are stored.

Use the ID of the Unit `<unitid>` element to designate control numbers not associated with a physical container, for example, accession numbers. Most repositories use either `<container>` or `<unitid>` as the call numbers for fetching material for researchers. If both elements are used, consider setting the `LABEL` attribute to specify which element is the call number.

The `PARENT` attribute can be used to point to the `<container>` element that describes the box in which a folder is housed.

<table><tr><td>Example</td><td><dsc xmlns="urn:isl:1-931666-22-9" type="combined"><c level="series"><did><unittitle>Correspondence, </unittitle><unitdate normal="1942/1987">1942-1987</unitdate></did><scopecontent>[...]</scopecontent><c level="file"><did><container id="mss1993-043.1.1" type="box">1</container><container parent="mss1993-043.1.1" type="folder">1</container><unittitle><unitdate normal="1942/1943">1942-1943</unitdate></unittitle></did><</c><c level="file"><did><container parent="mss1993-043.1.1" type="folder">2</container><unittitle><unitdate normal="194401/194408">January-August 1944</unitdate></unittitle></did><</c><c level="file"><did><container parent="mss1993-043.1.1" type="folder">3</container><unittitle><unitdate normal="194409/194503">August 1944-March 1945</unitdate></unittitle></did><</c> ... </c> ... </dsc></td></tr><tr><td>Example</td><td><c01 xmlns="urn:isl:1-931666-22-9" level="series"><did>[...]</did><c02 level="file"><did><container type="box">3</container></did></c01></td></tr></table>
<container type="folder">18</container>
<unititle>Parent-Teacher Association of Fondsville</unititle>

<unitdate type="inclusive"
normal="1959/1972">1959-1972</unitdate>

<c02 level="file"/>
<did>

<container type="box">3</container>

<container type="folder">19</container>

<unittitle>Pasta and Politics Club</unittitle>

<unitdate type="inclusive"
normal="1967/1975">1967-1975</unitdate>

<c02> ... </c01>

## Content model

<content>

</content>

## Schema Declaration

element container
{
  att.EADGlobal_attributes,
  att.typed_attributes,
  att.labeled_attributes,
  attribute parent { xsd:IDREFS }?,
  ( text | model.phrase.bare )*
}

## <controlaccess>

<controlaccess> (Controlled Access Headings) A wrapper element that designates key access points for the described materials and enables authority-controlled searching across finding aids on a computer network. Hundreds of names and subjects can appear in a finding aid. Prominence can be given to the major ones by bundling them together in a single place within the <archdesc> or within a large Component <c> and tagging them with <controlaccess>.

Module EAD

Attributes att.EADGlobal (@id, @altrender, @audience, @encodinganalog)

Member of model desc base

Contained by EAD: archdesc archdescgrp c c01 c02 c03 c04 c05 c06 c07 c08 c09 c10 c11 c12 controlaccess descgrp

May contain EAD: address blockquote chronlist controlaccess corpname famname function genreform geogname head list name note occupation p persname subject subtitle table title

Note

The <controlaccess> element designates terms comparable to those found in the 1xx, 6xx, and 7xx fields of MARC catalog records. Finding aid searches limited to the <controlaccess> element and its subelements will improve the likelihood of locating strong sources of information on a desired subject, because access terms will have been entered in a consistent form across finding aids, and also because only the most significant terms are likely to have been selected for encoding. Although names and terms from locally controlled vocabularies are permissible, the <controlaccess> subelements (<corpname>,
<famname>, <function>, <genreform>, <geogname>, <occupation>, <persname>, <subject>, and <title>) should come from national or international vocabularies whenever they are available to enable searches in information systems that include multiple finding aids, or finding aids and bibliographic records from many institutions.

These subelements have SOURCE attributes to specify the vocabulary tool from which the heading is taken and RULES attributes to specify the descriptive rules by which it has been formulated. The attribute AUTHFILENUMBER can be used to identify an authority file record that provides additional information about a heading and includes cross references. The ROLE attribute can be used to specify such factors as whether a heading is for the creator of the materials, the subject of the materials, or both.

### Example

<archdesc xmlns="urn:isbn:1-931666-22-9" level="collection">
  <did>[...]</did>
</scopecontent></scopecontent>

### Schematron
<table><tr><td>Schematron</td><td>In &lt;controlaccess&gt;, EHRI welcomes any access points types : &lt;subject&gt;, &lt;geogname&gt;, &lt;persname&gt;, &lt;orgname&gt;.<br/>&lt;s:rule context="ead:controlaccess"&gt;<br/>&lt;s:assert role="COULD" test="ead:geogname"&gt;controlaccess COULD have one or more geogname elements&lt;/s:assert&gt; &lt;/s:rule&gt;<br/>In &lt;controlaccess&gt;, EHRI welcomes any access points types : &lt;subject&gt;, &lt;geogname&gt;, &lt;persname&gt;, &lt;orgname&gt;.<br/>&lt;s:rule context="ead:controlaccess"&gt;<br/>&lt;s:assert role="COULD" test="ead:persname"&gt;controlaccess COULD have one or more persname elements&lt;/s:assert&gt; &lt;/s:rule&gt;<br/>In &lt;controlaccess&gt;, EHRI welcomes any access points types : &lt;subject&gt;, &lt;geogname&gt;, &lt;persname&gt;, &lt;orgname&gt;.<br/>&lt;s:rule context="ead:controlaccess"&gt;<br/>&lt;s:assert role="COULD" test="ead:orgname"&gt;controlaccess COULD have one or more orgname elements&lt;/s:assert&gt; &lt;/s:rule&gt;<br/>Access points COULD be chosen in authority lists. The list is declared with a source attribute. The related id of this authority should be declared in an authfilenumber attribute. Note that EHRI provides URLs for vocabularies and authorities. Check the EHRI website for more information<br/>&lt;s:rule context="ead:controlaccess"&gt; &lt;s:assert role="COULD" test="&lt;@authfilenumber and @source&gt;&gt;Access points COULD be chosen in an authority list. This list should be declared in a @source attribute. The related id of this authority should be declared in an @authfilenumber attribute. &lt;/s:assert&gt; &lt;/s:rule&gt;</td></tr></table>

<table><tr><td>Content model</td><td>&lt;content/&gt;</td></tr></table>

<table><tr><td>Schema Declaration</td><td>element controlaccess<br/>{<br/>att.EADGlobal_attributes,<br/>head?,<br/>( model_blocks | model.access.title | controlaccess )+<br/>}</td></tr></table>

## &lt;corpname&gt;

### &lt;corpname&gt; (Corporate Name)
The proper noun name that identifies an organization or group of people that acts as an entity. Examples include names of associations, institutions, business firms, nonprofit enterprises, governments, government agencies, projects, programs, religious bodies, churches, conferences, athletic contests, exhibitions, expeditions, fairs, and ships.

**Module** EAD

**Attributes** att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att.access (@source, @rules, @authfilenumber, @normal) att.roled (@role)

**Member of** model.access

**Contained by** EAD: bibref controlaccess entry event extrefloc indexentry item label namegrp origination p physdesc physfacet ref refloc repository unittitle

**May contain** EAD: emph extptr lb ptr subarea

**Note** All names in a finding aid do not have to be tagged. One option is to tag those names for which access other than basic, undifferentiated keyword retrieval is desired. Use of controlled vocabulary forms is recommended to facilitate access to names within and across finding aid systems. The &lt;corpname&gt;
element may be used in text elements such as <p>. To indicate a corporate entity with major representation in the described materials, nest <corpname> within the <controlaccess> element. When a <corpname> is also the name of the institution providing intellectual access to the described material, nest <corpname> within the <repository> element. The <subarea> element may be used to show a secondary or subsidiary level within the <corpname>. When a <corpname> is also the name of the creator or compiler of the described material, nest <corpname> within the <origination> element.

The ROLE attribute can be used to specify other relationship(s) of the name to the described materials, for example, "compiler," "creator," "collector," or "subject." The ENCODINGANALOG attribute can be used to specify corresponding data categories in another coding system such as MARC. The NORMAL attribute can be used to provide the authority form of a name that has been encoded with <corpname> in narrative text, e.g., within a paragraph. Use the SOURCE attribute to specify the vocabulary from which the name has been taken, and/or the RULES attribute to specify the descriptive rules followed when forming the name. The attribute AUTHFILENUMBER can be used to identify a link to an authority file record that has more information about the name or cross references for alternative forms of the name and related names.

The <corpname> element is comparable to MARC fields 110, 111, 610, 611, 710, and 711.

See also the related elements <controlaccess>, <persname>, <famname>, <name>, and <subarea>.

**Example**
```xml
<archdesc xmlns="urn:isl:1-931666-22-9" level="collection">
  <did>
    <head>Collection Summary</head>
    <origination label="Creator">
      <corpname encodinganalog="110"
        source="lcnaf">National Association for the Advancement of Colored People</corpname>
    </origination> ... </did> ... </archdesc>
```

**Example**
```xml
<controlaccess xmlns="urn:isl:1-931666-22-9">
  <head>Index Terms</head>
  <p>These records are indexed under the following headings in the catalog of the Minnesota Historical Society. Researchers wishing to find related materials should search the catalog under these index terms.</p>
  <controlaccess>
    <head>Organizations:</head>
    <corpname encodinganalog="610"
      source="lcnaf">Board of Game and Fish Commissioners of Minnesota.</corpname>
  </controlaccess> ... </controlaccess>
```

**Content model**
```xml
<content>
</content>
```

**Schema Declaration**
```xml
<schema>
  <declaration>
    <element corpname>
      <att.EADGlobal_attributes,
```
att.access_attributes,
att.roled_attributes,
(text | model.phrase.bare | subarea)*
}

## <creation>

**<creation>** (Creation) A subelement of the <profiledesc> portion of <adheader> used for information about the encoding of the finding aid, including the person(s) or agency(ies) responsible for the encoding, the date, and the circumstances under which the encoding was done.

**Module** EAD

**Attributes** att.EADGlobal (@id, @altrender, @audience, @encodinganalog)

**Contained by** EAD: profiledesc

**May contain** EAD: abbr archref bibref date emph expan extptr extref lb linkgrp ptr ref subtitle title

**Note** This element is modeled on a Text Encoding Initiative (TEI) DTD header element.

**Example**

```xml
<adheader xmlns="urn:isl:1-931666-22-9" langencoding="iso639-2b">
  <profiledesc>
    <creation>Machine-readable finding aid and skeletal markup derived via a macro from WordPerfect file; markup checked and completed by Sarah Taylor. <date normal="19950423">April 23, 1995.</date>
    </creation>
  </profiledesc>
</adheader>
```

### Content model

`<content>`

`</content>`

### Schema Declaration

**Declaration**

```json
{
  element creation
  {
    att.EADGlobal_attributes,
    (text | model.phrase basic | date)*
  }
}
```

## <custodhist>

**<custodhist>** (Custodial History) Information about the chain of ownership of the materials being described, before they reached the immediate source of acquisition. Both physical possession and intellectual ownership can be described, providing details of changes of ownership and/or custody that may be significant in terms of authority, integrity, and interpretation.

**Module** EAD

**Attributes** att.EADGlobal (@id, @altrender, @audience, @encodinganalog)

**Member of** model desc base

**Contained by** EAD: archdesc archdescgrp c c01 c02 c03 c04 c05 c06 c07 c08 c09 c10 c11 c12 custodhist descgrp

**May contain** EAD: acqinfo address blockquote chronlist custodhist head list note p table
**Note** Although the history of custody is sometimes synonymous with provenance, a description of archival provenance may be more appropriate for the `<origination>`, `<bioghist>`, or `<scopecontent>` elements. Use Acquisition Information `<acqinfo>` for text about the immediate source of the described materials and the circumstances under which they were received by the
repository.

In EAD Version 1.0 <custodhist> was a subelement of Administrative Information <admininfo>, which has been deprecated in EAD 2002 (see Appendix B). The new Description Group <descgrp> element, which can group any of the <did>-level elements (except the Description of Subordinate Components <dsc>), may be used to wrap elements where a group heading is desirable. The <descgrp> element can be used to replace <admininfo> where it has been used as a wrapper when converting finding aids encoded in EAD V1.0 to EAD 2002.

The <custodhist> element is comparable to ISAD(G) data element 3.2.3 and MARC field 561.

**Example**

<custodhist xmlns="urn:isl:1-931666-22-9">

<p>The George Franklin Papers were maintained by the staff of the Mayor's Office, City of Irvine, California, in the records storage facility at City Hall from the time of Franklin's death in 1972 until they were transferred, at his family's request, to Special Collections and Archives, The UC Irvine Libraries, in 1988.</p>

**Content model**

<content>

</content>

**Schema Declaration**

element custodhist

{ att.EADGlobal_attributes, head?, (model_blocks | custodhist | acqinfo)+ }

**<dao>**

<dao> (Digital Archival Object) A linking element that uses the attributes ENTITYREF or HREF to connect the finding aid information to electronic representations of the described materials. The <dao> and <daogrp> elements allow the content of an archival collection or record group to be incorporated in the finding aid. These digital representations include graphic images, audio or video clips, images of text pages, and electronic transcriptions of text. The objects can be selected examples, or digital surrogates all the materials in an archival fonds or series.

**Module** EAD

**Attributes** att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att.xlink (@label, @href, @type, @title, @from, @to, @role, @actuate, @show, @arcrole, @xpointer, @entityref, @target, @parent)

**Member of** model desc full model did

**Contained by** EAD: archdesc archdescgrp archref bioghist c c01 c02 c03 c04 c05 c06 c07 c08 c09 c10 c11 c12 did odd scopecontent

**May contain** EAD: daodesc

**Note** Use the Extended Pointer <extptr/> element to link the finding aid to electronic objects that are not part of the described materials. Use the ACTUATE attribute to designate whether the object is displayed automatically ("onload") or only if the user requests it ("onrequest"). Use the SHOW attribute to define whether a remote resource appears at the point of the link, in a new window, or replaces
the link.

See also related elements `<daodesc>`, `<daogrp>`, and `<daoloc>`.

While XML Linking Language (XLink) Version 1.0, which is the basis for EAD linking elements, is a stable document, examples of EAD usage are hypothetical and have not been tested in real XLink-based applications. Those wishing to use XLink are encouraged to consult the specification available online at http://www.w3.org/TR/xlink.

<table><tr><td>Example</td><td><c02 xmlns="urn:isl:1-931666-22-9" level="file"><br/><did><br/><unittitle>Photographs</unittitle><br/><unitdate type="inclusive" normal="1895/1928">1895-1928</unitdate><br/></did><br/><c03 level="item"><br/><did><br/><unittitle>John Smith graduation portrait</unittitle><br/><unitdate type="single" normal="18950528">May 28, 1895</unitdate><br/><dao linktype="simple" href="http://imgs.ud.edu/archives/image/f12001_1.jpg" actuate="onrequest" s how="new"/><br/></did><br/><c03><br/><c03 level="item"><br/><did><br/><unittitle>Photographs of John Smith and family members</unittitle><br/><unitdate type="inclusive" normal="1907-1928">1907-1928</unitdate><br/><physdesc><br/><extent>12 photographic prints</extent><br/></physdesc><br/></did><br/><c03><br/><c02></c02></td></tr><tr><td>Content model</td><td><content><br/></content></td></tr><tr><td>Schema Declaration</td><td>element dao { att.EADGlobal_attributes, att.xlink_attributes, daodesc? }</td></tr></table>

<table><tr><td>Schema Declaration</td><td>element dao { att.EADGlobal_attributes, att.xlink_attributes, daodesc? }</td></tr></table>

## <daodesc>

`<daodesc>` (Digital Archival Object Description) Information about the contents, usage, or source of a Digital Archival Object `<dao>` or Digital Archival Object Group `<daogrp>`. When the `<unittitle>` or other descriptive information in a Component `<c>` is sufficient to identify one or more digital objects, the `<daodesc>` caption is not necessary.

**Module** EAD

**Attributes** `att.EADGlobal` (`@id`, `@altrender`, `@audience`, `@encodinganalog`)
**Contained by** EAD: dao daogrp daoloc
**May contain** EAD: address blockquote chronlist head list note p table
**Note** See also related elements <dao>, <daogrp>, and <daoloc>.

**Example**
```xml
<c02 xmlns="urn:isbn:1-931666-22-9" level="file">
    <did>
        <unittitle>Photographs of John Smith and family members</unittitle>
        <unitdate type="inclusive" normal="1895/1928">1895-1928</unitdate>
        <daogrp linktype="extended">
            <daodesc>
                <p>Sample digitized image from this file: John Smith graduation portrait, <date normal="18950528">28 May 1895</date>.</p>
            </daodesc>
            <resource linktype="resource" label="start"/>
            <daoloc entityref="f0042_1 thumb" linktype="locator" label=" thumb"/>
            <daoloc entityref="f0042_1 ref" linktype="locator" label="reference"/>
            <arc linktype="arc" show="embed" actuate="onload" from="start" to="thumb"/>
            <arc linktype="arc" show="new" actuate="onrequest" from="thumb" to="reference"/>
        </daogrp>
    </did>
</c02>
```

**Content model**

```xml
<content>
</content>
```

**Schema Declaration**

element daodesc { att.EADGlobal_attributes, head?, model_blocks+ }

**<daogrp>**

<daogrp> (Digital Archival Object Group) A wrapper element that contains two or more related Digital Archival Object Locations <daoloc> that should be thought of as a group and may share a single common Digital Archival Object Description <daodesc>. They may also form an extended link group to enable a set of multidirectional links. The <dao>, <daogrp>, and <daoloc> elements allow the content of the described materials to be incorporated in the finding aid.

**Module** EAD

**Attributes**
att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att.xlink (@label, @href, @type, @title, @from, @to, @role, @actuate, @show, @arcrole, @xpointer, @entityref, @target, @parent)

**Member of** model desc full model did

**Contained by** EAD: archdesc archdescgrp archref bioghist c01 c02 c03 c04 c05 c06 c07 c08 c09 c10 c11 c12 did odd scopecontent

**May contain** EAD: arc daodesc daoloc extptrloc extrefloc ptrloc refloc resource

**Note** See also related elements <dao>, <daodesc>, <daoloc> and <linkgrp>. While XML Linking Language (XLink) Version 1.0, which is the basis for EAD linking
elements, is a stable document, examples of EAD usage are hypothetical and
have not been tested in real XLink-based applications. Those wishing to use
XLink are encouraged to consult the specification available online at
http://www.w3.org/TR/xlink.

<table><tr><td>Example</td><td><c02 xmlns="urn:isl:1-931666-22-9" level="file"><br/><did><br/><unititle>Photographs of John Smith and family<br/>members</unititle><br/><unitdate type="inclusive"<br/>normal="1895/1928">1895-1928</unitdate><br/><daogrp linktype="extended"><br/><daodesc><br/><p>Sample digitized image from this file: John Smith<br/>graduation portrait, <date normal="18950528">28<br/>May 1895</date>.</p></daodesc><br/><resource linktype="resource"<br/>label="start"/><br/><daoloc entityref="f0042_1tmb"<br/>linktype="locator" label="thumb"/><br/><daoloc entityref="f0042_1ref"<br/>linktype="locator" label="reference"/><br/><arc linktype="arc" show="embed"<br/>actuate="onload" from="start" to="thumb"/><br/><arc linktype="arc" show="new"<br/>actuate="onrequest" from="thumb" to="reference"/><br/><daogrp><br/></did></c02></td></tr></table>

<table><tr><td>Content model</td><td><content><br/></content></td></tr></table>

<table><tr><td>Schema Declaration</td><td>element daogrp<br/><br/><pre>{<br/>att.EADGlobal_attributes,<br/>att.xlink_attributes,<br/>daodesc?,<br/>( daoloc | model.extended.els )+<br/></pre></td></tr></table>

`<daoloc>`

`<daoloc>` (Digital Archival Object Location) The location of a Digital Archival Object `<dao>` that is a resource in an extended link. Within a Digital Archival Object Group `<daogrp>`, a `<daoloc>` element is used instead of a `<dao>` element to indicate that an extended, possibly multidirectional link is being tagged. See also related elements `<dao>`, `<daogrp>`, and `<daodesc>`.

<table><tr><td>Module</td><td>EAD</td></tr><tr><td>Attributes</td><td>att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att.xlink (@label, @href, @type, @title, @from, @to, @role, @actuate, @show, @arcrole, @xpointer, @entityref, @target, @parent)</td></tr></table>
**Contained by** EAD: daogrp
**May contain** EAD: daodesc
**Note** While XML Linking Language (XLink) Version 1.0, which is the basis for EAD linking elements, is a stable document, examples of EAD usage are hypothetical and have not been tested in real XLink-based applications. Those wishing to use XLink are encouraged to consult the specification available online at http://www.w3.org/TR/xlink.

**Example**
```xml
<c02 xmlns="urn:isl:1-931666-22-9" level="file">
  <did>
    <unititle>Photographs of John Smith and family members</unititle>
    <unitdate type="inclusive" normal="1895/1928">1895-1928</unitdate>
    <daogrp linktype="extended">
      <daodesc>
        <p>Sample digitized image from this file: John Smith graduation portrait, <date normal="18950528">28 May 1895</date>.</p>
      </daodesc>
      <resource linktype="resource" label="start"/>
      <daoloc entityref="f0042_1tmb" linktype="locator" label=" thumb"/>
      <daoloc entityref="f0042_1ref" linktype="locator" label="reference"/>
      <arc linktype="arc" show="embed" actuate="onload" from="start" to=" thumb"/>
      <arc linktype="arc" show="new" actuate="onrequest" from=" thumb" to="reference"/>
    </daogrp>
  </did>
</c02>
```

**Content model**
```xml
<content>
</content>
```

**Schema Declaration**
```
element daoloc { att.EADGlobal_attributes, att.xlink_attributes, daodesc? }
```

## <date>

### <date>
(Date) A generic element that contains a month, day, or year in any format. Use <date> to identify any dates that merit encoding, except for the creation and other relevant dates of the described materials, which are instead tagged with the <unitdate> element. Examples of dates that might merit encoding are a person's birth date, the date the materials were acquired, or the date of an event in a chronology. These dates may be entered in the form of text or numbers, and may consist of a single date or range of dates.

**Module** EAD
**Attributes**
att.EADGlobal (@id, @altrender, @audience, @encodinganalog) att.typed (@type) att[normalized (@normal) att calendar (@calendar) att.era (@era) att.certainty (@certainty)

**Member of** model.data
**Contained by**
EAD: change chronitem creation entry event extrefloc imprint item label
legalstatus p physdesc physfacet publicationstmt ref refloc subtitle title titlepage
titleproper untitletext

**May contain**
EAD: emph extptr lb ptr
**Note**
A standard numeric form of the date (YYYYMMDD, etc.) can be specified with
the NORMAL attribute to facilitate machine comparison of dates for searching,
for example, 19480101/19980401 (YYYYMMDD/YYYYMMDD), or 1948/1998
(YYYY/YYYY). The TYPE attribute can be used to supply a more specific
designation, for example, "life," "flourish," "depiction," "publication," or
"acquisition." The CERTAINTY attribute may be used to indicate the degree of
precision in the dating, for example, "circa," "approximately," or "after." The
CALENDAR attribute, which has a default value of "gregorian," specifies the
calendar from which the date stems. The value "ce" (common or Christian era)
is the default for the ERA attribute.

**Example**
```xml
<bibref xmlns="urn:isl:1-931666-22-9">
  <persname role="author">Kinder, Dolores.</persname>
  <title render="italic">Once Upon a Lullaby.</title>
  <imprint>
    <geogname>New York: </geogname>
    <publisher>Wells &amp; Sons, </publisher>
    <date type="publication">1931</date>
  </imprint>
</bibref>
```

**Example**
```xml
<acqinfo xmlns="urn:isl:1-931666-22-9">
  <p>This collection, number <num type="donor">1988-015,</num> was
donated by Mrs. Dolores Franklin on <date type="acquisition"
normal="19880423">April 23, 1988.</date>
</p>
</acqinfo>
```

**Schematron**
All the <date> elements MUST have a normal attribute whose pattern respects
the ISO8601 standard and take the following form: YYYY-MM-DD
<s:rule context="ead:-date"> <s:assert role="MUST" test="matches(@normal,
'^([^0-9][1-9][0-9][1-9][0-9]{2})([1-9][0-9]{3}))-([0-1-9][1-012])-([0-1-9][12][0-9]
3[01])')">@normal attribute MUST respect ISO8601 pattern = YYYY-MM-
DD</s:assert> </s:rule>

**Content model**
<content/>

**Schema Declaration**
```xml
<schema declaration>
  <element name="date" type="iri">
    <attribute name="EADGlobal attributes" value=""/>
    <attribute name="typed attributes" value=""/>
    <attribute name="normalized attributes" value=""/>
    <attribute name="calendar attributes" value=""/>
    <attribute name="era attributes" value=""/>
    <attribute name="certainty attributes" value=""/>
    <text>(text | model.phrase.bare)\*</text>
  </element>
</schema>
```