On Thu, 20 Feb 1997, Bill Landis wrote:
> I would be interested to hear more about how the choice of nested <c>s
> vs. nested <c0x>s plays out in displays. I assume that the implicit
> assumption in this concern is display in Panorama?
No, we are not assuming that our display will always be in Panorama; but
there will need to be display of _some_ kind. The implicit assumption is
that, in terms of display, we should focus on the individual finding aid
as a whole, and how the different <c>s nest within that finding aid, as
conveying the most useful information to the user. The other options
would be: 1) have a style sheet attached to each finding aid, which seems
more work than it would be worth; or 2) have a style sheet that handles
<c01>s etc. in a uniform way across finding aids. This may very well
work, but we're being somewhat conservative and trying to find a
minimalistic style sheet that will handle the widest possible variety of
nesting. So far, <c> seems to work.
> It seems to me though that you don't really get around this by using <c>s
> instead of <c0x>s, since regardless of what label you use, a particular
> item would be nested at a different location in different finding aids
> depending on whether or not the fonds in question is divided into only
> series or into series/subseries. I haven't actually experimented with this,
> but wouldn't this mess up the use of a single Panorama stylesheet file
> for all of Harvard's finding aids anyway?
Well, I wouldn't say that our style sheet is perfect yet, but basically
it's ok, and we do have a variety of nesting <c>s. I think the important
thing is that the display makes sense within that _particular_ document.
> Also, taking this further and exposing up front my bias that relying on
> Panorama as the sole means of accessing a repository's EAD files puts an
> unnecessary burden on the end user, I wonder if providing access to EAD
> files using a search engine like OpenText and relying on on-the-fly SGML
> -> HTML conversion for display would or would not have an effect on the
> consideration expressed in Leslie Morris' message.
We are not using Panorama as the sole means of accessing the finding aids;
we hope to use the new version of OpenText (although it's undergone a name
change, and I can't remember what the newest name is at the moment) as our
search engine. The search engine then delivers a list of finding aids
which, as you point out, could be delivered either in SGML or HTML. We
would _like_ to deliver in SGML because of Panorama's (and hopefully all
those other, future SGML browsers') navigational features, which one
doesn't get in HTML. But, given that Panorama, while free, requires
effort on the part of the user community to get and install, we are
considering delivering in HTML as well (as UCSD is doing). But we're
still working on getting a SGML --> HTML conversion to _look_ nice.
There are so many details to be worked out, and so little time!
Leslie A. Morris
Curator of Manuscripts in the Harvard College Library
Houghton Library, Harvard University
Cambridge, MA 02138
e-mail: [log in to unmask]