society of american archivists council meeting january 27 - 30, … · 2011-01-14 · council vote...

Standards: Adopt EAC-CPF of 4 0111-III-E-1-Stds-EACCPF

Agenda Item III.E.1.

Society of American Archivists

Council Meeting

January 27 - 30, 2011

Chicago, Illinois

Standards Committee:

Request to Adopt EAC-CPF as an SAA Standard (Prepared by: Kathy Wisser and Dennis Meissner)

BACKGROUND

The SAA Standards Committee has reviewed the submission package (see Adoption Proposal appended at the end of this document) from the Encoded Archival Context Working Group, including the XML schema, the tag library, the proposed review and maintenance plan, and the community review comments and requests that the SAA Council vote to adopt Encoded Archival Context – Corporate bodies, Persons, and

Families (EAC‐CPF) as a formal SAA standard. Since its own adoption as an SAA standard in 1996, Encoded Archival Description (EAD), which provides an encoding standard for the full description of archival materials as defined in ISAD(G): General International Standard Archival Description, has lacked a necessary sibling standard to similarly encode rich description of the entities who create or are the subjects of archival materials. The appearance of EAC-CPF, a stable and community-vetted XML schema and tag library, solves this problem by providing a means to fully encode archival authority records as defined in ISAAR(CPF): International Standard Archival Authority Record for Corporate Bodies, Persons and Families.

EAC‐CPF 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. Its primary purpose is to standardize the encoding of descriptions about agents to enable the sharing, discovery, and display of this information in an electronic environment. It supports the linking of information about one agent to other agents to

show/discover the relationships among 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. It supports the exchange of ISAAR (CPF)-compliant authority records.


DISCUSSION

The EAC‐CPF Schema is a standard for encoding contextual information about persons, corporate bodies, and families related to archival materials using Extensible Markup Language (XML). The standard, if adopted, will be maintained by the Society of American Archivists, with its official website (http://eac.staatsbibliothek-berlin.de/) hosted by the Berlin State Library. The EACWG members feel strongly that the hosting of the website by a European agency is advisable to recognize and underscore the international development, status, and significance of the standard.

EAC‐CPF, as an XML vocabulary, is a sibling to EAD and, in future, repositories will presumably utilize the two standards in tandem. The two vocabularies (at least, following the upcoming revision of EAD) understand each other and, in fact, share common elements or mutually reference elements from each other’s schemas. An EAD record may

ingest all or part of an EAC‐CPF record, and vice versa. For this reason, it is appropriate and necessary that both standards be owned and maintained by the same agency. Hence,

the need for formal adoption of EAC‐CPF by SAA.

EAC‐CPF began with a 1998 effort to envision a standard for encoding and exchanging authoritative information about the context of archival materials. This standard would provide a communication and encoding standard for the exchange of authority records based on the ISAAR(CPF) and would parallel the standard for encoding archival record finding aids that was expressed in EAD, which itself provided a communication standard based on ISAAR(CPF)’s companion structural standard, ISAD(G). 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 and their creators. Because 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 in finding and interpreting materials by users and in creating accurate and complete references to such entities by archivists. 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, Australian, and U.S. projects. Informed by


the results that emerged from this test bed, the Society of American Archivists' Encoded Archival Context Working Group was formed in 2007 to carry this work forward to the creation of a stable 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. Prior to the meeting, the EAC Working Group solicited feedback on the beta version from the international archival community. This feedback included twenty separate documents, including significant contributions from the PeopleAustralia project, which had significant experience implementing EAC Beta.

Following the face‐to‐face meeting in Bologna, ongoing work via electronic mail and conference calls continued for another year. The final draft was offered for community review from August to November 15, 2009, and the resulting completed schema was released in March 2010. During the review period, two webinars hosted by OCLC Research were presented in order to reach out to the archival community, expose the structure, and solicit questions and comments. Additional feedback from the PeopleAustralia project and the AFNOR project in France during this review period were invaluable in refining and identifying inconsistencies in the schema and tag library. The stable schema is available for immediate download in 3 versions: WC3 schema language, Relax NG Schema, and Relax NG Schema Compact. It is accompanied by an extensive Tag Library complete with encoding examples, which is also available for immediate download. It is expected that the online tag library will continue to evolve over time to meet the needs of the encoding community. The three schema versions, the Tag Library, and other information resources are available

on the official EAC‐CPF website: http://eac.staatsbibliothek-berlin.de/. RECOMMENDATION THAT the SAA Council adopt Encoded Archival Context – Corporate Bodies,

Persons, and Families (EAC‐CPF) as a formal SAA standard.

Support Statement: SAA’s long-standing support of the EAD standard makes the strongest possible argument for likewise adopting and maintaining the EAC-CPF standard. The standards are two sides of the same descriptive coin (in fact, they share data elements in common), and it is logical that they be supported and overseen by the same agency so that they may evolve in tandem. The EAC-CPF schema has been developed and tested carefully and has passed a rigorous review by an international encoding community. Its developers are committed to seeing rigorous maintenance of the standard.


Fiscal Impact: The immediate cost will be production and printing of the EAC-CPF Tag Library, if the Council and the Publications Board believe that a print version is warranted. Up-front costs may approach $10,000, which is likely recoverable via sales. Future costs would include supporting periodic review cycles, each of which might warrant a hosted meeting apart from SAA Annual Meetings. The EAC Working Group would hope to secure grant funding for any such meetings.

Encoded Archival Context – Corporate Bodies, Persons, and FamiliesWisser

1

Encoded Archival Context – Corporate Bodies, Persons, and Families Katherine M. Wisser, EAC Working Group Chair September 2010 For consideration by the Standards Committee Summary The Encoded Archival Context Working Groups seeks full adoption of the EAC‐CPF Schema as a formal SAA standard and the creation of a Technical Subcommittee for Encoded Archival Context to maintain and periodically review EAC‐CPF. Archival description includes information about the content, intellectual and physical attributes of the material, as well as information about the context of their creation and use. The context of the creation and use of material is 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 agents responsible for the creation or use of material, usually organizations, persons or families. With information about these agents, users can understand and interpret the records more fully since they will know the context within which the agents operated and created and/or used the material. Archives have traditionally treated contextual information about agents as a component within descriptive approaches that fully integrate contextual information into descriptive products. However, current strategies emphasize 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. Its primary purpose is to standardize the encoding of descriptions about agents to enable the sharing, discovery and display of this information in an electronic environment. It supports the linking of information about one agent to other agents 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. It supports the exchange of ISAAR (CPF)1 compliant authority records. The EAC‐CPF Schema is a standard for encoding contextual information about persons, corporate bodies, and families related to archival materials using Extensible Markup Language (XML). The standard is maintained by the Society of American Archivists. Its official website (http://eac.staatsbibliothek‐berlin.de/) is hosted by the Berlin State Library. EAC‐CPF, as an XML vocabulary, is a sibling to EAD, and in future repositories will presumably utilize the two standards in tandum . The two vocabularies (at least, following the upcoming revision of EAD) understand each other and, in fact, share common elements or mutually reference elements from each other’s schemas. An EAD record may ingest all or part of an EAC‐CPF record, and vice versa. For this reason, it is appropriate and necessary that both standards be owned and maintained by the same agency. Hence, the need for formal adoption of EAC‐CPF by SAA. Its official website (http://eac.staatsbibliothek‐berlin.de/) would continue to be hosted by the Berlin State Library.

1 http://www.icads.org.uk/eng/ISAAR(CPF)2ed.pdf


2

Background EAC‐CPF began with a 1998 effort 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), which itself provided a communication standard based on ISAAR(CPF)’s companion structural standard, ISAD(G). 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 in finding and interpreting materials by users and in creating accurate and complete references to such entities by archivists. 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, Australian, and U.S. projects. Informed by the results that emerged from this test bed, the Society of American Archivists' Encoded Archival Context Working Group was formed in 2007 to carry this work forward to the creation of a stable 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. Prior to the meeting, the EAC Working Group solicited feedback on the beta version from the international archival community. This feedback included twenty separate documents, including significant contributions from the PeopleAustralia project which had significant experience implementing EAC Beta. Following the face‐to‐face meeting in Bologna, on‐going work via electronic mail and conference calls continued for another year. The final draft was offered for community review from August to November 15 2009, and the resulting completed schema was released in March 2010. During the review period, two webinars hosted by OCLC Research were presented in order to reach out to the archival community, expose the structure, and solicit questions and comments. Additional feedback from the PeopleAustralia project and the AFNOR project in France during this review period were invaluable in refining and identifying inconsistencies in


3

the schema and tag library (see Appendix for sample comments). The Working Group is indebted to archivists throughout the international community for their input, review, and testing of the schema during its development phase. Input from the archival community:

1. Initial survey request on EAC Beta (see Appendix A for a sample of responses) 2. Report at 2008 and 2009 SAA Annual meetings in Standards Committee, EAD Roundtable, and

Description Section (reports given by Chair or substitute Working Group member). 3. Review period, August 21, 2009 through November 15, 2009 (See Appendix B for a sample of

responses). 4. Webinars presented to international audiences: October and November 2009 (151 of registrants

(multiple participants could be at 1 registration site)) 5. Final release of schema and tag library, March 5, 2010

Email lists were utilized as primary vehicles for dissemination. Working Group members were asked to distribute announcements to all relevant lists. Those lists include: A&A (SAA), EAD, aus‐archivists, can‐notices (collections Australia Network), DIGLIB (IFLA), TASI Mailing list, EPIDOC, DC‐ARCHITECTURE, Marc 21 Formats, METS, MIX, MODS, JISC‐Repositories discussion list, Metadata librarians, Humanist Discussion Group, XML4Lib, FRBR, archives‐nra (United Kingdom), scot‐arch (United Kingdom). Release Announcement to Community: March 5, 2010: The EAC‐CPF Working Group (EACWG) is pleased to announce the public release of the EAC‐CPF 2010 version of the schema and tag library for Encoded Archival Context‐Corporate Bodies, Persons, and Families. The new standard provides an XML vocabulary to enable encoding and communicating archival authority records created according to the rules promulgated in ISAAR‐CPF, and it is intended to facilitate content‐rich authority records that can interoperate in a global environment. EAC‐CPF 2010 results from work over the past 30 months by a 15‐member working group representing 9 countries. Their work has been supported by the Society of American Archivists, Staatsbibliothek zu Berlin, Archivio di Stato di Bologna, the Instituto per i Beni Artistici, Culturali e Naturali della Regione Emilia‐Romagna, and by generous funding from the Delmas Foundation. The Working Group benefitted from extensive input from the international archival community throughout the review process of the draft schema in late 2009. The stable schema is available for immediate download in 3 versions: WC3 schema language, Relax NG Schema, and Relax NG Schema Compact. It is accompanied by an extensive Tag Library complete with encoding examples, which is also available for immediate download. It is expected that the online tag library will continue to evolve over time to meet the needs of the encoding community. The three schema versions, the Tag Library, and other information resources, are available on the official EAC‐CPF website: http://eac.staatsbibliothek‐berlin.de/. The international standard is jointly supported by the Society of American Archivists and the State Library of Berlin. Please contact Kathy Wisser ([email protected]), Chair of the EACWG, if you have questions.


4

Encoded examples Fully encoded non‐normative examples are available from the EAC web site at: http://www3.iath.virginia.edu/eac/cpf/examples/list.html The EAC Working Group is continuing to solicit examples from the community in order to better illustrate the tag library and provide full examples. Related SAA subgroups & reporting mechanism of EACWG The EACWG has consistently presented reports to related subgroups and committees within SAA’s structure. Reports have been delivered to the Technical Subcommittee on Descriptive Standards (TSDS) of the Standards Committee in 2007‐2009, and at the Standards Committee in 2010. Reports have also been made to the EAD Roundtable, the Description Section, and Metadata and Digital Objects Roundtable during the development period. Consideration for a separate roundtable or email list was discussed among the working group, and it is believed that EAC‐CPF can be folded into the EAD community represented by the EAD Roundtable and the EAD email list. Presentations on EAC‐CPF have been given at SAA’s Annual meeting:

August 2007 “Context Schmontext: Contextual information innovations in archival description” (Description section)

August 2008 “Contextual information and the changing nature of archival description” (EAD@10 Symposium)

August 2009 “The Whole World is Watching: Contextual Information in Descriptive Systems in EAC‐CPF” (Session #711) In addition, a day‐long preconference to DC 2010 was co‐developed with NARA to bring the American archival community together to discuss implementation of the new standard. Time table for development: Date Activity 2007 Charge accepted by the TSDS 2007 Invitations submitted to EAC Working Group members (see list below) 2008 Grant awarded from the Gladys Krieble Delmas Foundation to bring the EAC Working

Group together for a three‐day meeting to establish the foundation of the new standard

2008 Support received from the IBC; June 2008 Meeting in Bologna, Italy 2009 EAC Working Group Charge revised and accepted by TSDS August 21, 2009 Penultimate draft submitted for review with the archival community October 8, 2009 Webinar, OCLC Research (East coast and European communities) – 96 participants November 3, 2009

Webinar, OCLC Research (Pacific Rim and Australia) – 55 participants


5

November 15, 2009

Review period closed

March 5, 2010 Schema is released EAC Working Group membership

• Anila Angjeli, Bibliothèque nationale de France (National Library of France) • Lina (Vasiliki) Bountouri, Ionian University • Karin Bredenberg, Riksarkivet (National Archives of Sweden) • Basil Dewhurst, National Library of Australia • Wendy Duff, University of Toronto, Faculty of Information • Hans‐Jörg Lieder, Staatsbibliothek zu Berlin (Berlin State Library) • Dennis Meissner, Minnesota Historical Society • Per‐Gunnar Ottosson (†), Riksarkivet (National Archives of Sweden) • Victoria Peters, University of Strathclyde • Daniel Pitti, University of Virginia, Institute for Advanced Technology in the Humanities • Chris Prom, University of Illinois at Urbana‐Champaign • Jennifer Schaffner, RLG Programs (OCLC Programs and Research) • Bill Stockting, British Library • Stefano Vitali, Soprintendenza archivistica per l’Emilia‐Romagna

(Bologna) • Kathy Wisser, Chair, Simmons College, Graduate School of Library and Information Science

Maintenance and Review Plan If EAC‐CPF is approved by the Standards Committee and adopted by SAA Council, the Standards Committee would form a Technical Subcommittee for Encoded Archival Context (TS‐EAC). The maintenance and review of EAC‐CPF will follow the pattern established by the Encoded Archival Description community and documented on the SAA website under “Technical Subcommittee for Encoded Archival Description (EAD).” The model established there calls for the creation of a technical subcommittee which is charged every five years by the SAA Standards Committee to maintain, revise and develop the standard. The proposed composition of the TS‐EAC would be at least five SAA members as well as significant international representation. Council will appoint co‐chairs for TS‐EAC, one a member of SAA and the other from among its international members. Ex officio members of the technical subcommittee could include: chair of the Standards Committee, chair(s) of TS‐EAD, chair of the Schema Development Team, chair of the EAD Roundtable, and a liaison from OCLC Research. TS‐EAC will report at least annually to the chair of the Standards Committee at the annual meeting and will provide any additional reporting required to the SAA office. In addition, they will report to the membership at various venues during the annual meeting, including the Description Section and EAD Roundtable. Generally, work will be conducted via electronic mail and conference calls. TS‐EAC shall meet at the SAA annual meeting in conjunction with TS‐EAD, and those meetings will be open to the public. Additional


6

funding for face‐to‐face meetings outside of the annual meeting will be sought either from SAA or from external sources (with prior approval from the SAA Council) where necessary.

Appendix A: Sample of comments from survey regarding EAC Beta

• AFNOR Introduction & comments • Dennis Meissner, Minnesota Historical Society • People Australia Project, National Library of Australia • Ilaria Barbanti, EAC beta version comments, Survey of EAC Use in Italy • Giovanni Michetti, Stella Di Fazio, and Chiara Veninata, EAC Beta standard: review

Appendix A: Sample of comments from survey regarding EAC BetaAFNOR Introduction

In order to respond to the call for comments in a most efficient way, the AFNOR French group of experts in Authority Data (AFNOR CG46/CN 357/GE 4 : Données d'autorité) has charged me to centralise and transmit the comments coming from different experts and organisations. You'll find attached two documents representing the work being done to gather and formulate the comments : 1) Re‐examination and update of the comments the group has already addressed in September 2006, when the French translation of the Tag Library of the EAC DTD, beta version (august 2004) was published. Since September 2006 implementations of EAC in archival describing systems have been carried out in France and the implementers’ opinion was that some of the comments we sent at the time the French translation was published were to be revised. The group decided to send an updated version of these comments. Attached the updated version of these comments: 2) Formulation of additional comments Implementation as well as training experiences have revealed other problems with the EAC DTD. The group decided to address comments on those other problems in a separate document. These comments come form people from different organisations in France, involved in projects of implementing the DTD EAC for the description of the creators of archives. Attached the additionnal comments: We find it also useful to give the names of experts and organisations having contributed to the formulation of these comments. Among them you’ll find archivists having implemented EAC in their archival description systems, software developers and archivists teaching the implementation of the EAC in archival systems. Experts having contributed with comments: Florence Clavaud Archivist and software developer. She has a double experience with the implementation of the EAC, as developer of the EAC based application ETANOT (see below) and as a software developer having developed the EAC module of PLEADE publishing tool (see below) which has been implemented by the Direction des Archives de France but also by the National Archives of Overseas at Aix‐en‐Provence (see below). Claire Sibille Archivist with experience in implementing EAC for the description of the creators of archives hold by the Direction des archives de France, and teaching EAC in training courses for archivists. André Brochier Archivist with experience in archival authority records within the finding aids of the Archives of Overseas at Aix‐en‐Provence: export into EAC of authority records. Yoric Schleef Archivist with experience in developing EAC archival records for the Archives départementales du Finistère.

1

AFNOR/CG46/CN357/GE4 Données d’autorité (French experts group working on Authority Data) In order to respond to the call for comments of Kathy Wisser, our group has proceeded to a re-examination of the comments we had attached to the French translation of the Tag Library of the EAC DTD, beta version (august 2004) published in September 2006 and available at <http://www.archivesdefrance.culture.gouv.fr/fr/archivistique/index.html>. The same comments were addressed directly to Daniel and Claire Sibille sent them also through the EAD list. Since September 2006 implementations of EAC in archival describing systems have been carried out in France and the implementers’ opinion was that some of the comments we sent at the time the French translation was published were to be revised. The following represent a revised and updated version of those comments.

Comments on the Tag Library of the EAC DTD, beta version (august 2004)

Updated version, November 2007

General comments

Distribution of the roles between the EAD DTD and the EAC DTD The presence of some elements and attributes containing information which should occur only in the EAD DTD is unjustified in the EAC DTD. Some of them seem to have been imported from the EAD DTD by a copy/paste processing, thus causing redundancies and inconsistencies in the EAC DTD. The respective role of each DTD does not seem to have been clearly defined. Emphasis should be put on the complementary relationship of both DTDs and its consequences:

- Limit the EAC DTD to information concerning persons, families and corporate bodies. It shouldn’t include information about documents, the description of which falls within the scope of the EAD DTD

- Clarify and homogenize the links between EAC instances on the one hand, and between EAC and EAD instances on the other hand. Currently the patterns vary depending on whether the starting point is an EAD instance or an EAC one.

- Nevertheless, it may be sometimes useful to include information about archival documents and repositories in EAC instances even if this should not be the general rule. (see specific cases below). The documentation should be very explicit about the distinct roles of EAD and EAC and insist on the fact that for practical purposes it may be sometimes allowed to use elements such as <unittitle> or <repository> in EAC instances but that this is not strongly recommended. In the process of revision of EAC, the EACWG should think in terms of information being managed by different standards, schemes, models which have to be linked to each other and which work as separate parts of the same conceptual system.

Technical solutions in the description of an element <archref>, <bibref>, <extptr>, <extref>, <ptr>, <didentifier>, <title> A section in the description text of each of these elements deals with a link technique: “While XML Linking Language (XLink) Version 1.0, which is the basis for EAC linking elements is stable, examples of EAC usage are hypothetical and have not been tested in real XLink-based applications. Those wishing to use XLink are encouraged to consult the specification available online at http://www.w3.org/TR/xlink/.” These technical aspects should be mentioned in a note or even removed from the Tag Library.

2

Elements and attributes inappropriate in the EAC DTD: to be withdrawn from the DTD

Elements

Elements coming from the element <did> of the EAD DTD and appearing in the element <archunit> of the EAC DTD

<abstract> At present this element has two uses in the EAC DTD:

1. provide “…a very brief summary of related archival materials described in an archival reference to an EAD instance.” (this belongs to the scope of the EAD DTD)

2. “Used primarily to encode bits of biographical or historical information about the creator”: this kind of information is already given by other EAC tags, notably <bioghist>.

<container>, <materialspec>, <physdesc> et and its elements (<extent>, <dimensions>, <physfacet>, <genreform>) An EAC instance should not provide detailed physical information about the archival materials described in the EAD instance that is associated with it. <langmaterial> An EAC instance should not provide detailed information about the language of the archival materials described in an EAD instance associated with it. The reference to ISAD(G) is irrelevant. <origination> This tag represents a duplication of information within the same EAC instance. This information is already present in the element <identity>. <repository> An EAC instance should not include information about the institution that is responsible for providing intellectual access to the materials described in an EAD related instance; neither should it include information about the place where those materials are stored. This piece of information should be processed in an EAD instance. However, it may be assumed that this kind of information is allowed to be recorded in some cases in an EAC instance. See general comments above. <physloc>, <subarea> An EAC instance should not include information about the institution that is responsible for providing intellectual access to the materials described in an EAD related instance; neither should it include information about the place where those materials are stored <unitdate> An EAC instance should not provide detailed information about the date the archive described in an EAD instance was created (modified, etc.). The reference to ISAD(G) is irrelevant. <unitid>, <unittitle> An EAC instance should not provide detailed information about the title, the location or the classification number of the materials described in an EAD instance. The reference to ISAD(G) is irrelevant. However, it may be assumed that this kind of information is allowed to be recorded in some cases in an EAC instance. See general comments above.

Other elements borrowed from the EAD DTD <subject> An EAC instance should not provide detailed information about the topics associated with or the entities covered by the materials described in an EAD instance. <bibseries> and its elements (<title>, <imprint>, <edition>)

3

An EAC instance should not provide “Information about the published series in which a book, encoded finding aid, or other published work has appeared.” However, it may be assumed that this kind of information is allowed to be recorded in some cases in an EAC instance. See general comments above.

Attributes ROLE With the proposed definition: “A contextual role or relationship for the person, family, corporate body, or geographic location within <persname>, <famname>, <corpname>, <geogname>, and <name> elements”, the ROLE attribute is not relevant within the EAC DTD. UNIT This attribute is used in the elements <extent>, <dimensions>, <physfacet> which we suggest should be removed. It is irrelevant in the EAC DTD.

Missing information, inconsistencies and issues needing clarification In order to respect the complementary relationship between the EAC DTD and the EAD DTD the developers of the EAC DTD are invited to consider: - using identical tags to encode information of the same nature in the two DTDs;

Examples: <geogname> (EAD) and <place> (EAC) <processinfo> (EAD) and <maindesc> (EAC)

- naming identical tags the same way in the two DTDs. Examples: <extptr> Extended pointer (EAD) / External pointer (EAC) <extref> Extended reference (EAD) / External reference (EAC)

Elements <altdate> - In the Tag Library the NORMAL attribute is mentioned in the description of the element <altdate> ; add this attribute in the list of the attributes applicable to this element. In the DTD make it available for this element. - Broadly speaking, this element should have the same attributes as the element Date <date>. <archunit>, <bibunit>, <musunit> In the Tag Library there is inconsistency in the wording of the names of these elements (Archival unit, Bibliographic description, Museum description). Given their similarity as to their purpose and scope, the wording should be consistent. <bioghist> May occur within <desc>. It should be equally allowed to occur within <persdesc>, <corpdesc> and <famdesc>. Add in the list of the “May occur within” of the elements <persdesc>, <corpdesc> and <famdesc>. <corpdesc> In the description of this element in the Tag Library the element <value> is mentioned as occurring within <funactdesc>, <assetstruct>, <env>, <location>, <causa>. In fact the element <value> may be contained within the <descentry> and <legalstatus> elements only. The description of the sub-elements of <corpdesc> should be revised. See also our comment about <persdesc> and <famdesc> <corphead>, <pershead>, <famhead>, <eacrel> In the Tag Library, the HEADTYPE attribute is mentioned in the description of these elements. Add this attribute to the list of the attributes applicable to these elements. Create it in the DTD and make it available for these elements. <date> In the Tag Library the CERTAINTY attribute is mentioned in the description of the element Add this attribute to the list of the attributes applicable to this element. Create it in the DTD and make it available for this element. <existdate>

4

The definition of this element in the Tag Library should be completed as follows: “Use <existdate> within the context of <existdesc> for the dates of existence of a corporate body and the life dates of a person, or the dates of usage of a form of name for the entity.” <famdesc> In the description of this element in the Tag Library the element <value> is mentioned as occurring within <funactdesc>, <assetstruct>, <env>, <location>. In fact the element <value> may be contained within the <descentry> and <legalstatus> elements only. The description of the sub-elements of <famdesc> should be revised. See also our comment about <persdesc> and <corpdesc> <funact> The <funactrels> element is mentioned in the description of this element. The <funact> element may be contained within the <funactrel> element and not within <funactrels>. Replace <funactrels> by <funactrel>. (The replacement was made in the French translation.) <head01>, <head02>, <head03> when contained in <chronhead> When this tag is used within <chronhead> for the dates which may occur in the second or third column, the name Head One <head01> may be confusing. Why not have separate tags for the designation of columns especially dedicated to dates, events, and places? (e.g.: such tags as: <headdate>, <headevent>, <headplace>)? <language> - The <language> element covers two distinct notions: language and script. Those two distinct notions should not be recorded in a single tag. Create a specific tag for the script, for example <script>. - This comment applies to the EAD DTD as well. - The notion of “multilingual authority record” is unclear. What is multilingual: the headings, or the descriptive part of the EAC instance? <legalstatus> In ISAAR(CPF) the descriptive element “Legal status” applies to corporate bodies only. In the EAC DTD this element applies equally to families and persons. What does “legal status” mean when applied to a person or a family? The use of this element in the EAC DTD should be consistent with ISAAR(CPF). <nameadds>, <nameadd> - The respective roles of each of these elements should be specified. - The example chosen in the description of <nameadds>: “Common additions generally reflect characteristics of the described entity rather than a characteristic of a particular form of name, for example, dates of existence or place” is ambiguous. <note>, <descnote> - What is the difference between these two elements? - The list of the elements: “May occur within” is different for each of these elements. Drop one of these elements in favor of the other. - What does “associated entry” refer to in the sentence: “For additional descriptive information of an associated entry use descnote”? <persdesc> In the description of this element in the Tag Library the element <value> is mentioned as occurring within <env>, <location>, <funactdesc>, <character>. In fact the element <value> may be contained within the <descentry> and <legalstatus> elements only. The description of the sub-elements of <persdesc> should be revised. See also our comment about <famdesc> and <corpdesc>. <sourceref>, <source> - Specify the respective roles of these two elements. <sourceref> is self-referring!

Attributes AUDIENCE Missing from the list of the attributes at the end of the Tag Library. Should be added to the Tag Library and the DTD.

5

CALENDAR Make the content of the CALENDAR attribute in the EAC DTD identical to that defined in the EAD DTD. CERTAINTY Missing from the list of the attributes at the end of the Tag Library. Should be added to the Tag Library and the DTD. COUNTRYCODE Define the COUNTRYCODE attribute as a simple country code without any additional precision (this comment applies to the Tag Library of the EAD DTD as well). In the DTD make it available for the elements <location> and <place> as well. ENCODINGANALOGSYS and ENCODINGANALOG Both these attributes should be of the type NMTOKENS and not NMTOKEN. The simultaneous assignment of more than one value, for the purpose of mappings between different formats (Dublin Core, Unimarc, Marc 21, etc.), becomes thus possible. HEADTYPE Missing from the list of the attributes at the end of the Tag Library. Should be added to the Tag Library and the DTD. LANG Missing from the list of the attributes at the end of the Tag Library. Should be added to the Tag Library and the DTD. SYSTEM The sentence: "The value of SYSTEM must by an entity declared…" seems incomplete. TARGETOUT The definition of this attribute is not clear: “The name of a nonparsed entity declared in the declaration subset of the document that points to a machine-readable version of the cited reference.” <list>, CONTINUATION - In the description of the element <list>, the following sentence is not clear: “While “starts” is also a value option, “starts” is implied when the CONTINUATION attribute is absent” The wording that was used for the CONTINUATION attribute seems preferable. - The “start” value of the CONTINUATION attribute is useless.

Editorial comments and list of errors Writing conventions need to be defined at the beginning of the DTD. For example: there is no consistency in the rendition of the attributes through the Tag Library. If in the section Attributes of each tag, lower case characters are used, in the text itself the names of the attributes are written in upper case characters and in the chapter dedicated to attributes the form “@attribute” is used. Use the same conventions as in the Tag Library of the EAD DTD, i.e. the name of the attribute is always in upper case characters wherever it occurs, be it in the definition of the tag, in the Attributes section of each tag or in the section dedicated to the attributes.

Elements <eacheader> The attributes LANG and SCRIPT mentionned in the description of the <eacheader> element do not exist in the EAC DTD. Replace by LANGUAGECODE and SCRIPTCODE. <num> The sentence “In general, such encoding is not necessary.” should be deleted. <env> Add the reference: ISAAR(CPF), 2nd edition: 5.2.8 General context. (The addition was made in the French translation.) <item>

6

The elements <defitem> and <change>, mentioned within the element <item>, are not described in the Tag Library, and they are not available in the EAC DTD either. This part of the text is just a copy/paste of the presentation text of the element <item> in the EAD DTD. Reference to these elements was omitted in the French translation. <language> Why should the statement of language be given twice: once in textual form (in natural language) within the <language> tag, and once in a coded form by using the values of the attributes LANGUAGECODE and SCRIPTCODE? Preference should be given to the coded form, which can be converted by automatic processing into any language. This task may be supported by stylesheets or other appropriate technical devices. <languagedecl> The reference to ISAAR (CPF) is erroneous. Fix 5.4.6 into 5.4.7. (The reference was fixed in the French translation.) <ocd> The reference to ISAAR (CPF) is erroneous, paragraph 5.2.9 does not exist in the final version of the standard (although it existed in the draft version of ISAAR(CPF)). (The reference was omitted in the French translation.) In the descriptive texts of the elements <ptr> and <ref> in the Tag Library, the following elements are mentioned:

Extended Pointer Location <extptrloc>, Extended Reference Location <extrefloc>, Pointer Location <ptrloc>, Reference Location <refloc>, Link Group <linkgrp>, Pointer Group <ptrgrp>,

But these elements are neither described in the Tag Library nor available in the EAC DTD. This part of the text is just a copy/paste from the presentation text of the element <ptr> in the Tag Library of the EAD DTD. (Reference to these elements was omitted in the French translation.)

Attributes Just like in the Tag Library of the EAD DTD it is advisable to categorise the attributes according to their function: - general attributes - linking attributes - tabular display attributes. The definitions for the attributes should be withdrawn form the descriptive texts of the elements in the Tag Library. For example, the attributes LANGUAGECODE and SCRIPTCODE are defined within the description of the element <language>, and again in the part of the Tag Library devoted to attributes. ALIGN The phrase: "Available in <colspec> and <entry>." is erroneous, as ALIGN is also available in the <tgroup> element. CALENDAR The phrase: "Available in <existdate>, <date> and <usedate>." is erroneous, as CALENDAR is also available in the elements <maindate> and <unitdate>. CHAR, CHAROFF, COLNAME, COLNUM, COUNTRYCODE, NORMAL, RENDER, TYPE The phrase: "Available in …" is useless since the list of the elements in which those attributes are available is provided in the specific section "Used on:". COUNTRYENCODING Replace <eadid> with <eacid> in the sentence: "The authoritative source or rules for values supplied in the COUNTRYCODE attribute in <eadid> and <unitid>." (The replacement was made in the French translation.) LANGENCODING

7

Replace EAD with EAC, and <eadheader> with <eacheader> in the sentence: "Language encoding for EAD instances subscribes to ISO 639-2b Codes for the Representation of Names of Languages, so the LANGENCODING attribute value in <eadheader> should be "iso639-2b." (The replacement was made in the French translation.)

Appendix A: Sample of comments from survey regarding EAC BetaDennis Meissner, Minnesota Historical Society

Here are the comments from MHS on EAC Beta. They reflect work done via our Photographers' Biographies project, and come largely from Monica Ralston who directed that project. In no particular order, here they are: 1) The @HEADTYPE that is described as being available for <corphead> in the tag library text is actually missing from both the DTD and tag library. The attribute is truly necessary to express earlier and later forms of a name. It would be equally useful for <persname> and <famname>, and should be available to those elements as well. Perhaps EACWG should consider establishing a closed list of values for the attribute. 2) <corphead>, <pershead>, <famhead> each needs availability of @SYSTEM and @SYSKEY in order to allow for identification of variant national authority files. For example, we may want to use either LCNAF or ULAN to form a name. 3) @EA ought to be changed from NMTOKEN to CDATA. This would permit one to specify MARC21 subfields and indicators as a part of the specific encoding analog, where appropriate. And, a picky point: why is the attribute not named @ENCODINGANALOG as it is in EAD? Since EAD and EAC are sibling standards, would it not be helpful down the road for them to use the same names to indicate identical functions? I would think it might aid interoperability, and would certainly aid understanding. 4) An ultra-picky point, that may never be of interest or utility to anyone but us (it came up at several points in the photographers' directory): When the @TYPE is used with <eacrel>, it seems to allow only a one-dimensional relationship: it is either one thing or it is another thing; it cannot be many different things. In our Photographers' Directory database, for example, one person may have at various times been a predecessor, partner, competitor, spouse, and bitter-ex-spouse of a particular second person. Probably not worth carrying forward. I'll be happy to explain these further, as necessary. And I'll be pulling together my part of the D-Lib submission over the next several days. Happy Thanksgiving!, Dennis ========================================= Dennis Meissner, Head of Collections Management Minnesota Historical Society <www.mnhs.org> Voice: 651.259.3350 ::: Fax: 651.296.9961 eMail: [email protected] =========================================

