Elizabeth Shaw wrote:
> I take to heart Bill's concern that we really don't understand what
> information is useful to our users. However, I would argue the
> opposite - that XSLT and other XML manipulation tools provide an
> incredible opportunity to discover precisely what we do not know about
> users. A good user study might take a richly encoded description of
> collections and display the same information in a variety of ways. An
> analysis of what patrons find most useful would lead to a better
> understanding of descriptive practice and presentation of
> information. So, in fact, XSL provides a wonderful opportunity in this
Just to clarify, I agree 100% with what Liz has said and if my previous message seemed like I was arguing the opposite, it was just poor word choices on my part. I absolutely agree that stylesheets used with a pool of standardized encoded data will enhance our ability to manipulate that information in order to find out from end users what data elements and kinds of presentation are most useful for them. This is exactly the point at which we are with the Online Archive of California: assembling a sample pool of finding aids encoded to our Best Practice Guidelines (BPGs) so that we can start sitting some end users representative of our primary target user communities down in front of a number of different "views" of the descriptive data and seeing what works and what doesn't for them. The BPGs that we are using were created by the OAC Working Group to consciously incorporate the guidance given by ISAD(G) on multi-level description, available data elements for archival description, and "core" elements necessary for international exchange of information.
The OAC BPGs are a minimal set of guidelines designed not to control every aspect of OAC finding aid encoding, but to provide some minimum amount of standardization of data across encoded finding aids while still giving individual archivists flexibility to expand beyond the BPGs when collections warrant more data. This gives programmers exactly what Liz mentioned in her earlier message, a pool of predictable data elements against which to program retrieval and display interfaces. It will also hopefully give us a basis from which to determine whether or not our encoding needs to be more detailed in order to satisfy the needs of the our targeted groups of end users of the OAC's under-development replacement for the current Dynaweb interface. The BPGs aren't perfect, but we can only improve them by using them and trying out the results on end users.
All that said, I still stick by my earlier contention that we all don't need to learn XSL to move in this direction! And I still think that we need a lot more input from end users before we spend a lot of time and effort trying individually to transform our EAD encoding into something that arranges data elements in idiosyncratic ways that are primarily driven by trying to duplicate the print finding aids that we still have around our repositories. Regardless of how XSL is used by us or the programmers we work with, we're kidding ourselves IMHO if we don't start figuring out a way to get substantive input from online users of our encoded information as we design interfaces that allow them to retrieve and look at that information. Liz stated better than I ever could and from a programmer's perspective why it is critical that we, as Hugo says, "get to it!" with an effort to promulgate some more robust minimal standards about how archival descriptive information should be encoded to maximize the ability of systems to manipulate it for retrieval and display.
| Bill Landis
| Manuscripts Librarian, Special Collections and Archives
| The UCI Libraries, University of California
| P.O. Box 19557, Irvine, CA 92623-9557
| 949 824.3113 Voice | 949 824.2472 Fax
| [log in to unmask]