3.87 scholarly computing, cont. (131)

Thu, 1 Jun 89 23:16:02 EDT

Humanist Discussion Group, Vol. 3, No. 87. Thursday, 1 Jun 1989.

(1) Date: Thu, 1 Jun 89 09:44 EST (50 lines)
Subject: 3.76,3.82 scholarly computing...

(2) Date: Thursday, 1 June 1989 1005-EST (61 lines)
Subject: Scholarly Research and Computers Again

(1) --------------------------------------------------------------------
Date: Thu, 1 Jun 89 09:44 EST
Subject: 3.76,3.82 scholarly computing...

One major initiative in scholarly computing that HUMANISTs may
not be familiar with is the very far reaching long range plan
by the National Library of Medicine, a branch of the U.S.
National Institutes of Health, Dept of Health & Human Services,
Bethesda Maryland. There is a 7 volume description of the
plan available for asking, which summarizes in very readable
text thousands of expert-hours in laying out what access to
the total global medical literature should look like over the
next 25 years. Much of this is applicable to other areas,
including long descriptions of Scholar's Workstations, AI,
networking, knowledge representation for instant retrieval,
even by the generic vs vendor name of drug (say, rock instead
of marble), etc. I highly recommend this for reading.
Associated with that is the IAIMS project, "Integrated
Academic Information Management Systems", attempting to seed
via grant money projects in actually using technology to
bring data to decision-makers at all levels. Several sets
of proceedings of this work are available: the program
officer is Richard T. West. General inquiries can go to
(301) 496-6308. The proceedings, as well as proceedings of
American Association for Medical Systems & Informatics have
hundreds of pages of reasoned discussion about technology
transfer barriers to use of computing in academia/medicine, etc.
Incidentally, I find almost exactly the same debate
going on in CompuServe in the Medical Forum -- what does it
take to get people to use computing, how do we teach
students/faculty, what really works, etc?
As a personal opinion addendum, I think the next big
area for "computing" will be groupware that actually makes
it easy for multiple authors, distributed geographically,
to work on the same research/manuscript, including good ways
to redline, annotate, include voice-mail messages (click here
for comments) that convey the tones and emotions so relevant
to achieve concensus on sensitive issues, etc.

For those who want the info, the address and phone numbers are
as follows:

National Library of Medicine
8600 Rockville Pike
Bethesda, Maryland 20894
United States

(301) 496-6308 General inquiries/publications
(301) 496-6095 Reference Services
(2) --------------------------------------------------------------64----
Date: Thursday, 1 June 1989 1005-EST
Subject: Scholarly Research and Computers Again

Charles Faulhaber thinks he disagrees with my argument that
for the most effective use of computer capabilities in scholarly
research, the scholar should have a general knowledge of how
computers work and should have, or have access to, expertise
that combines knowledge of what the humanities researcher needs
with knowledge of what computers can do -- if I ever claimed
that "the humanities scholar should have to become a computing
specialist" in this context, that is not what I meant to say.
I wanted to address the issue of appropriate "computer literacy"
and appropriate resources for consulting. I will be surprised if
Charles and I really disagree on these matters.

His analogy of the use of word-processing is, for me, a case in
point. Many scholars use "wordprocessing," but I have met very
few who have any real idea of the power and capabilities available
in the programs they use, much less of why one program might be
better for them than another! Why? Partly because they can't be
bothered to master the documentation, but that may be to a large
extent because the documentation itself often assumes a level of
"computer literacy" that is beyond the present experience of the
user. Users who have some idea of what the computer is capable
of doing usually can find a way to coerce their wordprocessors
into doing much more (including "research" tasks) than other,
less "literate" users can/do. And if the researcher knows how
(or sits next to someone who knows how) to do even minor modification
of source code, there are myriads of programs "out there" that can
be tailored to specific research needs very easily, with amazingly
effective results. Complaints about lack of appropriate software
are sometimes more a problem of the potential user's ability to
understand and adjust than of unavailability -- other times,
admittedly, the software doesn't exist yet in appropriate forms
(I doubt that Willard's question about ivory and marble in
classical Latin poetry could be solved "in an hour" even if we
had a complete Thesaurus Linguae Latinae CD-ROM and an IBYCUS
Scholarly Computer running it; maybe in 3 or 4 hours, with luck;
unless, of course, Charles meant an INDEXED TLL, with the right
sorts of indices -- more than incidentally, even attempting to
discuss this side issue intelligently requires knowledge about
the technology [why IBYCUS at this point would be a better
choice than IBM] and the software [how to work around the lack
of an "and not" choice in IBYCUS searching; or why PANDORA on the
Mac might have special advantages for this task], as well as the specific
research needs [what sorts of indexing might be most useful
for the task at hand]).

As for David Megginson's plea not to fix what ain't broke,
I don't disagree at one level, but in order to know what that
level is, I would need to know how much time it would take to
figure out how to do a task on a computer, and how many more
times in my life I would want to do the same task. Since usually
neither David nor I can answer that one without first trying,
I would vote to put in the time moving to the computer
approach, since in the long run it will almost certainly
pay dividends -- especially when the potential user learns
about the potential (and actual) usefulness of the technology.

Bob Kraft (CCAT)