Links are volatile things. They're like a high maintenance relationship.
You have to keep checking-in with them all the time to make sure
they're still OK. When they're broken, you need to do everything in
your power to fix them or you need to end the relationship, deciding
it's just too much to deal with. :) Some relationships aren't fixable.
Sometimes linked resources just decide to get up and walk out without
even leaving you a note, leaving you only the 404 error that they
generate. Remember, any link you put in will require on-going
maintenance. (And remember, not maintaining them is a form of
maintenance, just not a very good one.) We have thousands of links to
digital content in our EAD finding aids. This content lives on another
server. The URL that these links generate is about a million miles long
(plus or minus are few hundred thousand miles). These are the most
dangerous links of all. Forget the URL to your server changing, but
what about when the parameters and switches that that URL contains
change? Sure, you can globally change a URL string to a server, but
these parameters and switches might be a little more tricky (especially
when some of them become completely invalid). That is why I have our
stylesheet manufacture the correct link to these digital resources on
the fly, storing only the unique "pointers" in the EAD finding aid. In
some cases, we do something called "auto-linking". Something like this
can be used if the unique information can be gathered from elsewhere in
the finding aid and massaged to turn it into a meaningful link. (This
can be a time saver). I also use a local "mapping" technique for other
local links, storing only the filename in the link itself and then
having the stylesheet flesh out the link based on the mapping that I
created. For instance, uw-pdf-mss might translate to
http://www.somewhere.edu/findingaids/pdf/mss when the stylesheet parses
the EAD file. Move the file somewhere else and just change the mapping
in the stylesheet. Voila!
For other external links, we just pray to the link-god-in-the-sky that
the link won't die. Fortunately, we don't have too many of these types
of links. And, truth be told, we try not to use them much.
However, if we were really into external linking, I would create a
"linkbase" which would store every external link we wanted to create.
The EAD would then point to the linkbase. You'd run the linkbase
through a link checker periodically to check the links. Any bad links
could be fixed. Problem solved. Any dead links could be coded as such
in the linkbase and when the stylesheet went to retrieve them, it would
just NOT put in the link. It would be, essentially, an authority file of
links. Generate a link to a resource and point an infinite number of
things to it. (Instead of hardcoding the link in an infinite number of
different files). We'd call it a "smart" link, or a link with an
"attitude". You could also call it a "happy" link, since it makes the
user and us happy at the same time. :)
Another alternative, if you are concerned about the persistence of
links, is to use a tool like OCLC's PURL system (purl.org). You add the
link to purl and then you point your finding aid to the purl (i.e. the
persistent) link. Theoretically you should never need to update the
link in the finding aid. All the links are managed on PURL. Of course,
this is one more thing you have to manage.
I know this probably doesn't answer your question, but I think you just
need to weigh the likelihood of a link remaining persistent with the
inconvenience that NOT putting in a link might cause.
Mark
On 3/1/2012 1:51 PM, Deena Schwimmer wrote:
> I would like to know what others do as far as encoding links to external
> sources in your EADs. I have mostly thought about this with regards to
> linking to other institutions’ finding aids in <relatedmaterial>, but
> this could also apply to <bibliography>, <bioghist>, and probably other
> places.
>
> I previously decided against encoding links I don’t have control over,
> regardless of how authoritative or stable they seem to be, so that I’m
> not then forced to make sure they don’t become broken, but with the
> proliferation of digitized resources, I thought I’d revisit and see what
> others are doing.
>
> Thanks!
>
> Deena M. Schwimmer, Archivist
>
> Yeshiva University Archives
>
> */mail:/***500 W. 185th St. / New York, NY 10033 / */interoffice: /*MGL
> – 602
>
> */email:/*[log in to unmask] <mailto:[log in to unmask]>/ */phone:/* (212)
> 960-5451 / */fax:/* (212) 960-0066
>
|