Appendix A: Sample of comments from survey regarding EAC Beta People Australia Project, National Library of Australia

C:\Users\wisser\Documents\EACWG\standards committee\sample3.doc

People Australia Project Document History Version Date Prepared by CommentsWD1 5 Mar 07 Bemal Rajapatirana WD2 30 Apr 07 Bemal Rajapatirana Created detailed MARC21 to EAC (beta) mapping in separate document. Current document

provides complete mapping of EAC to MARC21 and high level mapping from MARC21. Mapping may require extension with further analysis of data sources.

WD3 22 May 07 Bemal Rajapatirana Data model document substantial modifications: 1. Removed mappings to separate documents 2. Introduced <eacgrp> elements 3. Notation for expressing elements and subelements has been modified to shorten document

WD4 28 Jun 07 Bemal Rajapatirana Re-edit and additional content for DATA MODEL section. PePO group identifier expressed Additional attribute value of “isNot” added to RELTYPE; Added EAC schema overview picture

DATA MODEL Encoded Archival Context (EAC) has been chosen as the preferred schema for the PePO (People Australia) data model.

EAC is a standard for encoding 1”information relating to the circumstances of record creation and use, including the identification, characteristics, and interrelationships of the organizations, persons, and families who created, used, or were the subject of the records”. The Toronto Tenets: Principle and Criteria for a Model for Archival Context Information was the foundation document for the development of EAC and indicates that EAC will serve as the means for “the identification and characteristics of the persons, organizations, and families who have been the creators, users, or subjects of records, as well as the relationships amongst them” and that “the model is also intended to support the exchange and sharing of context information, especially in those instances where repositories have holdings or interests that have context information in common, especially about creators or subjects of records”. EAC is defined in a document type definition (DTD) that is compatible with both Standard Generalized Markup Language (SGML) or extensible markup language (XML). It is intended to extend and complement Encoded Archival Description (EAD).

1PEARCE-MOSES, R 2005, A Glossary of Archival and Records Terminology, viewed 20 May 2007, <http://www.archivists.org/glossary/term_details.asp?DefinitionKey=1660>



EAC was chosen as the preferred schema for the following reasons.

• EAC is a rich schema capable of expressing a range of characteristics about the entities of interest and their relationships with other topics and resources. With this richer schema the services that are immediately relevant to People Australia can be supported. The comprehensiveness of the schema makes it possible to support a relatively complete mapping from other data schemas to EAC with minimal loss of data.

• It has the potential to be extended. No existing schema can be used without modification, however with EAC it is possible to combine elements and attributes to extend the scope and detail of the schema to support PePO and potentially other services reliant on people or organizational data. PePO extensions will be forwarded to the EAC Working Group (EAC WG) with a view to further developing the schema. In the interim the EAC PePO profile will be established to meet the requirements of the PePO service and its data contributors.

