Electronic Access to Archives- EAD and EAC

Transcription

1

2 Electronic Access to Archives- EAD and EAC Archives exist in the context of the social, political, and economic environments that create and sustain them. If archives are to survive as viable institutions, with a recognizable mission, delivering tangible goods and valued services, they must adapt to change. There are few challenges we face as archivists that are more significant for our success, indeed the very continued existence of institutions, than those created by the electronic age. The issues that electronic records create for archivists have been the subject of more conference papers, more books, and more study projects than any other professional topic I can think of over the past 25 years. One particular aspect of the electronic age- online access to information about archives and to the records themselveshas only emerged as a major concern in the last 10 years. As I speak about this challenge over the next two days, my remarks will be divided into four parts. 1. A review of the issues archives are encountering in providing access to records in our electronic age and a discussion of how two standards, Encoded Archival Description (EAD) and Encoded Archival Content (EAC), might play a part in responding to those challenges. 2. A gentle introduction to Extensible Markup Language (XML), the technical basis for EAD and EAC. Just a few basics so that you will understand generally how XML works, not a computer-programming workshop. 3. An overview of the structure of Encoded Archival Description (EAD) and how it relates to the General International Standard for Archival Description (ISAD (G)) and the new Brasilian Standard for Archival Description known as NOBRADE. 4. An overview of the structure of Encoded Archival Context(EAC) and how it relates to the International Standard Archival Authority Record for Corporate Bodies, Persons and Families (ISAAR (CPF)). Let begin by reviewing the- 1

3 1. Challenges facing archives and how EAD and EAC can help us respond. In providing better access to our collections, archivists face great challenges from three directions: from our users, from the very records we preserve, and from the technologies that we employ to make our work more effective and efficient. Providing access to information has always been a key function of archives. This is true whether you consider them to be an instrument of government; a resource for scholarly inquiry; a repository of information that serves the preservation of legal rights; or more generally the foundation of our collective social memory. At a basic level, our users have two questions: what records are available that answer my questions and where may I find them. But user expectations have become more sophisticated. In the past, a researcher would visit archives in search of records. To identify materials of possible interest, she would consult with staff and examine locally prepared guides, indexes, and other finding aids. These tools were prepared according to local specifications and presented in printed or typed format. Records would be retrieved from storage and the researcher would pour through boxes of paper documents or perhaps consult microfilm. Today, the researcher wants to be able to determine what records are available without the time and expense of traveling to many separate archives. They want to be able to search the holdings of many archives simultaneously. There's even more than that. Given their experience with access to digital materials on the Web, researchers want to be able to examine the documents themselves online. The nature of our records, our archival traditions, and our descriptive techniques themselves complicate the process of providing access. A body of archival records may be about many things and not as easily categorized as the contents of a book. But users are often looking for materials by topic or place or personal names. We have emphasized provenance as the way to find materials, not by subject matter or place or type of record. I doubt that our users actually agree with the idea that knowing how and by whom records were created is all one needs to know to find information in archives. We organize and describe materials in a hierarchical arrangement that proceeds from the general to the specific, from the series to the file to the item. This structured approach runs counter to the expectations of users who are accustomed to direct access to individual documents. 2

4 Finally, our practical utilization of collective description is very effective in managing large volumes of documents. We are not accustomed to describing documents individually except for the most important papers. Today we must face the reality of managing electronic files at the level of the individual document or computer transaction. Technology offers solutions but also creates its own complications. We have to master and implement new technologies that take time and energy. There are so many choices. What will be the best long-term solution? There is truly a technical Tower of Babel. To which voices shall we listen? At least three things are needed to create the access our patrons need and expect. 1. We need good descriptive metadata that is based on professional standards designed to meet the needs of our users. They represent a consensus of best practice across the profession rather than the personal preferences of individual archivists. Standards achieve three things. They guide archivists to more consistent analysis of records. They can result in more uniform presentations in finding aids across many archives, which is helpful to the user. Finally, they bring the consistency that is the sine qua non of information interchange. Without regularized content and structure, we cannot create share, consolidate, and present data from multiple collections and many archives in a way that meets customer expectations. 2. We need the technologies that will bring remote users to our collections. We want solutions that integrate readily with the web, enable data sharing, and are cost-effective and reasonably priced. They must work for archives, not someone else. 3. We need systems that go beyond just making it possible to discover what is in archives. They must be able to deliver archival records themselves online as well. While it will be a long time before we have fully electronic archives, that process is beginning and we need to design information systems today with that future in mind. What exists to support the archival response? What can we build on? Descriptive standards are emerging at the international and national levels. I've already mentioned ISAD (G), ISAAR (CPF), and NOBRADE. These all guide the archivist in determining what information should be recorded to create a description that meets the researcher's needs. We have a technical infrastructure for broad access- the web. It's not everywhere in the world but it is spreading. 3

5 One more technical piece is needed to complete the puzzle. We need a method for bringing together our standardized descriptive information and the web. How shall we best create, store, index, search, and display our metadata in electronic form and distribute it via the web? Finally, our protocols for electronic descriptions must also interact with other standards that address the management of digital archival records. EAD and EAC help fill those needs. Encoded Archival Description (EAD) is a standard for the electronic management of archival descriptions. Generic in design, EAD support descriptions created according a range of international and national descriptive conventions. Its international use has proven its flexibility. It is built on Extensible Markup Language (XML), a completely open and internationally adopted data standard. As such, EAD is not limited to any particular vendor's software and can be used with a variety of applications. XML data can be readily prepared for distribution on the web or used to create printed versions of guides with a single command using a programming language created specifically for these purposes. It is called Extensible Stylesheet Transformation Language (XSLT). EAD is widely employed internationally, with major use in North America and Europe. In England and France, it is being used as the basis for national archival information systems. In the United Kingdom, the Access to Archives (A2A) service, based on EAD, contains than ten million descriptions of archival records. In Spain, it is being used with another complementary standard, Encoded Archival Guides (EAG) that describes archival institutions. Of course, EAD is widely employed in the United States, particularly in eight large regional archival information systems as well as the international database of inventories maintained by the Research Libraries Group. Traditionally, the names and information about the creators of archival records were created, stored and presented within the description of a particular fond or series. ISAD(G) and EAD follow this model. But this approach creates duplication and maintenance problems when the same information must be created, stored and kept up to date in multiple inventories. There was no other option in the days of printed guides and inventories but with computer systems we nave other choices. The International Council on Archives has defined another data architecture in which information about creators is kept in one system and information about records is stored in another. Data from the two systems can be combined as needed. Descriptive information created according to ISAD (G) and national standards like NOBRADE would be stored in one system and authority data created according to ISAAR (CPF) would reside in another. In an electronic environment, EAD could store the descriptive information. Encoded Archival Context (EAC) was created to fill the need for a parallel method for managing authority data electronically. 4

6 This can be very confusing. How do EAD and EAC relate to other standards? One way to think about archival standards is to divide them into two groups. Content standards tell us what information to record about a fond in our inventories. Communication standards are the buckets in which we transport descriptions. This chart shows the relationships between content and communication standards and between descriptive and authority data. Descriptive Information Authority Information Content ISAD(G)/NOBRADE ISAAR (CPF) Communication EAD EAC EAC accommodates information created according to a variety of national and local conventions. It fully supports ISAAR (CPF), the two standards having been developed in close conjunction. EAC is based on XML, is software and system neutral, and is easily linked with other XML-based protocols. The next challenge will be to link archival descriptions with electronic representations of the records themselves. Imagine a researcher scanning through descriptions in an inventory, finding information of potential interest, and then instantly retrieving digitized images of those documents without having to exit the inventory and switching to a separate system or interface. In Germany, archives are experimenting with the integration of information in this way. Archival descriptions in EAD are linked to digital copies of archival records managed in another XML format known as the Metadata Transmission Standard (METS). Both of these communication standards, EAD and EAC, are based on the XML protocol. So it will be necessary first to know a few things about XML in order to understand how EAD and EAC work. 5

7 2. A Gentle Introduction to Extensible Markup Language Extensible Markup Language is a standard for the electronic encoding of text for computer processing. The word "text" is used deliberately because XML is optimized for the electronic manipulation of semi-structured documents like archival inventories. To understand how XML works, there are eight concepts you need to know: elements, attributes, entities, schemas and document type definitions, tag libraries, the separation of content and presentation, stylesheets and idea of a canonical version. Let s review these one at a time. Elements are the basic building blocks of an XML document. In a relational database, data is separated into individual fields, each of which is stored separately in a set of abstract tables. With XML, information is created, stored, indexed, retrieved all together in a single file. The individual elements are identified by marking them with codes that specify the beginning and ending of each data element. An XML file retains its document-like quality. Indeed, an XML document is simply an eye-readable computer text file. As a result, an EAD file in XML can be read with any text editing software in any operating system. While there are useful, specialized programs for creating XML files, they are not, strictly speaking, necessary. Consider this scenario of how XML encoding works. In an inventory, the biography of the creator of the records may contain the title of a book. For purposes of indexing and display, we want to indicate that this phrase is a book title and not just another string of words. In XML, one indicates that these words constitute a particular data element by marking the beginning of the text of the title with what is called a start tag and marking the conclusion of the title with an end tag like this. <title>floriano Peixoto: vida e obra</title> The start tag consists of the name of the data element, title in this case, enclosed in angle brackets. The end tag is the same except that it begins with the forward slash mark to differentiate it from the start tag. Those familiar with HTML, the language of the web, will instantly recognize this type of text encoding. Some elements have shortened forms of their names that appear in the start and end tags. The element Paragraph, for example, appears as <p>. 6

8 Some elements contain text. Other elements are used only to group other sub elements together. <date> <day>17</day> <month>março</day> <year>1946</year> </date> XML describes the hierarchical relationships among elements in family terms like a genealogy. In this example, Date is the parent of Day, Month and Year. Day, Month and Year are all children of Date and siblings of one another. In EAD, the <ead> element is the parent element. Ali other elements in the EAD document are nested within it as children. In the following example, the Title <title> element is wrapped inside a parent paragraph <p> element. It is one of two paragraphs within an Archival history element whose short name is <custodhist>. <custodhist> <p>após o falecimento do marechal Floriano Peixoto, em 29 de junho de 1895, Francisco Furquim Werneck de Almeida, prefeito do então Distrito Federal, por decreto legislativo de 14/12/1895, determinou que os documentos do arquivo Floriano Peixoto, que estavam na residência da viúva do titular, fossem arrolados para serem publicados na Revista do Arquivo Municipal, formando-se, para isso, a comissão composta por Alexandre José de Melo Morais Filho, Fernando Luís Osório, José Medeiros e Albuquerque, José Américo de Matos, Júlio Henrique do Carmo e Artur Vieira Peixoto. O trabalho de separação e arrolamento dos documentos foi concluído em janeiro de 1898, porém, o projeto de publicação foi suspenso e a comissão dissolvida. Artur Vieira Peixoto, cunhado do titular, fez inúmeras tentativas para preservar e divulgar o acervo e, em 1917, solicitou a Nilo Peçanha autorização para que este fosse depositado no Ministério das Relações Exteriores. Em 1925 é publicado <title>floriano Peixoto: vida e obra</title>, de autoria de Francolino Cameu e Artur Vieira Peixoto. Nos anos 1931, 1933, 1935 e 1937, novas tentativas, sem êxito, são feitas para organização e publicação do acervo. </p> <p>em 1937 o Ministério das Relações Exteriores envia ao Arquivo Nacional a documentação e em 1988 uma pequena parcela é doada à instituição. </p> </custodhist> 7

