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

1,298 views
1,200 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
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,298
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • International, process in place for regular review, turnoverNo representation from Central or South America – something I would welcome
  • -Best practices less critical for EAC-CPF, still necessary for local documentation
  • CSSS=Cascading Style Sheets
  • Disclaimer: Not cover all EAD elements.* Indicates required elements
  • ** Choice of one or the other
  • 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

    ×