Scripted Links in EADs

From UA Libraries Digital Services Planning and Documentation
Revision as of 08:36, 18 December 2009 by Jlderidder (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

We are scripting in links to items in folders, in the order encountered. We first studied the available addons for Archivists Toolkit, but they did not meet our needs. We didn't want to use more than one link per item, and we do NOT want to embed the content of the link into the finding aid.


This is based on the structure used by the Library of Congress on this page of their website: http://www.loc.gov/ead/tglib/elements/dao.html Shawn Averkamp, one of our Metadata Librarians, designed this after much debate and experimentation:

A sample folder-level segment from the Cabaniss EAD would look like this:

               <c id="ref555" level="file">
                       <did>
                           <unittitle>Incoming, I- K</unittitle>
                           <container type="Box">252.005</container>
                           <container type="Folder">6</container>
                       </did>
                     </c>
                 

After adding a link to a subsidiary item that has been digitized from Box 5, folder 6, it will look like this:

               <c id="ref555" level="file">
                       <did>
                           <unittitle>Incoming, I- K</unittitle>
                           <container type="Box">252.005</container>
                           <container type="Folder">6</container>
                       </did>
                       <c id="refu0003_0000252_0000002" level="item">
                          <did>
                            <unittitle>W.D. Chadick report concerning the prospects for freed persons in Ohio, 1858</unittitle>
                          </did>
                          <dao id="u0003_0000252_0000002" ns2:title="u0003_0000252_0000002" ns2:href="http://purl.lib.ua.edu/148" ns2:actuate="onRequest" ns2:show="new"/>
                        </c>
                     </c>
                 

Here are the results of Shawn's experiments with the current version of Archivists Toolkit:

1) On import, AT strips the dao @id and replaces it with one it automatically generates. (actually, it renumbers all @ids with each export, so all of the ids in the ead I exported are different than those on the imported ead. I don’t know how much of a problem this is since they’re for internal reference.)

2) On export, AT puts the <dao> outside the item-level <did> (but still within the item-level <c>). I don’t think this matters schema-wise, and I don’t think it will affect grouping the <dao>s in Acumen.

3) Within the <dao>, AT strips the @actuate and @show attributes and exports them with the default values of @actuate=”onRequest” (which is fine) and @show=”embed” (note that we are inputing @show=”new” which opens the link target in a new window). Acumen is not going to care about these attributes, but I don’t know about other contexts where this ead might show up.

4) On export, AT throws an empty <unittitle> into <did>. Best practices recommend having either <unittitle> or <unitid> within a <c><did>. I hesitate to put the digital object id into <unitid> because it identifies the digital surrogate, not the actual item. Despite the fact that the schema does not require <unitttle>, AT will not let you save unless there is a value in <unittitle> or <unitdate> (though you can still export).

5) On export, AT dumps anything in @ns2:title into <daodesc>. (We could just not use the title attribute.)


Therefore, after we have completed adding links to our mass-digitized EAD, the EAD will then be uploaded into Archivists Toolkit so the archivists will have a copy of the latest version; but an XSLT transform will be used on any further exports of that EAD, until the issues with AT are resolved. This transform will return the linked sections to the form we have delineated up above.

Personal tools