9 Attributes are the second important concept to understand with XML. Attributes provide additional information about the content of a particular element. In the previous example, it might be important to know not only that this phrase is a title but also whether it is the title of a book, a Journal, or an article in a Journal. The Title element in EAD has an attribute called TYPE that lets us specify what form of title it is. <title type="livro">floriano Peixoto: vida e obra</title> Attributes and their values appear within the start tag as a three-part unit of information: the name of the attribute, the equal sign, and the value of the attribute in quotation marks. In this case, it is the title of a book. Later, when one wishes to display this inventory, we can use the presence of the value "livro" in the TYPE attribute to instruct the computer to display this text in the format appropriate for the presentation of a book title according to local conventions for bibliographic citations. Note that the attribute appears only in the start tag. A single element may have multiple attributes but only as they have been formally defined in the Document Type Definition about which we will say more in a minute. Entities play an important role in XML documents. Entity is an abstract word that describes two concrete situations we encounter with electronic inventories. The first comes when we need to represent a character or symbol that is not found on the keyboard such as a letter in another language or the copyright symbol. We need to insert a code that the computer recognizes as representing that letter or symbol. These are called character entities. The second scenario occurs when we wish to include an image of some type in a guide. It may be the logo of our archives, a picture of the creator of a manuscript collection, or an image of archival records. Technically, we do not want actually to embed that image into the electronic file for our inventory. Instead, we store it in a separate computer file and have it appear in the finding aid at the time it is displayed on the computer or printed out on paper. In XML, a reference to the name and computer location of an external file (it could be a sound file as well as a picture) is called an entity reference. Document Type Definitions (DTD) and Schemas are a special aspect of XML. Extensible Markup Language itself does not specify any particular set of markup codes. Instead, user communities define particular applications for the encoding of documents they work with. The archival community created the EAD and EAC sets of codes, a few examples of which we have already seen. Other communities have created their own codes for other purposes, including the publishing of books, managing electronic sales, the electronic manipulation of scholarly texts, and even library catalog records. Since 2003, documents in Microsoft Word, Power Point and Excel are actually stored in an XML format that conforms to a schema developed by Microsoft. 8

10 These protocols specify such matters as the allowed data elements, their hierarchy, their sequence, whether a particular element is required or optional, and if it can be used more than once. They also specify the attributes that are valid for each element. These rules are recorded in a very formal, mathematical way so that they can be read by computers to ensure that coded documents conform to the established conventions. There are two sets standards for recording these rules- Document Type Definitions (DTDs) and Schemas. While the syntax of each is different, they perform the same function. There are official DTDs and schemas for EAD and EAC. Tag Libraries. A Tag Library is simply the user-friendly documentation that interprets the structure and elements in the DTD or schema. The EAD Tag Library is available both as a published book and as an online web document. It has been translated into several languages. The EAC Tag Library is still in draft form but it too is available online. Separation of Content and Presentation. One of the most significant concepts of text encoding schemes like XML is that the markup of the text focuses on the structural elements of the document and not how it is to appear to readers. When one creates a document in a word processor, presentation is the basic consideration. How will the text look on the screen or page? Will the words appear large or small, centered or to the left, in an Arial or Times New Roman font? The word processor concerns itself only with these issues, not with the content of the document. You could be typing your dissertation or a letter to your mother. Microsoft Word does not know or care. With EAD markup in XML, one identifies the structural components of an inventory- what information is the title of the fond, what are the dates of this series, what is the administrative history of this government agency. The encoding does not describe how the data will look on the screen or paper. After all, we may want to present the information in many different ways for different purposes. This separation of content and presentation is hardly unique to XML. Relational databases, book publishing and library catalogs all work on the premise that text is best maintained in a way that keeps content separate from the way it is presented. This is one of the big advantages computers have over typewriters, A styleshect is basically a small computer program (itself an XML document) that contains instructions for transforming the elements in an EAD-encoded inventory into a more user-friendly format That may be an HTML file for viewing in a browser or a PDF or Microsoft Word document for creating printed versions of the inventory. For example, a stylesheet could specify how a Scope and Content statement would appear on the screen or page- what font, type size and type weight would be used, how the text would be laid out on the screen or page- indented or centered or flush left, and so forth. There is a specialized computer language for writing these programs this called Extensible Stylesheet Language Transformations (XSLT) 9

11 Canonical version. Because the XML file remains unchanged through this transformation process and because it can be the source of multiple versions of the data, many archives consider the EAD electronic file to be the "master" copy of the inventory. This is also referred to as the "canonical" or official version from which others are created. When there are changes to an inventory, one only needs to make them in one place before generating other versions for different uses. Technical environments for XML files. There are several ways in which XML files currently are created, stored, searched and displayed, though many of these applications are hybrids that defy precise classification. One method is through a file system architecture. Inventories are stored as separate computer files that are collectively indexed, searched and displayed. One popular software application for doing this is Lucene from the Apache Web group. It is the foundation of the extensible Text Framework (XTF) suite developed by the California Digital Library and MidosaXML developed by the Federal Archives of Germany. There are also a variety of commercial applications such as the Digital Library extension Service (DXLS) and Idol. XML is supported by a variety of products such as Xhive, MarkLogic, Tomino, exist that manage data in its native XML form. Several popular database management software applications like DB2, SQLServer, and Oracle handle mixed environments that contain both relational and XML data. The final approach is to employ an application that stores descriptive metadata in traditional relational databases that have the capability of importing and exporting XML information. The Archivists Toolkit is an open source product of this type that was released recently in the United States. Built on the popular MySQL relational database, it promises to be able to ingest existing EAD and EAC documents into the system and export data in EAD and EAC format. 10

12 3. ENCODED ARCHIVAL DESCRIPTION (EAD) Before discussing the elements of EAD in detail, I want to begin with a general comparison of the structure of EAD with that of ISAD(G) to provide you with a point of reference. Consider these similarities and differences. 1. ISAD(G) has 26 data elements. There is a corresponding element in EAD (or element attribute in one case) for each element in ISAD(G). 2. There actually are many more elements in EAD, about 135, though one typically uses only about 35 of them. There are three reasons why EAD has so many more elements. First, EAD has many elements that relate to information about the electronic file in which the EAD data is contained as well as those that relate to the description of the archival materials. We shall review those elements later. Second, some of the additional elements in EAD result from the need for computers to divide information into smaller units for machine manipulation in situations where humans could easily distinguish aspects of data just by looking at it. In this respect computers are not nearly as intelligent as we are. Consider these two examples. ISAD(G) has an element called Reference Code. One element. But it actually consists of three parts: a country code, a respository cod, and the local reference code. EAD divides this element into three parts so that a computer can read and process each segment of the code separately, Here is another example. The Name of Creator element may contain a personal name, a corporate name or a family name. EAD permits us not only to record the name of the organization or individuals responsible for the creation, accumulation, and maintenance of the records but also to specify whether the type of name is personal, corporate or family. The third reason for the additional elements in that EAD includes descriptive elements not found in ISAD(G). For example, we need to identify the access points- names, places, topics, functions and activities, types of documents, and time periods- that researchers use to locate relevant records. NOBRADE also has added a new data area, one not found in ISAD(G), to accommodate this information. EAD provides a way to encode those headings in our inventories. 11

13 3. ISAD(G) groups elements into seven areas by type of information. The organization of the rules was intended to make the relationships among data elements clearer for the archivists using the code. Six of these elements are considered to be "essential for international exchange of descriptive information." They are Reference Code, Title, Creator, Dates, Extent, and Level of Description. 4. EAD also identifies several elements that are essential for the identification of the records being described. These are grouped together in the Descriptive Identification area, which must appear first in any EAD description, Otherwise, there are no further groupings and the order of elements is flexible. As an international standard, EAD needs to accommodate a wide range of different national practices. Indeed, the first edition of EAD included more grouping of elements but in practice it quickly became clear that there was no international consensus on this issue. The groupings were dropped in favor of a solution that permits archives to organize elements when and how they wish. 5. The important point to remember is that with EAD the sequence in which data is recorded in the electronic file need not be the sequence in which the information is presented to the public. Remember the discussion of stylesheets. We are going to use a stylesheet to transform our EAD encoded file into some other format such as an online inventory or a printed document. When we do that, we can reorder the data into whatever sequence we desire. Grouping can occur when the data is presented and need not be done when it is recorded. 6. Both EAD and ISAD(G) follow the principle that the same elements of description apply to every level of arrangement. That is, the same data may be recorded for a file or an item as may be employed to describe a series or fond. Each can have a title, dates, level of description, quantity, and creator but also restrictions on access and use, related material and conservation information, etc. The following chart shows the correspondence between elements in EAD and ISAD(G)/NOBRADE. As we go along, you will notice that the names of EAD element are very generic so as to afford the greatest flexibilty for international use. 12

14 Crosswalk: NOBRADE to EAD NOBRADE EAD Área de Identificação Código de referência <unitid> Within:<did> Titulo <unittitle> Within:<did> Datas <unitdate> Within:<did> Nível de descrição LEVEL attribute Dimensão e suporte <physdesc> Within:<did> Área de Contextualização Nome do produtores História administrativa Biografia História arquivística Procedência Área de conteúdo e estrutura Âmbito e conteúdo Avaliação, eliminação e temporalidade Incorporações Sistema de arranjo Área de condições de acesso e uso Condições de acesso Condições reprodução Idioma Características físicas e requisitos técnicos Instrumento de pesquisa Área de fontes relacionadas Existência e localização dos originais Existência e localização de cópias Unidades de descrição relacionadas Nota sobre publicação Área de notas Notas sobre conservação Notas gerais Área de controle da descrição Nota do Arquivista Regras ou Convenções Data da descrição Área de pontos de acesso e indexação de assuntos Pontos de acesso e indexação de assuntos <origination> Within:<did> <bioghist> <custodhist> <acqinfo> <scopecontent> <appraisal> <accruals> <arrangement> <accessrestrict> <userestrict> <langmaterial>within:<did> <phystech> <otherfindaid> <originalsloc> <altformavail> <relatedmaterial> <separatedmaterial> <bibliography> <processinfo>/<note> <odd>/<note> <processinfo>/<note> <descrules> <processinfo><p><date> <controllaccess> 13

15 The Elements of EAD Let s now review the elements in EAD, what each of them means, and how they are related to one another in the encoding of an archival inventory. The following descriptions have been adapted from the EAD Tag Library which contains additional information about these elements. It also covers other elements that our limited time and space here does not permit us to discuss. The discussion of each element begins with the full name of the element and its shortend form as it appears in markup. In the examples in this text, the names of attributes appear in upper case letters to distinguish them from the names of elements. In actual encoding, the names of elements and attributes are written entirely in lower case letters. <ead> Encoded Archival Description This is the root or outermost wrapper element that marks the beginning and ending of an encoded inventory. The <ead> element identifies a particular electronic record as being encoded according to the EAD Document Type Definition or schema. This element has three child elements. They must appear in the following order: eadheader which is required frontmatter which is optional and is seldom used. archdesc which is required So, the overall structure of an encoded document looks like this. Indention is used in these examples to make the hierarchy more apparent but is not technically required. <ead> <eadheader> Information about the electronic file. </eadheader> <frontmatter> Publication information </frontmatter> <archdesc> The archival description itself </archdesc> </ead> 14

16 Let us begin with these three, high-level elements that are the children of <ead>. The first is- <eadheader> EAD Header This element contains information about the electronic file that contains a particular EAD-encoded inventory. This data includes a unique identifying number and title for the file, which are required, as well as optional information about the individuals who encoded the document, the rules used to create it and a record of changes that may have been made to the file over time. We ll discuss this element more after we've first considered those elements that described the archival materials themselves. <frontmatter> Front Matter The front matter element was created as a place to record information that would be required if an inventory were to be published formally. It includes elements that capture the information that would appear on a title page such as a formal title, information about the publisher, copyright, and so forth. In my experience, this element is seldom, if ever, used and so we will not spend time on it. But, as with all EAD elements, the EAD Tag Library contains all the information you need to know to employ it if you wish as well as examples. The third child element of <ead> is Archival Description which appears as <archdesc>. <archdesc> Archival Description This element contains the text of an inventory or other finding aid that describes the content, context, and extent of a body of archival materials, including administrative and supplemental information that facilitates use of the materials. This element begins with a description of the whole body of archival materials covered by the inventory. In most countries, the presumption is that an inventory describes an entire fond. However, in some national traditions, notably the United States and Australia, descriptions of government records begin at the series level. Either approach is possible. In fact, the structure of EAD is flexible and allows descriptions that begin at any level in the archival hierarchy. Theoretically, the top level of description might be all the records in the archives, level 0 on the following chart, or even just a single item, level 5 on the chart, though there seems little practical value in actually doing so. Following the description of the entire body of records, one finds information about each of the components of the fond- on each series, followed by its subseries, and then the dossiers, the files and even individual items. 15