• EAC is used by a number of the contributors for People Australia and some key agencies such as Austech and the National Archives of Australia have an active role in the EAC WG (http://www.library.yale.edu/eac/members.htm). Note that, though highly desirable, data contributors may provide their files using other schemas and are not required to provide their data in EAC.

• Official support and maintenance. The beta version is currently under the editorial control of the EAC WG with support from Yale who hosts the EAC site. The expectation is that support will continue through a formal maintenance agency as is the case with EAD which is maintained by the Library of Congress. This removes the burden for the National Library to be the sole maintenance agency for a local schema such as MAPS.

The beta version, released in 2003, includes most of the data elements required for People Australia. Other schemas for describing people and organisations were examined including MARC21 Concise Format for Authorities (http://www.loc.gov/marc/authority/ecadhome.html), MADS (Metadata for Authority Description http://www.loc.gov/standards/mads/), Interparty (http://www.interparty.org/interparty/index.asp?), DCMI Agents Working Group Functional Requirements for Describing Agents (http://www.dublincore.org/groups/agents/agentFRdraft2-2.html) and MAPS (Music Australia Party Schema http://www.musicaustralia.org/schemas/maps/maps-v1.1.xsd).

The simpler schemas such as Interparty or DCMI Agents share similar shortcomings. They lack published schema or user documentation and have a limited number of elements which narrows the scope of their application and limits the type of data that can be recorded about entities. For example there is limited or no facility to express relationships between entities or between entities and associated works, descriptive data is held in unstructured notes elements making it difficult to mine and expose explicitly, and biographical data is not supported.

Richer schemas like MARC21 and MADS support more of the information of interest to the general public or researchers. However, MARC holds firmly to the concept of establishing and justifying an authoritative name so though variants (both authorised and unauthorised) are supported there is limited ability to express the type of variant (e.g. pseudonym, toponym, patronym). MARC also lacks important data elements such as location, place (birth, death, activity), address, affiliation, field of activity, associated works, gender, etc. Where more detail is supplied it is often subsumed in notes fields that reduce both the visibility and usability of the data. Though MARC contains a field for biographical data the instructions for its’ application leave little room for optimism about the extent or depth

of information recorded. Essentially the field is used for a ‘brief statement…’ or ‘summary of the essential biographical …information’. Although MADS attempts to extend the scope of the MARC21 model by including elements like field of activity and affiliation, it basically repeats the limitations inherent in MARC21.

Of the current data schemas for people, MAPS and EAC include most of the desired fields. Though MAPS is a comprehensive schema possessing some elements that should be incorporated in any chosen data model it is a local schema derived for a particular purpose and lacks granularity, extensibility and some elements that EAC supports. For example the MAPS record information element omits data about record status and level of detail, and MAPS has no mechanism for expressing relationships between entities and their associated works. EAC had been rejected as a schema at the time MAPS was established because it was in a beta version and was seen as too complex for data contributors. However MAPS was influenced by EAC and adopted a number of EAC conventions which are reflected in the overlapping semantic structure between the two schemas. The similarity between the two schemas will also make mapping MAPS to EAC relatively straightforward.

ISSUES The key issues with EAC are:

• There is no lossless mapping from this schema to the other major data schemas. Any data imported from contributors that do not deploy EAC cannot be exported in tact (as provided). For example, it would be expected that with EAC being the richer schema it would define elements that cannot be supported in MARC21 (yet) but it is also evident that MARC21 contains elements (i.e. coded data) that cannot be expressed in EAC. It may be possible to use the 2EA attribute to support elements from other schemas, or the alternative is to retain the original record as contributed (XMLised if possible) within the <eacgrp> element. However, it is also recommended that the ability to export without loss is not a service requirement.

• The schema is complex and at times quirky. It attempts to cover content encoding as well as format and stylistic requirements. It can also be repetitive and recursive though this offers flexibility in how certain information can be expressed, for example, providing the option to include data as additional descriptive information about an entity or to use that same data to differentiate between very similar entities. In order to record and represent they desired types of contextual information for people and organisations the schema chosen has to be comprehensive and this sometimes introduces complexity. The complexity of the schema can be mitigated by constructing user documentation and mapping tools for those contributors using simpler schemas (for example Dublin Core), and also by defining a minimal level standard. It may also be possible to establish a lightweight PePO profile that can be readily converted to the full version. Also as noted above, contributors will not be required to contribute data in EAC.

• The schema does not contain an audience flag or any type of privacy element or attribute. Any service that stores and disseminates data about people must have the capacity to flag data that should not be viewed publicly (e.g. birth dates, contact details, kin/clan names, superseded biographical excerpts) or that can only be viewed by a particular class of users. There may also be additional requirements to specify a release date when legally sensitive data can be viewed or made publicly available (for example a FOI attribute). Note that the schema does support expression of a relationship between a person’s

2 Seeking clarification from the EAC WG members on use of the EA attribute which enables recording a field or element in another descriptive encoding system to which an EAC element is comparable.

public identity and the real person, including instances where a person may have more than one official 3public identity. However it is not yet clear if People Australia has this requirement to distinguish and differentiate between a public identity and the real person.

• Application of the TYPE attribute is inconsistent. Sometimes TYPE has a defined list of values (EAC refers to these as ‘closed lists’) but TYPE is generally not defined. TYPE can be modified by two other attributes, TYPEAUTH and TYPEKEY that can reference an authoritative list (e.g. a thesauri) from which the TYPE value is derived. The intent is to control semantic extensions of EAC-specific descriptive elements however the rationale for why some TYPE attributes have closed definitions and others are extensible is not clear. Furthermore some key elements, for example the root element <eac>, do not have a TYPE extension mechanism. It may be that the schema has not been sufficiently exercised to work out appropriate application of this attribute and rules for extension. For now it is proposed that PePO specific extensions are recorded and deployed as required and that our requirements are communicated to the EAC WG members. For elements that do not have ‘closed list’ of EAC defined values, PePO uses existing standards, vocabularies and schemas such as MARC21 and MAPS, or, if these are unavailable any terms found in the EAC tag library definitions. Where possible TYPEKEY and TYPEAUTH attributes will be used in conjunction with TYPE to stem the ad hoc growth of unstructured lists.

• EAC does define some mandatory elements however there is a requirement to test and modify the mandatory elements stipulated below against the prevailing data quality standards evident in PePO contributor data. PePO definitions for minimal level records will also be informed by the work undertaken on the “Mandatory Data Elements for Internationally Shared Resource Authority Records” (http://www.ifla.org/VI/3/p1996-2/mlar.htm#2). Consideration should also be given to a statement of requirements to meet ‘partial’ or ‘full’ standards.

• The EAC definition for organisations does scope entities or topics that might not instantly be recognised as ‘organisations’ e.g. in the EAC tag libraries description of the <corphead> element they indicate that 4“a corporate name is the proper noun name that identifies an organization or group of people that acts as an entity including names of associations, institutions, business firms, nonprofit enterprises, governments, government agencies, projects, programs, religious bodies, churches, conferences, athletic contests, exhibitions, expeditions, fairs, and ships”. Semantic integration of contributor schema definitions will be required to ensure that organisations and or groups are correctly defined and scoped in to the PePO repository.

PePO IDENTITY

An identity may represent people or organisations. This includes any individual or group or combination of individuals acting as a unit.

The model supports variant forms of names by which a person or organisation is known. Variant forms may be any variant to the established forms (e.g. non-Roman script names) or an incomplete piece of an established heading, changes of name over time, such as maiden name or pseudonyms. When a person has more than one heading assigned, it is possible to designate one of the headings as the authoritative or preferred heading. 3 The concept of public identity is from Interparty who scoped only what is public domain information and ruled out of scope metadata that is “Not publicly known” or “Sensitive”. Interparty’s interpretation appears very restrictive, for example they excluded as out of scope biographical data and relationships between real persons and their public identities. 4 http://www.iath.virginia.edu/saxon/servlet/SaxonServlet?source=/eac/documents/tl_beta.xml&style=/eac/shared/styles/tl.xsl#e.corphead



EAC OVERVIEW The diagram below is included to demonstrate the basic structure of EAC and how the various root and standard elements operate. Each box header contains the name of a root element or main element and then lists the key sub-elements for each of these. Elements corralled within the pink dotted lines are optional. All elements names in italics are optional. A brief description and/or definition of each of main element is provided.

Figure 1: Purple and Pink PePO prototype plan

PePO DATA ELEMENTS

The following table specifies the EAC elements, sub-elements and attributes that are supported in the People Australia data model.

Not all EAC elements defined in the beta dtd are included below. The complete Encoded Archival Context beta dtd is available at: (http://jefferson.village.virginia.edu/eac/.) Definitions are primarily derived from the Encoded Archival Context Tag Library available at: (http://www.iath.virginia.edu/saxon/servlet/SaxonServlet?source=/eac/documents/tl_beta.xml&style=/eac/shared/styles/tl.xsl)

Support for the Extended and Non Roman Character Set is assumed. UTF8 will be supported for the character encoding. Data providers must provide data in UTF8 or in a character encoding that can be mapped to UTF8 using standard mapping tables.

In the table below:

Obl = Obligation (M = Mandatory, O = Optional, C = Conditional)

Occ = Occurrence (R = Repeatable, NR = Not Repeatable)

The table is structured into 3 main sections. The first lists the root elements. This is followed by the listing of elements and sub-elements where top level elements are situated in the far left column to convey the basic structure and group sub-elements. Elements are grouped where possible (e.g. <pershead:corphead> ) for brevity. The sub-elements listed within these are applicable to either element. Where elements have non-standard TYPE attribute values (those not defined in EAC) these are listed in this part of the table.

No elements specifically related to the entity “family” have been listed below. In most instances the structure, applicable sub-elements and attributes permitted under “person” can also be used for “family”.

A list of the supported attributes and their supported values are supplied at the end of the table. These attributes are indicated by a preceeding ‘@’ symbol (following the display convention used in the EAC tag library). For some attributes the text ‘Defined values’ is used to indicate terms defined in EAC. In all other cases these values are ‘locally’ derived e.g. from an existing schema such as MAPS or MARC, or a list of terms devised by the PePO team.

Solid and dotted lines have been used as a visual aid to indicate the boundaries of each container element.

Top level elements EAC xpath Obl Occ Datatype

Length

Form

Definition

Root elements

<eacgrp> <eacgrp> Attributes: type Defined TYPE values: disparate, identity, related

O NR Char Var Text Root element of a document containing two or more EAC instances. Three types of EAC groups can be designated: disparate: any package of records, linked or not, for the purpose of data exchange identity: a group of different eac records (from different sources) representing the same entity. A common header should then be contained in the condescgrp related: any group of eac instances representing related and linked entities, such as parents and children Key elements are <eacheader> and <condescgrp>. <eacheader> retains the PePO identifier for the group.

<condescgrp> <eacgrp/condescgrp> C NR Char Var Text A container element used only within <eacgrp>. The <condescgrp> consists of two or more EAC instances, and optional elements for identifying the group and its relations.

<eacheader> <eacgrp/eacheader> C NR Char Var Text

Length

Form

Definition

<eac> <eac> Attributes: type Defined TYPE values: corporatebody, person, family

M R Char Var Text Root element of an EAC instance. An EAC instance contains the description of one corporate body, family, or person as well as technical and intellectual information used in the creation, maintenance, and control of the description. Contains two required elements — the<eacheader> and the <condesc>. May occur multiple times in <eacgrp/condescgrp> The TYPE attribute is required to indicate whether the entity being described is a corporate body, person or family.

<eac> elements <eacheader> <eac/eacheader>

Attributes: status; detaillevel; encodinganalogsys; ea; langencoding; scriptencoding; dateencoding; countryencoding; ownerencoding

M NR Char Var Text Header of the EAC record. Contains technical and intellectual information used in the creation, maintenance, and control of the EAC entry. One of two required elements within the EAC schema under the root elements <eac>, <eacgrp>.

<eacid> <eac/eacheader/eacid> Attributes: syskey; system; ownercode; countrycode; type; typeauth TYPE values: superceded, alternative TYPEAUTH: maps

M NR Number

TBD Integer

<eacid> is a unique identifier for the descriptive document within the owning system, accommodates both machine- and human-readable versions of the identifier and is one of two required sub-elements of the <eacheader> The value of SYSKEY will be the PePO persistent identifier. The value of SYSTEM for People Australia will be “PePO” (unless someone challenges me for a better sys name) OWNERCODE is desirable in PePO. If used in conjunction with COUNTRYCODE it makes PePO identifier globally unique. (or so they said in the brochure…)

Length

Form

Definition

<mainhist> <eac/eacheader><mainhist>

M R Char Var Text <mainhist> contains one or more <mainevent> elements documenting events or activities in the maintenance of the EAC instance. It is a required element within the <eacheader> and must contain at least one <mainevent>.

<mainevent> <eac/eacheader><mainhist/mainevent> Attributes: maintype

C R Char Var Text Each <mainevent> may contain additional elements to document a maintenance event or activity. Each <mainevent> has a required MAINTYPE attribute to accommodate one of four possible values: create, update, import, or delete.

<maindate> <eac/eacheader><mainhist/mainevent/maindate> Attributes: calendar; normal

M

R

Char

Var

Text

<maindate> contains the occurrence date of a maintenance event and it may be machine generated or entered manually.

<maindesc> <eac/eacheader><mainhist/mainevent/maindesc>

M

R

Char

Var

Text

Contains a description of a maintenance event which may be machine generated or entered manually.

<name> <eac/eacheader><mainhist/mainevent/name>

M

R

Char

Var

Text

Contains the name of a person or agency responsible for a maintenance event.

<sourcedecl> <eac/eacheader><sourcedecl/source> Attributes: ownercode; id; system; syskey

M R Char Var Text <sourcedecl> occurs within the <eacheader> for specifying the source for evidence used in describing the entity. <source@ownercode> is a mandatory subelement in PePO. It contains codes that identify the contributing agency. SYSTEM and SYSKEY desired for PePO profile. SYSTEM equivalent to ID.

Length

Form

Definition

<languagedecl> <eac/eacheader><languagedecl/language Attributes: languagecode; scriptcode Default LANGUAGECODE value: eng Default SCRIPTCODE value: latn

M R Char Var Text Code

<languagedecl> contains one or more <language> elements representing the predominant language or languages used in the descriptive content of the record. If the descriptive content uses more than one language or script, <language> should be repeated for each language and script pair. For multilingual authority record with headings in different languages or scripts, the languages and scripts used in the heading are to be identified in the attributes LANGUAGECODE and SCRIPTCODE within <pershead>, <corphead> or <famhead>, as appropriate. The natural language name of the language and script should be entered as the content of the element.

<ruledecl> <eac/eacheader><ruledecl/rule Attributes: id ID values: TBD

O R Char Var Text The <ruledecl> contains one or more <rule> elements identifying the descriptive content standard or standards used in creating the EAC instance. When more than one content standard is used, <rule> should be repeated for each. ID is required so that RULE attributes used on <corphead>, <eacrel>, <famhead>, <funactrel>, <pershead>, or <resourcerel> may reference the appropriate standard by means of the ID value. But only when more than one standard is used in creating the EAC instance.

<condesc> <eac/condesc> M R Char Var Text <condesc> consists of groups of elements for identifying and describing a corporate body, person or family. One of two required elements under the root element <eac> which has several complex subelements used to describe different features of the entity:

Length

Form

Definition

<identity> <eac/condesc/identity> M NR Char Var Text Required element that groups other elements to provide both authorized and alternative name headings that identify the entity. Can include other elements that assist in identification of the entity. Name qualifiers that are common to all of the headings can be incorporated into a single <nameadds> directly within <identity>. Qualifying additions to names that are not common to all headings should be recorded in <corphead>,<famhead>, or <pershead>, as appropriate.

<didentifier> <eac/condesc/identitydidentifier> Attributes: role; show, actuate, href, type; typeauth ROLE values: image, moving image, sound, website TYPE values: doi, uri, hdl TYPEAUTH values: TBD

O R idRef Var Text Reference to a resource that will be used as an illustrative image, moving image or sound for a party. EAC defines as: a machine-readable reference to an internet accessible digital portrait or other non-textual digital identifiers of the described entity. An HREF takes the form of a Uniform Resource Identifier (URI). The TYPE attribute within <didentifier> supports additional identifier types. Current values taken from MAPS. Other TYPE values will be evaluated as they are contributed. .

<persgrp:corpgrp>

<eac/condesc/identitypersgrp:corpgrp>

O R Char Var Text The <…grp> elements can be used to associate parallel names in various languages or script forms. The <corpgrp> element can be used to associate parallel corporate names in various languages or script forms. It is optional in PePO.

Length

Form

Definition

<pershead:corphead>

<eac/condesc/identity><persgrp:corpgrp><pershead:corphead> Attributes: rule; type; authorised; typeauth TYPE values: common, nonPreferred, pseudonym, acronym, abbreviation, translation, otherVariant TYPEAUTH values: maps

M R Char Var Text Code

<pershead> contains a heading for the person. A personal name is the name given to an individual, or a name by which he/she is known, consisting of such elements as surname, forename, patronymic, or 5toponym. <corphead> element contains a heading for the corporate body. Name elements can have additional qualifiers so the entities can be identified with certainty, distinguished from others bearing the same or similar names. Elements used both for authoritative and alternative headings. TYPE is used to specify types of names. There is no defined or closed list of values. The current value list is inherited from the MAPS schema.

<part> <eac/condesc/identity><persgrp/corpgrp><pershead:corphead><part> Attributes: type; typeauth TYPE values: surname, forename, familyname, toponym, patronym, *jurisdiction, *subordinate TYPEAUTH values: eac

O R Char Var Text <part> is used to distinguish components of the containing element when this is useful in processing data, or when content rules require components to be discretely encoded. EAC examples indicate that for multiple forenames, each is contained in a separate forename element. However PePO will store 6multiple forenames in the format encoded by contributors (i.e. as multiple or single elements) Other TYPE values will be evaluated as they are contributed. *Only for organisations.

5 Toponyms may not be identified discretely in some data sources. E.g. 100 0 $aCebes,$cof Thebes is tagged as a personal name with additional information. In this example the additional information conveys that the name is a toponym however the data format has no way to express this clearly. The same could apply to patronymics. 6 Some content standards do not separate multiple forenames. So if we retain the principle that we do not deconstruct records unnecessarily then in the following example:

LA NAF heading <datafield tag="100" ind1="1" ind2=""> <subfield code="a">Cogger, Harold G</subfield> would convert to the EAC element: <pershead authorized="ANBD"> <part type="surname">Cogger</part> <part type="forename">Harold G</part> </pershead> BUT NOT to

Length

Form

Definition

<nameadd> <eac/condesc/identity><persgrp/corpgrp><pershead:corphead><nameadd> Attributes: type; typeauth TYPE values: extension, title, termsOfAddress TYPEAUTH values: TBD

O R Char Var Text <nameadd> is used for descriptive or distinguishing information other than date or place added to names within this element. Other TYPE values will be evaluated as they are contributed.

<usedate> <eac/condesc/identity><persgrp/corpgrp><pershead:corphead><usedate>

O R Char Var Integer

Date or dates when the associated name was used by or for the entity. Supported attributes within <usedate> are listed under <existdate>

<existdate> <eac/condesc/identity><persgrp/corpgrp><pershead:corphead><existdate> Attributes: scope; form; calendar; normal; era

O R Number

Var Integer

Dates of existence for the entity being described, such as dates of establishment and dissolution for corporate bodies, and dates of birth and death or floruit for persons .

<pershead authorized="ANBD"> <part type="surname">Cogger</part> <part type="forename">Harold</part> <part type="forename"> G</part> </pershead>

Length

Form

Definition

<place> <eac/condesc/identity><persgrp/corpgrp><pershead:corphead><place> Attributes: type; valueauth; valuekey; placetype; typeauth TYPE values: birth, death, incorporated, formed TYPEAUTH values: TBD VALUEAUTH values: marcgac, marcountry, iso3166-1

O R Char Var Text Code

<place> element within <identity> is use to record the places of birth and death for individuals, and to some extent organisations. <place> in this context also serves to differentiate or qualify both name and corporate headings. <place> in this context is used as a qualifying element to differentiate or disambiguate persons or organisations bearing the same name. PePO will support this usage when it occurs in contributor data. Other TYPE values will be evaluated as they are contributed. Other VALUEAUTH values will be evaluated as they are contributed.

<sourceref> <eac/condesc/identity><persgrp/corpgrp><pershead:corphead><sourceref>

O R Char Var Text <sourceref> contains a reference to the resource providing evidence for the heading or descriptive element container.

<sourceinfo> <eac/condesc/identity><persgrp/corpgrp><pershead:corphead><sourceref/sourceinfo/

O R Char Var Text <sourceinfo> contains a generic element that provides a short statement explaining the text, indicating the basis for an assertion, or citing the source of a quotation or other information. <sourceinfo> may contain additional elements to provide a more structured description of the resource. For example: <persname:corpname:title:date:place> Using these additional elements within the <note> element is optional (see below). Definitions of the element are available within the EAC Tag Library.

Length

Form

Definition

<note> <eac/condesc/identity><persgrp/corpgrp><pershead:corphead><sourceref/sourceinfo/note> Attributes: type; typeauth TYPE values: sourceDataFound, sourceDataNotFound TYPEAUTH values: TBD

O R Char Var Text Use of the <note> element is generally optional and only recommended when necessary to indicate the type of source information note for example to retain some parity in mapping from one schema to another (e.g. MARC21 to PePO) or where the contributor data has data that is best suited to a source note (with or without using or extending the TYPE options). Other TYPE values will be evaluated as they are contributed.

<bibref> <<eac/condesc/identity><persgrp/corpgrp><pershead:corphead><sourceref/sourceinfo/note/bibref> Attributes: href; status; label

O R Char Var Text <bibref> provides a citation and/or electronic link for a published work such as a book, article, dissertation, motion picture, or sound recording. The HREF attribute is optional and provides a locator for a remote resource in a simple or extended link. An HREF takes the form of a Uniform Resource Identifier (URI). The <bibref> may contain content-specific elements such as <title>, <imprint>, or <edition>. Use of these specific elements within PePO will be determined pending evaluation of contributor data.

<desc> <eac/condesc><desc>

O R Char Var Text Description contains either formal, informal, or a combination of formal and informal description

Length

Form

Definition

<bioghist> <eac/condesc><desc><bioghist> <p/chronlist> Attributes: href;

O R Char Var Text Biographical or Historical information about the party. Places the corporate body, person or family in its historical context and includes significant information about the administrative history of a corporate body, or the life of an individual or family. May contain text in a series of Paragraphs , and/or a Chronology List <chronlist> that matches dates and date ranges with associated events. The element may be recursive (i.e., available within itself) to facilitate use of multiple headings with subdivided descriptions and may also be nested to designate a portion of the essay or chronology that might be extracted as a subfield in another system. PePO will retain usage of this element as provided by contributors.

<bioghist> <didentifier>

<eac/condesc><desc><bioghist/didentifier> Attributes: href

O R Char Var Text Link to biographical or organisational information. HREF is a locator for a remote resource in a simple or extended link. HREF takes the form of a URI.

<bioghist> <bibref>

<eac/condesc><desc><bioghist/p/bibref>

O R Char Var Text The <p/bibref> elements can be used to contain the source of the biographical data as distinct from the source of data used for generating the headings or description found within <sourceref/sourceinfo/…> The use of <bibref> within <bioghist> will be queried with the EAC WG. It was previously supported as a direct sub-element, but now required to use a style/format element in order to include <bibref>

<persdesc:corpdesc>

<eac/condesc><desc><persdesc:corpdesc>

O R Char Var Text Optional elements are available for formal description of each entity type: <corpdesc>, <persdesc> and <famdesc>.

Length

Form

Definition

<env> <eac/condesc><desc><persdesc:corpdesc><env>

O R Char Var Text Information on the social, cultural, economic, and political context in which the corporate body, person or family operated.

<existdesc>

<eac/condesc><desc><persdesc:corpdesc><existdesc>

O R Char Var Text tainer element for the dates of existence (<existdate>) and associated places, such as place of birth and place of death. When a dates or places are intended to differentiate then use the options under <identity/…/pershead:corphead>

<existdesc> <existdate>

<eac/condesc><desc><persdesc:corpdesc><existdesc/existdate> Attributes: scope; form; calendar; normal; era


Dates of existence.

<existdesc> <place>

<eac/condesc><desc><persdesc:corpdesc><existdesc/place> Attributes: type; valueauth; valuekey; placetype; typeauth TYPE values: birth, death, incorporated, formed TYPEAUTH values: TBD VALUEAUTH values: see <identity/…/place>

O R Char Var Text Descriptive information about the place of birth for persons, place of establishment for corporate entities etc. When a place is intended to differentiate then use the options under <identity/…/pershead:corphead> Other TYPE values will be evaluated as they are contributed. Other VALUEAUTH values will be evaluated as they are contributed.

Length

Form

Definition

<locations> <eac/condesc><desc><persdesc:corpdesc><locations>

O R Character

Var Text Used for grouping two or more <location> elements with an optional <head>. Multiple addresses for an entity can be indicated using the <locations> grouping element.

Length

Form

Definition

<location> <eac/condesc><desc><persdesc:corpdesc><locations/location/place> Attributes: type; placetype; typeauth TYPE values: resided, namedAfter, foundedBy, designedBy, basedIn TYPEAUTH values: TBD

O R Character

Var Text <location> can be used to contain information on the place or jurisdiction where the entity was based, lived or resided or had some other connection. Use the TYPE attribute to specify how the location is related to the entity. Within <location> use <place> for the name of the place. <date> may be used to specify the date or dates the location is relevant to the described entity. Note: alternative to ‘namedAfter’ is the more formal ‘eponym’. Other TYPE values will be evaluated as they are contributed.

<address> <eac/condesc><desc><persdesc:corpdesc><locations/location/address> Attributes: 7adrtype; emailtype; teltype; label

O R Character

Var Text A generic element for information about the place where someone or something is located and may be reached. Examples include a postal address, or the electronic mail address and phone number of the party granting publication permission. <address> can be used for a full or partial address. Optionally also used <addressline> to enter single line of address (repeatable). To record addresses for related entities define the related entity using <eacrels> and record the address of the related entity in their EAC record. There is no formal mechanism to convey address details such as street, city, state, country, or postcode. If the LABEL attribute it is possible (if cumbersome) to record address details.

7 ADRTYPE, EMAILTYPE and TELTYPE are derived from: RFC 2426 - vCard MIME Directory Profile, viewed 20 May 2007 <http://www.faqs.org/rfcs/rfc2426.html>

Length

Form

Definition

<descentry> <value>

<eac/condesc><desc><persdesc/corpdesc><descentry/value> Attributes: type; countrycode; normal; typeauth; typekey TYPE values: nationality, expatriate, heritage, resident TYPEAUTH values: austlit, maps, marcgac

O R Char Var Text

<descentry> provides a means to extend the available descriptive categories and its’ meaning can be specified using the TYPE attribute. Each <descentry> contains a descriptive term entered within <value>. Can be optionally followed by <date/place/descnote/sourceref>. Support for optional elements pending. TYPE value <nationality> from MAPS was originally <citizen> but still interpreted as meaning formal citizenship. Note that this aspect of an entity will not be verified. PePO will use this value (when supplied) to assert that an entity is Australian, but that the definition may extend to entities who are of general ‘Australian interest’. “expatriate”: Australian subjects living permanently overseas. “heritage”: Self-identified cultural affiliation. Persons only. “resident”: (formerly “visitor”) defined as non-Australians with substantial periods of Australian residence.

<descentry> <character>

<sex>

<eac/condesc><desc><persdesc><descentry/character/sex> Attributes: type Defined TYPE values: m, f, u

O R Char 1 Text The gender of sex of a person. The <sex> element can be used either directly under <persdesc> or alternatively under <character>. PePO has chose to support this element within <descentry/character> as a collocation or grouping mechanism for other characteristics of individuals e.g. height, hair colour, other physical characteristics.

<funactrels> <eac/condesc><funactrels> O NR Char Var Text <funactrels> is used for grouping one or more <funactrel> elements with an optional <head>

Length

Form

Definition

<funactrel> <eac/condesc><funactrels/funactrel>

C R Char Var Text Contains a function or activity term selected from a controlled vocabulary or classification scheme in <funact>. In addition to the term, the <date> of the function or activity, the <place> of jurisdiction or occurrence, <source> , and a descriptive note <descnote> may also be associated with the term.

<funact> <eac/condesc><funactrels/funactrel//funact> Attributes: type; typeauth; typekey TYPE values: occupation, honours, awards, service TYPEAUTH values: raam, maps, austlit

O R Char Var Text

A term for a function, profession or activity performed by the entity. A function or activity term selected from a controlled vocabulary or classification scheme. TYPE values: “occupation”: Designated occupation “honours”: Personal awards and honours “awards”: Personal awards where these are different to honours “service”: Services offered by a person or organisation

<date> <eac/condesc><funactrels/funactrel/date> Attributes: scope; form; calendar; normal; era


<date> may be used within <funactrel> to convey the date of the function or activity.

<place> <eac/condesc><funactrels/funactrel/place> Attributes: placetype; valueauth; valuekey VALUEAUTH values: marcgac, marcountry, iso3166-1

O R Char Var Text <place> may be used within <funactrel> to convey the place of jurisdiction or occurrence of the function or activity. Other VALUEAUTH values will be evaluated as they are contributed.

Length

Form

Definition

<descnote> <eac/condesc><funactrels/funactrel/descnote>

O R Char Var Text A descriptive note associated with the term for the function or activity. Note: could be used to record runner-up recipients for awards, honours etc.

<eacrels>

<eacrels> O NR Char Var Text <eacrels> enables grouping of one or more <eacrel> elements.

<eacrel> <eacrels/eacrel> O R Char Var Text <eacrel> contains the description of a relation with another corporate body, person or family.

Length

Form

Definition

<persname:corpname>

<eac/condesc><eacrels/eacrel><persname:corpname > Attributes: reltype; type; typeauth; typekey; system; syskey RELTYPE values: Defined RELTYPE values: superior, subordinate, earlier, later, associative, parent, child, identity, is, isNot TYPE values: TBD

O R Char Var Text <persname> is proper noun designation for an individual, including any or all of that individual's forenames, surnames, honorific titles, and added names. <corpname> identifies an organization or group of people that acts as an entity. In contrast to <pershead> or <corphead>, these are not a formal heading intended for use in indexing, sorting, and display. RELTYPE specifies the relationship (or relations) of the related entity to the entity being described. RELTYPE can be refined with the TYPE attributes or preferably TYPEAUTH, which can be associated with a thesaurus or local term list identified. “superior, subordinate”: any hierarchical relation “earlier, later”: any temporal relations, such as predecessor, successor “parent, child”: a biological or adoptive relation “associative”: any other relationship, "see also" “identity”: for linking different eac instances describing the same entity (for linking to external systems or when it is not possible to remove the duplicate)

TYPE values will be evaluated as they are contributed. Potential to define PePO list of types e.g: (influenceOn, contemporaryOf, associateOf, rightsHolder, legal)

<resourcerels> <resourcerels> O NR Char Var Text An element used for grouping one or more <resourcerel> elements with an optional <head>

<resourcerel> <resourcerel> O R Char Var Text <resourcerel> describes a relation between the described entity and a resource.

Length

Form

Definition

<archunit> <bibunit> <musunit>

<eac/condesc><resourcerels/resourcerel><archunit:bibunit:musunit> Attributes: reltype; type; typeauth; typekey; system; syskey RELTYPE values: origination, destruction, control, causa, subject, other TYPE values: role TYPEAUTH values: m21relator

O R Char Var Text Three elements are available for describing related resources: archival records are described in <archunit>; bibliographic items in <bibunit>, and museum objects or collections in <musunit>. RELTYPE values show their archival origins but terms like ‘origination’ and ‘subject’ convey the basic ‘isBy’ or ‘isAbout’ relationship between the entity and the resource. “origination”: described entity is creator of the resource or record “estruction”: describe entity destroyed the resource or record “control”: referenced resource is controlled by the described entity “causa”: related resource is or describes the mandate or charge for the described entity “subject”: related resource describes or is about the related entity “other”: other relation To express more details the mechanism for extending RELTYPE will be utilised through the use of TYPE attribute. Initially TYPE will be locally defined for recording the role of the described entity in relation to the resource. Other TYPE values will be evaluated as they are contributed. If the resource is electronically available, the SYSTEM and SYSKEY attributes may be used to provide information for accessing the resource.

<eac/condesc><resourcerels/resourcerel><archunit:bibunit:musunit><name/title/imprint/edition/bibseries/descnote> Attributes: href (within descnote)

O R Char Var Text The <bibunit> may contain just text or may have content-specific elements such as <title>, <imprint>, or <edition>, etc. Where PePO contributed data supports greater content specificity these additional elements will be used.



Attributes Obl Occ Datat

ype Length

Form Definition

eac attributes

@actuate Defined ACTUATE values: Onload, onrequest, actuateother actuatenone

O R Char Var Text Defines whether a link occurs automatically or must be requested by the user. It is used in conjunction with the SHOW attribute to determine link behavior. Values are: onload: element is displayed automatically. onrequest: element is displayed if user requests. actuateother: some other action occurs with respect to the link. actuatenone: no action occurs with respect to the link.

@adrtype ADRTYPE values: postal, home, work, parcel, pref

O R Char Var Text Use ADRTYPE to specify the type of delivery address. Derived from 8rfc2426 (also used with vCard, hCard)

@audience AUDIENCE values: internal, external, restricted

O R Char Var Text The AUDIENCE attribute can be used within any element to convey data elements/subelements that should not be displayed publicly, or should not be viewed by general users. Use is optional and when it is not supplied the element or EAC instance is assumed to be public. Additional values and supporting attributes may be defined at a future date pending further input from EAC WG and an assessment of the privacy requirements of contributor data.

@authorized AUTHORIZED values: AuCNLKin

O NR Char Var Text AUTHORISED contains the owner or repository code of the contributing agency when that agency chooses to designate one of the headings provided for an entity as the authoritative or preferred heading. Descriptive rules applied for establishing the heading shall be stated in the RULE attribute. Other AUTHORISED values will be evaluated as they are contributed.

8 RFC 2426 - vCard MIME Directory Profile, September 1998, viewed 20 May 2007, http://www.faqs.org/rfcs/rfc2426.html

Attributes Obl Occ Datatype

Length

Form Definition

@calendar Defined CALENDAR values: gregorian, julian, Islamic

M

R

Char

Var

Text

System of reckoning time, such as the Gregorian calendar or Julian calendar. Contains the calendar from which the date stems. Other values will be evaluated as they are contributed.

@countrycode O NR Char Var Text A unique code for the country in which the materials being described are held. Codes are to be taken from ISO 3166-1, column A2 as specified in COUNTRYENCODING.

@countryencoding

O NR Char 9 Text Default value is iso3166-1. Standard for country codes permitted in description.

@dateencoding O NR Number

7 Integer

Default value is iso8601. Standard for formulating normalized date values. Only used within <eacheader> Note: Dates in some sources may not comply with iso8601. PePO will modify the date to comply with iso8601.

@detaillevel Defined DETAILLEVL values: minimal, partial, full

O NR Char Var Text Indication if the record consists of minimal, partial or full level of detail in accordance with the descriptive content standard or standards applied.

@ea

O NR Char Var Text A descriptive encoding system, such as MARC, or any local authority file, to which certain EAC elements can be mapped using the attribute EA.

@emailtype EMAILTYPE values: internet, x400, pref

O R Char Var Text Use EMAILTYPE to record the format or preference of the electronic mail address. Derived from rfc2426 (also used with vCard, hCard) The default email type is "internet". A non-standard value can also be specified.

@encodinganalogsys

O NR Char Var Text A field or element in another descriptive encoding system to which an EAC element is comparable. This attribute is defined for use with a large number of EAC elements.

@era ERA values: ce, bce

O R Char Var Text May be used to specify the era from which the date stems, such as "ce" (common or Christian era) or "bce" (before common or Christian era). Unlikely to be supplied by PePO contributors.

Length

Form Definition

@form Defined FORM values: openspan, closedspan, single

O R Char Var Text Most date forms will be open span or closed span.

@href

O R Char Var Text Locator for a remote resource in a simple or extended link. An HREF takes the form of a Uniform Resource Identifier (URI).

@id O R Char Var Text A identifier used to name the element so that it can be referred to, or referenced from, somewhere else. Each ID within a document must have a unique value. The ID attribute regularizes the naming of the element and thus facilitates building links between it and other resources. In EAC examples it operates like SYSTEM.

@label

O R Char Var Text display label for an element can be supplied using this attribute when a meaningful label cannot be derived by the style sheet from the element name or when a heading element

@languagecode

M R Char 3 Text Three-letter code for the language of the descriptive content of the authority record. Codes should be taken from ISO639-2b, as specified in the LANGENCODING attribute in <eacheader>.

@langencoding

O NR Char 9 Text Default value is iso639-2b. Standard for language codes used in description. Only used within <eacheader>

@maintype Defined MAINTYPE values: create, update, delete, import"

M R Char Var Text Each <mainevent> has a required MAINTYPE attribute to accommodate one of four possible values: create, update, import, or delete.

@normal O R Number

Var Integer

A machine-readable date is provided as the value of the NORMAL attribute (e.g. 20070208140412.0). Within <existdate> the NORMAL attribute follows the standard specified in DATEENCODING in the <eacheader> Human-readable natural language date (e.g. 8 February 2007) will not be applied. These dates will not be presented to general users.

@ownercode O NR Char Var Text A unique code for the owner of the system and should follow the standard specified in OWNERENCODING in the <eacheader>.

Length

Form Definition

@ownerencoding O NR Char 8 Text Default value is iso15511. Standard for repository or owner code values. Note: Australian symbols may not correspond to ISO 15511 or the MARC Code List for Organizations (http://www.loc.gov/marc/organizations/) which has largely incorporated ISO 15511. PePO establish iso15511 compliant codes as required.

@placetype PLACETYPE values: geog, juris

O NR Char 5 Text A specification on whether the element <place> refers to a geographic name (geog) or a jurisdictional area (juris).

@reltype

O NR Char Var Text Nature of relationship of the related entity or concept to the entity being described. <eacrel> has a closed list:

@role

O R idRef Var Text In linking elements such as <ptr>, information that explains to application software the part that a remote resource plays in a link.

@rule RULE values: aacr2

O NR Char Var Text RULE contains the name of the descriptive rules or conventions that govern the formulation of the content of the element. Other values will be evaluated as they are contributed e.g. isaar

@scriptcode

M R Char 4 Text Code for the writing script used with a given language. The code should be taken from ISO 15924 -- Code for the Representation of Names of Scripts.

@scriptencoding

O NR Char 8 Text Default value is iso15924. Standard for script codes used in description. Only used within <eacheader> Note: ISO15924 has no value for a collective ‘East Asian’ script. TBD whether unambiguous identification of the specific script forms for Korean, Japanese and Chinese scripts is possible.

Length

Form Definition

@show Defined SHOW values: embed, new, replace, showother, shownone

O NR Char Var Text Defines whether a remote resource that is the target of a link appears at the point of the link, replaces the existing link, or appears in a new window. It is used in conjunction with the ACTUATE attribute to determine link behavior. “embed”: the target resource displays at the point of the link. “new”: the target resources appears in a new window. “replace”: the target resource replaces the local resource that initiated the link. “showother”: some other action takes place with respect to the target resource. “shownone”: no target resource displays.

@status Defined STATUS values: draft, edited, deleted

O NR Char Var Text Drafting status of the record must be recorded in the STATUS attribute. ‘edited’ indicates the record is available for publication/dissemination, “draft” implies that it is not and ‘delete’ is to record a now obsolete instance to assure referential integrity and accountability. *Business rules to determine if ‘draft’ and ‘obsolete’ status records may be viewed/edited/exported.

@syskey O R Number

Var Integer

Contains the unique machine readable identifier of a record or a file within the system referred to in the SYSTEM attribute.

@system O R Char Var Text The value of SYSTEM must be an entity declared in the head of the EAC instance containing the path to the system or to a document describing how to access it.

@teltype TELTYPE values: home, work, message, voice, fax, pref

O R Char Var Text Use TELTYPE to indicate the intended use of any telephone numbers included in the EAC instance. Derived from rfc2426 (also used with vCard, hCard).

@type O R Char Var Text The TYPE attribute is available for a number of elements; its characteristics vary depending on the element to which it applies. Some instances of TYPE have closed lists (e.g. <eac>, <eacgrp>, <sex>), but most permit character data.

@typeauth O R Char Var Text On some elements, TYPE is made available with two other attributes, TYPEAUTH and TYPEKEY. This references an authoritative list from which the TYPE value is derived. The intension is to provide a means to control semantic extensions of EAC-specific descriptive elements.




Length

Form Definition

@typekey O R Char Var Text An identifier or term in the controlled vocabulary referenced in TYPEAUTH

@valueauth

O R Char Var Text A reference to the controlled vocabulary or thesaurus applied in the context . VALUEAUTH attribute can be used to specify the vocabulary from which the term has been taken and the VALUEKEY attribute can contain the unique identifier for the thesaurus term. VALUEKEY must be used in conjunction with VALUEAUTH.

@valuekey O R Char Var Text The unique machine readable identifier of a term in the thesaurus referred to in the VALUEAUTH attribute. VALUEKEY must be used in conjunction with VALUEAUTH.

EAC beta version Comments

Survey on EAC use in Italy

2

References

Title EAC beta version comments. Survey on EAC use in Italy Subject EAC comments

ISAAR Description EAC use in Italy and comments Type text Source surveyEAC-Italy.pdf Relation EAC Working Group call for suggestions proposals Coverage EAC beta version suggestions, 2007-2008 Creator Ilaria Barbanti ([email protected]) Contributor Accademia di Santa Cecilia – Saint Cecily National Academy

Archivio di Stato di Bologna - Bologna State Archives Archivio di Stato di Napoli - Naples State Archives Enel – Italian Electricity Company Fondazione Feltrinelli – Feltrinelli Foundation Istituto Luce - LUCE Institution Istituto per I beni artistici, culturali e naturali - Institution of arts, cultural and environment heritage of Emilia Romagna Region

Date 2007-12-04 Format text/pdf

296 KB Language EN

3

Summary 1. Content ........................................................................................................ 4

2. The Italian context: authority file projects and EAC ................................................... 4

2.1. xDams application ...................................................................................... 4

2.1.1. Bologna State Archives ........................................................................... 5

2.1.2. Naples State Archives ............................................................................. 5

2.1.3. Institution of art, cultural and environment heritage of Emilia Romagna Region ...... 5

2.1.4. Feltrinelli Foundation............................................................................. 6

2.1.5. LUCE Institution.................................................................................... 7

2.1.6. Italian Electricity Company ...................................................................... 7

2.1.7. Saint Cecily National Academy .................................................................. 8

3. xDams Authority files: traditional use and new perspectives of EAC use ........................... 9

3.1. Headings and authorized forms of name ............................................................ 9

3.2. The encoding of other contextual information................................................... 11

3.2.1. Examples of xDams’ EAC records ............................................................. 13

3.2.2. ISAAR-EAC-EAC xDams subset.................................................................. 17

4. Proposals of changes and improvements of EAC beta version ...................................... 21

4

1. Content This report include some general information about the application of EAC1 in the Italian context, with particular reference to the projects developed by some archival institutions and research centers which use xDams. xDams is an ASP solution, for producing, gathering and managing EAD compliant archival descriptions of historical archives and of related authority files, encoded according to EAC.

The focus of the report will be in particular on the solutions adopted for encoding authority files. The experience built up on archival description2 and on XML data element sets application in a digital environment set up several remarks that we hope will be considered by the EAC Working Group, in order to make the standard more effective for exchanging and sharing archival authority records on the web.

2. The Italian context: authority file projects and EAC In Italy, several online information systems have been developed for the past few years.

Amongst them, it is worth mentioning those developed and coordinated by the Archival Central and Local Administration: Guida generale degli Archivi di Stato (General Guide to the of State Archives), SIAS (State Archives Information System), SIUSA (Archival Superintendences Information Systems), SIASFI (Florence State Archives Information System) and PLAIN (Archives on Internet Project of Lombardia Region). This is not the appropriate site to describe them: just state that they are all relational databases oriented to describe various archival entities. In fact, they are conceived to hold and connect information about different archival metadata, such as descriptions of archival custodians, finding aids, authority files of creators, and other important contextual information, such as general institutional, historical, and territorial profiles3.

XML use is an essential tool for promoting interoperability between information systems which could be destined to remain closed off. For this main reason, some of these projects have adopted EAC as a standard to re-use or to encode for the first time archival authority records in an XML environment.

2.1. xDams application

Several Italian institutions, both public and private, use xDams (XML Digital Archives and Memory Storage), an XML-native platform developed by a private firm, regesta.exe4, to manage integrated access, research, and digital reproductions of documents of historical and multimedia archives on the web.

While the archival material comply with EAD standard, the authority files, if existing or requested by the xDams users, comply with EAC standard, so EAD and EAC are used as a transposition into an XML environment of the respective descriptive model, ISAD(G) and ISAAR(CPF), which are, in fact, the essential reference rules.

Regarding the XML encoding, in the EAD instance the AUTHFILENUMBER attribute of <*name> subelements of <origination> can be automatically linked with the <eacid> code archival authority records, and vice versa.

1 From now EAC is intended as EAC beta version, if not specified further on. 2 Let me offer thanks and make mention of the persons furthered the realization of this report: Ingrid Germani, Bologna State Archives; Paolo Franzese, before Naples State Archives and now ICAR (Istituto centrale per gli archive – Central Institute of Archives); Brunella Argelli, IBC (Istituto per I beni artistici, culturali e naturali - Institution of art, cultural and environment heritage of Emilia Romagna Region); Chiara Daniele, Feltrinelli Foundation; Patrizia Cacciani, LUCE Institution; Elena Accorinti and Daniela Napolitano, Enel; Annalisa Bini, Saint Cecily National Academy. 3 Please see also Stefano Vitali, EAD and EAC in Italy and the Italian archival descriptive systems on-line, available on http://www.bundesarchiv.de/imperia/md/content/instada/vitali.pdf. 4 Please visit http://www.regesta.com.

5

In the following an abstract of some institutions working in it is provided.

2.1.1. Bologna State Archives

The wealth of Bologna State Archives consists of 5064 fonds, split in over 248,000 archival items spread within the span of ten centuries, from the 10th to the 20th century. They include documents issued by Bologna public offices, starting from Middle Ages up to our age (the most ancient document dating back to 922 b.Ch.). One can find as well archives of noble families, churches and convents, hospitals, ancient university, notaries, and plenty of cadastral maps and papers.

Description of fonds and series has been already entered into institutional web site, while description of each archival unit, aiming at creating XML-native electronic inventories, is still in progress. Encoding of descriptive metadata is in compliance with EAD 2002 standard.

It is possible to enter databases on web interface through advanced search functions, or to browse the hierarchical structure of all documentary levels5.

In the future, all the archival creators, the name of which is encoded within the archival records of high level, will enter in separate authority records, beta-EAC compliant, so is in progress the definition of the authority file descriptive model, which will be conceived with respect to ISAAR fields.

2.1.2. Naples State Archives

Archival wealth of Naples State Archives is a living evidence of both city and surrounding territory history (South of Italy and Sicily at first, its province later on, for which it was the political and administrative centre), and of the way historical memory of this city sedimented.

Sate Archives include both official and administrative documents, and those given by private families and persons.

Institutional website6 provides access to information about three types of archival subjects:

- documentary archives (covering a historical span since the 10th up to the 20th century), including series and subseries level;

- authority files of archives creators; - search instruments for paper formats, collected in the Consultation Room.

Website also enables users to consult digital searching instruments.

Though upgrading of all databases on XML format is in progress, encoding process for descriptive metadata on documentary material, and for search instruments is already compliant with EAD 2002 standards, while documents’ authors are encoded according with EAC standards - beta version.

2.1.3. Institution of art, cultural and environment heritage of Emilia Romagna Region

The Istituto per i beni artistici, culturali e naturali (IBC) of the Region Emilia Romagna7 was founded in 1974 to support and advise the Regional Government in policy making and to act as an advisory body to local authorities in the field of cultural heritage. The Superintendence for libraries and book materials has

5 Please visit http://www.archiviodistatobologna.it. 6 Please see http://www.archiviodistatonapoli.it. 7 For any further information please visit the IBC website, http://www.ibc.regione.emilia-romagna.it.

6

been part of the Istituto since 1983, with the specific task of coordinating the regional policy addressed to libraries and archives.

The Istituto "promotes and carries out research projects for the enhancement, the restoration and the protection of cultural objects, historical cities and cultural heritage at large, advising both the Regional Government and local authorities" and "enforcing the legislation addressed to local authority museums and libraries, within the framework of regional policies and regulations".

The activities carried out by the Istituto Beni Culturali over the years and the important role played with respect to the Regional Government, have made it a unique organization in Italy, with an unrivalled experience in its field.

Concerning the archival domain, the Institution is carrying out census and on-line data-bases, and presides over the activities of inventory and classification in local historical archives.

Actually, the import and encoding of archival databases on XML format compliant with EAD and EAC is on going. Besides, a database of local archival repositories, CAStER (Census of historical archives of Emilia Romagna Region) was developed and accords to the draft ICA standard ISIAH, so is in the pipeline the conversion in XML format; to do it, EAG DTD, born in Spain to encode a similar Cesus, as data reference model is used, waiting the creation of a standard XML data element set ISIAH compliant.

2.1.4. Feltrinelli Foundation

Named for its founder, the Giangiacomo Feltrinelli Foundation was established in 1949 to collect, preserve and make available to scholars and interested members of the public diverse materials documenting the history of ideas, in particular those related to the development of the international labor and socialist movements. It had two prior incarnations: first as a library and then as an institute.

The Foundation has since grown to become one of Europe’s foremost centers for scholarly research on social, political and economic thought and history from the 18th century to the present. Its library and archival holdings, which cover a broad disciplinary and linguistic spectrum, comprise nearly 190,000 rare and modern monographs, extensive collections of newspapers and periodicals, both historical and current, and over one million manuscripts and rare primary source materials.

Focusing on the socio-economic and political development of Western Europe in the course of the past three centuries, with a spotlight on the evolution of the international labor movement, socialism and social democracy, the Foundation’s library and archival holdings are classified within Country Collections covering specific geographical areas and related Special Collections, thematic sections focused on watershed historical moments.

While the Country Collections for Western Europe are the strongest, there are also considerable sections on dozens of countries in Eastern Europe, Latin America and the Caribbean, Africa and Asia. Of special note among the Special Collections – to mention just a few – are the holdings on the Italian Risorgimento, the European revolutions of 1848, the British Chartist movement, Marxism, the Paris Commune of 1871, pre-Revolutionary Russia, the Spanish Civil War, the 1968 Prague Spring, Poland’s Solidarity movement and the Tiananmen Square uprising. The Foundation also possesses over 2,000 rare books relating broadly to social and political philosophy and political economy, with especially strong sections on early Utopianism,the Enlightenment and the French Revolution.

All of the Collections feature a wealth of unique archival materials that present extraordinary opportunities for researchers to get closer to the day-by-day events of defining moments in modern social history.

7

A long-term digitization project is underway to make available online reproductions of thousands of the most significant materials in the Foundation’s possession. Through a website8 users can consult over 20.000 archival records, encoded in XML format validated by EAD 2002, and related with their own creators’ authority file gathered in XML databases of EAC instances.

2.1.5. LUCE Institution

The Istituto Luce was established in 1924 in Italy during the fascist period. Its historical archive holds about 12,000 editions from more than 20 different newsreels that the Istituto and others produced in Italy between 1927 and 1990; foreign newsreels made in Germany (some by UFA) as well as 150 hours of material made by the American War Office between 1943 and 1945; thousand documentaries (about 6000, among which 1200 silent, 4500 talking pictures, from the1910s to the 1990s); 8000 reels of record footage; up to 3 millions photos from 1919 to 1990s. Moreover Istituto Luce is gathering collections from others film archives (Arkivi Qëndror Shtetëror i Filmit, Archivio audiovisivo del movimento operaio e democratico, Archivio Quilici).

The project is aiming at providing the whole collection on the web: the website will make available all digitized resources in a shared environment, the most important non fiction moving image gateway in Italy. At the present moment four portals gather and deliver Luce digital resources referred to Chamber of Deputies (link), Marche, Veneto and Valle d'Aosta Italian Regions9.

From its website it’s possible to browse the institutional collections (audiovisual or photographic database), using simple or advanced search (this one structured in specific fields: description, subject, place, people, date, credits, etc), or directories. The multimedia catalogue provides free access to descriptive records and digital materials (files of moving and still images) referring to all entered documents.

Documents are collated, processed, standardized to national and international standard: Fiaf rules for archival description of moving image, F rules provided by Iccd (Minister of cultural heritage institute) for cataloging photos, ISAD (G) for level description in hierarchical context. F and Fiaf rules specific fields description have been matched with EAD elements and attributes.

Authority files include topics, persons and places. They are encoded in a data element set adapted to the EAC structure, and are common to all the archival databases. The access to them allows to:

- control and normalize the authority entry and the description; - provide general and contextual information about the described entity; - search in the authority and between all the archival databases to which the specific entity is

encoded.

2.1.6. Italian Electricity Company

Enel holds one of the most important Italian enterprise archives, testifying the electric power history of the country. The archives are composed by paper, photograph and audiovisual material.

The paper documents refer to over 1.200 electric companies before their unification process (started from 1963 ahead) within Enel itself, and it is distributed between the Directorate-General archives and eight local archives. The first whole of material gathers information about the origin and the development of the firms operating previously to Enel, while the other archives collect historical documentation produced

8 Please visit http://risorseonline.fondazionefeltrinelli.it. 9 The Chamber of Deputies portal is available on http://camera.archivioluce.com/archivioluce/camera; the Veneto Region portal is on http://veneto.archivioluce.com/archivioluce/regioni/veneto; the Marche Region portal is on http://marche.archivioluce.com.

8

by the own companies, from 1800, and they are localized in the following Italian cities: Cagliari (Sardinia city), Florence, Milan, Naples, Palermo (Sicily), Rome, Turin and Venice.

Over 15.000 images constitute the photograph collection, and there are two fonds:

- Larderello fonds, photograph material showing the technical, environmental and social evolution of Toscana Region;

- Parisio Fonds, gathering over 2.500 photos testifying the electric power spread in the South of Italy, since 1930.

The movie material amounts to about 26 hours; the Edison Group fonds is the most extensive and also gather documentary films directed by Ermanno Olmi, showing geographical places and plants with soundtracks and voices-over.

Regarding the historical aspects, it is worth mentioning the archival material of SME (Società meridionale di elettricità - Electric Power Society of South of Italy), produced between 1921 and 1931, while Sade (Società adriatica di elettricità - Electric Power Society of Adriatic side) holds documentary films showing the Vajont Dam in the age of its planning and building construction (from 1956 to 1960).

All the material is described in XML databases EAD compliant, and is available online10. The archival databases are connected with different authority files of companies, plants, geographical and art sites, events and publications, everyone of which have specific own descriptive information encoded in XML records structured with reference to EAC standard (please see 3.2.1. paragraph of this report).

2.1.7. Saint Cecily National Academy

Management and handling of documentary wealth of Academy were conceived to support interaction between internal and external end-users of web facilities, and to gather the following databases in a common environment:

- historical archives; - collection of papers from mid seventeenth century up to nowadays (registers, artistic

correspondence, broadsheets, etc.); - photographic archives: a collection of over 20.000 photos since mid nineteenth century up to the

present day; - a library of over 120.000 volumes (among which manuscripts, scores, pamphlets); - ethno-music archives; - instrumental museum; - audio and audiovisual archives; - pieces of art collection; - press review archives.

This project is aiming at providing the whole collection with two access systems.

Internet portal provides users of internal and external network with a differentiated admittance (in this way, each user is registered on a database according to his operative areas and to his role). In Consultation Room of Media Library users can consult all material the Academy decides to show from time to time.

EAD (2002 version) was adopted as a standard encoding for all the archives, except for bibliographic and press review metadata, which have no reference with archival fields.

10 Please see http://www.enelikon.com.

9

From website it is possible to browse and search among all archives of the Academy: bibliographic catalogues, descriptive inventories and digital material referring to all entered documents – like files of images, or sounds, or audiovisual streamers.

The Academy implements various Authority files connected to the other material, of persons and corporate bodies, places, titles of musical works, and the ancient musical instruments stored by the institution. For all of them it is possible to attach images; besides, the authority files of musical works titles include information about its identification (number, catalog, tonality, dedication, and so on) and other characteristics, such as the music form/genre or the composition of the orchestra. While EAC is conceived as subject creators standard, the authority files of the Academy are encoded using it, having the institution the opportunity to gather and deliver its peculiar and interesting information.

3. xDams Authority files: traditional use and new perspectives of EAC use A part from the archival content provided by the organizations described above, we will deal here with some issues carried out in the EAC implementation within xDams application, in course of developing or already, such as:

1. the definition of the headings and the authorized forms of the authority entries; 2. some encoding choices allowing to implement a data element set more easy and functional to use; 3. the encoding of the relationships among the authority entities and the archival materials and the

archival institutions which have custody of archival materials, in order to link the authority domain to any information system implementing ISIAH standard.

The following section of this report is devoted to deepen the first issue, as well as the second section refers to the other ones.

3.1. Headings and authorized forms of name

ISAAR standard states11 “to create authorized access point that uniquely identifies a corporate body, person or family. […] Use dates, place, jurisdiction, occupation, epithet and other qualifiers as appropriate to distinguish the authorized form of name from those of other entities with similar names.”

As stated above we consider that the purpose and the rule of the ISAAR 5.1.2 field mix up two authorized forms: the heading one, composed by different description elements, and the authorized name one, that is part of the first one.

In 2002 the Italian Working Group on Archival Authority Record Headings12 convened to establish how to create an authorized form heading of the subject creators. Working Group has not completed its activity; however, it produced some draft documents about the elements composing a controlled heading, with respect to the national and international rules AACR2, APPM, RAD and RICA (Regole italiane per la catalogazione degli autori – Italian Rules of Author Cataloguing). A list of the elements of a controlled heading is provided below:

Corporate body Person Family the political and/or the hierarchical context of higher level (with reference to the internal structure), supplied by specific dates related to the period in which the creator was operating or is bearing, if needed

11 Please see the 5.1.2 section of ISAAR 2nd edition, available on http://www.ica.org/sites/default/files/ISAAR2EN.pdf. 12 The Working Group was founded in 2002. For any further information please see «Il mondo degli archivi», a. X - N. S. n. 1/2002, ANAI p. 28 e DGA p. 34-37.

10

the authorized name of creator the place(s) or location(s) the dates of existence genealogical context the branch name title predicate (if liege lord: the name of the fief) patronymic

Furthermore, both political and hierarchical context can change in the course of time. Two issues can be therefore adopted:

1. to create an authorized context for each change in context (either institutional or hierarchical one);

2. to create one heading only with any kind of necessary information about context.

The Italian Working Group and some institutions involved in xDams projects are inclined to adopt the first issue, which coincides with the direction that EAC can and wants to take.

Here are some examples to better understand this issue13:

Heading 1 Heading 2 One heading complete form Regno di Napoli (1806-

1816). Ministero della Polizia generale. Prefettura di polizia (1808-1860)

Regno delle Due Sicilie (1816-1860). Ministero della polizia generale. Prefettura di polizia (1808-1860)

Regno di Napoli (1806-1816); Regno delle Due Sicilie (1816-1860). Ministero della Polizia generale. Prefettura di polizia (1808-1860)

political context Regno di Napoli (1806-1816)

Regno delle Due Sicilie (1816-1860)

Regno di Napoli (1806-1816); Regno delle Due Sicilie (1816-1860)

hierarchical context Ministero della Polizia generale

Ministero della polizia generale

Ministero della Polizia generale

authorized name Prefettura di polizia Prefettura di polizia place [this element is provided in the political context name] existing dates (1808-1860) (1808-1860) Prefettura di polizia

(1808-1860)

EAC elements allow to encode separately and to repeat all of these descriptive information, as follows:

EAC element EAC path complete form Composed by the following

elements

political context

<part type="stateprofile"> eac/condesc/identity/*head/part[@type='stateprofile']

hierarchical context

<part type="parent"> eac/condesc/identity/*head/part[@type='parent']

authorized name

<part type="normal"> eac/condesc/identity/*head/part[@type='normal']

place <place> eac/condesc/identity/*head/place existing dates <existdate> eac/condesc/identity/*head/existdate

13 Heading 1: Naples Realm (1806-1816) – Ministry of General Police – Police Prefecture (1808-1860); Heading 2: Two Sicilies Kingdom (1816-1860) – Ministry of General Police – Police Prefecture (1808-1860); One Heading: Naples Realm (1806-1816) – Two Sicilies Kingdom (1816-1860) – Ministry of General Police – Police Prefecture (1808-1860).

11

Therefore, EAC make possible the encoding of separate controlled headings, that is a relevant requirement in the archival creators knowledge. After all, the Tag Library states that “the notion of "authorized heading" and "variant heading" is not explicitly privileged in the naming of the elements”.

However, xDams have not introduced distinct elements to name controlled headings in the EAC subset implemented in its applications yet (please see 3.2.2. paragraph). The delay is because of the EAC official documents seem not clear about it (please see 4. paragraph).

3.2. The encoding of other contextual information

The authority records for subject creators (corporate bodies, persons and families), prepared according to ISAAR(CPF), are encoded in EAC. It is worth mentioning that in some cases the authority files gather not only name and descriptions of corporate bodies persons and families, but also of topics, subjects, places, and so on (please refer to the description of the organizations using xDams). For encoding them EAC is used as well, although the data element set has been modified in order to include new descriptive requirements, such as the inclusion of other values in the <eac> TYPE attribute: place, topic, plant, and so on (please see 3.2.1. paragraph).

In the xDams descriptive systems the various authority files typologies are shared with all the other existing archival databases, and every single entity can be identified and described within a data structure such as ISAAR and EAC, offering enlarged perspectives of gathering information and access rather than any other authority file description rule.

This solution starts from two main statements:

a. the ISAAR definition of the archival authority records14: “Archival authority records are similar to library authority records in as much as both forms of authority record need to support the creation of standardized access points in descriptions”;

b. the Toronto Tenets Definitions and uses no. 2, 3 and 4 15: 2. Context information is not metadata that describes other information resources, but

information that describes entities that are part of the environment in which information resources (i.e., records) have existed.

3. The recording of context information in archival information systems directly supports a more complete description and understanding of records as well as the provenance approach to retrieval of these records across time and domains.

4. Context information also can have value as an independent information resource, separate from its use in supporting the description, retrieval, and interpretation of records.”

All the access key are physically collected in separated authority databases, as much as are their typology, and each record has identification and descriptive information of the entities and the relation among them and the archival material. The relation between the creator or any other keyword and the archival material will continue to be respected, because the encoding itself functions as distinct element among the creators and all the other access keys.

The advantages of this solution are the following ones:

o to control and normalize the entities within the description on the archival description side, the <origination> element and subelements and <controlaccess> element and subelements respectively will be used, while the RELTYPE attribute of <eacrel> element is filled in the authority description environment;

14 Please see 1.8 paragraph of ISAAR 2nd edition Scope and Purposes, available on http://www.ica.org/sites/default/files/ISAAR2EN.pdf. 15 Please see http://www.library.yale.edu/eac/torontotenets.htm.

12

o to provide focused researches within both the archival and authority databases, and to make available all the information about a specific object or produced from the same subject, regardless of the material is physically located.

Moreover, this solution, even if unsuited on the archival mean, allows to separate creators and keywords referred to the material description in an online access and presentation system.

13

3.2.1. Examples of xDams’ EAC records

The following examples are two XML records extracted from the Enel Authority files of Plants and Companies. They are encoded using a data element set structured on the basis of EAC standard but not totally compliant with it, as displayed in the “Notes” column of the tables.

PLANT AUTHORITY RECORD

EAC section XML example xDams fields labels xDams modifications Notes

eac/@type <eac type="plant"> Type of entity The “plant” value in the TYPE attribute

The plants are corporate bodies delivering electric power in the places where they operated

eac/eacheader <eacheader detaillevel="partial" status="draft"> <eacid countrycode="IT" ownercode="ENEL">0000015</eacid> <mainhist> <mainevent maintype="create"> <maindate>19-01-1999</maindate> <name>Fabio Rossi</name> </mainevent> […] </mainhist> <languagedecl> <language languagecode="ITA">italiano</language> </languagedecl> </eacheader>

Level of detail Status Authority record identifier Institution identifiers Type of event Date of the event Name who attended the record Languages

eac/condesc/identity <identity> <conhead languagecode="ITA" type="authorized"> <part type="ord">Acquoria</part> <part type="add">Centrale idroelettrica di</part> <part type="normal">Centrale idroelettrica di Acquoria</part> </conhead> <descnote>La centrale di Acquoria è del tipo a bacino con due derivazioni ed è alimentata dalle acque dell'Aniene. La sua potenza efficiente è di 51.900 kW, per una producibilità media annua di 180,3 GWh.</descnote> </identity>

Authorized form of name The name used to arrange

alphabetically the list of entities Other integrations of the name The whole of the name Specific information about

technical characteristics and electric power delivering

<conhead>, instead of <corphead>, in order to apply a unique data element set for all the authority files typologies

The whole of the name is composed automatically with the data filled in the previous elements. The variant forms of the name(s) include the same description elements, except for the value of the TYPE attribute of <conhead>, that is “parallel”

14

eac/condesc/desc/corpdesc <existdesc> <existdate normal="yyyymmdd-yyyymmdd"/> <descnote> <list> <head>proprietà</head> <item> <corpname id="0000245">Enel Produzione Spa <event> <date scope=""/> [text] </event> </corpname> <persname id=""/> </item> </list> </descnote> </existdesc> <locations> <location> <place>Lazio <descnote>La centrale si trova nel comune di Tivoli, in provincia di Roma.</descnote> <part type="latitudine"/> <part type="longitudine"/> <part type="nazionalità">ITALIA</part> </place> </location> </locations> <funactdesc> [text] <list> <head>componenti impianto</head> <items> <item/> <item/> </items> </list> </funactdesc>

History of the plant Existing date(s) Ownership information The company/ies owning the plant Ownership date(s) Ownership condition (turned into

another condition, dismissed or traded)

The name of the responsible(s) Geographical location of the plant Region Specific localization Latitude Longitude Nationality Plant functioning Plant components Type of component Quantity and description

<corpdesc> is not used here, in order to apply a unique data element set for all the authority files typologies

The company owning the plant and the persons are entities described in separate records, of companies and persons authority file respectively, and they are linked automatically

eac/condesc/desc/bioghist <bioghist> La centrale dell'Acquoria, entrata in servizio nel 1892, fu la prima centrale idroelettrica a produzione di corrente alternata realizzata in Italia. La seconda derivazione fu costruita nel 1989 con i macchinari forniti dalla Ganz di Budapest e trasportati sul posto a mezzo di carri delle ferrovie ungheresi instradati sui binari della tramvia Roma-Tivoli. </bioghist>

History of the plant

eac/condesc/desc/eacrels <eacrels> <eacrel syskey="0001173" reltype="superior" type="appartiene">Impianti idroelettrici del Basso Aniene</eacrel>

Plant structure and relationships It belongs to

<corpname> is not used here, in order to apply a unique data element set for all the authority files

The aim of the structure information is to refer to the other

15

<eacrel syskey="" reltype="subordinate" type="comprende"></eacrel> </eacrels>

It includes

typologies plant entities and to define the type of relationship with them. This is the reason why this information is included in <eacrels> section, instead of <assetstruct> subelements

eac/condesc/desc/resourcerels <resourcerels> <resourcerel reltype="other" syskey="ftenelXML"> <archunit> <unittitle>Archivio fotografico</unittitle> <physdesc> <genreform>foto</genreform> <extent>28</extent> </physdesc> </archunit> </resourcerel> </resourcerels>

Material referred to the plant Archives name Type of material (photograph,

drawing(s) or audiovisual material)

Extent of the material

eac/condesc/desc/funactrels <funactrels> <funactrel type="ambito attività"> <funact>Produzione</funact> </funactrel> <funactrel type="tipologia impianto"> <funact>Centrale idroelettrica</funact> </funactrel> </funactrels>

Plant classification Activity area Plant typology

COMPANY AUTHORITY RECORD

EAC section XML example xDams label fields xDams modifications notes eac/@type <eac type="corporatebody"> Type of entity eac/eacheader <eacheader detaillevel="partial" status="draft">

<eacid countrycode="IT" ownercode="ENEL">0000245</eacid> <mainhist> <mainevent maintype="create"> <maindate>03-02-2000</maindate> <name>Fabio Rossi</name>

Level of detail Status Authority record identifier Institution identifiers Type of event Date of the event Name who attended the record

16

</mainevent> […] </mainhist> <languagedecl> <language languagecode="ITA">italiano</language> </languagedecl> </eacheader>

Languages

eac/condesc/identity <identity> <conhead languagecode="ITA" type="authorized"> <part type="ord">Enel</part> <part type="add">Produzione Spa</part> <part type="normal">Enel Produzione Spa</part> <existdate normal="yyyymmdd-yyyymmdd"/> <place type="sede legale"/> <place type="area di intervento"/> </conhead> </identity>

Authorized form of name The name used to arrange

alphabetically the list of entities Other integrations of the name The whole of the name Existing date(s) Registered office Jurisdiction area

<conhead>, instead of <corphead>, in order to apply a unique data element set for all the authority files typologies

The whole of the name is composed automatically with the data filled in the previous elements. The variant forms of the name(s) include the same description elements, except for the value of the TYPE attribute of <conhead>, that is “parallel”

eac/condesc/desc/bioghist <bioghist> </bioghist>

History of the company

eac/condesc/desc/eacrels <eacrels> <eacrel syskey="" reltype="subordinate" type="partecipata"/> <eacrel syskey="" reltype="superior" type="azionista"/> </eacrels>

Shareholder of Shares held by

<corpname> is not used here, in order to apply a unique data element set for all the authority files typologies

The reason why this information is included in <eacrels> section, instead of <assetstruct> subelements, is to refer to the other company entities and to define the type of relationship with them.

eac/condesc/desc/funactdesc <funactdesc> <descentry type="ambito attività"> <value/> </descentry> </funactdesc>

Functions and activity Activity Activity description

17

3.2.2. ISAAR-EAC-EAC xDams subset This mapping intends to display the ISAAR2nd edition fields and the beta version of EAC, according to the official EAC/ISAAR Crosswalk available on http://jefferson.village.virginia.edu/eac/documentation/ISAAR2EACbeta.html, together with the EAC elements and attributes used by the institution mentioned above, within their xDams applications. A brief description provides information about the differences and the reasons of the specific need. If the explanation includes information on the EAC standard changes or remarks, the text is in blue.

ISAAR section ISAAR Element name EAC Tag/attribute name EAC Path used or other remarks Comments

5. ELEMENTS OF DESCRIPTION

5.1 IDENTITY AREA identity In this section all the used elements have the EA attribute filled with the respective ISAAR field

5.1.1 Type of entity eac@type

The value used in the TYPE attribute are • corporatebody • person • family

The values of the TYPE attribute are different in the Tag Library and in the XML Schema (corpname, persname, famname). Which are the wrong values?

5.1.2 Authorized form(s) of name

corphead OR pershead OR famhead

eac/condesc/identity/conhead[@ea='ISAAR5-1-2' and @type='authorized'] composed by: part[@type='ord'] part[@type='first'] part[@type='add'] part[@type='normal']

5.1.3 Parallel forms of name corpgrp/corphead OR persgrp/pershead OR famgrp/famhead

eac/condesc/identity/conhead[@ea='ISAAR5-1-3 and @type='parallel'] composed by: part[@type='ord'] part[@type='first'] part[@type='add'] part[@type='normal']

5.1.4 Standardized forms of name according to other rules

corphead OR pershead OR famhead

eac/condesc/identity/conhead[@ea='ISAAR5-1-4' and @type='otherules'] composed by: part[@type='ord'] part[@type='first'] part[@type='add'] part[@type='normal']

5.1.5 Other forms of name corphead OR eac/condesc/identity/conhead[@ea='ISAAR5-1-4' and

The names of the heading elements have been replaced by a unique <conhead> (Context Heading). The user has the use of three subelements: <part type="ord"> for the part of the name used to arrange alphabetically the list of entities; <part type="first"> for the forename or other name’s specifications; <part type="add"> for other integrations. All the data filled in them compose automatically the content of <part type='normal'>. The use of other heading subelements to compose the controlled heading form(s) is ongoing (please see 3.1. paragraph of this report). Anyway, as “the notion of "authorized heading" and "variant heading" is not explicitly privileged in the naming of the elements” (Please see EAC beta version Tag Library) xDams don’t use the AUTHORIZED attribute.

18


pershead OR famhead

@type='variant'] part[@type='ord'] part[@type='first'] part[@type='add'] part[@type='normal']

5.1.6 Identifiers for corporate bodies legalid eac/condesc/identity/legalid[@ea='ISAAR5-1-6']

5.2 DESCRIPTION AREA desc

As well as the type of entity is specified in the TYPE attribute of <eac>, <*desc> elements are not used. In this section all the used elements have the EA attribute filled with the respective ISAAR field.

5.2.1 Dates of existence existdesc/existdate eac/condesc/desc/existdesc/existdate[@ea='ISAAR5-2-1'] eac/condesc/desc/existdesc/existdate[@normal='yyyymmdd-yyyymmdd']

The existing date(s) are filled in three forms for the beginning day, month and year, and other three forms for the last day, month and year. All the data filled in them compose automatically the content of <existdate normal=""> according to ISO8601 standard.

5.2.2 History bioghist eac/condesc/desc/bioghist[@ea='ISAAR5-2-2']/p

5.2.3 Places location/place eac/condesc/desc/locations[@ea='ISAAR5-2-3']/place eac/condesc/desc/locations[@ea='ISAAR5-2-3']/descnote eac/condesc/desc/locations[@ea='ISAAR5-2-3']/date

The three mentioned elements are repeatable together

5.2.4 Legal status legalstatus eac/condesc/desc/legalstatus[@ea='ISAAR5-2-4'/value

5.2.5 Functions, occupations and activities

funactrels funactrel eac/condesc/desc/funactdesc[@ea='ISAAR5-2-5']/p Every textual information is entered in this

element

5.2.6 Mandates/Sources of authority causa eac/condesc/desc/causa[@ea='ISAAR5-2-6']/p

5.2.7 Internal structures/Genealogy assetstruct eac/condesc/desc/assetstruct[@ea='ISAAR5-2-7']/p

5.2.8 General context env eac/condesc/desc/env[@ea='ISAAR5-2-8']/p

5.3 RELATIONSHIPS AREA eacrels eacrel In this section all the used elements have the EA

attribute filled with the respective ISAAR field.

5.3.1 Name/Identifier of the related corporate

eacrel@syskey AND

eac/condesc/eacrels/eacrel[@type='person|corporatebody|family']/persname or corpname or famname[@ea='ISAAR5-3-1']

The TYPE attribute provide the type of the entity at an higher level, so that the <*name> could be

19


bodies, persons or families

corpname OR persname OR famname

replaced by a unique element, <name>.

5.3.2 Category of relationship eacrel@reltype eac/condesc/eacrels/eacrel[@type='person|corporatebody|fami

ly']/@reltype

The “child” and “parent” values of the RELTYPE attribute are not comprehensive of any other relationships with other members of the family, so we have adopted the “familiar” value, together with the <descnote> element, allowing to explain the type of the familiar relationship. In this attribute we hope to have another value among those predefined, in order to encode the relationship with archival holdings authorized entries of external descriptive systems, ISIAH compliant.

5.3.3 Description of relationship eacrel/descnote eac/condesc/eacrels/eacrel[@type='person|corporatebody|fami

ly']/descnote[@ea='ISAAR5-3-3']

5.3.4 Dates of the relationship eacrel/date eac/condesc/eacrels/eacrel[@type='person|corporatebody|fami

ly']/date[@ea='ISAAR5-3-4']

5.4 CONTROL AREA eacheader In this section the EA attribute has been kept off sometimes, because more than one EAC path accord to one ISAAR field.

5.4.1 Authority record identifier eacid eac/eacheader/eacid

5.4.2 Institution identifiers eacid@ownercode eac/eacheader/eacid/@ownercode and @countrycode

5.4.3 Rules and/or conventions ruledecl eac/eacheader/ruledecl[@ea='ISAAR5-4-3']/rule

5.4.4 Status eacheader@status eac/eacheader/@status

5.4.5 Level of detail eacheader@detaillevel eac/eacheader/@detaillevel

5.4.6 Dates of creation, revision or deletion mainhist

eac/eacheader/mainhist/mainevent/@maintype eac/eacheader/mainhist/mainevent/name eac/eacheader/mainhist/mainevent/maindate

The three mentioned elements are repeatable together and are filled automatically: <name> with the name who attended the record; the MAINTYPE attribute with the type of event, and <maindate> with the date of the event

5.4.7 Language(s) and script(s) languagedecl eac/eacheader/languagedecl[@ea='ISAAR5-4-7']/language

20


5.4.8 Sources sourcedecl eac/eacheader/sourcedecl[@ea='ISAAR5-4-8']/source

5.4.9 Maintenance notes maindesc eac/eacheader/mainhist/mainevent/maindesc[@ea='ISAAR5-4-9']

6

RELATING CORPORATE BODIES, PERSONS AND FAMILIES TO ARCHIVAL MATERIALS AND OTHER RESOURCES

resourcerels/resourcerel In this section the EA attribute has been kept off sometimes, because more than one EAC path accord to one ISAAR field.

6.1 Identifiers and titles of related resources

archunit/unitid archunit/unittitle bibunit/title musunit/title

eac/condesc/resourcerels/resourcerel/archunit/unittitle eac/condesc/resourcerels/resourcerel/archunit/unittitle/@id

The ID attribute is composed automatically with the system code of the <EAD> or description unit instance, if linked to an external information system

6.2 Types of related resources

It could be better to use the TYPE attribute of <resourcerel>, instead of <archunit>, <bibunit> and <musunit> elements, to distinguish the type of related resource. The scope of this purpose is to prevent the proliferation of new elements with a more simple definition of a set of predefined values of a unique attribute, such as: archunit, bibunit, musunit, artunit, audiounit, photounit, other

6.3 Nature of relationship resourcerel@reltype eac/condesc/resourcerels/resourcerel/@reltype eac/condesc/resourcerels/resourcerel/descnote

6.4 Dates of related resources and/or relationships

resourcerel/date OR archunit/unitdate OR bibunit/imprint/date OR musunit/imprint/date

eac/condesc/resourcerels/resourcerel/archunit/unitdate eac/condesc/resourcerels/resourcerel/date

21

4. Proposals of changes and improvements of EAC beta version On the basis of the issues and material supplied in paragraph 3., some purposes of encoding solutions are listed below:

1. to define the values of the TYPE attribute of <eac> element univocally: the values of the TYPE attribute of <eac> are different in the Tag Library (corporatebody, person, and family) and in the XML Schema (corpname, persname, famname);

2. to replace the heading elements <*head> with one element only, such as <conhead>, because the type of entity is specified in the TYPE attribute of <eac> already;

3. to provide a separate definition of the authorized heading and the authorized form of name. In the Tag Library, i.e., even if the <*head>, <identity>, and <part>definitions are quite focused, the following sections use “name” in a equivocal way:

- Overview of EAC Structure and Semantics / <condesc>: “<identity> Complex structure containing the name or name used by the entity over the course of his, her, or its existence”;

- Overview of EAC Structure and Semantics / <identity>: “[…] In addition to needing to accommodate one or more names used for or by the entity, <identity> must accommodate […]”;

- <*grp> definitions: “An element used to associate parallel corporate/family/personal names in various languages or script forms”.

4. to remove the HEADTYPE attribute from the <*head> and <eacrel> definitions of the EAC beta version Tag Library;

5. to remove, in the <desc> section, the <*desc> and to encode the description information in the <*desc> subelements directly, as well as the type of entity is specified in the TYPE attribute of <eac>;

6. to use the TYPE attribute of <eacrel> to encode the type of the entity, so the <*name> subelements could be replaced by a unique element, such as <name>;

7. to include “familiar” value in RELTYPE attribute, instead of “child” and “parent”, that are not comprehensive of any other relationships with other members of the family;

8. to have another value among those of the RELTYPE attribute of <eacrel> element, in order to encode the relationship with authorized names of archival repositories described in external descriptive systems, ISIAH compliant as well;

9. to use the TYPE attribute of <resourcerel>, instead of <archunit>, <bibunit> and <musunit> elements, to distinguish the type of related resource. This proposal of change aims to prevent the proliferation of new elements, defining a simple definition of a predefined values set within one attribute only, which could be: archunit, bibunit, musunit, artunit, audiounit, photounit, other.

Even if the projects explained above adopt solutions getting off EAC and ISAAR, both focused on the subject creators encoding, EAC is the unique XML data element set conceived to encode access points relevant to deepen the contextual information. For this reason some xDams applications have gave an extensive interpretation of the standard.

The archival metadata delivering and exchange should set up rules to encode all the contextual information in the network environment. So, what is the contextual information? By which entities it is constituted? Which are their characteristics? These could be the questions to answer in the next EAC version.

EAC BETA STANDARD:REVIEW

Comments by Giovanni Michetti, Stella Di Fazio, Chiara Veninata

1.

Proposal:To change the high-level design of EAC by eliminating any specific reference to the type of entity, using instead a more general concept of entity in order to eliminate redundancies, design a clearer architecture, and increase coherence with ISAAR.

Rationale:In EAC, inside the high-level <identity> element you can find <persgrp> & <pershead>, <famgrp> & <famhead>, and <corpgrp> & <corphead>. Similarly, inside the high-level <desc> element you can find <persdesc>, <famdesc>, and <corpdesc>. Actually, <persgrp>, <famgrp>, and <corpgrp> have exactly the same content model; and so do <pershead>, <famhead>, and <corphead>. They are not different elements. They use exactly the same informative elements/metadata/attributes with the same structure to describe entity which differ only by nature/tipology: the proper solution is then using an attribute associated multi-purpose elements, let’s say <entitygrp> and <entityhead>. One could argue that this is good for those elements, while <persdesc>, <famdesc>, and <corpdesc> have different content models: that’s true, but actually they differ for a very little portion. The differences among them are represented below:

<corpdesc> <famdesc> <perdesc><corptype> --- <sex>

<causa> --- ---<assetstruct> <assetstruct> <character>

Compared to <corpdesc>, <famdesc> differ for two elements (there is no <corptype> nor <causa>), and <persdesc> differ for three (there is a <sex> instead of <corptype>, no <causa>, and a <character> instead of <assetstruct>). And let’s recall the remaining seven element are the same for <persdesc>, <famdesc>, and <corpdesc>.

So, even in this case a strategy based on a single element still holds: an element <entitydesc> could be - in the worst case - just a least common multiple of all of the elements contained inside the elements above, i.e. the common seven element added with <corptype>, <causa>, <assetstruct>, <sex>, and <character>. And one could ‘activate’ them only if required. However this straightforward methodology could be easily improved by simply extending the meaning of some elements to make them usable in different contexts: the semantics of <assetstruct> could be generalized so to overlap with <character>; and the semantics of <corptype> doesn’t seem too far away from <sex>.

It must also be noted that the change proposed is perfectly coherent with ISAAR, or better still with ISAAR development: the first edition of ISAAR was built upon the same conceptual model of EAC (referring to this profile), using different areas for different entities (persons, families, and corporate bodies). The second edition discarded that modelling and adopted a more abstract view without any specific element - or even wrapper - devoted to a specific type of entity, and providing a full set of elements for any kind of description. Moreover, it is worthy remembering this is the modelling adopted in ISAD and EAD (see the concept of ‘unit of description’ in ISAD and <c> in EAD). So, a decision to maintain a model like this for EAC should be avoided and - in case - justified to explain such a different approach compared to ICA and EAD models.

Change:To modify the high-level design of EAC substituting the elements <persgrp>, <famgrp>, <corpgrp> with a single element <entitygrp>; the elements <corphead>, <pershead>, <famhead> with a single element <entityhead>; the elements <persdesc>, <famdesc>, and <corpdesc> with a single element <entitydesc>.

The DTD should be changed. The current definition of <identity> element is:

<!ELEMENT identity (head? , (legalid* , ((persgrp | pershead)+ | (corpgrp | corphead)+ | (famgrp | famhead)+) , nameadds* , didentifier* , ((sourceref | sourcerefs)? , (descnote | descnotes)?))) >

It should be changed to:

<!ELEMENT identity (head? , (legalid* , ((entitygrp | entityhead)+) , nameadds* , didentifier* , ((sourceref | sourcerefs)? , (descnote | descnotes)?))) >

where

<!ELEMENT entitygrp ((entityhead, entityhead+), nameadds* , (sourceref | sourcerefs)? , (descnote | descnotes)?)>

and

<!ELEMENT entityhead (part+ , ((existdate | place | nameadd)* , usedate? , (sourceref | sourcerefs)? , (descnote | descnotes)?)) >

The current definition of <desc> element is:

<!ELEMENT desc (head? , ((corpdesc | persdesc | famdesc)? , (bioghist | ocd)*)) >

It should be changed to:

<!ELEMENT desc (head? , (entitydesc? , (bioghist | ocd)*)) >

where the element <entitydesc> is to be designed. I could straightforward be designed like:

<!ELEMENT entitydesc (head?, (existdesc?, (corptype|sex|legalstatus|location|descentry)*, (locations|causa|funactdesc|assetstruct|character|env|ocd)*)) >

2.

Proposal: To state clearly that EAC is a standard aimed at guiding the description not only of records creators but also of any entities related - in a very wide meaning - to archival materials, in coherence with ISAAR, explicitly assumed as a fundamental reference.

Rationale:Actually, even about ISAAR there is a major misunderstanding, because it is quite often presented and intended for descriptions of creators only rather then for any entities associated in some way to archival materials. Unambiguously in ISAAR 1.1 - the very first statement of ISAAR - it is written that “This standard provides guidance for preparing archival authority records which provide descriptions of entities (corporate bodies, persons and families) associated with the creation and maintenance of archives” i.e. not only to the records creator. It is also true that ISAAR refers nearly always to records creator in the subsequent paragraphs but - as a general and final rule - the last statement about scope and purpose (ISAAR 1.11) states that “An archival authority record that conforms to this standard may also serve to control the form of name and identity of a corporate body, person or family named in an access point that is related to the unit of archival description” so definitely allowing and confirming ISAAR as a “general purpose” standard indeed, not restricted to records creators.

EAC presents a sort of ambiguity such that. In more than a point it is stated that EAC refers to records creators:• the purpose of EAC is “to encode descriptions of persons, corporate bodies, and families responsible for the

creation of records and other resources” (DTD Beta, Introduction)

• “the <condesc>-context description comprises the description of the creating entity” (EAC Tag Library, Overview of EAC Structure and Semantics). Actually it should be noted that the semantics of the element is more general: the specific <condesc> element in the Tag Library is described as “a container element for the bulk of an EAC instance consisting of groups of elements for identifying and describing a corporate body, person or family” without any reference to the creation process

• “EAC is an ongoing initiative within the international archival community to design and implement a prototype standard based on XML for encoding descriptions of record creators” (D. Pitti, Creator Description. Encoded Archival Context, http://www.unifi.it/universita/biblioteche/ac/relazioni/pitti_eng.pdf). One could properly argue this is not an official source of reference; however it is presented here because of the relevance of the speaker.

So far it seems EAC refers to records creators. Fortunately - in our view - there is a fundamental statement which invalidate such a view. It is worthy recalling the Toronto Tenets (Definition and Uses):

1. “Archival context information consists of information describing the circumstances under which records (defined broadly here to include personal papers and records of organizations) have been created and used. This context includes the identification and characteristics of the persons, organizations, and families who have been the creators, users, or subjects of records, as well as the relationships amongst them.

2. Context information is not metadata that describes other information resources, but information that describes entities that are part of the environment in which information resources (i.e., records) have existed.

3. The recording of context information in archival information systems directly supports a more complete description and understanding of records as well as the provenance approach to retrieval of these records across time and domains”.

Toronto Tenets clearly state a more general purpose of EAC (it’s not by chance it is called encoded archival Context and not EARC - Encoded Archival Record Creator). So there are two possibilities: either Toronto Tenets are not any more assumed as a fixed reference, and in this case it should be stressed and clearly stated by the Committee for the sake of transparency; or the Toronto Tenets still hold, and any specific reference in the official sources to the records creators must be deleted.

Change:To delete in the official sources any specific reference that restrains the use of EAC to the records creators.

3.

Proposal:To provide more granular elements inside <funactdesc> and <assetstruct> in order to make EAC suitable for more specialized descriptions.

Rationale:There is a growing need for standardization in archives but it can be accomplished by simply defining new standards for every minute aspect of archival practice. Archival institutions and associations in each country, and international committees should have a general project giving the archival community a clear idea of framework, objectives and strategies. The recent development of ISIAH by the International Council on Archives has rightly raised some doubts and questions about the co-ordination of ICA standards. We don’t think we need another standard for ‘Institutions with Archival Holdings’ (and what about Individual, or Families with Archival Holding? is there an ISFAH coming soon?). Of course this is not a matter for the EAC Committee but it is significant for the EAC model, and it strongly related to Proposal #2. We don’t know whether ISIAH will find its way or not but we could catch the needs it supports. In short, even if ISIAH will be approved as a standard, there is no reason to keep on matching one ICA standard onto one EA* standard (don’t forget ISAF: an EAF is on its way? :-) EAC is about context, and could contain the element needed by ISIAH (or at least we could try). Why not refining the <funactdesc> or <assetstruct> elements in order to - possibly - use them for a description? If it seems too hard, why not try with a specific high-level element grouping administrative/structural specific information? We think it’s worthy trying a more complete solution (a project) rather then running after every new standard.

Change:Provided that many more elements could be defined, the table below shows a very rough mapping between ISIAH and EAC. At least these elements could be inserted into EAC.

ISIAH EAC5.1 IDENTITY AREA5.1.1 Identifier eac/condesc/identity/legalid5.1.2 Authorised forms(s) of name eac/condesc/identity/corphead5.1.3 Parallel form(s) of name eac/condesc/identity/corphead5.1.4 Other form(s) of name eac/condesc/identity/corphead5.1.5 Type eac/condesc/desc/corpdesc/corptype5.2 CONTACT AREA5.2.1 Address(es) eac/condesc/desc/corpdesc/location/address/addressline

[@type=”address”]5.2.2 Telephone, fax, email Two different proposals:

• eac/condesc/desc/corpdesc/location/address/addressline [@type=”telfaxemail”]

• a specific new element inside <address>:eac/condesc/desc/corpdesc/location/address/telfaxemail

5.2.3 Website Two different proposals:• eac/condesc/desc/corpdesc/location/address/addressline

[@type=”website”]• a specific new element inside <address>:eac/condesc/desc/corpdesc/location/address/website

5.2.4 Officers in charge A specific new element inside <assetstruct>5.3 DESCRIPTION AREA5.3.1 Geographical and cultural context eac/condesc/desc/corpdesc/env5.3.2 History eac/condesc/desc/bioghist5.3.3 Administrative structure eac/condesc/desc/corpdesc/assetstruct5.3.4 Collecting policies eac/condesc/desc/corpdesc/descentry[@type=”collecting_policies”]5.3.5 Building(s) eac/condesc/desc/corpdesc/location5.3.6 Archival and other holdings eac/condesc/rsourcerels/resourcerel/archunit5.3.7 Finding aids and publications eac/condesc/rsourcerels/resourcerel/bibunit5.4 ACCESS AREA5.4.1 Opening times5.4.2 Conditions and requirements5.4.3 Disabled access5.4.4 Transport

Different proposals:• eac/condesc/desc/ocd/descentry[type=”…”]• a specific wrapper inside <ocd>• a specific wrapper in <condesc>

5.5 SERVICES AREA5.5.1 Research services5.5.2 Reproduction services5.5.3 Public facilities

Different proposals:• eac/condesc/desc/corpdesc/funactdesc[type=”…”]• specific elements inside <funactdesc>• specific elements in <desc>

CONTROL AREA5.6.1 Description identifier eac/eacheader/eacid5.6.2 Institution identifier eac/eacheader/mainhist/mainevent/name5.6.3 Rules and/or conventions used eac/eacheader/ruledecl/rule5.6.4 Status eac/eacheader[@status]5.6.5 Level of detail eac/eacheader[@detaillevel]5.6.6 Dates of creation, revision or deletion

eac/eacheader/mainhist/mainevent/maindate

5.6.7 Language(s) and script(s) eac/eacheader/languagedecl/language5.6.8 Sources eac/eacheader/sourcedecl/source5.6.9 Maintenance notes eac/eacheader/mainhist/mainevent/maindesc6. RELATING ARCHIVAL INSTITUTION …6.1. Title and identification of related archival material

eac/condesc/resourcerels/resourcerel/archunit/unittitle/unitid

6.2 Description of relationship eac/condesc/resourcerels/resourcerel/descnote6.3 Dates of relationship eac/condesc/resourcerels/resourcerel/date6.4 Authorised form(s) of name and identifier of …

eac/condesc/resourcerels/resourcerel/descnote[actually ISIAH 6.4 should be suppressed: it has no sense there]

4.

Proposal:To change the definition of the attributes of <eac> by adding an attribute ROLE to better specify the role of the entity.

Rationale:The current definition of <eac> attributes is:<!ATTLIST eac id ID #IMPLIED ea NMTOKEN #IMPLIED type (corpname , persname , famname) #REQUIRED > According to Proposal #2 an EAC description could refer not only to a records creator and so it is not enough to say it is a corporate, an individual, or a family: it must be specified the role. Of course one entity could act with different roles, so the attribute type should allow multiple values.

Change:<!ATTLIST eac id ID #IMPLIED ea NMTOKEN #IMPLIED type (corpname , persname , famname) #REQUIRED > role NMTOKENS #IMPLIED >

5.

Proposal:To change the definition of the attributes of <resourcerel> by adding an attribute ROLE to better specify the role of the entity.

Rationale:The current definition of <resourcerel> attributes is:<!ATTLIST resourcerel id ID #IMPLIED ea NMTOKEN #IMPLIED reltype (origination, destruction, control, causa, subject, other) #IMPLIED …. rule IDREF #IMPLIED >

According to Proposal #2 an EAC description could refer not only to a records creator and so an important value is the one referred to the custody. Actually there is a “control” value, or an “other” value suitable for that use, but they are too general, and if “causa”, “subject”, or “destruction” have been explicitly designed there’s no reason to not mention the custodial history.

Change:<!ATTLIST resourcerel id ID #IMPLIED ea NMTOKEN #IMPLIED reltype (origination, custody, destruction, control, causa, subject, other) #IMPLIED …. rule IDREF #IMPLIED >

Anyway a more precise semantics for the values is required: as mentioned before “control” overlaps a bit with origination and destruction because creation and destruction are a form of control over archival materials. At the very minimum the definition “control: referenced resource is controlled in some way by the described entity” could be changed in “control: referenced resource is controlled in some other way by the described entity” so giving a ‘residual’ meaning to this value. But a better solution could be identified

6.

Proposal:To refine the EAC-ISAAR mapping providing a more granular crosswalk designed evaluating the match of each EAC

element against ISAAR model; and designing an ISAAR-EAC crosswalk.

Rationale:The current mapping provided in the Tag Library is not precise and it is based on an old release of ISAAR. And it seems the mapping has not been made in a systematic way because there are still EAC elements that could be mapped (e.g. <ruledecl> can be mapped against ISAAR 5.4.3 Rules and/or conventions).

Change:Below some comments on the mapping proposed in the Tag Library, yet stressing the need for a review of the full set of EAC elements, and a careful designation of the ISAAR elements.

EAC ISAAR Comment<bioghist> 5.2.2 History OK<causa> 5.2.6 Mandate(s)/source(s) of authority OK<corpdesc> 5.2 Description area It’s correct but maybe it’s better not to map

onto areas because there’s no use in it<corpgrp> 5.1.3 Parallel forms of name OK<corphead> 5.1.2 Authorized form of name

5.1.3 Parallel form of name5.1.4 Standardized form of name according to other rules5.1.5 Other forms of name

5.1.2 Authorized form(s) ...5.1.3 Parallel forms ...5.1.4 Standardized forms …

<corptype> 5.2.4 Legal status OK<eacheader> 5.1.1 Type of entity NO.

eac@type maps onto ISAAR 5.1.1<eacid> 5.4.1 Authority record identifier

5.4.1 Institution identifierNO.<eacid> maps onto 5.4.2 Institution identifiers

<eacrel> 5.3 Relationship area It’s correct but maybe it’s better not to map onto areas because there’s no use in it

<eacrels> 5.3 Relationships area It’s correct but maybe it’s better not to map onto areas because there’s no use in it)

<famdesc> 5.2 Description area It’s correct but maybe it’s better not to map onto areas because there’s no use in it

<famgrp> 5.1.3 Parallel forms of name OK<famhead> 5.1.2 Authorized form of name



<funactdesc> 5.2.5 Function, occupations and activity OK (.. and activities)<funactrel> 5.2.5 Function, occupations and activity OK (.. and activities)<identity> 5.1 Identity area It’s correct but maybe it’s better not to map

onto areas because there’s no use in it<languagedecl> 5.4.6 Language(s) and script(s) of

recordNO.It maps onto 5.4.7 Languages and scripts

<langmaterial> ISAD 3.4.3 Language(s) and script(s) of material

NO.It is not correct a mapping onto ISAD here. And anyway there would be more elements to consider

<legalstatus> 5.2.4 Legal status OK<location> 5.2.3 Geographical areas NO.

It maps onto 5.2.3 Places<mainhist> 5.4.7 Dates of creation and revision 1) It should be better an exact mapping from

<mainhist> subelements2) Otherway <mainhist> has to be mapped onto both 5.4.6 Dates of creation, revision or deletion and 5.4.9 Maintenance notes

<ocd> 5.2.9 Other significant information NO.5.2.9 doesn’t exist anymore. <ocd> could be mapped onto 5.2.8 General context

<persdesc> 5.2 Description area It’s correct but maybe it’s better not to map onto areas because there’s no use in it

<persgrp> 5.1.3 Parallel form of name OK<pershead> 5.1.2 Authorized form of name



<sourcedecl> 5.4.8 Notes NO.5.4.8 doesn’t exist anymore. <sourcedecl> could be mapped onto 5.2.6 Mandates/Sources of authority

7.

Proposal:To change the definition of the attribute TYPE of <*head> by providing a closed list of values (authorized, parallel, otherrule, otherform)

Rationale:Considered the mapping above, where an informative element like <*head> can’t be mapped precisely on the proper ISAAR informative element; and given the possibility in EAC to use the attribute TYPE to specify the type of name entered, it seems worthy to provide a clear mechanism to describe the type of name in coherence with ISAAR. It’s not a relevant change but it can be very useful for a more precise mapping because it should be described like pershead@parallel mapped onto ISAAR 5.1.3

Change:The current definition

<!ATTLIST corphead type CDATA #IMPLIED …..>

could be changed to

<!ATTLIST corphead type (authorized, parallel, otherrule, otherform) #IMPLIED …..>

If it seems too strict we could adopt a semi-closed list like<!ATTLIST corphead type (authorized, parallel, otherrule, otherform, othertype) #IMPLIED othertype CDATA #IMPLIED ….>

8.

Proposal:To define precisely the <corphead> and <famhead> attributes

Rationale:In the Tag Library it is written: “For changes of name over time use HEADTYPE to specify if the form was used earlier or later” but there is no HEADTYPE attribute neither in the list associated to the element (in the Tag Library) nor in the schema

Change:HEADTYPE attribute could be useful so it could be associated to any <*head> element

9.

Proposal:To modify the model of <*grp> with reference to <sourcerefs> and <descnotes>

Rationale:The current definition of <*grp> is<!ELEMENT *grp ((*head, *head+), nameadds* , (sourceref | sourcerefs)? , (descnote | descnotes)?)>where<!ELEMENT sourcerefs (head ? , sourceref | sourceref+ ) >

The element <sourcerefs> could be a wrapper containing at least one <sourceref>, so it could be designed like this:<!ELEMENT *grp ((*head, *head+), nameadds* , sourcerefs? , (descnote | descnotes)?)>where<!ELEMENT sourcerefs (head ? , sourceref+ ) >

The same applies to <descnotes> so we could have

<!ELEMENT *grp ((*head, *head+), nameadds* , sourcerefs? , descnotes?)>where<!ELEMENT descnotes (head ? , descnote+ ) >

This choice makes the model clearer but requires more tagging when with a single sourceref or a single descnote, so the proposal must be balanced between costs and profits.

Change:<!ELEMENT *grp ((*head, *head+), nameadds* , sourcerefs? , descnotes?)><!ELEMENT sourcerefs (head ? , sourceref+ ) ><!ELEMENT descnotes (head ? , descnote+ ) >

10.

Proposal:To better define the meaning and objectives of the <funactrels> element

Rationale:It is not clear the difference between <funactrels> element and subelements, and <funactdesc>. It should be clarified where to put more than one function/activity, either in <funactrels> or into <descentry>s inside <funactdesc>?

Change:To refine the definitions of <funactrels>, <funactrel> and <funact> elements

11.

Proposal:To simplify the structure wherever possible

Rationale:To eliminate structures overloading the model. For example, the element <funactrel> is defined like this:<!ELEMENT funactrel (funact, (date?, place, (descnote|descnotes)?, source*))>This can be simplified:<!ELEMENT funactrel (funact, date?, place, (descnote|descnotes)?, source*)>

Change:For <funactrel> element:<!ELEMENT funactrel (funact, date?, place, (descnote|descnotes)?, source*)>

12.

Proposal:To clarify the meaning and use of <source>, <sourceref>, and <sourcerefs> elements.

Rationale:• in the Tag Library it is written that “<source> is a subelement of <sourcedecl> within <eacheader> for specifying the

source for evidence used in describing the entity” while <source> is also nested inside <eacrel> within <eacrel>. Similarly it is stated

• in the Tag Library it is written that “<sourceref> is a reference to the resource providing evidence for the heading or descriptive element container <sourceref>” and it seems a tautology

• it is not clear why there is a (sourceref|sourcerefs)? within <eacrels>, where <sourceref> is modeled as (#PCDATA|emph|lb|abbr|expan|sourceinfo)*; while inside <eacrel> there is simply (source*) modeled as (#PCDATA|name|title|edition|imprint|bibseries|descnote|sourceinfo)*

13.

Proposal:To define a CERTAINTY attribute for date elements (e.g. <date>, or <existdate>)

Rationale:The degree of precision of a date could be very useful, and it is used in EAD yet. Moreover in the Tag Library, at the

definition of <date> element, it is written : The CERTAINTY attribute may be used to indicate the degree of precision in the dating, for example, "circa," "approximately," or "after." there is no CERTAINTY attribute neither in the list associated to the element (in the Tag Library) nor in the schema

Change:To introduce a CERTAINTY attribute for date elements:<!ATTLIST xyz certainty CDATA #IMPLIED ... >

14.Proposal:To define/identify an element for the nationality

Rationale:It is not very easy to accommodate this kind of information because <location> is not a proper element. Probably <legalstatus> could also be used but it doesn’t fit very well. So it should be useful to redefine the semantics of some elements in order to adequately capture this information

15.

Proposal:Of course specific examples for each elements are needed in the Tag Library

Giovanni Michetti (University of Rome “La Sapienza”)Stella Di Fazio (MAAS Research Centre - Methodologies Applied to Archives - Rome)

Chiara Veninata (MAAS Research Centre - Methodologies Applied to Archives -Rome)

Appendix B: Sample of comments from Final draft review in 2009

• Ana Cristan and Frank Dixson, Library of Congress • Abelardo Santamaria, Archivo General de Simancas, Spain • The University of Melbourne, eScholarship Research Centre, EAC‐CPF Feedback

Appendix B: Sample of comments from Final draft review in 2009Cristan and Dixson, Library of Congress

From: "Larry E Dixson" <[email protected]> To: <[email protected]> Cc: "Ana Lupe Cristan" <[email protected]> Subject: EAC-CPF Response Date: Tuesday, October 27, 2009 3:19 PM Ms. Wisser: Following the Webinar about EAC-CPF on October 8, 2009, LC staff with EAD expertise met to further discuss the proposed EAC-CPF schema. The staff present at the meeting had no suggestions or concerns regarding the draft schema or the tag library. You have done a excellent job constructing the tag library and structuring the schema. The comments received from our staff were general concerns about how the EAC-CPF records were going to be gathered, shared, and maintained. Concerns were expressed about possible metadata differences with the EAC-CPF records and records that are present in other authority files (e.g., NACO, and VIAF). Will there be any attempt to keep the metadata in EAC-CPF records synchronized with the NACO file, or will the EAC-CPF file be as independent as the various national files currently represented in VIAF? Assuming that the file will be independent, the importance of implementing heading identifiers, like those proposed in the Functional Requirements for Authority Data was emphasized. Ana Cristan, Policy and Standards Division Larry Dixson, Network Development and MARC Standards Office

Appendix G: Sample of comments from Final draft review in 2009Abelardo Santamaria, Archivo General de Simancas

From: "Abelardo Santamaria" <[email protected]> To: <[email protected]> Subject: Schema Comment Date: Monday, August 24, 2009 3:22 AM Dear Katherine: I send you some suggestions about the EAC-CPF Tag Library Draft (21 august 2009) (URL: http://www3.iath.virginia.edu/eac/cpf/tagLibrary/cpfTagLibrary.html). Best regards, Abelardo Santamaria Archivo General de Simancas (http://www.mcu.es/archivos/MC/AGS/index.html) Comisión de Normas Españolas de Descripción Archivística (CNEDA) (http://www.mcu.es/archivos/MC/CNEDA/Presentacion.html) ---------------------------- Suggestions: (1) In the “Overview of EAC-CPF Structure and Semantics” section, in the "Relations" part, there is the following sentence: "<functionRelation> — includes an attribute @functionRelationType; values are activity, ambientFunction, functions, process, transaction, other. " I think that there is a mistake and the sentence should be: "<functionRelation> — includes an attribute @functionRelationType; values are controls, owns, performs." (2) In the “Overview of EAC-CPF Structure and Semantics” section, in the “@localType: One and The Many” part, there is the following sentence: "This element is intended to enable…" I think that there is a oversight and the sentence should be: "This attribute is intended to enable…" (3) In the “Elements” section, in the ”<functionRelation> Function Relations” element, there is the following title: ”<functionRelation> Function Relations”(plural) I think that there is a oversight and the title should be: ”<functionRelation> Function Relation” (singular) (4) In the “Overview of EAC-CPF Structure and Semantics” section, in the "<cpfDescription>" part, there is not information that explains if the <identity>, <description> and <relations> elements are optional or required. I think that should be better to add this data at the end of each element: "<identity> - Identity. Complex structure containing the name or names used by the entity over the course of the entity’s existence. Contains <nameEntry> elements for different names, and a <nameEntryParallel> for more than one <nameEntry> expressed in different languages. Required.

<description> - Description. Contains formal description elements parallel to those in ISAAR (CPF) for the description of the entity. An additional <descriptiveEntry> allows for local implementation of additional descriptive information not included in the other <description> elements. Optional. <relations> - Relations. Contains one or more references to [or] descriptions of related corporate bodies, persons or families <cpfRelations>, functions <functionRelations>, or resources <resourceRelations>. Optional." (5) In the “Elements” section, in the <maintenanceStatus> element, the "Main contain" part indicates that this element may contain one of the following six values: "cancelled" or "deleted" or "deletedReplaced" or "deletedSplit" or "new" or "revised". However I think that the EAC-CPF Schema (20090821) indicates that the <maintenanceStatus> element may contain one of seven values (the previous values plus "derived"). (6) In the “Elements” section, the <languageDeclaration> element has the "Occurrence: 1", but I think that in the EAC-CPF Schema (20090821) it has the occurrence "0…1". (7) In the “Elements” section, the <sources> element has the "Occurrence: 1", but I think that in the EAC-CPF Schema (20090821) it has the occurrence "0…1". (8) In the “Elements” section, the <agencyCode> element has the "Occurrence: 1", but I think that in the EAC-CPF Schema (20090821) it has the occurrence "0…1". (9) In the “Elements” section, the <eventDescription> element has the "Occurrence: 1", but I think that in the EAC-CPF Schema (20090821) it has the occurrence "0…1". (10) In the “Elements” section, the <language> element has the "Occurrence: 1...8", but I think that in the EAC-CPF Schema (20090821) it has the occurrence "1". (11) In the “Elements” section, the <script> element has the "Occurrence: "0...1", but I think that in the EAC-CPF Schema (20090821) it has the occurrence "1". (12) In the “Elements” section, the <existDates> element has the "Occurrence: "0...8", but I think that in the EAC-CPF Schema (20090821) it has the occurrence "0…1". (13) In the “Attributes” section, in "@cpfRelationType", I think that the possible values of this attribute should have quotation marks and be separated by "or":

"identity" or "hierarchical" or "hierarchical-parent" or "hierarchical-child" or "temporal" or "temporal-earlier" or "temporal-later" or "family" or "associative" (14) In the “Attributes” section, in "@identityType ", I think that the possible values of this attribute should have quotation marks: "given" or "acquired" (15) In the “Attributes” section, in "@resourceRelationType ", I think that the possible values of this attribute should have quotation marks and be separated by "or": "creatorOf" or "subjectOf" or "other" ---------------------------- From: "Abelardo Santamaria" <[email protected]> To: <[email protected]> Subject: Schema Comment Date: Monday, September 07, 2009 3:43 AM Dear Katherine: I send you some suggestions about the EAC-CPF Tag Library Draft (21 august 2009) and the EAC-CPF Schema (21 august 2009). Best regards, Abelardo Santamaria Archivo General de Simancas (http://www.mcu.es/archivos/MC/AGS/index.html ) Comisión de Normas Españolas de Descripción Archivística (CNEDA) (http://www.mcu.es/archivos/MC/CNEDA/Presentacion.html ) ---------------------------- Suggestions: (1) In the “Overview of EAC-CPF Structure and Semantics” section of the EAC-CPF Tag Library Draft, in the "<CPFDESCRIPTION>" part, there is the following sentence: "Similar to the <control>, element, <cpfDescripton> has several complex subelements..." I think that there is a mistake in the name of the last element ("<cpfDescripton>") and should be "<cpfDescription>". (2) In the “Overview of EAC-CPF Structure and Semantics” section of the EAC-CPF Tag Library Draft, in the "<CPFDESCRIPTION>" part, there is the following paragraph: "<relations> - Relations. Contains one or more references to or descriptions of related corporate bodies, persons or families <cpfRelations>, functions <functionRelations>, or resources <resourceRelations>." I think that there is a mistake in the names (plural) of the last three elements and the paragraph should be:

"<relations> - Relations. Contains one or more references to or descriptions of related corporate bodies, persons or families <cpfRelation>, functions <functionRelation>, or resources <resourceRelation>." (3) In the “Elements” section of the EAC-CPF Tag Library Draft, in the <description> element, in the "May contain" part, there is a <placeDates> element. In the “Elements” section, in the element, in the "May occur within" part, there is a <placeDates> element. But there is not a <placeDates> element in the current EAC-CPF Schema. I think that there is a mistake and it should be "<placesDates>". (4) In the “Elements” section of the EAC-CPF Tag Library Draft, in the <term> element, there is the following sentence: "The local authority – thesaurus or local controlled vocabulary – should be declared in the <authorityDeclaration> element within the <control> section." But there is not a <authorityDeclaration> element in the current EAC-CPF Schema. I think that there is a mistake and the sentence should be: "The local authority – thesaurus or local controlled vocabulary – should be declared in the <localTypeDeclaration> element within the <control> section." (5) In the "Attributes" section of the EAC-CPF Tag Library Draft, in the @notAfter Attribute, there is the following sentence: "The @notAfter may occur on <dateSingle>..." In the "Attributes" section, in the @notBefore Attribute, there is the following sentence: "The @notBefore may occur on <dateSingle>..." In the "Attributes" section, in the @standardDate Attribute, there is the following sentence: "The @standardDate may occur on <dateSingle>... The value of @standardDate provides a standard form of the date expressed in <dateSingle>..." But there is not a <dateSingle> element in the current EAC-CPF Schema. I think that there is a mistake and it should be "<Date>". (6) In the "Attributes" section of the EAC-CPF Tag Library Draft, in the @resourceRelationType Attribute, there is the following sentence: "The @ResourceRelationType may occur on..." I think that there is a mistake in the name "ResourceRelationType" and it should be "resourceRelationType". (7) In the “Elements” section of the EAC-CPF Tag Library Draft, in the <multipleIdentities> element, there is the following paragraph: "A wrapper element to encode more than one <cpfDescription> in a single EAC-CPF instance. An EAC-CPF instance can contain more than one <cpfDescription> in one of two ways. The first is used to represent more than one persona (including official personae) each with a separate

description; the second is used to represent a collaborative personae which includes multiple individuals operating under a shared personae (such as a shared pseudonym)." This paragraph includes the Latin word "persona" (and its plural "personae") that means "mask" (I.e., an identity). So this paragraph is very confused for a Spanish reader because the Spanish word "persona" means "person" (I.e.,a real individual). I think that should be better to remove the Latin words "persona" and "personae" and to include the words "identity" or "identities" (Such as in the "EAC-CPF Concepts" section). In the "Attributes" section, in the @identityType attribute, there is the same problem: "It will enable processors to distinguish between the description of a person and one or more personae." (8) In the "Attributes" section of the EAC-CPF Tag Library Draft, the @relatedResourceType attribute indicates that this attribute of the <resourceRelation> element can include the value "library", "archival", "museum", "monument" or "site", and "If a more specific type is needed for local processing, @xlink:role may be used in addition to @relatedResourceType". I think that this information is insufficient if we want to encode related types of resources in the same way, because there is a need to explain the meaning of the different values ("library", "archival", "museum", "monument" and "site") and its use. For example: If the related resource is a record kept in a Museum, which is the appropriate value of the @relatedResourceType attribute?, "archival" or "museum"? (9) In the "Attributes" section of the EAC-CPF Tag Library Draft, the @resourceRelationType attribute indicates that this attribute of the <resourceRelation> element can include the value "creatorOf", "subjectOf" or "other", and "If the nature of the relation is more specific than one of the available values, @xlink:arcrole may be used in addition to @resourceRelationType". I think that this information is insufficient if we want to encode common roles in the same way. For example: How can I encode the "authorOf" value?; Does the "creatorOf" value include the "authorOf" value?. According to ISAD(G)2 and ISAAR(CPF)2 the "creator", the "author" and the "collector" are different roles: - "Author. The individual or corporate body responsible for the intellectual content of a document. Not to be confused with creators of records." (ISAD(G)2) - "Creator. The corporate body, family or person that created, accumulated and/or maintained records in the conduct of personal or corporate activity. Not be confused with collector." (ISAD(G)2) - "Creator. Any entity (corporate body, family or person) that created, accumulated and/or maintained records in the conduct of personal or corporate activity." (ISAAR(CPF)2), ISDF)

- "Creator. Any entity (corporate body, family or person) that created, accumulated, maintained and/or used records maintained records in the conduct of personal or corporate activity." (ISDIAH) - "6.3 Nature of relationships. Purpose: To identify the nature of the relationships between the corporate body, person or family and the related resources. Rule: Describe the nature of the relationships between the corporate body, person or family and the related resource, e.g. creator, author, subject, custodian, copyright owner, controller, owner." (ISAAR(CPF)2, 6.3) I think that should be better: - To explain in the EAC-CPF Tag Library the different meaning of "creator", "author" and "collector". - To add in the @resourceRelationType attribute of the <resourceRelation> element of the EAC-CPF Schema the values "authorOf" and "collectorOf". (10) According to the EAC-CPF Tag Library Draft, the <functionRelation> element contains the description of a function related to the described entity, and the @relatedFunctionType attribute of <functionRelation> includes a value that designates the type of function related to the entity being described ("ambientFunction", "function", "activity", "process", "transaction" or "other"). I.e., the <functionRelation> element allows to encode a description of a related "ambientFunction", "function", "activity", "process", "transaction", etc. The name "functionRelation" of the element (<functionRelation>) has a generic meaning, due to it can refer not only to a related "ambientFunction" or "function", but also to a related "activity", "process", "transaction", etc. However, according to the EAC-CPF Tag Library Draft, in the <description> element there are two specific elements to encode a function or an activity performed by the entity being described: <function> and <activity> (the <functions> element includes one or more <function> elements, and the <activities> element one or more <activity> elements). In this case, I suppose that the <function> element only allows to encode a term that identifies an "ambient function" or a "function", and that the <activity> element only allows to encode a term that identifies an "activity". But in the <function> or <activity> element I cannot include a term that identifies a "process", "transaction", etc. I think that there is a contradiction between the encoding way of the <functionRelation> element and the encoding way of the <function> and <activity> elements. I think that should be better: - To eliminate the <activity> and <activities> elements of the EAC-CPF Schema. - To maintain the <function> and <functions> elements in the EAC-CPF Schema. - To add a new attribute (for example, @functionType) for the <function> Element to include a value that designates the type of function ("ambientFunction", "function", "activity", "process", "transaction" or "other"). - To explain in the EAC-CPF Tag Library that the <function> element has a generic meaning, and allow to encode not only a term that identifies an "ambient function" or "function", but also a term that identifies an "activity", "process", "transaction", etc.

----------------------- From: "Abelardo Santamaria" <[email protected]> To: <[email protected]> Subject: Schema Comment Date: Wednesday, September 09, 2009 6:52 AM Dear Katherine: I send you one suggestion about the EAC-CPF Schema (21 august 2009). Best regards, Abelardo Santamaria Archivo General de Simancas (http://www.mcu.es/archivos/MC/AGS/index.html) Comisión de Normas Españolas de Descripción Archivística (CNEDA) (http://www.mcu.es/archivos/MC/CNEDA/Presentacion.html) ---------------------------- Suggestion: (1) In the "Attributes" section of the EAC-CPF Tag Library Draft, the @resourceRelationType attribute indicates that this attribute of the <resourceRelation> element can include the value "creatorOf", "subjectOf" or "other", and "If the nature of the relation is more specific than one of the available values, @xlink:arcrole may be used in addition to @resourceRelationType". But I think that, according to ISAAR(CPF)2 and ISDIAH, the “custodian” is other possible common role: - "6.3 Nature of relationships. Purpose: To identify the nature of the relationships between the corporate body, person or family and the related resources. Rule: Describe the nature of the relationships between the corporate body, person or family and the related resource, e.g. creator, author, subject, custodian, copyright owner, controller, owner." (ISAAR(CPF)2, 6.3) - “1.5 As corporate bodies, persons or families, the holders of archival materials may be described in ISAAR(CPF) compliant authority records including the appropriate elements of description as indicated in ISDIAH. Otherwise, the description of holders may be included in separate authority files. In this case, links between the relevant authority records should be made.” (ISDIAH, 1.5) Consequently, I think that should be better: - To add in the @resourceRelationType attribute of the <resourceRelation> element of the EAC-CPF Schema the value "custodianOf". - To add in the EAC-CPF Schema some necessary elements and attributes to allow the encoding of descriptions of “institutions with archival holdings” according to some especialized elements of ISDIAH (Location and address; Telephone, fax, email; Contact persons; etc.]. Like this the EAC-CPF Schema could allow the encoding of all descriptions of agents (corporate bodies, persons or families), independently of the

roles (creator, author, subject, custodian, etc.) that the agent plays with regard to the archival materials. ---------------------------- From: "Abelardo Santamaria" <[email protected]> To: <[email protected]> Subject: Schema Comment Date: Wednesday, September 09, 2009 7:35 AM Dear Katherine: I send you some suggestions about the EAC-CPF Tag Library Draft (21 august 2009) and the EAC-CPF Schema (21 august 2009). Best regards, Abelardo Santamaria Archivo General de Simancas (http://www.mcu.es/archivos/MC/AGS/index.html) Comisión de Normas Españolas de Descripción Archivística (CNEDA) (http://www.mcu.es/archivos/MC/CNEDA/Presentacion.html) ---------------------------- Suggestions: (1) According to the “Appendix ISAAR(CPF) Crosswalk” of the EAC-CPF Tag Library Draft, the data of the ISAAR(CPF)2 element “5.4.5 Level of detail” must be encoded in the <localControlEntry> element. In the ISAAR(CPF)2 there is the following rule: - “5.4.5 Level of detail. Purpose: To indicate whether the authority record applies a minimal, partial or a full level of detail. Rule: Indicate whether the record consists of a minimal, partial or full level of detail in accordance with relevant international and/or national guidelines and/or rules. In the absence of national guidelines or rules, minimal records are those that consist only of the four essential elements of an ISAAR(CPF) compliant authority record (see 4.8), while full records are those that convey information for all relevant ISAAR(CPF) elements of description.” For example, if I want to encode a “minimal”, “partial” or “full” level of detail (values established in the ISAAR(CPF)2 international standard) I think that: - I must include one value (“minimal”, “partial” or “full”) in a <term> element, inside a <localControlEntry> element. - I must include an @localType attribute in <localControlEntry>, for example with the value “http://www.ica.org/sites/default/files/ISAAR2EN.pdf”(ISAAR(CPF)2) - If I want to declare the ISAAR(CPF)2 international standard, I must use the <localTypeDeclaration> element.

But, according to the EAC-CPF Tag Library Draft, the <localTypeDeclaration> element “is available to declare the local conventions and controlled vocabularies in @localType” and not for an international standard. So I can´t find a satisfactory way of encoding a “minimal”, “partial” or “full” level of detail, according to the ISAAR(CPF)2 international standard. (2) In the “Elements” section of the EAC-CPF Tag Library Draft, in the <agent> element, there are the following sentences: - “...The agent (human or machine) responsible for an event in the maintenance of the EAC instance.” - “For each maintenance event described in a <maintenanceEvent> element, the name of the agent responsible for the maintenance event must be given.” According to the EAC-CPF Schema, one <maintenanceEvent> element must contain one <agent> element (not one or more). But if I want to encode one maintenance event with two or more agents responsible for it, How can I encode it?, Can I include two or more names of responsible agents (for example, persons) in one <agent> element? I think that should be better: - To explain in the EAC-CPF Tag Library if it is possible to include two or more names of responsible agents in one <agent> element. - If it is not possible, to modify the EAC-CPF Schema. ---------------------------- From: "Abelardo Santamaria" <[email protected]> To: <[email protected]> Subject: Schema Comment Date: Monday, September 14, 2009 4:13 AM Dear Katherine: I send you one suggestion about the EAC-CPF Schema (21 august 2009). Best regards, Abelardo Santamaria Archivo General de Simancas (http://www.mcu.es/archivos/MC/AGS/index.html) Comisión de Normas Españolas de Descripción Archivística (CNEDA)

(http://www.mcu.es/archivos/MC/CNEDA/Presentacion.html) ---------------------------- Suggestion: (1) According to the EAC-CPF Schema, each description of an agent (corporate body, person or family) encoded in an EAC-CPF instance can be related to one or more descriptions of other agents or other entity types. In the <relations> element of an EAC-CPF instance it is possible to encode: - Relationship(s) with other agents (corporate body, person or family), using <cpfRelation> element(s). - Relationship(s) with functions (ambient function, function, activity, process, transaction or other), using <functionRelation> element(s). - Relationship(s) with records (fonds, series, item, etc.) or other resources (library, museum, monument or site), using the <resourceRelation> element(s). But in the <relations> element: - There is not an element to encode the relationship(s) with mandates (ISO/TS 23081-2: 2007). - There is not an element to encode the relationship(s) with concepts, objects or events (FRAD). - There is not an element to encode the relationship(s) with places. I think that should be better to add in the EAC-CPF Schema the necessary specific <xRelation> elements to allow the encoding of relationship(s) with: mandates; concepts, objects or events; places.

The University of Melbourne eScholarship Research Centre

C:\Users\wisser\Documents\EACWG\OHRM_-_2009-10-29_EAC-CPF_Feedback.doc 10-Jun-10

EAC-CPF Feedback Our feedback on the draft EAC-CPF comes mainly from the perspective of using the schema as a way to exchange information between our Online Heritage Resource Manager (OHRM) 1 system and the National Library of Australia’s (NLA) People Australia (http://www.nla.gov.au/initiatives/peopleaustralia/) component of Trove (http://www.nla.gov.au/pub/gateways/issues/101/story01.html). We have created EAC output from the OHRM, which is made accessible for harvest via an OAI-PMH Repository. From the NLA’s SRU interface we can then harvest back the People Australia identifiers, so that the web output from the OHRM points users to where they might find more resources relating to the entity in Trove. This scenario has been instantiated for the Australian Women’s Register (http://www.womenaustralia.info/). The example below shows how a user can move from the Australian Women’s Register to Trove, and from Trove to the Australian Women’s Register.

This scenario represents two use cases for EAC:

1. The first is that it can be used to ‘identity map’ between descriptions of the same entity in different systems.

2. The second use case is the ability to export EAC from one system so that it may be incorporated as a blob of XML (i.e. structurally encoded/marked up text) in another system. Trove re-presents the Australian Women’s Register’s EAC, but does not attempt to translate or incorporate it into other databases of the NLA that feed into Trove. The XML is indexed using Lucene for utlising in their discovery services.

In the short to medium term, we would like to explore extending our usage of EAC to three additional use cases:

1 For more information on the OHRM and its relationship to archival description, see http://www.esrc.unimelb.edu.au/ohrm/index.html.

2


3. As part of establishing an entry in an OHRM, harvesting EAC from other systems and

translating it into OHRM fields rather than the current labour intensive cutting and pasting.

4. For sophisticated search capabilities, beyond keywords, particularly involving spatial and temporal dimensions.

5. For display across browsers and devices and in conjunction with point 4 using XSL transforms of the XML, search using Xquery, etc. We see that EAC could potentially be the basis for building timeline/map/relationship search and visualisation tools that could be used across systems.

Hence our requirement for EAC is that it facilitates machine processing and manipulation, allows us to move beyond fast paper re-presentation, and could begin to cope with the dynamics of archival description in a digital and networked, web 2.0 and beyond, world. Hence we are looking for a degree of semantic precision and lack of ambiguity, and are influenced by our involvement in developing the dynamic metadata model of the ISO 23081 Recordkeeping Metadata standard, as well as descriptive practices based on the Australian Series System. In schema design, trade-offs between use cases are inevitable, especially when dealing with the different needs of humans versus machines. Perhaps the background to the standard needs to have a more explicit statement of the schema’s design priorities, instead of perpetuating the idea that it can be universal/agnostic to perceived scenarios of use. We have direct experience of the first two use cases outline above, but have not yet been able to explore the others - a combination of limitations on resources, the need for skills development and the right content and project in which to pursue them. We strongly believe that usage of EAC in real world scenarios will reveal its capabilities and short-comings, as it is difficult in the abstract/conceptual to see all the consequences and possibilities. Hence we hope that there will be avenues to continue the development of the schema in conjunction with its uptake and implementation.

Schema-specific feedback <CONTROL> Only concern here was the required <MAINTENANCESTATUS> element and what its use case is? From our perspective, EAC descriptions are always in the process of becoming so not quite sure of use of 'new' versus 'revised', when perhaps 'current' best describes our instances. Also could this value be derived from <MAINTENANCEHISTORY>? I guess if we had a clearer understanding of its purpose and projected use then that would allow us to interpret what it means for our uses and data accordingly.

<IDENTITY> As with the earlier draft of the revised EAC schema that was supplied to us by Basil Dewhurst, we are pleased to see the simplification of this section. However we feel that the existence dates of an entity are an important part of its identity and need to be included in this section. Our thought is that for effective and efficient sharing of data the identity section should be the minimal exchange unit, hence it needs to contain enough

3


information to distinguish between other entities that might have the same name with a degree of certainty. Dates are an important part of authority control as they help to distinguish between two entities with the same name. In OHRM HTML output a link to an entity is always presented using an authority form of name, which includes the dates, where known. This is based on the UK’s National Council of Archives, Rules for the Construction of Personal, Place and Corporate Names, 1997, http://anws.llgc.org.uk/ncarules/title.htm. In these rules, dates are a mandatory part of the name for a person and ‘should be the year in which a person was born or died, the span of years of his/her lifetime or the approximate period covered by his/her activities.’ It is similarly an important distinguisher, along with place and function/sphere of activity, for a corporate body. Could <EXISTDATES> be moved from the description section to here? While it is good to see <USEDATES> for the names, it is just not quite semantically the same as saying when did this entity exist, no matter what it might be called. This might also resolve the potential for clashes between the use of <EXISTDATES> and <PLACEDATE> as discussed below. The final relatively minor point is just to flag that we have used family name and given name for the name parts of a person rather than surname and forename. It seems to be common practice on many government forms in Australia to use this terminology as it is based on the semantics of the name part rather than the ordering. However it is noted that most authority control and citation standards refer to surname, forenames so the terminology is synonymous, along with content standards being the method by which the right translations across systems is achieved.

<DESCRIPTION> Our comments on this section are two fold – issues of immediate concern and those regarding the long-term future for EAC and the potential uses of contextual description beyond that envisaged by ISAAR(CPF). With respect to the former, in this section we would like to see:

a) <EXISTDATES> moved to the <IDENTITY> section as it is a mandatory part of identification as discussed above. We also feel that this will reduce the potential for usage conflicts with <PLACEDATE> and other elements used to record significant event data for an entity as discussed below.

b) the ability for a GIS shape file to be embedded or pointed to as part of place elements.

Building good geospatial capabilities into the schema given the number of web 2.0 tools available to exploit them is essential.

With regards to the use of EAC as a way to exchange contextual data between systems, we are concerned with the degree of choice available in this section to record significant event data for an entity in a number of different ways. Take something like the birth and death date and place of a person. This could be recorded using <EXISTDATES>, <PLACEDATE>, <DESCRIPTIVEENTRY>, <ACTIVITY>, or in a <CHRONLIST> under <BIOGHIST>. From the perspective of programming an EAC export format from the OHRM, repetition of the same event information in different elements is no particular problem. However if EAC records are manually created then ensuring consistency with the usage of different elements becomes a concern. In addition if seeking to import EAC into an OHRM or other such system then building a parser which has to look in a number of places, and then also potentially resolve any anomalies,

4


is a much more complicated exercise. Building shared search and visualisation capabilities that could operate dynamically across systems also becomes much more difficult if the same information can be represented in a number of different ways. We are in favour of constraining the schema so that the (extraordinary) benefits of data and tool interchange may be realised. We would like to see the EAC schema laying the foundation for more standardised description in order to deliver a whole new order of access services to users of archival resources. Our development and application of the OHRM system in different environments over the past decade has seen an increasing shift away from description as a textual narrative towards representing it as events and relationships – components that are re-usable and machine processable in digital and networked environments. This has been informed by work such as the metadata model of ISO 23081, the subsequent conceptualisation of events and relationships that has informed the Australian Government Recordkeeping Metadata Standard2 developed by the National Archives of Australia and the ABC Metadata Model3 (where time and space are first order) developed by the Harmony project. Our ultimate goal is for entity description to be an abstract and a series of typed events and relationships, complemented by <BIOGHIST> narratives which may be authored and dated. The typing of events and relationship would allow for their presentation under different headings using XSL or other transformation languages, so that an ISAAR(CPF) rendition of the record would be possible.

<RELATIONS> The representation of relationships between entities and between entities and resources is pretty close to our hearts given our work on various OHRM implementations over the past decade. Their power to represent a dynamic complex contextual information network in a relatively user-friendly and navigable way continually astounds us. Hence we have thought a lot about how relationships are modelled and captured to facilitate re-presentation and automated re-use. In the <CPFRELATION> section we see two problems:

a) Firstly the xlink to the related entity needs to go with the <RELATIONENTRY> element not on the <CPFRELATION> element (as per the Lemoyne example - http://www3.iath.virginia.edu/eac/cpf/examples/Lemoyne.xml). The link refers to the description or surrogate of the related entity not of the relationship.

b) Secondly, as has been identified in the Mabo example, there is no place other than a

 in the descriptive note for the role of the related entity with respect to the described entity. This needs to be an element, despite the different vocabularies that may be used in local implementations, because it is an essential part of a relationship. While the primitive typing gives a classifier to the overall relationship, in many cases and particularly with ‘associative’ you just have to have more information otherwise it is too ambiguous. Having say a <TERM> element here would allow for the role to be specified. If controlled by a local vocabulary with mappings to the primitive role types, then benefits of grouping and filtering relationships in display and search would be achieved. We note that the @localtype attribute could be used, but as the role is an integral part of the relationship then we feel it needs element status.

2 http://www.naa.gov.au/records-management/create-capture-describe/describe/rkms/index.aspx 3 http://metadata.net/harmony/

5


The labelling of roles and relationships raises the issue of the direction of relationships when they are represented as properties of an entity. There is potential for confusion here as in the ISAAR(CPF) Person example of Eddie Mabo, his relationships are described in terms of his relationship to the related entity, whereas in many Australian Series System implementations (e.g. the NAA and the systems of various State Archives) relationships between agencies are represented in terms of the related entity’s relationship to the described entity. For example the heading ‘Previous’ lists the agencies previous to the one being described. So if this standard is about machine mediated exchanges then what needs to be done to ensure consistent direction of relationships? From the perspective of the OHRM, data can be pumped out in either way (hopefully due to the mechanisms we have set up to capture them consistently, i.e. from the related entity to entity perspective), but importing could be difficult with mixed perspectives. In the <RESOURCERELATION> we are pleased with the <OBJECTXMLWRAP> elements being introduced here so that the most appropriate structure to describe the resource can be used. However as with <CPFRELATION> above we feel that the xlink attribute which points to the resource needs to go with the element describing the resource rather than the relationship, i.e <OBJECTXMLWRAP> or <OBJECTBINWRAP> or <RELATIONENTRY> elements.

Concluding remarks In conclusion, we welcome the working group’s efforts in getting the EAC-CPF schema through to this exposure draft stage. The opportunity to comment has been a useful exercise for the ESRC and we will be using this report to stimulate further local discussion, particularly with other metadata communities. The tenor and extent of our feedback is prompted by the crucial role EAC could play in information infrastructure for the digital and networked world. We appreciate that some of our comments may be beyond the remit of this version of the scheme, but we are keen to see it being set on a path to realise its full potential. We hope to continue to experiment with the schema, testing it in various implementations and usage scenarios, and be able to feed that experience back into its continued evolution. Staff of the eScholarship Research Centre, The University of Melbourne

Appendix C: Draft charge for TS‐EAC

Technical Subcommittee for Encoded Archival Context (TS-EAC)

Reports to: Standards Committee Established: 2011

I. Purpose

The Technical Subcommittee for Encoded Archival Context (TS-EAC) of the SAA Standards Committee is responsible for overseeing the timely and ongoing intellectual and technical maintenance and development of Encoded Archival Context – Corporate bodies, Persons, and Families (EAC-CPF). EAC-CPF is the internationally accepted XML (Extensible Markup Language) standard for the transmission of descriptions of the corporate, personal, and familial creators and subjects of archival records. EAC-CPF is compatible with ISAAR (CPF): International Standard Archival Authority Record for Corporate Bodies, Persons, and Families, 2nd ed. (International Congress on Archives, 2004). EAC-CPF is an SAA-adopted standard; documentation is hosted by the Staatsbibliothek zu Berlin at http://eac.staatsbibliothek-berlin.de/.

II. Committee Selection, Size, and Length of Term

The Technical Subcommittee for Encoded Archival Context shall be charged for five years, beginning 2011, with the charge expiring at the SAA annual meeting of the fifth year (2015). The TS-EAC will complete a review of the Encoded Archival Context – Corporate bodies, Persons, and Families according to the SAA Standards Committee's Procedures for Review and Approval of an SAA-Developed Standard before its charge expires. After the charge is completed, if EAC-CPF continues to be an adopted standard of SAA, the TS-EAC shall be re-charged for a subsequent review cycle.

The members and chair(s) of the TS-EAC shall be appointed for the subcommittee's full five-year term. The technical subcommittee shall have five members who are members of SAA and sufficient international membership to ensure effective representation of EAC-CPF professional communities outside the United States. All members shall demonstrate significant knowledge of and experience with archival description generally, and with EAC-CPF specifically.

The TS-EAC shall have a chair who is a member of the Society of American Archivists. The technical subcommittee is encouraged to have a co-chair from among its international members.

SAA members of the TS-EAC shall be recommended by the Standards Committee for appointment by the Vice President. International members who are able to represent other professional EAC-CPF-using communities effectively shall be appointed at the recommendation of the TS-EAC chair(s), who is/are responsible for ensuring appropriately diverse international representation. Members and chairs may be reappointed to the TS-EAC for consecutive review cycles, but at least one new SAA member must be appointed per review cycle.

Ex officio members of the Technical Subcommittee for EAC shall include the following if they are not regular members of the subcommittee:

• Chair of the Standards Committee (or an appointed representative); • Chair(s) of the Technical Subcommittee for Encoded Archival Description; • Chair and members of the Schema Development Team; • Chair of the EAD Roundtable; • Liaison from the Staatsbibliothek zu Berlin;

• Liaison from OCLC Research.

III. Reporting Procedures

The chair(s) of the Technical Subcommittee for Encoded Archival Context shall report at least annually to the chair of the SAA Standards Committee on the occasion of the SAA annual meeting. If extramural funding is obtained by SAA, the chair (or co-chairs) shall provide all necessary narrative reports to the SAA office in order that the reporting requirements of SAA and the funding source are met.

IV. Duties and Responsibilities

To fulfill this mission internationally, the TS-EAC is specifically charged to:

• Carry out a review of EAC-CPF at least every five years and revise as needed. • Revise the EAC-CPF tag library and other official documentation as necessary. • Promote the understanding and use of EAC-CPF internationally. • Support educational efforts related to EAC-CPF by SAA and international communities. • Develop members of the archives profession who are capable of promoting and

maintaining EAC-CPF over time. • Communicate its activities to relevant SAA components and EAC-CPF-using

communities internationally. • Collaborate as needed with the Schema Development Team to maintain the relevant

EAC-CPF schemas.

VI. Meetings

The TS-EAC shall carry out its charge primarily via electronic mail, regular mail, and conference calls. It shall meet at the SAA annual meeting and as necessary with funding from SAA or from extramural sources (with prior approval by the SAA Council).