Designated elements within encoded documents or entire documents themselves can serve as resources in a link, either as sources or as destinations. When you establish a link by placing a linking element in an encoded finding aid, that element generally serves as the source resource for the link. Each linking element has a group of linking attributes that provide further information regarding the link. Some of these attributes provide addresses for the destination resource for the link, while others provide information about how the link is intended to behave when the document instance is output to some display mechanism. The functionality of various linking attributes will be discussed below in the context of the various EAD linking elements with which they can be used.
It is important to stress that software must interpret the values of linking attributes and stylesheet instructions to actually effect these linking capabilities. Version 1.0 of EAD was designed specifically to support linking as defined in the XLink and XPointer specifications currently in draft format. (108) However, there currently are no commercially available software packages that implement certain linking attributes available in EAD. The discussion in this chapter relates to the broad functionality of the various linking elements and attributes in EAD, and not to the specifics of how a particular delivery system will translate or implement these encoded links. The chapter does provide some recommendations regarding attributes that archivists should consider using at a minimum when establishing links in EAD-encoded finding aids.
Thirteen manage links directly, while two (<daogrp> and <linkgrp>) are wrapper elements that consolidate multiple, related links. These 15 elements have several significant characteristics.
Conceptually, a link has four facets, each of which has only two or three possible values. Different linking elements possess different combinations of these facet values. In any given situation, the encoder of a finding aid will select the proper linking element based on these characteristics and on other considerations that will be described later in this chapter. These are the significant characteristics of links:
| Destination location | Internal or External | (See section 7.1.2.1) |
| Extent | Simple, Locator or Extended | (See section 7.1.2.2) |
| Source location | Inline or Out-of-line | (See section 7.1.2.3) |
| Contents | Empty or With text | (See section 7.1.2.4) |
Attributes play a very important part in linking elements. TARGET, HREF and ENTITYREF are used to provide destination addresses for links. ACTUATE, SHOW and BEHAVIOR work together to govern the way in which processing software presents links to end users. ROLE, TITLE, CONTENT-ROLE, CONTENT-TITLE and other attributes specific to EAD's linking elements provide additional specificity regarding the nature of links or the resources that participate in them.
An encoder can create a link to and from a destination by establishing two single-direction links that can be traversed in opposite directions, as illustrated in figure 7.1.2.2b.
The direction of link traversal in both figures is indicated by arrows. Some software may support the ability to traverse a link from source to destination and back to source without encoding two single-direction links for this purpose.
The focus of this linking discussion will be on simple links, since they are universally supported by SGML-aware software applications. Most of the links that an encoder creates in an EAD instance will be simple links. Simple links have these features:
All other types of links are considered extended links. The concept of extended links is currently being clarified and expanded in work on XLink, the linking component of XML, and will be discussed only briefly. EAD has one main category of linking elements that are always extended, the bundling linking elements <linkgrp> and <daogrp>, which will be discussed in greater detail in section 7.3.5 and section 7.3.6. They are considered extended links because they do not themselves contain a destination resource for the established link, but rather bundle multiple locator elements (<extrefloc>, <daoloc>) containing addresses for the link's multiple destinations. The attribute XLINK:FORM, which supplies the designation of each linking element as simple, extended or locator, is discussed in section 7.2.4.
| Simple Links Simple links are inline. |
Extended Links Extended links can either be inline or out-of- | ||
| Internal links | With text | <ref> | <refloc> |
| Empty | <ptr> | <ptrloc> | |
| External links | With text | <archref>, <bibref>, <dao>(111) , <extref>, <title> | <daoloc>, <extrefloc> |
| Empty | <extptr> | <extptrloc> | |
| Table 7.1.3a. EAD linking elements categorized by significant characteristics. Since currently available software does not generally support the use of extended links, EAD implementers should consult with their systems expert prior to employing the linking elements shown in the shaded area. | |||
As mentioned above, the use of any one of these elements(112) signals the establishment of a link between the information being encoded and information available somewhere else. That somewhere else may be within the same finding aid, on the same server, or on some other server available via the Internet.
The following discussion of various linking options will proceed from the simple to the complex. Additionally, it will first describe linking options that any SGML or XML system should be able to support and will then move to an abbreviated discussion of the more complex options that eventually will take advantage of the currently incomplete and unimplemented XLink and XPointer specifications in XML. It bears emphasis here that Version 1.0 of the EAD DTD was designed to support fully XML-compliant encoding when that specification is completely developed and when software is readily available to support its implementation. The degree to which a particular repository will want to take full advantage of many of the more complex linking capabilities in EAD is a decision that will need to be taken in consultation with persons possessing expertise in whatever local delivery system that repository chooses to use for its encoded finding aids. In the current environment, archivists are limited to the simpler linking options discussed below.
It should be noted that for the sake of clarity examples in section 7.2, section 7.3, and section 7.4 will only include the linking element attributes being discussed in each particular subsection. Section 7.6, the final section in this chapter, will include several examples of the use of optimally encoded linking elements.
The ID attribute plays a critical role in internal links. The TARGET attribute on the linking element used to establish a source for an internal link contains the value of the ID attribute for the destination element. Virtually all EAD elements have an ID attribute and therefore may be the target of an internal link. As noted in the general discussion of attributes in section 6.4, the ID attribute has a value designation of "ID", which requires that its value be unique within a particular encoded document instance. Any element containing text that an encoder wishes to make the target of an internal link must be given a unique value using the ID attribute within that element. Once a unique value is assigned, this encoded information can serve as a link target.
To create an internal link, you must do the following:
In figure 7.2.1a, the text of an access restriction note has been encoded at the collection level, and a unique ID value has been established for that note. In both figures below, some elements have been omitted in order to focus on the link-related points being made.
In figure 7.2.1b, a linking element has been used to establish a relationship between access restriction information within the series-level description and the collection-level note illustrated in figure 7.2.1a. This encoding eliminates the need for repetition at various levels of description of the access restriction information.
In order to alert the end user about the availability of a link, the use of the empty element <ptr> might result in the insertion of a link indicator icon in place of <ptr> when this encoded document is displayed. How such an icon is displayed will be determined by the system or display application (a client browser, a stylesheet, or an SGML server).
Alternatively, the link in figure 7.2.1b could have been declared using <ref>, which must contain text or other elements, as shown in the following example with a reencoded excerpt from figure 7.2.1b. The display to an end user would most likely involve highlighting the text contained within the <ref> element to indicate the presence of the link, in the manner of an HTML browser.
<arrangement><p>The bulk of the contents of the series arrived at the repository in chronological order and this arrangement has been retained. <ref target="restrict1">The single exception is a file of student recommendations on which access restrictions have been imposed.</ref> These folders have been temporarily removed to a restricted box in the collection.</p></arrangement>
<c02 level="file"><did> <unittitle id="corresp197306"><unitdate> June-December 1973</unitdate></unittitle> </did></c02> <c02 level="file"><did> <unittitle id="corresp1974"><unitdate> 1974</unitdate> </unittitle> </did></c02> <c02 level="file"><did> <unittitle id="corresp197501"><unitdate> January-August 1975</unitdate></unittitle> </did></c02> Figure 7.2.2a. Establishing unique ID values for several elements. <add> <index> <head>Correspondence Index</head> [other possible elements and text ...] <indexentry><persname>Doe, Jane S.: </persname> <ptrgrp> <ref target="corresp197306">24 August 1973 </ref> <ref target="corresp1974">28 February and 16 July 1974</ref> <ref target="corresp197501">15 March 1975 </ref> </ptrgrp></indexentry> [other possible elements and text ...] </index> </add> Figure 7.2.2b. Using a linking attribute to establish a link to the ID attribute value encoded in Figure 7.2.2a.
Generally the use of <linkgrp> should be reserved for links that themselves have some specific element of commonality, where bundling would enhance the ability of the link destinations to function together. The primary usage of <linkgrp> will likely be for bundling external links (see section 7.3.5). Currently available software may not be capable of implementing <linkgrp> for display to end users, nor are XLink developments, including the concept of extended links, finalized. Archivists interested in the potential use of extended links in their finding aids should follow XLink developments.(114)
The terms "simple," "extended" and "locator" all are values for the attribute XLINK:FORM, which is conditionally available on all EAD linking elements and will in the future allow software to readily recognize a specific link as being of a type defined in the XLink specification. This attribute is specific to XLink functionality in the EAD DTD, and it is characterized as conditionally available because, in order to be used, XML functionality must be "turned on" in the DTD file ead.dtd. In order to do so, you must edit the values of two parameter entity declarations in section "XLINK INCLUSION/EXCLUSION" in the file ead.dtd. These values are encoded as follows when this file is obtained from the official EAD Web site hosted by the Library of Congress:
<!ENTITY % xlink 'IGNORE' > <!ENTITY % noxlink 'INCLUDE' >
This means that the XLink functionality is "turned off," which is the default for the EAD DTD because most SGML software cannot handle the colon (:) in the attribute name XLINK:FORM. In order to enable XLink functionality when using XML software in the future, you must change these parameter entity declarations in your local copy of the ead.dtd file so that they appear as follows:
<!ENTITY % xlink 'INCLUDE' > <!ENTITY % noxlink 'IGNORE' >
The value of this attribute is declared as FIXED and is set by the DTD for each linking element. Even when the XLink functionality remains "turned off," familiarity with the role that each linking element plays as designated by this attribute can help encoders understand the proper way to use these linking elements in various situations. Table 7.2.4a categorizes the 15 EAD linking elements by the fixed value of their XLINK:FORM attribute.
| xlink:form="simple" | <archref>, <bibref>, <dao>, <extptr>, <extref>, <ptr>, <ref>, <title> |
| xlink:form="extended" | <daogrp>, <linkgrp> |
| xlink:form="locator" | <daoloc>, <extptrloc>, <extrefloc>, <ptrloc>, <refloc> |
| Table 7.2.4a. Fixed XLINK:FORM attribute values for EAD linking elements. | |
The attribute INLINE is not specific to XLink functionality, and so it is not turned "on" or "off" in the file ead.dtd. INLINE has a value of either "true" or "false," with the default value being "true," meaning that a link is inline. Unless an encoder wishes to change the value of this attribute to "false" to indicate that a link is out-of-line, the attribute need not be used in encoding (see section 7.1.2.3 for a discussion of inline and out-of-line linking).
The attribute INLINE is available on all simple and extended linking elements as categorized in table 7.2.4a. In extended links, the INLINE attribute, if used, would appear on the bundling element, since INLINE is not an attribute option on individual locator elements. As stated previously, current EAD users need not explicitly encode this attribute. The default value of "true" is recommended until the XLink specification and software that will support out-of-line linking is closer to completion.
As noted in section 3.5.2.4, archivists may wish to consider encoding the container and/or folder information for each descriptive component (<c> or <c0x>) below the subseries level, in other words for those hierarchical descriptive components for which box and folder numbers are frequently given in print-based finding aids. A computer processing an encoded document cannot intuit the same meaning from the layout of a container list that a human being processing the same information can. Encoding containment information for each component will insure that container list data will be useful computationally as more sophisticated systems develop in the future for the manipulation and repackaging of data from archival finding aids. Not encoding this information for each component may make it difficult for data to be reused in such systems as they develop.
For example, a person would readily understand, in the following excerpt from a container list, that all three folders are in Box 12:
Box Folder Contents 12 1 Breakdance, 1989-1991 2 Fosse, Bob, 1980-1984 3 Jitterbug, 1938-1942
The problem arises when this same container list is encoded in EAD, as shown in figure 7.2.5a:
<c02 level="file"><did> <container type="box">12</container> <container type="folder">1></container> <unittitle>Breakdance, <unitdate type="inclusive"> 1989-1991</unitdate></unittitle> </did></c02> <c02 level="file"><did> <container type="folder">2</container> <unittitle><persname>Fosse, Bob</persname>, <unitdate type="inclusive">1980-1984</unitdate> </unittitle> </did></c02> <c02 level="file"><did> <container type="folder">3</container> <unittitle>Jitterbug, <unitdate type="inclusive"> 1938-1942</unitdate></unittitle> </did></c02> [...] Figure 7.2.5a. Encoding of container information that may be problematic for computer processing and repackaging of the data.
To a computer processing this file, the descriptive unit "Fosse, Bob" is housed in a folder but not in a box. This is because the closing of the </c02> for the preceding descriptive unit "Breakdance" effectively cuts off the information about Box 12 for use in the processing of succeeding <c02> components. This may not cause a problem if EAD encoding is used only for generating a linear online finding aid. It could, however, become problematic in the future when application software attempts to extract descriptive component information from an encoded finding aid. This might be required in order to present an end user, as the result of a search, with a hit list of folder-level information across multiple collections and multiple repositories. Such a scenario is currently possible for repositories or consortia with access to a good programmer and an SGML-aware search engine. Even in the linear display of finding aids, however, the encoding in the above example has the potential to generate a display that would force the end user constantly to scroll up and down to find the relevant box number for a particular folder, especially in cases in which a box contains a lot of folders.
The PARENT attribute makes it possible, if you are using a delivery system that is technically capable of supporting its use, to drop the <container type="Box"> encoding from all but the first component that falls within each new box and still provide the computer with the necessary information to process unambiguously the containment information for each descriptive component. Figure 7.2.5b is a reencoding of figure 7.2.5a, demonstrating use of the PARENT attribute:
<c02 level="file"><did> <container id="box12" type="box">12</container> <container type="folder">1</container> <unittitle>Breakdance, <unitdate type="inclusive">1989-1991 </unitdate></unittitle> </did></c02> <c02 level="file"><did> <container parent="box12" type="folder">2</container> <unittitle><persname>Fosse, Bob</persname>, <unitdate type="inclusive">1980-1984</unitdate></unittitle> </did></c02> <c02 level="file"><did> <container parent="box12" type="folder">3</container> <unittitle>Jitterbug, <unitdate type="inclusive">1938-1942 </unitdate></unittitle> </did></c02> [...] Figure 7.2.5b. Using the PARENT attribute to establish containment relationships unambiguously.
The PARENT attribute is declared in the EAD DTD with a value of IDREF, the same as the attribute TARGET. Figure 7.2.5b illustrates declaration of a value for an ID attribute on the <container> tag for the first instance of a new box, which can then be referenced using the PARENT attribute on the <container> tag for each successive folder contained within that box. Software processing a document thus encoded would now have access to the box information for every descriptive component in the box. Currently available commercial application software does not have the capability of utilizing the PARENT attribute, but repositories with in-house SGML programming expertise may be able to take advantage of this attribute to avoid repetitive tagging of containment information.
For delivery systems that cannot support the use of the PARENT attribute but that can suppress the delivery of information encoded with the AUDIENCE attribute set to "internal," an alternative encoding of figure 7.2.5a is provided in figure 7.2.5c. This approach supplies the containment information for each descriptive component and does not utilize the PARENT attribute; by using the AUDIENCE attribute, a stylesheet could be used to create a linear finding aid display that masks repetitious box numbers from the end user.
<c02 level="file"><did> <container type="box">12</container> <container type="folder">1</container> <unittitle>Breakdance, <unitdate type="inclusive"> 1989-1991</unitdate></unittitle> </did></c02> <c02 level="file"><did> <container type="box" audience="internal">12</container> <container type="folder">2</container> <unittitle><persname>Fosse, Bob</persname>, <unitdate type="inclusive">1980-1984</unitdate> </unittitle> </did></c02> <c02 level="file"><did> <container type="box" audience="internal">12</container> <container type="folder">3</container> <unittitle>Jitterbug, <unitdate type="inclusive">1938-1942 </unitdate></unittitle> </did></c02> [...] Figure 7.2.5c. Using the AUDIENCE attribute to mask repetitive box information included to facilitate computer processing.
![[VIEW OF LC DOME]](http://www.loc.gov/homepage/lc2.gif)
The Library of Congress