EAC began with a 1998 effort by Richard Szary, Wendy Duff, and Daniel Pitti to envision a standard for encoding and exchanging
authoritative information about the context of archival materials. This standard would provide
a communication standard for the exchange of authority records based on the International Standard for Archival
Authority Records—Corporate Bodies, Persons, Families (ISAAR(CPF)) and would parallel the standard for encoding
archival record finding aids that was found in Encoded Archival Description (EAD). As EAD enabled the practical
expression of the General International Standard Archival Description (ISAD(G)), the new standard would enable the
expression of ISAAR(CPF). A parallel standard would preserve and strengthen the essential duality that characterizes
archival description when it is presented in archival finding aids.
A separate standard would pave the way to eliminating some practical problems found in the use of EAD, which had been developed
as a comprehensive solution for encoding standalone finding aids—the dominant presentation
model—which held all forms of descriptive data about archival records. Since materials by or about a single
entity might be found in many fonds or many repositories, there is much redundant effort in recording information
about the same entity. In addition, these duplicative efforts can result in great inconsistency, which bedevils
both users, in finding and interpreting materials, and archivists, in creating accurate and complete
references to such entities.
Yale University hosted an international meeting in 1998. The meeting was organized by Richard Szary and funded by the Digital
Library Federation. The goals of the meeting were to plan the funding and development of an
encoding standard based on ISAAR(CPF).
In 2001, with financial assistance from the Gladys Krieble Delmas Foundation, a second international working group met in
Toronto. This meeting produced the Toronto Tenets, the principles that gave shape to the proposed
standard. The group also established goals for the standard, mapped out the broader parameters of the Document
Type Definition (DTD), and established a working group to create a fully formed syntax. The DTD achieved its
Beta distribution in 2004, beginning a long testing phase as it was applied in several European and U.S.
projects. Informed by the results that emerged from this testbed, the Society of American Archivists' Encoded
Archival Context Working Group was formed in 2007 to carry this work forward to the creation of a standard
version, and expression in a schema and Tag Library. With the support of the Gladys Krieble Delmas Foundation, the
IBC (Instituto per I beni artistici culturali e naturali) of the Regione Emilia-Romagna, the Archivio di
Stato di Bologna, OCLC Research, and the National Library of Australia, the EAC Working Group met for three days in
Bologna, Italy in May 2008 to lay the foundation of the existing EAC-CPF standard. On-going work via electronic
mail and conference calls continued the work started in Bologna. A review period of the final draft was
offered between August and November 2009, and the completed schema was released in March 2010. The Working
Group is indebted to archivists, librarians and other information professionals throughout the international community for
their input, review, and testing of the schema during its development phase. In 2011, the Working Group was disbanded and
SAA Council approved a charge to form the Technical Subcommittee for Encoded Archival Context (TS-EAC). The Tag Library and,
in collaboration with the Schema Development Team (SDT), the EAC-CPF schema are currently maintained by the Technical Subcommittee.
Archival description includes information about the content, intellectual and physical attributes of the archival material,
as well as information about the context of their creation and use. The contextual information of the creation and use of
material is often complex and multi-layered and may involve individuals, families, organizations, societies, functions, activities,
business processes, geographic places, events, and other entities. Primary among these entities are the corporate bodies,
persons and families (CPF entities) responsible for the creation or use of material, usually organizations or persons. With
information about these CPF entities, users can understand and interpret the records more fully since they will know the context
within which the CPF entities operated and created and/or used the material. Information about these CPF entities can be used
either as a component within descriptive approaches that fully integrate contextual information into descriptive products,
as archives have traditionally done, or as an independent system that is linked to other descriptive systems and products
that focus on content.
Encoded Archival Context – Corporate Bodies, Persons, and Families (EAC-CPF) primarily addresses the description of individuals,
families and corporate bodies that create, preserve, use, and are responsible for and/or associated with records in a variety
of ways. Over time, other types of contextual entities may evolve under the larger EAC umbrella, but currently its primary
purpose is to standardize the encoding of descriptions about CPF entities to enable the sharing, discovery and display of
this information in an electronic environment. It supports the linking of information about one CPF entities to other CPF
entities to show/discover the relationships amongst record-creating entities and the linking to descriptions of records and
other contextual entities.
EAC-CPF is a communication structure for archival contextual information for individuals, corporate bodies and families and
thereby supports the exchange of ISAAR(CPF) compliant authority records. ISAAR(CPF) "determines the types of information that
could be included in an archival authority record and provides guidance on how such records may be deployed in an archival
descriptive system." ISAAR(CPF) also notes that "[s]uccessful automated exchange of archival authority information over computer
networks is dependent upon the adoption of a suitable communication format by the repositories involved in the exchange. Encoded
Archival Context (EAC) is one such communication format which supports the exchange of ISAAR(CPF) compliant archival authority
data over the World Wide Web" (ISAAR(CPF), 2004, p. 12). EAC-CPF provides a mechanism for enabling the full expression of
ISAAR(CPF), however it may also contain some additional elements or technical content not contained within ISAAR(CPF).
Based upon the Toronto Tenets, established in 2001, the following have informed the development of the schema:
Definitions and Uses
1.
Archival context information consists of information describing the circumstances under which archival materials have been
created, maintained and used. This context includes, but is not limited to, the identification and characteristics of corporate
bodies, persons, and families (CPF entities) who have been the creators, users, or subjects of records, as well as the relationships
amongst them.
2.
Context information about CPF entities is not data that describes other information resources, but rather data that describes
entities that are part of the environment in which those information resources (e.g., records) have existed.
3.
The recording of context information about CPF entities in archival information systems directly supports a more complete
description and understanding of records, as well as a provenance-based approach to retrieval of these records across time
and domains.
4.
Context information about CPF entities can also have value as an independent information resource, separate from its use in
supporting the description, retrieval, and interpretation of records.
5.
This model is also intended to support the exchange and sharing of context information about CPF entities, especially in those
instances where repositories have holdings or interests that have context information in common.
Structure and Content
6.
Each instance of context information about CPF entities describes a single corporate body, person or family.
7.
The model provides a framework within which the full range and depth of context information about agents can be recorded but
suggests a minimum set of elements for describing an entity. The model defers recommendations for the appropriate use of other
elements toguidelines developed for specific implementations.
8.
The model defines a set of elements used to describe CPF entities and the structure of relationships between those elements.
This structure supports the discovery, navigation and presentation of context information about CPF entitiesand the linking
of that information to descriptions of resources or to other contextual entities, such as those encoded according to EAD,
MARC, and similar standards.
9.
The model supports the linking of descriptions of contextual entities to digital or other surrogate representations of those
entities.
Technical Issues
10.
The model is expressed as an XML language to encourage platform independence and portability of information. The model may
also be implemented using other approaches.
CPF Entities are complex. For example, one CPF entity can represent multiple identities, or a single identity can be associated
with several different CPF entities. This fact necessitates the structure of a standard to account for the various ways in
which CPF entities can be expressed. In order to accommodate the variety of CPF entities, EAC-CPF has adopted the following
definitions:
SINGLE IDENTITY: one person (or corporate body or family) with a single identity represented in one EAC-CPF instance. This
is the most common identity type.
MULTIPLE IDENTITY-MANY IN ONE: two or more identities (including official identities) with each represented by distinct descriptions
within one EAC-CPF instance. Can be programmatically converted into Multiple Identity-One in Many.
MULTIPLE IDENTITY-ONE IN MANY: two or more identities (including official identities) each represented in two or more interrelated
EAC-CPF instances. Can be programmatically converted into Multiple Identity-Many in One.
COLLABORATIVE IDENTITY: a single identity shared by two or more persons (e.g. a shared pseudonym used in creation of a collaborative
work). Use Multiple Identity-One in Many.
ALTERNATIVE SET: derived EAC-CPF instance that is based on and incorporates two or more alternative EAC-CPF instances for
the same entity. To be used by a consortia or a utility providing union access to authority records maintained in two or more
systems by two or more agencies. Alternative EAC-CPF instances may be in different languages or in the same language.
EAC-CPF has been created to accommodate this variety of identities, and includes a number of ways to express complexities
based on individual repository or aggregator preferences. These options reflect a design principle that underscores increased
opportunity for repositories or aggregators to customize the standard for specific needs while at the same time ensuring future
aggregation. These flexibilities also reflect an acknowledgement that some fundamental philosophical differences with regard
to the processing of information related to separate identities of the same CPF entity exist in the international community.
EAC-CPF maintains a neutral stance on those philosophical differences and instead has accommodated the various options without
precluding aggregation in the future.
For purposes of this tag library, agents refer to repositories or services creating or maintaining EAC-CPF records, while
entities refer to those for which the records are about.
Agent: Within the framework of the EAC-CPF schema and Tag Library, agent refers to a repository where records are managed
or to individuals performing maintenance activities in the repositories. For example, agent is an element of the EAC-CPF schema within maintenanceEvent.
CPF entity: A shortcut within the framework of this Tag Library to generically designate the type of entities that are the
object of a description in an EAC-CPF instance. In other words, it stands for “the corporate body, person or family being
described in an EAC-CPF instance.”
Grouping: In the EAC-CPF Tag Library, the term “grouping” is used as a specialized type of wrapper for those pluralized description
elements, e.g., legalStatuses, functions, etc.
Identity: Though most commonly individuals are known by their real name (the name they were given at birth), it happens that,
in the course of their life, they might acquire names other than their real name. In cases where an individual has separate
lines of activity, each under a different name, it might be of interest to distinguish between these names and consider them
as distinct identities. From the information management standpoint, according to the policy of the repository, each of these
distinct identities, though belonging to the same physical person, might either be described separately in distinct EAC-CPF
instances (see EAC-CPF concepts, case of MULTIPLE IDENTITY – ONE IN MANY) or might co-exist in one EAC-CPF instance (see EAC-CPF
concepts, case MULTIPLE IDENTITY – MANY IN ONE). Another case is that of a collaborative identity where several individuals
chose to make themselves publicly known under a personal name (see EAC-CPF concepts, case COLLABORATIVE IDENTITY), justifying
their being described in one single EAC-CPF instance.
Resource: Materials, other than CPF entities and functions’ descriptions, to which CPF instances are related.
Wrapper: In the EAC-CPF Tag Library, the term “wrapper” is used as a descriptive function for elements that can contain other
elements only, e.g., legalStatus, function, and cpfDescription, etc.
The section “Availability” informs about the conditions of the occurrence of an element within its parent element.
Overview of EAC-CPF Structure and Semantics
[toc]
Each EAC-CPF instance contains two mandatory elements, the <control> element and
either the element <cpfDescription> or <multipleIdentities>. The
<control> element contains data used in management of the EAC-CPF instance by providing administrative metadata for the description
it contains. cpfDescription contains information on the
name structures, descriptive elements, and relationships. <multipleIdentities> is
used when there is more than one <cpfDescription>. These two wrapper elements contain
specific elements to support the functional intentions of the parent or containing
element.
<eac-cpf>
<control>
[control elements]
</control>
<cpfDescription>
[description elements]
</cpfDescription>
</eac-cpf>
OR
<eac-cpf>
<control>
[control elements]
</control>
<multipleIdentities>
<cpfDescription>
[description elements]
</cpfDescription>
<cpfDescription>
[description elements]
</cpfDescription>
<cpfDescription>
[description elements]
</cpfDescription>
</multipleIdentities>
</eac-cpf>
The <control> element contains the following subelements; they are presented in the prescribed order in the EAC-CPF schema:
<recordId> - Required. Contains the one or more unique identifiers for the
EAC-CPF instance.
<otherRecordId>-Optional.An element that allows the recording of additional identifiers that may be associated with the EAC-CPF instance.
<maintenanceStatus> - Required. Contains the current drafting status of the EAC-CPF instance. Values include: new, revised, deleted, cancelled,
deletedSplit, or deletedReplaced.
<publicationStatus> - Optional.Contains information about the editorial status of the EAC-CPF instance.
<maintenanceAgency> -Required. Contains the name and coded information about the institution or service responsible for the creation, maintenance,
and/or dissemination of the EAC-CPF instance.
<languageDeclaration>-Optional.Contains coded and natural language information about the language or languages of the EAC-CPF instance.
<conventionDeclaration>-Optional.Contains information on the rules used to construct the EAC-CPF instance, in particular the names formed in <identity> and the controlled vocabularies and thesauri used in the EAC-CPF instance.
<localTypeDeclaration>-Optional.An element used to declare local conventions used in the @localType attribute.
<localControl> - Optional. An element in which to record any administrative metadata necessary due to local practice that are not represented
by the other elements in <control>.
<maintenanceHistory> - Required. Contains information about the date, type and events within the life cycle of an EAC-CPF instance. Contains one
or more <maintenanceEvent> elements that document creating, importing, updating, and deletion of the description. Each maintenance event contains an
agent, the type of agent (human or machine), the type of event, a description of the event, and the date of the event.
<sources>-Optional. Contains information about the sources consulted in creating the description of the CPF entity or entities in the
EAC-CPF instance. Contains one or more <source> element.
The <cpfDescription>-Corporate body, person or family description, comprises the
description of the entity. Similar to the <control> element,
<cpfDescription> has four complex subelements used to describe different features
of the entity:
<identity> -Required. Complex structure containing the name or names used by the CPF entity over the course of the entity’s existence.
Contains a repeatable <nameEntry> element for different names, and a repeatable <nameEntryParallel> element for more than one <nameEntry> expressed in different languages.
<description> -Optional. Contains formal description elements parallel to those in ISAAR (CPF) for the description of the CPF entity. An
additional <localDescription> allows for local implementation of additional descriptive information not included in the other <description> elements.
<relations> -Optional. Contains one or more references to or descriptions of related corporate bodies, persons or families <cpfRelation>, functions <functionRelation>, or resources <resourceRelation>.
<alternativeSet> -Optional. Contains two or more descriptions for the same CPF entity derived from two or more systems, expressed within a
single EAC-CPF instance. The <alternativeSet> consists of two or more <setComponent> elements for the descriptions.
The most complex element in the EAC-CPF schema is the <identity> element. In
addition to needing to accommodate one or more names used for or by the CPF entity,
<identity> must accommodate two or more parallel names in different languages and/or
scripts. In countries where there is more than one official language, such as Canada, names of
corporate bodies have more than one language. The <identity> contains a required
<entityType> and one or more <nameEntry> and/or
<nameEntryParallel> elements. It also includes an optional <entityId> and
<descriptiveNote>. The <nameEntry> element is constructed of one or more
<part> elements and contains the attributes @scriptCode,
@xml:lang, @transliteration, and @localType to provide
precision about the language and script of the names if desired. It includes an optional
<useDates> element to identify dates of use of a name. <nameEntryParallel>,
which is intended for use when the same name is expressed in different languages, contains one
or more <nameEntry> elements and an optional <useDates> element. For
example, within the context of the Archive of Ontario, parallel French and English headings
can be designated through two parallel
<nameEntry> elements, with the two different headings being distinguished by the
values in the @xml:lang.
Within <identity>, names represented through <nameEntry> or <nameEntryParallel> may be selected as authorized or variant names. The <authorizedForm> and <alternativeForm> elements are
available within <nameEntry> and <nameEntryParallel> elements to identify the status of the name according to a particular set of rules. The content of the element is the identification
of those rules.
Additionally, within <nameEntryParallel>, a single <nameEntry> may be preferred over others. A <preferredForm> element is available in that instance to identify the preferred form of the name
according to a particular set of rules. The content of the element identifies those rules.
The <description> accommodates a variety of both controlled and prose descriptions of CPF entities. The contained elements closely reflect
the descriptive categories outlined in ISAAR (CPF). Descriptive elements
generally have a singular and plural form, the latter being used for those cases of multiple instances
of a descriptive category or less formal prose description. For example, <function> would be used for a
single function term, <functions> will bundle more than one function descriptor or alternatively, it will allow a discursive description. Most elements within
<description> include an optional
<descriptiveNote> element to provide explanatory text. Elements for description include:
<existDates> — Optional. Dates of existence of the CPF entity being described. Can include actual or approximate dates, using either <date>, <dateRange>, or <dateSet>.
<place> — Optional. Includes relevant location information, optionally paired with related date information. Includes elements <placeEntry> and <placeRole> and the range of possibilities with date information: <date>, <dateRange>, <dateSet>.
<localDescription> — Optional. An element intended to extend the descriptive categories available in a local system. Includes a <term> element and the range of possibilities with date information: <date>, <dateRange>, <dateSet>.
<legalStatus> — Optional. Includes the legal status of a corporate body, typically defined by authorities and granted by either a government
or an authorized agency. Includes a <term> element and the range of possibilities with date information: <date>, <dateRange>, <dateSet>.
<function> — Optional. Includes relevant functions, processes, activities, tasks, or transactions performed by the CPF entity being
described. Includes a <term> element and the range of possibilities with date information: <date>, <dateRange>, <dateSet>.
<occupation> — Optional. Includes relevant occupations held by the CPF entity being described. Includes a <term> element and the range of possibilities with date information: <date>, <dateRange>, <dateSet>.
<mandate> — Optional. Includes relevant mandates for corporate bodies being described. Includes a <term> element and the range of possibilities with date information: <date>, <dateRange>, <dateSet>.
<structureOrGenealogy> — Optional. Includes information about the structure of a corporate body or the genealogy of a person or family. Includes
elements <outline>, <list>, and <p> to assist in structuring the text.
<generalContext> — Optional. Includes information about the general social and cultural context of the entity being described. Includes <list>, <outline>, <p> elements to assist in structuring the text.
<biogHist> — Optional. Includes discursive text providing biographical and/or historical information about the CPF entity being described.
Includes an <abstract> element for a brief synopsis of the full content; a <chronList> element allows for structured date, event and optional place information. Includes <list>, <outline>, <p> elements to assist in structuring the text.
All elements in <description> provide a @localType attribute to provide semantic specificity to the term being used. With the exception of <existDates>, <structureOrGenealogy>,
<generalContext>, and <biogHist>, plural form grouping elements are available to bundle multiple occurrences of these elements. These grouping elements also
include elements <citation>,
<list>, <outline>, and <p> to accommodate greater complexity in representing the description being created.
One of the core design principles of EAC-CPF is to avoid describing relationships in a linear fashion, but instead to leverage
a distributed descriptive environment.
As a component of archival description, the description of corporate bodies, persons and families must be brought into relation
with the other descriptive components. Such CPF entity descriptions must be dynamically related to the record descriptions
for which they provide context, and the functions and activities in which they engage and that the records document. With
the exception of unique relations, it is the nature of relations that they take place among entities and not within them.
Corporate bodies, persons and families are related to other entities, to functions and activities, and to records. Similarly,
functions and activitiesare related to other functions and activities, to creators, and to records; and records are related
to other records, to CPF entities, and to functions and activities. Each CPF entity, record, or function/activity description
can thus act as a node in a set of relations.
Because relations occur between the descriptive nodes, they are most efficiently created and maintained outside of each node.
A person, for example, can be related to one or more persons, organizations or families; to
one or more archival records, books, journals, and museum objects; and to various functions and activities.
Each of the related entities can be related to one or more other entities. To record all of these relations
in the description of each node is inefficient, as correction of an error would require updating two
or more descriptions.
While maintaining relations independent of descriptions is efficient, when communicating descriptions between systems or to
users it will be necessary to assemble or gather and represent the related descriptions using descriptive surrogates. Each
surrogate for a related description will optimally include both human- and machine-readable information. The human-readable
information provides succinct descriptions of the related CPF entity, records, or function/activity sufficient to enable identification
and a relevancy judgment. The machine-readable information supports a traversable link to the related description.
There are three elements for describing relations with other descriptions included in the <relations> element: <cpfRelation>, <functionRelation>, <resourceRelation>. Within
each of these relations elements, there are <relationEntry>, <objectXMLWrap>, <objectBinWrap>, <date>, <dateRange>, <dateSet>, <placeEntry> and <descriptiveNote>
elements. Individual relations include the following optional attributes related to the type of relation
that is being described:
<cpfRelation> — includes an attribute @cpfRelationType; values are identity, hierarchical, hierarchical-parent, hierarchical-child, temporal, temporal-earlier, temporal-later,
family,
associative.
<functionRelation> — includes an attribute @functionRelationType; values are controls, owns, performs.
<resourceRelation> — includes an attribute @resourceRelationType; values are creatorOf, subjectOf, other.
Other attributes available for the relation elements include @lastDateTimeVerified, and the suite of simple Xlink attributes.
There are two principal rationales behind the simple typing of relations. First, there is general interest in enabling coherent
expression and navigation of relations as well as creation of graphic displays of organizational charts, family trees, and
time lines. The simple relationships are an experimental attempt to provide the data necessary to construct such displays.
At this point, there has been no attempt to test the utility of the structures with graphic displays. Second, basic information
about the nature of relations is necessary in order to make the relationship intelligible to users. Given cultural and institutional
differences, the number of possible relation types is, in principle, unlimited. EAC-CPF designers decided, though, that to
achieve a minimum level of functionality there needed to be consensus on a set of basic or primitive relation types.
Integrating XLink into EAC-CPF
[toc]The EAC-CPF schema includes support for linking to external resources using a limited subset of the xlink standard, which
is defined at
http://www.w3.org/TR/xlink/. The
xlink attributes can be used to create and describe links between resources. In particular they can be
used to reference a richer set of relationships than those that are supported by @cpfRelationType,
@functionRelationType, and @resourceRelationtype. The xlink attributes are available on the following
elements: <citation>, <cpfRelation>, <functionRelation>, <resourceRelation>,
<setComponent>, and <source>.
A more complete description of these attributes is provided in the attributes section of the tag library, but the following
information is intended to summarize how they might be used in conjunction with each
other.
Xlink Type Attribute
@xlink:type — This attribute is required if any of the other xlink attributes are used on the parent element. It takes the fixed value
of 'simple' since EAC-CPF's implementation of xlink only supports
outbound links to one resource. If multiple outbound links are required, each link should be represented
in a new parent element.
Locator Attribute
@xlink:href — This optional attribute may be used to provide the location of the resource that is being linked to. The link must be a
valid URI.
Semantic Attributes
@xlink:arcrole — This optional attribute may be used on <cpfRelation>, <functionRelation>, and <resourceRelation> to provide a precise description of the relationship between the CPF entity
described in the EAC-CPF instance and the description to which it is linked. When used on <citation>, <setComponent>, and<source>, it provides an explicit and perhaps more precise description of the
relationship that is implied by the context of use. The value must be a valid URI.
@xlink:role — This optional attribute is used to provide a reference to the nature of the linked remote resource. It specifically provides
a means to specify the nature of a linked resource in
<resourceRelation>, as described in ISAAR (CPF) 6.2. The value provided must be a valid URI.
Link Behavior Attributes
@xlink:actuate — This optional attribute may be used in conjunction with xlink: show to instruct an external application as to the circumstances
under which the linked resource should be resolved. For
example, an application can be instructed to load the resource when the parent xml document is loaded
or only when the page is requested by a user or application.
@xlink:show — This optional attribute may be used in conjunction with xlink:actuate to instruct an external application as to the manner
in which the linked resource should be shown to the user when it is
resolved. For example, the application can be instructed to replace the current xml document when
loading the resource or to load it in a new window or tab.
@xlink:title — This optional attribute may be used to provide a caption or title that an external system or application may use when presenting
a link to the user.
Implementers of EAC-CPF will need to provide for the full
implementation of the xlink attributes using server-side instructions. One implementation example, demonstrating
the intended effects of xlink usage, is provided at
http://www.snee.com/xml/xlink/sxlinkdemo.xml.
The following excerpt provides one example of how xlink might be implemented in reference to an external vocabulary, to indicate
that the information at the related URL describes the spouse of the person described in
the EAC-CPF record:
<cpfRelation cpfRelationType="family" xlink:actuate="onRequest" xlink:arcrole="http://library.illinois.edu/archives/eac-cpfRelations.html#spouseOf" xlink:href="http://library.illinois.edu/archives/archon/index.php?p=creators/creator&id=546" xlink:show="new" xlink:type="simple">
<relationEntry>Gregory, John Milton</relationEntry>
<descriptiveNote>
<p>John Milton Gregory was the husband of Louisa Allen Gregory.</p>
</descriptiveNote>
</cpfRelation>
<resourceRelation resourceRelationType="creatorOf" xlink:role="http://library.illinois.edu/archives/eac-cpfRelations.html#collector" xlink:type="simple">
<relationEntry>Collezione Fortunato Depero (Polo culturale e Galleria Museum Depero, Roverto</relationEntry>
<descriptiveNote>
<p>ITA MART, Collezione Depero, Collezione d'arte, 1919-1959, Creatore della collezione, </p>
</descriptiveNote>
</resourceRelation>
The vocabulary at purl.org referenced above is not intended to be normative and is provided for illustrative purposes only.
Over time it is hoped that communities will develop and maintain controlled
vocabularies to describe the nature of the relationships to the people, families, corporate bodies, resources,
and functions that are described in the <cpfRelation>, <resourceRelation>, and
<functionRelation> elements. Such vocabularies could be maintained locally, nationally, or even internationally, perhaps as a continuation of
the work of the Technical Subcommittee – Encoded Archival Context (TS-EAC).
As an international effort, the designers of EAC-CPF are attempting to agree on as much as possible while accommodating cultural
and institutional differences. The semantics and structure described above represents the
current semantic and structural consensus and is tied closely to ISAAR(CPF).
In addition to the element <localDescription>, described above, many elements may also be qualified with @localType. This attribute is intended to enable EAC-CPF to be adapted for use in national,
regional, and local environments where semantics more specific than those provided in EAC-CPF may be
necessary, or where descriptive categories not specifically addressed in EAC-CPF are necessary.