This is the first of several messages that I will forward to the list
concerning the reaction here at Yale to our experience with the EAD dtd. We
have had three Yale repositories (the Beinecke Rare Book and Manuscript
Library, the Special Collections Department of the Yale Divinity Library,
and Manuscripts and Archives) working on the dtd for some months now. To
some extent, our comments are informed by our experiences with the FINDAID
dtd and ongoing discussion we have been having since last April's meeting in
Berkeley. My apologies for missing Daniel's Tuesday deadline.
A bit of background might be useful. Following demonstration of the
original Berkeley FINDAID database, discussions with the Berkeley team and
colleagues at last April's meeting, and experience with a few prototype
encoded finding aids, the above three repositories here at Yale were
sufficiently impressed with the progress made and confident enough of the
general direction, that we decided to pursue a more active role in helping
to evaluate, develop, and implement the dtd. Rather than work int he
abstract, we decided to acquire a package that would support maintenance,
indexing, and delivery of SGML documents and reviewed a number of packages
last summer. Our requirements included the ability to deliver SGML
documents to workstations across the Yale campus (and to the larger research
community) that had access to the campus network and the Internet and to
readily available searching and viewing software. We chose the OpenText
software package for the maintenance, indexing, and delivery functions, and
Panorama from SoftQuad as the viewing software for users. Our working
assumption has been that we would deliver the marked-up finding aids through
the World Wide Web using Panorama as a helper application. Our charge in
evaluating software was also to keep in mind potential uses for delivering
other full-text databases in the Library. OpenText's ability to handle a
wide variety of text files (including SGML) and to work with documents
mounted on multiple platforms were strong features in its favor. We also
acquired the Latitude Web Server package from OpenText which provides a
web-based interface to the OpenText database language (PAT). This allows us
to construct HTML forms for user searching of the finding aid database.
Since the OpenText software arrived last fall, we have installed it on the
Yale Library server and loaded the pre-alpha (October 1995 version) of the
EAD. We used this as our learning experience with OpenText since the alpha
EAD with examples wasn't yet available. We have resolved most of our
questions about how to mount and run and application on OpenText and are in
the process of mounting the alpha EAD with available examples.
Simultaneously with the systems work, another group of "Text Deployers" has
been working with the alpha EAD to evaluate how well it meets our structural
and content needs. Two of the repositories are using WordPerfect for
Windows SGML edition for creating marked up finding aids and one is using
Author/Editor. Our working assumption is that each repository will choose
the document creation/encoding environment that fits best with its
particular environment, but that we will not prescribe a particular software
approach to markup. As long as each repository provides the server with
valid, encoded finding aids, we are not concerned about how they created
them. That's a bit of overstatement since we are comparing notes about the
effectiveness of the various tools and whether it is of benefit to
standardize on a common set of encoding tools, but the basic assumption of
source independence still holds. We are all using Panorama Pro to create
our prototype style sheets and to test our assumptions about display and
navigation.
Another working assumption is that most, if not all, of the repositories
will continue to create finding aids as they currently are doing (using w-p
software) and the vast majority of the markup will be done through macros or
scripts once the finding aid is complete. This leverages our existing
experience with our existing systems, but obviously depends on each
repository having a standard format for its finding aids that will make
automatic markup feasible. Fortunately, that is the case for all three of
us. If this works, we will not be using an SGML editor for document
creation, but only for validation and special editing that the macros and
scripts can't handle.
The Yale Library was kind enough to sponsor a visit by Daniel week before
last and we were able to clarify many of our assumptions and discuss our
questions with him.
Within a month, we should have a small set of encoded finding aids and some
basic search forms operational for testing. When that happens, we will let
you all know the url so you can peek in and see what we've been up to.
I'd be happy to forward any questions to the group here or refer you to
specific people who are focusing on particular software or implementation
strategies.
More to follow on specific issues and concerns.
Rich Szary
Manuscripts and Archives
Yale University Library
|