17 16

18 The <archdesc> element has a mandatory attribute, LEVEL, which specifies the archival level of the materials being described. This attribute has a series of specified values that are the English version of those found in ISAD(G). A mechanism is provided for using terms in other languages using a second attribute, OTHERLE VEL. In Portugese, the encoding would look like this. <archdesc level="otherlevel" otherlevel= Fundo"> As we review each of the elements in <archdesc>, we need to remember again that the sequence of data in EAD for the description of any particular level in BAD is almost entirely at the discretion of the archivist. Hopefully, as more inventories appear online and we are better able to assess user reaction to them, we will be able to reach more definitive and scientific conclusions about the best way to share this information with a new and broader group of users. There is one exception to this considerable flexibility in EAD. EAD identifies a series of elements as basic to the identification of a body of archival records. They are familiarcreator, respository, title, extent, dates, etc. These form a cluster of elements that are encoded within a parent element called Descriptive Identification <did>. The Descriptive Identification must appear first at every level. While there are no further groupings in EAD, I am going to arbitrarily present the elements within <archdesc> in a certain order to help you better understand them. This is strictly a pedagogical technique and is not meant to imply anything beyond convenience for our consideration here. As you follow along with this overview, my five groups will be Descriptive identification Context and content Conditons governing access and use Adjunct data Administrative data 17

19 <did> Descriptive Identification This is a required element that bundles other sub elements containing core information about the described materials. They are brief, clearly designated statements of information. They include the name of the repository, the name of the creator, title, identification code, extent, location of the material, language of the records, an abstract, a general note, and an element for display called a head. Except for <note>, none is more than a paragraph in length. The <did> elements constitute a good basic description of an archival unit. This grouping ensures that the same data elements and structure are available at every level of description within the HAD hierarchy. It facilitates the output and retrieval of a cohesive body of elements for resource discovery and recognition. All the elements in <did> have an attribute called LABEL in which one can specify text that will be displayed before the contents of the element. For example, with the title element encoded like this <unittitle label="título"> Campanha da Mulher pela Democracia- CAMDE < / u n i t t i t l e > The LABEL attribute might be used to create a display like this Título: Campanha da Mulher pela Democracia- CAMDE <repository> Repository Here we record the name of the institution or agency responsible for providing access to the materials being described. When inventories were available only in the archives that held the records, it was not necessary to specify the name of that archives on the inventory. But with remote, online access it is obviously important to state explicitly where the records may be found. There is no element comparable to Repository in ISAD(G) other than the coded data in the Reference Code. Since the repository's name is that of a corporate body, the Corporate Name <corpname> element may be used within <repository> to facilitate indexing. <repository label="custódia"> <corpname>museu Nacional (Brasil)</corpname> </repository> 18

20 <unitid> ID of the Unit This element contains any alphanumeric string that serves as a unique reference point or control number for the described material, such as a lot number, an accession number, a classification number, or an entry number in a bibliography or catalog. To comply with ISAD (G), one needs to record three pieces of information: the country code, a repository code, and the local reference code. There are two ways to encode this data. The simplest is simply to record the code as a string of text. <unitid label="código de referência">br AN lh</unitid> The other option is to divide this information explicitly into three parts so that the computer might process it more precisely. One does not to have to rely on the fact that the person who typed in the code correctly put a blank space between the three sections. This approach uses the COUNTRYCODE and REPOSITORYCODE attributes. COUNTRYCODE provides the ISO code for the country in which the institution is located. REPOSITORYCODE specifies the ISO code for the institution that has custody of the materials described. In this case the markup would look like this. <unitid label "Código de referência" countrycode="br" repositorycode="an"> 1H </unitid> <Origination> Origination We record in <origination> the name of the individual or organization responsible for the creation, accumulation, or assembly of the described materials. The <origination> element may be used to indicate such agents as correspondents, records creators, collectors, and dealers. Using the LABEL attribute may help identify the role of the originator, e.g., "creator," "collector," or "photographer." Several name elements are available within <origination>, i.e., <corpname>, <famname>, and <persname>, to facilitate indexing. <origination label="produtor"> <persname>feio, José Lacerda de Araújo, </persname> </origination> 19

21 <unittitle> Title of the Unit This is the name, either formal or supplied, of the described materials. It may consist of a word, phrase, character, or group of characters. Do not confuse <unittitle> with Title <title>, a more general element used to encode the formal names of works such as monographs, serials, paintings, etc. <unittitle label="título">visita de Júlio Argentine Roca, ex-presidente de República Argentina, ao Museu Nacional</unittitle> <unitdate> Date of the Unit Here we record the creation year, month, or day of the described materials. The <unitdate> may be in the form of text or numbers, and may consist of a single date or range of dates. The <unitdate> is used to tag only the creation and other relevant dates of the materials described in the encoded finding aid. Do not confuse it with the <date> element, which is used to tag all other dates. Of course, many different types of dates may be recorded: dates of creation, coverage, production or accumulation. Here the LABEL attribute may be helpful in conveying to the user exactly what types of date are being presented. We often record dates in different ways, according to conventions that are readable by the human eye but difficult for a computer to comprehend for indexing. We use brackets to indicate supplied dates and question marks to indicate uncertain dates. Sometimes just a year is given, other times a year, month and day. We need to assist the computer so that it can search inventories by dates more precisely. To do this, EAD provides both a place to record the dates according to our descriptive protocols and another place to record the date information in a highly structured form that a computer can machine-process. This standardized form goes in the NORMAL attribute and must comply with ISO Standard 8601, the international standard for representing dates. The regular, eye-readable version of the dates goes in the <unitdate> element. ISO specifies that this form follows the structure YYYY-MM-DD (AAAA- MM-DD). The text of the element contains the form of the dates we wish to present to the reader and the attribute the dates as they will be processed by the computer. <unitdate normal=" / " label="data de produção"> 26/4/ /3/1975 </unitdate> 20

22 If the dates are unknown or uncertain, this fact can be specified in the CERTAINTY attribute. <unitdate normal- 1823/1968" certainty="incertaza" label="data-assunto"> [1823?]-[1968?] </unitdate> <physdesc> Physical Description Here we record information about the appearance or construction of the described materials, such as their dimensions, a count of their quantity, or statement about the space they occupy, and terms describing their genre, form, or function, as well as any other aspects of their appearance, such as color, substance, style, and technique or method of creation. <physdesc label "Dimensão e suporte"> Textuais 1m; Bibliográficos 0,10 m; Iconográficos 136 fotografias </physdesc> <physdesc label="dimensão e suporte"> Fotografia 1 item p&b </physdesc> The information may be presented as plain text, or it may be divided into the <dimension>, <extent>, <genreform>, and <physfacet> sub elements. <langmaterial> Language of the Material This is a prose statement enumerating the language(s) of the archival materials found in the unit being described. This element may also be encoded in two different ways. The first is simply to give the information as a string of text. <langmaterial label="idioma">português e inglês</langmaterial> 21

23 If more than one language is recorded or if one wants to record this information in a coded form for better international computer searching, each language may be specified within a separate <language> element, with the three-letter code for the language according to ISO given in the LANGCODE attribute. <langmaterial label-"idioma"> <language langcode="deu">alemão</language> <language langcode="spa">espanhol</language> <language langcode="fre">francês</language> <language langcode="eng">inglês</language> <language langcode="por">português</language> </langmaterial> Do not confuse with this with the Language Usage <langusage> element which specifies the language(s) in which the finding aid is written. See also the description for the <language> element. The Descriptive Identification <did> also includes several other useful elements that are not found in ISAD(G) or NOBRADE. <abstract> Abstract An abstract is a very brief summary of the materials being described, used primarily to encode short biographical or historical information about the creator and abridged statements about the scope, content, arrangement, or other descriptive details about the archival unit or one of its components. This element was added to assist researchers who may be scanning many collections online and need to have a short summary of the contents of the materials so as to be able to quickly sort records of potental interest from those that are not relevant. The <abstract> is often extracted from the longer descriptions found in <bioghist> and <scopecontent>. In the descriptions of series, subseries and files, the abstract may include information that would be encoded in separate Arrangement <arrangement>, Biography/Administrative History <bioghist>, Physical Description <physdesc>, and Scope and Content elements <scopecontent>, if the available data were substantial. <abstract label="resumo"> Documentos de comissão especial estabelecida em 1916 para investigar possíveis desvios de fundos dos empréstimos do Cofre dos Órfãos ao Tesouro Nacional. Inclui material produzido pela Comissão para provar suas conclusões e seu relatório final, alem de documentos privados de um de seus servidores, Candido Venâncio Pereira Peixoto. </abstract> 22

24 <note> Note The Note is a generic element that provides a short statement explaining other text, indicating the basis for an assertion, or citing the source of a quotation or other information. It is used both for general comments and as an annotation for the text in a finding aid. It may appear in many different areas within an inventory. Because a <note> may be longer than a single paragraph, it requires a Paragraph <p> sub element in all cases even when it is included in Descriptive Identification <did>. It is the only <did> element that requires a Paragraph <p>. However, do not use it when more specific content designation elements are appropriate, e.g., <abstract>, <altformavail>, <archref>, or <scopecontent>. Do not confuse it with Other Descriptive Data <odd> element that is used when more than a short comment in a <note> is required. <dao> Digital Archival Object This is a linking element that connects electronic representations of archival records with their descriptions in an inventory. Such digital representations may include graphic images, audio or video clips, images of text pages, and electronic transcriptions of text. The objects may be selected examples or digital surrogates of all the materials in an archival fonds or series. Since one does not actually store the images themselves within the electronic finding aid, there must be some method for associating the two files (that of the image and that of the inventory) so that they may be combined when being presented to the user. The electronic path to the digital representation may be specified in one of two different ways, using either the ENTITYREF or the HREF attribute to reference the relevant file and its physical location. Each <dao> element specifies a single related digital file. When more than one file is to be linked, the <dao> elements for each are combined within a Digital Archival Object Group <daogrp> element. Use the Extended Pointer <extptr> element to link the finding aid to electronic objects that are not part of the described materials. 23

25 <head> Heading Like all other the other child elements of Archival Description <archdesc>, the <did> has a sub element called Head <head>. This is a generic element that designates the title or caption for a section of text that is included to explain to the reader the nature of the information that she is reading. When a <head> is used, it should be the first subelement, followed by one or more other elements. Often the text of the Head is the name of the element whose content it introduces. The following example shows the encoding for the elements we have discussed thus far, including a fully encoded <did> It also illustrates the use of <head>. 24

26 <ead> <archdesc level- "otherlevel" otherlevel="fundo"> <did> <head>identificação</head> <repository label="custódia"> <corpname>arquivo Nacional (Brasil)</corpname> </repository> <unitid countrycode="br" repositorycode="an" label ="Código de referência" > 1H </unitid> <origination label="produtor "> Brasil. Comissão Especial de Exame do Cofre dos Órfãos </origination> <unittitle label="título"> Comissão Especial de Exame do Cofre dos Órfãos </unittitle> <unitdate normal="1889/1932" label="datas"> 1889 a 1932 </unitdate> <abstract label="resumo"> Documentos de comissão especial estabelecida em 1916 para investigar possíveis desvios de fundos dos empréstimos do Cofre dos Órfãos ao Tesouro Nacional. Inclui material produzido pela Comissão para provar suas conclusões e seu relatório final, alem de documentos privados de um de seus servidores, Candido Venâncio Pereira Peixoto. </abstract> <langmaterial label="idioma">português</langmaterial> <physdesc label="dimensão e suporte"> Textuais 0,97 m; fotografia 1 item p&b </physdesc> </did> </archdesc> </ead> 25

