Strictly speaking the idea with <dao> is that the objects are 'part of the described materials'. It seems to me that with this interpretation you shouldn't use <dao>. But it does depend on what 'part of' means.
It feel like, if we go with strict definitions, you should use <extref> and yet it feels more consistent to just use <dao> to link to digital representations at any location where they do represent the materials you are describing. I'd rather use <dao> and maybe recommend making it clear that these are held elsewhere.
The Archives Hub
email:[log in to unmask]
tel: 0161 275 6055
On 10 Jun 2011, at 22:19, Michele R Combs wrote:
> OK, here's another <dao>-related question.
> Let's suppose that the Smith Library has a collection that includes typewritten transcripts of interviews. Let's further suppose that some other institution -- we'll call it the Jones Library -- has scanned images of these transcripts in PDF files. To keep it simple, let's suppose that the paper and digital have always belonged to their respective institutions so it's not a case of <separatedmaterial>.
> In such a case, is it appropriate for the Smith Library to use <dao>s in their finding aid at the item level, next to the listing of the typed copy, to link to the digitized version at the Jones Library?
> On the one hand, the PDFs certainly are digitized versions of items in the collection, so <dao> seems appropriate. On the other hand, the digital objects don't belong to the Smith Library so perhaps <extref> is more appropriate. (I won't even go into whether <archref> might be appropriate. What's that you say? EAD has too many linking elements? Pshaw!) Or perhaps, since the PDFs don't belong to the Smith Library, nothing should be linked at the item level but instead just an <altformavail> up at the collection level. So many options...
> My guess is that this situation is not unique and will become increasingly common as institutions collaborate on digitization efforts. Your thoughts?
> Michele Combs
> Librarian for Manuscripts and Archives Processing
> Special Collections Research Center
> Syracuse University
> [log in to unmask]