The ead cookbook- 2002 Edition icon

The ead cookbook- 2002 Edition

страницы:   1   2   3   4   5   6   7   8

THE EAD COOKBOOK- 2002 Edition

The first edition of the EAD Cookbook appeared in 2000 in response to a desire within the profession for practical, step-by-step assistance with the implementation of EAD. It contained a simple model encoding protocol with an accompanying suite of software tools for “authoring” electronic finding aids and stylesheets for “publishing” them on the Web. It functioned as an extension of the EAD Tag Library and the EAD Application Guidelines.

The appearance of EAD Version 2002, the shift of the EAD community from SGML to an XML environment, the appearance of new tools for creating and distributing finding aids, and the emergence of community-based encoding protocols necessitate a revision of that earlier work. While the basic EAD recipe has not changed, some of the ingredients have. As an update, this edition focuses on those aspects of implementation that have changed since 2003, specifically changes in the EAD element set, new tools for creating EAD-encoded documents, and the need to provide additional XSLT stylesheets for transforming EAD files into HTML.

The encoding protocol in the first edition was a compilation of guidelines from several sources. In this version, it is based on the "RLG Best Practice Guidelines for Encoded Archival Description," though no significant differences have resulted from that change. Regularized encoding is important for very practical reasons. The consistent use of the EAD element set makes it possible to exchange and consolidate multiple finding aids from many institutions into union databases or simply with others in one's own repository. Without standardized encoding, it is difficult to manage indexing, display, and manipulation of files. Consistency of presentation also improves user understanding of the purpose and scope of inventories just as the standardized display of library catalogs makes them comprehensible to a large and diverse audience. As testimony to the necessity and wisdom of such regularization, every EAD consortium has adopted some form of encoding protocols.

This edition provides assistance in using three applications for creating encoded finding aids- XMetaL, , and Note Tab. This includes instructions for installing and modifying the applications, and auxiliary files such as templates that make them easier to use.

New stylesheets have been created that accommodate the changes in EAD 2002, offer greater flexibility and more choices for local display, and a simpler and more fully documented syntax to facilitate local modifications.

Bon appetit!

Michael J. Fox

July 2003

^ Section 1: The Recipe

Step 1. Learn about EAD.

Three volumes published by SAA make a good start: Encoded Archival Description: Context, Theory and Case Studies, the EAD Application Guidelines, and the EAD Tag Library. The EAD Help pages maintained by the SAA EAD Roundtable contain much practical and useful information, including descriptions of many implementation projects and lists of available training opportunities. They are available at:

Step 2. Determine how you will deliver your finding aids over the web.

How will researchers find these documents? Many options are available. You can do any or all of the following:

  1. Create links to the finding aids from other web pages.

  2. Create links to finding aids from entries in your online catalog.

  3. Index your finding aids on your local web site. Many sites now have software that performs at least keyword searches of documents located there. EAD-encoded documents transformed into HTML may be indexed and accessed along with other files.

  4. Contribute to a consortium that hosts a central file of finding aids. Such data servers typically feature sophisticated software that provides structured and keyword searching of the full text of finding aids. A growing number of state and regional projects are creating such services. The RLG's Archival Resources service hosts finding aids from repositories in several countries and is not limited to its member institutions.

  5. Buy your own data server and software. Choices range from freeware to commercial full-text search software.

  6. Start you own cooperative project.

The tools for creating EAD documents that accompany the Cookbook are applicable to all of these options.

The Cookbook provides explicit directions in Sections 5 through 7 for implementing publishing options a and b above.

Step 3. Review the general principles and specific details of the Encoding Protocol.

These are found in sections 2 and 3. Some encoding choices are specified in the encoding protocol and built into that accompanying templates. You will need to ratify those decisions and; in other cases, decide what your local practice will be. For example, what text do you wish to appear in specific elements? These sections will help you identify your options and make those decisions. The sources cited above and the EAD Tag Library will provide additional information.

^ Step 4. Acquire a software application for authoring finding aids.

Products currently available include XMetaL, XML Spy, Oxygen, Note Tab, WordPerfect 2000, and others. Consult your favorite web search engine for current addresses and additional information about each of these products.

Step 5. Install and configure the software. (Section 4)

Step 6. Create EAD-encoded finding aids. (Sections 3 and 4)

Step 7. Adopt or modify an existing XSLT stylesheet or create your own.

(Section 5)

Step 8. Transform your EAD files into HTML or print. (Section 6)

Step 9. Deliver your finding aids to your users. (Section 7)

Section 2: The EAD Cookbook Design Principles

