For what it's worth, at the Berkeley Art Museum, we've used both solutions
- that is, both relating individual DAO digital images with item-level
descriptions in our EAD finding aids (as in our Hans Hofmann paintings, see, and
using EBIND to display images of a 180 page artist book in another finding
aid, see In the
latter to see the book you can either click on "DICTEE" in the main menu on
the left as a shortcut and go directly to the EBIND interface; or you can
scroll down on the main menu and conduct a search for the work entitled
"dictee" in which you'll see the link to the EBIND'ed (EBOUND?) document as
a DAO link from the sub-series level in the EAD itself (though in reality
it probably should have been on the actual item level there).

The main reason for using EBIND for us was one of presentation; that is
giving users an easy way to view 180 sequental images related to one EAD
encoded "work" or item. As mentioned, it's just one way to accomplish a
many-to-one image to item relationship; I guess one could include in one
item-level EAD markup a series of 180 DAO's which would imply that they all
relate to that one item, but it would of course be very clumsy to navigate.
I guess has to do with the number of related images, for perhaps a mere two
images of one item, we might just include two DAO's in the EAD, for 180 we
needed something better. The nature of the images would be important to
this decision too, if the images are meant be be seen separately and
sequentially as in our book, then the EBIND is great since it mimics that
presentation style; if the images are say four sides of an object and
better compared side-by side, then another way might be good.

Also, as soon as I used it I mentioned to Alvin my wish that EBIND could
also accomodate the inclusion of the full-text of the book along with the
images, perhaps even multiple versions for translations, which he said was this still desirable Alvin? The EBIND exists as a separate
DTD- bound file with a cgi for activating it directly via the web server,
thus our SGML server software need not deal with it.

Visual materials are of course important to our museum finding aids, so
thanks for all the ideas and discussion so far.

Richard Rinehart              | Berkeley Art Museum/Pacific Film Archive
Systems Manager & Education   | University of California
Technology Specialist         | 2625 Durant, Berkeley, CA 94720-2250
[log in to unmask] |
& President-Elect, Museum Computer Network,