The latest version of the EAC-CPF schema and tag library was adopted in 2010 and updated in late 2018. This version is called EAC-CPF 2010 edition 2018.
A process for a major revision started in 2017, following the 2015 merger of the Technical Subcommittees on EAD and EAC-CPF and the Schema Development Team into the Technical Subcommittee on Encoded Archival Standards (TS-EAS). This major revision aims to modernize the schema in terms of:
- simplifying where possible,
- aligning with EAD where useful,
- implementing features and solutions upon users’ request,
- clearing up unused components.
The revised version, draft EAC-CPF 2.0, is the result of a major overhaul of EAC-CPF 2010 edition 2018 and incorporates new features to harmonize and reconcile the standard with EAD. Below is a summary of key changes reflected in EAC-CPF 2.0.
Following ISAAR(CPF), the established structure of the control area, identity area, description area, and relations is still available, as is the idea of encoding multiple identities in one EAC-CPF instance.
The ICA Expert Group on Archival Description (ICA EGAD) is working on a 2nd draft of Records in Contexts (RiC), which is being designed as the next comprehensive description standard for archives. EAC-CPF 2.0 includes the ideas of RiC where feasible, to achieve greater interoperability.
The question of spelling was widely discussed since the related standard, EAD, uses lower-case for element and attribute names. For easier reading and teaching it was agreed to keep the camel case spelling for element and attribute names and also for fixed values.
To support and facilitate EAC-CPF schema usage a few general principles have been defined.
Elements are ordered within their parent elements as follows:
- required, not repeatable elements
- required, repeatable elements
- optional, not repeatable elements
- optional repeatable elements
The current EAC-CPF schema has two concepts to bundle elements:
- Plural elements
Plural elements serve as wrapper elements for one or more singular elements of the same kind. Examples include
Plural elements can occur once, all are optional and not repeatable, and they must contain at least one singular element, but can include unlimited additional singular elements, plus a descriptive note. A new singular element within its plural wrapper is needed for a new entry. Translations can be given in a repeated term of the singular element.
Even a single singular element needs to be wrapped by a plural element.
- Element sets
Element sets bundle elements with different concepts/information. Examples include
Following elements were removed without substitution:
<level>, cf. list encoding
Next to specified EAC-CPF attributes, all elements can contain any additional attributes from any other namespace.
There are three global attributes for all elements:
- @id to refer to the element,
- @target to point to another element within the EAC-CPF instance (not available in
- @audience to control the visibility of an element.
The attribute @status is introduced to elements for identifiers, codes, names, and dates to add status information on their validity.
Relaxed data type and elements definition
Restrictions on element content and attribute values were relaxed for the following cases:
<recordId>relaxed from NMTOKEN to text (must have at least one non-whitespace character)
<agencyCode>relaxed the constraint ISO 15511 to text
- @countryCode, @languageCode, @scriptCode relaxed the constraint ISO standards (ISO 3166-1, ISO 639-2, ISO 15924) to NMTOKEN
- @localType data type relaxed from anyURI to token
- @vocabularySource data type relaxed from NMTOKEN to token
Renamed elements to be more distinct
Some of the elements were renamed to be more precise or to align with EAD:
Schema alignment with EAD
TS-EAS is responsible for maintaining two archival encoding standards: EAD and EAC-CPF. The user communities of both standards overlap; therefore, the alignment of both schemas, where possible, shall ease the standards’ maintenance, usage, teaching, and learning.
To harmonize the control area of both standards, EAC-CPF contains the following changes:
- The element
<control>contains new optional attributes for external encoding standards: @countryEncoding, @dateEncoding, @languageEncoding, @repositoryEncoding, and @scriptEncoding.
- The element
<representation>is introduced as an optional child element of
- The element
<geographicCoordinates>is introduced as an optional child element of
<place>, cf. place encoding
- The element
<chronItemSet>is introduced as an optional child element of
<chronItem>to bind several events and places to a date.
Changes to attributes resulting from the realignment, with some attributes borrowed from EAD and introduced in EAC-CPF 2.0, include:
- Removed XML namespace:
a. @xml:id becomes optional attribute @id that is available for all elements
b. @xml:lang becomes optional attribute @languageOfElement and is available for non-empty elements, i.e., the element can contain text directly or via its child elements
c. @xml:base becomes optional attribute @base
- Removed XLink namespace
a. @xlink:actuate, @xlink:arcrole, and @xlink:show were removed
b. @xlink:linkrole, @xlink:linktitle, and @xlink:href become optional attributes under the new names @linkRole, @linkTitle, and @href, respectively
- Newly added attributes borrowed from EAD
a. @audience as a global optional attribute for all elements with the values: external, internal
b. @calendar, @certainty, and @era as optional attributes for date elements, cf. date encoding
c. @coordinateSystem as a required attribute in
<geographicCoordinates>to enter the code for a system used to express geographic coordinates, cf. place encoding
d. @listType as an optional attribute in
<list>to specify the type of a list with the values: ordered, unordered
e. @unit as an optional attribute in the new element
<citedRange>, cf. assertion description
f. @value as a required attribute in
<entityType>with the values: corporateBody, person, family, cf. identity area
With the goal of simplifying the schema and aligning it with EAD, some encoding concepts were modified.
Linking and referencing
The EAC-CPF schema will now provide possibilities to link internally to any other element within the same EAC-CPF instance and externally to any other online resource.
Internal linking between the EAC-CPF elements can be realized with the global optional attribute @id to tag an element uniquely. The global optional attribute @target can then be used to point to any element with an attribute @id. Furthermore, there are four attributes to link directly to declarations of rules and conventions, local type definitions, maintenance events, and sources. These specific reference attributes (@conventionDeclarationReference, @localTypeDeclarationReference, @maintenanceEventReference, and @sourceReference) are optionally available in all elements in the identity area, except in
<entityType>, in the description area, and in the relations. All attributes for internal linking are defined with data type IDREFS to provide multiple link targets, if necessary.
To support interoperability with linked data next to the existing attribute @vocabularySource, two new linking attributes, @vocabularyURI and @vocabularySourceURI, were added. They serve as optional attributes in all elements that can contain any type of entity (e.g., the attributes are available in elements encoding identifiers like
<identityId>). They are also available in the elements
<targetRole> where links to vocabularies, thesauri, or authority files might be useful.
When creating links to external generic resources (like any website, preferably with a persistent URI) the element
<reference> with the optional attribute @href should be used. The element
<reference @href> is available in a wide range of EAC-CPF elements as a child element of
<p>. If there is not a
<p> available, the element
<reference> is added. The optional attributes @linkRole, @linkTitle, and @lastDateTimeVerified accompany @href.
To clarify, if a link to a Wikipedia page is provided, use the element
<reference @href>, but if a reference to a Wikidata ID shall be given, use @vocabularyURI.
Generally, EAC-CPF does not provide any formatting possibilities. However, as EAC-CPF is an encoding standard for archival descriptions (which may comprise narrative text), some formatting options are needed to assist readers with easily ascertaining the text.
<span>, as a child element of some text elements (
<p>) with the optional attribute @style, is used to format words or phrases for linguistic effect. Values of the attribute @style should conform to W3C CSS.
Lists can be formatted as an ordered or an unordered list, specified in the optional attribute @listType, with the attribute @style and a W3C CSS value.
<list>, elements designed to include descriptive text such as
<structureOrGenealogy> can contain the new element
<head> to encode a title or caption for a section of text.
Date encoding is possible for single dates (
<date>), for time spans (
<dateRange> with child elements
<toDate>), and for complex dates (
<dateSet> with child elements
All text date elements (
<toDate>) can contain the optional attributes @calendar and @era to specify the date being encoded.
<toDate> may also include the optional attribute @status to indicate unknown or open dates, using the values unknown or ongoing. The optional attribute @certainty can be used to indicate the level of confidence for the information given in
<toDate> (e.g., approximate or circa).
Additionally, the usage of Extended Date/Time Format (EDTF) integrated in ISO 8601‐2019, to qualify a date as uncertain (?), approximate (~), or uncertain and approximate (%), is possible via the optional attribute @standardDate.
Language information can be given in several places of an EAC-CPF instance depending on the context and the object of the attributed language.
First, the encoding standard for the representation of a language name and script needs to be specified in
<control> using the optional attributes @languageEncoding and @scriptEncoding (e.g., iso639-1 or iso15924). All language and script codes specified in one EAC-CPF instance should follow the same standard.
Language used in the EAC-CPF instance
Second, the language and script codes themselves might be entered in the attributes @languageCode and @scriptCode, following the once declared encoding standard.\ The attribute @languageCode is required to be used within the element
<languageDeclaration> as a child element of
<control>; whereas, @scriptCode is an optional attribute of this element.
<languageDeclaration> declares the language and script in which an EAC-CPF instance is written and it cannot contain any text, but can have a descriptive note.
The language and the writing system of the content of each single text element can be specified by using the optional attributes @languageOfElement and @scriptOfElement. Both elements contain the language and script codes, following the once declared encoding standard. To achieve greater distinction, the attributes @xml:lang and @scriptCode were renamed.
This new approach enables users to create multilingual EAC-CPF descriptions. Languages and scripts for elements’ content might be specified in an element or in the parent or wrapper element to summarize language and script information for an encoding section. Most text elements in the description area are repeatable for translation.
While it is possible to specify the language and the writing system for each single element, it might be more feasible to encode the primary language in the EAC-CPF instance in
<languageDeclaration>. Use the single element language attribute @languageOfElement only in cases where the content language differs from the primary language.
Language used in the creative work of an CPF entity
Third, the attribute @languageCode is also available as an optional attribute in the element
<language>, a child element of
<languageUsed>. The element
<language> identifies a particular language used in the creative work of the CPF entity being described and can contain the name of the language itself, next to the attribute @languageCode using the code for said language.
In the same sense, the optional attribute @scriptCode is available in the element
<writingSystem>, also a child element of
<languageUsed>. The element
<writingSystem> identifies the writing script for a language in which the CPF entity being described was creative or productive. The element
<writingSystem> can contain the name of the script, whereas the attribute @scriptCode uses the code for said script.
Declaring a script or writing system is useful if it is not obvious for the specified language, e.g., Turkish was written in Arabic script until 1929 when it changed to Latin script. Another use case for declaring a writing system is the expression of names and terms of a language in a different script, e.g., a German name in Cyrillic script. If a language used is written in only one script, the specification is not necessary.
The attribute @transliteration was removed from EAC-CPF.
In order to specify the system, conventions, or rules applied to transliteration, the element
<control> should be used. The optional attribute @conventionDeclarationReference can be used to refer to the according convention declaration for the transliteration scheme.
The control area is mainly updated for EAD alignment and to simplify the schema.
Upon evaluation of the elements and attributes, some elements were removed and superseded by attributes in their parent elements.
Elements to encode status information on an EAC-CPF instance:
<maintenanceStatus>becomes the mandatory attribute @maintenanceStatus in
<control>with the values: revised, deleted, new, deletedSplit, deletedMerged, deletedReplaced, cancelled, derived
<publicationStatus>becomes the optional attribute @publicationStatus in
<control>with the values: approved, inProcess, published
<control maintenanceStatus="new" publicationStatus="inProcess">
Elements with type information:
<eventType>becomes the mandatory attribute @maintenanceEventType in
<maintenanceEvent>with the values: cancelled, created, deleted, derived, revised, unknown, updated
<agentType>becomes the mandatory attribute @agentType in
<agent>with the values: human, machine, unknown
<maintenanceEvent maintenanceEventType="created"> <agent agentType="human">agent name</agent> <eventDateTime standardDateTime="2020-07-01T13:01:48">01.07.2020</eventDateTime> </maintenanceEvent>
The convention declaration in control will be used to provide rules for transliteration and rules for authorized, alternative, and preferred forms of names, cf. name encoding and language encoding. A new optional attribute @conventionDeclarationReference in the elements of the identity area, the description area, and the relations allows for linking to a specific convention declaration (i.e., to
<conventionDeclaration @id> in the current EAC-CPF instance).
Information given in the elements
<maintenanceEvent> lay the foundation to the description of an assertion to the EAC-CPF description, cf. assertion description. The new optional attributes @sourceReference and @maintenanceEventRefercence in the elements of the description area allow for linking to a specific source and maintenance event (i.e., to
<source @id> or
<maintenanceEvent @id> in the current EAC-CPF instance).
The optional attribute @localType is used to support an element semantically. The specification of values available in @localType is given in the
<localTypeDeclaration>. The new optional attribute @localTypeDeclarationReference accompanies each attribute @localType and allows for linking to a specific local type declaration (i.e., to
<localTypeDeclaration @id> in the current EAC-CPF instance).
The identity area has changed slightly.
It is now possible to encode additional entity types complementary to the given options person, family, and corporate body. Next to the mandatory element
<entityType> (designed as an empty element with the mandatory attribute @value, values: person, family, corporateBody) a new optional element (
<otherEntityTypes>) provides the option to enter one or more entity types as text information or as reference to a vocabulary.
<identity> <entityType value="family"/> <otherEntityTypes> <otherEntityType> <term>Group</term> <descriptiveNote> <p>Family is a kind of Group.</p> </descriptiveNote> </otherEntityType> <otherEntityType> <term>Dynasty</term> </otherEntityType> </otherEntityTypes> </identity>
<entityId> was renamed to
<identityId> to be more precise.
The wrapper element
<nameEntryParallel> was renamed to
<nameEntrySet>, cf. name encoding.
Encoding various forms of names is essential for EAC-CPF producers. There are different reasons that make it necessary to encode several names for one entity.
Rename the grouping element
The grouping element for names is renamed from
<nameEntrySet>. A name entry set can contain one or more name entries and dates. It can record parallel names that have equal statuses of being authorized and it can also encode multiple name forms, including translations of a name or an abbreviation.
Status of a name
The quality of a name, authorized or alternative form, can be given with the new optional attribute @status (values: authorized, alternative) in each element
Rules or conventions to express the name can be defined in
<conventionDeclaration> in the control area; the same applies to any rule or convention according to which the name is the authorized or alternative form. The optional attribute @conventionDeclarationReference in
<nameEntry> points directly to the according convention declaration (i.e., to
The optional attribute @preferredForm (values: true, false) specifies whether or not a name entry provides the preferred form of a name for display. A convention declaration can be used to define the rules or conventions according to which a name is deemed as preferred to others.
Translations and parallel names
The optional attribute @localType (value: parallel) in
<nameEntryParallel> should be used to reflect the usage of parallel names.
The same optional attribute @localType in
<nameEntry> should be used to indicate what kind of parallel name is used (e.g., translation).
The attended optional attribute @localTypeDeclarationReference points directly to the according local type declaration (i.e., to
<nameEntrySet localType="parallel"> <nameEntry languageOfElement="fr" preferredForm="true" status="authorized" conventionDeclarationReference="#cd1"> <part>Institut international des droits de l'homme</part> </nameEntry> <nameEntry languageOfElement="en" preferredForm="false" status="authorized"> <part>International institute of human rights</part> </nameEntry> <nameEntry languageOfElement="es" preferredForm="false" status="authorized" conventionDeclarationReference="#cd1"> <part>Instituto internacional de derechos humanos</part> </nameEntry> </nameEntrySet>
The EAC-CPF user community has long desired the ability to add evidence-based assertions. With EAC-CPF 2.0, it is possible to enter new information with a range of existing elements in the control area. Additionally, all information in the description area is repeatable in order to add assertions there as well, as desired.
To provide additional, differing, or new information, the according element in the description area must be repeated with the new information entry.
The source supporting the information can be given in the control area in the repeatable element
<source>. Here, the new optional element
<citedRange> with the optional attribute @unit (no limited values) can contain detailed information like page number(s), paragraphs, or editions, in order to give detailed evidence to a source. Next to
<citedRange>, the element
<source> can contain
<reference>. The optional attribute @sourceReference in the elements in the description area links directly to the according element
<source> (i.e., to
The agent responsible for adding an assertion and the date when an assertion was added or revised has to be entered in
<maintenanceEvent> in the control area. A
<maintenanceEvent> can be described with
<eventDescription>. The optional attribute @maintenanceEventReference in the elements in the description area links directly to the according element
<maintenanceEvent> (i.e., to
A rule used for formulating the assertion can be added in
<conventionDeclaration> in the control area. The optional attribute @conventionDeclarationReference in the elements in the description area links directly to the according convention declaration (i.e., to
<maintenanceHistory> <maintenanceEvent maintenanceEventType="updated" id="me2"> <agent agentType="human">TS-EAS EAC-CPF team</agent> <eventDateTime standardDateTime="2021-02-23"/> </maintenanceEvent> <maintenanceEvent maintenanceEventType="created" id="me1"> <agent agentType="human">TS-EAS EAC-CPF team</agent> <eventDateTime standardDateTime="2019-01-01"/> </maintenanceEvent> </maintenanceHistory> <sources> <source id="source1"> <reference href="https://www.loc.gov/item/40009284/">History of University of Oregon</reference> <citedRange unit="page">270</citedRange> </source> </sources> [...] <relations> <relation sourceReference="source1" mainenanceEventReference="me2"> <targetEntity targetType="corporateBody" valueURI="https://snaccooperative.org/ark:/99166/w63z1x39" vocabularySourceURI="<https://snaccooperative.org>"> <part>Princeton University</part> </targetEntity> <relationType valueURI="https://www.wikidata.org/wiki/Property:P69" vocabularySourceURI="https://www.wikidata.org/">educated at</relationType> </relation> </relations>
Places are, along with names and dates, paramount when describing archival context. A place can be given to locate a function, a legal status, a local description, a mandate, an occupation, and any other entity types, but also to describe a biography or history and to locate a relation. Of course, the element
<places> still serves as a plural element to include one or more elements
<place> to describe any place connected with the entity described.
<placeEntry> is renamed to
<placeName> to be more precise. The optional attribute @accuracy was removed since there was not a single use case available.
<place> has two new child elements. Next to the existing optional element
<address> as a wrapper element for any physical or analog address information, the new optional element
<contact> allows for bundling digital addresses and contact information. Both follow the same content model of at least one or more address lines or contact lines. The
<address> element is ideally bound with a place name. The other new optional child element of
<geographicCoordinates>. Following EAD encoding, the element
<geographicCoordinates> is used to express a set of geographic coordinates as text. The mandatory attribute @coordinateSystem specifies the system used to express the geographic coordinates. In this context, the optional attributes @altitude, @latitude, and @longitude are removed.
<places> <place> <placeName valueURI="<https://www.geonames.org/9675434>" vocabularySource="GeoNames" vocabularySourceURI="<http://www.geonames.org>">The White House and President's Park</placeName> <placeRole>Park</placeRole> <geographicCoordinates coordinateSystem="WGS84">N 38°53′49" W 77°02′12"</geographicCoordinates> <address> <addressLine addressLineType="country">United States</addressLine> <addressLine addressLineType="county">Washington, D.C.</addressLine> <addressLine addressLineType="municipality">Washington</addressLine> <addressLine addressLineType="street">White House Liaison Rm 344 1100 Ohio Drive, SW</addressLine> </address> <contact> <contactLine contactLineType="homepage" href="<https://www.nps.gov/whho/index.htm>">Website</contactLine> <contactLine contactLineType="phoneNumber">(202) 208-1631</contactLine>` </contact> <dateRange> <fromDate>late 18th century</fromDate> <toDate status="ongoing"/> </dateRange> </place> </places>
The encoding of lists was revised and simplified.
<list> can contain the new optional element
<head>, the optional element
<item>, and the optional element
<list>. This results in a new way of nesting lists to express hierarchies or family trees, which replaces the use of the element
<level> that has been removed.
The optional attribute @listType, with the values ordered and unordered, specifies the type of a list and the optional attribute @style can be used to define the style of the list type with W3C CSS values.
<structureOrGenealogy> <list> <head>Bach family</head> <list> <item>Johannes Bach I (1580--1626)</item> <list> <item>Heinrich Bach (1615--1692)</item> <list> <item>Johann Christoph Bach (1642--1703)</item> <list> <item>Johann Nicolaus Bach (1669--1753)</item> </list> </list> <list> <item>Johann Michael Bach (1648--1694</item> <list> <item>Maria Barbara Bach (1684--1720)</item> <list> <head>Marriage with Johann Sebastian Bach</head> <item>Wilhelm Friedemann Bach (1710--1784)</item> <list> <item>Carl Philipp Emanuel Bach (1714--1788)</item> <list> <head>Marriage with Johanna Maria Dannemann</head> <item>Johann Sebastian Bach (painter) (1748--1778)</item> </list> </list> </list> </list> </list> </list> </list> </list> </structureOrGenealogy>
Relations got a new encoding structure in order to simplify them and to achieve better interoperability.
The optional element
<relations> serves as a wrapper element for one or more single relation entries.
<relation> contains one required element
<targetEntity> to identify the entity that is being targeted by the relation. The mandatory attribute @targetType specifies the type of the entity as an agent, a corporate body, a person, a family, a resource, or a function, whereas the attribute value agent is foreseen mainly for conversion from EAC-CPF 2010 to EAC-CPF 2.0. The targeted entity can be encoded with URIs and references to an authority record or any other external file using the optional attributes @vocabularySource, @vocabularyURI, and @vocabularySourceURI.
The optional element
<relation> specifies the type of relation that the entity being described within the EAC-CPF instance has to the targeted entity. Relation types are not fixed and can be given as identity, hierarchical, temporal, family, or associative, but also as creator or subject of a resource. Relations between the entity being described and a function could be controls, owns, or performs. The relation type is given as element text content and also allows using the optional attributes @vocabularySource, @vocabularyURI, and @vocabularySourceURI.
A third target element is called
<targetRole> and can be used to provide information about the role of the targeted entity toward the entity described. Family roles like parent, child, or sibling can be given in that text element.
Furthermore, relation context can be given with date, place, and descriptive information in the according child elements of
<cpfDescription> <identity> <entityType value="person"/> <nameEntry> <part localType="family">Ahrendt</part> <part localType="given">Hannah</part> </nameEntry> </identity> <relations> <relation id="r1"> <targetEntity vocabularySource="GND" vocabularySourceURI="http://d-nb.info/gnd/" valueURI="http://d-nb.info/gnd/1190671301" targetType="person"> <part localType="family">Arendt</part> <part localType="given">Paul</part> </targetEntity> <relationType languageOfElement="de">Familie</relationType> <relationType languageOfElement="en">Family</relationType> <targetRole languageOfElement="de">Eltern</targetRole> <targetRole languageOfElement="en">parent</targetRole> <targetRole localType="code">par</targetRole> </relation> </relations> </cpfDescription>