27 Here is how this same data might be presented to a user through a web browser. Identificação The <head> identifies the nature of the data elements that follow. You will notice that it is presented in a different typeface, a larger type size, and in bold format. Each element within the <did> is shown on a separate line in two columns, with the value of LABEL attibute given first, again to characterize the data for the user. All of these details of presentation- layout of text into columns, what data goes where, and the size and position of the data is dictated by specifications in the stylesheet. And just to show you that it is possible for a stylesheet to do so, I have reversed the order of the last two elements: Physical description and Language. 26

28 Context and Content Elements The next six elements provide basic information about the context and content of the records. <archdesc> <bioghist> <scopecontent> <arrangement> <custodhist> <phys tech> <controlaccess> Biography Scope and Content Arrangement Custodiai history Physical characteristics and technical requirements Controlaccess <bioghist> Biography or History Here we record a concise essay or chronology that places the archival materials in context by providing information about their creator(s). This includes significant information about the life of an individual or family, or the administrative history of a corporate body. The <bioghist> may contain text in a series of Paragraphs <p>, and/or a Chronology List <chronlist> that matches dates and date ranges with associated events. Additional <bioghist> elements may be nested inside one another when a complex body of materials, such as a collection of family papers, is being described, and separately headed sections are desired. Many elements, such as <bioghist> are recursive (i.e., the elements are available within themselves) to facilitate the use of multiple headings with subdivided descriptions for complex collections, and to enable EAD markup to be used for a variety of output. 27

29 <bioghist> <head>biografia</head> <p>floriano Vieira Peixoto nasceu na cidade de Ipioca, em Alagoas, atual Floriano Peixoto, a 30/04/1839 e faleceu a 29/06/1895. Filho de Manoel Vieira de Araújo Peixoto e Joaquina de Albuquerque Peixoto, foi criado, desde o nascimento, pelo tio, coronel José Vieira de Araújo Peixoto. Estudou em Alagoas e em 1855 foi para o Rio de Janeiro completar sua educação, matriculando-se no Colégio São Pedro de Alcântara. Sua vida militar teve início em 1857, quando assentou praça. Ingressou na Escola Militar em 1861, e em 1863 foi promovido a 1 tenente. Foi coronel, posto obtido devido à sua atuação na Guerra do Paraguai, comandante de batalhões de artilharia no Amazonas e Alagoas, diretor do Arsenal de Guerra em Pernambuco (l ), governador da província de Mato Grosso (l 884) e marechal de campo (1889). Participou do 1 governo provisório da República, assumindo a pasta da Guerra (1889). Em 25/02/1891 venceu as eleições para vice-presidente no governo do marechal Deodoro da Fonseca e, após a renúncia deste, assumiu a presidência (23/11/1891). Em seu governo enfrentou, com o apoio do Exército, a Revolução Federalista no Rio Grande do Sul (1893) e a Revolta da Armada (1893).</p> </bioghist> <scopecontent> Scope and Content This prose statement summarizes the range and topical coverage of the described materials, often mentioning the form and arrangement of the materials and naming significant organizations, individuals, events, places, and subjects represented. The purpose of the <scopecontent> element is to assist readers in evaluating the potential relevance of the materials to their research. It may highlight particular strengths of, or gaps in, the described materials and may summarize in narrative form some of the descriptive information entered in other parts of the finding aid. Additional <scopecontent> elements may be nested inside one another when a complex collection of materials is being described and separate headings are desired. For example, when a collection is received and processed in installments, individual scope and content notes may be created for each installment. EAD permits these separate narrative descriptions to be encoded as discrete <scopecontent> elements, but it also enables the encoder to gather the independent <scopecontent> notes within a single larger <scopecontent> reflective of the materials as a whole. 28

30 <arrangement> Arrangement In this element, we find Information of two different types. One is a statement of how the materials have been subdivided into smaller units, e.g., how a fonds is grouped into series. The other use of <arrangement> is to express the filing sequence of the described materials, the principle characteristics of the internal structure, or the physical or logical ordering of materials, including alphabetical, chronological, geographical, office of origin, and other schemes. Identifying logical groupings and the arrangement pattern may enhance retrieval by researchers. <arrangement> <head>sistema de arranjo</head> <p>o fundo encontra-se organizado em 11 séries: Documentos pessoais; Presidente do diretório do PTB/RS; Presidente do PTB; Ministro do Trabalho; Vice-Presidente da República; Presidente da República; Exílio; Post-mortem; Recortes de Jornais; Fotografias; Bibliográficos.</p> </arrangment> <arrangement> <head>sistema de arranjo</head> <p> O códice está ordenado cronologicamente </p> < / arrangment> More complex encoding is also possible using a list. Here each of the three series is coded separately as an Item within a List. <arrangement> <head>sistema de arranjo</head> <p> A documentação foi arranjada em 3 séries, a saber: </p> <list> <item> Cândido Venâncio Pereira Peixoto: documentos particulares</ item> <item> Administração</item> <item>exame Contábil</item> </list> </arrangment> 29

31 This permits a stylesheet later to identify the text of each series title as a discrete piece of data and displayed each on a separate line like this. Sistema de arranjo A documentação foi arranjada em 3 séries, a saber: Cândido Venâncio Pereira Peixoto: documentos particulares Administração Exame Contábil <custodhist> Custodial History This element contains information about the chain of ownership of the materials being described. Both physical possession and intellectual ownership can be described, providing details of changes of ownership and/or custody that may be significant in terms of authority, integrity, and interpretation. The history of custody is sometimes synonymous with aspects of the concept of provenance. However, a description of archival provenance, in the sense of those responsible for the creation of the documents, may be more appropriately recorded in the <origination>, <bioghist>, or <scopecontent> elements. Use Acquisition Information <acqinfo> for text about the immediate source of the described materials and the circumstances under which they were received by the repository. <custodhist> <head>história arquivísta </head> <p>por ser a presidência da Comissão assumida pelo diretor do Museu Nacional, parte de sua documentação permaneceu sob a guarda desta última instituição. Em 2001 esta documentação foi considerada um fundo distinto daquele do próprio Museu Nacional.</p> </custodhist> 30

32 <phystech> Physical Characteristics and Technical Requirements Sometimes we might describe important physical conditions or characteristics that affect the storage, preservation, or use of the materials described. These includes details of their physical composition or the need for particular hardware or software to preserve or access the materials. <phystech> <head>características ficas e requistos ténicos </head> <p>fotografia com pequenos furos em sua superfície.</p> </phystech> 31

33 <controlaccess> Controlled Access Headings As our inventories become accessible online, we need to make it possible for researchers to locate materials of specific interest within descriptions that are often very large and complex. Of course, most search engines permit the user to search the full text of the inventory by particular words or phrases. This type of searching is what we seem to be doing when we type words into a web search engine like Google or Alta Vista. In fact, sophisticated web developers rely on something more complex to guide users to their sites than simply the ability of Google to index every word in a document. They are also specifying particularly important terms- names, places, topics, themes- in their web pages. We can't see them in our browser but Google can and gives them greater importance when it indexes documents. This additional metadata facilitates more precise searching. As archivists we similarly need to specify in our inventories the most important points of access to aid indexing and retrieval of data. Librarians have been doing this for a century to aid access to published materials. For archives in Brasil, NOBRADE has created a new area of description for the recording of this data. It is called the Area of Points of Access and Indexing of Subjects. EAD has a series of elements for encoding the different types of access points found in this area, They include <controlaccess> <pername> <corpname> <famname> <subject> <geogname> <genreform> <function> <occupation> Personal name Corporate Names Family names Subjects Geographic Names Genre and Physical Characteristics Functions Occupations Ali of these data elements may then be brought together in a single part of the inventory. In EAD, the are all wrapped in a parent element called <controlaccess>. Where hundreds of names and subjects can appear in a finding aid, this element permits us to highlight the most significant of them. There are two reasons why this element is called Controlled Access. First, there is the obvious fact that the terms have been specifically brought together in this area. The second is that the terms recorded here typically are in a standardized form that is prescribed by an authority file, theausus, or even a local headings list. This creates consistency that improves indexing and retrieval 32

34 Although names and terms from locally controlled vocabularies are permissible, the <controlaccess> subelements (<corpname>, <famname>, <function>, <genreform>, <geogname>, <occupation>, <persname>, <subject>, and <title>) should come from national or international vocabularies whenever they are available to enable searches in information systems that include multiple finding aids, or finding aids and bibliographic records from many institutions. This example includes headings from several different fonds simply for illustrative purposes <controlaccess> <head>descritores</head> <persname>gramajo, Osbert- fotografía</persname> <persname>roca, Júlio Argentino - fotografia</persname> <corpname>ministério da Educação (Brasil).</corpname> <geogname>plata, Rio de la (Argentina e Uruguai) - fronteiras</geogname> <geogname>américa descrições e viagens</geogname> <geogname>américa história</geogname> <geogname>américa - Política econômica </geogname> <subject>filosofia e arte</subject> <subject>missões</subject> <subject>índios Mojo</subject> <subject>índios da América do Sul</subject> <subject>rios da América do Sul</subject> <genreform>legislação </genreform> <genreform>direito público</genreform> <genreform>biografias</genreform> </controllaccess> 33

35 Conditions Governing Access and Use There are two further elements that relate to a reader's ability to use records. <archdesc> <accessrestrict> <userestrict> Archival description Conditions governing access Conditions governing use <accessrestrict> Conditions Governing Access Sometimes we need to record information about conditions that affect the availability of materials for research. Physical, logistical, or administrative circumstances may require the researcher to make an appointment or wait a period of time before being able to use records. Other restrictions on use may be imposed by the donor, legal statute, the repository, or other agency. Conversely, one may also indicate a lack of restrictions. This element is not be confuse with Conditions Governing Use <userestrict>, which designates information about limitations on the use of the described materials after access has been granted. We will consider that element next. <accessrestrict> <head>condições de acesso</head> <p>documentos manuscritos acessíveis somente por microfilme; documentos cartográficos acessíveis em originais e formato digital; documentos bibliográficos acessíveis em originais e por microfilme.</p> </accessrestrict> 34

36 <userestrict> Conditions Governing Use This element contains information about conditions that affect use of the described materials after access has been granted, such as copyright restrictions. It may indicate other limitations, regulations, or special procedures imposed by a repository, donor, legal statute, or other agency regarding reproduction, publication, or quotation of the described materials. It may also indicate the absence of restrictions, such as when copyright or literary rights have been dedicated to the public. <userestrict> <haad>condiçoes reprodução</head> <p>os documentos textuais e bibliográficos podem ser reproduzidos por via eletroestática, fotográfica ou digital; os documentos iconográficos podem ser reproduzidos por meio fotográfico ou digital. No caso das fotos é necessário a assinatura de um termo de cessão de uso de imagens.</p> </userestrict> 35

37 Adjunct Descriptive Data There are several descriptive elements that do not describe the records themselves but rather provide useful information that may assist the researcher in understanding the documents and using them more effectively. <archdesc> <otherfindaid> <originalsloc> <altformavail> <relatedmaterial> <separatedmaterial> <bibliography > Archival description Otherfinding aid Location of originals Alternative form available Related materials Separated materials Bibliography <otherfindaid> Other Finding Aid This element contains information about additional or alternative guides to the described material, such as card files, dealers inventories, or lists generated by the creator or compiler of the materials. It is used to indicate the existence of additional finding aids; it is not designed to encode the content of those guides. Do not confuse with <fileplan>, which designates information about a particular type of access tool, known as a file plan, which explains the classification scheme used by the parties originally responsible for creating or compiling the described materials. <otherfindaid> <head>instrumento de persquisa</head> <p>guia de fundos do CPDOC e sistema Accessus. on- line</p> </otherfindaid> 36

