St/
Your point is well made, as usual. EAD is also conservative to the extent that EAD implementation so often focuses on replicating the print environment online. On the other hand, it has been a useful and necessary first step in moving from a finding aid environment that was presentation-centric to one that is data centric.
MARC went through this for a long time. Though based on data structure, it was initially used to create print output on cards and subsequently to populate a first generation of library catalogs that so often replicated the look and feel of the 3x5 card on a terminal screen. Now we are seeing ILS search environments and graphic displays that are more informed by the nature of the data and user needs. As the archival world makes that same transition, we too will come to see that the online environment may have different navigational requirements than the print one.
The irony I see in most current displays of archival data is this- print models have replicated in the online environment which in turn is trying to drive print displays. A circular line of reasoning.
Michael
-----Original Message-----
From: Encoded Archival Description List on behalf of Stephen Yearl
Sent: Fri 6/30/2006 6:18 PM
To: [log in to unmask]
Subject: Re: Generating hard copy from EAD
On 6/30/06, Fox, Michael <[log in to unmask]> wrote (in part):
>> Ironically, I see the requirement to replicate the hierarchy on every
page (if I understand your situation correctly) ...
Michael:
You do understand correctly, and you also understand that print is a
conservative and known medium for many. I do not presume that the online
(HTML, essentially) should be congruent with the print. There are plenty of
CSS/HTML/JS mechanisms for helping the researcher overcome the "where the
heck am I in this hierarchy", but in print, there are very few albeit tried
and trusted markers to achieve just this. It IS hard do do this in FO 1.0 is
my sole point.
I see no irony in this...
except that we have not yet come to the point in our community when we can
stop thinking of finding aids as documents, and can start the process of
data exchange that well structured SGML promised. I await the day. Until
then, it is necessary to replicate the print finding aids that have served
our researchers so well; our PDFs are printed and bound after all.
Best regards,
St.
On 6/30/06, Fox, Michael <[log in to unmask]> wrote:
>
> A requirement is a requirement but this one seems retro. With page
> form, printed presentations of finding aids, most institutions did not
> repeat this hierarchy on the top of every page because it was easy to scan
> visually from page to page, flipping back when we needed to reestablish
> where we were in the structure of the collection.
>
> 25-line monitors changed that so now we have a need for more continuous
> context-notation as we scroll through a document. It's also needed in
> database retrieval where the response set consists of "chunks" of
> descriptions extracted from the whole.
>
> We see that presentation in the online environment requires different
> navigation than the print world.
>
> Ironically, I see the requirement to replicate the hierarchy on every page
> (if I understand your situation correctly) as the reverse situation-
> where the online requirements are now trying to drive print products. Have
> we forgotten the earlier lesson that the needs of print and screen are
> different?
>
> Michael
>
> [----Original Message-----
> *From:* Encoded Archival Description List [mailto:[log in to unmask]]*On Behalf
> Of *Stephen Yearl
> *Sent:* Friday, June 30, 2006 9:07 AM
> *To:* [log in to unmask]
> *Subject:* Re: Generating hard copy from EAD
>
> Mike:
>
> The closest I got was with using table heads in the flow, thus at least we
> always have the collection title in the header and the series (always a c01)
> at the head of each page; so a two-part running header. If pushed logically
> the table header method might be used to recreate the hierarchy, but
> regressing though some 14 tables is messy in the extreme.
>
> >>Furthermore, the page can easily be overrun with such extended
> >>headings and result in very little room for the actual information
>
> Indeed! But a requirement-- such as this was for us-- is a requirement
> nonetheless.
>
> Best regards,
>
> St.
>
> On 6/30/06, Mike Ferrando <[log in to unmask]> wrote:
> >
> > Stephen Y.,
> > Concerning running headers for dsc content, I had the idea to
> > implement floats. The header area cannot be changed or added to
> > without disrupting the flow.
> >
> > However, although this can be done to bring headings to the top of
> > the page (under the header area), the next problem is how to set this
> > information off as part of the header. The issues being spacing,
> > formatting (style and spacing), etc.
> >
> > How can this be done in such a way that the user understands that
> > these are an "extended" part of the header and not part of the dsc
> > flow?
> >
> > I was experimenting with a couple of things.
> >
> > 1. Keep the headings to subseries only.
> > 2. Expect subseries/subseries
> > 3. Use a Windows icon folder structure for this area (open folders
> > before the subseries name and "L" shaped icons joining the outline
> > structure of the extended header.
> >
> > But the whole thing seemed to me to rather difficult and a regression
> > in the workflow. The PDF should have bookmarks active and available
> > for the user. When the user is at a certain page, the bookmark will
> > be grayed-out indicating the location in the document.
> >
> > Furthermore, the page can easily be overrun with such extended
> > headings and result in very little room for the actual information.
> > One would wonder if we are loosing site of the object and goal of
> > moving the information into this format in the first place (forest
> > and trees issue).
> >
> > The hard copy should really be considered as a product of the display
> > format, not an entity existing of itself.
> >
> > Page-by-page orientation in a hard copy is a regression of the data
> > to a obsolete format which should be avoided at all costs.
> >
> > My two cents.
> >
> > Mike Ferrando
> > Library Technician
> > Library of Congress
> > Washington, DC
> > 202-707-4454
> >
> > --- Stephen Yearl <[log in to unmask]> wrote:
> >
> > > MIchelle:
> > >
> > > the Manuscripts and Archives unit at Yale has been using the
> > > formatting
> > > objects processor (FOP, http://xmlgraphics.apache.org/fop/) to
> > > produce PDF
> > > for a number of years. A very localised stylesheet converts EAD 1
> > > to XSL-FO
> > > (1.0) which is then run through FOP. FOP is only of many available
> > > FO-processors, and the only one I know that is free, and has a
> > > reasonable
> > > enough implementation of the FO standard that it is certainly
> > > usable since
> > > version 0.20.4 to produce PDF or rich text format, RTF for editing
> > > in a word
> > > processor. Producing barcodes, folder/box labels and such is also
> > > not _too_
> > > tricky once you understand the FO standard, but that's quite
> > > another story.
> > >
> > > The biggest gripe with FO 1.0 is that it is impossible (someone
> > > prove me
> > > wrong, please!) to create 'running headers' at page breaks; viz. if
> > > a c05
> > > falls at the head of a new page, list the parent C0xs unittitles to
> > > give a
> > > sense of where one is in the hierarchy. I have been told that this
> > > is
> > > possible in FO 1.1 (a candidate recommendation as of February this
> > > year). As
> > > far as I know The FO processor (XSL Formatter, version 4 ) from
> > > Antenna
> > > House is the only processor that supports 1.1.
> > >
> > > Our EAD 1 to FO 1 stylesheet, as I said, is very tuned to our
> > > specific tag
> > > usage, and so may not work well for others. That said, over the
> > > coming
> > > months Yale will overhauling its EAD implementation and, lawyers
> > > permitting,
> > > we would like to make available our stylesheets and other code
> > > through the
> > > EAD Help Pages (On which, expect an updated site in the very near
> > > future).
> > >
> > > Good luck,
> > >
> > > St.
> > >
> > > Stephen Yearl
> > > Systems Archivist
> > > Yale University Library::Manuscripts and Archives
> > >
> > > On 6/29/06, Michele Rothenberger < [log in to unmask]> wrote:
> > > >
> > > > Hello all --
> > > >
> > > > Wondering whether anyone would care to share their method of
> > > getting
> > > > hard copy from EAD. A style sheet within your EAD authoring
> > > software
> > > > that formats for printing? An XSLT style sheet that produces
> > > HTML
> > > > formatted to print nicely? or perhaps outputs PDF? or Word?
> > > Something
> > > > daringly new and different that no one else has thought of?
> > > (BTW,
> > > > thanks to Susan Hamburger at Penn State for explaining her
> > > NoteTab Pro
> > > > approach to me a couple of weeks ago!)
> > > >
> > > > Any and all information is welcome. Thanks in advance --
> > > >
> > > > Michele
> > > >
> > > >
> > > > -=--=--=--=--=--=--=--=--=--=--=--=--=--=-
> > > > Michele Rothenberger
> > > > Special Collections Research Center
> > > > Syracuse University Library
> > > > 222 Waverly Avenue
> > > > Syracuse, NY 13244
> > > > (315) 443-2697
> > > > -=--=--=--=--=--=--=--=--=--=--=--=--=--=-
> > > >
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
>
>
St.
|