EAD offers great flexibility in how one might encode a finding aid. The options chosen may have a significant impact on the subsequent usability of the file. The particular markup choices suggested in the ^ EAD Cookbook are designed to facilitate the transport of data between systems, the sharing of data through union catalogs, the reuse of data for different purposes, hyper-navigation within inventories, and the presentation of data in different environments, currently through the web and as print output. The following principles serve as the basis for the model encoding protocol.

  1. EAD encoding is not a substitute for sound archival description. Before marking up a single document, consider what information you wish to record. Descriptive conventions like Archives, Personal Papers, and Manuscripts (APPM), the Rules for Archival Description (RAD), and the General International Standard for Archival Description (ISAD(G)) all have very useful things to say about what information ought to be included in a good archival description and how to structure that data. Finding aids are not different fundamentally from the other tools we create to help our users in identify and locate relevant materials in our collections. Consider using indexing terms drawn from standardized vocabularies in controlled elements to improve retrieval across metadata systems.

  1. The description embodied in an EAD-encoded finding aid conveys the multilevel or hierarchical nature of the materials themselves. This approach reflects the fundamental and intrinsic characteristics of archival materials and their interrelationships, and the function of the finding aid as a surrogate for the originals and a tool for resource discovery and interpretation.

  1. Description proceeds from the general to the specific, in reflection of the hierarchy just described, as a practical and flexible solution to the problem of creating intellectual and physical control over large bodies of materials, and as an aid to resource discovery by researchers.

  1. While markup may use either “classic SGML” or XML syntax, virtually all current applications employ XML. This edition of the Cookbook focuses exclusively on XML implementations. If you have older SGML files, please consult the first edition.

  1. The model assumes that the materials described in the finding aid form a collection of personal papers or organizational records. The accompanying stylesheets provide formatting for collections that are either complex with multiple series and perhaps sub-series or have a simpler structure consisting of multiple files in a single series. The encoding further assumes that the collection is fully processed and described.

6. No method for managing large numbers of images or other associated non-textual files is prescribed. Repositories using finding aids to link to many external files will need to review the options outlined in Section 4.4.3 of the EAD Application Guidelines. The simple inclusion of an institutional logo can be handled through a single Extended Pointer element or by a stylesheet, as is the case with those that accompany the Cookbook (see Section 5.5).

7. There is a growing consensus within the archival community that there is a set of core data elements that ought to be included at a minimum in every finding aid to help users determine the applicability of a collection to their research needs and to identify specific materials for retrieval and inspection. Appendix A of the EAD Application Guidelines specifies four elements that should be included in every finding aid: the top level Descriptive Identification, Biography or History, Scope and Contents, and Controlled Access. Information regarding user restrictions should be included as appropriate. The specific sub-elements within these groups are described in Section 3. Further, there are certain elements necessary for the identification of the electronic file that carries the encoded finding aid. Some of these are required by the EAD DTD, particularly in the EAD Header element. The "RLG Best Practice Guidelines" goes farther and specifies a larger set of elements as mandatory or recommended.

8. The protocol detailed in Section 3 prescribes the explicit inclusion of certain data elements to facilitate transport, display in external systems, internal hyper-navigation, data reuse such as in converting EAD content into MARC records, and the future migration of data to new systems. One cannot assume that local protocols for display, such as may be specified by a local stylesheet, will always travel with the document or be applied to its presentation in other systems and contexts. The protocol in Section 3 is more prescriptive than the RLG guidelines in one respect. It requires the inclusion of user-friendly displays using the Head element for specific individual elements, because, among other reasons, the text of these Head elements is needed to populate the entries in the table of contents produced by the accompanying stylesheets. It also includes recommended text for display labels used with elements and samples of explanatory text that might be added to a finding aid elsewhere to assist remote users who might not readily understand the purpose of elements such as Controlled Access terms. To minimize subsequent display problems, avoid the use of phrases written entirely in upper case.

9. When encoding inventories, other conventions also apply. Observe the recommendations regarding whitespace and internal punctuation found in sections and of the EAD Application Guidelines and Section 3.3.22 of the Cookbook. Internal links are specifically encoded with a Reference element.

10. Additional markup such as the encoding of personal names and subjects beyond the prescribed structural elements may be cost-justifiable only if it supports enhanced comprehension or retrieval through indexing or display. The protocol markup scheme does not provide any special support, such as keyboard macros for data entry or distinctive styling for display through the stylesheets, for nominal content markup such as
within elements for narrative text such as paragraphs. However, this certainly does not preclude in any way their inclusion. This topic is discussed in several of the EAD case studies that appeared in ^ Encoded Archival Description: Context, Theory and Case Studies.

11. Markup follows the “combined” model for the Description of Subordinate Components. The resulting information may be presented either in the sequence in which it is encoded or divided for presentation into separate “analytic overview” and “in-depth” views of the contents of the inventory by a stylesheet. The use of stylesheets to produce either of these outputs from a single set of data eliminates the need for duplicate entry of information common to the two views.

12. No conceptual significance is implied by the sequence in which elements appear in the encoding specifications or the templates except insofar as the EAD DTD enforces a given order. With the use of the stylesheets written in the XSL Transformation (XSLT) language that accompany the Cookbook, the arrangement of information upon output to the web is largely independent of the order of data in the source document. While the protocol makes few assumptions about input sequence, the stylesheets do enforce a predefined order at publication. However, publication techniques other than XSL stylesheets often are not so flexible and one may have little or no ability to reorder elements. In those scenarios, the order of data input may be directly and absolutely related to the order in which data is published.

Download 197.18 Kb.
leave a comment
Date conversion29.09.2011
Size197.18 Kb.
TypeДокументы, Educational materials
Add document to your blog or website

страницы:   1   2   3   4   5   6   7   8
Be the first user to rate this..
Your rate:
Place this button on your site:

The database is protected by copyright ©exdat 2000-2017
При копировании материала укажите ссылку
send message