38 The Bibliographic Reference <bibref> element may be used within <otherfindaid> to give a formal citation to the other fmding aid or to link to an online version of it. In this example, the citation is divided into a series of sub elements; <corpname>, <title>, and <imprint>. <otherfindaid> <head>instrumento de persquisa</head> <bibref> <corpname> Arquivo Nacional (Brasil).</corpname> <title type="livro"> Catálogo dos Documentos Iconográficos dos Fundos Privados.</title> <imprint> <geogname> Rio de Janeiro</geogname> <publisher>o Arquivo</publisher> <date> 1998</date>. </imprint> 291p </bibref> </otherfindaid> <originalsloc> Location of Originais Here we find information about the existence, location, availability, and/or the destruction of originals where the unit described consists of copies. Do not confuse <originalsloc> with Alternative Form Available <altformavail>, which is used to encode information about copies of the material being described. <originalsloc> <head>existência e localização dos originais</head> <p>entidade custodiadora: Arquivo Nacional (Brasil)</p> </originalsloc> 37

39 <altformavail> Alternative Form Available Here we find information about copies of the materials being described, including the type of alternative form, significant control numbers, location, and source for ordering if applicable. The additional formats are typically microforms, photocopies, or digital reproductions. Do not confuse with Location of Originals <originalsloc>, which is used to encode information about the existence, location, and availability of originals where the unit described consists of copies. <altformavail> <head> Existência e localização de cópias</head> <p>cópia em meio eletrônico, disponível no local.</p> </altformavail> 38

40 Related Material The ISAD(G) Related Material element is divided in EAD into two separate elements to differentiate two different situations in archival work that ISAD(G) does not distinguish. First, there is the scenario where an archives holds other records that are related to those being described because of similar characteristics such as covering common subject matter. Descriptions of these records are described in the Related Material <relatedmaterial> element in EAD. But there is a second situation that we encounter with archival materials. Sometimes materials with a common provenance are divided among multiple institutions. This most often occurs with personal and family papers but also sometimes with organizational and governmental records. If the archivist wishes to differentiate between these two scenarios, a second element is available where one might encode data about records with a common provenance that are held in another institution. It is called Separated Material <separatedmaterial>. <relatedmaterial> Related Material This is the element for the description of materials that are not physically or logically included in the records described in this finding aid but that may be useful for the reader to know about because of some association with them. Do not confuse <relatedmaterial> with the element <separatedmaterial> which provides information about materials that have been separated or physically removed from the described materials but that are related to them by provenance. Also do not confuse with <altformavail>, which encodes information about copies of the described materials, such as microforms, photocopies, and reproductions in digital formats. Do not confuse with <originalsloc>, which encodes information regarding the existence and location of the originals when the unit being described consists of copies. <relatedmaterial> <head>unidades de descrição relacionadas</head> <p>ver também as Coleções: América do Sul ( ); Bolívia ( ); Chaco ( ); Chile ( ); Decimal ( ); Europa ( ); Ilhas Malvinas ( ); Limites do Brasil ( ); México ( ); Missões Espanholas na América ( ); Paraguai ( ); Patagônia ( ); Províncias do Rio da Prata ( ) e República Argentina (l ).</p> </relatedmaterial> 39

41 <separatedmaterial> Separated Material Here we find Information about materials that are associated by provenance to the described materials but that are now physically separated. This may occur for various reasons, including the dispersal of special formats to more appropriate custodial units; the outright destruction of duplicate or nonessential material: and the deliberate or unintentional scattering of fonds among different repositories. Do not confuse with <relatedmaterial>, which is used to encode descriptions of or references to materials that are not physically or logically included in the material described in the finding aid but that may be of use to a reader because of an association to the described materials. Items encoded as <relatedmaterial> are not related to the described material by provenance, accumulation, or use. <separatedmaterial> <head>unidades de descrição relacionadas</head> <p> Entidade custodiadora: Academia Brasileira de Letras</p> </separatedmaterial> <bibliography> Bibliography Sometimes an inventory contains a citation to works that are based on, about, or of special value when using the materials being described, or works in which a citation to or brief description of the materials is available. The works could be books, articles, television programs, unpublished reports, web sites, or other forms of information. The <bibliography> may be a simple <list>, a list of both Bibliographic References <bibref> and Archival References <archref>, or a series of Paragraphs <p>. A bibliographic reference may be recorded simply as text within a Paragraph. In this example, the title is specified in a <bibliography> <head>nota sobre publicação</head> <p>ministério da Educação (Brasil) Floriano: Memória e documentos. Organização de Artur Vieira Peixoto. Imprensa Nacional, volumes. </bibliography> 40

42 Alternatively, the various components of a bibliographic citation may be subdivided into various elements. <bibliography> <head>nota sobre publicação</head> <bibref> <persname>bandeira, Moniz</corpname> <title>o governo João Goulart: as lutas sociais no Brasil </title> <imprint> <geogname>rio de Janeirc</geogname> <publisher>ed. Civilização Brasileira</publisher> <date type="publicação">1977</date> p. 187 </imprint> </bibref> </bibliography> 41

43 Administrative Information Within EAD there are four elements that provide administrative information that is deemed useful for the archivist but that may or may not be of particular interest to the user. They are <archdesc> <acqinfo> <processinfo> <appraisal> <accruals> Archival Description Acquisition information Processing information Appraisal Accruals <acqinfo> Acquisition Information Description: The immediate source of the materials describes the circumstances under which the records were received. It includes donations, transfers, purchases, and deposits. After opening a Paragraph <p> within <acqinfo>, optional subelements may be used to tag separately such common acquisition information as the name of the source, e.g., <persname> or <corpname>; the <date> the materials were received; or the accession number <num> assigned to them. The <address> element could be used to document the address of the source, and the AUDIENCE attribute could be set to "internal," if the address information should only be available to authorized staff. Note that the accession number may also serve as the <unitid> and be encoded as such within a <did>. The Custodial History <custodhist> element can be used for information about the chain of ownership before the materials reached the immediate source of acquisition. <acqinfo> <head>procedência</head> <p>os documentos do dossiê pertenciam à parcela do fundo doada por Luiz Alberto Moniz Bandeira ao CPDOC da Fundação Getúlio Vargas, em março de 2003.</p> </acqinfo> 42

44 <processinfo> Processing Information This element contains information of many different types about accessioning, arranging, describing, preserving, storing, or otherwise preparing the described materials for research use. Specific aspects of each of these activities may be encoded separately within other elements, such as <acqinfo>, <arrangement>, <physloc>, etc. <processinfo> <head>notas sobre conservação</head> <p>mapas - alguns restaurados e digitalizados, outros necessitando de restauração. Demais documentos - em bom estadot</p> </processinfo> <appraisal> Appraisal Information Researchers may find it useful to know about the process of determining the archival value and thus the disposition of records based upon their current administrative, legal, and fiscal use; their evidential, intrinsic, and informational value; their arrangement and condition; and their relationship to other records. <appraisal> <head>avaliação, eliminação e temporalidade</head> <p>a documentação da extinta LLOYDBRAS foi avaliada, selecionada e eliminada com base na Tabela Básica de Temporalidade e Destinação de Documentos de Arquivo relativo às Atividades-Meio da Administração Pública, aprovada pela Resolução n 4, de 28/3/1996, e revista e ampliada pela Resolução n 14, de 24/10/2001, do Conselho Nacional de Arquivos (CONARQ).</p> <p>foram eliminados documentos relativos às áreas de organização e funcionamento, de pessoal, de orçamento e finanças, de material e patrimônio e documentação técnica, do período de 1947 a 1997, num total de l.450 metros lineares de documentos, conforme consta do Edital de Ciência de Eliminação de Documentos, publicado no D. O. U. de 3//2/2003, Seção 3, página 55.</p> </appraisal> 43

45 <accruals> Accruals Description: Accruals contains information about anticipated additions to the materials being described. Can indicate quantity and frequency. It can also be used to indicate that no additions are expected. <accruals> <head>incorporações</head> <p>algumas subséries poderão receber novos acréscimos de documentos em decorrência do processo de identificação levado a termo no âmbito do fundo Museu Nacional.</p> </accruals> 44

46 Multi-level Description One of the most distinctive features of archival inventories is that they not only describe each of the series, files and items in a fond, but that they also present these components (to use a term that is central to EAD) of the fond together in a way that reflects the hierarchical nature of the physical arrangement of the materials themselves. An archival inventory is not like bibliographic catalog entry where each book is more or less an independent entity. An inventory has two objectives: to describe each component (series, file, item) and to arrange those descriptions so that they repeat the physical order of the records. EAD must address these same two challenges from an electronic perspective. The following chart from NOBRADE illustrates the complex variety of hierarchical relationships that occur within different fonds or even within different parts of the same fond. As you can see, in some cases the child of the fond is a subseries, in some cases a series., and possibly even a dossier. 45

47 46

48 The following chart specifically illustrates the hierarchical relationships among parts of the records of the fond we have been using as an example, namely the Special Commission. The entire fond itself which is divided into three series (série). Each series consists of a number of organizational units (dossiê/processo) each of which contains between l and 203 files. Within each of these dossiers there are many individual documents that also could be described if the archives had the desire and the resources to do so. As noted earlier, an inventory has two goals, the first of which is to describe each of the series, subseries, and files individually. Collectively, EAD refers to all of these as Components. That is an important term of which you need to take note. One of the principles we stated previously is that the same elements of description may potentially be used at every level of the hierarchy, for every component. Of course, we know that a fond is normally described in greater detail than an individual series. As a practical matter, less information is usually recorded for a dossier and individual items are described in a very summary fashion if at all. This applies with FAÜ encoding as well, namely that the same codes we have applied to data in the description of a fond may also be used to encode any series, subseries, file, or item that we might include. 47

49 48

50 To illustrate this point, let s examine the second series in this fond, the Administrative records of the Commission. It is the middle one on the previous chart. Here is the text of that description. Cód. de Referência BRAN1H2 Título Administração Datas 1889 a 1932 Dimensão 0,44 m de documentos textuais l foto (p & b) Produtor Comissão Especial de Exame do Cofre dos Órfãos Nível de Descrição Série Âmbito e Conteúdo Documentação de caráter administrativo sobre o funcionamento da Comissão, incluindo uso de verbas especiais para pagamento de gratificações aos servidores, requerimentos dos servidores, estudos legislativos e propostas de novos atos para tornar permanente o trabalho da Comissão, despesas com telefone, solicitação de devolução de móveis emprestados á Comissão, levantamento de legislação sobre o Cofre dos Órfãos desde as Ordenações e foto de servidores [?]. Sistema de Arranjo A documentação foi arranjada em ordem cronológica, sendo, às vezes, inferida a data dos documentos. Condições de acesso Documentação pública. 49

51 When we encode that information in EAD, it looks like this. <did level="otherlevel" otherlevel="série> <head>identificação</head> <unitid label="cód. de Referência"countrycode="BR" repositorycode="an">lh 2</unitid> <unititle label="título">administração</unititle> <unitdate label="datas" normal="1889/1932">1889 a 1932</unitdate> <physdesc label="dimensão">0,44 m de documentos textuais</physdesc> <physdesc>l foto (p & b)</physdesc> <origination label=" Produtor "> <corpname>comissão Especial de Exame do Cofre dos Órfãos</ corpname> </origination> </did> <scopecontent> <head>âmbito e Conteúdo</head> <p>documentação de caráter administrativo sobre o funcionamento da Comissão, incluindo uso de verbas especiais para pagamento de gratificações aos servidores, requerimentos dos servidores, estudos legislativos e propostas de novos atos para tornar permanente o trabalho da Comissão, despesas com telefone, solicitação de devolução de móveis emprestados á Comissão, levantamento de legislação sobre o Cofre dos Órfãos desde as Ordenações e foto de servidores [?].</p> </scopecontent> <arrangement> <head>sistema de Arranjo</head> <p>a documentação foi arranjada em ordem cronológica, sendo, às vezes, inferida a data dos documentos.</p> </arrangement> <accessrestrict> <head>condições de acesso</head> <p>documentação pública.</p> </accessrestrict> 50

