[log in to unmask] wrote:
> In order to be able to convert the finding aids on the fly, so to speak, we
> would need to get Dynaweb, which I found out costs $22,000+ (anyone know of
> a cheaper yet comparable product).
Ahh, but DynaWeb is but one of many ways in which you can convert your
finding aids on the fly. Duke University has demonstrated the conversion
of SGML-formatted finding aids into HTML [1] using OCLC's FRED [2]
software. There are many other ways in which one can convert SGML
documents into other formats--the Duke project also prepared printed
finding aids by transforming the SGML into LaTeX. There is David
Megginson's sgmls.pm [3], a post-processor of SGMLS and NSGMLS [4]
output, which uses Perl. There is also the Copenhagen SGML Tool [5],
and its companion tool costwish [6].
In addition, James Clark (author of the public-domain SGMLS and NSGMLS)
is currently working on a transformation engine for the Document
Style Semantics and Specification Language, a recent ISO standard
style-sheet language, which will allow users to transform SGML instances
into other formats.
So it is plain to see that DynaWeb is by no means the only game in
town--and all of the tools mentioned above, with the exception of OCLC's
Fred, are freeware. By choosing SGML you are liberating your data
from the control of software vendors. If you choose now to use a freely
available product to do your transformations, but decide in the future
that you need the service and support of a commercial product, your
investment in SGML guarantees that your data will work with your new
vendor's product, with no changes whatsoever.
> In essence, what is the value to our institution to do all this, when we can
> just as easily make our finding aids available as preformatted html text.
Let me address the first point in two ways, making two different assumptions.
First, I'll assume that by "preformatted html text" you do not mean to
simply do the following:
<HTML>
<PRE>
Finding aid
</PRE>
</HTML>
With that assumption, I would ask: to what version of HTML should you
encode your finding aids? Will it include Netscape-isms? If you choose
to use the new kewl Netscape "tags", but decide at some point in the
future that Microsoft's Internet Explorer is the better target browser,
what does that imply for all of the finding aids that you have encoded
using Netscape's version of HTML? Would it be preferable for you to
re-encode all of your "legacy" HTML finding aids according to the
new "standard?" or would you be better off making some simple changes
to a transformation routine to make your updates?
If the previous assumption is incorrect, I would suggest that placing
your finding aids into a <HTML><PRE>text</PRE></HTML> format is only
a small step beyond scanning the finding aids and making those digital
pictures of the finding aids available. Each step might give you a
marginally more useful version of the finding aid than the standard
paper-based guide. The ability to do a full-text search on an
unindexed collection of documents is almost useless when one is dealing
with a colleciton of any size.
> In
> either case they are about equally as searchable without the added expense
> of a search engine which works across files/directories.
Again, there are even freeware tools that support the searching/indexing
of structured texts. For example, sgrep [7] is a grep-like tool that
provides this function.
Although I am not aware of other similar tools, this should not be
a deterrant in pursuing EAD and SGML. While I sympathize with the
desire to save money, the added benefits of being able to do
searching within structred texts is nearly immeasurable. Can we
imagine what it would be like to search our library OPACs if the
records were indexed only on a full-text basis?
I'm perfectly aware of the great costs associated with much of the
commercially available SGML software. It is a major drawback in
many ways, however, we should not be short-sighted in our pursuit
of wider access to our collections.
-- Tom
[1] <URL:http://scriptorium.lib.duke.edu/findaid> Note that these
example finding aids were encoded using the FINDAID DTD.
[2] <URL:http://www.oclc.org/fred/>
[3] <URL:http://www.uottawa.ca/~dmeggins/SGMLSpm/sgmlspm.html>
[4] <URL:http://www.jclark.com/sp/index.htm>
[5] <URL:http://www.art.com/cost/cost.html>
[6] <URL:http://www.venus.co.uk/omf/costwish/costwish/index.html>
[7] <URL:http://www.cs.helsinki.fi/~jjaakkol/sgrepman.html>
Thomas A. La Porte
DreamWorks SKG [log in to unmask]
100 Universal Plaza, Bldg 601 Phone: 818-733-6328
Universal City, CA 91608 Fax: 818-733-6318
|
