Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Formats for Exchanging Archival Data: An Introduction to EAD, EAC-CPF, and Archival Metadata Standards

1,603 views

Published on

Presented July 1, 2011, as part of the session "Standards, Information, and Data Exchange" at the 7th International Seminar of Iberian Tradition Archives, Rio de Janeiro, Brazil.

Published in: Education, Technology
  • Be the first to comment

Formats for Exchanging Archival Data: An Introduction to EAD, EAC-CPF, and Archival Metadata Standards

  1. 1. Formats for Exchanging Archival Data An Introduction to EAD, EAC- CPF, and Archival Metadata Standards VII International Seminar of Archives from Iberian Tradition
  2. 2. Michael Rush Accessioning Archivist / EAD Coordinator, Beinecke Rare Book and Manuscript Library, Yale University Co-Chair, Technical Subcommittee2 for Encoded Archival Description,
  3. 3. Assumptions and Definitions3
  4. 4. Assumptions  Familiarity with some ICA standards - ISAD (G), ISAAR (CPF), ISDF, or ISDIAH  Awareness of EAD, but little of no experience with it  Little or no experience with XML4
  5. 5. Definitions  EAD: Encoded Archival Description  EAC-CPF: Encoded Archival Context – Corporate bodies, Persons, and Families  XML: Extensible Markup Language5
  6. 6. Development History6
  7. 7. EAD Development History  Berkeley Finding Aid Project (1993-1995)  EAD Alpha (1996)  EAD Beta (1996)  EAD 1.0 (1998)  EAD 2002 (2002)  EAD 2002 Schema (2007)  EAD 2013?7
  8. 8. EAC-CPF Development History  Meeting at Yale University (1998)  Meeting at University of Toronto (2001)  EAC Beta (2004)  EAC-CPF (2010)8
  9. 9. Governance and Maintenance9
  10. 10. Governance and Maintenance  EAD  EAD Working Group (1995-2010)  Technical Subcommittee for EAD (2010- )  EAC-CPF  Ad hoc working group (2001-2004)  EAC Working Group (2007-2011)  Technical Subcommittee for EAC-CPF (2011- )  Schema Development Team (2010- )10
  11. 11. Design Goals and Applications11
  12. 12. EAD Design Goals  Represent hierarchical structure of finding aids  SGML, then XML  Flexibility, to encourage adoption.  Compatibility with ISAD (G)12
  13. 13. EAD Applications  Delivery  Standardization  Sharing  Transmission/Communication  Repurposing13
  14. 14. Example EAD Implementations  Yale Finding Aid Database  Online Archive of California (OAC)  Northwest Digital Archive (NWDA)  Archives Portal Europe (APEnet)14
  15. 15. EAC-CPF Design Goals  Close compatibility with ISAAR (CPF)  A change from EAC Beta to current schema  XML  Philosophical neutrality  Relatively simple and straightforward  Extensible design  Adaptability to relational database structures15
  16. 16. EAC-CPF Applications  Identity/Authority  Description  Relationships  Aggregation  Transmission/Communication16
  17. 17. Oral history interview with Terry Sanford UNC SOHP Terry Terry SanfordTerry Sanfordpapers, 1946- Sanford records and papers, 1945- 1993 1998UNC (#3531) (EAC- Duke University CPF) Terry Sanford’s Governor’s papers, 1959- 1965 NC State Archives
  18. 18. Example EAC-CPF Implementation  The Social Networks and Archival Context Project (SNAC)18
  19. 19. Challenges19
  20. 20. Challenges  Data migration and/or creation  Establishing encoding best practices  Delivery  Indexing and search  Display  Data maintenance  Sharing20
  21. 21. Data migration/creation  Methods  Hand encoding  Templates  Scripting  Outsourcing  Export from databases (Archivists’ Toolkit, Archon, ICA AtoM)  Costs  Staff time  Staff training  Consultant or outsourcing fees21  Software
  22. 22. Encoding Best Practices  Local  Yale EAD Encoding Best Practice Guidelines [EAD]  Consortial  Northwest Digital Archives Best Practice Guidelines [EAD]  RLG Best Practice Guidelines for Encoded Archival Description [EAD]22
  23. 23. Delivery  Indexing and search  No single solution  Popular tools include :  XTF (eXtensible Text Framework)  Fedora Commons Repository Software  Display  Transformation via XSLT (Exstensible Stylesheet Language – Transformations)  XML --> HTML  XML --> PDF23
  24. 24. XML HTML XSLT CSS24
  25. 25. Data Maintenance  File management  Version control  Link maintenance25
  26. 26. Sharing  Consortia  Bulk Aggregators  ArchiveGrid  Topical Aggregators  U.S. National Library of Medicine, History of Medicine Finding Aids Consortium26
  27. 27. Related Standards27
  28. 28. Related Description Standards  ICA standards:  ISAD(G): General International Standard Archival Description - Second edition  ISAAR(CPF): International Standard Archival Authority Record for Corporate Bodies, Persons and Families, 2nd Edition  ISDF: International Standard for Describing Functions  ISDIAH: International Standard for Describing Institutions with Archival Holdings  National Description Standards  DACS: Describing Archives: A Content Standard28 (USA)
  29. 29. EAD Data Structure29
  30. 30. EAD: Basic Structure <ead>* <eadheader>* <archdesc>* <dsc>30
  31. 31. EAD Header <eadheader>* <eadid>* <filedesc>* <profiledesc> <revisiondesc>31
  32. 32. File Description <filedesc>* <titlestmt>* <titleproper>* <author> <publicationstmt> <publisher>32
  33. 33. Profile Description <profiledesc> <creation> - Creation <langusage> - Language Usage <descrules> - Descriptive Rules33
  34. 34. Revision Description <revisiondesc> <change> - Change <date> - Date <item> - Item34
  35. 35. EAD: Basic Structure <ead>* <eadheader>* <archdesc>* <dsc>35
  36. 36. Hierarchical Encoding  <archdesc>  Top level of description.  <dsc>  Optional child of <archdesc>  Consists of nested components36
  37. 37. Components  <c> - Component (Unnumbered)  Or  <c01> - Component (First Level) <c02> - Component (Second Level)37 Through <c12> - Component
  38. 38. Levels of Description  @level [ISAD(G) 3.1.4]  subseries  collection  file  fonds  item  class  Otherlevel  recordgrp  series  <archdesc  subfonds level=“fonds”>  subgrp  <c level=“series”>38
  39. 39. Descriptive Elements  Valid as at all levels of description  <did> is required at each level of description.39
  40. 40. Descriptive Identification  <did>*  Always the first child of <archdesc> and the component elements.  Wrapper element containing elements with basic identifying information.  Must have one child element.40
  41. 41. <did> Children  <unitid> - Unit Identification [ISAD(G) 3.1.1]  <unittitle> - Unit Title [ISAD(G) 3.1.2]41
  42. 42. <did> Children (continued)  <unitdate> - Unit Date [ISAD(G) 3.1.3]  <physdesc> - Physical Description [ISAD(G) 3.1.5]42
  43. 43. <did> Children (continued) <origination> - Origination [ISAD(G) 3.2.1] <langmaterial> - Language of the Material [ISAD(G) 3.4.3]43
  44. 44. <did> Children (continued)  <note> - Note [ISAD(G) 3.6.1]  <abstract> - Abstract  <physloc> - Physical Location  <materialspec> - Material Specific Details  <repository> - Repository44
  45. 45. <did> Children (continued) <did> <container> - Container <dao> - Digital Archival Object <daogroup> - Digital Archival Object Group45
  46. 46. <did> Siblings  <bioghist> - Biography or History [ISAD(G) 3.2.2]  <custodhist> - Custodial History [ISAD(G) 3.2.3]  <acqinfo> - Acquisition Information [ISAD(G) 3.2.3]46
  47. 47. <did> Siblings  <scopecontent> - Scope and Content [ISAD(G) 3.3.1]  <accruals> - Accruals [ISAD(G) 3.3.2]  <appraisal> - Appraisal [ISAD(G) 3.3.3]  <arrangement> - Arrangement47 [ISAD(G) 3.3.4]
  48. 48. <did> Siblings (continued)  <accessrestrict> - Conditions Governing Access [ISAD(G) 3.4.1]  <userestrict> - Conditions Governing Use [ISAD(G) 3.4.2]  <phystech> - Physical Characteristics and Technical Requirements [ISAD(G) 3.4.4]48  <otherfindaid> - Other Finding Aid
  49. 49. <did> Siblings (continued)  <originalsloc> - Location of Originals  [ISAD(G) 3.5.1]  <altformavail> - Alternative Form Available [ISAD(G) 3.5.2]  <relatedmaterial> - Related Material49 [ISAD(G) 3.5.3]
  50. 50. <did> Siblings (continued)  <bibliography> - Bibliography [ISAD(G) 3.5.4]  <note> - Note [ISAD(G) 3.6.1]  <odd> - Other Descriptive Data [ISAD(G) 3.6.1]  <processinfo> - Processing Information50 [ISAD(G) 3.7.1]
  51. 51. <did> Siblings (continued)  <prefercite> - Preferred Citation  <controlaccess> - Control Access  <fileplan> - File Plan  <index> - Index51
  52. 52. EAC-CPF Data Structure52
  53. 53. EAC-CPF Concepts SINGLE IDENTITY: one person (or corporate body or family) with a single identity represented in one EAC-CPF instance. (Most common.) 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. (Less common though not rare.) 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. (Less common though not rare.) 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 same53 language.
  54. 54. Basic structure  <eac-cpf>* <control>* <cpfDescription> <identity> <description> <relations>54
  55. 55. Basic Structure <control>: identity, creation, maintenance, status, rules and authorities, and sources used to generate the EAC-CPF instance. <cpfDescription>: description of the EAC-CPF entity  <identity>: names  <description>: formal and informal descriptive elements  <relations>: relationships to other entities, resources and function descriptions55
  56. 56. Philosophical neutrality (1) <eac-cpf> <control></control> <cpfDescription> <identity></identity> <description></description> <relations> <cpfRelation></cpfRelation> <cpfRelation></cpfRelation> </relations> </cpfDescription> </eac-cpf>56
  57. 57. Philosophical neutrality (2) <eac-cpf> <control></control> <multipleIdentities> <cpfDescription></cpfDescription> <cpfDescription></cpfDescription> <cpfDescription></cpfDescription> </multipleIdentities> </eac-cpf>57
  58. 58. <control>  <recordId>*  <maintenanceAgency>*  <maintenanceStatus>*  <maintenanceHistory>*  <publicationStatus>  <languageDeclaration>*  <sources>*  <conventionDeclaration>  <otherRecordId>  <localControl>  <localTypeDeclaration>58
  59. 59. <cpfDescription>/<identity>  <entityType>*  <nameEntry>**  <nameEntryParallel>**  <entityId>  <descriptiveNote>59
  60. 60. Basic Name Models <nameEntry> <part></part> <useDates></useDates> </nameEntry> <nameEntryParallel> <nameEntry></nameEntry> <nameEntry></nameEntry> </nameEntryParallel>60
  61. 61. <cpfDescription>/<description>  <existDates>  <function>  <generalContext>  <legalStatus>  <languageUsed>  <mandate>  <occupation>  <place>  <biogHist>  <structureOrGenealogy>  <localDescription>61
  62. 62. <cpfDescription>/<relations>  <cpfRelation>  <functionRelation>  <resourceRelation> ◦ @*RelationType ◦ <relationEntry> ◦ <objectBinWrap> ◦ <objectXMLWrap> ◦ <date>, <dateRange>, <dateSet> ◦ <place> ◦ <descriptiveNote>62
  63. 63. <cpfRelation>: relation types  @cpfRelationType  identity  hierarchical  hierarchical-parent  hierarchical-child  temporal  temporal-earlier  temporal-later  family  associative63
  64. 64. <resourceRelation>: relation types  @resourceRelationType  creatorOf  subjectOf  other64
  65. 65. <functionRelation>: relation types  @functionRelationType  controls  owns  performs65
  66. 66. Future Development66
  67. 67. EAD Revision Timeline  Comment period complete (October 2010 – February 2011)  EAD Revision Forum (SAA Annual Meeting, August 2011)  TS-EAD Working Meeting (March 2012)  Release draft schema (Fall 2012)  Second comment period (Winter 2013)  Finalize schema and documentation (Spring 2013)  Release revised schema (August 2013)67
  68. 68. EAD Revision Goals  Clarify relationship with EAC-CPF  Improve interoperability with databases  Reconsider finding aids as documents or data  Simplification  To eliminate unnecessary complexity  To make implementation easier  Improve usability  Enable profiles (schema subsets)  Data-friendly  Implementation-friendly (may or may not be the same as data-friendly)68
  69. 69. Future EAC Development  EAC-CPF Implementation  Review by 2016  Companion EAC standards?  EAC-Functions (EAC-F)?  EAC-Institutions with Archival Holdings (EAC-IAH)?69
  70. 70. EAC- CPF EAC- EAD EAD IAH EAC- F70
  71. 71. EAD EAC- CPF EAC- EAC- F CPF71
  72. 72. EAC- F EAC- F EAC- EAD CPF72
  73. 73. Questions? michael.rush@yale.edu http://twitter.com/mike_rush73

×