52 There is a Descriptive Identification <did> element with sub elements for the Identification, Title, Dates, Physical Description and the Name of the Creator of the series. These are followed by three elements containing the Scope and Content statement, the Arrangement of the records, and a note about Restrictions on Access. In the EADencoding, each of these elements contains a display Head and a Paragraph. Similarly, let s examine the content and the encoding of the first processing unit within this series. Its content looks like this in the inventory. Cód. de Referência 1H 2 9 Título Processo da 3 a Diretoria do Tribunal de Contas Referente à representação de Cândido Venâncio Pereira Peixoto. Resumo Solicitação de franqueamento pela Recebedoria do Distrito Federal à escrituração do Cofre dos Órfãos, para os exames necessários à tomada de contas. Datas 24/08/1905 Dimensão 4fls. Actually, in this example I have taken the liberty of dividing a rather lengthy title statement that appears in the inventory into a short title and an abstract with the expectation that it might be easier for the user to read and understand it this way. 51

53 When we encode this same data in EAD, it looks like this. <did level="otherlevel" otherlevel=processo> <unitid label="cód, de Referência">lH 2 9</unitid> <unititle label="título">processo da 3 a Diretoria do Tribunal de Contas Referente à representação de Cândido Venâncio Pereira Peixoto. </unititle> <unitdate label-"datas" normal=" ">24/08/1905</unitdate> <abstract label="resumo">solicitação de franqueamento pela Recebedoria do Distrito Federal à escrituração do Cofre dos Órfãos, para os exames necessários à tomada de contas. </abstract> <unitdate label="datas">24/08/1905</unitdate> <physdesc label="dimensão">4 fls.</physdesc> </did> You will also notice that entire description falls within the Descriptive Identification <did> group. This is not uncommon in the description at lower levels of arrangement and description. You will also note that I have used the Abstract <abstract> element rather than a separate Scope and Content <scopecontent> statement. While the data may be appropriately encoded in either place, its brevity makes it seem more like an abstract to me. We will create many encoded descriptions like these for each of the individual series and subseries and dossiers and files items. This brings us to the second challenge for the archivist- to associate these separate descriptions in a way so that the computer can understand their hierarchical relationships. These descriptions cannot just be "floating" around. We need a way to specify that a particular dossier is part of a particular series or subseries. EAD does this with the simple concept of Components. In this chart, each of the three series, like the center one of Administrative records, is a component of the fond. They are its children. Each of the processing units beneath it is a component (and child) of that series. The description of each of the these units of arrangment is embedded in a Component element. We keep the hierachical relationships among the components in order by numbering them relative to the fond. Ali of the series are encoded as Component Level l <c01>. Ali of the processing units are encoded as Component Level 2 <c02> 52

54 53

55 <dsc> Description of Subordinate Components This element is simply a wrapper element that bundles the descriptions of all the components in the hierarchy that are subordinate to the fond. The components at the first level down in the hierarchy are encoded as <c01>. <c01> Component (First Level) This is a wrapper element that designates the top or first-level subordinate part of the materials being described. The numbered components <c01> to <c12> assist a finding aid encoder in nesting up to twelve component levels accurately. The LEVEL attribute is used to identify which level of description the <c0l> covers, e.g., "series," "subseries," "file," or "item." The OTHERLEVEL attribute permits the use of locally designated terminology. In the previous example, each series description is wrapped with a <c01> tag. The component numbers are hierarchical and not sequential. if a fond had 50 series, they would all be encoded as level <c01>. <c02> Component (Second Level) Each child element of a first level component is encoded as a second level component <c02> and is nested inside that <c01>. While some theoretical models show five or six levels of arrangment, we know that in practice complex collections may have more levels than that and so EAD provides component levels up to level <c12>. 54

56 55

57 The last important concept is to note that the description of a component is always nested inside that of its parent as a way of physically expressing the relationships. Here the nesting of elements, basic to XML, matches archival description very nicely. This model shows how the nesting looks, with all the components within a Description of Subordinate Components <dsc> element. <dsc> <c01 level="série"> Description of a series <c02level= "Processo "> The description of a processing unit. <c03 level="item"> The description of a documentary item. </c03> <c03 level="item"> The description of a documentary item. </c03> <c03 level="item"> The description of a documentary item. </c03> <c03 level="item"> The description of a documentary item. </c03> </c02> </c01> <c01 level="série"> Description of a series <c02 level="processo"> The description of a processing unit. </c02> </c01> </dsc> </archdesc> </ead> 56

58 Notice that in this example a <c02> may be either a processing unit or an item. In either case, the <c02> is embedded with in the <c01>, that is to say the <c02> opens and closes before the <c01> closes. Description in the second series is done only to the level of processing unit. The coding all depends on the nature of the materials. This ends the description of the components as marked by the end tag for the <dsc> element. We have also come to the end of the archival description as indicated by the end tag for the <archdesc> grouping. Finally, it is also the end of the EAD document with the <ead> end tag closing off the EAD instance. At this point, we will return back to the beginning of the electronic finding aid to complete our work by examining the EAD Header <eadheader>. You will recall that we discussed it briefly at the beginning of our review of EAD but defered it until now. 57

59 We have been reviewing <archdesc>. The EAD Header <eadheader> is the other major part of an EAD-encoded inventory. It is simply metadata about the electronic EAD file and not about the records themselves. For the most part, it contains information that will not come from an existing paper finding aid because it deals with aspects of the electronic document. Though we are discussing it at the end of our overview of EAD, <eadheader> actually must appear first in the electronic file. And while there are few required elements in EAD (that is up to national or local descriptive standards), most of those that are mandatory appear in the <eadheader>. <eadheader> EAD Header This is a wrapper element for bibliographic and descriptive information about the finding aid as a document rather than about the archival materials themselves. It is required because information that was often unrecorded for a local paper finding aid is essential in a machine-readable environment. It has five attributes that are embedded explicitly into every EAD instance as default values. They specify particular ISO standards with which an EAD document must conform if it includes coded information to specify a country, repository, dates, languages, and scripts. In other words, if an EAD document includes a coded value in the COUNTRYCODE attribute in the <eadid> or <unitid> elements, that coded value must be consistent with ISO standard If a normalized form of a date is recorded in the NORMAL attribute of <unitdate> or <date>, it must conform to the norms of ISO Standard EAD Header has four sub elements: <eadheader> <eadid> <filedesc> <profiledesc> <revisiondesc> EAD header EAD Identifier File Description Profile Description Revision Description They must appear in this order. The first two of them, <eadid> and <filedesc>, are mandatory. These elements and their subelements provide a unique identification code for the finding aid; bibliographic information, such as the author and title of the finding aid; information about the encoding of the finding aid; and statements about significant revisions. 58

60 Here is a sample of an EAD Header. Let me go through it and explain the use of the various elements. <eadheader langencoding="iso639-2" countryencoding="iso3166-l" dateericoding="iso8601" repositoryencoding="iso15511" scriptencoding="iso15924"> <eadidcountrycode="br" mainagencycode="an">l H</eadid> <filedesc> <titlestmt> <titleproper>inventário da Comissão Especial de Exame do Cofre dos Órfaos</titleproper> <author>vitor Manoel Marques da Fonseca; Mauro Lerner Markowski</author> </titlestmt> </filedesc> <profiledesc> <creation>digitação e copidesque: Vitor Manoel Marques da Fonseca e codificação EAD: Michael Fox, <date>1999.</date> </creation> <langusage>inventário en português</langusage> <descrules>norma Geral Internacional de Descrição Arquivística (ISAD)G</descrules> </profiledesc> <revisiondesc> <change> <date>15 February 2007</date> <item>conversão para EAD em 2002</item> </change> </revisiondesc> </eadheader> 59

61 <eadid> EAD Identifier A required subelement of <eadheader> that designates a unique code for a particular EAD finding aid document. Two of the attributes, COUNTRYCODE and MAINAGENCYCODE, are required to make the <eadid> compliant with ISAD(G) element MAINAGENCYCODE provides the ISO code for the institution that maintains the finding aid (which may not be the same as the institution that is the custodian of the materials described). COUNTRYCODE supplies the ISO code for the country of the maintenance agency. <filedesc> File Description This is the other required subelement of the <eadheader>, one that bundles much of the bibliographic information about the finding aid, including its author, title, subtitle, and sponsor (all in the <titlestmt>), as well as the edition, publisher, publishing series, and related notes (encoded separately). The required Title Statement File <titlestmt> consists of a required Title Proper <titleproper> as well as a Author Statement <author> and a Subtitle <subtitle>. This title statement is not to be confused with the title of fonds which is found in the Unit title in Archival Description. It is the title of the finding aid itself. Note that the title here states that it is the "Inventory "of the records of the Special Commission, not the records of the Special Commission. Likewise, the Author element records the name of the person who created the inventory, not the person who did the encoding. That information is recorded in <profiledesc>. 60

62 <profiledesc> Profile Description This is another optional subelement of the <eadheader> that bundles information about the creation of the encoded version of the finding aid, including the name of the agent, place, and date of encoding. The <profiledesc> element also designates the predominant and minor languages used in the finding aid. Within <profiledesc> the Descriptive Rules <descrules> element can be used to specify the descriptive code or guidelines followed in creating the finding aid, Here the reference is the new Brasilian rules. <descrules> Descriptive Rules A subelement of Profile Description <profiledesc> for the enumeration of the rules, standards, conventions, and protocols used in preparing the description. The <descrules> element is comparable to ISAD(G) data element <revisiondesc> Revision Description This is another optional subelement of the <eadheader> for recording information about changes or alterations that have been made to the encoded finding aid. The revisions may be recorded as part of a <list> or as a series of <change> elements. The example shows that the finding aid was originally encoded in 2001 for a workshop here at the National Archives in Rio and has been more recently converted to the version EAD

63 ENCODED ARCHIVAL CONTEXT (EAC) Encoded Archival Context (EAC) is a standard for the electronic management of archival authority information of the type defined by ISAAR (CPF). EAC is a companion to EAD as ISAAR (CPF) is a companion to ISAD (G). As noted earlier, ISAAR (CPF) is the data content standard for authority records, EAC is the Communications formal The introduction to ISAAR (CPF) describes its scope and purpose: "to provide guidance for preparing archival authority records which provide descriptions of entities (corporate bodies, persons and families) associated with the creation and maintenance of archives." The structure of ISAAR (CPF) reveals the nature of the information that is contained in an archival authority record and the ways in which one differs from the authority information created by librarians. An ISAAR (CPF) compliant authority record might contain information in the following general areas: Identity- a name that uniquely identifies a person, family or corporate body Description- the nature, context and activities of that entity Relationships- other associated corporate bodies, persons or families Control- archival management information References-links to other informational resources by or about the entity. Four elements are considered to be "essential" in an authority record: type of entity, authorized for the name, dates of existence, and a record identifier. Before reviewing the overall structure of EAC and its individual elements, several general observations are in order. L EAC currently exists as a draft so it is still a work in progress. While I suspect that the final version will be very much like what I am describing here, one cannot be certain about all particulars. The timetable for finalizing the standard and forming an international maintenance body like the EAD Working Group is unclear at this moment. 62

64 2. The high-level data structure of EAC is very much like that of EAD: a header with information about the electronic file, followed by the body of the description. Beyond that, the structure of EAC is more complex than that of EAD. EAD was created by examining the structure of a large number of existing archival inventories as a way to codify existing practice. There was also a body of well-defined and broadly implemented descriptive standards supporting that practice. There was existing warrant for what was defined in EAD. The same is not true of authority data There is an established history of authority work in libraries but that usually has the very limited scope of headings management, ensuring that a consistent form names used as headings in catalog records. In several countries there are national archival authority systems, notably the United Kingdom and Sweden. But these predate any international standards. Finally, while ISAAR (CPF) was first introduced in 1996, it received little attention and almost no use until the second and greatly revised edition was adopted in Lacking existing models, the authors of EAC had to build on the structure of the second edition of ISAAR (CPF) and their best thinking as to how archives might implement it in the future. There were few existing models to verify it against. As a result the EAC structure is extremely flexible to accommodate a range of possible future uses. This presentation will attempt to reduce some of that complexity and illustrate how EAC can be used to create a basic authority record, using the Brasilian example of an entry for the National Archives that appears in the appendix of examples in ISAAR (CPF). In doing so, you will miss some of the flexibility and power of EAC but that is a practical tradeoff one must make for this occasion. 63

