EAD Revision, EAC-CPF introduction

1. EAD Revision
2. EAC-CPF: an
introduction
Timothy Ryan Mendenhall
Leo Baeck Institute
2012 March 28

EAD Revision

 Timetable:
 Currently: analyzing comments
submitted during open comment
period
 December 2012: draft schema for
revision and comment
 August 2013: release of new schema

EAD Revision
 What to expect:
 Migration plan
 Interoperability:
• better support for the semantics of
relationships (cf. EAC-CPF, RDA)
 Interchange:
• data interchange trumps presentation
• promote uniform and predictable use to
enable better interchange of data.

EAD Revision: the details. . .

 Schema only -- DTD will be
deprecated
 Simplification:
 Reduced number of tags
 Deprecate presentation-oriented tags
like <emph>, <head>, <table>

DTD  Schema


 Simplification:
 Simplified header
 Simplified hierarchical structure
• <c01>, <c02> etc merge into
undifferentiated <c> tags
• Wrapper and structural tags like <dsc>
might be deprecated

 Make EAD more database-friendly:
 Less mixed content, more tagged data
 More specific, granular tags: e.g. forenames
and surnames
 More flexibility for normalizing dates (multiple
dates, ranges of dates, etc. Cf. EAC, RDA)
 Geo-tagging
 “Profiles” of tag sets for different types of
repositories

 Extend potential for language
qualifications:

 <geogname language=”ger”>Köln
(Deutschland)</geogname>

and/or

<geogname language=”eng”>Cologne
(Germany)</geogname>

Date-centered model: Goals
 Improve machine-readability of
finding aids
 Aid in the sharing of finding aid
data across platforms, CMS’s,
languages, countries, and different
aggregators
 Move away from the document
model: finding aid as a fluid,
malleable record, not a fixed
document

Affect on CJH
 Likely minimal – migration paths will
be made available
 Conversion from EAD-DTD to EAD-
Schema
 Creation of task force?
 Resources, stylesheets available
 Creation of new EAD templates
 New possibilities!

Basics
 EAC-CPF: Encoded Archival Context
– Corporate Bodies, Persons,
Families
 XML vocabulary
 Based on ISAAR-CPF: int’l standard
related to ISAD(G)
 Adopted by SAA in 2011: standard for
archival authority data

Features

 Parallels many RDA changes
 Increased granularity of data
• E.g. life dates split into birth and death
dates
 Emphasis on relations
• With other resources
• With other corporate bodies, persons,
families
• With functions

Features

 Compatibility with existing authority
data (LCSH, etc.)
 Wrapper elements allow wholesale
inclusion of outside metadata, i.e.
authority MARC-XML
 Great flexibility for alternate names,
variant forms, local implementations

Features

 Accomodates 4 different types of
“entities”
 Single identity
 Multiple identity
• Many in one (single EAC-CPF instance)
• One in many (multiple instances)
 Alternative sets (i.e. variant records)

Why EAC?
 Part of broader move towards
semantic web, linked open data (LOD)
 Better end-user experience
 Improves capacity for faceted
searching
 More intuitive web interfaces
 Standardization of authority data
 Sharing of authority data
 Eventually – saves time

Examples

 Sample records:
 http://www3.iath.virginia.edu/eac/cpf/examp

 EAC in action:
 http://socialarchive.iath.virginia.edu/xtf/sear

Basic structure

 Like EAD (and MARC), divided into
control and descriptive sections:
 <eac-cpf>
<control> […] </control>
<cpfDescription>
[ALTERNATE
<multipleIdenties><cpfDescription> . . .]
</cpfDescription>
</eac-cpf>

Basic structure : Control
 Administrative data about the record
itself
 Required elements:
• recordId
• maintenanceAgency
• maintenanceStatus
• maintenanceHistory
• languageDeclaration
• sources

Basic structure : Control

 Optional elements
 Allow for local customization
 Use of other identifiers for same entity
(i.e. from other thesauri, other national
libraries, etc.)

Basic structure : cpfDescription

 Descriptive section <cpfDescription>
 For most records: single <identity>
 For complex identities
• many-in-one, corporate and compound
entities
• multiple <cpfDescription> elements
wrapped in <multipleIdentities> tag

 Required: <identity>
 Optional:
 <description>
 <relations>
 <alternateSet> -- alternate records for
the same entity imported from a
different authority system, such as
LCSH, VIAF, or a different national
library.

 Descriptive section: required <identity>
 Most complex element
 Parallels RDA changes:
• Increased functionality for parallel and
variant forms of names
• Can distinguish between “authorized” and
“preferred” forms of a name
• Increased granularity (parts of names,
dates)
• Ability to qualify variant forms of names
by “use dates”


 Optional <description>
 Very similar to RDA, but encoded in XML
 <existDates>
• <date>, <dateRange>, <dateSet>
 <places>
• May be qualified by dates and roles
• Place of residence, place of birth, place of
death, etc.


 All may be qualified by dates:
 <occupations>
 <functions>
 <legalStatus> (corporate body)
 <mandates> (corporate body)


 “Free text” descriptive sections:
 <biogHist> -- same as in EAD
 <generalContext> -- “general social
and cultural context
 <structureOrGenealogy>
• Structure of corporate bodies
• Genealogy of individuals, families


 Relations section:
 <cpfRelation> -- relations to other
“entities”
 <functionRelation>
 <resourceRelation>
 <objectXMLWrap> to include other
records, portions of other records

 Relations section:
 All have “relation type” attributes to help
specify the type of relation:
• cpf: Family, associative, hierarchical-child,
hierarchical-parent, etc.
• Functions: controls, owns, performs, etc.
• Resources: creator, subject, etc.
 To include other records, portions of other
records:
• <objectXMLWrap>
• <objectBinWrap>

Implementation at CJH?

 Via Digitool?
 Similar to MARC to EAD
• Wholesale batch conversion
• Issues:
• data cleanup
• Skeletal data
• Resolving differences in existing biographical
notes, etc.
• Digitool’s interface – not good for “active”
records needing frequent syncing, updating

 Via Digitool?
 Steps required:
• Batch export of authority data from Aleph
• LCNAF is also available for download
• MARC to EAC stylesheet
• Google Refine: cleanup data
• Ingest to Digitool
• EAC to HTML stylesheet
• Google Refine: resolution with existing
EADS

 Via Digitool?
 Potential for *labor-intensive* edits
• Roles within collection
• Center-wide agreement on relator terms
(RDA?), manually updating EAD “role”
attributes
• Expansion of biogHist,
structureOrGenealogy, etc.
 Custom database outside of Digitool?
 Eventually – ArchivesSpace?

Future potential
 Crowd-sourcing
 Relationship data
 Function data (“Is correspondent”, “Is
subject” etc)
 Genealogical data
 Harvesting biographical, historical and
genealogical data
 DBPedia
 JewishGen

Resources

 MARC-XML to EAC stylesheets
 Entire LCSH, LCNAF available for
download (MADS/RDF):
 http://id.loc.gov/download/
 EAC-Pages:
 http://eac.staatsbibliothek-berlin.de/
 EAC listserv = EAD listserv

EAD Revision, EAC-CPF introduction

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to EAD Revision, EAC-CPF introduction

Similar to EAD Revision, EAC-CPF introduction (20)

Recently uploaded

Recently uploaded (20)

EAD Revision, EAC-CPF introduction

Editor's Notes