There are a number of inconsistencies with DAO links in the EAD 
DTD/Schema.  For instance, there is no equivalent to #PCDATA <extref> 
element for DAO.  Instead, for <dao> you are required to put your local 
resource (the text that you click on if the object is not to be 
embedded) in one of the attributes of <dao> or within a child <daodesc> 
element.  This doesn't exactly follow the XLink specification.  The tag 
library example for <daogrp> also doesn't follow the XLink 
specification, which (XLink specification 1.1/section 5.2) states that 
the local resource (the text that you click on to traverse the link) 
should go in a resource-type element (<resource> in EAD) instead of 
<daodesc>.  So you first need to decide how you are going to work around 
these mapping issues no matter which element you end up using.

More responses below...

Mark Carlson
Computer Support Analyst
Special Collections Division
University of Washington Libraries
BOX 352900
Seattle, WA, 98195
(206) 543-1929

John Bewley wrote:
> Any help or opinions on the following would be greatly appreciated:

I'm always happy to give my opinion, especially in regards to linking 
elements and EAD ;)

> RLG, LC, NWDA guidelines all state that <daogrp> is recommended for use 
> for all linking to digital objects from collections, rather than <dao>. 
> Does this leave any uses of <dao> as recommended practice?

I have found, in practice, that for simple type links (where you are 
only linking to one item rather than multiple versions of the same 
item), <dao> is much easier to encode since you are just dealing with 
the one element (and possibly a child <daodesc> element) instead of the 
multiple required sub-elements of <daogrp>.  This might make your EAD 
encoders happier!

And once you have the mapping issues settled, you can easily convert a 
<dao> element to <daogrp> if you should need to do this for some reason 
down the road.

> Tag Library examples show <daogrp> stated within <did>. It could also be 
> stated within <scopecontent> or <c0X). Has anybody developed a rationale 
> for stating <daogrp) anyplace other than <did>?

We have embedded DAO objects within <bioghist>.  It's also available in 
<odd> in addition to <scopecontent> as you state.  This would be at the 
top of my wish list for future revisions to the EAD schema.  I have 
resorted to using <linkgrp> or <extref><extptr> when necessary as a work 
around.  The linking concepts are the same, so it's just a matter of 
being able to identify these as DAO links later on.

> The Tag Library uses the same example for <daogrp>, <daodesc>, <daoloc>, 
> <resource>, and <arc>. The example is for a thumbnail/reference image 
> setup. Can anybody provide examples that would provide links to multiple 
> images rather than multiple versions of the same image?

This is something that I grappled with for a long time.  One can make a 
<daogrp> element so complicated that it's difficult to construct and 
even more difficult for your stylesheet to parse.  I like to think of 
each <daogrp> element as capable of one or two traversals at the most.
There can be multiple resources (i.e. <daoloc>) on the first traversal 
if they are embedded, but only a single resource can be pointed to on 
the second traversal.  Beyond this, it just becomes to convoluted in my 
opinion, so you are better off just creating another <daogrp> element.

For two traversals (without using some scripting language link 
JavaScript) the only valid use for such a scenario would be to embed 
multiple images on the first traversal and then linking out to a single
resource on the second traversal.

This is covered in the XLink specification and there is also a quick 
reference to this in wikipedia that is pretty good:

Let's say you have three images that you want to embed in your document 
using a single link.  I would encode it like this:

<resource label="start"/>
<daoloc label="image" href="image1.jpg" role="image/jpeg"/>
<daoloc label="image" href="image2.jpg" role="image/jpeg"/>
<daoloc label="image" href="image3.jpg" role="image/jpeg"/>
<arc from="start" to="image" show="embed" actuate="onload"/>

Now let's say that you want to be able to click on these images to open 
another html page.  Just add another resource and another <arc>:

<resource label="start"/>
<daoloc label="image" href="image1.jpg" role="image/jpeg"/>
<daoloc label="image" href="image2.jpg" role="image/jpeg"/>
<daoloc label="image" href="image3.jpg" role="image/jpeg"/>
<daoloc label="document" href="mydoc.html" role="text/html"/>
<arc from="start" to="image" show="embed" actuate="onload"/>
<arc from="image" to="document" show="new" actuate="onrequest"/>

Note, these examples are encoded for the requirements of the EAD DTD. 
The values are different for the EAD schema.

> entityref vs. href - in the case of links to digital objects from 
> container lists (as opposed to logos or illustrations), does the use of 
> entityref have any benefits over the use of href in <daoloc> statements? 
> Does the use of entityref entail certain vulnerabilities concerning the 
> contribution of finding aids to shared, or regional databases of finding 
> aids?

I would recommend not using entity references for many reasons but 
mainly because the HREF attribute is a required attribute in XLink 
elements, so the EAD schema requires it (while the DTD doesn't).  So you 
should make all of your XLink elements XLink compliant.

> How many institutions are now incorporating METS into their descriptions 
> and links to digital objects? Does that affect the choice of <dao> vs. 
> <daogrp> in any way? Is this becoming an accepted practice that is 
> likely to become standard practice?
> John Bewley
> Music Library
> University at Buffalo, The State University of New York
> 716 645-2924