65 The Elements of EAC We will begin with a review of the principal elements in EAC, what each of them means, and how they are related to one another in the encoding of an archival inventory. The following descriptions have been adapted from the EAC Tag Library. which contains additional information about these elements. It also covers other elements that our limited time and space here does not permit us to discuss. The discussion of each element begins with the full name of the element and its shortened form as it appears in markup. In the examples in this text, the names of attributes appear in upper case letters to distinguish them from the names of elements. In actual encoding, the names of elements and attributes are written entirely in lower case letters. <eac> Encoded Archival Context This is the root or outermost wrapper element that marks the beginning and ending of an authority record. The <eac> element identifies a particular electronic record as being encoded according to the EAC document type definition or schema. 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. This element has two child elements. Both are required and must appear in the following order: eacheader context description It has one very important and mandatory attribute, TYPE, which specifies whether the entity described in the record is a personal, corporate or family name. Many subsequent encoding decisions depend on which type of name is indicated here. So, the overall structure of an encoded document looks like this. Indention is used in these examples to make the hierarchy more apparent but is not technically required. <eac type="corporate"> <eacheader> Information about the electronic file. </eadheader> <condesc> The authority description itself </condesc> </eac> 64

66 If we expand this out, we can compare the areas of EAC with the major sections of ISAAR (CPF). They align this way. <eac> EAC <eacheader><eadheader> ISAAR (CPF) Areas Control <condesc> <identity><identity> <desc></desc> <eacrels></eacrels> <resourcerels></resourcerels Identity Description Relationships Resource references </condesc> </eac> 65

67 <identity> Identity The first element in the context description <condesc> is Identity <identity> It is a mandatory element that groups both authorized and alternative name headings that identify the entity being described, as well as other elements that assist in identification of the entity such as the Legal identity <legalid>. Like many elements it has a child Head <head> for specifying the text of a display heading. To understand the encoding in <identity>, we must consider first whether the name is corporate, personal, or family. There are separate groups of elements for each type. Then we must determine whether the entry contains a single representation of the name or multiple versions, both authorized and variant forms. If the record contains only a single name, it is recorded in <pershead>, <corphead> or <famhead>. If more than one form of the name is recorded, each appears in one of these three elements (as appropriate) and then all of the name elements in the record are grouped together under a heading: <persgrp>, <corpgrp>, or <famgroup>. Depending on the form of name, we will have <pershead> or <persgrp> <pershead></pershead> <pershead></pershead> <pershead></pershead> </persgrp> <corphead> or <corpgrp> <corphead></corphead> <corphead><corphead> <corphead></corphead> </corpgrp> <famhead> or <famgrp> <famhead></famhead> <famhead></famhead> <famhead></famhead> </farngrp> 66

68 Let us begin with these two, high-level elements that are the children of <eac> and then work our way down to the lower levels of information. The first child is- <eacheader> EAC Header This element contains information about the electronic file that contains a particular EAD-encoded authority record. This data includes a unique identifying number and title for the file, which are required, as well as optional information about the individuals who encoded the record, the rules used to create it and a record of changes that may have been made to the file over time. Well discuss this element more after we ve first considered those elements that describe the entity that is the subject of the authority record. <condesc> Context Description This is the parent element for the bulk of an authority record that describes a corporate body, person or family. As a wrapper element it may contain five principal children, Head, Identity, Description, EAC Relations, and Resource relations. <eac> <condesc> <head></head> <identity></identity> <desc></desc> <eacrels></eacrels> <resourcerels></resourcerels </condesc> Heading for display Identity Description EAC Relationships Resource references As with EAD, the <head> element is found in many places in an EAC record and is used for the same purpose. It specifies explanatory text that may be inserted into public displays to characterize the following data for the reader who may not be familiar with the nature of the information. 67

69 <corpgrp> Corporate Body Heading Group When a record contains more than one form of a corporate name, the <corpgrp> element is used to associate individual Corporate Heading elements <corphead> together into a group. <identity> <corpgrp> </corpgrp> <corpheadauthorized="br AN"> <part>arquivo Nacional (Brasil)</part> </corphead> <corphead rule="aacr2"> <part>brasil. Arquivo Nacional </part> </corphead> <corphead> <part>arquivo Público do Império</part> <existdate>( )</existdate> </corphead> <corphead> <part>archivo Público do Império</part> </corphead> <corphead> <part>arquivo Público Nacional </part> <existdate>( )</existdate> </corphead> <corphead> <part>archivo Público Nacional </part> </corphead> <corphead> <part>arquivo Nacional</part> <existdate>( )</existdate> </corphead> <corphead> <part>archivo Nacional</part> </corphead> 68

70 <pershead> Personal Name Heading This element contains a heading for the name given to an individual, or a name by which he/she is known, consisting of such elements as surname, forename, patronymic, or toponym. The heading may combine name elements with additional qualifiers, such as birth and death dates, to identify that individual and distinguish him or her from others with the same or 'similar name. Both for authoritative and alternative headings may be recorded with one designated as the authoritative or preferred heading by use of the AUTHORIZED attribute. The descriptive rules applied for establishing the heading are stated in the RULE attribute. The full name may be recorded together in a single Part <part> element, or the separate parts of a name entry- first name, surname, additions to the name such as titles, and datesmay be divided into separate part elements. <identity> <pershead rule="aacr2r"authorized="br AN"> <part type="surname">feio</part> <part type="forename">josé Lacerda de Araújo</part> <existdate> </existdate> </pershead> 69

71 <persgrp> Personal Name Heading Group When a record contains more than one form of a personal name, this element is used to associate individual Personal name heading elements <pershead> into a group. We also have headings for family names. <famhead> Family Heading This element contains a heading for the family, a group of persons closely related by blood or persons who form a household. The heading may combine name elements with additional qualifiers so that the family can be identified with certainty and distinguished from others bearing the same or similar names. The element is used both for authoritative and alternative headings. The internal structure of this element closely parallels that of <corphead> and <perhead>. <famgrp> Family Name Heading Group When a record contains more than one form of a family name, this element is used to associate individual Family name heading elements <famhead> into a group. The internal structure of this element closely parallels that of <corpgrp> and <pergrp>. <legalid> Legal Identification This element contains a unique identifier for the entity described in the EAC instance. Such legal identifiers are typically assigned by an authoritative and typically public agency. Though listed here, it must the first child element following a <head> within <identity> <identity> <legalid> / (Cadastro Nacional de Pessoas Jurídicas - CNPJ) (nº da unidade rotocolizadora no Governo Federal) </legalid> 70

72 <desc> Description Description constitutes the second major area of both ISAAR (CPF) and EAC. It contains information about the "history, roles, context, and activities of the corporate body, person or family." The information may appear either as a series of separate, structured elements within a <perdesc>, <famdesc>, or <corpname> element, or as a single narrative text in <bioghist>, or both. <eac> <condesc> <desc> <head></head> <persdesc></persdesc> <famdesc></famdesc> An optional headfor display Followed by one of these three elements or or <corpdesc></corpdesc> <bioghist></bioghist> followed by an optional narrative </desc> 71

73 <persdesc> Person Description <persdesc> contains structured information about a person or the context of the person. Within <persdesc>, several specific descriptive entries are available. They are Legal status Gender Location or residence) Functions and activities, Personal characteristics Cultural and physical environment. <legalstatus> <sex> <location> <funactdesc>; <character> <env> <famdesc> Family Description Family Description contains elements used to provide a formal, structured description of a family. Within <famdesc>, several specific descriptive entries are available. They are Legal status Residence Functions Assets Cultural and physical environment <legalstatus> <location> <funactdesc> <assetstruct> <env> The third category of description relates to corporate bodies <corpdesc>, which we will examine in more detail. 72

74 <corpdesc> Corporate Body Description This a parent element that groups structured information about a corporate body and its context. We will discuss each of these elements in turn. 73

75 <legalstatus> Legal Status The legal status of an entity, as the name suggests, is typically defined by government authorities and granted by the same government authorities or through authorized agencies. <desc> <corpdesc> <legalstatus> <value>órgão público do Executivo Federal, da administração direta. </value> </legalstatus> <assetstruct> Assets and Structure This element contains a description of the internal structure of a corporate body or the genealogy of a family. <desc> <corpdesc> <assetstruct> <p>tem como órgãos de assistência direta e imediata ao diretorgeral o Gabinete da Diretoria Geral e a Coordenação do Conselho Nacional de Arquivos. Como órgãos específicos e singulares, a Coordenação Geral de Gestão de Documentos, a Coordenação Geral de Processamento e Preservação do Acervo, integrada pela Coordenação de Documentos Escritos, pela Coordenação de Documentos Audiovisuais e Cartográficos e pela Coordenação de Preservação do Acervo, a Coordenação Geral de Acesso e Difusão Documental, integrada pela Divisão de Consultas, pela Divisão de Atendimento f Distância e pela Divisão de Pesquisa e Difusão do Acervo, a Coordenação-Geral de Administração e a Coordenação Regional no Distrito Federal. Ver também Apêndice</p> </assetstruct> 74

76 <causa> Causa The source of authority for the corporate body in terms of its powers, functions, responsibilities or spheres of activity, as established by laws, directives or charters is recorded in this element. <desc> <corpdesc> <causa> <p>decreto ns 4.915, de 12/12/2003, que dispõe sobre o Sistema de Gestão de Documentos de Arquivo. SIGA, da administração pública federal, e dá outras providencias </p> <p>decreto ns 4.073, de 3/1/2002, que regulamenta a lei nº 8.159, de 8/1/1991, que dispõe sobre a política nacional de arquivos públicos e privados<p> <p>portaria nº 16, de 4/7/2001, da Casa Civil da Presidência da República, que dispõe sobre o regimento interno do Arquivo Nacional da Casa Civil da Presidência da República </p> <p>medida Provisória nº , de 29/6/2000, que altera dispositivos da Lei nº 9.649, de 27/5/1998, que dispões sobre a organização da Presidência da República e dos Ministérios, e dá outras providencias [entre elas a transferência do Arquivo Nacional para a estrutura da Casa Civil da Presidência da República] </p> <p>medida Provisória nº , de 28/6/2000, que institui o Fundo Nacional de Segurança Pública. FNSP, suspende temporariamente o registro de armas de fogo e dá outras providencias [entre elas a transferência do Arquivo Nacional para a Casa Civil da Presidência da República] </p> <p>medida Provisória nº , de 28/6/2000, que institui o Fundo Nacional de Segurança Pública, FNSP, suspende temporariamente o registro de armas de fogo e dá outras providencias [entre elas a transferência do Arquivo Nacional para a Casa Civil da Presidência da República] </p> <p>medida Provisória n 2.029, de 20/6/2000, que institui o Fundo Nacional de Segurança Pública. FNSP, suspende temporariamente o registro de armas de fogo e dá outras providencias [entre elas a transferência do Arquivo Nacional para a Casa Civil da Presidência da República] </p> </causa> et cetera 75

77 <funactdesc> Function or Activity Description This is a prose description of the functions and activities of the corporate body or person. <desc> <corpdesc> <funactdesc> <p>gestão e recolhimento dos documentos produzidos e recebidos pelo Poder Executivo Federal, preservação e acesso aos documentos sob sua guarda e acompanhamento e implementação da política nacional de arquivos, na forma do disposto no art. 2º do decreto n 3.843, de 13/6/2001. <p> </funactdesc> <location> Location This element contains information on the place or jurisdiction where the entity was based, lived or resided or had some other connection. If there is more than one location, they are grouped together within a <locations> element. <desc> <corpdesc> <location> <place>sediado no Rio de Janeiro e dispondo de uma coordenação regional no Distrito Federal, em Brasília, atua em todo o território nacional. </place> </location> 76

