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). In 2015
the Technical Subcommittees on EAD and EAC-CPF were merged to form the Technical Subcommittee
on Encoded Archival Standards (TS-EAS), responsible for the ongoing maintenance of
EAD and EAC-CPF.
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
[toc]
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
[toc]
1.
Each instance of context information about CPF entities describes a single corporate
body, person or family.
2.
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.
3.
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.
4.
The model supports the linking of descriptions of contextual entities to digital or
other surrogate representations of those entities.
1.
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.