Our server is back on line!
Ebind does accomodate the full text of a document. Available
markup is minimal, restricted primarily to display tags. The
design philosophy with Ebind is that if more detailed markup
is desired, a full-fledged text-based dtd, like TEI, is the
way to go. The cgi script also accomodates full text display,
witness the Patrick Breen diary,
but *searching* functionality is currently lacking. This is
a lack in the *application* not the *DTD*. I remember another
publically accessible finding aid with a link to an ebind
document, this one being a music score, something one might
be hard-pressed to mark up in TEI, see:
In the container list of the same finding aid are examples
of what Richard was talking about, some images are better
displayed in-line using multiple <dao>'s, although the case
could be argued that the images of the letter might be better
represented in Ebind.
Electronic Text Unit
UC Berkeley Library
[log in to unmask]
At 01:43 PM 12/9/97 -0800, Richard Rinehart wrote:
>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
>using EBIND to display images of a 180 page artist book in another finding
>http://www.bampfa.berkeley.edu/collections/bam/texts/cha.ead.html). 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
>possible....is 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] | http://www.bampfa.berkeley.edu/
>& President-Elect, Museum Computer Network, http://www.mcn.edu/