>> Timothy, others -
>>
>> Seems there's enough interest to warrant posting to the list.
>>
>> > Has anyone implemented EAD 1.0 with OpenText Livelink?
>> > If so, I would appreciate the chance to exchange notes on
>> > how to set up the software.
>>
>> We use Open Text (OT) Livelink 7 for indexing & retrieval (I/R) of our
>> cross-institutional DB of around 5000 Finding Aids. Some are beta, some
>> version 1. We haven't seen any problems with version 1, but then we
>> don't use OT's presentation facilities directly.
See if they will give you a copy of an earlier version such as OT5 --
others have been doing this.
>>
>> One reason we chose OT in the first place was their sgml
>> support. This seems to be going away, & never worked properly for us
>> anyhow. Their sgml processor required that all tags be explicitly
>> closed. Since we had no control over the encoding of the documents, we
>> couldn't conform with this requirement.
There are many other reasons why you want to avoid minimized tagging,
but in SGML mode, if teh DTD allows it, OT tries to deal with it. At
its heart, it des not like them however.
>> Instead, we use their 'tagged
>> ascii' indexing feature, which seems to work about like the sgml would
>> have, allowing us to use tag names as fields in searches. I think the
>> only thing we lose by doing 'tagged ascii' rather than sgml is the
>> ability to use attribute names as field names in searches. This doesn't
>> seem to have much practical impact for us.
Unless the tool has changed radically in OT 7 there is a way around this
in previous versions (I've been using attributes with OT for years).
>> A more significant shortcoming of OT's indexing, for us, is the lack of
>> a structural notation in fielded searches: i.e., if you have an element
>> X that can occur withing element A & element B, there's apparently no
>> way to say 'consider only X values within A'. I'm not sure if this is
>> because we're indexing as 'tagged ascii' - maybe you can do this with
>> their sgml indexing? I'd like to hear about reasonably priced I/R
>> software that will do this, for sgml & xml.
Again - this can be done in earlier versions -- when indexing, after
having indexed the tags, you can build a "region" that is
region B within region A
and then save the index pointers to an index file that can be used from
that point on. If you called the ergion "regionA", you could then
search within it:
"jefferson" within regionA
>> I think verity will, but
>> it's out of our price range.
>>
>> We like OT's I/R power very much The snappy performance compensates
>> pretty well for the middleware we encumber it with. We came up with the
>> middleware because we didn't care at all for their out-of-the-box user
>> interface. There is a command-line interface to their search software,
>> but it's undocumented & unsupported. Some of the pat50 commands
>> documented by michigan (?) seem to work the same way with the 'pat60'
>> that came with our bundle, but we couldn't figure out how to use it in
>> the cgi environment to do things like deliver a stream of summary-level
>> elements from a result set. (I can dig other complaints/puzzles out of
>> my notes if anyone's interested.) So we ended up interposing a web
>> interface of our own devising between the users & the OT web server.
>> This middleware gives us the look we want, at some performance cost - at
>> a very minimum, it doubles the hit rate, since each post to our
>> middleware becomes at least 1 more post to the livelink httpd, &
>> sometimes more.
Given that you are doing exactly what we (and many others) do, see if
you can run OT5, which may lack some features that 7 has, but possibly
few that you can for, and because it has no web interfaces at all (only
windows 3.1 and X clients) it is much easier to use the comandline
interface, and therefore much easier to roll your own web forms and html
converters.
>> Originally we thought web browsers would support sgml more widely than
>> has turned out to be the case. Many folks found Panorama unpleasant
>> though, & nothing better came along, so we decided to serve html. We
>> were disappointed with OT's html conversion, & contracted with UC's Alvin
>> Pollock for some enhancements to his ead2html proofing tool, to make it
>> more general & configurable. We are quite pleased with the quality of
>> the html produced by ead2html, & with its flexibility. It isn't fast
>> enough for on-the-fly conversions, though, so we make static conversions
>> as part of the DB maintenance cycle, & serve these.
Is it a perl script? We have had no problem with conversion speed using
perl -- all our etexts and EAD guides are filtered live and have always
been so.
>> We don't really think we fit OT's customer profile any more, if we ever
>> did, & this is one reason we're looking to replace them. They don't
>> offer us educational discounts (nor do INSO) - no doubt we'd find them
>> more likeable if they did.
Even before they effectively abandoned many library customers after OT5
when they dropped AIX support, their service was appalling.
I'm off on a lecture trip for a few days but maybe we can talk when I
get back.
David Seaman, Director 804-924-3230 (phone)
Electronic Text Center 804-924-1431 (fax)
Alderman Library email: [log in to unmask]
University of Virginia http://etext.lib.virginia.edu/
Charlottesville, Virginia 22903
|