![[VIEW OF LC DOME]](http://lcweb.loc.gov/homepage/lc2.gif)
The Library of Congress
Figure 7.3.1a creates two general external entity declarations in the document type declaration of an encoded finding aid instance:
<!DOCTYPE ead PUBLIC "-//Society of American Archivists//DTD ead.dtd (Encoded Archival Description (EAD) Version 1.0)//EN" [ <!ENTITY tedschell SYSTEM "http://www.archivesrus.gov/findaids/ead/ms045.sgm" NDATA sgml> <!ENTITY schellpix SYSTEM "http://www.myserver.edu /images/ms023_schell.gif" NDATA gif>]> Figure 7.3.1a. Two general entity declarations in a document type declaration.
The first declaration provides as a system identifier an absolute URI on a server at some fictitious government archives for an EAD-encoded finding aid for the Theodore R. Schellenberg Papers. The second declaration provides an absolute URI for a GIF image housed on the same server as the encoded document instance in which the link will be declared.
Section 6.5.2.4.2 provides information about external entity declarations to files not intended to be parsed with the document instance. The present section will discuss using linking elements to create links within a document instance to those files. Establishing links to declared entities is accomplished with an ENTITYREF attribute in the chosen linking element. The value designation in the EAD DTD for the ENTITYREF attribute is ENTITY, a keyword meaning that the attribute value will be validated when the encoded document instance is parsed, ensuring that an entity declaration exists to match each ENTITYREF attribute used. Figure 7.3.1b provides an example of two linking elements containing destination addresses to the entities declared in figure 7.3.1a:
<add> <relatedmaterial> <head>Related Collections</head> <archref entityref="tedschell"> <origination> <persname source="lcnaf" normal="Schellenberg, T. R., 1903-1970" role="creator">T. R. Schellenberg</persname></origination> <unittitle>Theodore R. Schellenberg Papers, <unitdate type="inclusive">1938-1970</unitdate></unittitle> <extptr entityref="schellpix"> <unitid type="collection number">MS-045</unitid> <repository><name>Archives R Us</name></repository> </archref> [other possible elements and text ...] </relatedmaterial> </add> Figure 7.3.1b. Using the ENTITYREF attribute to establish links.
In this example, the Archival Reference <archref> element with an ENTITYREF attribute is used to supply a link to an encoded finding aid for a related collection. The External Pointer <extptr> element with an ENTITYREF attribute is used to supply a link to a picture relevant to the archival collection. The <archref> element is discussed in greater detail in section 7.3.3, and the <extptr> element is explained in section 7.3.4.
Since the development of the SGML standard, the World Wide Web and the HTML encoding scheme that serves as its markup foundation have taken the world of networked communications by storm. The advantages and disadvantages of both HTML and SGML are discussed in chapter 1, so suffice it to say here that the Web introduced some simplifications of SGML that ongoing XML developments aim to incorporate. One of these simplifications is to add to the SGML entity-based linking scheme the capability of using the direct address-referencing capacity of the HREF attribute. Version 1.0 of the EAD DTD fully supports this development.
Use of the HREF attribute is relatively simple; it involves only the single step of providing a URI for the destination resource directly within the linking element itself. Figure 7.3.2a illustrates a reencoding of the ENTITYREF example in figure 7.3.1b above, using instead the HREF attribute; this eliminates the need for the entity declarations shown in figure 7.3.1a. Note that the encoder retains the choice of using an absolute URI or a relative URI to provide the destination address (see section 6.5.2.4.1 regarding the strengths and weaknesses of these options).
<add> <relatedmaterial> <head>Related Collections</head> <archref href="http://www.archivesrus.gov/findaids/ead/ms045.sgm"> <origination> <persname source="lcnaf" normal="Schellenberg, T. R., 1903-1970" role="creator"> T. R. Schellenberg</persname></origination> <unittitle>Theodore R. Schellenberg Papers, <unitdate type="inclusive">1938-1970</unitdate></unittitle> <extptr href="../images/ms023_schell.gif"> <unitid type="collection number">MS-045</unitid> <repository><name>Archives R Us</name></repository> </archref> [other possible elements and text ...] </relatedmaterial> </add> Figure 7.3.2a. Using the HREF attribute to establish links.
Some of the advantages and disadvantages of choosing to use a linking scheme based on entities or on the HREF attribute will be discussed in section 7.5. Perhaps the most important factor in making a decision about which linking attribute to use in order to provide a destination address for a link is a basic knowledge of how linking is supported in the particular system in which you will deliver your finding aids. Use of the HREF attribute does not allow for provision of the same amount of information concerning the destination resource of the link as does the entity-based scheme. Note, for example, that the entity declaration for the GIF image in figure 7.3.1a provides specific information to the delivery system software about the non-SGML data resource to which a link is being established. Provision of this specific information is not possible using the HREF attribute, so the delivery system will have to attempt to make this determination based on the file type suffix appended to the filename (.gif).
This section also provides a discussion of an alternative use for <archref>, which has proven useful to some repositories for virtually reuniting large collection descriptions that, for practical purposes, have been broken into smaller components for encoding.
The element <bibref> can be used in a similar manner for creating links either to surrogate descriptions or to the actual text of published materials available online. For example, an encoded finding aid for the papers of the author Paul Laurence Dunbar might include a bibliography of Dunbar's published works. The full text of some of Dunbar's poetry is available online (encoded in SGML using the TEI DTD) through the American Verse Collection of the University of Michigan's Humanities Text Initiative.(115) Figure 7.3.3a illustrates the encoding of bibliographic references to Dunbar's works, the first citation with no link and the second with a link directly to the full online text:
<add> <bibliography> <head>A Bibliography of the Works of Paul Laurence Dunbar</head> [other possible elements and text ...] <bibref> <persname role="author" source="lcsh">Dunbar, Paul Laurence, 1872-1906</persname>. <title pubstatus="pub">The Best Stories of Paul Laurence Dunbar</title>. <imprint><geogname>New York</geogname> : <publisher> Dodd, Mead & Company</publisher>, <date type="publication"> [1938]</date> </imprint> </bibref> [other possible elements and text ...] <bibref href="http://www.hti.umich.edu/bin/amv- idx.pl?type=header&id=DunbaLyrLL"> <persname role="author" source="lcsh">Dunbar, Paul Laurence, 1872-1906</persname>. <title pubstatus="pub">Lyrics of Lowly Life</title>. <imprint><geogname>London</geogname> : <publisher> Chapman & Hall, Ltd.</publisher>, <date type="publication"> 1897</date></imprint> </bibref> [other possible elements and text ...] </bibliography> </add> Figure 7.3.3a. A use of both the nonlinking and linking capabilities of <bibref>.
Note that while the HREF attribute was used in this example, the encoder could just as easily have created an entity declaration containing the URI to the resource and then used the ENTITYREF attribute on <bibref>.
The Public Record Office (PRO)-which as the national archives of the United Kingdom holds the records of British government departments, courts of law, and other public records as defined by the Public Records Act of 1958 and its schedules-has this problem with many of its finding aids. Each fonds equates to the entire range of surviving records of a department, made up of perhaps 10 or 20 record-creating divisions, each potentially producing dozens of record series (or in PRO parlance, classes) comprising from one to many thousands of documents that are available to end users. The sheer bulk of each fonds (originally envisaged as a discrete EAD instance) immediately posed difficulties for archivists at the PRO: first, in the parsing of files over 2.5 megabytes in size using some of the software commonly available; and secondly and more fundamentally, in the time required by end users to download files on the Internet.
A decision was made to split the files and to link them using <archref>. A parent file would hold the fonds and subfonds (in PRO parlance, departments and divisions) data; individual files would act as finding aids for each series (in PRO parlance, class) and its components. The <archref> tag is used to virtually unite the fonds and subfonds file with all of the series files that are its intellectual subunits and to link the series files back to the parent.
Figure 7.3.4a illustrates an entity declaration for information at the Nobel Foundation Web site on the 1995 prize in Physics given to Frederick Reines, whose papers are described elsewhere in an EAD instance:
<!DOCTYPE ead PUBLIC "-//Society of American Archivists//DTD ead.dtd (Encoded Archival Description (EAD) Version 1.0)//EN" [ <!ENTITY nobelreines SYSTEM "http://www.nobel.se/laureates/physics- 1995.html" NDATA html> ]> Figure 7.3.4a. An entity declaration for an external web site.
Within the text of the EAD instance, perhaps in a chronologically arranged Biographical Note, <extptr> and the ENTITYREF attribute are used to create a link to Reines' entry at the Nobel Foundation Web site, as illustrated in figure 7.3.4b:
<bioghist> <head>Biographical Note</head> <chronlist> [other possible elements and text ...] <chronitem> <date>October 1995</date> <event><extptr entityref="nobelreines">Awarded Nobel Prize in Physics by the Royal Swedish Academy of Sciences</event> </chronitem> [other possible elements and text ...] </chronlist> </bioghist> Figure 7.3.4b. Using <extptr> to link to a declared external entity.
Alternatively, the link in figure 7.3.4b could have been declared using <extref>, which must contain text or other elements, as shown in the reencoded example below. Although system-dependent, the most likely implementation of this encoding would involve the highlighting of the text included in the <extref> element to indicate the presence of a link.
<chronitem> <date>October 1995</date> <event><extref entityref="nobelreines">Awarded Nobel Prize in Physics by the Royal Swedish Academy of Sciences</extref></event> </chronitem>
Finally, the above link could have been established by using the HREF attribute, either by itself or paired with an entity declaration, to directly encode the URI for the Nobel Foundation Web site information on Reines:
<chronitem> <date>October 1995</date> <event><extref href="http://www.nobel.se/laureates/ physics-1995.html">Awarded Nobel Prize in Physics by the Royal Swedish Academy of Sciences</extref></event> </chronitem>
Like <extptr> and <extref>, <extptrloc> and <extrefloc> serve exactly the same function. The difference between them is the encoder's desire to include text as the link indicator (in this case use <extrefloc>) or not to include text (in this case use <extptrloc>).
Three of the four elements mentioned above are linking elements. The <daodesc> element, the one exception, is available for use when "the <unittitle> or other descriptive information in a Component <c>" is insufficient to identify the digital object(s); <daodesc> essentially provides for a caption for digital archival objects when one is necessary.(117)
It is important to grasp the distinction between the <dao> suite of elements and other external linking elements that EAD makes available. The <dao> suite is intended for use only where the destination of the link is something that, based on its provenance and custodial history, is part of the collection being described by the encoded finding aid in which the <dao> tags are included. Links to all other materials should be created using the other external linking elements (such as <extref> or <extptr>) discussed in section 7.3.
The element <dao> is available to create a simple link to a digital representation of any material included in an archival collection. The <daogrp> element, which must be used to bundle multiple <daoloc> elements, is available to create an extended link to multiple versions of digital facsimiles of collection materials (see section 7.1 for an overview of these linking concepts).
While it may often appear to be empty, <dao> itself is not declared in the EAD DTD as an empty element. The content model for this element states that it may contain either zero or one <daodesc> elements. Therefore, while it may appear frequently with no content, it is not technically an empty element in the same way as <ptr>, which is declared in the DTD with the content model EMPTY. As a result it must always appear with both a start-tag and an end-tag, regardless of whether or not it contains a <daodesc>. This is also true of <daoloc>.
An archivist might choose to create links to digital facsimiles for two photographs from the same folder within a collection. Figure 7.3.6a illustrates an entity declaration for each of these two JPEG images:
<!DOCTYPE ead PUBLIC "-//Society of American Archivists//DTD ead.dtd (Encoded Archival Description (EAD) Version 1.0)//EN" [ <!ENTITY f0042_1 SYSTEM "http://www.myserver.edu/images/ fonds0042_image1.jpg" NDATA jpeg> <!ENTITY f0042_2 SYSTEM "http://www.myserver.edu /images/ fonds0042_image2.jpg" NDATA jpeg> ]> Figure 7.3.6a. Entity declarations for two JPEG images.
Even though the rest of the collection is described only to the folder level, the archivist chooses to encode the folder containing the two original photographs at the item level and to establish links to the digital facsimiles using a <dao> tag for each item, as illustrated in figure 7.3.6b:
<dsc type="combined"> [other possible elements and text ...] <c02 level="file"><did><unittitle>Photographs, <unitdate type="inclusive">1895-1928</unitdate></unittitle> </did> <c03 level="item"><did><unittitle>John Smith graduation portrait, <unitdate type="single" normal="18950528">May 28, 1895</unitdate></unittitle> <dao entityref="f0042_1"></dao></did></c03> <c03 level="item"><did><unittitle>Wedding of John Smith and Stella Jones, Windsor, Ontario, <unitdate type="single" normal="18970606">June 6, 1897</unitdate></unittitle> <dao entityref="f0042_2"></dao></did></c03> </c02> [other possible elements and text ...] </dsc> Figure 7.3.6b. Using <dao> to establish links to digital image facsimiles.
The <daogrp> element is used instead of <dao> when it is necessary to bundle together different versions of the same resource. For example, suppose the image links established in figure 7.3.6b included both a thumbnail and a larger reference image for each link. In order to unambiguously encode the relationship between the pair of files for each image, it would be necessary to use <daogrp> to bundle a <daoloc> pointer for each related file, as in the following reencoding:
<dsc type="combined"> [other possible elements and text ...] <c02 level="file"><did><unittitle>Photographs, <unitdate type="inclusive">1895-1928</unitdate></unittitle> </did> <c03 level="item"><did><unittitle>John Smith graduation portrait, <unitdate type="single" normal="18950528">May 28, 1895 </unitdate></unittitle> <daogrp> <daoloc entityref="f0042_1thumb"></daoloc> <daoloc entityref="f0042_1"></daoloc> </daogrp> </did></c03> <c03 level="item"><did><unittitle>Wedding of John Smith and Stella Jones, Windsor, Ontario, <unitdate type="single" normal="18970606">June 6, 1897</unitdate></unittitle> <daogrp> <daoloc entityref="f0042_2thumb"></daoloc> <daoloc entityref="f0042_2"></daoloc> </daogrp> </did></c03> </c02> [other possible elements and text ...] </dsc> Figure 7.3.6c. Using <daogrp> to establish links to related versions of digital image facsimiles.
Within EAD, XPOINTER is an attribute available on all "simple" and "locator" linking elements, as categorized in table 7.2.4a. The inclusion of this attribute is one of the forward-looking aspects of EAD that anticipates the stabilization of XML's XLink and XPointer specifications in the not-too-distant future. In SGML systems that are capable of implementing it, use of the XPOINTER attribute allows an encoder to create-using XPointer syntax to create the value of that attribute-a pathway for a link to a specific point within an external encoded document. An SGML-aware delivery system should be capable of resolving the content of an ENTITYREF destination address and the content of an XPOINTER attribute from a single EAD linking element in order to create, on the fly, an XML-compliant HREF link to the specific point within the document that the encoder intended as the destination for the link. This will give implementers of EAD the ability to take advantage of some of the link management strengths of the entity-based approach in SGML (discussed in section 7.5), while still being able to utilize XPointer capabilities when they are more fully developed and stable.
Use of the remaining attributes discussed herein is recommended only when the type of link being created or the software used to deliver the encoded document requires it. All of the attributes discussed in this section can be used for either internal or external links.
ACTUATE refers to the way in which traversal of a link will be initiated. The value "auto" indicates that the link should be automatically traversed by the system when an end user reaches it, displaying, for example, an image on the screen in an online finding aid without the user having to select or activate any link. This might be useful when linking externally to an image that the encoder intends to display as an illustration in a Biography or History <bioghist> note. The value "user" indicates that the end user must initiate in some way, perhaps with a mouse click or a voice command, the traversal of the link. This might be useful, for example, when the link destination is an internal "see also" reference or an external finding aid for a related collection, which an end user may wish either to explore or to ignore.
SHOW indicates the intended behavior of the link once it has been traversed. It has three possible values. The value "embed" indicates that the destination resource of the link should be embedded in the encoded document in place of the linking element and would generally be used in tandem with the ACTUATE attribute value "auto". The value "replace" indicates that the link's destination resource should replace the text surrounding the link's source resource in the same browser window, while the value "new" indicates that a new browser window should be opened for displaying the destination resource of the link. Either of these values for SHOW generally would be used with the ACTUATE value "user".
In certain cases the constrained values of the attributes ACTUATE and SHOW may not provide enough guidance for particular system software. When this occurs, the attribute BEHAVIOR, whose value is completely unconstrained, may be used to provide whatever instructions the system software needs concerning the desired behavior of the link.
Figure 7.4.1a illustrates the use of the attributes ACTUATE and SHOW in an internal link that alerts the user that other materials on a particular organization exist elsewhere in the collection. Because the <ref> element is used, the text contained between the start-tag and end-tag will probably, depending on the system, be highlighted in some way when this document appears on a display monitor. The end user must initiate traversal of the link by selecting the highlighted link text. The text in the targeted area of the finding aid will replace the text surrounding the link's source in the browser window. Note that an ID attribute value has been assigned at the appropriate component level so that a cross-reference link also can be established in the encoding of Series 4 in this collection.
<c01 level="series"> <did><unitid>Series 1: </unitid> <unittitle>Correspondence, <unitdate type="inclusive"> 1946-1970</unitdate></unittitle> <physdesc><extent>4.4 linear feet</extent> </physdesc></did> <c02 level="file" id="s1:agba"> <did><unittitle>Apple Growers Benevolent Association, <unitdate type="inclusive">1950-1952</unitdate></unittitle> <physdesc><extent>12 items</extent></physdesc> </did> <note><p>See also <ref target="s4:agba" actuate="user" show="replace">AGBA materials</ref> in Series 4: Topical Files</p></note> </c02> [other possible elements and text ...] </c01> Figure 7.4.1a. Using the ACTUATE and SHOW attributes to specify link properties.
In figure 7.4.1b a link is made to an image of the creator of a collection of personal papers that is being used to illustrate the biographical note in the collection-level description. The link is encoded in such a way that the traversal of the link will happen automatically; the picture will always appear when an end user reads the biographical note.
<bioghist> <dao href="http://www.myserver.edu/images/ms452_port1.gif" actuate="auto" show="embed"></dao> <p>Sanford J. Archiviste, depicted above in a 1945 portrait photograph from his papers, was a significant intellectual force in the North American archival world during the mid-twentieth century. [...]</p> [other possible elements and text ...] </bioghist> Figure 7.4.1b. Using the ACTUATE and SHOW attributes with <dao> to specify link properties.
Note that <dao> was chosen to establish the link because the digital facsimile that is its destination is of an item from the materials being described. If there were no photographs in the collection and the archivist had found an image from some other source for inclusion in the encoded finding aid, the use of <dao> would not have been appropriate. In such a case either <extptr> or <extref> would be the correct tag to use in establishing such a link, depending on whether or not the inclusion of text within the linking element is desired. Figure 7.4.1c is a reencoding of figure 7.4.1b using <extptr> as the linking element:
<bioghist> <p><extptr href="http://www.archivists.org/famousFolk/ sanford.jpg" actuate="auto" show="embed"></p> <p>Sanford J. Archiviste, depicted above in a 1945 portrait photograph available digitally at the Society of American Archivists' Web site, was a significant intellectual force in the North American archival world during the mid-twentieth Century. [...]</p> [other possible elements and text ...] </bioghist> Figure 7.4.1c. Using the ACTUATE and SHOW attributes with <extptr> to specify link properties.
In such cases the attributes ROLE and TITLE are used in the locator elements to encode information about the role that each remote resource plays in the link. The values of these attributes are unconstrained by the DTD, so encoders must be certain that the values supplied will be meaningful in the context of the intended audience. For ROLE, the audience is the application software and for TITLE it is the end user. It is important to understand that you will need to know something about the requirements of the system in which you will deliver your encoded finding aids before utilizing these attributes in your encoding. Most commercially available systems do not yet support the use of these attributes. The following discussion is intended to provide EAD implementers with a basic understanding of the purpose of each attribute so that they can be used properly in the future when systems do readily support their use.
The ROLE attribute is intended to provide clarification regarding the role of a remote resource to application software that will be processing an EAD instance. Perhaps a stylesheet has been created in a particular delivery system that assigns behavior to image links based on whether they are identified as "thumbnail" or "reference" copies of those images. The encoding for all image links (simple and extended) in files using that stylesheet may be required by the delivery system to specify which of these roles an image will play. Figure 7.4.2a illustrates the encoding of an image sampler that includes both a thumbnail file and a larger reference file for each image. The <daogrp> tag is used to bundle the group of files for each image. The ROLE attribute on each <daoloc> locator tag is used to specify for processing software the relationship between the files within each <daogrp>. Since <daogrp> is not recursive (cannot be nested within itself), the Other Descriptive Data <odd> element is used to bundle the multiple <daogrp> tags that comprise the image sampler. Of course, entity declarations for all of the images would have to be added to the prolog of the EAD instance (see section 6.5) in order to make the encoding in this example valid.
<odd> <head>Image Sampler</head> <p>The following photographs are illustrative of the types of images available in this collection.</p> <daogrp> <daoloc entityref="s1_img1-th" role="thumbnail" actuate="auto" show="embed"> <daodesc><p>Oldest extant photograph of the Lassen County (Calif.) Courthouse, taken in 1897. <ref target="s1:LCCph">Link to the location of this image within the collection description</ref></p></daodesc></daoloc> <daoloc entityref="s1_img1" role="reference" actuate="user" show="new"></daoloc></daogrp> <daogrp> <daoloc entityref="s3_img1-th" role="thumbnail" actuate="auto" show="embed"> <daodesc><p>Placer mine operations along the Feather River, Plumas County (Calif.), ca. 1870. <ref target="s3:MINEph">Link to the location of this image within the collection description</ref></p></daodesc></daoloc> <daoloc entityref="s3_img1" role="reference" actuate="user" show="new"> </daoloc> </daogrp> [other possible elements and text ...] </odd> Figure 7.4.2a. Use of the ROLE attribute to specify linking roles.
The TITLE attribute is intended to provide information to end users regarding the role of the remote resource. In many cases, as in the encoding in figure 7.4.2a, this additional information will not be needed, because plenty of clues already exist in the contextual information surrounding the link. Also, as the use of thumbnails to serve as the source resource for links to larger reference images has become more prevalent on the World Wide Web, many end users understand and expect this behavior, so additional information would be superfluous. If an encoder decides, however, that additional information regarding the role of a remote resource in a link is needed, the TITLE attribute is available for that purpose. How the information encoded as the value of this attribute displays to end users is something that would most likely be determined by the particular application software being used to deliver the encoded finding aid.
The final two attributes discussed in this section, CONTENT-ROLE and CONTENT-TITLE, are intended for use only with extended links. They provide additional information about the role of the local resource in the extended link. As with the attribute ROLE, CONTENT-ROLE is intended to provide information to application software, while CONTENT-TITLE, like TITLE, provides additional information to end users. In all inline links, which the vast majority of EAD implementers will be using for the time being, the role of the local resource as the source of the link is made clear by the establishment of the link itself. This will not be the case in the future when out-of-line links, in which the local resource may not participate as either a source or a destination, may be possible. Goldfarb and Prescod even relate a scenario in which the values of attributes like CONTENT-TITLE and TITLE may be used by sophisticated application software to present end users with popup menus giving them the choice of selecting from among a variety of sources and destinations for out-of-line links.(122)
The Library of Congress