Altformavail is probably not the right place to put a PID, but you may not be able to put the PID into the c02/@id either since the PID may not necessarily be a valid xml:id. You certainly couldn't put the PID into the c02/@id in your case since the c02 is really only a subset of the collection object in the repository.
It's difficult to say how one may accomplish this interaction between your finding aid and the repository since implementations of repositories vary from institution to institution, particularly with regard to the way metadata standards are approached.
If there is a definite relationship between the <unittitle> and <unitdate> in your finding aid and the title and date fields associated with the digital objects in the repository, I'd highly recommend building the query to the repository at processing time from the PID, unittitle, and unitdate rather than to encode query strings straight into the finding aid. If there is a change to a repository API in 5 years, you'll be stuck making changes to your finding aids. Maybe some of that can be automated, but it is much easier to alter your XSLT, or whatever language you happen to be using to render your finding aids.
Hi Ethan –
Interesting. So you’re suggesting not using <dao> at all then? I thought altformavail was just for informational purposes, not for linking.
I agree that putting a full URL or a full query string in the EAD is not what I want, absolutely. But I’m not sure that just the collection ID will be sufficient. If the only piece of info in my EAD is the collection ID, that will pull up ALL the digital objects, when what I really want is a specific subset, like correspondence between 1850 and 1860. Or are you suggesting that the style sheet would construct the HTML link by pulling information from an <altformavail> plus the <unittitle> plus the <unitdate> ? Wouldn’t that actually be more cumbersome (also risky) than simply passing the specific parameters (collection ID; correspondence; 1850 and 1860) for the set of digital objects that I want?
If you have 3500 digital objects that belong to a collection, the collection itself should be a digital object, correct? Does the Gerrit Smith collection have a unique identifier in your repository? I would think that your repository software would enable one to query all child objects from a master collection object. Fedora has REST APIs that enable this interaction. If the Gerrit Smith collection has a unique identifier, you could use it as the id for the c02 or place it into altformavail, perhaps. There are probably a few ways to go about it, but this would remove the need for placing URLs and query strings directly into your finding aid. Software structure changes over time. Certain APIs become deprecated (potentially making your query string nonfunctional), but unique identifiers in an institutional repository are intended to last for all time.
On Wed, Apr 6, 2011 at 10:02 PM, Michele R Combs <[log in to unmask]> wrote:
Suppose that you have a collection of 3500 items that has been completely digitized.
Suppose that you do not wish to have 3500 <dao>'s in your EAD finding aid, but instead would prefer to provide a link that would fire off a search of your digital image system and retrieve all relevant items for each particular series or subseries,
Suppose, finally, that you do not wish to hard code a full URL of "http://very-very-very-long-string" but rather want to encode just the relevant search terms and let the style sheet construct the link.
Presumably you would still use <dao> for this, since these are digital versions of archival material in the collection. But what attribute(s) of the <dao> would you use to encode the search terms?
For example, let's say this dao is intended to fire off a search of a digital collection called "Gerrit Smith" and bring up all the correspondence from 1850-1860. Would this be a correct encoding, with the two search parameters in the href?
Also, if anyone has working examples of something like this please share.