78 <env> Environment Information on the social, cultural, economic, and political context in which the corporate body, person or family operated. <desc> <corpdesc> <env> <p> A instituição foi criada no contexto da formação do Estado Nacional, sendo já prevista na 1ª Constituição (1824), dois anos após a proclamação da independência. Durante o período imperial, na medida em que o país era unia monarquia centralizada, reuniu também documentos de origem provincial. Com a República, dado seu caráter federativo, passou a atuar primordialmente no âmbito do Executivo Federal. O Arquivo Nacional custodia acervo oriundo dos poderes Executivo, Legislativo e Judiciário, documentação cartorária e privada, esta de pessoas, famílias e instituições</p> <env> 77

79 <bioghist> Biography or History This is a concise essay or chronology that places the corporate body, person or family in its historical context. Includes significant information about the administrative history of a corporate body, or the life of an individual or family. The <bioghist> may contain a series of Paragraphs <p>, and/or a Chronology List <chronlist> that matches dates and date ranges with associated events. In its structure and use, it is identical to the element of the same name in EAD. 78

80 <bioghist> <head>história</head> <p> Previsto na Constituição de 1824, o Arquivo Público do Império foi estabelecido na Secretaria dos Negócios do Império pelo regulamento nº 2, de 2/1/1838. Tinha por competência a guarda dos diplomas legais dos poderes Legislativo, Executivo, Judiciário e Moderador, dos documentos eclesiásticos, dos relativos f família imperial e rs relações exteriores. Em 3/3/1860, o decreto nº reorganizou o órgão, que passou a guardar e classificar os documentos concernentes ao direito público, f legislação, r administração, f história e geografia do Brasil.</p> <p>em 21/11/1890, pelo decreto nº 10, o Arquivo Público do Império teve seu nome alterado para Arquivo Público Nacional, mantendo-se na Secretaria dos Negócios do Interior. Em 3/12/1892, o decreto n l. 160 o transferiu para o Ministério da Justiça e Negócios Interiores. </p> <p>em 21/11/1958, o decreto nº aprovou uma nova competência para órgão: preservar os documentos de valor administrativo ou histórico, oriundos dos órgãos da União e entidades de direito privado por ela instituídos e os de valor histórico, provenientes de entidades públicas ou particulares; possibilitar seu uso aos órgãos governamentais e particulares e promover a pesquisa histórica, realizá-la, e divulgar a história pátria, visando a educação cívica do brasileiro.</p> <p>em 15/10/1975, a portaria nº 600-B do Ministério da Justiça determinou que o órgão tinha por finalidade recolher e preservar o patrimônio documental do país com o objetivo de divulgar o conteúdo científico cultural e incentivar a pesquisa lacionada com os fundamentos e as perspectivas do desenvolvimento nacional. </p> <p>a portaria nº 384, de 12/7/1991, do Ministério da Justiça, aprovou um novo regimento interno para o Arquivo Nacional, que se tornou o órgão central do Sistema Nacional de Arquivos. Sua finalidade, desde então, é executar a gestão, o recolhimento, a guarda, a preservação e a restauração do acervo arquivístico da Administração Pública Federal, bem como dos documentos privados de interesse público, sob sua guarda, garantindo o acesso público rs informações neles contidas, com o objetivo de apoiar o governo nas suas decisões político-administrativas, o cidadão na defesa dos seus direitos, divulgando o conteúdo de natureza técnica, científica e cultural, incentivando a pesquisa e implementando a política arquivística do Governo Federal, visando a racionalização e a diminuição dos custos públicos. </p> <p> Em junho de 2000 várias medidas provisórias visando dar melhores condições ao combate r violência na sociedade brasileira são editadas e reeditadas, implicando em reorganização ministerial. No conjunto dessas mudanças, o Arquivo Nacional tem sua subordinação transferida do Ministério da Justiça para a Casa Civil da Presidência da República, ato finalmente consolidado pela medida provisória nº , de 29/6/2000. </p> </bioghist> 79

81 <eacrels> EAC Relations Having covered Identity and Descriptions, we turn now to EAC relations, the third major area with Context Description. <eac> <condesc> <head></head> <identity></identity> <desc></desc> <eacrels></eacrels> <resourcerels></resourcerels> </condesc> Heading for display Identity Description EAC Relationships Resource relations 80

82 <eacrel> EAC Relation <eac> <condesc> <eacrels> <eacrel></eacrel> <eacrel></eacrel> <eacrel></eacrel> Resource relations Individual relation Individual relation Individual relation </eacrels </condesc> EAC Relation describes how a particular corporate body, person or family and relates to the subject of this authority record The nature of that relationship is specified in the RELTYPE attribute that has a fixed list of relationships as follows, though other, local values may be substituted. superior, subordinate: earlier, later: parent, child: associative: identity: any hierarchical relation any temporal relations, such as predecessor, successor a biological or adoptive relation any other relationship, "see also" for linking different EAC instances describing the same entity (used esp. for linking to external systems or when it otherwise is not possible to remove the duplicate) <eac> <condesc> <eacrels> <head>relacionamentos</head> <eacrel type="hierárquica"> <corpname> Brasil. Presidência da República. Casa Civil </corpname> <descnote>subordinado á Casa Civil da Presidência da República <date>2000- </date> </descnote> </eacrel> 81

83 <resourcerels> Resource Relations The last major area of the EAC Context Description is EAC Relation <eacrel>. This area contains Information that directs the reader to other sources of information by or about the entity that is the subject of this authority record. These sources may be published works such a biographies, histories, and biographical directories, web sites and other online resources, inventories to archival materials, and any other useful source of information that collaborates or supplements Information in the authority record, Each related resource entity is described within a separate EAC Relation <eacrel> element. <eac> <condesc> <head></head> <identity></identity> <desc></desc> <eacrels></eacrels> Heading for display Identity Description EAC Relationships <resourcerels></resourcerels Resource relations </condesc> 82

84 <resourcerel> Resource Relation The <resourcerel> element describes a particular relation between the described entity and a resource that provides additional information about the person, family or corporate body. The citation to the related resource must be characterized as either a bibliographic citation <bibunit>, a reference to an archival description <archunit> or a reference to a museum object <musunit>. The RELTYPE attribute value provides a general classification of the nature of the relation. The available values are: origination: the described entity is the creator of the resource or record destruction: the described entity destroyed the resource or record based on an appraisal decision control: referenced resource is controlled in some way 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 Here are three examples of three resource relations that pertain to the National Archives. The first refers to an archival resource, namely the fond of the records of the National Archives. The second two are bibliographic citations. The first of these is to the inventory of the fond of the National Archives, the third is a reference to its web site. 83

85 <eac> <condesc> <resourcarels> <head>relacionando a materiais arquivistícos e outros recursos</head> <resourcerel reltype="origination" countrycode="br" ownercode="an"> <archunit> <unittitle>fundo</unittitle> <unitdate>1838- </unitdate> </ archunit> <descnote>produtor</descnote> </resourcerel> <resourcerel reltype="subject"> <bibunit> <name>arquivo NACIONAL (Brasil).</name> <title>inventário sumário da documentação permanente do fundo Arquivo Nacional </title> <imprint> <place>rio de Janeiro</place> <date>1994</date> </imprint> 102 p. </bibunit> </resourcerel> <resourcerel reltype="subject"> <bibunit> <descnote> <date>2000- </date> </descnote> <descnote>site na web</descnote> <descnote>autor e propietário</descnote> </bibunit> </resourcerel> </resourcerels> This concludes the discussion of the Context Description area that contains the body of the authority record. Now we return to the EAC Header, which actually appears at the beginning of an EAC document. 84

86 <eacheader> EAC Header <eac type="eorporate"> <eacheader> Information about the electronic file. </eadheader> <condesc> The authority description itself </condesc> </eac> <eacheader> contains technical and intellectual information used in the creation, maintenance, and control of the EAC instance. The element is required, and must contain an EAC Identifier <eacid> with a unique identifier for the record and a Maintenance history <mainhist> element providing information on the creation, maintenance, and disposition of the record. The drafting status of the record must be recorded in the STATUS attribute. Here then is an overview of the EAD Header with it five child elements: EAC identification, Maintenance history, Language declaration, Rule declaration, and Source declaration. <eacheader> <eacid></eacid> <mainhist></mainhist> <languagedecl><languagedecl> <ruledecl></ruledecl> <source></source> EAC identification Maintenance history Language Rules Source 85

87 <eacid> EAC Identifier A required sub element of <eacheader> that designates a unique identifier for a particular EAC instance. The assigning owner ensures the uniqueness of the value within the EAC descriptive system under its control. The value of <eacid>, here 00320, will provide a globally unique identifier for the record when used in combination with the values in COUNTRYCODE and OWNERCODE. <eac type="corpname"> <eacheader status="draft"> <eacid countrycode="br" ownercode="an">00320 </eacid> <mainhist> Maintenance History Within the <eacheader>, <mainhist> contains one or more <mainevent>s documenting milestone events or activities in the maintenance of the EAC record. This is a required element, containing at least one <mainevent>. <eacheader status="draft"> <eacid countrycode="br" ownercode="an">00320</eacid> <mainhist> <mainevent maintype="create"> <maindate>9/12/2002</maindate> <name>vitor Manoel Marques da Fonseca</name> </mainevent> <mainevent maintype="update"> <maindate>24/02/2007</maindate> </mainevent> </mainhist> 86

88 <languagedecl> Language Declaration Within <eacheader>, <languagedecl> contains one or more <language> elements that declare the predominant language or languages used in the descriptive content of the record. <eacheader status="draft"> <languagedecl> <language>português</language> </languagedecl> <ruledecl> Rules Declaration Within the <eacheader>, <ruledecl> contains one or more <rule> elements identifying the descriptive content standard or standards used in creating the EAC instance. <eacheader status="draft"> <ruledecl> <rule>international Council on Archives. ISA AR (CPF): International Standard Archival Authority Record for Corporate Bodies, Persons and Families. 2. ed. Canberra, </rule> <rule>associação Brasileira de Normas Técnicas. NBR 6023: Informação e documentação, referências, elaboração. Rio de Janeiro, p. </rule> </ruledecl> 87

89 <sourcedecl> Source Declaration This is a container element for the specification of sources used to create the content of this authority record. These two examples are both to published works about the archives. <eacheader status-"draft"> <sourcedecl> <source> <name>arqulvo NACIONAL (Brasil).</name> <title>arquivo Nacional</title> <imprint> <place>rio de Janeiro</place> <date>2002</date> </imprint> 51 p. </source> <source> <name>castello BRANCO, Pandiá H. de Tautphoeus. </name> <title>subsídios para a história do Arquivo Nacional na comemoração do seu primeiro centenário ( ): o Arquivo no Império. </title> <imprint> <place>rio de Janeiro</place> <publisher>arquivo Nacional</publisher> <date>1937</date> </imprint> 356p. <bibseries>publicaçoes do Arquivo Nacional, 35</bibseries> </source> </sourcedecl> 88

90 Conclusions This presentation began with a discussion of the challenges that archivists face in meeting the expectations of researchers who want online access to Information about records in our archives and who anticipate a future where they will be able also to see the contents of those records online. With national and international descriptive standards in place and with the emergence of the internet, we have two important prerequisites in hand to meet this challenge. As I trust I have demonstrated Io you, Encoded Archival Description and Encoded Archival Context provide us with protocols for managing our data electronically and in a way that are standards based, involve a neutral technical environment with Extensible Markup Language, are web compatible, and that have been created and controlled by archivists. Their basis in XML facilitates further interoperability with data stored in other XML formats like those being employed to manage digital content such as METS. They are flexible in another important way. EAD and EAC may be employed either as the basis for systems that manage data directly in XML databases or XML-enabled relational databases, but also simply as data interchange protocols for transferring information among computer systems in a format that is neutral and completely independent of particular computer systems The most important thing we gain with their use is results: online access to collections with structured display, navigation, and searching of data; standardized data exchange; and computer system independence that minimizes data obsolescence and promotes data migration. The final and probably the most important benefit is their support for the work of archives, particularly the complexities of multi-level description and the maintenance of full authority data. 89