Date: 1 February 1988, 11:44:12 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: texts wanted (19 lines)
--------------------------------------------
From Mark Olsen <ATMKO@ASUACAD>
before we scan and keyboard some texts by walter pater, does
anyone have or know of the following texts on disk: *marius the
epicurian* and *gaston de la tour*. i am not sure that the
latter exists in print form, so we might have to keyboard it
from mss. any other texts by pater would also be useful.
thanks.
mark
=========================================================================
Date: 1 February 1988, 13:41:31 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: OS/2 (50 lines, and not of code)
--------------------------------------------
From Jack Abercrombie <JACKA@PENNDRLS>
Last week I attended an IBM sponsored course on OS/2, IBM's new
micro operating system. I came away with some personal
observations that I haven't seen in most published descriptions.
First, OS/2 is the IBMer's ultimate answer to microcomputing:
mainframe computing brought to you in a smaller box. For me, the
idea of batching processing in the background while I work in the
foreground interactively is an exciting opportunity that I have
missed since I left the mainframe and the minicomputer worlds for
the micro environs. Nevertheless, I worry that the processor is
too small to handle the multi-tasking. I am also concerned that
most humanist don't need that kind of power. In almost all cases,
they require better peripherals and not a box that can juggle
several tasks at once.
My second observation is that OS/2 will not be as difficult to
teach as some have led us to believe. Most users, I don't think,
will start off using OS/2 fully and will continue to work in the
provided DOS mode. When these users start to move to batch
processing, there is limited knowledge needed to make the machine
work reasonably well. The reason for this is that in the
installation of OS/2 the configuration files sets up the entire
system for a user. As long as the user does not fool with the
default settings, they should be able to work in a batch mode. Of
course, they will not be able to control the hardware as well as
they possible could if they understood how to set speeds of
processing, memory allocation, etc.
My last observation concerns the hardware. It is clear to me that
OS/2 needs and eats memory. To avoid swapping memory to disk
which slows your processing time down and can lead to other nasty
problems, buy OS/2 with more than enough memory especially if you
plan to do more than two or three tasks at a time. Also, I have
strong doubts that OS/2 multi-tasking will work reasonably fast on
low-end machines such as an IBM AT or System 2 (Model 50). I
think that eventually will find that IBM will suggest that if you
really want to do multi-tasking do it on an 80, 90, 100, and other
models to be announced. Of course, you could always use the
mainframe, n'est-ce pas?
=========================================================================
Date: 2 February 1988, 09:03:37 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Ibycus computer users
--------------------------------------------
From Sterling Bjorndahl <BJORNDAS@CLARGRAD>
I would like to get a head count, if I may, as to how many Ibycus
computer users there are reading HUMANIST. I am interested in setting
up an online discussion forum for Ibycus users (especially the
microcomputer version). If we are few enough, and we are all on
BITNET/NETNORTH/EARN, we can set it up very "cheaply" using
CSNEWS@MAINE's CSBB bulletin board utility (to subscribe on CSNEWS you
must send an interactive message - hence the network limitation). The
advantage of CSNEWS is that we won't have to mess with LISTSERV
software :-). I am interested in hearing from all interested parties.
Sterling Bjorndahl
Institute for Antiquity and Christianity
Claremont, CA
BJORNDAS@CLARGRAD.BITNET
=========================================================================
Date: 2 February 1988, 09:07:53 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: OS/2 (45 lines)
--------------------------------------------
From Wayne Tosh <WAYNE@MSUS1>
I found the observations on OS/2 interesting, particularly the
one concerning whether humanists even need multi-tasking, given
the nature of most of their activities (such as word-processing).
On the one hand, such a blanket dismissal is always a bit
troubling. On the other, we do have in my own department a
colleague who is pushing for the purchase of a 286-class machine
to support the multi-tasking environment of Desqview. While I
myself like the idea of popping from one application to another
quickly, I wonder whether most of my colleagues wouldn't rather
have more (cheaper) workstations. They have found the learning
of word-processing (PC-WRITE) a steep enough process that most
are, for the moment, still unwilling to go on to database and
spreadsheet software, for instance. So I wonder whether it isn't
premature to be spending our limited funds on a 286 machine in
order that, as this colleague puts it, "Everyone can have a
chance to sit down and play (sic) with it (Desqview)."
One measure of the prematureness of this proposal is, I think, my
colleagues' unenthusiastic reception of a menuing interface which
I recently put at their disposal. If they feel, as they seem to,
that it is too much to read a few lines of options from which to
choose in order to execute some program or other, then I doubt
that they will take readily to a shell like Desqview and the
juggling of several processes at once.
Are you aware of any discussion on this subject?
Wayne Tosh, Director
Computer Instructional Facilities
English Dept--SCSU
St. Cloud, MN 56301
612-255-3061
WAYNE@MSUS1.bitnet
=========================================================================
Date: 2 February 1988, 09:09:30 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: RE: texts wanted (19 lines)
--------------------------------------------
From Wayne Tosh <WAYNE@MSUS1>
One possible source of further information might be
Mark Emmer
Catspaw, Inc.
P. O. Box 1123
Salida, CO 81201
voice: 303-539-3884
bulletin board: 303-539-4830
ARPA: emmer@arizona.edu
Mark publishes irregularly the newsletter "A SNOBOL's Chance"
and markets his implementation of SNOBOL4+ for the PC, in addition
to Elizabethan texts and the King James Bible on disk.
Wayne Tosh, Director
Computer Instructional Facilities
English Dept--SCSU
St. Cloud, MN 56301
WAYNE@MSUS1
=========================================================================
Date: 2 February 1988, 09:16:21 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Re: OS/2 and multitasking (56 lines)
--------------------------------------------
From Hans Joergen Marker <DDAHM@NEUVM1>
Jack Abercrombie had some comments on OS/2, and although I share his
generally skeptical view on the matter, there is a point in his comment
in which I disagree. It is: "I am also concerned that most humanist(s)
don't need that kind of power. In almost all cases, they require better
peripherals and not a box that can juggle several tasks at once"
This may or may not hold true for most humanists, but it is not true in
the field of history. Many historians may feel that they don't need much
computing power because the software to make use of the increased power is
not available yet. But in order to make the computer an adequate research
tool for the historian, and not just an expanded typewriter/calculator, what
we need is exactly a multitasking software environment. (On the lines
of what Manfred Thaller describes as the historical workstation.) In this
concept calculation of ancient mesure and currency, geographical references
and searches for appropriate quotations are handled by background applications.
Leaving the historian free to take care of his actual job of making history
out of the bit and peaces of information on the past.
I feel that in historical research we often have a problem with making one
person's research useful for the next person doing research in a related
field. Most historians feel that they have to understand for themselves
how the different units of a particular system of mesurement relate to
each other and in that way we all remain on the same level of abstraction.
It is my hope that through the use of software as the means of communicating
the results of research, a qualitatively different way of making historical
research will be made possible.
An example: If I know that the Danish currencies of the early 17th century
relate in a certain way to each other, I provide not only the article with
tables and stuff like that, but also a piece of software that does the actual
conversions.
This approach would naturally be more useful if a general framework existed
in which the different pieces of software fitted in, and combined to an inte-
grated unit: The historical workstation.
Given the existense of a historical workstation future research can take
two major paths, either utilising the tools provided in it for traditional
historical research aims, or refining or expanding the tools provided. In
this concept software development becomes an integrated part of historical
research. The term for this could be "historical informatics".
Hans Joergen Marker
=========================================================================
Date: 2 February 1988, 09:22:36 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: OS/2 (38 lines)
--------------------------------------------
From Sebastian Rahtz <spqr@ibm.soton.ac.uk>
The note on OS/2 was interesting; it seems curious that IBM are
writing a new operating system to do what non-micro users have
had for years. Why should I get excited about OS/2? Because
it will allow me to run MS-DOS programs in batch mode? wow.
Since MS-DOS has at least one root as a cut-down Unix, it seems
perverse to build it up again in a new direction - why not just
use Unix? My regular daily machines are a Sun 3/50, and a Masscomp
5600; both of these have a single chip (68020) doing the work which
provides enough power for me and a number of other people, in the
context of a mature operating system (Unix) which already gives me
a vast selection of tools for my work. If I had any money, a Sun 3/50
of my own would set me back about 5000 pounds, which I dont regard
as a quantum leap above a fully configured PS/2 (such as a model
80 with 8 Mb of memory etc).
Of course this is a trivial point, and IBM aren't going to give up
on OS/2, and it will all be successful, yawn yawn. But lets not kid
ourselves that it adds anything to our desktop facilities; now if you
gave me a machine with half a dozen transputers in, and a language
to let me play with them, there would be an intellectual stimulus
in the challenge of co-ordinating my new friends...
Let me hear praise for OS/2 from someone who has used both that
and a decent Sun workstation, and then I'll start being convinced.
yrs
a dinosaur
=========================================================================
Date: 2 February 1988, 14:00:26 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Text encoding (36 lines)
The following is extracted from a note from Paul Fortier,
who is not a member of HUMANIST, but who suggested that we
might air this on HUMANIST in order to get
reactions. Replies may be sent to Paul at FORTIER@UOFMCC.BITNET
or to me (IDE@VASSAR.BITNET).
-----------------------------------
From: <IDE@VASSAR.BITNET>
It seems to me that the ACH text encoding guidelines should have, parallel to
the printed version, a program version which will run on as many machines as
possible, at least all micros. The user would load this program when she/he
wants to begin inputting a new text, and the program would interrogate the user
on the features of the text: language, genre, author/anon., date, edition used,
and on and on and on, right down to how accents are coded in languages that use
them. I had thought this would be a useful way of encouraging users to have an
explicit header record on text files so that archives could pass them on, etc.
This is rarely suggested in the literature, possibly since most of us old timers
wrote such information with a felt-nib pen on the top of the hollreith cards in
the first box of the file, and never really thought to put it in the text file
when we switched up to better technology.
A second advantage to this approach is that it could also at the same time be
used to fill in tables for filter and markup minimization routines (like
Chesnutt's program for printer-drivers) automatically. That way people who
wanted a five or ten-character code for an 'e' grave accent could have it, and I
could input e`.
=========================================================================
Date: 2 February 1988, 14:04:12 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: OS/2
--------------------------------
From Mark Olsen <ATMKO@ASUACAD>
Jerry Pournelle got it right:
OS/2 -- Yesterday's Software Real Soon Now.
Unfortunately, the MS-DOS-OS/2 kludge is the only serious game in
town for day-to-day IBM micros. Why would anyone want multi-users
on a 286/386 box, anyway? If running applications in the background
is all we really want OS/2 for, then use something like DoubleDOS (which
is being given away for $29.97). OS/2 will win, inspite of it all,
because of those three magic letters: IBM.
Mark
=========================================================================
Date: 2 February 1988, 14:05:02 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: OS/2 (38 lines)
--------------------------------
From Jack Abercrombie <JACKA@PENNDRLS>
Let me clear up a point concerning OS/2. You can only
run MS-DOS applications in the foreground and not in the
background in batch mode. There is a linker system for
converting DOS applications into OS/2 applications. It appears
that the linker works best for "C" programs rather than TURBO
PASCAL though we have yet to try it out since we lack sufficient
memory to run OS/2 on our System 2 machines and IBM AT's.
Another aspect about OS/2 that another reader raised is that
there is insufficient third party software for applications.
I think then you might ask me what we plan to do given this
situation and also the fact that we are going to install a
System 2 (80) on the network for general access to large text
bases from remote locations. Jack, what operating
system do you plan to run? The answer is UNIX! OS/2 is not
there yet and won't be in place for our type of application until
1989. Furthermore, we have a number of SUNs and APOLLOs that
also are UNIX based as well as VAX computers so that the sensible
thing for us over the short-term and perhaps the long-term is
a UNIX operating system. Of course, we are willing to
review this decesion at a later date.
JACK ABERCROMBIE
ASSISTANT DEAN FOR COMPUTING (HUMANITIES)
DIRECTOR OF THE CENTER FOR COMPUTER ANALYSIS OF TEXTS
UNIVERSITY OF PENNSYLVANIA
=========================================================================
Date: 2 February 1988, 14:06:22 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: OS/2. multi-tasking, and all that (49 lines)
--------------------------------
From Jim Cerny <J_CERNY@UNHH>
At the risk of getting somewhat tangential to the interests of most
HUMANIST subscribers, I can't resist making a few observations about
multi-tasking.
I have been using VAX/VMS systems (from 8650 size to VAXstation 2000
size) and a Macintosh for quite a while. As multi-tasking, or the
promise of it, comes to Macs and IBM PCs, I occasionally try to
extrapolate from our VAX/VMS usage to imagine how people will use
multi-tasking on desk-top machines. "Our" covers various kinds of
users. There are myself and the other staff in our Large Systems
Support Group who are relatively expert in VMS usage and who are to
varying degrees involved in VMS system management. There are faculty
users. There are student users. Assorted others.
The big multi-tasking use I see is background printing. Then, for
some users there is the need to run batch jobs. For faculty in the
definitely non-humanist number-crunching areas, there are spells when
long batch jobs get run again and again. For staff involved in system
management there are various periodic (daily, weekly, monthly)
maintenance tasks to run in background.
But overall it is background printing that is needed on the large
machines and which I see as the primary extra task(s) needed on the
desktop machines. When I look long and hard at the most sophisticated
things we do as computer support staff, it is to "spawn" one or more
additional processes to do something while leaving the original
process suspended. That is multi-tasking, but not very demanding. It
is what Switcher has provided on the Macintosh, except (and this is a
big except) for the appropriate memory and process management to keep
one process from straying and clobbering another one.
Conclusion-by-extrapolation: If you have multi-tasking you will use it
at least a little, but for most desktop users I see it as an
incrementally useful capability and not a revolution.
Jim Cerny, University Computing, University of NH.
=========================================================================
Date: 2 February 1988, 16:08:59 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: OS/2 (39 lines)
--------------------------------
From dow@husc6.BITNET (Dominik Wujastyk)
Regarding the OS/2 debate, I am definitely in need of a multitasking
operating system, although I do not think of myself as a particularly
computer-intensive worker. I.e., I mainly process text, not program or
anything.
I use TeX all the time for formatting everything I
write, except letters. While PCTeX on a 12Mhz Compaq port. III is quite
fast, as TeX goes (about the same as a medium loaded Vax), I still have to
twiddle my thumbs while it chugs away. I cut my stuff up into 10--20 page
pieces, which helps a bit, but the TeX processing still seems an intrusive
nuisance when one it concentrating on the ideas IN the text.
Even worse is the fact that I cannot print in bacground mode.
TeX output is put on paper as a graphics image, so on a
matrix printer -- which is what I have at home for drafting
-- it is *very* slow by any normal standards. This wouldn't matter so much
if I could print in the background, but with PC DOS I can't. Some printer
buffers and spoolers can help, and I have used
this route to alleviate the problem to some extent,
but it is still not the answer, because a page of graphics is
a LOT more information than a page of ASCII character codes.
My ideal would be to be able to have a wordprocessor in the forground,
sending text to TeX running as another job, with my previewer putting the
pages up on the screen in another window simultaneously (or as soon as TeX
had finished them). And, of course, background printing. Now THAT would
be cooking!
Dominik
=========================================================================
Date: 3 February 1988, 00:04:51 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: OS/2, Multitasking, and all that (21 lines)
--------------------------------
From ked@garnet.Berkeley.EDU (Charles Faulhaber)
Multitasking
I use a Sun 3/50 and right now have 9 windows open, in five
of which processes are running. I use it primarily as a
writing tool (so far), but have found it immensely useful
to have two files open simultaneously in order to compare
2 versions of a text or to cut and paste from one file to
another or to access my mainframe account while working
on the Sun. I was a reasonably experienced UNIX user, but
I find no comparison between "old" UNIX and a windowing
environment.
=========================================================================
Date: 3 February 1988, 00:11:00 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Dictionaries; OS/2 and restraint (39 lines)
--------------------------------
From goer@sophist.uchicago.edu(Richard Goerwitz)
In NELC at the University of Chicago there are several projects underway that
one might generally call dictionary-making. We have, of course, the Chicago
Assyrian Dictionary, and the Hittite Dictionary. We also have a couple of peo-
ple doing lexical work in related areas.
Not all of this work is exactly state of the art. The CAD has been done mostly
without any electronic help. The Hittite Dictionary is being done with TRS-80
machines. Others are using dBase on MS-DOS machines.
I am wondering whether there are any established approaches one can use to
text-base construction. dBase is not exactly a linguist's dream. Are there
better approaches available, either in theory or "off the shelf"?
Let me add a parting word about another topic: OS/2. I'd hate to see the dis-
cussion get too out of hand until we know what we are talking about. After all
not too may folks have seen OS/2 yet. And even fewer have gotten to play with
it. As for speculation about whether the majority of scholars will want to
work in a multitasking environment, I don't think there's much way of knowing.
We just don't have software that is built to take advantage of it in a way
that will attract scholars in the humanities in large numbers. Restraint!!
-Richard
=========================================================================
Date: 3 February 1988, 00:13:35 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Printing in the background
----------------------------
From goer@sophist.uchicago.edu(Richard Goerwitz)
In response to grumblings about not being able to "print in the background,"
let me point out that in MS/PC-DOS, printing is inherently multitasking. You
can run the DOS print command in the background. If you have a word-proces-
sor that doesn't print in the background, print to disc (most wp's have this
feature). Then print the file using this DOS print command. A good print
spooler will speed this process up a lot. (A print spooler is a program that
intercepts DOS printer interrupts, sending the file being printed into RAM
memory, where it waits for opportune moments to be fed out to the printer.
A good spooler will work fast, but yet shut down quickly when the user demands
computer processing time. Good examples of MS-DOS spoolers include the PD
programs MSPOOL and SPOOL.)
If background down/uploads are needed, use Mirror, a Crosstalk clone that does
background work like this.
If more serious background work is necessary, use a program called Double
Dos. As one recent poster pointed out, it can be had for under $30.
-Richard
=========================================================================
Date: 3 February 1988, 00:16:05 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Deadline for the ACH Newsletter is soon! (22 lines)
Vicky Walsh, editor of the Newsletter of the Association for Computing
in the Humanities, reminds me that the deadline for submitting material
to be considered for the next issue is 19 February. Any member of the
ACH -- one of our major sponsors -- is welcome to submit material for
the Newsletter. As difficult as it may be to believe, some computing
humanists cannot be reached by electronic mail, indeed, some even
actively refuse to become connected. So, the ACH Newsletter does reach
people whom you cannot contact through HUMANIST.
Vicky can be reached by e-mail; she is imd7vaw@uclamvs.bitnet.
Yours, Willard McCarty
=========================================================================
Date: 3 February 1988, 09:02:25 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Multitasking (41 lines)
----------------------------
From Sebastian Rahtz <spqr@CM.SOTON.AC.UK>
I find the claim that all the average person wants multi-tasking for
is background printing incredible! Like Charles Faulhaber, I often have
half a dozen windows open when I am using a Sun, and all I am doing
is writing something, like him. Is it so difficult to imagine how
I can have one window for my mail (brooding on what to reply), one
for playing Mazewar, one for editing my file, one for running it through
LaTeX, another for previewing, another for a database process thats getting
some data I want? I do not know about you people and your computers,
but they are my no means fast enough for me - I often want to start a new
job while the computer is tediously processing another. If we take a reasonable
job of editing a book, it took me about 40 minutes on a Sun 3 to process from
scratch the whole of a conference proceedings I just finished (3
passes through LaTeX and 1 through BibTeX - dont tell me to use a
silly Mac, I have my standards..); what am I supposed to do while this
burbles away? read a book? no, i want to write a letter, edit a
chapter thats just been processed, run a program etc; i WANT
multi-tasking.
I suspect that those who think of multi-tasking as 'batch processing'
haven't used a proper windowing system...
or to be more 'academic', lets take a project being worked on here, a
archaeological database that extracts details of pots and sends an
image of each in PostScript to a NeWS process; if we did this
normally, the database would suspend, draw a picture and then resume;
with each pot in a separate window, i can play with the generated
images while the database is working, and I can keep a number of
images on my desk.
Sebastian Rahtz
=========================================================================
Date: 3 February 1988, 09:04:22 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Paul Fortier's sensible remarks about textual encoding (21 ll.)
----------------------------
From Grace Logan <LOGAN@VAX.OXFORD.AC.UK>
Paul Fortier says such sensible things! I would just like to
enthusiastically support his suggestions, especially the part
about header information being easily (or even automatically)
entered.
I have been in computing long enough to have gone back to texts
as much as ten years later and I fervently wish that Paul's
recommendations had been in force when they were input. Having
the kind of information Paul talks about at the top of every
file would have saved me so much time!
=========================================================================
Date: 3 February 1988, 09:07:38 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Multitasking and all that (16 lines)
This is really a rather interesting discussion. I recall something that
Gaston Bachelard says in _The Psychoanalysis of Fire_, that "Man is a
creature of desire, not of need." Let us not ever put shackles on our
imagination, especially not here!
Willard McCarty, mccarty@utorepas
=========================================================================
Date: 3 February 1988, 20:14:07 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Multitasking according to IBM (20 lines)
----------------------------
From Jack Abercrombie <JACKA@PENNDRLS>
Just a quick note on IBM's concept of multi-tasking.
What was discussed in the seminar I attended was not
having multiple windows open at the same time though they
made it clear that that is a direction IBM hopes to move
in with the release of the Presentation Manager at the
end of 1988. No. They presented a mainframe batch
processor, and not a true windows environment.
JACK ABERCROMBIE
=========================================================================
Date: 3 February 1988, 20:16:22 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Fortier-style texts (19 lines)
----------------------------
From Sebastian Rahtz <spqr@CM.SOTON.AC.UK>
It seems obviously sensible that texts should have a "Fortier heading"
explaining what they are about, but I dont really think a specific program
for adding this stuff is really a very good idea. Surely you
text-encoding standard gurus have dealt with the idea of the format of
a text header, however it is created? If not, shame on you...
sebastian rahtz
=========================================================================
Date: 3 February 1988, 20:17:59 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Data headers and SGML (not too vehement) (41 lines)
----------------------------
From David Durand <DURAND@BRANDEIS>
There has already been a lot of discussion of SGML on this list which
does not have to be re-opened. However, it is worth noting that a document type
definition or SGML prologue is detailed documentation of a file
format, with the additional advantage that one is required to use
mnemonic names to indicate the special information in the text. That
is not to say that an SGML prologue gives you all the information you
might want, just that it gives much that is essential, and requires (hopefully)
meaningful names for all indicated information.
Some other points are worth noting: the creation of the structure
definitions for a file provides a very useful discipline to control the
consistency of entered data, despite its time consuming creation and seeming
obstruction of the straightforward process of data entry. I think that in
some ways the SGML debate is like the programming community's debate over
structured programming. It all seems like such a bother, in part because it
is an attempt to reduce the total effort of all users of the data at
the expense of some extra effort on the part of the preparers.
Finally, it is worth remembering that SGML is optimized for interchange,
and that fairly simple tools can be used to convert to and from SGML and
special purpose formats to allow more efficient searching or data retrieval
or scansion or whatever.
Well, a simple comment about format headers has turned into a small rant
on the virtues of standard markup. In closing I'd like to say that I don't
necessarily think that SGML is perfect, just that it has addressed the
right questions in the right KIND of way. Certainly, it could have been ten
times simpler and still done the job.
=========================================================================
Date: 3 February 1988, 20:26:26 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Multitasking and windows (36 lines)
----------------------------
From Sebastian Rahtz <spqr@CM.SOTON.AC.UK>
I used to play with Microsoft Windows; apart from the speed etc,
we can assume (I hope) that OS/2 will not *look* that different.
What was wrong with it was not that it was cripplingly slow, but that
the area of the screen you could carve into windows was too small.
The 25 x 79 screens on our PCs are TOO SMALL to work well on. Bring
on at least A4 size screens if not bigger.... theres no point in
saying this mind, its like asking for a better keyboard.
Do any punters in HUMANIST-land have an extended edition OS/2 with
the micro-DB2 grafted underneath? Does it exist yet? Now there IS an
interesting development, if it works as it might, with references
to data being passed through a relational database manager instead
of sequential file access. Somewhere recently I read an interview
Laurence Rowe (of INGRES fame) who saw the future as a hypercard
interface to INGRES; I like this - lets stop seeing our hard disks
as collections of named files, but see it as giant relational
database reflecting the relationships of all the data we possess.
Our applications need then only pass on an abstract, file independent,
query to the OS, and get back an answer. hoorah, high-level
coding rules OK. I expect Bill Gates and his boys thought of all
this ages ago.
Does anyone have experience with Microsoft Bookshelf?
sebastian rahtz
=========================================================================
Date: 3 February 1988, 20:30:31 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Contributions to the ACH Newsletter (20 lines)
Good news: Nancy Ide tells me that contributors to the ACH Newsletter
don't have to be members of that organization. So, if you've got
something to say to North American computing humanists, or something to
ask them, the Newsletter is also open to you, even if (God forbid) you
are not a member of the ACH.
Again, the editor is Vicky Walsh, her address imd7vaw@uclamvs.bitnet,
the deadline for the next issue 19 February.
Yours, Willard McCarty
=========================================================================
Date: 3 February 1988, 20:45:39 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Printing in the background (24 lines)
----------------------------
From dow@husc6.BITNET (Dominik Wujastyk)
Richard Goerwitz didn't take the point about background printing of graphics
data. The DOS PRINT.COM only works with a stream of plain ASCII characters,
not graphics data. The other solutions he mentions, e.g. DoubleDos, may
well work, although all the "simple" multitasking efforts on the market
that I have tried all had some fatal flaw. Background spooling can work,
as I said, but for more that a very small amount of graphics data a PC will
run out of memory very quickly. A test file of the words "this is a test"
ended up a file of 991 bytes, to give an concrete example. This is, of
course, for a printer that does not support downloaded fonts, so the whole
bitmap for every character is there.
Dominik Wujastyk
=========================================================================
Date: 4 February 1988, 16:38:01 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: 9 windows at once (18 lines)
----------------------------
From Ronnie de Sousa <SOUSA@UTOREPAS>
Re Cha Faulhaber's nine windows open at once:
if you are just writing, you don't need OS/2 for that. All you need
is a decent scholar-oriented word processor like NOTA BENE, in which you can
also open nine files at once, and even automatically compare the
two (finding next point of discrepancy and then next point of agreement.)
...Ronnie de Sousa, Toronto
=========================================================================
Date: 4 February 1988, 16:43:48 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Looking for Adam Smith on-line (21 lines)
----------------------------
From Malcolm Brown <mbb@jessica.Stanford.EDU>
Does anyone have either "Theory of Moral Sentiments" or "Wealth of
Nations" by Adam Smith on-line and available?
If so, please send a note to me (GX.MBB@STANFORD.BITNET)
thanks!
Malcolm Brown
Stanford University
=========================================================================
Date: 4 February 1988, 17:07:51 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: OS/2, multitasking, multiple windows, and more (31 lines)
Last month we had a discussion about some of our needs for software. Now
we seem to be having another about hardware. We all know how silly and
moronic the ruling things of the present tend to be, being nevertheless
very useful, but what about the future? What gizmos would we as
humanists like to have? Perhaps our collective influence is usually
minuscule, but I suspect that if we imagine well, what we imagine may
stir someone with the means.
Multitasking would appear to be one thing we want, with a multitude of
windows, and not just for wordprocessing. Diverging back to software,
perhaps the problem of small screens can be solved by having "rooms" as
well as "windows." (Who has heard of the work being done at PARC on
"rooms"? Would one of our members there like to report on this?) Who has
had experience with current multitasking shells, e.g., DESQVIEW,
MicroSoft Windows? Does this experience suggest anything about future
systems?
What else?
Willard McCarty
mccarty@utorepas.bitnet
=========================================================================
Date: 5 February 1988, 09:07:16 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Headings for documents (25 lines)
----------------------------
From amsler@flash.bellcore.com (Robert Amsler)
Sebastian Rahtz expressed my sentiment exactly. There already exist
plenty of programs in which you can create this header information, they
are called `text editors'. The problem is there doesn't (yet) exist
any statement of what the lines of such text should contain. Rather than
a hopeless quest to write software for every PC on the market, it would
be more sensible to describe what the attributes should be for
a machine-readable text to be acceptable. I really think the archives
have some obligations here to nag their contributors to provide this
information since if they don't get it, then it will result in multiple
recipients of the archives data having to do without it or individually
nag the originating author-----or maybe that is a good idea. Maybe we
should gather together the names of all the people who created undocumented
machine-readable text and ALL send them letters asking for the information.
=========================================================================
Date: 5 February 1988, 09:13:27 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: OS/2 and the Mac
----------------------------
From elli%ikaros@husc6.BITNET (Elli Mylonas)
All the discussion on OS/2 centers around comparisons of this operating
system with mainframes and other higher-end machines. Background processing
and a semblance of multitasking are available NOW on the Macintosh,
using the Multifinder system (version 4.2).
It is possible print in the background, or to download files in the
background, while working away at something else in the main window.
It is also possible to have more than one application open at the same
time, although only one is active. I know that this requires more
memory than the average Mac has, but even a memory upgrade costs
less than the machines against which OS/2 is being measured (an extra 1MB for
Mac + -- $175, upgrade to 2.5MB for the SE -- $460).
It is surprising how fast one can come to depend on the multiple window,
multiple application environment that Multifinder offers. Mac users, even
those who are not expert users, start to make use of it immediately, and
without realizing they are doing something fundamentally different.
This is primarily due to the consistency of the Mac user interface, which
consistency Multifinder adheres to.
So, to answer those who say that humanists only do word processing, and
do not need to do 2 things at once, all the humanists who are given the
opportunity to do so make use of it, if it is not hard to learn. After
all, compiling an index or pulling cross references require cpu time, when
the writer just sits and waits. Furthermore, few people do *just* word
processing. They have their references in a database, they may look at
images or maps they have online, and they may be logged in on their local
networked machine reading HUMANIST. Not to mention more mundane chores
like looking up an address in their electronic phonelist, or cleaning
out their files.
I do not want to say that the Mac with Multifinder is the solution to
everyone's computing needs, but it is available now, on an inexpensive
machine. We cannot all have Suns, and we do not all have that kind
of networking, so as to be able to use workstations off a central server.
Elli Mylonas elli@wjh12.harvard.edu
=========================================================================
Date: 5 February 1988, 10:12:29 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: File Documentation (45 lines)
----------------------------
From Bob Kraft <KRAFT@PENNDRLN>
OK, I'm ready to get serious and gather the combined
wisdom of the collected HUMANISTs on what you want by way of
information about a text file. This is timely, because I am
in the final stages of attempting to document the materials
included on the CCAT part of the new PHI/CCAT CD-ROM (see
the OFFLINE 17 list). This documentation will be included with
each disk -- ideally (and in the future), it would be on the
CD-ROM itself, but in this instance it was not yet ready.
In any event, the categories I have used are as follows:
(1) Edition of the text used (if applicable), or background
information about the text; (2) Encoding information -- who
deserves credit for creating the electronic form and/or for
making it available? (3) Coding information -- what special
symbols are used, how are non-English characters represented,
etc. -- often with reference to appended charts; (4) Verification
status -- how well verified is the text (if known)?
(5) Special Notes -- e.g. to whom should questions or corrections
be addressed (where does quality control reside), are there any
special issues to consider in using the text (e.g. restrictions
of any sorts, relation to similar texts, future plans for
revising the format).
I have not thought it necessary to stipulate the size of each
file (some files are anthologies -- e.g. Arabic, Sanskrit --
while others are homogeneous), although that might be useful
information especially for persons who plan to offload material
from the CD-ROM for individual treatment. Are there other
important pieces of information you think should be included
in such documentation? I should look at the format of the
Rutgers Inventory to see whether the librarian's needs are
covered as well. Speak now ....
Bob Kraft for CCAT
=========================================================================
Date: 5 February 1988, 10:24:48 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: SGML editing (23 lines)
----------------------------
From David Nash <nash@cogito.mit.edu>
We are about to draw deep breaths and plunge into converting the
Warlpiri dictionary master files to SGML. We have been inspired to do
this by most of what we know about SGML. Does anyone want to talk us
out of it?
Has anyone experiences to share of SoftQuad's Author/Editor SGML-based
software for the Macintosh? Are there any alternatives on the market?
Less importantly, is ISO 8879 (on SGML) available in machine-readable
form?
-DGN
=========================================================================
Date: 5 February 1988, 10:47:16 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Windows and rooms (36 lines)
----------------------------
From BobKraft <KRAFT@PENNDRLN>
Although I get the feeling that many people don't want to
keep hearing about the IBYCUS SC -- its that special
scholarly micro-workstation that has been working with CD-ROMs
since 1985 (!!), among other things -- you should at least know
that the SC (for "Scholarly Computer") has ten obvious "windows"
(or perhaps better, "rooms") that are accessed through the
number pad keys and can be used to access and work with various
files conveniently. Actually there are more than 10, but
the 10 are obvious. The SC does not "multi-task" in the sense
of being able to run programs in each room at the same time.
Only one program can be actually running, in the foreground or
in the background, but the memory for each of the rooms (to the
limits of available RAM) is readily accessible at a keystroke.
Thus I can write my 9 different articles at the same time while
using window/room 0 to pull materials off the CD-ROM.
Why mention this? Because if we want to discuss what scholars
think they need, and how they might want to use various types
of proposed options, it is good to know what some scholars
have, and to find out how their "needs" and hopes/wants
change once they have what they thought they wanted.
What do the IBYCUS SC users see as the next level of
wants in relation to their windowing/rooming environment?
Bob Kraft, CCAT
=========================================================================
Date: 5 February 1988, 11:46:50 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Windows, multitasking, and programming environments (33 ll.)
----------------------------
From Randall Smith <6500rms@UCSBUXB.BITNET>
I have been experimenting with Windows and XTREE PRO, trying to find
a suitable environment for programming in C. I have not yet been
successful in getting Windows to work smoothly, but it does not seem to
be too slow, though I am running on a 12 MHz clone with a high speed hard
disk. I am expecting version 2.0 shortly, and I hear that it is much faster.
As far as size of screen, I am using one the super EGA cards (the Vega
Deluxe) which gives me a resolution of 752x410. This is *much* better
than the standard resolution and provides much more room to put things on
the screen. My goal is to be able to perform a compilation according to
a make file in one window and do another task or two while that compiling
is continuing. Also, I am trying to get my TLG search software to run in
a window. I know that this will slow it down, but I would rather have it
take ten minutes during which I can use the computer for something else than
five minutes during which the machine is lost to me. I will pass along more
information on this if I can get it to work. Has anyone tried anything like
this with Windows 386 or Desqview? By the way, XTREE PRO with a mouse and
its new editor is not a bad dos manager. I recommend giving it a try. I
will be happy to provide a Logitech mouse driver for it if anyone is
interested.
Randall Smith
=========================================================================
Date: 5 February 1988, 20:56:37 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: multi-tasking (18 lines)
----------------------------
From Wayne Tosh <WAYNE@MSUS1>
>
> Rahtz makes some very good points concerning multi-tasking and
> multiple windows as he is able to realize them on his Sun
> workstation. Would that we all had NOW such a large-screen
> environment! My objection is to colleagues who want to spend
> limited (English department) funds on small-screen 286-based
> machines--who wants to do multitasking while peering through a
> keyhole?
=========================================================================
Date: 5 February 1988, 21:03:30 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Tennessee Williams' plays on-line? (17 lines)
----------------------------
From Rosanne Potter <POTTER@VAX.OXFORD.AC.UK>
Does anyone have copies of The Glass Menagerie, A Streetcar Named
Desire and/or Cat on a Hot Tin Roof on-line? or know of their
existence in an archive?
Please respond to me at POTTER@UK.AC.OXFORD.VAX
[for those outside JANET that's potter@vax.oxford.ac.uk -- W.M.]
Thanks.
=========================================================================
Date: 5 February 1988, 21:07:31 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: documenting texts (26 lines)
----------------------------
From Lou Burnard <LOU@VAX.OXFORD.AC.UK>
Just before Xmas I sent an enquiry to Humanist, requesting feedback on
just what minimal information people would like to see recorded about texts
in the Oxford Text Archive catalogue. I know the message didnt get lost because
I happened to meet one Humanist in person a week or so later (always an
inexplicable pleasure to see those acronyms fleshed out in a suit) who gave
me his views using that curious old technology known as speech. Alas that
represented exactly 50% of the response rate my enquiry provoked, i.e. I got
one (1) other reply. What I want to know, apart from the answer to my
original query, which Bob Kraft has just posed again, is
(a) is the response rate to queries placed on Humanist always so low?
(b) or was it a boring question?
I had considered mailing an enquiry to all other enquiriers, but forbore!
Lou
=========================================================================
Date: 5 February 1988, 21:14:43 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: SGML for the dictionary
----------------------------
From Nancy Ide <IDE@VASSAR>
I would like to suggest that NASH at MIT consider holding off
on the conversion of the dictionary to SGML. I expect they will
be defining document types and ne tags for this application, and
it may be that the effort will duplicate that of the ACH/ACL/ALLC
Text Encoding Initiative. We will have a very large group at
work on tagging schemes for dictionaries, and while this work
will not be well enough along for at least 18 months to provide
a concrete scheme for actual use, the wait might be worthwhile.
We expect our scheme to be based on or even an extension of SGML
and the AAP implementation of SGML for typesetting, and so
they will get what they need, plus compatibility, without the
trouble of developing the tags on their own.
Nancy Ide
ide@vassar
=========================================================================
Date: 5 February 1988, 21:18:57 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Hardware wars (30 lines)
----------------------------
From David Graham <dgraham@mun.bitnet>
This discussion clearly has the potential to degenerate very quickly into one
of those depressing and unproductive flame wars about hardware that
periodically rage through the Usenet comp.sys.* groups. [As someone recently
wrote there, "Oh no, not another of those 'Your favorite microprocessor is
sh*t' discussions".] Instead of flaming one another's preferences and arguing
about whether or not Multifinder is 'true multitasking' (I can see that one
coming), may I suggest that we listen to Willard McCarty's suggestion to re-
strict the discussion to accounts of actual experience, and resist (insofar as
possible) the temptation to evangelize?
I can't afford a Sun either (I can't even afford a memory upgrade for my Mac),
and it doesn't help matters to have the feeling that HUMANIST's Sun users
are looking down their noses from a great height. One of the reasons I joined
HUMANIST was that I thought we were all in this together, as Humanities people
with an interest in computing, and because I thought that HUMANIST would
provide a forum for some interesting discussions. So far I haven't been
disappointed (though frequently reminded of my ignorance), but if we're going
to waste time and bandwidth flaming each other, I'll stop reading. Am I being
thin-skinned? Is this hopelessly idealistic?
David Graham dgraham@mun.bitnet
=========================================================================
Date: 5 February 1988, 21:21:35 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: PhD exams in Computing and the Humanities? (89 lines)
----------------------------
From Sterling Bjorndahl <BJORNDAS@CLARGRAD>
Here is another twist on the issue of academic credit in the
Humanities for work with computers. Is it academically legitimate for
a PhD student to write one of his or her exams in the general area of
"Computers and blank" where 'blank' is his or her field of study? In
the case I am thinking of, the topic would be something like "Computer
Assisted Research and the Study of the New Testament and Christian
Origins," including early Christian literature and movements. I might
even be willing to broaden it further and include all of the biblical
corpus.
Some arguments pro: One can develop a Forschungsbericht, and in our
field at any rate that seems to be a kind of magic that makes
something a legitimate field of study. Admittedly this history of the
investigation is not that old, but it is at least as old as is
structuralism in the study of this corpus of literature - if not
older! One could do a very nice job, I think, of looking at various
computer-assisted projects, evaluating their methods and results,
identifying diachronic changes as machines and methods became more
sophisticated, and analyzing the difference that the computer made to
each investigation. One could then attempt to generalize about the
role of computers in this area of study, and extrapolate as to how the
role will change in the future.
I must admit that this is the only aspect of such an exam that I can
imagine at this time. We typically have four exams in our field, each
exam being four hours long and consisting of from two to four
questions. Could one write for four hours on such a Forschungs-
bericht? Probably not. But one would probably find that one hour is
insufficient. What else could one write about?
There are also very good arguments against allowing such an exam. The
computer does function, after all, more like a "tool" than a "method,"
and we seldom allow exams in "tools." We would be unlikely to allow
an exam in lexicons, say, or synopses of the Gospels.
Unless: what if the student were planning to do major work, even a
dissertation, in the history of the development of lexicons or
synopses? It might take a lot of convincing for some people to
believe that this was a worthwhile area of study, but one could look
at the types of texts utilized, the priniciples of organization, the
underlying philosophical perspective? I think that a case could be
made for an exam on this.
I have already discussed this question privately with a couple of
people, and Bob Kraft has made the most eloquent statement of the
issues to date. The following paragraphs are from his response to my
question: If we teach graduate level courses in computing and the
biblical studies, and even give examinations in those courses, why is
it not legitimate to allow a doctoral exam in that area?
From Bob Kraft:
> If my category for the computer is that it is a "tool" in some ways
> similar to typewriters, indices, concordances, scrapbooks, cards,
> etc., etc., I resist focusing on it by itself, although I am open to
> the idea of examining the student on the uses of research tools
> (including, but not only, computers). If I see it as an "approach"
> similar to archaeological method, then it would seem to be an
> appropriate subject in itself. In between these two models might fall
> the "library science" model, which encompasses a special set of tools
> in a fieldwork environment. Would I permit a PhD exam on library
> methodology? I would hesitate, despite the fact that there are
> courses, programs, etc.
>
> Yes, we teach graduate level courses in humanistic computing, and
> there are examinations in them. We also have courses in archaeological
> methods. And there are courses and programs in library science. I
> don't think that fact is determinative of what is appropriate to a PhD
> exam. The issue that I need to explicate is why I am not very
> uncomfortable about the archaeology model. Partly because discussion
> of "archaeological method" has developed in a partially
> confrontational context vis-a-vis "historical-philological method," in
> a way that clearly required exposure of assumptions, justifications
> for valuation of certain types of evidence, etc. It involves more than
> knowledge of how to use a tool or set of tools efficiently (although
> this "more" is not necessarily inherent in the category!). I'm not
> sure that, in isolation, a similar case can be made for "computer
> methodology," but I am open to being persuaded.
Finally, I wonder if this would be a non-issue if this were an
information science PhD rather than a New Testament/Christian Origins
PhD? Someone studying computers _per se_ could very well be able to
examine their application in a particular field of the humanities.
Does this make a difference? Am I really asking a cross-disciplinary
question?
Sterling Bjornahl
=========================================================================
Date: 5 February 1988, 21:25:58 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: SGML standard document: ref. and ordering info. (22 lines)
----------------------------
From David Durand <DURAND@BRANDEIS>
In response to number of requests, here is the reference for the SGML
standard document:
American National Standards Institute. "Information Processing --
Text and Office Systems -- Standard Generalized Markup Language (SGML)"
ISO 8879-1986, ANSI, New York, 1986.
I called them in New York (at: (212)-354-3300) and got the following
ordering information:
It is very important that you mention that you want document number
ISO 8879-1986. Apparently the name may not be sufficient.
$58.00 --
+ 6.00 shipping and Handling
Mail to:
ANSI
Attn: Sales Department.
1430 Broadway
New York, NY 10018
=========================================================================
Date: 5 February 1988, 21:49:45 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Public-domain UNIX relational database program? (41 lines)
A colleague in Toronto, Frank Davey (English, York), is looking for a
relational database program in the public domain. Any suggestions would
be very welcome. In the following he describes the intended application.
Willard McCarty
----------------------------------
From Frank Davey <virgil@yuyetti.bitnet>
We are looking for a programme that will let us compile bibliographic
entries for searches that will be useful for research into the
history of Canadian publishing as an institution. We'd like to be
able to search for combinations of key fields, to answer questions
such as between 1900 and 1914, what publishers published fiction
by women, or between 1860 and 1900, what cities were the places
of publication for 1st books of poetry. On the other hand, we don't
want necessarily to have to establish in advance the sorts of questions
we want to be able to ask, and we'd like to be able to add fields
(such as which book -- first, second, etc. -- an item represents in
a writer's career) if we hadn't thought of it first time around. That
feature would be particularly useful if a graduate student wanted
to modify the database slightly so that it could answer a new set
of research questions. My understanding is that a relational database
would allow one to do exactly this, as well as allow an immense
variety of utterly different projects.
A useful feature of the Empress database programme is that it can
be output through the Standard Generalized Markup codes that Softquad
is developing for Apple (I think that Mac programme is called
Author/Editor).
From Frank Davey <virgil@yuyetti.bitnet>
=========================================================================
Date: 6 February 1988, 16:12:46 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: mark-up (37 lines)
----------------------------
From Mark Olsen <ATMKO@ASUACAD>
Other than a minimal amount of textual identification -- titles,
editions, etc. -- coding of texts will depend on the applications
and intentions of the collector. Rather than impose a SGML or some
such thing why not have a header that clearly identifies each
element of codes being used. I have several texts from the Oxford
Archive that have extensive codes with no explanation of what they
mean or how they were determined. This could be appended to the data
file as part of the contributed text. I suspect that we gather
text for the immediate application at hand -- I know I work that
way -- without realizing that someone 20 years later needs some
footprint to follow the trail. The general rule might be that if
the character did NOT appear in the original printed edition or
mss, then it is a code that must be defined. That defintion should
form the bulk of a header.
The poor response rate from HUMANISTS recently lamented by Lou Burnard
and Bob Kraft might be due to the nature of e-mail. If I can't
fire off a quick response, I file the note, to be lost forever in
an ever growing HUMANIST NOTEBOOK. Stored there, out of the way,
they do not form an annoying pile which threatens to overwhelm my
desk. Free from the threat of avalanche, I can forget the with
the good faith that I will get to it "real soon now." With a
clear desk and a clean conscience, I continue on my way, safe
in the knowledge that "out of sight is truly out of mind."
Mark
=========================================================================
Date: 6 February 1988, 16:13:45 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Document Characteristics (63 lines)
----------------------------
From amsler@flash.bellcore.com (Robert Amsler)
Minimally the description should make it possible to identify exactly
what material was used as the source of keyboarded data such that
someone else will be able to find another (or, if the source was
unique, the specific) copy of the source to recheck the input for
accuracy.
Thus, the first goal is ``How can I tell someone where to check my
data against the original from which it was made''.
The next goal is to describe those attributes which will enable
someone to appreciate how the data was captured. To describe the
methods by which it was put down in the computer. Specifically, what
transliterations were used; what aspects of the original were not
captured (e.g. original hyphenation, orginal page boundaries, etc.);
whether data is as-is or has been corrected in some way for possible
abberations in the original (e.g. black smudge in printing obscured
letters here, but context implies it said ...; misspelling or
incorrect numbers corrected by (a) checking with dictionary or (b)
through incorporating errata notes from material into the copy,
etc.); method by which disjoint parts of materials were entered (e.g.
footnotes entered all in special footnote file, or entered at point
at which footnote number appeared in text; or entered at bottoms of
each page, etc.; physical arrangement of text which was captured vs.
which were not--i.e. how is the blank space in the original document
being dealt with (a problem here is that original text with variable
width letters must be distorted in some fashion to be keyboarded on
computers with only fixed-width character displays). What is being
done to represent different fonts (both fontsize and
italic/bold/small-caps/Roman, etc.)
Thus, the goal here is to answer the question ``How can I tell
someone what steps to follow once they find the original source
material to result in an exact matching copy of this machine-readable
file should they also accurately type it in''
A sub-part of this last answer should include how to distinguish the
original source material from any contributions of the data enterer,
that is--if the data enterer created what business folks are fond of
calling ``added value'' by further clarifying the text in some way
(e.g. adding line/verse/chapter/etc. numbers; adding definitions from
another work; providing translations of foreign quotes, or even
interpreting the meaning, etc. of the material--this added value
should be capable of being distinguished from the original such that
the original text and the added material could be separated again.)
Added value sources, where such exist, should also be identified
as in the first step, and where needed, their method of capture
itself should be described as in the second step (this forming a
type of recursion that hopefully finishes).
=========================================================================
Date: 6 February 1988, 16:16:25 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Ph.D. in humanities computing (29 lines)
----------------------------
From Norman Zacour <ZACOUR@UTOREPAS>
Given what I have seen so far, I daresay that someone will soon ask to
do a Ph.D on the use of computers in medieval historical research. Why
should I find such an idea uncomfortable? We teach medieval history; we
teach a great deal about computers; we want our medievalists to apply
the use of computers to their scholarship as much as possible; and
finally, such a study might be quite interesting in itself. But is it
worth a Ph.D? Does any interesting book describing the work of
academics warrant the doctorate? I suspect that I find all this
problematical precisely because I think of the doctorate as a
disciplinary qualification, and while I am used to disciplines such as
computer science and medieval history, there is no point in pretending
that the question of historians' using computers is in itself a
disciplinary qualification. It's a great idea, and I hope that we will
soon have some good works on the manner in which computers have
stimulated scholarship and modified techniques of study and research.
This is the kind of thing that practictioners write, not students. But
on the other hand, when I see what we accept now...
Norman Zacour@Utorepas
=========================================================================
Date: 6 February 1988, 16:33:08 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: A colloque (78 lines)
----------------------------
From Robert Gauthier <GAUTHIER@FRTOU71>
This year,from July .7th to July . 13th, the theme of the Colloque
international d'Albi, in the south of France
will be Pictures and Texts. Workshops on visual semiotics( French B.
D.,films,posters...)and textual analysis will be scheduled in the
morning and early afternoon. A daily conference will take place in the
late afternoon. The trend of the whole colloque will be to link formal
analysis with either current ideologies and axiologies or psychic human
traits. Didactical aspects will not be neglected and the inter-
disciplinary approach will be sustained by the participation of
semioticians, psychologists, linguists, philosophers , sociologists and
communication experts. Among others, world-known specialists like
Courtes J., Ducrot O...have announced their participation. FRTOU71
Le Colloque d'Albi se propose de mettre l'accent sur l'etude de l'image,
et par dela, de l'imaginaire. Etant donne l'importance croissante du
visuel - dans notre vecu individuel et social - il convient de
s'interroger sur son fonctionnement et sur sa fonction dans notre
univers socio-culturel. Meme si aucune parole ne l'accompagne l'image
est un texte a lire dont la signification est fonction de regles
particulieres. Comme texte l'image est evidemment le support de valeurs
: elle n'est jamais que pretexte a une axiologie determinee ; elle vise
a convaincre au dela de ce qu'elle represente. Inversement le texte se
presente souvent de maniere imagee au point de produire un effet de sens
"realite". Nous voici alors au point de depart de l'imaginaire, de
l'onirique : inventivite sans fin des images, avec ou sans paroles.
Notre objectif sera de proposer des strategies pedagogiques utilisables
a l'ecole et au lycee, issues de la confrontation entre les theories
scientifiques et les demarches pratiques des enseignants. On s'appuiera
sur l'etude linguistique et litteraire de textes (poemes, nouvelles,
textes administratifs, etcI), de messages audio-visuels (productions
cinematographiques, publicitaires, illustrations, bandes dessinees,
etcI) de maniere a construire des systemes de valeurs tels qu'ils
peuvent se degager par l'analyse semantique. Le theme choisi permettra
un travail de collaboration entre linguistes, litteraires, philosophes,
historiens, sociologues et specialistes de la communication.
Dans des ateliers on analysera le texte et l'image, on etudiera
notamment "le personnage" dans le recit comme lieu d'investissement
(valeurs, ideologies, fantasmatiqueI). On s'interrogera sur les
rapports entre l'environnement culturel actuel et les pre-requis exiges
pour la comprehension des textes. Dans le but d'aider les eleves a
preparer l'epreuve du baccalaureat, on reflechira au theme en question
dans le cadre de l'exercice dit de "groupement de texte", a partir de
l'exemple des descriptions litteraires ; etcI En resume, le but
poursuivi est de degager des outils d'analyse a la fois pour le texte et
pour l'image.
Les specialistes de l'image pourront utiliser les ressources offertes
par le Musee TOULOUSE-LAUTRE d'Albi et ses expositions temporaires.
Participation Form to be sent to: G. MAURAN 19 rue du Col du Puymorens
31240 L'UNION France NAME....................................
................. Fees : 300F (students : 100F)
ADDRESS................................. ............. Fees+lunch:
550F/350 PROFESSION.............................. ............
Fees+1/2 Board: 900/700 TEL.....................................
.................... " + Full Board:1150F/950
Rooms in Guest House 12 rue de la Republique -ALBI Guests may arrive on
Wednesday from 6 p.m. You will be met at the station Time of
arrival................................. Do you want reduced
train-fare.................
Children holiday-center: lunch and tea : 300
....................................
=========================================================================
Date: 6 February 1988, 16:39:41 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Preparing electronic manuscripts (28 lines)
----------------------------
From Tom Benson 814-238-5277 <T3B@PSUVM>
This is a question about manuscript presention and text
editing/formatting, rather than about research per se. As such,
it may be too elementary for this list, and if so, my apologies.
I am preparing a book-length manuscript for a publisher who has
asked that it be prepared in machine-readable form according to the
markup system of the University of Chicago Press's GUIDE TO
PREPARING ELECTRONIC MANUSCRIPTS. The explanation of what the
text should look like is straightforward enough, but it results, if
I understand it, in a situation where the only text that can be
printed out is a marked-up one--which is clumsy to read, at the
very least.
Is there a reasonable way to prepare such a text so that one would
have a form marked up as the Press advises and at the same time a
"normal" looking text for reading, reviewing, and revising? The
two manuscript preparation systems to which I have easiest access
are XEDIT and SCRIPT on the university's mainframe VM/CMS system,
and DW4 on an IBM PC.
If anyone out there has experience working with the Chicago format,
I'd be grateful for suggestions--including the suggestion that I should
just go ahead and do it their way and not worry about having "normal"
looking output at any stage before the final printed book.
Tom Benson
Penn State University
T3B@PSUVM
=========================================================================
Date: 6 February 1988, 23:08:16 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Who uses CD-ROMs?
----------------------------
From David Nash <nash@cogito.mit.edu>
Beryl T. Atkins (Collins Publishers, 11 South Street, Lewes, Sussex,
England BN7 2BT) cannot receive HUMANIST at the moment, and would like
to ask you all a question:
"What I want to ask them is: how many of them
actually use CD ROMs in their daily work & research? [Collins] are
hesitating about CD ROM publication of concordances because they don't
believe enough people use CD ROMs. And they say, rightly, that one CD
ROM drive in the University library isn't going to make people in
departments buy their own research material."
I would prefer that you reply to MCCARTY@UTOREPAS.bitnet rather than me
directly, but either way I'll amalgamate replies and pass them on to
Atkins.
-DGN
=========================================================================
Date: 6 February 1988, 23:10:07 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: SGML and word processors (29 lines)
----------------------------
From goer@sophist.uchicago.edu(Richard Goerwitz)
It shouldn't be too hard to get just about any word processor to output SGML
or U of Chicago or whatever marked text, as long as one is willing to create
an appropriate printer table. Nota Bene printer tables are pretty easy to cus-
tomize. In fact, I've customized my NB 2.0 so that it outputs Hebrew, Greek,
and Syriac - which turned out to be an easier job than I had anticipated. I
would assume that any major word-processor would be sufficiently customizable
that one could have it output SGML markers rather than printer codes.
Really, though, shouldn't the makers of major academic word processors create
SGML, UofC, and other appropriate tables for us?
Or is such a suggestion a bit premature?
Richard Goerwitz
=========================================================================
Date: 6 February 1988, 23:11:51 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Re: Preparing electronic mss. (28 lines)
----------------------------
From dow@husc6.BITNET (Dominik Wujastyk)
I have recently changed to XyWrite II plus precisely because the underlying
text file is very close indeed in format to the type of markup that the Chicago
guide recommends. At the interface level, XyWrite is as polished as any
major word processor. Footnotes are hidden, underlining and bold show as
such on the screen, etc, etc. It is also fast and programmable.
Dominik
=========================================================================
Date: 6 February 1988, 23:17:56 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Re: Preparing electronic mss. (51 lines)
----------------------------
From Allen H. Renear <ALLEN@BROWNVM>
Tom, you should not let your publisher bully you into text processing
practices with which you are uncomfortable or which do not support you as
an author. Many of us have argued in many places for the AAP/SGML style
tags presented the Chicago Guide -- but the last thing such tags should be
is a burden on the author. Descriptive markup is a fundamentally correct
approach to text processing: it should simplify and enhance *all* aspects
of scholarly writing and publishing.
First, talk to your publisher about exactly how they plan to process your
tagged manuscript. It may turn out that they only want to get a plain
ascii file with as much descriptive markup as possible. In that case you
should be able to use Script GML. This will allow you to get nicely formatted
copy for proofing and good support from your computer center.
I suspect this is the situation. I always demand descriptive markup for
typesetting projects -- but it makes less difference to me whether the tags are
GML, Scribe, troff -ms, TEX, AAP or homegrown, as long as they describe the
editorial objects of the document rather than specify formatting procedures.
But if your publisher says that they really must have the tags described
in the Chicago Guide you still have several options available. For instance,
you can define Script macros that parallel the Chicago Guide tags, have each
one end in a ">", and then use Script's ".dc" command to change the control
word indicator to "<". Presto, your source file will have Chicago's AAP/SGML
style tags and yet can be formatted by the Script formatter. You should have
your Computer Center help you with this; it's their job. (I'm assuming your
Script is Waterloo Script).
In any case you will be using a general editor (Xedit) to prepare the files.
This leaves something to be desired of course, but that's where we are today.
For the direction in which text processing should be moving look at Softquad's
Author/Editor. This is an AAP/SGML based editor for the Mac.
I thought this much of my reply to Tom would be of general interest to the
list. Anyone who wants further details should contact me directly.
Allen Renear
Computing and Information Services
Brown University
Bitnet: ALLEN@BROWNVM
=========================================================================
Date: 7 February 1988, 14:41:41 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Use of CD-ROMs
Beryl Atkins has asked,
"how many of them
actually use CD ROMs in their daily work & research? [Collins] are
hesitating about CD ROM publication of concordances because they don't
believe enough people use CD ROMs. And they say, rightly, that one CD
ROM drive in the University library isn't going to make people in
departments buy their own research material."
From our point of view as researchers, I suspect that we almost
unanimously want Collins and others to produce the CD-ROMs
despite the fact that very few now use the technology "daily", so that we
can make up our minds whether or not to buy the readers and disks. After
all, our private and departmental funds are very limited, and few of us
will put out the cash unless we can be sure that we'll make significant
use of this technology. Because they earn their living at some peril,
however, the publishers want us to clamour for CD-ROM publishing so that
they can minimize their risks. So, how can we answer Beryl's question?
I suggest that we say (1) what CD-ROMs
we would buy if we already had readers, and (2) what minimum selection
of CD-ROMs would drive us to buy a reader.
This is my list:
(1) desirable CD-ROMs
(a) the CCAT/PHI disk (soon available; see OFFLINE 17)
(b) the New OED (when available & depending on software provided)
(c) the TLG (if I didn't already have access to an Ibycus & the TLG
in my office)
(d) the Thesaurus Linguae Latinae (from the PHI), when it becomes
available
(e) a disk of 16th & esp. 17th cent. English lit.
(2) minimum selection
(a) & (e), or better (a), (d) & (e)
None of the above, I'd guess, are likely to be published by Collins, so
this reply may not encourage them. I have great difficulty, however,
imagining what I would use on CD-ROM that I don't use regularly in any
form because it's not available electronically.
Willard McCarty
mccarty@utorepas.bitnet
=========================================================================
Date: 7 February 1988, 19:16:30 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Preparing electronic mss.
----------------------------
From dow@husc6.BITNET (Dominik Wujastyk)
While we are on this subject, I have just been given _Goedel, Escher and Bach_
which was apparently produced by the author himself using a text processor
called TV-Edit. Anyone heard of it?
Dominik
=========================================================================
Date: 7 February 1988, 19:21:47 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROMs (41 lines)
----------------------------
From Norman Zacour <ZACOUR@UTOREPAS>
[The following was sent to me as a private message; I'm submitting
it to HUMANIST with the author's blessing and with a few
very minor changes. -- W.M.]
For what it is worth, I do not use, I have not used in
the past, nor shall I ever use in the future, CD-ROMs.
When libraries have the machinery installed, why bother
duplicating everything at home? I am assuming that
the great advantage to the scholar is the rapidity of access of large
reference works - dictionaries, concordances, and the like. Have you
counted recently the number of such references you consult in a year?
How about 15 for a good guess? Is the expenditure worth it? I have at
my fingertips dozens of language dictionaries, bibles, bible
concordances, and medieval reference works in canon law etc etc that
won't get CD-ROMMED in my lifetime. But the real point is that I won't
get around to consulting most of them in my lifetime either. Beyond
about a dozen helps that I lean on extensively (all of which I have in
my office) I consult other such works only very occasionally.
[Do you know about] the Domesday project,
an extensive project undertaken by the BBC a couple of years ago, now on
CD-ROMs? It [is] quite breathtaking, and as an aid to teaching
school-children about England through the medium of pictures and graphs
it's unbeatable. As an aid to scholarship, it's a bust. Nevertheless,
it is possible that many people will buy CD-ROM machines for their home
for uses other than scholarship (my colleague John Benton, of Cal Tech,
for example - they are wonderful for movies) who would then use them as
aids to scholarship also. How extensive that kind of market would be is
anybody's guess.
=========================================================================
Date: 7 February 1988, 19:30:46 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROM use (22 lines)
----------------------------
From Mark Olsen <ATMKO@ASUACAD>
The Humanities Computing Facility is currently in the process of
purchasing two CD-ROM players in order to experiment with the technology
and access material that comes online in future. The biggest problem
I see is getting university administrations to catch up to the
technology. Budget requests etc. take time. The ASU library has
a dozen laser disc installations running iwth PCs devoted to a couple
of information services. These are not 4.5 inch disks, but that is
only because the services they subsrcibe to have not converted to CD
format. From personal experience, it is almost impossible to get on
these systems during weekdays ... they are very popular.
Mark
=========================================================================
Date: 7 February 1988, 19:35:26 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Who uses CD-ROMs?
----------------------------
From Sterling Bjorndahl <BJORNDAS@CLARGRAD>
I do. The Institute for Antiquity and Christianity has two Ibycus micros
with the TLG texts - and we will get the PHI and CCAT CD's too. I would
say there are a half dozen of us who use the CD regularly, with a few more
occasional users.
Sterling
=========================================================================
Date: 8 February 1988, 08:58:22 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROM use (28 lines)
----------------------------
From Randall Smith <6500rms@UCSBUXB.BITNET>
This is a reply to David Nash's question of behalf of Beryl T.
Atkins concerning CD-ROM use. The Classics Department at
University of California at Santa Barbara has its own CD-ROM
system, and we use it regularly to do text searches on TLG
materials. We also plan to obtain Latin texts on CD as soon as
they are available, and since we have the equipment, we would be
interested in other items, such as journals, book collections,
etc., which might become available on CD's, as long as the price
is reasonable.
Also, several members of the Classics Department have purchased
computers with an eye to purchasing CD units as soon as the
necessary CD's containing Greek and Latin text are available for
home use. As far as we are concerned, there is plenty of
interest in CD's, as long as the price is kept reasonable.
Randall M. Smith
=========================================================================
Date: 8 February 1988, 16:00:17 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROM query (63 lines)
----------------------------
From <CNNMJ@BCVMS> (M.J. CONNOLLY [Slavic/Eastern])
I speak only from the Macintosh world, where the release of two
important products (9 March?) will rapidly change the CD-ROM scene and the
size of the prospective audience: CD-ROM drives and driver software, and
the new version of HyperCard (to handle CD-ROM files currently inaccessible
to version 1.0.1). One reasonably expects the Microsoft Bookshelf to
run in the Macintosh environment then (announcement perhaps also to come
in early March) and also the OED.
Some large corporations, of course, have not waited, and these
produce their own drivers and discs for internal use. Databases like
4th Dimension should have no difficulty with CD-ROM, once the appropriate
driver is in the System folder.
I see a market that will take off very soon. We have been tinkering
with CD-ROM for our new Instructional Development Lab, but await the 'official'
releases and know that there are a number of vendors out there ready to pull
the wraps off once the Apple(<Sony) drives are shipped.
How long will the CD-ROM market last? Beyond CD-ROM we have the
fully defined standard of CD/I from Philips/Sony. CD/I promises better
access of video and partial-screen moving video. Products are already in
preparation for CD/I -- I know of five major ones. Beyond CD/I Philips and
Sony are moving toward an 'ultimate' standard which combines all the best
of CD/ROM and LV (LaserVision, i.e. 'videodisc'). They are also seeking,
against some resistance from the computer hardware manufacturers like Apple,
to integrate the home-entertainment market (at least the 'upscale' end)
with the desktop/PC market -- use the same drive(s) for your audio CDs as you
do for your CD/ROMs, plug in your PC just as you would a tape deck, run
your household with the same machines as you do your 'real' work on.
One promise, which I hope will be kept in all this, is that, beginning
with this year's crop of CD/V players (the newest 'entertainment' product
combining CD-Audio and x minutes of video) there will be a guaranteed
upgrade path, so that a device which 'reads' CD-ROM, LV, CD-Audio, and CD-V
will also (with a plug-in module) be able to handle future formats like CD/I
and CD/??. Therefore one need not expect that CD/I will make CD-ROM obsolete:
each may be better at its own specialization.
I see dictionaries, bible texts, literature series going onto CD-ROM
at an increased rate over the next few years. The availability of the proper
retrieval hardware and software at decent prices will stimulate that market,
and I see the Macintosh area, fairly well footed in US academics, contributing
to the upsurge.
A postscript: In Britain, the faster successors to the BBC Computer
(Acorn's new Archimedes) will also make CD-ROM a far more viable publishing
format. We have been working on adaptations of BBCs Domesday and Eco-discs
to the Macintosh world, and CD-ROM or CD/I seem a better alternative to
the current LV-I. Canada's Jean Talon project may also provide a major
impetus to CD-ROM or a similar format.
To answer the question posed: Academics are not using CD-ROM all that
much right now, but they certainly will be quite soon.
Prof M.J. Connolly
Slavic & Eastern Languages
Boston College / Carney 236
Chestnut Hill MA 02167
( U . S . A .)
<tel:> (617)552-3912 <email:> cnnmj@bcvax3.bitnet
=========================================================================
Date: 8 February 1988, 19:15:32 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: OS/2 (35 lines)
----------------------------
From Dan Church <CHURCHDM@VUCTRVAX>
Given the fact that most of us don't seem to have regular access to
mainframes or advanced workstations, most of the discussion of OS/2 and
multi-tasking along the lines of "I can already do that on my... [Fill in
the blank with the name of your favorite mini or mainframe.]" appears to
me to be beside the major point. Even granted that a Macintosh with enough
memory and MULTIFINDER can already do most of what we would like to be able
to do with OS/2, most of us who use PC's or clones can't afford to junk them
and run out to buy an SE. So what about us? I suggest that we start by
reading the editorial in the latest (January/February 1988) issue of _Turbo
Technix_, the new technical magazine put out by Borland and sent free to
anyone who has purchased a Borland product. The editorial by Jeff Duntemann
entitled "DOS, The Understood" argues that DOS will outlast OS/2 because
a) it can be made to fake most of OS/2's features seamlessly, b) OS/2 was
designed primarily for the 80286, a "dead-end processor", c) a 386 machine
with DOS and programs such as WINDOWS/386 or PC MOS-386 is already everything
OS/2 claims to be, and d) we will never be able to do as much with OS/2 as
with DOS because it is designed around a kernel that is a black box highly
resistant to probing by hackers.
This editorial strikes me as one of the most sensible discussions of the
supposed advantages of OS/2 I've read so far. I would have quoted the whole
thing for you if it hadn't appeared on the same page as the warning that no
part of the magazine may be reproduced without permission. But I'd be willing
to bet that you could get a reprint of it by writing to Borland Communications,
4585 Scotts Valley Drive, Scotts Valley, CA 95066, U.S.A.
=========================================================================
Date: 8 February 1988, 20:07:06 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: documenting texts (36 lines)
----------------------------
From Lou Burnard <LOU@VAX.OXFORD.AC.UK>
1. Mark Olsen rightly complains that the texts he received from the Text
Archive were inadequately documented. Alas, he does not say whether or
not he intends, having (presumably) gone to the trouble of identifying what
all those mysterious tags actually represent, to pass the information
back to us...
2. Such information should (in theory) be available from the depositor
of the text. In this connexion, may I ask what the general feeling is about
publishing names and address of depositors? We have this
information, necessarily, for all A and X category texts, but it is not
in the catalogue so as to save space. Should it be? Should we also indicate
a (possibly many years out of date) contact address for all U category
texts? How do actual or potential depositors feel about this?
How do actual or potential punters feel?
3. I have just finished a document (about 10
pages) which describes in some detail the various english language
dictionaries available from the text archive. Please send a note to
archive@uk.ac.oxford.vax if you would like a copy.
Lou Burnard
Oxford Text Archive
P.S. Sorry Rosanne, we're fresh out of Tennessee Williams.
Would Tom Stoppard do?
=========================================================================
Date: 8 February 1988, 20:09:41 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Dan Brink's tour (18 lines)
----------------------------
From Dan Brink <ATDXB@ASUACAD>
I am planning an eastern tour to check out computer conferencing
systems in early April. NJI, Guelph, UMich are on the tour so
far, and maybe NYIT. Any suggestions of other good places to
try to visit would be appreicated.
*****P L E A S E R E S P O N D T O
Dan Brink
ATDXB@ASUACAD
*****& N O T T O H U M A N I S T
=========================================================================
Date: 8 February 1988, 20:16:44 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Producing GML markup with Xedit (34 lines)
----------------------------
From Michael Sperberg-McQueen <U18189@UICVM>
In addition to the good suggestions of Allen Renear, it should also be
mentioned that Waterloo GML can also be modified in the two ways
salient for Tom Benson's problem: the tags defined by the U of C
style can be defined, as GML tags, and added to the set of GML
tags provided by Waterloo, and (if the publisher thinks it important,
or the author finds it makes the file easier to read) '<' and '>'
can be used as tag delimiters instead of ':' and '.'.
The advantages of adding new GML tags instead of new Script macros are
that you can use existing Waterloo tags and their underlying macros
where appropriate, and you can use GML tags in the middle of a line
instead of only in column 1, which makes it easier to have a clean,
readable input file.
The consultants on your CMS system ought, as Allen Renear suggests, to
help you with the adaptations. They may, however, need to be told to
look at the .GT and .GA control words in the reference manual to see
how to define new GML tags and map them either to existing Script
macros or to ones you and they define, and to change the GML delimiters
with ".DC GML <;.DC MCS >" -- even good Script consultants may not
know these ins and outs of GML.
Michael Sperberg-McQueen, University of Illinois at Chicago
=========================================================================
Date: 8 February 1988, 20:22:25 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROMS & Players (30 lines)
----------------------------
From Dr Abigail Ann Young <YOUNG@UTOREPAS>
Subject: CD-ROMS & Players
My attitude to this is similar, I think, to what Norman Zacour
said earlier. I tend to look on the CD's themselves and the
equipment necessary to use them as something a library, rather
than an individual, would acquire. I use the Thesuarus Linguae
Latinae, and DuCange's Lexicon of Mediaeval Latin, but I don't
own them: the Library has them readily available, and if occasionally
I have to wait for a few minutes because someone else is using
a volume I want to consult, well, it's just not that great a
hardship! I also consult the PG and PL of Migne, and the more
modern critical editions of ancient and mediaeval church
fathers and teachers in the library, except for a few volume(s)
of authors I regularly work with. I can no more imagine
buying a CD-ROM of the TLL for myself than I can imagine buying
the printed TLL for myself, but I think that that sort of thing
ought to be available in the University Library System on CD-ROM
as well as in print: it seems to be the librarians' dream medium,
no matter how many people use it, the "book" can't be hurt!
=========================================================================
Date: 8 February 1988, 20:25:23 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Using CD-ROM for textual research (43 lines)
----------------------------
From Robin C. Cover <ZRCC1001@SMUVM1>
In response to the inquiry of David Nash on the use and popularity of
CD-ROM's, I would suggest (at least) that he find out how many IBYCUS
micro-computers there are in use. Even if used institutionally, they
constitute available drives that could be used with other CD-ROM disks.
Secondly, I would add that our institution has done some market research
concerning the potential popularity of CD-ROM drives *provided that*
tantilizing software and databases were available. It was determined
that CD-ROM is a viable market (we can get OEM prices for close to $400,
and the prices will probably drop). So, we are planning a hypertext
CD-ROM product for biblical studies, the first version of which is due
(maybe) late this year.
In response to Norman Zacour, who says he will never buy a personal
CD-ROM unit, and could not really conceive of its use: would you be
seduced if we could provide you with original biblical texts linked by
hot-key to the major lexica, grammars (etc) together with programs to do
interactive concording on the texts, and searching (grep/Boolean) of
these texts to boot?
Finally, the only dark cloud I see with respect to CD-ROM is the advent
of read/write optical-magnetic disk, which already is available. It has
30 millisecond disk access time, which is a considerable improvement
over the 500 millisecond time of CD-ROM, and hinders performance. If
these drives drop to within the $1000 range during the next year or so,
I think many of us would want to support this medium rather than CD-ROM;
the removable (90 megabyte, 650 megabyte) disks would be optimal for our
other storage problems as well.
Professor Robin C. Cover
ZRCC1001@SMUVM1.bitnet
=========================================================================
Date: 8 February 1988, 20:27:32 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Text encoding initiative (16 lines)
----------------------------
From Sebastian Rahtz <spqr@CM.SOTON.AC.UK>
Nancy Ide's throwaway remark "even an extension of SGML" fills
me with horror. Isnt SGMl complicated enough for you text-encoding
people? Why create something non-standard for humanists, why not go
with the crowd NOW. I say good luck to the dictionary chap that
wanted to use SGML. Much as I hate S*, its not that bad
=========================================================================
Date: 8 February 1988, 20:29:17 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROM and videodisk (26 lines)
----------------------------
From Randall Jones <JONES@BYUADMIN>
Norman Zacour's recent note about the Doomsday Project has prompted me
to offer a clarification concerning a misconception that apparently
exists among some of us. The Doomsday project is N O T on CD-ROM,
rather is is on videodisc, a medium that is similar to CD-ROM only
in that it is optical storage that uses laser technology. Videodisc
stores analog video images and can also store digital information, but
for most applications the video material what is important. There
are digital motion video programs now available, but they are still
quite experimental and very expensive.
Randall Jones
Humanities Research Center
3060 JKHB
Brigham Young University
Provo, Utah 84602
=========================================================================
Date: 8 February 1988, 20:42:03 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: The Sun also rises on HUMANIST (22 lines)
----------------------------
From Sebastian Rahtz <spqr@CM.SOTON.AC.UK>
David Graham feels that Sun users are looking down on him, and urges
us not to start a hardware war on HUMANIST. Yes, I agree! But its not
"evangelizing" to say that multiple tasks in multiple *visible* windows
is an excellent working environment. I don't think our Sun is an
expensive luxury, any more that an Ibycus would be if we could afford
it .....
Why don;t you declare the correspondence on multi-tasking over,
Willard?
Sebastian Rahtz
=========================================================================
Date: 8 February 1988, 20:43:34 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: PhD exams in computing
----------------------------
From Sebastian Rahtz <spqr@CM.SOTON.AC.UK>
I would have thought that the idea of a "computer methodology" was
a non-starter; after all, the virtue of the computer is that it is
a *general purpose* tool. Could the exam subject not be "a
quantitative approach to New Testament studies", making it
comparable to "structuralist", "Marxist" etc approaches? If
quantification is the issue addressed by these NT 'n' computing
courses referred to.
We are about to start an MSc course in Archaeological Computing
here; the punters will do the programming/database/graphics sorts
of things you might expect. I also have a friend whose PhD revolves
around a statistical approach to Roman pottery. I'd hate to defend her
doing a PhD on "programming in archaeology" though.
Sebastian Rahtz
=========================================================================
Date: 8 February 1988, 20:45:07 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Relational database software in the public domain
----------------------------
From Sebastian Rahtz <spqr@CM.SOTON.AC.UK>
I sympathise with the request for a PD database, but, really, you
cannot expect to get EVERYTHING for free! People will recommend
PC-FILE (supposed to be good stuff) for a PC, but wouldn't
it be worth spending a few 100 [pounds,dollars] on a commercial
product with support and a manual, if its going to be used a lot?
Creating SGML-conformant output shouldn't be hard from any
reputable database.
But if you are on a mainframe, what about Famulus77? Its not PD, but its
cheap; its not relational but it would do what you asked for? Lou
Burnard will tell you all about it on request, I am sure.
As an example of a commercial product, PC-Ingres cost us 250 pounds
for a site license. OK, so it may not be appropriate, but for that
kind of money for the whole site, going outside PD isn't impossible.
(That was an academic price, mind you!)
Sebastian Rahtz
=========================================================================
Date: 8 February 1988, 20:46:44 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Texts?
----------------------------
From Mark Olsen <ATMKO@ASUACAD>
I have a request for the Consolatione de philosophiae by Boethius.
The user would be particularly interested in the Loeb edition, (1952?).
Any information on this would be greatly appreciated. If we can
not find it, we might have to scan it. Thanks
Mark
=========================================================================
Date: 8 February 1988, 20:49:40 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: SGML, markup, and texts (106 lines)
----------------------------
From Stephen DeRose <D106GFS@UTARLVM1>
Well, I've been watching HUMANIST with interest for some time, and I
guess it's time to dive in.
First, on the issue of data format and headers: SGML provides the
features I have so far seen requested on HUMANIST. An SGML file is
pure ASCII, and contains text, tags, and entities. Tags are mnemonic
names for parts of the text, marked off by angle brackets (e.g.,
"<p>"for paragaph). Entities name things that can't otherwise be coded
in straight ASCII (perhaps "ℵ"). That's all there need be to
SGML, unless you want to get fancy. A "prolog" in a well-defined
format defines the document's particular tag-set, entities, and any
non-default syntax.
Because it is all printable characters, you don't lose data going
through mailers, dealing with IBM mainframes, etc. Because the tags
are descriptive rather than procedural, you need not encode the
specifics of your word-processor, printer, current style sheet,
display characteristics, etc. etc. A block quote is still a block
quote regardless of any of these factors. Also, because the tags are
mnemonic and pure ASCII, even with *no* word-processor a human can
read an SGML file.
The objections I hear to SGML are usually:
1) "It doesn't have the tags I need." This shows a widespread
misunderstanding of SGML. SGML is not a tag-set at all, but a way of
*specifying* tag-sets, entity-names, and their syntax. A well-known
tag-set called "AAP" (for it is from the American Association of
Publishers) is *one* instance of an SGML-conforming tag-set; but
saying it "is" SGML is like saying that a particular user program "is"
Pascal.
2) "It takes up too much space." But just about any mnemonic for (say)
paragraph is sure to be shorter than 2 RETURNs and 5 spaces, or
procedural commands to skip line and change the indentation level,
etc., etc. One can also define abbreviations (say, for "ℵ"),
gaining the brevity of transliteration without losing the other
advantages, all within the easy part of the SGML standard. So, for
example, if one is doing a lot of Hebrew, one defines a "<hebrew>"
tag, within the scope of which a defined transliteration scheme is
used.
3) "Typing pointy brackets and mnemonics is a pain." SGML says nothing
whatsoever about what you have to type. Any word-processor with "style
sheets" at least allows SGML-like mnemonic descriptors -- and how you
specify them is as varied as the programs themselves. Also, it seems
obvious that even *typing* a mnemonic is less pain than the usual task
of translating the mnemonic into a long series of formatting codes
which are specific to some particular word processor.
4) "Slashes (or whatever) are better than pointy brackets." This is of
course insignificant. One can change the default, but in any case the
choice of tag punctuation is a trivial matter. Globally changing "<p>"
to ":p." is a problem of a very different magnitude from locating all
paragraphs given only a file with miscellaneous carriage returns and
spaces, some of which sometimes happen to mark paragraphs. It's the
difference between artificial intelligence and a text-editor "change"
command.
5) "SGML isn't WYSYWYG". This is simply false; just as with typing,
the display can be anything. MS Word using style sheets (which is a
very poor but real example of a descriptive tagging system) is no less
"WYSIWYG" than MS Word using (shudder!) rote formatting all the time.
Of course, the true, ultimate "WYSIWYG" word-processor is the pencil.
6) "SGML isn't efficient enough for purpose X." Usually, X is some
specialized kind of information retrieval. One must consider Fisher's
Fundamental Theorom from Genetics: "the better adapted a system is to
a particular environment, the less adaptable it is to new
environments." To draw an analogy from my own domain, one can always
design a specialized grammatical theory for a single language, which
is more effective for that language than any of the general theories.
But linguists are trained to avoid this, because such analysis usually
contributes nothing to the work of students of other languages. It is
true also in Computer Science: if one optimizes a program for one
machine/language/ task, it will be vastly more difficult to adapt it
for a new of extended one. An SGML file can be trivially converted to
other forms for special purposes. Consider that the SGML version of
the entire OED can be searched in a small number of seconds.
On another topic, it's interesting to watch the multi-tasking debate.
There is so much about OS-2 and Windows. Discussions with Microsoft
indicate it has little consciousness of the problems of writing
systems. Even accents are not handled adequately. Someone called the
Mac "silly" -- that's fine for him, but since I can do almost
everything I want (and almost everything I have heard Humanists and
HUMANIST's express desire for) in a multitude of languages, off-
the-shelf, with *any* monitor and *any* video card, with standard
commercial software on the Mac, in an interface style that IBM is
working hard to copy, I'm willing to use a "silly" machine.
Steven J. DeRose
Brown University and the Summer Institute of Linguistics
D106GFS at UTARLVM1.bitnet
=========================================================================
Date: 8 February 1988, 20:53:21 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD Rom caveat
----------------------------
From Sterling Bjorndahl <BJORNDAS@CLARGRAD>
M.J. Connolly's enthusiastic response about cd/rom, cd/i, etc.,
reminded me of a caveat. I raised this on humanist some time ago
already and aroused zero response. Warning: readable/writeable optical
media are being developed. Some of these use laser-magnetic
technology; others use laser-phase change technology, and there are yet
other technologies being investigated. My own feeling is that this
will send the read-only media the way of the eight-track audio
cartridge. ROM works fine for the short and medium term, and I'm very
glad I have access to it, and I expect to see more of it now that it
is a practical and functioning technology. However, if I were a major
commercial publisher I would think twice about investing my own money
*heavily* in the read only technologies. If the hardware developers can
get the read/write heads to move fast enough (for I read that this is
a major design problem at this point), we may all have 500MB drives
hooked up to our micros as a matter of course, and these may be as
easy to use as modern floppies (if I understand the technology
correctly). At that point we won't need or want the ROM devices,
unless perhaps we are running a text archive.
Sterling Bjorndahl
BJORNDAS@CLARGRAD.BITNET
=========================================================================
Date: 9 February 1988, 00:03:55 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Seductive biblical hot keys for that 5% (27 lines)
----------------------------
From Norman Zacour <ZACOUR@UTOREPAS>
To Robin Cover and his seductive biblical hot keys I can only respond
with Luke 4:5-8. With a CD Rom he should have no trouble finding it.
Seriously, however, the technology available for rapid and thorough
consultation of reference works is quite admirable, and will become more
so; its role, however, is the role that the indices of scriptoria,
archives, and libraries played in the past. They are really
institutional in nature, useful - indeed essential - in their place.
But since I spend about 95% of my working time reading, thinking,
writing and swearing, and only 5% (if indeed that) looking things up, I
cannot get excited about moving a proxy library into my apartment. I
think that what I'm talking about is a sense of proportion. I also
have a sneaking suspicion, somewhat confirmed by Cover's last paragraph,
that the latest obsession can quickly become the latest obsolescence,
unavoidable in this day and age, perhaps, but preferably to be borne at
the institutional level.
=========================================================================
Date: 9 February 1988, 00:09:24 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: SGML/AAP tag text processing today (36 lines)
----------------------------
From Allen H. Renear <ALLEN@BROWNVM>
Michael Sperberg-McQueen's approach to defining SGML/AAP tags in Script GML
is the correct one of course. Within seconds of posting my note I realized
what an embarassing kludge I was about to exhibit to the world and fired
off notes to McCarty (to excise the offending bits) and Benson (to keep him on
the right path). But, alas, CORNELLC went down and my northward mail queued
up &c. &c. Anyway, both Script and GML allow the delimiters -- both beginning
and ending -- to be reassigned; and tailoring the GML delimiters, as Michael
noted, makes the most sense. *If* you feel you really must change delimiters
at all. As Sperberg-McQueen hints delimiters are trivial; stick with the
sensible ":" and "." of GML and just define AAP GML tags. If your publisher
says they *have* to be "<>"s you can change them at the end.
There are some general morals here though. One of them is that SGML/AAP style
text processing is indeed possible today, apart from any special SGML software.
And it can be supported by powerful formatters and programmable editors.
Another is that using SGML/AAP style tags is easy, in fact, nothing could
be easier. Of course we do want software that will support our tag based
text processing more actively than general editors and formatters do.
And that's coming. Consider, again, Softquad's Author/Editor -- it creates
an SGML/AAP file, but as you simply choose document components from a
context sensitive menu (it shows you only the relevant components for that
point in the document) not only do you not bother with delimiters, you don't
even bother with tags per se -- that's all handled by the editor.
This is the sort of stuff we can hope to see more of.
=========================================================================
Date: 9 February 1988, 00:20:16 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Zacour's sense of proportion (33 lines)
Norman Zacour has responded with a certain lack of enthusiasm to the
various comments about CD-ROMs and what they offer. I also spend a great
deal of time thinking, swearing, etc., and less time looking things up,
but I think my percentages are not quite his. Having spent the last 3
years or so tinkering with database software and learning to depend on
it for gathering, arranging, and retrieving the textual evidence I use,
I am less resistant to the vision (from "an high mountain" to be sure,
but I smell no sulphur) of wonderfully vast amounts of source material.
At the fingertips, in one's own study, this material will tend to be
used much more than if it's only in the Library. Perhaps that's good,
perhaps not; anyway, for the kind of work I do, the easier the sources
are to get to, the better.
Zacour has a more basic point with which I have no trouble whatsoever.
Forgive me, but I sometimes, in some contexts, wonder what happened to
the "humanities" in "humanities computing." I am reminded of our ancient
colleague Archimedes, who is supposed to have said that if he were given
a place to stand and a lever long enough, he would be able to move the
world. I suppose that he would have, too. Where would we be now?
Spinning beyond the orbit of Pluto?
Willard McCarty
mccarty@utorepas.bitnet
=========================================================================
Date: 9 February 1988, 09:42:19 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
Comments: From: goer@sophist.uchicago.edu(Richard Goerwitz)
From: MCCARTY@UTOREPAS
Subject: CD-ROMS and what not (64 lines)
In response to Robin Cover's posting, asking whether we would be tempted to
buy a CD-ROM given advanced hypertext systems, let me point out that these
systems are still vaporware! And when they do come out, most will not even
be able to act like a simple concordance, allowing you to look up things by
root (or some generalized dictionary entry). Most will not even allow a
sophisticated pattern-matching set (say regular expressions).
I guess I should let everyone in on the fact that we have been corresponding
privately about this, and that the system you are working on actually has these
capabilities in the works. I wish you the best of luck in your endeavors.
When I begin to see electronic products that can offer me keyword searches,
regular expressions, and textual variants, I most certainly will purchase
them! Until then, I'll have to keep the hardcopy at hand constantly anyway
(hard to use the LXX, BHK, etc. with no textual apparatus), so the expense
is hard for me to justify, given my graduate student's budget!
Let me point out that, even if such systems do not rival their hardcopy coun-
terparts in comprehensiveness, those who can afford them will probably find
them useful for browsing, or for quick location of scattered references in
various texts. One thing that is troublesome about hardcopy is that it takes
oodles of time to flip through several texts at once, trying to locate little
things here and there, all the while staying parallel in each work (this is
often the case in biblical work, where one has the original, and several of
the versions lying out on one's desk at once, not to mention reference works
and commentaries). I believe that some will find the computer something of a
time-saver in cases like this.
In all, though, I must agree with Norman Zacour, who notes that most of one's
time is spent flipping through mental pages - not actual books.
I might also point out that at this point in my life - word processing excepted
- computers have probably cost me more time than they've saved. I've spent a
lot of time learning MS-DOS, UNIX, and some programming languages. I've also
spent a long time developing a few programs that really aren't terribly sophis-
ticated by commercial standards (the economic realities here dictate that I do
other things than program all day). Worst of all, I've spent countless hours
learning individual programs, from the tiniest utility to the biggest applica-
tions programs - all of which are constantly growing, mutating, maturing, and
dying. It is an incredible time investment, and so far it has cost me far more
than it's paid off. For me to take the plunge for new software right now, it's
going to have to be pretty slick, pretty easy to use, pretty reliable, and su-
premely useful, not to mention stable in its interface, and permanent in its
availability!
The kinds of projects you are working on have as good a chance of fitting this
bill as any other I've heard of. Again, good luck.
-Richard L. Goerwitz
goer@sophist.uchicago.edu
!ihnp4!gargoyle!sophist!goer
=========================================================================
Date: 9 February 1988, 11:17:20 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROM use (32 lines)
----------------------------
From Keith W. Whitelam (<WWSRS@UK.AC.STIR.VAXA>)
We are in the process of ordering a CD-ROM reader so that the technology can
be assessed. The hope is to equip a micro lab with readers for use by Arts
departments in text analysis. Departmental funds are scarce, particularly in
the Arts, so Computing Science are going to provide the hardware and help
in the assessment. Incidentally does anyone know if it is possible to network
a CD-ROM reader so that the texts can be accessed by more than one micro or
are we faced with the problem of providing readers for all the machines?
The hypertext CD-ROM for biblical studies, mentioned by Robin Cover, is
precisely the kind of development that we are looking for. As a biblical
specialist, such a development offers immense possibilities for research.
The great advantage of CD-ROMS is surely not simply to look up a few
passages but to provide a large text database for searches and so analysis
of a particular text or texts.
The caveat introduced by Sterling Bjorndahl concerning a breakthrough in
read/write optical disks is a major problem. With limited resources, do we
await the breakthrough, in technology and more importantly pricing, or do
we provide a research and teaching facility based on CD-ROMS?
As a footnote, do IBYCUS market their micro in Britain?
=========================================================================
Date: 9 February 1988, 11:45:12 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Are CDROMs all that marvellous? (43 lines)
----------------------------
From Susan Hockey <SUSAN@VAX.OXFORD.AC.UK>
Before we get too excited about the prospect of CDROMs all
over the place, shouldn't we be asking what we can do with
them, or (to put it the right way round) can they answer the
questions which we want to ask?
There are two approaches to CDROMs for text:
(1) The TLG and the planned PHI CDROMs which are intended for
use with Ibycus. These contain only sequential text files - the
apparent speed of searching on Ibycus is because of a hardware
chip between the disk and the CPU which acts as a filter and only
passes to the CPU hit records. Any other software which reads this
disk on a PC is bound to be much slower, probably too slow for
anybody to want to use interactively on anything but a short text.
(2) Everybody else's which use indexes for searching, and are
supplied to the user with packaged software for their use. For
these it is in the supplier's interest not to let the user reproduce
the basic text. To speed up access times these systems often hold
the indexes on more conventional disk. Most CDROMs which are available
now in this category contain bibliographic data, but there are plans
for others holding text.
Therefore it seems to me that (1) can only answer questions which
are defined as a sequential search (I admit it does this very well)
and (2) can only answer questions which somebody else (i.e. the
compiler of the indexes) has decided need to be answered.
Neither (1) nor (2) address the problem of retrieving too much
information (for human digestion) other than at the level of
collocations, nor do they provide the user with much opportunity
to do any further analysis with the text using other software.
Apart from one or two attempts to index the TLG material I don't know
of any CDROMs for textual scholarly use apart from the ones intended
for Ibycus. (I don't count the OED CDROM here.)
I would like to know what use HUMANISTS want to make of CDROMs.
I don't want to hear how marvellous it is have all this text
available. I want to hear what specific questions can be answered
now and what scholarly activities can be aided by CDROMs. I also
want to hear what questions people would like to ask which can't be
answered now and whether they think existing CDROM systems could
answer them.
Susan Hockey
SUSAN@VAX.OX.AC.UK
=========================================================================
Date: 9 February 1988, 16:09:45 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Teleconferencing at Rochester Institute of Technology (204 ll.)
----------------------------
From Doug Hawthorne <ELI@YALEVM>
REPLY TO 02/09/88 08:31 FROM UNKNOWN:
In a remarkable coincidence I received the following, fairly lengthy
description of the use of teleconferencing in a history course at Rochester
Institute of Technology just before reading Dan Brink's query. Other
readers of HUMANIST may find in the RIT experience some ideas applicable
to their own teaching.
Doug Hawthorne <ELI@YALEVM>
From the Handicap Digest # 235:
Written by: patth@dasys1 (Patt Haring)
Modern American History
on VAX Notes
Computer Conferencing in RIT Classes
by Professor Norman Coombs
Professor of history
Rochester Institute of Technology
1 Lomb Memorial Drive
Rochester N. Y. 14607
Bitnet address: bitnet%"nrcgsh@ritvaxd"
At Rochester Institute of Technology (RIT), a truly modern version of
Modern American history is being taught with VAX Notes, Digital's new
electronic conferencing package. This class is part of an on-going
experiment using a computer conference to replace the standard
classroom lecture/discussion format. Results have been extremely
positive to date.
Using VAX Notes, professors and students have the opportunity to
transcend the boundaries of time and space. Since no one has to be at
the same place at the same time to participate in the conference, VAX
Notes provides a maximum of schedule flexibility for everyone
concerned. This approach is particularly useful for off-campus
students trying to balance busy schedules that include work, family
and school. VAX Notes is also a convenient and easy conference program
to use even for professors and students who have very limited computer
experience.
VAX Notes is a software package that is compatible with the VMS
software environment and works with standard editors, such as EDT, EVE
and WPS. It can be called from the ALL-IN-1 Office and Information
System menu and is available on all Digital VAX systems, from MicroVAX
to high-end VAX computers.
A VAX Notes conference is overseen by a moderator, (in this case, the
class professor), who posts of a variety of topics within a particular
conference. At RIT the data is entered on the professor's (Apple ii
plus and modem). Students can enter their
responses on a variety of terminals, personal workstations and pc's
located in labs in class buildings, dorms or, in the case of a pc, at
home) and the response to each topic is automatically attached to that
subject. This allows several discussions to be held simultaneously
within a conference. Everyone is assigned a title and a number,
allowing the user to follow each in a logical and normal fashion.
VAX Notes keeps a notebook in the user's main directory that tracks
which topics and responses a user has read. Each time the user
participates in the conference, VAX Notes automatically begins at the
first item which had been added since the user last took part. This
allows the participant to keep up with the discussion without having
to remember which notes had already been viewed and without having to
find find his or her place.
The Modern American History course was structured so students gained
information from textbook readings and from watching video tapes.
These were available in the library where students could use them at
their own convenience. The VAX Notes conference took the place of a
classroom discussion on these materials.
Each week I posted a set of three to five topics on the current
material, consisting of several questions. Students logged on to VAX
Notes and attached their responses electronically to the relevant
topic by inputting them on terminals located either on campus or from home I
checked the postings for new entries several times each day and added
comments of MY own when appropriate.
There were two sections of Modern American History given in the Summer
and Fall semesters. The material in each was identical and both
sections took the same objective exams. The traditional class met
twice weekly for discussions with the professor and served as a
control group for the experiment.
Both in the Summer and Fall, the students in the computer confeencing
section scored a higher mean grade than those in the traditional
class. In the Fall, the control group scored a mean grade of 78.7
while the computer students averaged 82.0. This probably does not mean
that computer conferences are better than class discussion. Rather,
the use of the computer frightened away the below average student.
Also the computer section did have a grade point average slightly
above that of the control class.
Students and professors also used electronic mail (VAXmail)
extensively. The professor and some students felt that there was more
than the usual interaction between professor and student. It is
unusual for a professor to single out a student in public and call him
in for a discussion, but (VAXmail) made it easy to develop
one-to-one conversations quite frequently. One student remarked that,
as a result of being able to use this facility, this professor was the
most helpful she had encountered at college.
The questionnaire mentioned previously asked the students to rate
professor helpfulness and availability compared to normal class
settings. The computer students ranked that item 4.8 out of 5 and also
scored electronic mail as the major factor in that process.
Electronic mail has been of especial aid to me because I am blind.
Students use electronic mail to submit written materials to me; this
replaces the need for human readers. Finding the computer as a
communication tool made it easy for me to envision its possibility in
teaching. Because the project ran on a minimal budget, the personal
PC, old fashioned Apple II PLUS AND eCHO II sPEECH SYNTHESIZER WHICH
were used could not emulate a VT100 terminal. This did not interfere
with the use of VAX Notes, but it has limited the use of some of the
system's possibilities. Obviously upgrading the access equipment would
open even more computing potentials.
During the Winter quarter of 1986-87, Mr. Stanley Bissell used VAX
Notes in a telecourse on micro computers. This will open new avenues
of communication with distance learners. Plans are also underway to
adapt the Modern American history course for a class of deaf students.
The National Technical Institute for the Deaf (NTID) is on the RIT
campus. I plan to use captioned television, textbooks and the VAX
Notes program on the computer to work directly with the NTID students.
This will remove the need for interpreters, note takers and tutors and
bring teacher and student closer together. Not only can computer
conferencing bridge the gap between the teacher and distance learner,
it can transcend the gulf of physical handicaps in the teaching
process.
RIT Sidebar
Founded in 1829, Rochester Institute of Technology (RIT) is a
privately endowed, co-educational university that enrolls about 14,000
full- and part-time students in its undergraduate and graduate
programs. RIT's modern campus occupies 1,300 acres in suburban
Rochester, N.Y. There are nine colleges at RIT. Its primary emphasis
is oncareer education
A pioneer in cooperative education, RIT offers programs that allow
students to alternate academic course work with paid experience in
business and industry. With a program that began in 1912, RIT has the
fourth oldest and fourth largest cooperative education program in the
nation. In addition tot traditional curriculum, RIT offers world
renowned programs at the School for American Craftsmen and the
National Technical Institute for the Deaf.
As part of RIT's emphasis on career education, the Institute believes
that the availability of computing resources is critical to the
education of students, the instructional and research efforts of
faculty, and effective administration. Computing resources rely
heavily on Digital Equipment Corp. equipment.
Through its department of Information Systems and Computing (ISC), the
Institute maintains relatively open access to computing facilities for
all students, faculty and staff. All RIT students, regardless of
major, must demonstrate computer literacy before graduation.
ISC has a VAX cluster with a VAX 8650 computer and three VAX-11/785
systems running the VMS operating system. Among others, we use APL,
COBOL, LISP, PASCAL, BASIC, DSM (MUMPS), PL/I, C, Fortran, MACRO
ASSEMBLER, ALL-IN-1, VAX NOTES, C.A.S., DAL, DECgraph, GKS and ReGis.
ISC also has a VAX-11/785 computer which runs ULTRIX. The College of
Engineering has a VAX-11/782 system, and NTID has a VAX-11/750
computer. The Center for Imaging Science has a VAX 8200 comuterand a
GPX II system, (a color Microvax graphics workstation). The Computer
Science department has a VAX-11/780 computer running ULTRIX and two
VAX-11/780 computers running Berkley 4.2 UNIX. The American Video
Institute has a VAX-11/780 computer and several Pro IVIS videodisk
systems.
All of these systems and several others are linked via two Ethernet
networks which are bridged together, an Infotron IS4000 data switch
and most recently with an AT&T ISN data switch. ISC has about 300
Digital terminals, including GIGI, VT220, VT240 and VT241, located in
five major users center distributed around campus. There are several
hundred other terminals and microcomputers which access our system
both on campus and off-campus. They include approximately 800 Rainbows
personal workstations, 30 Pro 350 systems, 25 DECmate personal
workstations, and IBM PC%, Macintosh%, Apple II% and others.
Patt Haring UUCP: ..cmcl2!phri!dasys1!patth
Big Electric Cat Compu$erve: 76566,2510
New York, NY, USA MCI Mail: Patt Haring; GEnie-PHaring
(212) 879-9031 FidoNet Mail: 1:107/701 or 107/222
=========================================================================
Date: 9 February 1988, 16:11:45 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Text Encoding Initiative (22 lines)
----------------------------
From Nancy Ide <IDE@VASSAR>
Sebastian, We certainly hope that the set of specific tags that we develop
for use in encoding machine readable texts intended for literary and linguistic
research do not *extend* SGML. I may have been inaccurate in what I said on
HUMANIST, since we have every expectation that the tag sets we develop will,
like the AAP tag set for electronic manuscript markup, be an *application*
of SGML. But without beginning the actual research, we cannot yet be sure that
SGML will serve all of our needs (althogh we expect it to--the argument
about SGML's adequacy has already gone around once on HUMANIST).
Nancy Ide
ide@vassar
=========================================================================
Date: 9 February 1988, 16:16:38 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: TVedit and how-far-have-we-come (52 lines)
----------------------------
From Michael Sperberg-McQueen <U18189@UICVM>
A recent inquiry on Humanist concerned the program TVedit, reportedly
used by Douglas R. Hofstadter in writing and typesetting his book
<cit>Goedel Escher Bach</>. I had never heard of this, but by chance
ran into a reference to it yesterday. In their survey (1971) of
early interactive editors, Andries van Dam and David E. Rice describe
TVedit as "one of the earliest (1965) time-sharing, CRT-based text
editors." It was developed at Stanford University, and appears from
the description to be what we would now call a full-screen editor,
more restricted in its command language but more sophisticated in its
user interface than Stanford's later editor Wylbur (itself a very
good program, the best line editor I've ever used), which did not
acquire full-screen capacities until much later. No details are
given but the program appears to have run under a time-sharing
system called Thor, about which I know nothing.
Reference: Andries van Dam and David E. Rice, "On-line Text Editing:
A Survey," <cit>Computing Surveys: The Survey and Tutorial Journal
of the ACM</> 3.3 (September 1971): 93-114.
The article also contains a brief description of what must be the first
implementation of hypertext on a machine (the "Hypertext Editing System"
at Brown) and the earliest hierarchically structured editor I've
encountered, used both for outline processing and as a syntax-directed
editor for PL/I and other programming languages ("Emily," developed
at Argonne National Labs by a Stanford grad student, and named for Emily
Dickinson).
The amateurs of history among us will be amused or intrigued to read
of editors "supplied ... as part of a time-sharing system for those
few lucky enough to have access to one." Can it be so recently that
even mainframe time-sharing was so rare? And who among Bitnet users
can remain unmoved by the authors' closing evocation of a day when,
they hope, manuscripts will not need to be rekeyboarded every time
authors jump from one system to another, when "files can be
cooperatively worked on in real-time, regardless of geographic
location or editing system, and still at reasonable costs." Let us
pause for a moment of silence and all give thanks for the networks,
which have given us facilities that only sixteen years ago were only
a visionary dream.
Michael Sperberg-McQueen, University of Illinois at Chicago
=========================================================================
Date: 9 February 1988, 16:20:31 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Multitasking, Desqview, Windows (62 lines)
----------------------------
From Mike Stairs <STAIRS@UTOREPAS>
It is time for me to join the fray! Up to this time I have been quietly
reading Humanist without actively participating. My office is next to
Willard's so I figured he could respond for the CCH as a whole. Willard
asked about Deskview and Windows etc. I just acquired both packages along
with a mouse and 4 meg extended memory and 1 meg expanded memory. Both these
packages make using PCs almost bearable (I am hoping to get a 386 machine
very soon). Though some of my computing needs may differ from the average
humanist I have some idea of what they probably need and also what they think
they need.
There seems to be a general fear of new technology and a desire to make do
with what is presently available rather then venture into the *new wave*.
This is a waste of computing power that is there for YOU if you dare! I came
from the Computer Science department to this position but have a strong
background in philosophy. I would argue that machines could never think but
that they are tools for achieving that which was previously impossible or
very time consuming. I don't want to start a discussion on the first claim
but the second point is important. If Humanists are afraid of available tools
they are losing their own very valuable time. Why do a concordance that takes
5 hours when with a faster machine it may take 1 hour? It seems a false
economy indeed if cost is the motivating factor. Analysis that would not be
undertaken with a slow machine could now be possible. I'm not advocating
that everyone rush out and buy the fastest machine on the market today but
people should try to not be so aprehensive of the changing technology.
All this said, what are the present alternatives to DOS? Both DeskView and
Windows are superior to DOS standing alone. They are not replacements to DOS
but rather enhancements. They allow you to use a mouse, for this reason alone
you should be convinced. The use of a mouse is a great time saver. But this
is just a bonus, the true joy of these systems is their multitasking ability.
Anyone who has used TeX will will be happy that they can have their favorite
word processor, previewer and TeX all running at the same time. You can use
the spooler and work on something else too. You could be even downloading a
huge document with your modem at the same time. It is like having a room full
of computers all accessing the same files, but capable of doing completely
different tasks at the same time. You could even view multiple tasks on the
same screen. OS/2 will not be able to do this with DOS tasks so there is no
point in using it. You are not forced to buy (expensive) expanded memory to
use DeskView. It can swap programs on and off your hard disks as they become
activated. It is like a large ramdisk (though it is a bit slower).
I realize that I have rambled on a bit too much. The point is that it is
frustrating to see people afraid of new technology which could save them a lot
of time and work in the long run. I guess the question is whether it is worth
the effort to keep up. If the answer is "no" there will be many important
answers that Humanists are searching for that will never be found. I know my
time is too valuable to waste it when there are alternatives to the present
methodologies.
Mike Stairs
Site Coordinator
Centre for Computing in the Humanities
University of Toronto
=========================================================================
Date: 9 February 1988, 20:08:03 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROM / SGML (36 lines)
----------------------------
From David Nash <nash@cogito.mit.edu>
Last night here I attended a talk by Bill Gates (founder etc. of the
MicroSoft corporation) at the monthly meeting of the Macintosh group
of the BCS (Boston Computer Society). Followers of recent threads on
this group may be interested to note that the up-beat note on which he
ended his hour was an assured expression of confidence that SGML-based
documents on CD-ROM are about to appear in great numbers.
He cited examples outside academia, such as large manuals, parts
catalogues, and didn't even mention MicroSoft Bookshelf (the CD-ROM
now available with a dictionary, Zip Code directory, almanac, etc.)
He noted that the people at Boeing regard the paper copies of the full
manuals for their large aircraft as rare immoveable objects (which are
consulted in some kind of rack, as I read his gesture).
He said that US Government publications are now prepared in SGML, and
predicted (?) that in a few years the machine-readable versions of
(most?) US Government documents would be more readily available than
printed versions.
I noted that he didn't explain "CD-ROM", but felt he had to expand on
what "SGML" is. If you believe what he was saying, it sounds CD-ROM
readers will soon be around as much as, say, microfiche readers.
-DGN
=========================================================================
Date: 9 February 1988, 20:09:18 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Early editors (40 lines)
----------------------------
From David Durand <DURAND@BRANDEIS>
If we're going to talk about the history of editing and advanced text-
handling on computers I have to put in a plug for Douglas Engelbart's amazing
work. He implemented the first integrated office with central file handling,
outlining, text-handling + arbitrary cross referencing in the early 60's.
I'm not sure when the first version cam online, but I think it was before 1965.
A few articles: still very worthwhile reading, as the fundamental issues
have not changed since then, though the technology certainly has:
::BOOKLONG:
ANA:Engelbart, Douglas C.
ATL:A Conceptual Framework for the Augmentation of Man's Intellect
MTL:Vistas in Information Handling, Volume 1
AMR:editors
MOA:Howerton, P. D., and Weeks, D. C.
LOC:1-29
PLP:Washington, D.C.
PUB:Spartan Books
DAT:1963
::CONFPROC:
ANA:Engelbart, Douglas C., and English, W. K.
ATL:A Research Center for Augmenting Human Intellect
MTL:AFIPS Proceedings, Fall Joint Computer Conference
DAT:Fall 1968
There are a number of later ones not included here. Citations taken from Paul
Kahn's distribution of the IRIS Hypermedia Bibliography which was started by
Steven Drucker and is now maintained by Nicole Yankelovitch.
=========================================================================
Date: 10 February 1988, 09:12:53 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Nuancing Susan Hockey on CD-ROMs (89 lines)
----------------------------
From Bob Kraft <KRAFT@PENNDRLN>
There is much to say about the current CD-ROM discussion,
but for the moment I would like to nuance some of the
information in Susan Hockey's recent contribution, to help
avoid possible misunderstanding on a couple of details:
(1) Currently three different TLG CD-ROMs have been
produced, dubbed "A", "B", and "C". The TLG "A" disk
was issued in the summer/fall of 1985 in a provisional,
pioneering (pre High Sierra) format that simultaneously
was made available on the new IBYCUS Scholarly Computer.
Subsequently, CCAT (with Packard Foundation funding)
developed experimental prototype programs to access the
"A" disk from IBM type machines.
The TLG "B" disk appeared soon after, prepared as a
version of the "A" materials (or at least of the Greek texts
on the "A" disk, which also had some Latin and other texts)
with lexical indices by Brown University (Paul Kahn) in
cooperation with Harvard (Gregory Crane). This disk does not
run on IBYCUS, and ran very fast on the machines for which
it was intended (initially an IBM RT, I think). The software was
adapted for an IBM PC environment by Randall Smith, and,
I think, for an Apple Macintosh environment as well, although
I am sketchy on the exact details. Gregory Crane now uses it
on a Mac, if I am not mistaken. The TLG CD-ROM "B" uses a
format developed at MIT, also pre-High Sierra.
TLG CD-ROM "C" has been mastered and is about to be released.
It uses the (provisional) High Sierra format and can, at a very
rudimentary level, be accessed by any machine equipped to read
that format; CCAT is developing software to use the "C" disk from
IBM type machines (employing the recently released DOS Extension),
and IBYCUS has redesigned its access program to read the "C" disk.
Complications are caused by the internal ID-locator formatting
of the materials on the disk, which must be decoded for ease and
efficiency of access, but there is nothing peculiarly "IBYCUS
oriented" about this disk. The TLG "C" disk also includes
indexing at some level, although the IBYCUS access program does
not make use of this feature.
(2) A "sister CD-ROM" to the TLG "C" disk has been prepared by
the Packard Humanities Institute (PHI) in cooperation with CCAT.
For details see OFFLINE 17. This disk is intended to be in the
same "High Sierra" format as the TLG "C" disk, and to employ the
TLG "Beta coding" for ID-locators. The IBYCUS software can read
the PHI/CCAT CD-ROM, which has been mastered and is about to be released
for distribution. CCAT also has "experimental" software for reading
this disk from IBM type machines. This disk does not contain indices.
(3) It is not difficult to treat the CD-ROM as a source from
which to offload particular texts or portions of texts, so that
a user's favorite software can then be applied to the offloaded
material. This is true on IBYCUS or on IBM, and is perhaps the
most obvious use of a CD-ROM for the "average" user who is not
yet in a position to make more sophisticated direct use of the
materials. For people who want to have access to large bodies
of texts, even if only for offloading, the economic and storage
advantages are tremendous. I can give concrete figures, as
examples, if anyone cares.
Finally, to Susan's question -- what research benefit does my
access to CD-ROM (via IBYCUS, I confess) offer? Apart from the
obvious searching and selecting, which can include searching the
entire corpus of available Greek (or Latin, etc.) material for
a given word, phrase, combination of words, etc., I use the CD-ROMs
as a reference point for quality control (correction of errors;
no small matter, at this point!), as a convenient source for
offloading (no need to hunt for the tape, mount it, etc.), and
as a gigantic pool in which to hunt for identifying papyri scraps,
unknown quotations/allusions, etc. (a special kind of searching).
Basically, they are at present for me repositories and bases for
excerpting and sophisticated index-type searches. I have not yet
tried to do anything imaginative with the variety of non-linear
or extended-linear files on the PHI/CCAT disk -- e.g. morphological
analysis, parallel texts, text with variants, word lists. But they
are there for the experimenting!
Bob Kraft, CCAT
=========================================================================
Date: 10 February 1988, 09:16:55 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: IBYCUS in Europe (17 lines)
------------------
From Bob Kraft <KRAFT@PENNDRLN>
In response to Keith Whitelam's footnote, it is my
understanding that John Dawson at Cambridge has agreed to
act as a representative of IBYCUS for European (or at least
British) distribution.
Bob Kraft, CCAT
=========================================================================
Date: 10 February 1988, 09:18:03 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Re: Are CDROMs all that marvellous (43 lines)
-------------------------
From Charles Faulhaber <ked@garnet.berkeley.edu>
Scholarly activities aided by CD-ROMS:
1) Textual criticism. To be able to check the usus scribendi of an
author, an age, or an entire corpus would be an enormous boon for
the establishment of texts. It simply cannot be done now except in
the very simplest of cases.
2) Historical linguistics: First attestations of word usage are
important for lexical studies of all sorts, but so are last
attestations. At this point it is impossible to say "This is the
last time word x" is used. With the TLG we can say this with a
very high degree of certainty.
I'm with the CD-ROM people (but it doesn't have to be CD-ROM). Access
in any reasonable fashion to the entire machine-readable corpus of
a given literature will revolutionize the study of that literature.
I would like to see some thought given to software for semantic
access, probably some sort of thesaurus approach. This may already
exist, but my ignorance is vast ....
=========================================================================
Date: 10 February 1988, 09:25:46 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROMs (51 lines)
-------------------------
From ghb@ecsvax (George Brett)
Hullo from mid-south.
My work with micro concordances is minimal... I have watched Randall
Jones do a presentation of BYU Concordance. I may be off course, so
please accept my apologies early on.
Now, about this cd-rom business and concordances and hypertext. Have
you seen a HyperCard stack named Texas? This stack has the ability to
index a text file at a rate of 3Mb per hour. The result of the
indexing are two "lists" and the text file. The first list is a word
list that is alphabetically sorted, numbered by frequency, and can be
searched. Once a word is selected from list one you are presented
list two. List two shows the word you have selected in a one line
context sitution. Each line has the selected word centered on the
screen with text to the left and right on the same line. When you
find a line that appears to meet your criteria you select that line
and then Texas presents you the paragraph in the original text file
with the word in it. (verbally that's the best I can get at the
moment.)
If you have access to a Mac with HyperCard I would be most willing to
mail you a copy of this package. The author has expressly mentioned
that it is intended for CD-ROM application. I would be interested to
hear what someone more familiar with concordance packages would have
to say.
Cordially --
-- george
George Brett (not the baseball player)
Manager, Academic Services
UNC-Educational Computing Service
ghb@ecsvax.UUCP or ghb@ecsvax.BITNET or ECSGHB@TUCC.BITNET
>work: UNC-ECS POB 12035 RTP NC 27709-2035 919/549-0671
>home: 1408 Alabama Ave. Durham, NC 27705 919/286-9235
=========================================================================
Date: 10 February 1988, 12:23:32 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROMs and the problem of defining a "corpus"
---------------------------
From Dr Abigail Ann Young <YOUNG@UTOREPAS>
I'm not acquainted in detail with the CD-ROM (or any other version!)
of the TLG, although I've used the printed TLL a great deal, so I
may be misinformed about what I'm going to say as it pertains to
the TLG as opposed to the TLL. But unless the TLG project did as
the DOE project has done, and edited from MSS. all the hither-to
UNpublished writings in Classical Greek, Koine, patristic, &
Byzantine Greek, you cannot use to it determine the earliest
occurrence or the latest occurence of a word in Greek. Similarly,
I cannot now use the TLL to find the earliest or last occurrence of
a given word in Latin. I can find the earliest or last occurrences
of words in PRINTED works/MSS. I think it is important for those
of us who work with languages like Latin to remember that, even with
the best CD-ROMs, software, et al., we are still restricted in
our analyses to a comparatively small portion of the actual
surviving texts because only a comparatively small portion of
those texts have been edited and printed. (And I wouldn't
want to think about the problem of how many of them have been
edited well!) We can perhaps analyse and study the available
corpus of Latin or Greek literature on CD-ROM much better than
in any other form, but we should be careful not to confuse the
available corpus with the entire corpus. It is a problem I
often experience in my own work, because people are apt to say
of a Latin word, "That form doesn't exist!" or "No, it doesn't
mean that!" on the basis of the TLL. But the TLL only includes
edited and published material, which means that it is entirely
possible for other forms and other senses of known forms to
exist in many, many MSS. texts of which the TLL is unaware. In
our desire to use the latest technology to expand our understanding
of a language or a literature, we mustn't forget how much work
remains to be done in the locating, editing, and publishing
(in whatever form, print or electronic) of writings still in
MSS. or on papyrus, etc. I doubt even a Kurtzweil and a 386
machine could help much with that!
Abigail Ann Young
REED
=========================================================================
Date: 10 February 1988, 12:28:34 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CDROMMERIE (24 lines)
--------------------------------------
From David Nash <nash@cogito.mit.edu>
Beryl T. Atkins thanks you for the (first 15) reponses on CD-ROM.
" Have only scanned the Humanist responses
so far but wonder if it's worth making the point that what we're
thinking of putting onto CDROM now would be a corpus of general
English, with a front end allowing selection (& downloading to
one's own computer) of node-word concordances of flexible length.
It's really a research linguist's tool. We have also of course
thought of putting out dictionaries on CDROM, I suspect these too
would be for the researcher rather than the sporadic user or the
dic freak browsing through etymologies at midnight."
-DGN
=========================================================================
Date: 10 February 1988, 16:19:11 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Long-term storage of electronic texts (37 lines)
-----------------------------------
From Ian Lancashire <IAN@UTOREPAS>
A journal called Electronic Library intermittently publishes
interesting articles about electronic methods of storing text.
The general impression given by these is that computer-readable
media, including CD-ROM, offer much less of a storage life than
acid-free paper or (best) microform. Since an alarming percentage
of existing library collections is already irrevocably lost to this slow fire,
and since most of us are using electronic storage for our own work,
may I pose a question?
What is the most secure method of storing machine-readable text
and how long many years does that method offer us?
The best solution for mass storage I know of has been
termed videomicrographics by Dennis Moralee ("Facing the
Limitations of Electronic Document Handling", Electronic
Library 3.3 [July 1985]: 210--17). This proposes very high-resolution
page images stored with conventional micrographics and then -- here's
where mother CPU comes in -- output electronically by scanning
when (and only when) the user asks for the page(s). This
method is, in theory, technology-independent and reliable.
I hope my colleagues and students will begin to make good
use of concordances and indexes of vast archives of literature
on CD-ROM and the like, but a better use of our efforts might
be to save some fragments of the past 150 years from the
fires of acid paper.
=========================================================================
Date: 10 February 1988, 16:27:44 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: In defense of write-only (59 lines)
------------------------------------
From <CNNMJ@BCVMS> (M.J. CONNOLLY [Slavic/Eastern])
I restricted my reply about CD-ROM usage to the read-only formats
because the question seems to have come from the publishing quarter. I do,
however, agree with Bjorndahl that the issue of read/write deserves attention
and his caveat is well put.
One important consideration, which humanists must appreciate, is
the matter of _authority_ in data. When I read something in a reference work
I can be reasonably certain that what I see at line m on page n is the same as
what another reader has in another copy of the same edition. Not so, however,
if those contents were in a read/write format. Short of edit-trails, which
few will be likely to implement or respect, we could never be sure whose Dante
we are really reading. The same difference applies in music with LPs and CDs
on the one hand versus the far more volatile and editable tape media on the
other hand. Why is the recording industry in the US ashiver at the prospect
of digital audio tape decks? Granted, they could care less whether
the Mozart in your living room is echt, but they do see that they forfeit
control in a read/write scheme. For many of our needs, that same control
rigidity serves as a blessing.
I should not feel able to place scholarly reliance on a work
presented in a medium where anyone else may have been before me, dickying
around at leisure. If you've used some one else's Home stack in Hypercard
or an editable spell-checker in a public facility, you'll understand the
feeling on a minor scale. This is also why an MIS officer at your institution
will prefer to maintain his own database and job mailing labels and
reports when you need them, rather than letting you have a copy of the
database with which to make your own. Without linked editing of the
copies (then virtually a shared file) changes to A do not appear in B and v.v.
The second issue with read/write involves availability and standards.
CD-ROM is here, and the manufacturers are in near uniform agreement about
the standards for the emerging alternate formats. (See also what I wrote
about the intended upgrade paths). Read/write is still not here yet, and
I see no guarantee that we shall be spared the CBS:RCA-color-television
duel or the VHS:Beta wars or the interactive laserdisc skirmishes whenever
speedy products appear at affordable prices. For the meantime we should not
put important work on hold to wait for the next stage of the technology --
there is always an exciting next stage.
Yet even when we do have useful read/write, the need for read-only
will not have passed.
Prof M.J. Connolly
Slavic & Eastern Languages
Boston College / Carney 236
Chestnut Hill MA 02167
( U . S . A .)
<tel:> (617)552-3912 <email:> cnnmj@bcvax3.bitnet
=========================================================================
Date: 10 February 1988, 18:48:56 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROMS *are* marvellous (73 lines)
------------------------------------
From Sterling Bjorndahl <BJORNDAS@CLARGRAD>
Susan Hockey asks if CD ROMS are marvellous. All I can say is that
the Ibycus system provides a relatively cheap way for people to be
able to do linear searches, as she describes. Cheap both in terms of
money (if your department buys it) and time. And even though it is
just a linear search it has revolutionized the way we do research here
at Claremont. It is becoming unacceptable here for us as graduate
students to write a paper without checking through and digesting
several centuries worth of Greek literature. Let me give an example.
I wanted to find out something about in what context a man and a woman
could recline on the same couch in a meal setting. This was in an
examination of the Gospel of Thomas saying 61, in which Jesus says
"Two will rest on a couch; the one will die, and the other will live."
Salome replies: "Who do you think you are, big shot? You've been up
on my couch and eaten from my table!" (implying: which of us two is
going to die, you or I?). This is an amusing Cynic-type chreia which
goes on to be elaborated in sayings 62-67 in a rather gnostic fashion.
My question was: isn't it a little unusual for Jesus to be on a couch
with Salome at all?
I am not from a classics background - a situation shared by many in my
field - and so I didn't know where to turn to find out about men and
women eating together on the same couch. I found a couple of old books
dealing with home and family in Greece and Rome, but they were rather
popular in orientation and didn't cite many sources to back up their
assertions. I knew a little bit about hetaerae, of course, but didn't
know if I knew enough to compare Salome's behaviour with that
particular role.
However with the TLG texts on CD-ROM I was able to pick a few key
Greek words to search for. In a half an hour I had twenty pages of
references, in context, in which those words appeared together. Over
the next few days I was able to digest them and put them into
categories of public/private, married or non-married couple, and I
paid some attention to time frame, social status, and geographical
setting. This resulted in about twenty texts that made a rather nice
appendix to a paper (although it suffers from a lack of archeological
data, and of course it cannot claim to have *every* relevant text -
just enough to argue a case).
I really don't know how else I could have done this. I would have not
taken the time to search through the index of every volume in the Loeb
Classical Library series. It may be that some bright classics person
reading this will be able to point me to a monograph dealing with this
subject, but as I say, it's not my field and I don't know my way
around it very well yet. I couldn't find any secondary literature
that helped very much (if you know of some, I'd be grateful to hear
about it).
So even though it's not CD-I, even though it's just a linear search on
a literal string, it has made quite a difference to me and to several
other people here. It has allowed us to work conveniently with texts
that we may have never before touched. It certainly does not do our
work for us - we would not want that. Our work is the digesting and
analyzing. Flipping through indices is menial labour that we don't
mind letting the machine do. I belive that it is IBM's unofficial
motto that reads: "Machines should work. People should think." The
more texts I can have at my fingertips, the more I'm going to enjoy
making connections that may never have been made before.
Sterling Bjorndahl
BJORNDAS@CLARGRAD.BITNET
=========================================================================
Date: 10 February 1988, 18:52:18 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CATH 88, call for papers (59)
----------------------
From May Katzen <MAY@VAX.LEICESTER.AC.UK>
---------------------------------------------------------------
---------------------------------------------------------------
HUMANIST readers are reminded that the deadline for submitting
abstracts for the CATH 88 conference is 29th February 1988.
---------------------------------------------------------------
CALL FOR PAPERS FOR CATH 88 CONFERENCE
Computers and Teaching in the Humanities:
Re-defining the Humanities?
University of Southampton, UK
13th-15th December 1988
The theme this year is the interface between the computer
and the humanities disciplines and whether or not traditional
assumptions and methods are being supported or challenged by
the use of new technologies in higher education.
The conference will be mainly devoted to workshops and
seminars, and proposals are invited for contributions to
workshops. Abstracts of at least 500 words should be sent
to:
Dr May Katzen
Office for Humanities Communication
University of Leicester
Leicester LE1 7RH
UK
Tel: 0533 522598 (from UK)
011 44 533 522598 (from North America)
E-mail: MAY @ UK.AC.LEICESTER.VAX
Please note that the deadline for receipt of papers is
29TH FEBRUARY 1988.
-------------------------------------------------------------
May Katzen
Office for Humanities Communication
University of Leicester
=========================================================================
Date: 10 February 1988, 19:00:24 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: academics and apartheid
------------------------------------------
From Sebastian Rahtz <spqr@CM.SOTON.AC.UK>
Its nothing to do with computers at all, but could I take the
opprtunity to suggest to anyone reading this that they consider
joining the World Archaeology Congress? For a mere $20 you can be
part of a body which is more or less unique (so far as I know) in
its commitment to the THE academic subject (archaeology - didnt you
know?), to Third World integration into the subject, and to a vision
unbiased by geographical or historical constraints. It is founded on
the success of the 1986 'anti-apartheid' World Archaeological Congress.
If you have never heard of it, find out now by writing to W A C,
Department of Archaeology, University, Southampton S09 5NH, UK.
I might add that I disagree with much of what WAC has to say about the
past and the relationship between ethnic groups and historic remains.
But since WAC is the most anarchic body I have yet encountered in academia,
and is seriously trying to bring together academia and politics, it gets
my vote every time.
join WAC or be square....
Sebastian Rahtz
Computer Science
University
Southampton S09 5NH
=========================================================================
Date: 10 February 1988, 19:02:50 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Large corpora and interdisciplinary poaching (45 lines)
Sterling Bjorndahl in his most recent note tells a story I'm sure many
of us could repeat in essence: how access to some large textual corpus,
such as the TLG, allows a scholar to get a grip on the material of an
academic discipline outside his or her training. I certainly can, but
I'll spare you most of the details, since Sterling's are as good.
Like Sterling I'm not a classicist; like Sterling I found myself
forced to poach on the classicists' turf in order to serve
research in another field, and I also used the TLG on an
Ibycus. I know I didn't find every reference to the Greek words for
"mirror" (footnote prowling turned up several the experimental TLG disk
didn't produce), but never mind. I found enough to make a sound
argument, at least sound enough to get the thing accepted in a
classicists' journal. Having so much evidence was, yes, marvellous for
all the obvious reasons.
My point, again, is to underscore what Sterling noted about the benefit
of access to large corpora for us interdisciplinary poachers. Ok, in the
good old days, anyone lucky enough to get into a good school would have
read classics and, perhaps, have known just where to look for "mirrors,"
though I doubt the comprehensiveness of *his* knowledge. And yes, the
CD-zealot isn't guaranteed a sound argument simply by having mounds of
evidence. Intelligence is required. But it IS marvellous for a poorly
educated Miltonist to be able to survey 21,000,000 words of Greek so as
to be able to make a plausibleGreconstruction of what his intellectual
master was talking about.
And all this merely by doing a sequential search, with no built-in
morphological analysis, no tools for disambiguation. Are you all
aware of what Yaacov Choueka and his colleagues have done with the
Global Jewish Database, ca. 80 million words of rabbinic Hebrew?
If only the Ibycus could run that software!
Willard McCarty
mccarty@utorepas.bitnet
=========================================================================
Date: 10 February 1988, 23:19:00 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Scanning query (21 lines)
------------------------------------------
From goer@sophist.uchicago.edu(Richard Goerwitz)
Can anyone recommend a decent, inexpensive scanning service that can handle
a typset English document whose only catch is a some variation in type size,
and some extra, accented characters?
-Richard L. Goerwitz
goer@sophist.uchicago.edu
!ihnp4!gargoyle!sophist!goer
=========================================================================
Date: 10 February 1988, 23:23:30 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: TEXAS 0.1, in response to George Brett (49 lines)
------------------------------------------
From David Nash <nash@cogito.mit.edu>
>From ghb@ecsvax (George Brett)
Date: 10 February 1988, 09:25:46 EST
writes:
Have
you seen a HyperCard stack named Texas? This stack has the ability to
index a text file at a rate of 3Mb per hour. The result of the
indexing are two "lists" and the text file.
And goes on to give a clear description of what Mark Zimmerman's
software will do for the Mac user.
I would be interested to
hear what someone more familiar with concordance packages would have
to say.
Well, I'm not familiar with a range of concordance packages, but as
nice as TEXAS 0.1 is (and at a very nice price), it calls for some
additional features to make it a good tool. There are two handicaps I
found in the first minutes:
(1) A context word cannot be selected from the line- or full-context
displays, and then used in turn in the index. One has to return to
the word-list screen and type in the desired word.
(2) A slice of display (whether index, line-context or page context)
cannot be saved to a (ASCII) file.
Both these would be no problem if the Clipboard were available from
TEXAS, but unfortunately it isn't.
I believe Zimmerman <science@nems.arpa> would like to hear further
suggestions for its improvement. I would use an option of reverse
lexicographic indexing for instance, and of suppressing material
marked in a certain way (e.g., all material inside square brackets).
The approach deserves encouragement, I think. And I like it that he
added the HyperCard interface to a previous package. (Zimmerman's
browsing package was written in C and used first with Unix.)
-DGN
=========================================================================
Date: 10 February 1988, 23:26:26 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Text archiving (44 lines)
------------------------------------------
From David Durand <DURAND@BRANDEIS>
Ian Lancashire's posting about the longevity of various forms of machine
readable archival brought a few thoughts to mind. The first thought, is
agreement with the plea to use the greatest possible speed in moving
information from pages printed on acid paper to some more secure form. It
would truly be a sad irony if the last 200 years of written production, an
accumulated weight (literally) of knowledge and effort, were to be lost to
the very technology of inexpensive printing that helped it to be created.
However, I think there is a common misconception about the safety of digitally
stored data that needs to be addressed.
Granted that the longevity of most digital media currently in existence
probably cannot be guaranteed to be greater than 30 years, there is a
significant difference between digital and analog media. The crucial difference
is that digital media do not degrade gradually as they are stored, and they
can be speedily duplicated without loss of content in a way that other
media cannot. In addition, given the speed of technological change, each
copying operation is likely to pack more and more information into one
storage unit. This means that over time, the copying process becomes
easier and easier. Compare the operation of copying the TLG on magnetic tape
to the operation of printing a new copy of the CD-ROM from the master
stamping plate.
Another factor is that once data is captured in character-based form
(i.e. not page images) it can be manipulated much more flexibly than
printed, video, or microform media which can only be read by human beings.
All of these technologies may be needed in the interim process of converting
past knowledge into permanent electronic form. We have to work with what is
available, after all. But the fact remains that a computer file is both more
easily duplicated without error, and is more useful for research than an
image-based representation of the same texts. Perhaps character recognition
will eventually solve the problems of converting photographs of badly typeset
victorian books into ascii files, but it seems best to go with the most
flexible format available.
=========================================================================
Date: 10 February 1988, 23:28:53 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Final SGML posting (64 lines)
------------------------------------------
From David Durand <DURAND@BRANDEIS>
This posting is a joint product with Allen Renear of Brown.
A point of terminology: The word `tagset' refers to the set of content
entities indicated in a computer stored document. The issue of what tagset
to use is independent of the decision to use SGML or not.
The point that must be kept in mind about SGML that must be kept in mind
is that SGML is *not* a tag set -- it is a language for rigorously declaring
a tagset and its associated grammar. An SGML complying file consists of
2 components: (1) the prologue, a header which declares the tags and
describes their grammar, and (2) the tagged text itself. The AAP standard
describes a tagset -- and gives the associated SGML declarations. That is,
it is a tagset that conforms to the SGML standard in having,
among other things, an SGML declaration.
Many of us believe that the important thing is that SGML provides a
standard for declaring and then using tagsets. But attempts to
standardize tagsets themselves are much riskier projects.
For one thing a great deal of ingenuity and innovation goes into
a tagset. For another, a tagset may correspond to a work of scholarship
in itself, if the tagged information involves a new interpretation of the
the text. Consider, for example, the introduction of paragraphing into a
manuscript text, or the scansion of a work previously regarded as ametrical.
Tagsets often represent an improved understanding of a text's structure
or of the relative importances of different aspects of that structure.
The may be innovative, they may be controversial. Not the sort of thing
which is ripe for standardization.
I understand that University Microfilms is accepting, as an experiment,
some dissertations in electronic form -- provided they are marked up
in the AAP tagset. Well my dissertation is rigorously marked up -- but
there are no AAP tags corresponding to my *primitive_term_introduction*
tag, or my *counterexample* tag. In some cases I add detail to what
seems to be an AAP analogue: my definition is composed of a *definiendum*
and a *definiens* -- so far so good. But my definiens contains *clauses*
and my definiendum a *predicate* tag. In more awkward cases there may be
semantic incongruities in tagsets that no amount of granularity adjustments
will resolve. Such tagsets will be fundamentally incommensurable.
Standard tagsets support comparative work, so we should explore them
and create them. But we should not hold out too much hope for them if we
expect them to be adequate for all applications. Extensibility within
a uniform structure is an essential.
The important thing is that 1) the manuscript be tagged and
2) the tags and their grammar be declared in a prologue and
the 3) the tags be glossed as to their meaning.
SGML provides a way of doing 1) and 2) -- without restricting anyone
to any particular tagset. The problem of 3) -- standardizing a semantic
gloss -- is still up for grabs -- but I doubt if much more can
be done than to describe their meaning as clearly as possible in English.
=========================================================================
Date: 11 February 1988, 16:12:15 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROM Bibliography
------------------------------------------
From Bob Kraft <KRAFT@PENNDRLN>
A footnote to my nuancing [Lou B. wonders about the use of
"nuance" as a verb; is this unusual?] of Susan Hockey's
comments on CD-ROM:
For a more extensive and balanced treatment of the state of
text oriented CD-ROM development as of a year ago, see the
article by Linda W. Helgerson entitled "CD-ROM: the Basis for
Scholarly Research in Higher Education" in the periodical
publication called _CD Data Report_ 3.2 (December 1986) 15-18
(Langley Publications, 1350 Beverly Road, Suite 115-324,
McLean, VA 22101). This "Profile" report covers TLG, the
Brown-Harvard Isocrates Project (TLG disk "B"), the new
Perseus Project of Gregory Crane at Harvard, CCAT, and PHI.
It also includes a bibliography and set of relevant addresses.
Finally, Randall Smith of University of California in Santa Barbara
should be urged to say something in some detail about his work
with the TLG "B" disk on IBM type machines, building on the
Brown-Harvard development. He is 6500RMS@UCSBUXB.BITNET and
should not be bothered too much or his graduate program work
will suffer. But he has done important work in this important
area.
Bob Kraft, CCAT
=========================================================================
Date: 11 February 1988, 16:20:34 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: PhD exams in humanities computing (
------------------------------------------
From Nancy Ide <IDE@VASSAR>
I sympathize with the problem of putting HUMANIST mail aside for several days
with good intentions to get to it later. If I actually do get to it eventually,
I find another problem arises: the topic I'd like to comment on has been
abandoned in the current discussions. With this as a preface I'd like to say
something about Sterling Bjorndal's question concerning PhD exams in humanities
computing.
Bob Kraft made a good point: I, too, would be reluctant to consider a PhD exam
that focusses on the computer-as-tool, and I too don't see the fact that courses
are offered in the field as reason enough to argue that a PhD exam is
appropriate--such a course in the field of English literature is effectively an
extension of the methods course that every graduate student is required to take,
but which no one would consider the basis of a PHD exam. However, I can see an
exam in computer-as-method, or, put more broadly, quantitative
methods--especially where the focus is on the the relationship between
quantitative methodology and more traditional methods. In literary studies, at
least, understanding the critical approach that quantitiative methods embody and
fitting them into the critical context is a substantial task. I have argued
before that courses in literary computing should include ample consideration of
the critical approach that the methodology embodies, and that especially for
beginning graduate students, such consideration is essential in order to prevent
the inappropriate or at least, ill-considered use of computers for literary
research.
I can also see PhD exams in areas that support humanities computing that involve
a substantial theoretical component. For instance, an exam that focussed on
certain relevant areas within computer science (such as formal language and
parsing theories, or data base theory and design) or linguistics or both would
make sense.
The answer to the question about offering PhD exams in humanities computing,
then, is no in my opinion--not if the focus is tools or applications. However,
there are substantially theoretical aspects to humanities computing that could
justify such an exam. My remarks are made in the context of what I know
best--literary and linguistic studies. I hope that those of you who are in other
fields can determine whether what I say makes sense in relation to your own
disciplines.
Nancy Ide
ide@vassar
--note that my address has been and may continue to be incorrectly specified in
message headers as ide@vas780 or ide@vaspsy. Please note that these addresses
are incorrect and mail should be sent to ide@vassar. The problem should clear up
in a few weeks.
=========================================================================
Date: 11 February 1988, 16:23:31 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Time as a commodity (20 lines)
------------------------------------------
From Brian Molyneaux <AYI004@IBM.SOUTHAMPTON.AC.UK>
Mike Stairs makes some interesting comments about the value of time - at
least, his time - but I wonder if there is not some advantage in the
physical activity of working, in that spending more time with the undivided
object - a text, an image - may help one conceive of new ways of seeing it.
when I get the money, I'm going to get my 386 with as much memory as I can
cram into it, and shove in the best time-saving and time-segmenting software
I can get - but I will still spend a lot of time turning pages and dreaming -
and, gosh, I might even pick up a pen now and then, for old time's sake.
=========================================================================
Date: 11 February 1988, 16:29:43 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: The Packard Humanities Institute (63 lines)
[John M. Gleason of The PHI has kindly supplied the following
information about his Institute, which has just become a member of
HUMANIST. I am publishing his blurb here because it speaks to questions
about the PHI's work that have arisen recently. --W.M.]
The Packard Humanities Institute
300 Second Street, Suite 201
Los Altos, California 94022 USA
Telephone (415) 948-0150
Bitnet xb.m07@stanford
All of our activity currently involves collecting and analyzing
bodies of text for eventual inclusion in a CD-ROM:
1. We are collecting all Latin writings through some undecided
cutoff date. We issued in December 1987 PHI Experimental CD-ROM #1,
which contained:
4 million Latin words processed by PHI. These include most of
the authors of the Republic. For example, Cicero is complete.
Several of these texts have not been available before in
machine-readable form, e.g. Quintilian, Celsus, Seneca the
Elder.
IG 1 and 2, produced at Cornell University under a grant from
The David and Lucile Packard Foundation.
A number of miscellaneous texts produced by the Center for the
Computer Analysis of Texts at the University of Penssylvania.
Many of these were previously included in the Pilot CD-ROM of
the Thesaurus Linguae Graecae. Biblical texts include the
Septuagint, New Testament, Hebrew Old Testament, Authorized and
Revised Standard Versions. Other texts include Arabic,
Syriac, Coptic, Aramaic, French, Danish and English.
Experimental CD-ROM #1 will be ready for distribution by the
end of February 1988. The cost will be very low.
2. PHI is working with outside scholars to produce complete
morphological analyses of the Hebrew Old Testament and the Greek New
Testament.
Various other projects are being considered and even dabbled at, but
the Latin CD-ROM should occupy us for quite a while.
Main PHI personnel:
Director: David W. Packard
Associate Directors: Stephen V.F. Waite
John M. Gleason
*****END*****
=========================================================================
Date: 11 February 1988, 19:32:53 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Conference on Sentence Processing (212 lines)
------------------------------------------
From Terry Langendoen <TERGC@CUNYVM>
CUNY FIRST ANNUAL CONFERENCE ON HUMAN SENTENCE PROCESSING
MARCH 24 - 27, 1988
---------------------------
CORPORATE SPONSORS:
BELL COMMUNICATIONS RESEARCH
INTERNATIONAL BUSINESS MACHINES CORPORATION
---------------------------
- PROGRAM -
All meetings (except reception) will be held at the CUNY Graduate
Center, 33 West 42nd street in the Auditorium at the Library level.
THURSDAY, March 24, 7:00-9:00 pm
Evening wine reception at Roosevelt House, Hunter College, 47-49
East 65th Street (between Park and Madison).
FRIDAY MORNING, March 25, 9:30-12:30
David Swinney, Janet Nicol, Joan Bresnan, Marilyn Ford, Uli
Frauenfelder, and Lee Osterhout--Coreference Processing During
Sentence Comprehension.
Kenneth Forster--Tapping Shallow Processing with a Sentence
Matching Task.
Susan M. Garnsey, Michael K. Tanenhaus, and Robert M. Chapman--
Evoked Potentials and the Study of Sentence Comprehension.
Wayne Cowart--Notes on the Biology of Syntactic Processing.
Merrill Garrett--Semantic and Phonological Structure in Word
Retrieval for Language Production.
Jose E. Garcia-Albea, Susana Del Viso, and Jose M. Igoa--Movement
Errors and Levels of Processing in Sentence Production.
pa
FRIDAY AFTERNOON 2:30-6:30 Tutorial Sessions
2:30 Recent Developments in Syntactic Theory
Edwin Williams, University of Massachusetts
4:30 Computational Studies of Sentence Processing
Ronald Kaplan, Stanford University and Xerox Corporation
SATURDAY MORNING, March 26, 9:30-1:00
Stuart Shieber--An Architecture for Psycholinguistic Modeling.
Amy Weinberg--Minimal Commitment, Deterministic Parsing and the
Theory of Garden Paths.
Aravind Joshi--Processing Crossed and Nested Dependencies: An
Automaton Perspective on the Psycholingistic Results.
Eric Sven Ristad--Complexity of Linguistic Models.
Joseph Aoun and Samuel S. Epstein--A Computational Treatment of
Quantifier Scope.
Mark Steedman--Context and Composition.
Mark Johnson--Parsing as Deduction: The Use of Knowledge of
Language.
SATURDAY AFTERNOON 3:00-6:00 Special Session on Ambiguity
Resolution
Michael K. Tanenhaus, Greg Carlson, Julie Bolard and Susan Garnsey--
Lexical Parallelism.
Paul Gorrell--Establish the Loci of Serial and Parallel Effects in
Syntactic Processing.
Lyn Frazier--Ambiguity Resolution Principles.
Martin Chodorow, Harvey Slutsky, and Ann Loring--Parsing
Nondeterministic Verb Phrases.
Mitch Marcus--Whence Deterministic Parsing?
5:30 Round Table Discussion
pa
SUNDAY MORNING, March 27, 9:30-12:30
Steven P. Abney--Parsing and Psychological Validity.
Thomas G. Bever, Caroline Carrithers, and Brian McElree--The
Psychological Reality of Government and Binding Theory.
Maryellen MacDonald--Facilitation Effects from NP-Trace in Passive
Sentences.
Charles Clifton, Jr.--Filling Gaps.
Emmon Bach--Understanding Unnatural Language: Dutch and German Verb
Clusters.
Anthony S. Kroch--Grammatical and Processing Effects on the
Appearance of Resumptive Pronouns.
pa
PREREGISTRATION FORM
Name _____________________________________________________________
Address _____________________________________________________________
_____________________________________________________________
_____________________________________________________________
University or corporate affiliation (if not shown above):
_____________________________________________________________
Fees may be paid by mail with check or Post Office money order
payable to: CUNY Sentence Processing Conference
Please circle: STUDENT* NON-STUDENT
Advance registration $ 5.00 $15.00
Walk-in registration $10.00 $20.00
*To verify student status, please have a faculty member sign below:
________________ _____________________________________________
Name (printed) Faculty signature
Return this form to:
Human Sentence Processing Conference
Linguistics Program
CUNY Graduate Center
33 West 42nd St.
New York, N.Y. 10036
__ Check here to be put on a list for crash space. (You will need
to bring sleeping bag. Assume no smoking unless specially
arranged). Any special needs (we will try to accommodate):
___________________________________________________________________
A small demonstration area will be open on Friday and Saturday from
12-2pm and for two hours after the afternoon sessions. An IBM-XT
with 512K internal memory and a Symbolics 3620 (Rel.7.1) can be
made available for running demonstrations. Please check the
appropriate box if you wish to do a demo on one of these machines
and provide a brief description of your program.
IBM-XT ________________________________________________________
_________________________________________________________
Symbolics _________________________________________________________
3620
_________________________________________________________
pa
FOR FURTHER INFORMATION
Call: (212) 642-2173
Write: Human Sentence Processing Conference
Linguistics Program
CUNY Graduate Center
33 West 42nd Street
New York, N.Y. 10036
Email: TERGC@CUNYVM or JDF@CUNYVMS1 (Bitnet)
=========================================================================
Date: 11 February 1988, 22:10:46 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Job advertisement (24 lines)
------------------------------------------
From Vicky Walsh <IMD7VAW@UCLAMVS>
UCLA Humanities Computing Facility has a job open for a
programmer/analyst with experience in the Humanities.
I am looking for someone with lots of micro experience,
UNIX knowledge, use, or experience, knowledge of networking,
but especially a technical person with a good grounding in the
humanities and what humanists do for a living.
If you are interested, or know anyone who is, contact me via
bitnet (IMD7VAW@UCLAMVS) or send a letter and resume to:
Vicky A. Walsh, Humanities Computing, 2221B Bunche Hall, UCLA,
405 Hilgard Ave, LA, CA 90024-1499. PH: 213/206-1414.
I will be at Calico later this month, if anyone would like
to talk to me about the job.
Vicky Walsh
=========================================================================
Date: 12 February 1988, 09:16:24 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD what?
------------------------------------------
From Sarah Rees Jones <SRRJ1@VAXA.YORK.AC.UK>
Quiet voice from the slip-stream, "What EXACTLY is CD-ROM?"
=========================================================================
Date: 12 February 1988, 09:56:52 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: TEXAS 0.1 from science@nems.arpa (66 lines)
------------------------------------------
From David Nash <nash@cogito.mit.edu>
[Lightly edited -DGN]
Date: 11 Feb 88 06:57 EST
From: science@nems.ARPA (Mark Zimmermann)
Subject: Re: For HUMANIST: TEXAS 0.1
tnx for comments/suggestions re TEXAS! Note that the version number is
0.1 -- not meaning to imply completeness....
[Index or context displays can be copied to the Clipboard: ]
I deliberately made the buttons that cover those fields a few pixels too
small to entirely shield the text area. Try moving the HyperCard 'hand'
cursor to the very edge (left or right) of the index or context
pseudo-scrolling display, and it should turn into an I-beam, so that
you may select that text and copy/paste it ad lib. (Alternatively,
hit the "tab" key and the entire contents of the field gets selected.)
Sorry that I didn't document that.
[...] as for the problem in pasting into the "Jump to..." dialog box,
that's HyperCard's fault, and (I hope!) will be fixed in a new release
of that program soon.
Also, you are of course free to shrink the buttons yourself if you
want a different arrangement -- that's what HyperCard is for, user
flexibility....
[...] To unlock the stack so that you can move buttons around, resize
them, change fonts, etc., hold down command key before you pull down
the HC 'File' menu -- that lets you choose "Protect Stack..." and
raise the user level above Typing.
The saving to ASCII file is easy under MultiFinder -- and you can
certainly copy and accumulate arbitrary chunks of ASCII text and
export them via scrapbook/clipboard/etc. Unfortunately, the current
version of HyperCard isn't friendly enough to allow continuously-open
desk accessories, so unless you have extra memory enough to run
MultiFinder with HC, the procedure is a trifle inconvenient. That's
why I provided the "Notes Card", which of course you're free to make
multiple copies of, modify at will, etc. Hyper-Card limits text
fields to 32kB each, which is another inconvenience....
I will think about how to make jumping around in the Index better ...
would like to allow a special (perhaps option-click?) on Context or
Text words to jump the Index to that point, but haven't figured out a
good implementation yet. Proximity searching (subindexing as in my
UNIX-type C progs for browsing) is a higher priority at this time, for
me ... really need to be able to cut down on the search space when
indices get big....
As mentioned on the TEXAS v.0.1 stack, all my C source code is
available if anybody wants to do any of these extensions -- send a
formatted Mac disk, self-addressed stamped envelope, and $2 or less to
me to get it. (I need to subsidize my son who does the disk dup'ing.)
[...] ~z
=========================================================================
Date: 12 February 1988, 16:57:35 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROM and related technology at Penn
------------------------------------------
From Jack Abercrombie <JACKA@PENNDRLS>
Bob K. neglected to report on all forms of CD-ROM and related
technology available within CCAT. We have two addition WORM
drives installed in a computer lab on campus. These WORMs
(400 megs of storage) are used heavily in the following ways:
1. Masters for gang copying of the New Testament, LXX, and
other texts are stored on the WORMs. Our staff loads individual
diskettes with duplicate of parts of the texts from the WORMs
over a network.
2. The South Asia Department and other departments at Penn have
archival texts stored on the WORMs for use by faculty and
graduate students. The students can search and concord texts
off the WORMs or copy the texts to their diskettes for use
in another installation. Incidentally we have a major effort
this year in transfering our Asian language holdings into
electronic form much as we did last year for modern Russian
poetry.
3. The WORMs also hold digitized pictures of material for papyrology,
language instruction, and textual research in which pictorial
information is closely linked to ASCII texts. A user can access
the WORMs and search both texts and pictures together.
Jack Abercrombie
Director of CCAT,
Assistant Dean for Computing,
University of Pennsylvania
=========================================================================
Date: 12 February 1988, 22:45:38 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Ibycus UK
------------------------------------------
From John L. Dawson <JLD1@PHX.CAM.AC.UK>
My company (Humanities Computing Consultants Ltd) has the agency for
distributing Ibycus machines in Britain, so I am in close touch with everyone
in Britain who has an Ibycus (all of them micro versions).
=========================================================================
Date: 12 February 1988, 22:47:31 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: TLG CD-ROM B usage (50 lines)
------------------------------------------
From Randall M. Smith <6500rms@UCSBUXB.BITNET>
This is a partially rewritten copy of a letter which I sent directly to
Susan Hockey. I think it will serve as a brief description of the work
which I have been doing. I wasn't sure if people in HUMANIST would be
interested in all of these details, but I will gladly share them:
At the Classics Department at the University of California at Santa Barbara,
we are using the TLG CD-ROM #B, which was indexed by Greg Crane at the
Harvard Classics department and Paul Kahn at IRIS at Brown. We are using it
on an AT clone with software which I have been adapting from Greg Crane's
UNIX software. It is true that sequential searching on the AT is abysmally
slow, but the index searching is very fast. We can find a word with a few
occurrences on the entire disc in less than a minute, and displaying the
Greek text on the screen takes another minute or two. While this is not as
fast as a program like the BYU concordance program, this is working with a
database over 200MB in size. Since this is not a commercial system, we do
have free access to the text, and pointers to the correct place in the text
are provided by the index system. This seems to me the ideal compromise
since we can revert to a (slow) sequential search if we ever need to. We
are currently working to include relational searches, which can be
implemented fairly easily using the information provided by the indices. It
should be fairly quick, though it may not be exactly "interactive." Also,
we are using a general purpose CD filing system (the Comapct Disc Filing
System, developed by Simson Garfinkel at the MIT media lab) which is rather
slow; I am sure that we could speed operations immensely by replacing this
with a CD interface designed specifically for this application.
Because of my experience with the indices I am all in favor of indices being
provided on the TLG and PHI CD-ROM's. I am told that the new TLG CD-ROM #C
has an index system which provides the number of occurrences of a word in
each author, but no references into the text to retrieve the context. I
suppose that this eliminates scanning an author who does not use a given
word, but it is still a lengthy process to search the entire disc.
In any case, we are using our system to search for occurrences of words; we
recently looked for _monadikes_ in conjunction with _stigmes_, though we had
to do the correlations by hand. (We actually used the same technique which
we are writing into the software.) We also ran a search for words built on
the stem _vaukrar-_ for a professor in the history department. One of our
professors is working on a project which will involve searching for specific
verb stems in conjunction with certain endings. Also, students in Greek
Prose Composition have used the computer to verify the existence of various
forms or stems in Attic Prose authors. We have not yet tried to do any sort
of thematic searching or anything that sophisticated, but we have been quite
pleased so far.
I would be pleased to answer any questions that anyone may have about our
software. (If people are interested in the nitt-gritty on the index system
I would be happy to post a brief description of how it works.) I would also
be interested in other people's ideas about or experience with indices on
CD-ROM's.
Randall M. Smith (6500RMS@UCSBUXB.BITNET)
Department of Classics
University of California
Santa Barbara, CA 93106
=========================================================================
Date: 12 February 1988, 22:50:30 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Job advertisement (39 lines)
------------------------------------------
From Susan Kruse <UDAA270@VAXA.CC.KCL.AC.UK>
KING'S COLLEGE LONDON
University of London
COMPUTING CENTRE
The post of ASSISTANT DIRECTOR HUMANITIES AND INFORMATION MANAGEMENT is
available within the Centre. This senior post, supported by 6 specialist
staff, carries particular responsibility for developing and supporting
computing applications in the Humanities Departments, an area of the
Centre's work to which the College attaches great importance. The
successful applicant will play a crucial role as the Centre carries
through a major expansion of its computing and communications facilities
at all levels from the micro to the mainframe. The College's central
computing provision will be based on a large VAX Cluster.
Applicants should possess a degree in an appropriate discipline and
be able to demonstrate a substantial degree of relevant computing and
managerial experience.
The appointment will be made at a suitable point, depending on age,
qualifications and experience, on the academic-related grade 5 scale
(1st March 1988): #21,055 - 24,360 per annum including London
Allowance.
Further particulars and application forms may be obtained from the
Assistant Personnel Officer, King's College London, Strand, London
WC2R 2LS. The closing date for the receipt of applications is
2nd March 1988.
=========================================================================
Date: 12 February 1988, 23:06:38 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: whos to blame (57 lines!)
------------------------------------------
From Sebastian Rahtz <spqr@CM.SOTON.AC.UK>
ok, lets see who dominates HUMANIST; i just took my HUMANIST backlog
(I keep most of it) for the last six months or so, and picked out
those whose name I could easily identify (is those with decent mail
headers!),which gave me 121 messages.
The following appeared once:
ked@coral.berkeley.edu Robert Amsler
Tom Benson John Bradley Dan Brink Robin C. Cover Jim Cerny Dan Church
Stephen DeRose Charles Faulhaber Robert Gauthier David Graham Doug Hawthorne
Susan Hockey Randall Jones May Katzen Bob Kraft Ian Lancashire
Joanne M. Badagliacco George M. Logan Brian Molyneaux Elli Mylonas
Stephen Page Rosanne Potter Sarah Rees Jones Laine Ruus David Sitman
Mike Stairs Wayne Tosh Vicky Walsh Keith Whitelam Ronnie de Sousa
the following twice:
George Brett Allen H. Renear Charles Faulhaber M.J. CONNOLLY Malcolm Brown
Jack Abercrombie Randall Smith Terry Langendoen
and thrice:
Richard Goerwitz Lou Burnard Dr Abigail Ann Young
and four times
Sterling Bjorndahl Norman Zacour
but the winners are:
5 Dominik Wujastyk
5 David Durand
5 Nancy Ide
5 David Nash
5 Michael Sperberg-McQueen
5 Robert Amsler
6 Mark Olsen
6 James H. Coombs
6 Bob Kraft
I have left out myself and Willard.......
sebastian rahtz
PS please dont bother checking this; I just spent 2 minutes with
'grep' and 'sort' while waiting for something. Lou Burnard promises
a proper analysis
=========================================================================
Date: 14 February 1988, 14:54:44 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Utility of CD-ROMs (30 lines)
------------------------------------------
From amsler@flash.bellcore.com (Robert Amsler)
The question of utility of CD-ROMs involves both the issue
of what type of data one would want on CD-ROMs, which affects
how many people would buy the CD-ROM--but also how they would
want to access that data. I believe this was mentioned
several months ago as an issue for CD-ROM.
I would expect CD-ROM access to be such that I could easily
download any portion of the available information for
further manipulation, editing, etc. CD-ROMs lacking such
accessibility would not be totally impractical, but would
only be attractive to a subset of the total potential users.
If CD-ROM publishers decide that they wish to prohibit this
kind of access and only provide the equivalent of contemporary
database access, to selected items without downloading
permission--then I am more pessimistic about the future of
CD-ROM apart from a storage medium incorporated into specific
hardware-based systems intended solely for the use of that
CD-ROM.
=========================================================================
Date: 15 February 1988, 12:54:42 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: What is CD-ROM? (23 lines)
------------------------------------------
From M.J. CONNOLLY (Slavic/Eastern) <CNNMJ@BCVMS>
For Sarah Rees Jones:
'Tain't exactly the most up-to-date presentation any more,
but your question will perhaps find a ready answer in
Laub, Leonard: "What is CD ROM?"
ex: Lambert, Steve / Suzanne Ropiequet:
_CD ROM. The new papyrus._
(Microsoft Press) Redmond WA, 1986c.
ISBN: 0-914845-74-8
TK7882.C56N49 1986
Other articles in this uneven but highly informative collection may also
answer some of the questions others may be afraid to ask (but bravo to you
for asking!).
=========================================================================
Date: 15 February 1988, 16:12:57 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: This is a test (11 lines)
AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZzzzzzzzzzzzzzzzzzzzz!
=========================================================================
Date: 16 February 1988, 16:25:42 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: A file-server for HUMANIST (104 lines)
Dear Colleague:
You may recall that some months ago we began trying to set up a
file-server here so that HUMANISTs could download files of common
interest without having to trouble anyone other than themselves.
At long last, due to the untiring efforts of Steve Younker, our
Postmaster, we seem to have succeeded. Here are instructions on
how to use this file-server.
Two separate but very similar operations will usually be
required: (1) to discover what files the file-server has to offer;
and (2) to request one of these. What you do will depend on the
kind of system you are using and the network to which it is
attached. We think the following is complete, but we are quite
prepared to be told that some variation has been overlooked. If
you have trouble and think that it is attributable to faulty or
missing instructions, please let us know.
Note that in the following what you type is in caps; all
semicolons and periods are not part of the commands to be typed;
and addresses expressed as USERID AT NODENAME may have to be
entered as USERID@NODENAME.
A. If you are on Bitnet/NetNorth/EARN and use an IBM VM/CMS
system:
- for (1) send the interactive command:
TELL LISTSERV AT UTORONTO GET HUMANIST FILELIST HUMANIST
- for (2) send the command:
TELL LISTSERV AT UTORONTO GET fn ft HUMANIST
where fn = filename, ft = filetype (of the file you've chosen)
B. If you are on Bitnet/NetNorth/EARN and use a Vax VMS system,
you may be able to use the following interactive procedure:
- for (1) type:
SEND/REMOTE UTORONTO LISTSERV
you should get the prompt:
(UTORONTO)LISTSERV:
then type:
GET HUMANIST FILELIST HUMANIST
- for (2) repeat the above but substitute GET fn ft HUMANIST,
where fn and ft are as above.
C. If you are on Bitnet/NetNorth/EARN but don't use an IBM VM/CMS
system, or if you are not on Bitnet, etc.:
- for (1) use your mailer of whatever kind, e.g., MAIL, to send an
ordinary message to LISTSERV AT UTORONTO and include as
the one and only line,
GET HUMANIST FILELIST HUMANIST
This should be on the first line of mail message. In other
words, there should be no blank lines pGeceding this line.
- for (2) repeat the above but substitute for the first line GET
fn ft HUMANIST, where fn and ft are as above.
D. As an alternative to B, use whatever command you have to send
a file, e.g., SENDFILE, to LISTSERV AT UTORONTO, the first and
only line of this file being again,
for (1):
GET HUMANIST FILELIST HUMANIST
and for (2)
GET fn ft HUMANIST
At the moment the offerings are not extensive, and you've
probably all seen what's there, but we'd be pleased if you would
test the procedures anyhow.
If you have enduring material of possible interest to HUMANISTs,
please consider submitting it for storage on our file-server. Send
me a note describing what you have and I'll let you know. Since
space on the server is not infinite, we need to exercise some
restraint.
Yours, Willard McCarty (mccarty@utorepas <NetNorth>)
Steve Younker (postmstr@utoronto <NetNorth>)
=========================================================================
Date: 16 February 1988, 19:57:52 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: More on software viruses (138 lines)
----------------------------
From Y. Radai <RADAI1@HBUNOS.BITNET>, with thanks
Issue 74 of the Info-IBMPC digest contained a description of a "virus"
discovered at Lehigh University which destroys the contents of disks after
propagating itself to other disks four times. Some of us here in Israel,
never far behind other countries in new achievements (good or bad), are
suffering from what appears to be a local strain of the virus. Since it
may have spread to other countries (or, for all we know, may have been im-
ported from abroad), I thought it would be a good idea to spread the word
around.
Our version, instead of inhabiting only COMMAND.COM, can infect any ex-
ecutable file. It works in two stages: When you execute an infected EXE
or COM file the first time after booting, the virus captures interrupt 21h
and inserts its own code. After this has been done, whenever any EXE file
is executed, the virus code is written to the end of that file, increasing
its size by 1808 bytes. COM files are also affected, but the 1808 bytes
are written to the beginning of the file, another 5 bytes (the string
"MsDos") are written to the end, and this extension occurs only once.
The disease manifests itself in at least three ways: (1) Because of this
continual increase in the size of EXE files, such programs eventually be-
come too large to be loaded into memory or there is insufficient room on
the disk for further extension. (2) After a certain interval of time
(apparently 30 minutes after infection of memory), delays are inserted so
that execution of programs slows down considerably. (The speed seems to be
reduced by a factor of 5 on ordinary PCs, but by a smaller factor on faster
models.) (3) After memory has been infected on a Friday the 13th (the next
such date being May 13, 1988), any COM or EXE file which is executed on
that date gets deleted. Moreover, it may be that other files are also af-
fected on that date; I'm still checking this out.
(If this is correct, then use of Norton's UnErase or some similar utility
to restore files which are erased on that date will not be sufficient.)
Note that this virus infects even read-only files, that it does not
change the date and time of the files which it infects, and that while the
virus cannot infect a write-protected diskette, you get no clue that an at-
tempt has been made by a "Write protect error" message since the pos-
sibility of writing is checked before an actual attempt to write is made.
It is possible that the whole thing might not have been discovered in
time were it not for the fact that when the virus code is present, an EXE
file is increased in size *every* time it is executed. This enlargement of
EXE files on each execution is apparently a bug; probably the intention was
that it should grow only once, as with COM files, and it is fortunate that
the continual growth of the EXE files enabled us to discover the virus much
sooner than otherwise.
From the above it follows that you can fairly easily detect whether your
files have become infected. Simply choose one of your EXE files
(preferably your most frequently executed one), note its length, and ex-
ecute it twice. If it does not grow, it is not infected by this virus.
If it does, the present file is infected, and so, probably, are some of
your other files. (Another way of detecting this virus is to look for the
string "sUMsDos" in bytes 4-10 of COM files or about 1800 bytes before the
end of EXE files; however, this method is less reliable since the string
can be altered without attenuating the virus.)
If any of you have heard of this virus in your area, please let me know;
perhaps it is an import after all. (Please specify dates; ours was noticed
on Dec. 24 but presumably first infected our disks much earlier.)
Fortunately, both an "antidote" and a "vaccine" have been developed for
this virus. The first program cures already infected files by removing the
virus code, while the second (a RAM-resident program) prevents future in-
fection of memory and displays a message when there is any attempt to in-
fect it. One such pair of programs was written primarily by Yuval Rakavy,
a student in our Computer Science Dept.
In their present form these two programs are specific to this particular
virus; they will not help with any other, and of course, the author of the
present virus may develop a mutant against which these two programs will be
ineffective. On the other hand, it is to the credit of our people that
they were able to come up with the above two programs within a relatively
short time.
My original intention was to put this software on some server so that it
could be available to all free of charge. However, the powers that be have
decreed that it may not be distributed outside our university except under
special circumstances, for example that an epidemic of this virus actually
exists at the requesting site and that a formal request is sent to our head
of computer security by the management of the institution.
Incidentally, long before the appearance of this virus, I had been using
a software equivalent of a write-protect tab, i.e. a program to prevent
writing onto a hard disk, especially when testing new software. It is
called PROTECT, was written by Tom Kihlken, and appeared in the Jan. 13,
1987 issue of PC Magazine; a slightly amended version was submitted to the
Info-IBMPC library. Though I originally had my doubts, it turned out that
it is effective against this virus, although it wouldn't be too hard to
develop a virus or Trojan horse for which this would not be true. (By the
way, I notice in Issue 3 of the digest, which I received only this morning,
that the version of PROTECT.ASM in the Info-IBMPC library has been replaced
by another version submitted by R. Kleinrensing. However, in one respect
the new version seems to be inferior: one should *not* write-protect all
drives above C: because that might prevent you from writing to a RAMdisk or
an auxiliary diskette drive.)
Of course, this is only the beginning. We can expect to see many new
viruses both here and abroad. In fact, two others have already been dis-
covered here. In both cases the target date is April 1. One affects only
COM files, while the other affects only EXE files. What they do on that
date is to display a "Ha ha" message and lock up, forcing you to cold boot.
Moreover (at least in the EXE version), there is also a lockup one hour
after infection of memory on any day on which you use the default date of
1-1-80. (These viruses may actually be older than the above-described
virus, but simply weren't noticed earlier since they extend files only
once.)
The author of the above-mentioned anti-viral software has now extended
his programs to combat these two viruses as well. At present, he is con-
centrating his efforts on developing broad-spectrum programs, i.e. programs
capable of detecting a wide variety of viruses.
Just now (this will give you an idea of the speed at which developments
are proceeding here) I received notice of the existence of an anti-viral
program written by someone else, which "checks executable files and reports
whether they include code which performs absolute writes to disk, disk for-
matting, writes to disk without updating the FAT, etc." (I haven't yet
received the program itself.)
Y. Radai
Computation Center
Hebrew University of Jerusalem
RADAI1@HBUNOS.BITNET
=========================================================================
Date: 16 February 1988, 20:05:46 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: IBM Regional Conference in Princeton, NJ (126 lines)
----------------------------
From Jack Abercrombie <JACKA@PENNDRLS>
IBM CONFERENCE ON ACADEMIC COMPUTING sponsored
by Princeton University, University of Pennsylvania, and
IBM Corporation
I have selected out the following presentations that relate
to computing in the Humanities from the IBM Regional
Conference to be held in Princeton N.J. on 18th-19th March.
This regional IBM conference is different than other such
conferences this year in that the emphasis here is on
humanities computing rather than computing in the hard
sciences or engineering. On the 18th March, colleagues will
present their work in panel discussions and seminar sessions.
On the 19th, there will be general demonstration of software.
Any readers interested in further details on the conference
may write to me directly.
Thank you.
*********************************************************************
10:00-NOON (March 18, 1988)
FOREIGN LANGUAGE INSTRUCTION
R. Allen Computers and Proficiency-Based Language Acquisition:
(Univ. of PA) The Case of Arabic
P.A. Batke CAI on Micros at Duke University
(Duke Univ.)
D.F. Sola TECHNOLOGY TRANSFER: Databased Foreign Language Writing
(Cornell Univ.)
R.M. Wakefield The Development of Listening Comprehension in
(Univ. Minn.) German with IBM AT, InfoWindow and Laserdisk Video
CONCURRENT PANELS(10:00-noon) NOT LISTED HERE: Economics, Psychology,
Technology-based curriculum development, and Information Sharing.
1:30-3:00
HISTORY
W.O. Beeman Linking the Continents of Knowledge
(Brown Univ.)
D.W. Miller The Great American History Machine
(Carnegie-Mellon Univ.)
J.E. Semonche Encountering the Past: Computer Simulations in
(Univ. of N.C.) U.S. history
PANEL DISCUSSION on LANGUAGE & LITERATURE
J.S. Noblitt (Cornell University), P.A. Batke (Duke University),
R.L. Jones (Brigham Young University), G.P. Landow (Brown University)
USE OF CAD IN ARCHITECTURE/CLASSICAL ARCHAEOLOGY
D.G. Romano The Athena Polias Project:
(Univ. of PA) Archaeology, Architecture, Athletics and AutoCAD
CONCURRENT PANELS(1:30-3:00) NOT LISTED HERE: Mathematics,
Instructional Video Disc/CD ROM.
3:30-5:00
ARCHAEOLOGY
H. Dibble Interactive Computer Graphics, Imaging and Databasing:
(Univ. of PA) Applications to a Stone Age Archaeological
Project in France
T.D. Price Archaeological Concepts for Undergraduates:
(Univ. of Wisc.) The Case of the Mysterious Fugawi
R. Saley Two Archaeologically-Based Computer Applications
(Harvard Univ.)
TEXTUAL ANALYSIS
J.R. Abercrombie Teaching Computer-Assisted Research Techniques to
(Univ. of PA) Future Scholars
R.L. Jones The Creation of a Literary Data Base: Two Approaches
(BYU)
I. Lancanshire The Art and Science of Text Analysis
(Univ. of Toronto)
MUSIC
R.B. Dannenberg Real Time Music Understand
(Carnegie-Mellon Univ.)
F.T. Hofstetter To be announced
(Univ. of Del.)
R. Pinkston A Practical Approach to Software Synthesis
(Univ. of Texas) on the IBM PC
CONCURRENT PANELS(3:30-5:00) NOT LISTED HERE: Biology,
Examples of Instructional Computing.
=========================================================================
Date: 16 February 1988, 21:38:32 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: A query and a (very brief) return to Hypertext (29 lines)
----------------------------
From Stephen R. Reimer <SREIMER@UALTAVM>
First, I am interested in obtaining a copy of Wilhelm Ott's "TUSTEP" program:
can anyone advise me on how to proceed?
Secondly, I noticed a series of quotations from Ted Nelson in the February
BYTE magazine (p. 14): in case anyone missed it, I offer just a small
sampling. "Xanadu /his hypertext system/ is not a conventional project. . . .
This is a religion." "The objective is to save humanity before we send it into
the garbage pail. We must remove the TV-induced stupor that lies like a fog
across the land . . . /and/ make the world safe for smart children." Our
children, however, are threatened not only by the influence of TV, but also by
the influence of database software: "Compartmentalized and stratified fields
produce compartmentalized and stratified minds." These quotations are from a
speech given at the Software Entrepreneur's Forum in Palo Alto recently. (He
also offered a reflection on publishers and CD-ROMs: "Information lords
offering information to information peons.") Is this man sane? Is BYTE
misrepresenting him?
Stephen Reimer, University of Alberta (SREIMER@UALTAVM)
=========================================================================
Date: 17 February 1988, 09:13:41 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Updated report on the Israeli virus (111 lines)
[Yisrael Radai has sent me a revised version of his report on the recent
MS-DOS virus discovered in Israel. It is intended to replace what I
circulated yesterday on this subject. --WM]
----------------------------
From Y. Radai <RADAI1@HBUNOS.BITNET>, with thanks
Issue 74 of the Info-IBMPC digest contained a description of a "virus"
discovered at Lehigh University which destroys the contents of disks after
propagating itself to other disks four times. Some of us here in Israel, never
far behind other countries in new achievements (good or bad), are suffering
from what appears to be a local strain of the virus. Since it may have spread
to other countries (or, for all we know, may have been imported from abroad),
I thought it would be a good idea to spread the word around.
Our version, instead of inhabiting only COMMAND.COM, can infect any execu-
table file. It works in two stages: When you execute an infected EXE or COM
file the first time after booting, the virus captures interrupt 21h and inserts
its own code. After this has been done, whenever any EXE file is executed, the
virus code is written to the end of that file, increasing its size by 1808
bytes. COM files are also affected, but the 1808 bytes are written to the
beginning of the file, another 5 bytes (the string "MsDos") are written to the
end, and this extension occurs only once.
The disease manifests itself in at least three ways: (1) Because of this
continual increase in the size of EXE files, such programs eventually become too
large to be loaded into memory or there is insufficient room on the disk for
further extension. (2) After a certain interval of time (apparently 30 minutes
after infection of memory), delays are inserted so that execution of programs
slows down considerably. (The speed seems to be reduced by a factor of 5 on
ordinary PCs, but by a smaller factor on faster models.) (3) After memory has
been infected on a Friday the 13th (the next such date being May 13, 1988), any
COM or EXE file which is executed on that date gets deleted. Moreover, it may
be that other files are also affected on that date (in which case use of
Norton's UnErase or some similar utility to restore files which are erased on
that date will not be sufficient).
Note that this virus infects even read-only files, that it does not change
the date and time of the files which it infects, and that while the virus cannot
infect a write-protected diskette, you get no clue that an attempt has been made
by a "Write protect error" message since the possibility of writing is checked
before an actual attempt to write is made.
It is possible that the whole thing might not have been discovered in time
were it not for the fact that when the virus code is present, an EXE file is
increased in size *every* time it is executed. This enlargement of EXE files
on each execution is apparently a bug; probably the intention was that it should
grow only once, as with COM files, and it is fortunate that the continual growth
of the EXE files enabled us to discover the virus much sooner than otherwise.
From the above it follows that you can fairly easily detect whether your
files have become infected. Simply choose one of your EXE files (preferably
your most frequently executed one), note its length, and execute it twice. If
it does not grow, it is not infected by this virus. If it does, the present
file is infected, and so, probably, are some of your other files. (Another way
of detecting this virus is to look for the string "sUMsDos" in bytes 4-10 of
COM files or about 1800 bytes before the end of EXE files; however, this method
is less reliable since this string can be altered without attenuating the virus.
If any of you have heard of this virus in your area, please let me know;
perhaps it is an import after all. (Please specify dates; ours was noticed on
Dec. 24 but presumably first infected our disks much earlier.)
Fortunately, both an "antidote" and a "vaccine" have been developed for this
virus. The first program cures already infected files by removing the virus
code, while the second (a RAM-resident program) prevents future infection of
memory and displays a message when there is any attempt to infect it. One such
pair of programs was written primarily by Yuval Rakavy, a student in our
Computer Science Dept.
In their present form these two programs are specific to this particular
virus; they will not help with any other, and of course, the author of the
present virus may develop a mutant against which these two programs will be
ineffective. On the other hand, it is to the credit of our people that they
were able to come up with the above two programs within a relatively short
time.
My original intention was to put this software on some server so that it
could be available to all as a public service. However, the powers that be have
decreed that it may not be distributed outside our university unless an
epidemic of this virus actually exists at the requesting site and a formal
request is sent in writing to our head of computer security by the management
of the institution.
Incidentally, long before the appearance of this virus, I had been using a
software equivalent of a write-protect tab, i.e. a program to prevent writing
onto a hard disk, especially when testing new software. It is called PROTECT,
was written by Tom Kihlken, and appeared in the Jan. 13, 1987 issue of PC
Magazine; a slightly amended version was submitted to the Info-IBMPC library.
Though I originally had my doubts, it turned out that it is effective against
this virus, although it wouldn't be too hard to develop a virus or Trojan horse
for which this would not be true.
I have ordered (on a trial basis) a hardware write-protection mechanism which
I heard of. If it works, I'll post an evaluation of it to the digest.
Of course, this is only the beginning. We can expect to see many new viruses
both here and abroad. In fact, two others have already been discovered here.
In both cases the target date is April 1. One affects only COM files, while
the other affects only EXE files. What they do on that date is to display a
"Ha ha" message and lock up, forcing you to cold boot. Moreover (at least in
the EXE version), there is also a lockup, *without any message*, one hour after
infection of memory on any day on which you use the default date of 1-1-80.
The identifying strings are "APRIL 1ST", VIRUS" and "sURIV". (These viruses
may actually be older than the above-described virus, but simply weren't
noticed earlier since they extend files only once.)
The author of the above-mentioned anti-viral software has now extended his
programs to combat these two viruses as well. At present, he is concentrating
his efforts on developing broad-spectrum programs, i.e. programs capable of
detecting a wide variety of viruses.
Yisrael Radai
Computation Center
Hebrew University of Jerusalem
RADAI1@HBUNOS.BITNET
=========================================================================
Date: 17 February 1988, 09:28:34 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Our new Republic of Letters (31 lines)
Jean-Claude Guedon, a new HUMANIST, has sent me the following
observation on our discussion group. A "beginner's mind," as a teacher
of mine once used to say, is open to perceptions that experience and
specialization tend to attenuate. So I'm grateful for his beginner's
glimpse.
"After sampling some of the discussions going on and looking at
the various interests of the members, I am rather glad I am part of
[HUMANIST]. In a sense, groups like the Humanist, based on
efficient means of communication, rebuild a situation not unlike
that of the old "Republic of Letters". The comparison
appears even more convincing if we remember that many members of this
informal republic were the equivalent of modern functionaries and could,
therefore, take advantage of the mail systems developed for kings and
princes. Our only challenge - and it is not a small one - is to be as
good as they once were!"
Jean-Claude Guedon
Institut d'histoire et de
Sociopolitique des sciences
et Litterature comparee
Universite de Montreal
=========================================================================
Date: 17 February 1988, 09:40:02 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: A new text-analysis package for MS-DOS (40 lines)
The following is republished from another Canadian ListServ discussion
group, ENGLISH. My thanks to Marshall Gilliland, the editor of that
group, who is also a HUMANIST. -- WM
--------------------------------------------------------------------------
From <GILLILAND@SASK>
There is a review of a new program for DOS micros in the January
issue of RESEARCH IN WORD PROCESSING NEWSLETTER, and it may interest some of
you. The reviewer is Bryan Pfaffenberger, author of several books on personal
computing.
The program is TEXTPACK V, version 3.0, on four 5 1/4" floppies, from
Zentrum fur Umfragen, Methoden, und Analysen e.V.
Postfach 5969
D-6800 Mannheim-1, West Germany Cost: $60.00 (US), postpaid
This is the micro version of a mainframe software package for content
analysis. Pfaffenberger says in his summary that it "is probably the most
powerful content analysis program available . . .[and is] a family of related
text analysis programs that include procedures for generating simple word
frequency analysis, creating key-word-in-context concordances, compiling
indexes, and comparing the vocablularies of two texts. Although far from
user-friendly in the Macintosh sense, Textpack's programs are well-conceived,
fast, and powerful. The documentation is cryptic and dry, but a reasonably
proficient PC user can manage it. Textpack V can, in sum, do just about
everything that a literary scholar or political scientist would want to do with
a computer-readable text. Academic computing centers take note: when the
humanists and social scientitsts start knocking on your door and talking about
text analysis, you'll do well to have a copy of the MS-DOS version of Textpack
V around."
M.G.
=========================================================================
Date: 17 February 1988, 12:50:56 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Activities on HUMANIST, second report (449 lines)
Dear Colleagues:
Today HUMANIST has for the first time reached a (momentary) total of 200
listed members. Since 7 of these are actually redistribution lists, this
numeriological fact is somewhat fuzzy. Nevertheless, an occasion to
celebrate, if you need one.
To mark the event I am circulating Lou Burnard's report on our online
activites for about the last six months. It has been submitted to the
Newsletter of the ACH.
Yours, Willard McCarty
HUMANIST So Far:
A Report on Activities, August 1987 to January 1988
by
Lou Burnard, Oxford University Computing Service
This is the second in a series of reports on HUMANIST, the
Bitnet/NetNorth/EARN discussion group for computing humanists
that is sponsored jointly by the ACH, the ALLC and the University
of Toronto's Centre for Computing in the Humanities. The first
report, published in the ACH Newsletter, vol. 9, no. 3 (Fall 1987)
and circulated on HUMANIST itself, covered the initial two months.
This one reviews the subsequent six months of strenuous activity.
At the time of writing, participants in HUMANIST number nearly
180 and are spread across 11 countries (see table 1). Members are
largely, but by no means exclusively, from North American
academic computing centres. Table 2 shows that less than half of
these participants actually create the messages that all,
perforce, are assumed to read; out of over 600 messages during
the last six months, nearly 500 were sent by just eight people,
and out of 180 subscribers, 107 have never sent a message. In
this, as in some other respects, HUMANIST resembles quite closely
the sort of forum with which most of its members may be presumed
to be most familiar: the academic committee. Personality traits
familiar from that arena - the aggressive expert, the diffident
enquirer, the unsuppressable bore - are equally well suited to
this new medium: both young turks and old fogies are also to be
found.
Some of the rhetorical tricks and turn-taking rules appropriate
to the oral medium find a new lease of life in the electronic
one; indeed it is clear that this medium approximates more
closely to orature than to literature. Its set phrases and jargon
often betray an obsession with informal speech, and a desire to
mimic it more *directly*, re-inventing typographic conventions
for the purpose. As in conversation too, some topics will be
seized upon while others, apparently equally promising, sink like
stones at their first appearance; the wise HUMANIST, like the
good conversationalist, learns to spot the right lull into which
to launch a new topic. Perhaps because the interactions in an
electronic dialogue are necessarily fewer and more spaced out (no
pun intended) than those in face-to-face speech, misunderstanding
and subsequent clarifications seem to occur more often than one
might expect. However, the detailed functional analysis of
electronic speech acts is an interesting but immense task, which
I regretfully leave to discourse analysts better qualified than
myself. (Needless to say, HUMANIST itself reported at least two
such studies of "electronic paralanguage" during the period under
review).
For the purposes of this survey I identified four broad
categories of message. In category A (for Administrative) go test
messages, apologies for electronic disasters, announcements -but
not discussion- of policy and a few related and oversized items
such as the beginner's Guide to HUMANIST and the invaluable
"Biographies". (On joining each member submits a brief
biographical statement or essay; these are periodically gathered
together and circulated to the membership.) Messages in category
A totaled 57 messages, 18% of all messages, or 25% by bulk.
In category C (for Conference) go announcements of all other
kinds - calls for papers, job advertisements, conference reports,
publicity for new software or facilities etc. The figures here
totaled 39 messages, 12% of all messages, 20% of all lineage. As
might be expected, categories A and C are disproportionately
lengthy and not particularly frequent. I do not discuss them much
further.
In category Q (for query) go requests for information on
specified topics, public answers to these, and summaries of such
responses. These amounted to 20% of all messages but (again
unsurprisingly) only 10% of all lines. I have been unable, as
yet, to gather any statistics concerning the extent of private
discussions occurring outside the main HUMANIST forum, though it
is clear from those cases subsequently summarised that such
discussions not only occur but are often very fruitful. What
proportion of queries fall on stony ground is also hard, as yet,
to determine.
In category D (for discussion) I place those messages perhaps
most typical of HUMANIST: general polemic, argument and
disputation. Overall, these messages account for nearly 50% of
the whole, (44% by line) and thus clearly dominate the network.
With the curious exception of November, the relative proportions
of D category messages remains more or less constant within each
month. As table 5 shows, the relative proportions of other types
of message are by no means constant over time.
Of course, assigning a particular message to some category is not
always a clear-cut matter. Correspondents occasionally combine a
number of topics - or kinds of topic - in a single message.
Moreover, the medium itself is still somewhat unreliable.
Internal evidence shows that not all messages always get through
to all recipients, nor do they always arrive in the order in
which they were despatched or (presumably) composed. This report
is based only on the messages which actually reached me here in
Oxford; concerning the rest I remain (on sound Wittgensteinian
principles) silent. I am equally silent on messages in categories
A and C above, which are of purely transient interest.
Space precludes anything more than a simple indication of the
range of topics on which HUMANISTs have sought (and often
obtained) guidance. In category Q over the last six months I
found messages asking for information on typesetters with a
PostScript interface, on scanners capable of dealing with
microform, about all sorts of different machine readable texts
and about software for ESL teaching, for library cataloguing, for
checking spelling, for browsing foreign language texts, and for
word processing in Sanskrit. HUMANISTs asked for electronic mail
addresses in Greece and in Australia, for concordance packages
for the Macintosh and the Amiga ST, for address lists and
bibliographies; they wondered who had used the programming
language Icon and whether image processing could be used to
analyse corrupt manuscripts; they asked for details of the
organisational structure of humanities computing centres and of
the standards for cataloguing of computer media.
Above all however, HUMANISTs argue. Back in August 1987 HUMANIST
was only a few months old, yet many issues which have since
become familiar to its readership were already on the agenda.
Where exactly are the humanities as a discipline? what is their
relation to science and technology? Correspondents referred to
the infamous "Two cultures" debate of the late fifties, somehow
now more relevant to the kind of "cross-disciplinary soup we are
cooking", but rather than re-flaying that particular dead horse,
the discussion moved rapidly to another recurrent worry: did the
introduction of computing change humanistic scholarship
quantitatively or qualitatively? Does electronic mail differ only
in scale and effectiveness from the runner with the cleft stick?
Do computers merely provide better tools to do tasks we have
always wanted to do? The opinion of one correspondent ("if
computers weren't around, I doubt very much if many of the ways
we think about texts would have come to be") provoked another
into demanding (reasonably enough) evidence. Such evidence as was
forthcoming, however, did concede the point that "it could all be
done without computers in some theoretical sense, but certainly
not as quickly". Reference was made to a forthcoming collection
of essays which might settle whether or not it was chimerical to
hope that computers will somehow assist not just in marshaling
the evidence but in providing interpretations of it.
A second leitmotiv of HUMANIST discussions was first heard
towards the end of August, when an enquiry about the availability
of some texts in machine readable form provoked an assertion of
the moral responsibility the preparers of such texts should
accept for making their existence well known and preferably for
depositing them in a Text Archive for the benefit of all. A note
of caution concerning copyright was also first sounded here, and
it was suggested that those responsible for new editions should
always attempt to retain control over the rights to electronic
distribution of their material.
With the start of the new academic year, HUMANIST became more
dominated by specific enquiries, and a comparatively low key
wrangle about whether or not product announcements, software
reviews and the like should be allowed to sully its airspace.
Characteristically, this also provided the occasion for some
HUMANISTs to engage in an amusing socio-linguistic discussion of
the phenomenon known as "flaming", while others plaintively asked
for "less chatter about the computer which is only a tool and
more about what we are using it for". It appeared that some far
flung HUMANISTs actually have to pay money proportionate to the
size of the mailings they accept, recalling an earlier remark
about the uniquely privileged nature of the bulk of those
enjoying the delights of this new time-waster, which was (as one
European put it) "surely *founded* for chatter".
In mid October, a fairly pedestrian discussion about the general
lack of recognition for computational activities and publications
suddenly took off with the re-emergence of the copyright problems
referred to above. If electronic publication was on a par with
paper publication, surely the same principles of ownership and
due regard for scholarly labours applied to it? But did this not
mitigate against the current easy camaraderie with which
articles, gossip and notes are transferred from one medium to
another? as indeed are those more substantial fruits of
electronic labours, such as machine readable texts? For one
correspondent such activities, without explicit permission, were
"a measure of the anesthetizing effect of the xerox machine on
our moral sense". For another, however "asking concedes the other
party's right to refuse".
In mid-November, after a particularly rebarbative electronic foul
up, minimal editorial supervision of all HUMANIST submissions was
initiated. Other than some discussion of the "conversational
style" appropriate to the network, this appears to have had
little or no inhibitory effect on either the scale or the manner
of subsequent contributions.
An enquiry about the availability of some Akkadian texts led to a
repeated assertion of the importance to scholarship of reliable
machine readable texts. Conventional publishers were widely
castigated for their short-sighted unwillingness to make such
materials available (being compared on one occasion to mediaeval
monks using manuscripts for candles, and on another to
renaissance printers throwing away Carolingian manuscripts once
they had been set in type). HUMANISTs were exhorted to exert peer
pressure on publishers, to pool their expertise in the definition
of standards, to work together for the establishment of a
consortium of centres which could offer archival facilities and
define standards. More realistically perhaps, some HUMANISTs
remarked that publishers were unlikely to respond to idealistic
pressures and that a network of libraries and data archives
already existed which could do all of the required tasks and more
were it sufficiently motivated and directed. At present, said
one, all we have is "a poor man's archive" dependent on voluntary
support. Others were more optimistic about the possibility of
founding a "North American text Archive and Service Center" and
less optimistic about the wisdom of leaving such affairs to the
laws of the marketplace. One intriguing proposal was that a
national or international Archive might be managed as a giant
distributed database.
Following the highly successful Vassar conference on text
encoding standards in mid November, a long series of
contributions addressed the issue of how texts should be encoded
for deposit in (or issue from) such an archive. No one seems to
have seriously dissented from the view that descriptive rather
than procedural markup was desirable, nor to have proposed any
method to describe such markup other than SGML, so that it is a
little hard to see quite what all the fuss was about - unless it
was necessary to combat the apathy of long established practise.
One controversy which did emerge concerned the desirability (or
feasibility) of enforcing a minimal encoding system, and the
extent to which this was a fit role for an archive to take on.
"Trying to save the past is just going to retard development"
argued one, while another lone voice asserted a "rage for chaos"
and praised "polymorphic encoding" on the grounds that all
encoding systems were inherently subjective ("Every decoding is
another encoding" to quote Morris Zapp). Anxiety was expressed
about the dangers of bureaucracy. Both views were, to the middle
ground at least, equally misconceived. In the first case, no-one
was proposing that past errors should dictate future standards,
but only that safeguarding what had been achieved was a different
activity from proposing what should be done in the future. In the
second case, no-one wished to fetter (or to "Prussianize")
scholarly ingenuity, only to define a common language for its
expression.
There was also much support for the commonsense view that
conversion of an existing text to an adequate level of markup up
was generally much less work than starting from scratch. Clearly,
however, a lot depends on what is meant by "generally" and by
"adequate": for one HUMANIST an adequate markup was one from
which the "original form of a document" could be re-created, thus
rather begging the question of how that "original form" was to be
defined. To insist on such a distinction between "objective text"
and "subjective commentary" is "to miss the point of literary
criticism altogether" as another put it.
One technical problem with SGML which was identified, though not
much discussed, was its awkwardness at handling multiply
hierarchical structures within a single document; one straw man
which was repeatedly shot down was the apparent verbosity of most
current implementations using it. However, as one correspondent
pointed out, the SGML standard existed and was not going to
disappear. It was up to HUMANISTs to make the best use of it by
proposing tag sets appropriate to their needs, perhaps using some
sort of data dictionary to help in this task.
At the end of 1987 it seemed that "text markup and encoding have
turned out to be THE issue for HUMANISTs to get productively
excited about". Yet the new year saw an entirely new topic sweep
all others aside. A discussion on the styles of software most
appropriate for humanistic research soon focused on an energetic
debate about the potentials of hypertext systems. It was clear to
some that the text-analysis feature of existing software systems
were primitive and the tasks they facilitated "critically naive".
Would hypertext systems, in which discrete units of text,
graphics etc. are tightly coupled to form an arbitrarily complex
network, offer any improvement on sequential searching, database
construction, concordancing visible tokens and so forth?
Participations in this discussion ranged more widely than usual
between the evangelical and the ill-informed, so that rather more
heat than light was generated on the topic of what was
distinctively new about hypertext, but several useful points and
an excellent bibliography did emerge.
A hypertext system, it was agreed, did extend the range of what
was possible with a computer (provided you could find one
powerful enough to run it), though whether or not its facilities
were fundamentally new remained a moot (and familiar) point. It
also seemed (to this reader at least) that the fundamental notion
of hypertext derived from somewhat primitive view of the way
human reasoning proceeds. The hypertext paradigm does not regard
as primitive such mental activities as aggregation or
categorisation (this X is a sort of Y) or semantic relationships
(all Xs are potentially Yd to that Z), which lie at the root of
the way most current database systems are designed. Nevertheless
it clearly offers exciting possibilities - certainly more
exciting (in one HUMANIST's memorable phrase) than "the discovery
of the dung beetle entering my apartment".
Considerations about the absence of software for analysing the
place of individual texts within a larger cultural context lead
some HUMANISTs to ponder the rules determining the existence of
software of any particular type. Was there perhaps some necessary
connexion between the facilities offered by current software
systems and current critical dogma? One respondent favoured a
simpler explanation: "Straightforward concordance programs are
trivial in comparison to dbms and I think that explains the
situation much better than does the theory of predominant
literary schools". It seems as if HUMANISTs get not just "the
archives they deserve" but the software that's easiest to write.
-----------Tables for the Humanist Digest------------------------
Table 1 : Humanist Subscribers by Country
|Country of |Total number |Number of re-
| origin |of sub's |distribution
| |per country |lists incl. |
|--------------------------|------------|
|? | 2| 0| Note: Each "redistribution
|Belgium | 3| 0| list" appears as one
|Canada | 54| 1| member of HUMANIST but
|Eire | 1| 0| stands for a number of
|France | 1| 0| people. These are passive
|Israel | 4| 0| members, i.e., they only
|Italy | 1| 0| receive messages. The number
|Netherlands | 1| 0| of such members are not
|Norway | 3| 0| known to the compiler of
|UK | 37| 4| this report & so do not
|USA | 73| 2| figure in these tables.
|--------------------------|------------|
Total 180 7
Table 1a. Subscribers per node
|nusers |nsuch |
|---------------------------|
| 1| 70|
| 2| 17|
| 3| 11|
| 4| 2|
| 5| 1|
| 7| 1|
| 8| 1|
| 13| 1|
|----------------------------
Table 2. Messages sent per subscriber
|n_mess_sent |number_such |messages |
|-----------------------------------------|
| 0| 107| 0|
| 1| 31| 31|
| 2| 10| 20|
| 3| 9| 27|
| 4| 3| 12|
| 5| 2| 10|
| 6| 3| 18|
| 7| 3| 21|
| 8| 2| 16|
| 10| 1| 10|
| 12| 1| 12|
| 14| 1| 14|
| 17| 1| 17|
| 18| 1| 18|
| 20| 1| 20|
| 71| 1| 71|
|-----------------------------------------|
Totals 177| 316|
-------------------------------------------
Table 3 Messages by origin
|country |Total message|
|--------------------------|
|? | 8|
|Canada | 130|
|Israel | 6|
|UK | 40|
|USA | 132|
|--------------------------|
Table 4: Messages by type
|tag |messages |% messages|linecount |%lines |
|--------------------------------------------------------|
|A | 57| 17.981| 3867| 25.306|
|C | 39| 12.303| 3078| 20.143|
|D | 156| 49.211| 6707| 43.891|
|Q | 64| 20.189| 1616| 10.575|
|--------------------------------------------------------|
Table 5: Messages by type within each month
|type |messages |% in month|lines |% in month|
---------------------------------------------------------------|
AUG87 |A | 10| 23.256| 1230| 32.031|
SEP87 |A | 7| 17.500| 105| 9.722|
OCT87 |A | 9| 30.000| 428| 36.992|
NOV87 |A | 16| 34.783| 863| 48.840|
DEC87 |A | 10| 11.494| 1178| 25.732|
JAN88 |A | 2| 4.000| 5| 0.256|
AUG87 |C | 3| 6.977| 1712| 44.583|
SEP87 |C | 6| 15.000| 208| 19.259|
OCT87 |C | 1| 3.333| 93| 8.038|
NOV87 |C | 13| 28.261| 526| 29.768|
DEC87 |C | 6| 6.897| 218| 4.762|
JAN88 |C | 6| 12.000| 112| 5.744|
AUG87 |D | 22| 51.163| 694| 18.073|
SEP87 |D | 17| 42.500| 577| 53.426|
OCT87 |D | 13| 43.333| 518| 44.771|
NOV87 |D | 4| 8.696| 131| 7.414|
DEC87 |D | 52| 59.770| 2649| 57.864|
JAN88 |D | 37| 74.000| 1678| 86.051|
AUG87 |Q | 8| 18.605| 204| 5.313|
SEP87 |Q | 10| 25.000| 190| 17.593|
OCT87 |Q | 7| 23.333| 118| 10.199|
NOV87 |Q | 13| 28.261| 247| 13.978|
DEC87 |Q | 18| 20.690| 520| 11.359|
JAN88 |Q | 5| 10.000| 155| 7.949|
---------------------------------------------------------------|
*****END*****
=========================================================================
Date: 17 February 1988, 22:53:32 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Lou unkindly cut off when peeked under VM/CMS (22 lines)
As more than one person has complained to me today, Lou Burnard's report
on HUMANIST when PEEKed in the reader of an IBM VM/CMS system appears to
be unkindly cut off in mid stride. Actually the whole thing has arrived,
but one "feature" of PEEK is that by default it will show only the first
x lines of a long file. To read the whole thing you should first RECEIVE
it. Then you can read it with XEDIT, or download it and print it out. I
suggest the latter, since I find it a pleasure to read, and I find such
pleasures hard to sustain on screen. Perhaps that's just a sign of age,
however.
Willard McCarty
mccarty@utorepas.bitnet
=========================================================================
Date: 18 February 1988, 10:28:56 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROMs, on-line dictionaries, and NLP (32 lines)
----------------------------
From Joe Giampapa <GIAMPAPA@BRANDEIS>
I would like to direct this message to all people who use CD-ROMs, on-line
dictionaries, or are familiar with natural language processing (NLP).
I am trying to do research in NLP, but am frequently confronted by the stark
reality that my programs (as well as those of others) are merely "toys" without
an on-line dictionary. Is there anybody out there who has had this problem and
has managed to get around it on a modest budget and hardware configuration
(ie. <=$2k, <10Meg, on a VAX 8650, or Symbolics Lisp Machine{_)?
The "solution" I came up with was using a CD-ROM dictionary (like MicroSoft's
Bookshelf), paired with a database of linguistic information for lexical items
(ie. subcategorization) on the hard disk. However, I still have not seen one
working CD-ROM dictionary, wonder how their addressing works, and how feasible
my idea is.
I would appreciate any insight into my dilemma, and references of people (or
departments) to contact who are doing similar work. Thank you in advance.
Joe Giampapa
giampapa@brandeis.bitnet
=========================================================================
Date: 18 February 1988, 19:33:18 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Contact
----------------------------
From Mark Olsen <ATMKO@ASUACAD>
Does anyone know if the Centre for Research in Education, University
of East Anglia, can be reached via BITNET or other e-mail system?
Thanks,
Mark
=========================================================================
Date: 19 February 1988, 00:00:03 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Hyper text and Stephen Reimer's note (28 lines)
----------------------------
From Jean-Claude Guedon <GUEDON@UMTLVR>
Stephen Reimer asked us whether Ted Nelson was sane or misrepresented by
Byte Magazine. I do not think the question is very interesting in itself,
but it is significant of the way in which ideas are staged (not to say m
marketed) nowadays. It reminds me of the way the term "postmodernism"
was bandied about in a conference I attended last November.
This said, it would be useful to examine what is really new in the
expression "hypertext". To me, hypertext is quite old. Pascal may have
done a good example of it in his "Pensees". Diderot certainly implemented
a form of hypertext in the Encyclopedie when he injected "renvois" to
various articles at different places within an article, thus allowing the
reader to "drift" according to the inclinations of his thought.
Indeed, it would be fun to store the Encylopedie in hypertext
mode on CD-ROM with electronic referrals following the indications
of the original volumes. Anybody interested in pursuing the idea
(and finding the financing to do it). Best to all.
Jean-Claude Guedon (Guedon@umtlvr.bitnet)
=========================================================================
Date: 19 February 1988, 00:04:12 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Hypertext, on-line dictionaries (36 lines)
----------------------------
From Randall Smith <6500rms@UCSBUXB.BITNET>
This is partly in response to Joe Giampapa's question about on-
line dictionaries for natural language processing and partly a
description of a hypertext system which HUMANISTS may be
interested in knowing about.
Greg Crane at the Harvard University Classics Department is
working on a model Greek hypertext system called "Perseus." This
model, when complete, will have a Greek text linked to an
_apparatus criticus_, dictionary, grammar, metrical scansion, and
commentary for teaching purposes. As far as I know this work is
being done using Lightspeed C on a Macintosh (probably a Mac II).
One of the things it will incorporate is an on-line version of
the intermediate Liddell and Scott Greek Lexicon. I know that he
just received the electronic version of this lexicon, though I
have no idea how it is stored, indexed, etc. Also, he is using a
program written by Neal Smith at Cincinnati which does
morphological parsing of Greek words. Even though this does not
directly involve natural language processing, some of the
techniques which Greg is using may be helpful. He can be reached
at:
Department of Classics
319 Boylston Hall
Harvard University
Randall Smith
=========================================================================
Date: 19 February 1988, 11:54:03 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: References for SGML wanted (16 lines)
----------------------------
From Leslie Burkholder <lb0q+@andrew.cmu.edu>
During the course of the many exchanges on SGML, someone posted some
references to introductions to SGML. Could that person, or someone else, send
me these references?
Thanks.
lb0q@andrew.cmu.edu
=========================================================================
Date: 19 February 1988, 11:55:56 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Lou Burnard's article (30 lines)
----------------------------
From PRUSSELL%OCVAXA@CMCCVB
I have some observations to make on Lou Burnard's article that I suspect
are not unique to my experience.
In the article, he alludes to the "private discussions occurring outside
the main HUMANIST forum." I have not (until now) contributed to the main
HUMANIST forum. I have, however, joined a special interest group
(IBYCUS); sent information to and received help from individual members,
institutions, and programs; and re-established communication with long
lost colleagues on both sides of the Atlantic. HUMANIST has also served
as a real-time example in faculty seminars I give on computer networks.
HUMANIST's value to me may not be reflected in Lou's impressive
statistics, but it goes far beyond the discussions carried on amongst
the "top seven."
Roberta Russell
Oberlin College
=========================================================================
Date: 19 February 1988, 11:59:11 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Asides, private discussions, and undocumented uses of HUMANIST
I for one would be very interested to hear from people who, like Roberta
Russell, have used HUMANIST in ways that do not show up in the public
forum. I wonder if the membership would not very much enjoy a report now
and then about what HUMANIST has provoked or assisted offline?
Willard McCarty
mccarty@utorepas.bitnet
=========================================================================
Date: 19 February 1988, 13:19:01 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: SGML reference (28 lines)
----------------------------
From amsler@flash.bellcore.com (Robert Amsler)
I came across what appears to be an excellent introduction to SGML in the
Univ. of Texas at Austin library earlier this week. It is:
SGML and Related Issues by Joan Margaret Smith,1986.
It is a British National Bibliography Research Fund Report
available from: (1) The British Library Publications Sales Unit,
Boston Spa, Wetherby, West Yorkshire, LS23 7BQ, UK
or (2) Longwood Publishing Group, Inc.,
51 Washington Street
Dover, New Hampshire, 03820, USA
It had both an ISBN number (0-7123-3082-8) and an ISSN number (0264-2972;22)
It was a report on the events leading up to the creation of the ISO SGML
standard and seemed quite readable. I don't know what the price is.
=========================================================================
Date: 19 February 1988, 14:23:57 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: An undocumented use of HUMANIST (23 lines)
----------------------------
From Lou Burnard <ARCHIVE@VAX.OXFORD.AC.UK>
One of the many which I failed to find space for in my recent
account was the case of a colleague of mine who, having occasion
to visit New York at a particular crucial point during some electronic
discussions on JANET, was provided by HUMANIST with an introduction to
a BITNET site in NY from which he could continue his negotiations.
On the offchance, he sent four pleas for help in the morning and received
3 offers of a temporary BITNET account the same day. New Yorkers are of
course famous for their hospitality, but this was beyond the call of
duty. It's also worth bearing in mind the next time people start droning
on about the dehumanising effect of the computer on personal interaction!
Lou
=========================================================================
Date: 19 February 1988, 18:34:09 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: SGML (me too!)
----------------------------
From Francois-Michel Lang <lang@PRC.Unisys.COM>
I too would be greatly interested in some introductory references
to SGML. If somebody out there (Bob Amsler?) could send them
to me too, I'd be very grateful. Thanks.
--Francois Lang
Francois-Michel Lang
Paoli Research Center, Unisys Corporation lang@prc.unisys.com (215) 648-7469
Dept of Comp & Info Science, U of PA lang@cis.upenn.edu (215) 898-9511
=========================================================================
Date: 20 February 1988, 01:52:36 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Reference on SGML tags for literary documents (20 lines)
----------------------------
From Peter Roosen-Runge <CS100006@YUSOL>
I recently came across a Master's Thesis which gave me a good introduction to
the key ideas of SGML and what's involved in applying them to the creation
of a set of tags for literary documents. An implementation in SCRIPT/VS is
discussed, there's a 90-page reference manual as an appendix which gives a clear
description of all the elements defined in the "standard" proposed by the
author, and she's provided a sample markup and formatted output for a scene
from Hamlet.
This is rather outside my field, so I can't assess how complete or useful
the proposed set of tags would be, but I found the thesis a great help in
understanding the recent HUMANIST discussion of SGML issues.
The thesis is from 1986 but was recently published as a technical report:
Fraser, Cheryl, A.
An Encoding Standard for Literary Documents
External Technical Report ISSN-0836-0227-88-207
Department of Computing & Information Science,
Queen's University: January 1988
=========================================================================
Date: 20 February 1988, 12:28:52 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROMs, Hypertext, and GUIDE (43 lines)
----------------------------
From Ken Tompkins <H156004@NJECNVM>
I note that the same sort of intensity and conviction has
pervaded the discussion of CD-ROMS that was involved in the
remarks on Hypertext. Here, we are just in the early stages
of considering wider purchases of CD-ROM technology -- we
have a modest application in our library accessing the
READER'S GUIDE. The various questions posed by readers
asking if faculty will use the technology to such an extent
that wide purchase can be justified seem terribly important.
I suspect that we will recommend an area in our library
where various CD-ROM disks will be stored for faculty and
student access. I doubt the College will support individual
purchases.
A recent piece in PC-WEEK suggests that there may still be
life in magnetic media. At IBM's Almaden Lab in San Jose,
scientists discovered that a 3 1/2 inch disk could store
10 gigabytes. The only limits found in the project was in
recording head technology. Clearly, optical disk technology
offers substantial benefits -- stability, etc. but it seems
equally clear that magnetic media cannot be so easily
counted out.
One final question. Are any readers experimenting with GUIDE
a hypertext application for PC-AT's? I bought a copy a week
ago and am rather impressed with its pedagogical
possibilities. To learn how to use it, I'm developing a
set of files on a Shakespearean sonnet. Do other readers
have practical experiences with the program. If so, I'd like
to hear about them.
Ken Tompkins
Stockton State College
=========================================================================
Date: 20 February 1988, 12:33:08 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Tenure-track job in electronic publishing & literature (62 ll.)
----------------------------
From Ken Tompkins <H156004@NJECNVM>
The following position is now open; if you know of anyone
fitting the description who would like to develop an
Electronic Publishing Track from the ground up, PLEASE HAVE
THEM RESPOND to the address below. Also please note my
request at the bottom.
************* Faculty Position Open **************
The Literature and Language Program (Department) of Stockton
State College seeks an Instructor or Assistant Professor of
Applied Communications for a renewable tenure track position
starting September 1, 1988. The candidate should have a Ph.D
or ABD (for Instructor) in the appropriate field. Curricular
expertise plus experience in the field of Electronic/Desktop
Publishing or related area required. College level teaching
experience strongly preferred. Literature specialization may
be British, American, or non-Western.
The function of this position is to develop an Applied
Communications concentration emphasizing Electronic
Publishing and/or Publication Design within the Literature
and Language Program.
Current salary range: $20,713 -- $28,956 depending on
qualifications and experience plus State mandated fringe
benefits. Screening begins February 1, 1988.
Send letter of application with CV and direct three letters
of reference to:
Margaret Marsh
Chair, Faculty of Arts and Humanities
Stockton State College
Pomona, N.J. 08240
AA/EOE Employer -- Minorities and Women encouraged to
apply.
**********************************
My request: We have advertised this position in the major
listings applicable to the Literature component but so far
have received no responses. Can members of HUMANIST suggest
other outlets more oriented to the electronic publishing
component? If you can please reply directly to me.
This is an opportunity to teach literature and to develop a
college-wide facility for electronic publishing as well as
to establish a concentration for students.
=========================================================================
Date: 20 February 1988, 13:13:46 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Amendment to Ken Tompkin's item (28 lines)
----------------------------
From David Nash <nash@cogito.mit.edu>
>From Ken Tompkins <H156004@NJECNVM>
[...]
A recent piece in PC-WEEK suggests that there may still be
life in magnetic media. At IBM's Almaden Lab in San Jose,
scientists discovered that a 3 1/2 inch disk could store
10 gigabytes. The only limits found in the project was in
recording head technology.
February 1988 BYTE (page 11) reports what must be the same story, but
have it that the 3.5" disks can hold "10 gigabits". This would be a
factor of 8, I guess, less than 10 gigabytes, and really to be
compared to the ca. 1 gigabyte hard disks on the market now.
"Several industry watchers said they'll get more excited when they see
devices that can read those disks..."
-DGN
=========================================================================
Date: 20 February 1988, 15:01:32 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Why CD-ROM? (24 lines)
----------------------------
From Mark Olsen <ATMKO@ASUACAD>
The excitment over CD-ROM is in the first two letters. It is
a technology that is in place, with existing and rapidly expanding
production facilities, and -- if audio CD is any example -- the
prospect of rapid decending prices. Standards in the computing
business, as in many others, has less to do with technical excellence
as with economic and marketing considerations. You can go out
right now and buy 500 meg HD, but this will always be a limited
market (read expensive) item. The CD has the benefit of economy
of scale that will probably not be rivaled by specialized magnetic
media. The IBM-PC standard is a lasting tribute to the power of economics
and marketing to ignore technical advances and to retard future
technical developments.
Mark
=========================================================================
Date: 20 February 1988, 16:36:54 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Parsing programs (37 lines)
----------------------------
From Richard Goerwitz <goer@sophist.uchicago.edu>
I'm interested in working up a parsing engine geared for the Hebrew Old Testa-
ment. Can anyone recommend any relevant articles? This really isn't a query
about machine translation, as I am only interested in distinguishing various
grammatical categories. It isn't even about machine-assisted translation. My
reason for wanting to do this is that I am interested in doing grammatical
searches of various sorts on the Old Testament text. Probably articles on
Arabic or other Semitic languages will be applicable. I don't know. Maybe
someone out there *does*.
NB: I am not interested in analyzed or lemmatized texts, since this would
cause me to lose a lot of flexibility. Every time my notion of a grammatical
category changed, I'd need to mark everything over again. Fully analyzed text
actually makes parsing more a matter for the editor of the text than the author
of the parsing program!
-Richard L. Goerwitz
goer@sophist.uchicago.edu
!ihnp4!gargoyle!sophist!goer
P.S. Most of what I have done so far is in Icon. But if anyone wants to send
sample code, please feel free to do so. I don't mind reading C, SNOBOL4, or
some PASCAL (though Icon is definitely my home-field).
=========================================================================
Date: 21 February 1988, 11:01:53 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Silent use of HUMANIST (30 lines)
----------------------------
From R.J.Hare@EDINBURGH.AC.UK
Like Roberta Russell, I too have used HUMANIST as an example of the
intelligent use of computers to disseminate information, etc. in a series of
seminars we give at Edinburgh to the annual intake of English Literature
post-graduates. HUMANIST is an impressive example of such usage, and the only
way I intend to change this type of usage in the future is to increase the
range of people we demonstrate it to.
Roger Hare.
=========================================================================
Date: 21 February 1988, 11:04:14 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Parsing engine for Hebrew (49 lines)
----------------------------
From Robin C. Cover <ZRCC1001@SMUVM1>
In response to the inquiry of Richard Goerwitz on parsing engines
for Hebrew: I am also interested, but the last time I investigated this
topic I found disappointingly little information. We should ask the
Israelis, I'm sure, and in particular Yaacov Choueka. An important
question is whether we want a parser WITH a dictionary or WITHOUT a
dictionary; the latter, I'm afraid, would be one big program. Some
progress has been made on Greek parsers (Gregory Crane, Harvard; Neel
Smith, Bowdoin College; Tony Smith, Manchester) but apparently not for
Hebrew. If other HUMANISTS have better news, I'm all ears.
One possibility would be to check with Gerard Weil. A student of
his once wrote a dissertation on parsing Hebrew by computer, but to my
knowledge it was not perfected (Moshe Azar, "Analyse Morphologique
Automatique du Texte Hebreu de la Bible," 2 volumes; Nancy 1970). A
more profitable lead might be to ask Yaacov Choueka, whose work on
lemmatization and disambiguation is highly regarded, and is implemented
(I understand) in the software of the Responsa Project, where much of
this mammoth corpus of Hebrew is parsed on the fly; see J.J. Hughes in
_Bits and Bytes Review_ 1/7 (June, 1987) 7-12. (Also, bibliography in Y.
Choueka, "Disambiguation by Short Contexts," _CHum 19 (1985) 147-157.)
But I doubt that this is portable or obtainable code. I suspect you
want a completely rule-based parser, working with a grammar but not a
dictionary. If you don't mind a little help from a dictionary, see
Walter Claassen's article "Towards a Morphological Analysis of Biblical
Hebrew:a semi-automatic approach," in the proceedings of the Louvain
conference, _Bible et Informatique: Le Texte_ (1986), pp. 143-54. But I
suspect you should be asking this to the ACM group, not on HUMANIST. I
also wish there WAS more interaction between computational linguists and
those (HUMANISTS) who generally work as literary critics.
There is bibliography on this topic in the volume published by the CIB in
1981, _Centre: Informatique et Bible_ (Brepols, 1981); cf pp. 105-106 on
morphological analysis, and pp. 138-140 on lemmatization by computer.
Professor Robin C. Cover
ZRCC1001@SMUVM1.bitnet
=========================================================================
Date: 21 February 1988, 18:33:02 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Bitnet/EARN connection to Univ. of East Anglia (32 lines)
----------------------------
From Ian Lambert <iwml@ukc.ac.uk>
I picked up a message during the last 3 days from someone
wanting to know of the Centre for Research in Education at the University of
East Anglia. Specifically they were seeking a BITNET or EARN connection.
I logged into our database of hosts here in Canterbury and found only the two
references to UEA, and thought that this at least would give our colleague
HUMANIST a contact to work from.
The numbers are the numerical ids. We have alpha ids here but I am aware that
the majority of them are UKC specific, and therefore unlikely to work outside
our internal network.
The only links we have to the University of East Anglia apparently are:
000008006002 their central VAX; and
000008006003 the Computer Centre
Perhaps their postman can help.
Ian
=========================================================================
Date: 22 February 1988, 09:10:38 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Icon (52 lines)
----------------------------
From Richard Goerwitz <goer@sophist.uchicago.edu>
It occurs to me that there are probably a few people reading Humanist
mailings who run all kinds of programs, and yet do not program themselves.
For those who would like to, there is an easy way - learn Icon. Icon is
a very high-level, general-purpose programming language that shines when
put to text and string-handling tasks. Fortunately, it is also a modern
"structured" language, so unlike BASIC, FORTRAN, SNOBOL, etc., it *forces*
the programmer into a more structured, procedurally-oriented approach.
For me Icon served as an excellent starting point. Before this, I had
learned a little assembler (80x86 and some BASIC), but had not really
been able to lauch into more substantial programming tasks. Though Icon
has a very rich and complex syntax, one can master its basic features in
two or three weeks. Just a few lines of Icon code, moreover, can do
what would take many lines of, say, Pascal or C (especially with no string
handling facilities). Almost as soon as one begins writing Icon programs,
one begins writing useful and even very powerful programs.
After learning Icon, one can then move into lower-level languages. It's
a little hard to get used to having to tell the compiler how much storage
to allot every variable (i.e. to operate without "garbage collection")
but overall, it seems much easier to begin programming in C after Icon
than before. I know because I tried. C seemed incredibly cryptic when
I had my first run at it, and I gave up. I guess after learning basic
techniques with Icon, it all fell into place.
I say this not because I'm connected with the creators of Icon in any way.
I just wanted to offer a little information that might be useful to those
who feel walled off from their machines because of their inability to pro-
gram it themselves - either at all, or in a language suitable to the sorts
of tasks they want to perform.
For the interested, Icon is free (!). Send a note to the Icon project
at icon-project@arizona.edu. There's also a book out called *The Icon
Programming Language* by Ralph and Madge Griswold (Prentice Hall: New
Jersey, 1983).
-Richard L. Goerwitz
goer@sophist.uchicago.edu
!ihnp4!gargoyle!sophist!goer
=========================================================================
Date: 22 February 1988, 09:16:01 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: East Anglia successfully reached by Arizona (15 lines)
----------------------------
From John Roper <S200@CPC865.UEA.AC.UK>
From John Roper (S200@cpc865.uea.ac.uk)
Just to let everybody know that Mark Olsen successfully contacted
University of East Anglia. There is obviously a lot of activity
behind the scenes if that request was any guide.
=========================================================================
Date: 22 February 1988, 09:48:59 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Assessment of the Oxford Text Archive (39 lines)
----------------------------
From Judith Proud <ARCHIVE@VAX.OXFORD.AC.UK>
Lou Burnard's recent requests for ideas and opinions
concerning various aspects of the Text Archive and its catalogue
(Humanist 9th Dec, 8th Feb and passim) are not (necessarily) an
early indication of mid-life crisis, mounting self-doubt or basic
insecurity but largely the result of recent funding granted by
the British Library to enable an assessment of the past workings
and current status of the Oxford Text Archive and the formulation
of a realistic policy for its future. This funding has led to my
appointment to the project for the period of one year at the end
of which I shall be producing a report containing our various
findings and recommendations.
As Lou has already started to do, with somewhat disappointing
results, we would like during the course of the project
to throw out a number of general requests
for information, opinions and ideas from Humanists who
have used the Archive in the past or decided not to use it for
particular reasons. Just as important for our research, however,
and perhaps of more general interest to most Humanists,
are the broader issues involved in the use of Text Archives,
a vast area that includes a number of topics that have already
been touched on in earlier Humanist discussions and which we hope
will continue to be discussed energetically and productively.
This is just a preliminary announcement to introduce you
to the project, but any initial thoughts or comments would of
course be very welcome.
Judith Proud
Oxford Text Archive
=========================================================================
Date: 22 February 1988, 13:20:55 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Thanks and some comments on ICON (31 lines)
----------------------------
From Mark Olsen <ATMKO@ASUACAD>
First, let me thank all those who offered help in contacting
East Anglia -- I received no less than 7 messages, showing that
we are a humane lot.
Richard Goerwitz's comments on Icon are interesting, for what he says
and what he does not say. Icon is a sophisticated string processing
language that is a marked improvement on SNOBOL and certainly easier
to use for many applications than either C or BASIC. But Goerwitz
treats it as a "learning" language rather than as a serious application
language. Inspite of my positive evaluation of Icon, I too have looked
at it and used it in only limited applications. This is because
the PD implementation does not have a number of important features that
are necessary for serious programming, such as random disk access and
a decent debugger, not to mention the combined editor/compilers like
Turbo Pascal. The basic components of the language, as defined
by Griswold and his group, are admirable, but will probably not see
very wide use until a software house picks up the language and
gives it higher levels of support.
Mark
=========================================================================
Date: 22 February 1988, 13:23:16 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Hebrew parsing programs (34 lines)
----------------------------
From John Gleason <XB.M07@STANFORD.BITNET>
The Packard Humanities Institute is currently involved in correcting
an automated morphological analysis of the Hebrew text of the Old
Testament. The original automated analysis was done by:
Richard E. Whitaker
300 Broadway
Pella, IA 50219
(515) 628-4360
I believe Whitaker did the analysis on an Ibycus system, but I don't
know if it was the mini or the micro. He's a knowledgeable
Semiticist, and can also give you lots more information than I can
on what's being done in this area.
The correction of the automated analysis is being done by:
J. Alan Groves
Westminster Theological Seminary
Box 27009
Philadelphia, PA 19118
(215) 572-3808
=========================================================================
Date: 22 February 1988, 13:26:01 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Hebrew Bible parsing (58 lines)
----------------------------
From Bob Kraft <KRAFT@PENNDRLN>
A couple of footnotes to the informative reply by Robin Cover
to Richard Goerwitz' query about Hebrew Bible parsing. I will
admit that I'm not sure why it wouldn't be suitable to start
with "analyzed or lemmatized texts" from which a lot of
flexibility could easily be constructed, but I will leave that
for Richard and Robin to enlighten me. My footnotes do in fact
refer primarily to analyzed text. Sorry. But they are part of
the broader discussion.
(1) Several "morphological analyzed" forms of the Hebrew Bible
exist in various stages of verification and availability. Two
that we at CCAT were unable to obtain for use in the Septuagint
Project (CATSS) are by the late Gerard Weil and his French
team, and by Francis Andersen and Dean Forbes in Australia.
Early in the game, the results from the Maredsous (Belgium)
project were also unavailable, so we commissioned Richard
Whitaker to create programs for automatic analysis on the
older IBYCUS System in the IBYX language (similar to C).
As we made progress on this project, negotiations with the
Maredsous project became more favorable, so now the results
from the Whitaker programs and from Maredsous are being collated
and corrected/verified as necessary by the Westminster Seminary
team under Alan Groves. Our desire is to make this material
avaialble for scholarly research, and if there is some way that
Whitaker's code could be of help, I am willing to investigate
the question further along those lines. I know nothing beyond
what Robin communicated about the other players in this game,
except that Dean Forbes did the programming for the Andersen
analysis and could be approached about his code as well.
(2) The discussion of Greek analysis programs should make note of
the pioneering efforts of David Packard, whose morphological analysis
program written for IBM maniframes has been around for a very long
time and is described in an article from one of the Linguistic
Computing conferences at Pisa. This program is mounted in various
centers, the most recent of which is Manchester (Robin referred to
Tony Smith there), which has permission to serve as a center for
others to access the program electronically.
(3) Analysis programs for other languages also exist, and are sometimes
available in one way or another. We were able to obtain DeLatte's
Latin program (Liege) for use on projects through CCAT, and doubtless
others have developed or obtained similar programs. Perhaps HUMANIST
would be a good place to create an inventory of information on such
matters, for accessing through the fileserver?
Bob Kraft (CCAT)
=========================================================================
Date: 22 February 1988, 14:21:42 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: XT vs. Mac (31 lines)
----------------------------
From Maurice Charland <charlan@CONU1>
I have a modest sum to spend on microcomputers for our PhD program in
Communication. My university supports PC-style machines, but does not
support Macs. Also, current XT-clone prices are such that they come in
approx. $1000 less than Macs. Given this, are there compelling arguments
that would favour purchasing Macs?
The machines will be used by PhD students and faculty. With the exception of
word processing, the possible applications of these machines is undetermined.
I do not, in the near future, expect much in the way of computer-based
textual analysis (a hot topic currently on HUMANIST).
While I gather that, in the abstract, Apple's designs are far better than
IBM's I do wonder whether this difference makes a difference for most
applications in the social sciences and humanities. What do fellow HUMANISTS
think.
Thanks,
Maurice Charland
Communication Studies
Concordia University
=========================================================================
Date: 22 February 1988, 14:23:38 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Using the KDEM 4000 for non-Roman alphabets (55 lines)
----------------------------
From Robin C. Cover <ZRCC1001@SMUVM1>
I would like to accumulate some wisdom on the use of the Kurzweil Data
Entry Machine (KDEM 4000) for digitizing complex textual materials,
especially non-roman scripts. We recently acquired a KDEM 4000, but
found the documentation somewhat spartan, and the support personnel
(including engineers) have been less than enthusiastic about supplying
additional information. By trial-and-error, we have learned some tricks
that allow us to tweak performance for tasks that press the scanner to
its limits, and perhaps into service for which it was not designed. But
I suspect there are rich storehouses of "departmental lore" held at
various universities where the KDEM has been used in precisely this way.
It would be helpful to know, if we can find out, exactly what kind of
intelligence the KDEM 4000 has, how it operates (at the algorithmic
level), how its performance can be optimized for scanning multiple-font
materials.
I will appreciate cooperation from any institutions who would be willing
to contribute to this task: documenting undocumented features of optimal
KDEM performance. Perhaps veteran operators could be asked to
contribute a paragraph or two, or suggestions in list format, describing
their most critical discoveries in working with the KDEM. I will be
glad to compile these suggestions for redistribution if they are sent to
me personally, but I would also like to know via public postings if
HUMANISTS at other KDEM sites think this is a worthwhile enterprise.
Maybe the KDEM 4000 is "just as smart (or stupid) as it is, and not much
more can be said."
Finally, does anyone know whether OCR technology is currently being
developed by major companies? I understand that Palantir is increasing
the sophistication of its scanners by adding more font libraries
(including foreign language fonts), but this is hardly a godsend for our
applications. Much optical scanning technology (as with Recognition
Corporation) seems to be focused on bit-mapped images and sophisticated
compression algorithms for mass storage, but with less emphasis upon
character recognition per se. I'd be delighted to hear that some kind
of commercial application is driving development of *intelligent*
optical character recognition devices. Wouldn't libraries want this
technology?
Professor Robin C. Cover
ZRCC1001@SMUVM1.bitnet
3909 Swiss Avenue
Dallas, TX 75204
(214) 296-1783
=========================================================================
Date: 22 February 1988, 18:59:20 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Teaching with hypertext/media conference (45 lines)
----------------------------
From elli@husc6.BITNET (Elli Mylonas)
I am posting this for a friend.
Please pass it on to local bulletin boards, and to others
who may be interested.
--Elli Mylonas
CALL FOR PAPERS
Conference: "Teaching with Hypertext," August 8-9, Bowdoin College,
Brunswick, Maine.
It has long been predicted that the advent of hypermedia will have a
dramatic impact on education. Now, particularly since the introduction of
Apple's Hypercard in August, 1987, hypermedia is becoming widely
available to educators for the first time. What effect is hypertext having
on pedagogy? "Teaching with Hypertext" will bring together teachers from
a wide variety of disciplines, both within and outside of academia, to
consider how easily available, cheap hypermedia is influencing them and
their students.
Desirable topics for papers include examples of applications of hypertext
in both formal classroom settings, and independent or less structured
learning environments; sound and video applications with hypertext; the
impact of hypermedia on form and pace of curriculum; and the relationship
between traditional hard-copy learning resources and hypermedia.
Please send a 500 word abstract by Friday, March 15 to:
Neel Smith
Department of Classics
Bowdoin College
Brunswick ME 04011
or
dsmith@wjh12.harvard.edu
=========================================================================
Date: 22 February 1988, 19:01:34 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: HUMANIST's preoccupations (31 lines)
----------------------------
From Sebastian Rahtz <spqr@CM.SOTON.AC.UK>
I found Lou Burnard's report fascinating; pity he didn't supply it
marked up in SGML, but wotthehell....
anyway, can I add two further observations to his remarks on trends?
The first is serious: HUMANISTs are predominantly literary, and
there are a high proportion of classicists amongst us (I include
biblical scholars in that), far more than any normal average. For one
reason or another, the discussion does not often cover history, music,
archaeology, fine art, languages etc; is this because these subjects
are covered in other ways or because literary types are naturally
argumentative? I suggest that HUMANIST could become a ghetto one
day...
The second point is trivial, and prompted by a lunch-time conversation
with the a fellow-HUMANIST here (there aren't many of us in
Southampton...); why aren't more contributions funny? OK, the worlds a
miserable place, and we are all desperately trying to get on in the
rat race, but computers are not THAT important....
sebastian rahtz
=========================================================================
Date: 22 February 1988, 19:03:56 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: ICON (37 lines)
----------------------------
From Sebastian Rahtz <spqr@CM.SOTON.AC.UK>
I was interested in Richard Goerwitz's promotion of Icon
(sorry Richard my mailer *refuses* to talk to you, by the way),
and Mark Olsen's rebuttal.
I am afraid I cannot share Richard's claim that Icon is easy to
learn; I enjoy using it, as I used to use Snobol and after that it
seems like the ideal language, but when I tried to teach it to 1st
year students last year, they floundered. It is TOO rich, are
too many features, for easy comprehension (sounds like ADA!).
But equally, I think Mark is being unfair; why does he *want*
random access files for the tasks Icon was designed for? Its tracing
facilities are good enough for the casual punter, who never uses
a debugger anyway (well, I never have and never want to, nor do
I know any 8x86 assembler). It ISNT a system language, its a utility,
exploratory, prototyping language. I do concur that a Turbo-style
environment would be lovely, but there are still people out
there would don't use PCs, y'know... to me, the major criticism
of Icon as a daily language is that it cant create pure executables
in the current version (nor is such a thing planned, so far as I know).
This makes it awkward to give programs to friends.
Mark could always add random access functions himself (at least in
the Unix version) by creating a personalised interpreter.
sebastian rahtz
=========================================================================
Date: 22 February 1988, 19:05:42 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Job announcement (44 lines)
----------------------------
From Nancy Ide <IDE@VASSAR>
Job Announcement
Instructor in Computer Literacy
Vassar College
The Department of Computer Science seeks applicants for an Instructor in
Computer Literacy beginning September 1988. Candidates holding a doctorate will
be given highest priority though others who demonstrate appropriate experience
or credentials will be considered. Prior teaching experience in computer
literacy is strongly desirable.
Candidates should have a broad familiarity with computer literacy issues and an
in-depth knowledge of microcomputing in a Macintosh environment, including
Pascal programming, word processing, spreadsheets, graphics and similar software
applications. Experience with a VAX/VMS computing system is a plus. The
teaching load is five courses per year.
Vassar is a coeducational liberal arts college of 2,250 students located in the
Hudson Valley, approximately ninety minutes north of New York City. The
Department of Computer Science consists of five full-time faculty members.
Vassar is a charter member of the Carnegie-Mellon InterUniversity Consortium for
Educational Computing and has participated in numerous national projects in
educational computing for liberal arts colleges.
Salary is dependent upon qualificatinos. Candidates should send a resume,
transcript(s), three letters of recommendation, and a letter stating teaching
interests to: Dr. Martin Ringle, Chairman, Department of Computer Science,
Vassar College, Poughkeepsie, NY 12601. Application closing date is March 30,
1988. An Equal Opportunity/Affirmative Action Employer. Women and Minority
candidates are encouraged to apply.
=========================================================================
Date: 22 February 1988, 19:53:42 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: More on ICON (46 lines)
----------------------------
From Richard Goerwitz <goer@sophist.uchicago.edu>
Mark Olsen is correct in saying that a decent debugger would be nice for
Icon. I, however, have found little trouble using it without one. I'm
not claiming to be a hot-shot programmer. In fact, I would say quite
the opposite. Still, I can often crank out huge amounts of nearly error-
free Icon in a few hours. It's really amazing how easy programming in
Icon is.
I say this because, if I were thinking about learning to program, I would
probably have been turned away from Icon by Mark's comments. This would,
at least in my case, have been a very drastic error.
Version 7 of Icon has much better debugging facilities.
As for random disc access, please note the new seek function in version 7.
Clearly Icon does not offer low-level hardware control, but you can now
at least go to whatever line you want in a file.
Combination editor-compiler packages are nice, I think. However, most of
the time compilers are not set up this way. Turbo Pascal and a few other
packages stand out as notable exceptions. The lack of such facilities would
not discourage me from learning a particular programming language!
I say this not to get into any dispute with Mark. Actually, he points out
some very important things to keep in mind when looking at Icon. I just
wanted to point out that, having had the experience of self-teaching myself to
program, Icon has proved an excellent choice. You might argue that I am
just so fantastically intelligent that any way I had approached this task
would have worked out. This, however, would be completely false, since I
am just an everage Joe who wanted to start doing things for himself....
-Richard L. Goerwitz
goer@sophist.uchicago.edu
!ihnp4!gargoyle!sophist!goer
=========================================================================
Date: 22 February 1988, 20:06:03 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Sebastian's points (32 lines)
Sebastian, my friend, I recall that the last time we tried to be funny,
or perhaps were funny, our unfortunate colleagues in New Zealand, who
were paying to read our flames about flaming, objected. (They are gone
now, I hope only temporarily, and they are gone *because of* the cost.)
The real reason for so little humour amongst us, however, may be that
being funny, or delightfully imaginative, is very hard! Being serious,
without wit or irony, is much easier. It may also be only appropriate to
the kind of forum we have, though I hope not.
As for the literary bias of HUMANIST, I disagree. If literary types were
in the majority of those who hold forth, then I'd guess that we'd have
heard more, for example, on the subject of software for problems of
literary scholarship. We do hear a fair bit about linguistic problems,
however.
It would be very interesting to have a Burnardian analysis
of the backgrounds of our members, at least as far as the biographies
would reveal them. Is anyone willing to do that? (Some of you will
remember that such an analysis was one of the original aims of the
Special Interest Group for Humanities Computing Resources, of which
HUMANIST was the first public expression.)
Willard McCarty
mccarty@utorepas [bitnet]
=========================================================================
Date: 23 February 1988, 00:14:01 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Iconography (40 lines)
----------------------------
From Mark Olsen <ATMKO@ASUACAD>
Don't get me wrong. I like Icon and would use it over SNOBOL4+,
save that the support levels for a PD language have to be minimal.
One can't expect the kind of support and development for Icon that
a commercially supported product receives. What this really boils
down to is a plea for a commercially supported version of Icon, one that
can be used for writing larger, more complex applications. I'll have
to look at version 7, I think I'm back at 6.n, to see what improvements
have been added.
Sabastian is quite right that I am being unreasonable about wanting
random access disk files (and other goodies) in a language that is
designed to be something else. This is because I am simply too damned
lazy to try to implement the kinds of things that SNOBOL and Icon have
built in -- associational arrays, pattern matching etc -- in another
language in order to get standard services like random disk i/o and
faster i/o. The mere thought of the number of pointers required to
implement an Icon table gives me gas pains. So I write most of my
analysis programs in SNOBOL4 and wish that SOMEBODY ELSE would do the
dirty work. As for a debugger, I had a student writing a program in
Icon who managed to bomb the system when he tried to call a procedure
with several large parameters. Only after MUCH experimentation was
he able to detect the problem. More effective debugging would help
there.
There is enough good about Icon to lament the fact that it is
supported only by volunteer effort. I suspect that I am not the only
one in the world who uses these "prototyping" languages for more
serious applications rather than try to write similar programs in
other languages.
Mark
=========================================================================
Date: 23 February 1988, 00:15:18 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Dangers of Ghetto Mentality (32 lines)
----------------------------
From ROBERT E. SINKEWICZ <ROBERTS@UTOREPAS>
I was very pleased to read Sebastian's comments and I quite agree that
HUMANIST is leaning very heavily in the direction of becoming a ghetto for
those whose primary interest is in text oriented computing. I would guess
that this is in part a reflection of the way in which the humanities have
been segregated in specialized departments that very often do not talk to
one another. I believe that HUMANIST would be failing in its purpose if it
does not contribute to overcoming this sort of compartmentalization of
knowledge.
To take only one example, as best as I can recall there have been no
more than four or five references to the research possiblities of
relational databases since last August. And yet relational databases and
their statistical counterparts are becoming increasingly common in
historical studies. Where are all the historians, archaeologists, and
even the librarians???
Perhaps Toronto is unusual in having several major research projects
that are heavily computerized and adopt a more interdisciplinary approach
to their work. For example, REED - Records of Early English Drama (not just
the texts but any and all information about their historical, social and
economic context); ATHENIANS - a Who-was-who in old Athens; DEEDS -
statistical analysis of the medieval charters of Essex county; GIP - Greek
Index Project (everything you want to know about Greek manuscripts anywhere
in the world). And this is only the short list. Where are all the other
HUMANISTS who are doing interesting things with information databases,
building such interesting tools as PROLOG expert systems to analyze data?
I have nothing against texts. I read a lot of them, have edited a few
of them (Byzantine texts), but I do insist that texts have contexts -
historical, social, economic, etc.
Robert Sinkewicz (ROBERTS@UTOREPAS)
Pontifical Institute of Mediaeval Studies
University of St. Michael's College
Toronto
=========================================================================
Date: 23 February 1988, 00:26:13 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Solomon's solemn silence (31 lines)
----------------------------
From Norman Zacour <ZACOUR@UTOREPAS>
I cannot speak about those interested in "music, archaeology, fine art
etc.", but if we lack contributions about computing and history it may
be because most historians who deal with personal computers are
primarily interested in word processors and data processors, both highly
developed in the business world and therefore leaving little for the
academic to get worked up about. It's the newness of some things that
leads to excitement: one can appreciate and welcome the advent of
WordPerfect 5.0, which with its competitors will allow the production of
oceans of books, but it lacks the explosive excitement of invention,
like that of Mr. Crapper in the 19th century. Rather it is all very
serious business. It was Mark Twain, though I wish it had been I, who,
in discussing our profession, said that many things do not happen as
they ought, most things do not happen at all, and it is for the
conscientious historian to correct these defects. It's a terrible
burden, being conscientious, and leaves little room for frivolity. I do
not know where Twain said it, and so I follow notices to HUMANIST about
marking up text, hoping that when the entire corpus of biblical, Greek
and Latin literature has been thoroughly annotated, perhaps then...
Norman Zacour (Zacour@Utorepas)
=========================================================================
Date: 23 February 1988, 00:31:35 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Thanks; Dictionaries (83 lines)
----------------------------
From Richard Goerwitz <goer@sophist.uchicago.edu>
Thanks for the many replies on Hebrew parsing programs. I will have a fair
number of leads to follow up over the next few weeks. I promise to post re-
sults - should any be forthcoming.
This is perhaps as good a time as any to clear up an apparent misunderstand-
ing. Some individuals took it to mind that I was opposed to the idea of a
dictionary. This was probably based on my aversion to lemmatized or other-
wise analyzed text. The two are not the same. I'd like to explain why.
Let me back up and explain first why I want to find out about parsing methods.
Basically, I would like to do more than simply look for patterns (grepping,
say) - more even than looking for keywords, as in a lemmatized concordance. I
want to locate syntactic and other sorts of patterns. There's no sense offer-
ing Hebrew examples here. Too many people on the HUMANIST have other areas of
expertise. Let me point out, though, that "grammatical" searches are some-
thing almost anyone involved in linguistics or some form of language-study
would find useful.
To facilitate such searches, some folks have apparently lemmatized (i.e. added
dictionary entry keys) to texts. Others have actually separated out morphemes
or labled words as to their syntactic category. This is a good thing to do. I
make no bones about it. However, one must keep in mind that programs which use
these texts are not really parsing. They may be doing some parsing. The real
grammatical analysis, though, has already been done by the editor of the text.
In my mind, this offers several distinct disadvantages. First of all, what if
the editors change their minds about something? They have to re-edit the en-
tire text, and then redistribute it. Worse yet, what if a user doesn't agree
with the editors' notions of morpheme boundaries, of grammatical categories, or
of syntactic structure? He basically has to ignore the information provided,
or else try to weed out whatever he can use.
For Semiticists, let me offer some examples (I'm talking mostly Heb., some Ara-
maic). Do we call a participle an adjective or a noun? Do we include a cate-
gory "indirect object" (yes, says Kutcher; no, say I). Are infinitives absol-
ute to be classified as adverbs, nouns, verbs, or what (sometimes one or ano-
ther of these classes will be better)? The problem we are getting into here
is that in Hebrew, a word's class will depend partly on morphology, and partly
on its external syntax. It's not like Latin, where the morphology will pretty
much tell us a word's class. Nor is it like English, where external syntax or
the lexicon will usually tell us this information. Whether we adopt a tradit-
ional, morphological approach to classification (the "classical" tradition -
which likes to impose Greek or Latin categories on languages where it is com-
pletely inappropriate), or a more broad one, will be terribly subjective.
My feeling, therefore, is that if I can, I'd like to find out if a true parser
is possible for biblical Hebrew. Sure, I'll used analyzed text if I need to.
I want to know, however, if the other alternative is - even dimly - feasible.
Now, about the dictionary: I have no objection to one. Certainly native
speakers of any language will memorize a great deal. So why shouldn't our
parsing programs? If I have to lexicalize tense distinctions like "go" and
"went," why not let my parser lexicalize them, too?
I also have no objection to front ends to parsers, which have lists of the
most frequent words handily pre-analyzed. Using such a module cuts down
the amount of work a parser has to do, while not crippling it in any way.
In sum, then, I don't at all object to tables, dictionaries, etc. Nor do I
object to analyzed text. It's just that in the latter case, I'd like to try
to see whether I can get along without it. Again, if anyone knows of any
relevant articles on Semitic languages (like, say the recent one on Arabic
in Computers in Translation), please drop me a line!
Many thanks again.
-Richard L. Goerwitz
goer@sophist.uchicago.edu
!ihnp4!gargoyle!sophist!goer
=========================================================================
Date: 23 February 1988, 00:35:00 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Hypertext, on-line dictionaries (80 lines)
----------------------------
From elli@husc6.BITNET (Elli Mylonas)
>This is partly in response to Joe Giampapa's question about on-
>line dictionaries for natural language processing and partly a
>description of a hypertext system which HUMANISTS may be
>interested in knowing about.
Since the Perseus Project was mentioned by Randall Smith in a recent
posting, I would like to clarify and add to his description of the
project.
>Greg Crane at the Harvard University Classics Department is
>working on a model Greek hypertext system called "Perseus." This
>model, when complete, will have a Greek text linked to an
>_apparatus criticus_, dictionary, grammar, metrical scansion, and
>commentary for teaching purposes.
The Perseus Project is collecting visual and textual data on Classical
Greece and putting it together in such a way that it may be used for teaching
and research. The project is taking place both at Harvard and at Boston
University. The textual data will consist of Greek texts, translations,
meter, app. crit. and notes. The latter two items may not be provided for every
text, but will certainly be available for a basic canon. (Don't jump
on me, we will be asking professors what they consider canonical for
inclusion.) The system will also include a Greek lexicon (the Intermediate
Liddel Scott Lexicon) and a classical encyclopedia. All this will be
linked together to allow access from one part of the database to the others,
and to allow a user to look up a word while in a text, or to see a picture
or a map that are relevant.
By the way, all our texts will be encoded using content markup in accordance
with the SGML standard, so that they may be as machine independant as possible.
>As far as I know this work is
>being done using Lightspeed C on a Macintosh (probably a Mac II).
We are working on Macintoshes, it is true. We are developing material
on Mac II's, but most of it will run on a Mac plus, and the parts that won't
will tell you that they don't.
We are using Hypercard, however, so that we can avoid writing software
as much as possible, and concentrate our efforts on
the content and how to organize it. The coding that must be done in-house
is being done with Lightspeed.
>One of the things it will incorporate is an on-line version of
>the intermediate Liddell and Scott Greek Lexicon. I know that he
>just received the electronic version of this lexicon, though I
>have no idea how it is stored, indexed, etc.
We do have the online version of the intermediate L&S. It was keyboarded in
the Philipines and approximately half of its cost was defrayed by PHI. It is
at the moment in alpha code with very little markup, although we are in the
process of marking it up. The first task is to get as much of the
morphological information out of it as possible, in order to feed that
to the parser (see below). We plan on storing this in descriptive
markup also. However we are aware of the difficulty of parsing meaningful
content elements out of a complex document which contains almost only format
information.
>Also, he is using a
>program written by Neal Smith at Cincinnati which does
>morphological parsing of Greek words. Even though this does not
>directly involve natural language processing, some of the
>techniques which Greg is using may be helpful.
The morphological parser, appropriately named Morpheus, was begun by Neel
Smith while he was at Berkeley, but later rewritten in C and finished by Greg
Crane at Harvard. It is now finished, but still needs information for
its rules in order to be useful. This will be supplied from the Middle
Liddel. Morpheus has been tested in beginning Greek classes at Chicago and
Claremont.
I have given a *very* brief description of a large project. Many details
and facts have been glossed over and left out. If anyone would like more
information, please note me so I can go into more detail, or send you
our written information.
--Elli Mylonas
Research Associate,
Principle Investigator
Perseus Project elli@wjh12.harvard.edu
=========================================================================
Date: 23 February 1988, 00:36:22 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: References for SGML wanted & Author/Editor (17 lines)
----------------------------
From elli@husc6.BITNET (Elli Mylonas)
I would like recommend an article that explains why descriptive markup
like that prescribed by the SGML standard is to be recommended.
It described other forms of markup and compares them to descriptive markup.
This was written by 3 HUMANIST's, but I think that they will not mention
it, so I will.
Coombs, J. H., Steven J. DeRose and Allen H. Renear,
"Markup Systems and the Future of Scholarly Text Processing"
Communications of the Association for Computing Machinery,
Nov. 1987, pp.933-947.
An addendum: I will be getting a copy of SoftQuad's Author/Editor program,
and will post a review to the mailing list as soon as I have had a
chance to take a look at it.
--Elli Mylonas
elli@wjh12.harvard.edu
=========================================================================
Date: 23 February 1988, 00:41:11 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: A ghetto of what kind? (40 lines)
In replying to Sebastian's warning about the "literary" ghetto that we
may find ourselves in, Bob Sinkewicz says,
I have nothing against texts. I read a lot of them, have edited a few
of them (Byzantine texts), but I do insist that texts have contexts -
historical, social, economic, etc.
This I applaud. This was just my substance some weeks ago, when I
speculated that New Criticism and similar movements in and outside
academia have caused us to take a very narrow view of what humanistic
software we might want. Perhaps, as someone said, concordance software
is easier to write than database software, but that does not adequately
explain our more general preoccupation with The Text as an isolated
object of study, perhaps even of idolatry.
It's not a *literary* preoccupation that immures us in
a narrower space than some would wish to inhabit but a particular and
historically provincial view of what text is all about. Any literary
critic worth the name (I say with no humour or subtlety) will be
interested in some context or other, and this context necessarily has a
history, or several histories. Database software is what one uses to
keep track of such things.
I'm not saying that people interested in the workings of the language on
the page are wrongheaded but that the relative poverty of other kinds
amongst computing humanists is not a good sign. Or have I read the
innards of my chicken incorrectly?
Willard McCarty
mccarty@utorepas
=========================================================================
Date: 23 February 1988, 09:05:02 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: HUMANIST's ghetto (36 lines)
----------------------------
From Joe Giampapa <GIAMPAPA@BRANDEIS>
I would like to call attention to an outstanding individual who began
"humanities computing" way before computing made it out of the realm of
the more technically-oriented sciences.
George Cowgill, a faculty member of the Brandeis Department of Anthropology,
began a computerized reconstruction of either Tenochtitla'n or
Teotihuac'an (or both?) years ago, using stacks of punch cards. From what I
hear and have read, he has achieved considerable success with his project,
and has contributed greatly to the advancement of archaeological methods of
site reconstruction.
I do not know what state his project is in now -- it might be "completed"
(if ever one with these proportions could be completed) -- but it is at
least off those darn punch cards. I am sure he would be able to provide a
clearer and more thorough explanation of his work, if anyone asked. For
those interested in contacting him, they can send mail to him directly at
cowgill@brandeis.bitnet
If, in the weird event that someone cannot get mail to him, I can serve as
a message forwarder.
Joe Giampapa
giampapa@brandeis.bitnet or
garof@brandeis.csnet or
giampapa@cogito.mit.edu
=========================================================================
Date: 23 February 1988, 09:45:47 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Cumulative Kurzweil lore (28 lines)
----------------------------
From Susan Hockey <SUSAN@VAX.OXFORD.AC.UK>
In summer 1985 there was a proposal to form a user group of academic
Kurzweil users. I think this proposal came from the University of
South Carolina. I have heard nothing more of it since and would
be interested to know if it ever got off the ground and if not,
whether there is enough interest now.
The cumulative wisdom of five year's Kurzweil usage at Oxford can
be found in my article 'OCR: The Kurzweil Data Entry Machine',
in Literary and Linguistic Computing, 1 (1986), 61-67. This article
describes the Kurzweil Data Entry Machine, not the Kurzweil 4000, but
the recognition algorithms are the same. The main differences between
the two machines are in the user interface and the fact that training
and production are separate tasks on the KDEM, but not on the Kurzweil
4000.
Susan Hockey
SUSAN@VAX.OXFORD.AC.UK
=========================================================================
Date: 23 February 1988, 09:54:03 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Italian computational musicology (388 lines)
[Lelio Camilleri, HUMANIST and Professor of Computer Music, Conservatory
of Music L. Cherubini, in Florence, Italy, has submitted the.
following report in response to the recent concerns about the
narrow specialization of HUMANIST. Bene! -- WM]
-----------------------------------------------------------------
From Lelio Camilleri <CONSERVA@IFIIDG.BITNET>
MUSICOLOGY AND THE COMPUTER IN ITALY
A report on the current activity and the educational implications
(Forthcoming in MUSLETTER, I, 3)
Lelio Camilleri
Conservatorio di Musica L. Cherubini
Piazza delle Belle Arti 2
I-50122 Firenze
E-mail address: CONSERVA@IFIIDG.BITNET
Phone: ++39-55-282105
INTRODUCTION
The Italian situation of computer assisted research in
musicology is still in development even though there are some
centers which carried out a permanent research activity is this
field. In fact, although in Italy several centers work
on computer music and an Italian Association for Computer
Music (Associazione Italiana di Informatica Musicale AIMI) has
been founded, the various activities are mainly focused on
composition, sound synthesis or hardware/software development
rather than on musicology, music theory or analysis research.
The year 1987 has registered an increasing interest in the
use of computer for musicological purposes. A two days
seminar, sponsored by the Istituto di Studi Rinascimentali
of the University of Ferrara, has been held in March to discuss
the use of computer to create database or system of information
retrieval for musical studies. Another important international
meeting has been held in Bologna, co-sponsored by the
University of Bologna and the Center for Computer Assisted
Research in the Humanities, Menlo Park, during the
International Musicological Society Conference. In this
meeting (Selfridge-Field forthcoming) the participants
discussed two main subjects: musical data and music analysis.
The research activity on music theory and musicology in
Italy, can be divided into two parts:
- research in music theory, analysis and music
analysis/theory software development;
- musical data bases realization.
RESEARCH IN MUSIC THEORY AND ANALYSIS
The research work in music theory and analysis can be
summarized in the following way: research project using the
computer as a tool for testing musical theory or hypotheses
(these works are mainly based on the notion of musical
grammar) and research focused on the realization of music
analysis software and its usage on musicological work.
The works of Baroni et al. (1978, 1983, 1984) and of the
present author (Camilleri 1985) can be classified in the
first aspect of computer use in musicology.
The research work of the group of Baroni and Jacoboni,
University of Bologna and Modena, is the first of this kind in
Italy and one of the most interesting projects. It deals with
the definition of a grammar for melody and it is
devoted to the examination of four different but related
melodic repertoires.
The first and more advanced project is concerned
with the melodies of the Bach Chorales. The second
project analyzes all the four parts of J.S. Bach Chorales.
Finally, the third and the fourth respectively deal with a
repertoire of one hundred French melodies taken from a
collection of popular chansons published in 1760, and
the Legrenzi's Cantatas.
The ultimate goal of these research projects is to
identify the structural principle of what we define a
melody. The methodology used is based on the formalization
of a grammar, or set of rules, which should describe by
means of concepts like, kernel, transformation, primitive
phrase, the hierarchical structure of a melody. This grammar is
then implemented in a computer program to generate melodies
whose stylistic pertinence to the original model serves to
verify the theoretical assumptions. They assumptions is to
define general rules for melody found in all the repertories, as
well as rules belonging to a well defined musical style.
My work, carried out at the Conservatory of Music of
Firenze and the Musicological Division of CNUCE, starts from
similar methodological grounds. The goal of this project is to
define some high-level structural features of melody which
should also have psychological implication. The main hypotheses
concern with the perfection and imperfection of phrases, the
existence of a kernel, the concept of melodic contour
hierarchically related to a particular structural level. The
popular melodies of North Europe has been chosen as model. In
this work also the computer has been used to check the various
theoretical hypotheses by means of the implementation of the
formalized rules in a program and the subsequent automatic
generation of melodies.
Other research projects related to this kind of computer use
are those of Camilleri and Carreras for the realization of an
expert system, based on ESE, for musical segmentation and
tonal harmonic analysis, and F. Giomi and M. Ligabue
(Ligabue 1985, 1986) for the analysis of jazz improvisation.
The first research project is still in the developmental
stage, concerning the realization of a theoretical
model based mainly on the work of Schenker, Lerdahl and
Jackendoff and Keiler. It is also based on the research
work of one of the authors on the musical cognitive
processes (Camilleri 1987). At present time, a model of
musical segmentation (Camilleri forthcoming) is in phase of
completion and the testing stage is starting.
The work of F. Giomi and Ligabue, two associates of the
Musicological Division of CNUCE in the Conservatory of Music
of Firenze, is based on similar methodologies of Baroni's
and Camilleri's works. A system of rules to model the
harmonic/melodic jazz improvisation has been formalized and
implemented in a software tool. The software is integrated with
the TELETAU system and provide a sound output by means of TELETAU
sound facilities. Jazz software also supplies an interactive part
in which the user can specify harmonic path, melodic scale and
other musical parameters as to investigate the various aspects
of jazz improvisation.
Software for music analysis has been realized at the
Musicological Division of CNUCE (Camilleri et al 1987),
Florence.
The programs currently available at the Musicological
Division of CNUCE and the Conservatory of Music L.
Cherubini, Firenze, fall in two categories: those which
use quantitative and statistical techniques to supply
information on the surface structure of musical pieces
(recurrence analysis, thematic analysis) and the ones which
allow a deeper analysis of a piece structure and evidence
the hierarchical relations among its parts (Schenkerian
analysis, pitch-sets analysis). The two sets of programs may be
considered as complementary in that they produce information
which allows more complete understanding of the piece from
different points of view.
Some of this programs are integrated with the TELETAU system.
TELETAU system (Nencini et al. 1986) can also be viewed as a
tool for musicological work. It is a mainframe based system
which supplies sound output by a special MIDI/RS232
interface. The system features of musicological interest
comprehend a musical encoding language,
and several commands to decompose and process the musical data
in a very flexible way. TELETAU is also accessible through the
BITNET-EARN network.
The Laboratorio di Informatica Musicale, University of Milano,
is pursuing research on the description of musical process by
means of Petri's nets and a work on the study of the
orchestration. The description of musical processes uses the
notion of hierarchy, concurrency and causality (Camurri,
Haus, Zaccaria 1986). The other research work aims at
describing by Petri's nets the rules of orchestration of a
particular composer. A sound output is provide to verify the
correctness of the orchestration realized.
Two software realizations for analytical purposes have been
carried out by L. Finarelli, University of Bologna, and W.
Colombo, University of Milano, as works for dissertation thesis.
The software developed by L. Finarelli is based on some
elementary analysis procedure, like those of the first
categories of the Musicological Division of CNUCE
software, which should serve to complete a sort of score data
base. The goal of the system realized by W. Colombo is to
develop a set of programs for tonal harmonic analysis based
on the Schoenberg's theory of Regions. The software allows the
user to scrutinize the harmonic skeleton of the piece and
to bring out the belonging to a particular region of a chord
succession. The two works just mentioned use micro or personal
computer.
Finally, P. de Berardinis (1983,1984,1985), Studio di
Sonologia Computazionale "E. Varese, Pescara, has realized an
analysis software for atonal music which uses the pc-sets
theory of A. Forte. The software package runs on Apple II
computer.
A kind of computer application to music theory can be found
in the work of the research group of the Department of
Computer Science, University of Salerno (D'Ambrosio,
Guercio, Tortora 1984). They have been realized a formalism
to represent musical texts and rules in a grammatical
fashion which is implemented in a package of programs. This
approach has the goal of building a system containing
the capacity to elaborate musical texts automatically.
Another work of musicological interest is the one of Barbieri
and Del Duca (1986) who uses the computer to demonstrate the
microtonal tuning system used by Vicentino, Colonna, Sabatini,
and Buliowski.
MUSICAL DATA BASE REALIZATION
The realization of musical data base is the aim of
several projects which have also the feature to concern with
other artistic fields as poetry and theater and educational or
printed musical sources.
The first project started four years ago at the University of
Bologna and it is carried out by people working on the
research about the grammar for melody at the same
University. This project deals with the realization of a
system which allows to handle information about the Emilian
libretti of the XVII and XVIII centuries (Baroni et al. 1987).
The data of each libretto, composer, librettist,
title, year, place, performers, are encoded in a
personal computer. An information retrieval system makes
discovery of historical kind and crossed data analysis
possible. The data of about 4000 libretti have been actually
encoded.
The other project is carried out by the collaboration
among several Institution as the University of Ferrara,
Rome, Pisa and the University of California at Berkeley.
It deals with the Italian lyric poetry of the Renaissance in
musical and literary prints. The aim is to realize a
100.000 poetic texts data base, for publication information and
retrieval of "lost" poetry from music part-books. The Italian
part of the project is more related to the literature aspects.
Furthermore, we have to mention the library of encoding
musical pieces of the Musicological Division of CNUCE, about 1000
pieces of different authors. The library is also accessible from
remote users belonging to the Earn-Bitnet network and is made
easy by a query system.
A large project, financed by funds of Ministry of Cultural
Funds, has been started in 1987, concerning musical sources
located in Veneto, a northern Italy region. The project deals
with several fields as cataloguing printed music, textbooks on
singing education, and a music thematic catalogue of venetian
music.
Other two projects are the multiple indexing of performance
details and text incipits of all comic operas produced in Naples
form 1700 to 1750 carried out at the University of Milan under
the direction of Professor Degrada, and the encoding and
cataloguing of a musical funds using technical devices as OCR or
CD-ROM, in which collaborate several Institutions and the
Laboratorio di Informatica Musicale in Milano.
CONCLUSION
The situation of computer application to musicology in
Italy is in evolution. As I mentioned above the use of
computer at the University Department of Music and in the
Conservatory is still not well established even though the
people (scholars, students and researcher) who start
to interest in this field is increasing.
One may also hope that the realization of software for
musicological purposes will be more and more concerned with the
design of packages which can be used by several
researchers. The software designer should be oriented to
create not only experimental software, that is used only by the
research group who realized it.
An interesting issue related to the problem of spreading and
promoting the use of computer in musical studies is its
educational implications. Mainly, the use of computer in music
education is only concerned with the study of the computer music
itself or the study of sound processing. The music educational
activities established which use the computer are the Computer
Music course at the Conservatory of Music L. Cherubini in
Florence, the only one in an Italian Conservatory, the computer
music summer courses held at the Centro di Sonologia
Computazionale in Padova, and other few which also deal with
electronic music. A three day seminar on Computer and Music
Education has been held by myself last October at the Centro di
Ricerca e Sperimentazione per la Didattica, and I will hold a
summer course on Computer and Musicology next September in
Florence.
In my opinion, a very important question is: How could be used
the methodological approach of, say, musical grammar to teach the
theory of melody by computer to students ? Is it possible to
integrate the methodology and the realized tools with, say, the
curriculum of music history and music analysis courses ?
My answer is yes, and I think this is a promising path to
follow for the near future.
REFERENCES
SELFRIDGE-FIELD, E., forthcoming. "Computer-Based Approaches to
Musical Data and Music Analysis: a Technical Exchange", in
Proceedings of the XIV IMS Conference.
BARBIERI, P., DEL DUCA, L., 1986. "Reinassance and Baroque
Microtonal Music Research in Computer Real Time Performance, in
Proceedings of the 1986 International Computer Music Conference,
P. Berg (ed.), S. Francisco, Computer Music Association.
BARONI, M., Jacoboni, C., 1978, "Proposal for a Grammar of
Melody: The Bach Chorales", Montreal, Les Presses de l'
Universite de Montreal.
BARONI, M., 1983. "The Concept of Musical Grammar", Music
Analysis, II, 2.
BARONI, M. et al.,1984. "A Grammar for Melody.
Relationships between Melody and Harmony", in Musical Grammars
and Computer Analysis, M. Baroni and L. Callegari (eds.),
Firenze, Holschki.
BARONI, M. and JACOBONI, C., 1983. "Computer Generation of
Melodies: Further Proposals", Computer and The Humanities,
XVII.
BARONI, M. et AL., 1987. "Libretti of Works Performed in Bologna,
1600-1800", Modena, Muchhi.
CAMILLERI, L., 1985. "Un Sistema di Regole per Generare
Semplici Melodie Tonali", Quaderni di Informatica Musicale, V.
CAMILLERI, L., 1987. "Towards a Computational Theory of Music",
in The Semiotic Web '86, T. Sebeok and J. Umiker-Sebeok (eds.),
Berlin, Mouton De Gruyter.
CAMILLERI, L., forthcoming. "Psychological and Theoretical Issues
of Musical Segmentation".
CAMILLERI, L., CARRERAS, F., GROSSI, P., NENCINI, G., A Software
Tool for Music Analysis, Interface, forthcoming.
CAMURRI, A., HAUS, G., ZACCARIA, R., 1986. "Describing and
Performing Musical Processes", in Human Movements Understanding,
Tagliasco and Morasso (eds.), Amsterdam, North-Holland.
DE BERARDINIS, P., 1983. "Il Microcomputer nell' Analisi
Strutturale della Musica Atonale", Quaderni di Informatica
Musicale, I.
DE BERARDINIS, P., 1984. " Analisi Strutturale della Musica
Atonale (II)", Quaderni di Informatica Musicale, IV.
DE BERARDINIS, P., 1985. "Analisi Strutturale della Musica
Atonale (III)", Quaderni Informatica Musicale, V.
D' AMBROSIO, P., GUERCIO, A., TORTORA, G., 1984 "Music Theory
by Means of Relational Grammars", Internal Report, Dipartimento
di Informatica e Applicazioni, Salerno, Universita' di Salerno,
LIGABUE, M., 1985. "Un Sistema di Regole per l' Improvvisazione
nel Jazz", in Atti del VI Colloquio di Informatica
Musicale, Milano, Unicopli.
LIGABUE, M., 1986. "A System of Rules for Computer
Improvisation", in Proceedings of the 1986 International Computer
Music Conference, P. Berg (ed.), S. Francisco, Computer Music
Association.
G. NENCINI, e al., 1986. "TELETAU - A Computer Music Permanent
Service", in Proceedings of the 1986 International Computer
Music Conference, P. Berg (ed.), S. Francisco, Computer Music
Association.
Acknowledge-To: Lelio Camilleri <CONSERVA@IFIIDG>
*****END*****
=========================================================================
Date: 23 February 1988, 10:08:14 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Kurzweil lore? (26 lines)
----------------------------
From PROF NORM COOMBS <NRCGSH@RITVAX>
I am a kind of Kurzweil user. Not primarily for data entry although I have
done some and expect to do more. I am totally blind history prof at the
Rochester Institute of Technology. I use a KRM to do some of my reading.
On occasion I have connected through a bi-directional terminal to our VAX
and read the material simultaneously by "ear" and also into a text file.
If there is an "accumulated body of wisdom" especially about text entry,
I surely could benefit by learning more than I know... which is not much.
Looking forward to more info.
Norman Coombs
=========================================================================
Date: 23 February 1988, 18:49:59 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: KDEM and scanning (29 lines)
----------------------------
From Bob Kraft <KRAFT@PENNDRLN>
Like Oxford, CCAT has a KDEM III (not the newer 4000). There are
a number of ways to trick the machine to read more efficiently,
although I do not know whether they will work as well on the 4000.
One easy and obvious (once you think about it) tactic is to let the
machine tell you what it reads and develop an artificial coding
in that manner, to be changed to the desired coding later through
tailoring. Thus for Hebrew, the resh looks to the KDEM like a "7"
and the beta looks a "2" and the dalet is enough like a "T" to get
by, etc. Of course, ambiguities must be avoided, but it really helps
the scanner to guess correctly. And there are more such tricks, if
this is really what Robin Cover is after.
May I use this occasion to renew my scanner question -- has anyone
developed the ability to go directly from microform (film, fiche)
to electronic form, without a hardcopy intermediate? I still have
not found a concrete lead to such technology.
Bob Kraft (CCAT)
=========================================================================
Date: 23 February 1988, 18:51:38 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Work on on-line dictionaries (16 lines)
----------------------------
From Terry Langendoen <TERGC@CUNYVM>
I understand that Prof. Herbert Stahlke, Dept. of English, Ball State
University, has a project for making large on-line dictionaries
available in a variety of environments. I don't have an email address
for him, but I'm sure he'd be receptive to inquiries by regular post
or phone.
=========================================================================
Date: 23 February 1988, 18:53:29 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CALL (Romance essays)
----------------------------
From Joanne Badagliacco <JMBHC@CUNYVM>
Does anyone out there know of any programs to teach foreign languages -
particularly essay writing in Romance languages? German and Russian
would also be interesting.
Please reply to Joanne Badagliacco (JMBHC@CUNYVM).
=========================================================================
Date: 23 February 1988, 19:00:26 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Ghetto mentality (58 lines)
----------------------------
From ked%garnet.Berkeley.EDU@jade.berkeley.edu (Charles Faulhaber)
All right, I have under development a relational
data base for the primary sources of medieval
Spanish literature, i.e., MSS and early printed
books.It is written in Advanced Revelation, an
MS-DOS-based dbms like DBase but considerably
more flexible: variable-length fields, no limits
on number of fields and number of records. The
only real limit is that records can be no more
than 64K and no field can be no more than 64K.
The Bibliography of Old Spanish Texts (BOOST)
has evolved from a system based on FAMULUS
at the U. of Wisconsin which originally had 19
data elements. The current version has 7 related
files (biography, uniform title, libraries, MSS,
copies [printed books], contents [information
about specific copies of a given text in a given
MS or ed.], and secondary bibliography) with some
300 data elements. Still to come are a subject
file and major additions to some of the other ones.
E.g., for biography we want to add standard
prosopographical information.
Advanced Revelation is a window-based system which
is designed to allow for the integration of information
from a number of different files in any given window
as well as for customizable sorts of all kinds. We
eventually plan to use the system as a data base
front end for a corpus of machine-readable texts in
medieval Spanish. Many of these already exist,
having been transcribed for the purposes of the
Dictionary of the Old Spanish Language at the U.
of Wisconsin directed by John Nitti and Lloyd
Kasten. We are focussing on 1992, since our
corpus represents the literary culture which
Spain took to America; and we hope that storage
developments and compression algorithms will
have developed sufficiently so that in addition
to the data base and the texts themselves we will
also be able to include a good selection of digitized
facsimiles of significant MSS, probably on a CD-ROM
disk.
(I would be interested in more information aboaut
the GIP [Greek Index Project].)
Charles B. Faulhaber (ked@garnet.bitnet)
=========================================================================
Date: 23 February 1988, 19:04:06 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: ICON and SPITBOL... (30 lines)
----------------------------
From Richard Giordano <RICH@PUCC>
I haven't used ICON yet, but I have been programming extensively in
different version of SNOBOL for just about ten years. If ICON is
anything like SPITBOL, it is true that you can learn to write
complicated string-handling and symbol manipulation programs in little
more than a couple of weeks. As many people know, SNOBOL is a powerful
tool for text analysis and retrieval, and ICON seems to be even more
powerful than SNOBOL, particularly because it's a structured language.
I really have to agree with Richard Goerwitz's praise.
I'm a little puzzled over the comments I've read regarding indexing files
with ICON. I use IBMPC SPITBOL, and I have had no problem indexing
records, and retrieving them. In fact, I created a pretty large database
system written entirely in IBMPC SPITBOL. Maybe I am puzzled because I
am mis-reading the comments.
Richard Giordano
Computing and Information Technology
Princeton University
RICH@PUCC
=========================================================================
Date: 23 February 1988, 19:06:00 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: ICON and commercial support (49 lines)
----------------------------
From dow@husc6.BITNET (Dominik Wujastyk)
I don't agree at all with Mark Olsen's claim that Icon is fettered by
its public domain status. Of course it would be nice if a company took
it up and added goodies. But I probably couldn't afford them anyway.
But look for a moment at TeX. This is a public domain product that has
more support than any commerical product I can think of. Have you ever
tried, for example, to get help from IBM? Or Lotus? Or Microsoft?
Sometimes one strikes lucky, and will get a helpful person. But TeX
has a huge and thriving community of users, including many very talented
programmers, who provide a steady stream of excellent add-on programs and
macros. In the first place there is TeXhax, which is a digest of
questions, answers and macros produced by Malcolm Brown, which appears
sometimes as often as thrice weekly! Then there is TeXmag, another on line
magazine with news and more macros. There is the USENET news area
comp.text which is full of TeXiana, and there is TUGboat, a tri-annual journal
of the highest quality, which is again full of help and interest. The
staff of the TeX Users Group are also on hand with help and advice. As I
say, I have not met support like this *anywhere* else, and the commercial
software I have used over the years, especially from the big companies, has
been abysmally supported.
It would be interesting to try and analyse just why it is that TeX has
attracted the support that it has. In the first place it is a superb
program: so is Icon. It is portable across systems and OSs: so is Icon.
It is supported by the User group, which in turn received a lot of support
from the American Mathematical Society, which uses TeX for most (perhaps
all by now) of its journals. Ah! A difference. Icon does not lend itself
in any obvious way for large scale use in a semi commercial environment.
And I think the main reason is that it cannot produce compiled executables.
As someone else said recently here in Humanist, I think this is one of its
main drawbacks.
I make it my general policy to prefer the PD software to the commercial as
far as possible, and there are few areas where this has not led me to have
better programs and better support for them.
Dominik Wujastyk
=========================================================================
Date: 23 February 1988, 19:07:01 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: The Greek Index Project (17 lines)
----------------------------
From dow@husc6.BITNET (Dominik Wujastyk)
Robert Sinkewicz recently mentioned a project at Toronto called GIP. Could
someone who knows about it please send me information about it?
bitnet: user DOW on the bitnet node HARVUNXW
arpanet: dow@wjh12.harvard.edu
csnet: dow@wjh12.harvard.edu
uucp: ...!ihnp4!wjh12!dow
=========================================================================
Date: 23 February 1988, 19:08:18 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Kurzweil and OCRs not pundits? (14 lines)
----------------------------
From dow@husc6.BITNET (Dominik Wujastyk)
Am I right in thinking that no Kurzweil or other OCR machine has yet
succeeded in reading Devanagari?
Dominik Wujastyk
=========================================================================
Date: 24 February 1988, 00:33:54 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Parsers for Semitic languages (39 lines)
----------------------------
From Jack Abercrombie <JACKA@PENNDRLS>
Just a quick footnote to the query on parsers for Semitic
languages.
As noted, Dick Whitaker wrote a parsing program for biblical
Hebrew. His work was funded by CATSS Project, and its results,
a parsed Hebrew text, was then collated against the Maredsous text.
(Whitaker's program incidentally can be modified to work with most
Semitic Languages.)
Both the Maredsous biblical text and that of G. Weil were parsed by
hand, and not program.
As far as I know, only a few individuals have admitted
to writing a parsing program for Hebrew or any Semitic language,
besides Whitaker and of course Dean Forbes. Some eight
years ago, Nahum Sarna informed me that his son had written
such a program for Hebrew. About five years ago, one of my students
wrote an automatic parsing program for Hebrew. Another student took
this same work and modified the data files for Arabic. Neither
version has survived, though Roger Allen and I have saved the algorithm
for other purposes and it would be easy to reconstruct it if we
were seriously interested. Lastly, Everhard Ditters has also written
a parsing program for Arabic according to information I received from
him last year.
Jack Abercrombie,
Assistant Dean for Computing &
Director of CCAT
=========================================================================
Date: 24 February 1988, 08:53:10 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: SPITBOL, ICON, Brain Damage (24 lines)
----------------------------
From Lou Burnard <ARCHIVE@VAX.OXFORD.AC.UK>
Like Richard Giordano I've been a happy spitbol hacker for more years than
I care to remember. I've also been greatly tempted by the evident superiority
of icon in terms of language design structure etc. My question is, am I
alone in finding it very difficult to re-think problems in iconic-ic (as
opposed to snobol-ic) terms? i dont get this problem programming in other
high level languages because they dont have built in string operations
so similar to those of spit/snobol, but whenever i start trying to write
a piece of icon code i find myself wanting to introduce gotos and call
snobol functions. maybe its just my celebrated mid-life crisis.
or does the snobol style actually damage the brain in the way dijkstra
warned us it would?
lou
=========================================================================
Date: 24 Feb 88 09:01:14-EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Date: 24 February 1988, 08:55:41 EST
From: MCCARTY at UTOREPAS
To: HUMANIST at UTORONTO
Cc: ralph at arizona.edu, icon-project at arizona.edu
Subject: Griswold and ICON
----------------------------
From R.J.Hare@EDINBURGH.AC.UK
Why doesn't someone try and contact Griswold et. al. at Arizona and invite
them a to contribute to the current discussion of Icon? I have tried and
failed (for reasons which are not clear to me) to contact them by electronic
mail from here, but I'm sure that they would be interested in the current
discussion (if they aren't already aware of it).
As an indication of the power and versatility of Icon, I might say that the
first program I wrote using Icon was an editor (yeah, I know context editors
are passe, but it seemed a useful starting exercise for a language whose
strong points include powerful string processing capabilities), and I was
amazed that I was able to get a more or less working editor, albeit a very
simple one, after only a few days 'spare-time' effort, particularly as I
hadn't done any *real* string processing before.
I'm a fan, and if I had more time I'd be a better one.
[Note that a copy of this message is being sent to Ralph Griswold.
W.M.]
=========================================================================
Date: 24 Feb 88 09:02:41-EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Date: 24 February 1988, 09:01:42 EST
From: MCCARTY at UTOREPAS
To: HUMANIST at UTORONTO
Cc: ralph at arizona.edu
Subject: Icon and the PD
----------------------------
From Mark Olsen <ATMKO@ASUACAD>
I would like to agree with Dominik Wujastyk's comments regarding PD
software. There is some good stuff out there. But I'm not sure that
the example of TEX is appropriate as, from what I understand, one
purchases it through one of several vendors, each of whom might add
something to the TEX standard and give more or less support to particula
printers/environments/etc. I know we have looked at TEX for the PC and
found the price at about $250, with options for additional printer
support. This is not PD software, at least as I define it. Developers
have taken a good design, ported it to particular machines and added
other support.
Software marketed by the major manufacturers and small houses can all
attract good users groups (and Lord knows we need a KDEM_SIG) and
other levels of "informal" support. I have also had some good
experiences with smaller developers, who take an intense interest in the
product and in customer satisfaction. I see the PD as a testing ground
for design ideas, the most successful of which appear in later
incarnations as either "shareware" or commercial ventures.
I don't really want to depend on the spare time of some individuals
to improve products and design reasonable upgrade paths. I'm more
than willing to shell out the price for WordPerfect or PC-Write
(remember it ain't PD), both of which are good products, than to
try to find some PD product that is only a third as effective.
I think that Icon is probably at the point in its life where it
could be reasonably picked up by a small developer, like Catspaw
or the developer of SPITBOL for the PC, and given real support at
a fair price. I know academics are broke, but that does not mean that
we should really try to get something for nothing.
Mark
=========================================================================
Date: 24 February 1988, 09:02:58 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: WordCruncher texts (36 lines)
----------------------------
From Randall Jones <JONES@BYUADMIN>
Electronic Text Corporation, home of the text retrieval program known as
WordCruncher, has recently announced a number of indexed texts that can
be used with WordCruncher. These include the Riverside Shakespeare; ten
volumes from the Library of America collection, viz. Franklin,
Jefferson, Melville, Twain, Emerson, Thoreau, Hawthorne, Whitman, Henry
James, London; a collection of approximately 50 writings on the U.S.
Constitution (including Federalist Papers), and the King James Bible.
Texts in progress include the Oxford Shakespeare, additional volumes
from the Library of America, other English bibles, the Hamburg edition
of the complete works of Goethe, and the Pfeffer spoken German corpus.
Because of agreements with the publishers these texts cannot be sold
simply as electronic texts, but can only be used with WordCruncher. For
additional information as well as suggestions for texts to be made
available for the future send me a BITNET note or write or call:
Electronic Text Corporation
5600 N University Ave
Provo, Utah 84604
801-226-0616
Randall Jones, Director
Humanities Research Center
Brigham Young University
Provo, Utah 84602
801-378-3513
=========================================================================
Date: 24 February 1988, 09:04:54 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Line-counts; the fileserver (36 lines)
Following the suggestion of a HUMANIST in the U.K., I have almost
faithfully been adding line-counts to the subject lines of messages. I
have not counted the lines myself but used the built-in line-counter
provided me by the operating system I use, CMS. This counter registers
the total number of lines in a message, including the header. It's not
much work to do this, and I'll continue to do it without protest, but I
want to make sure that some of you are finding this count useful. Please
let me know >>only if you are<<.
On another matter, I propose that henceforth announcements of
conferences be posted once to all of us, then transferred to the
fileserver for future reference. I also invite anyone with relevant
bibliographies, catalogues (such as the SNAPSHOT of the Oxford holdings,
Lou), or technical reports, to submit them for storage on the server
together with a very brief notice that will be sent to all HUMANISTs
when the material is ready for access. The biographies will be kept
there, and I encourage anyone whose life has changed in a way that he or
she wants to announce, to fetch the relevant file, make the update, and
send me the results. Shortly we will make efforts to see what can be
done to store public-domain packages on the server. One HUMANIST, David
Sitman, has already sent me a number of very useful suggestions about
the operation of the server. I invite others to do the same.
Willard McCarty
mccarty@utorepas <bitnet>
=========================================================================
Date: 24 February 1988, 10:05:10 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Jean Talon Project (44 lines)
----------------------------
From <CNNMJ@BCVMS> (M.J. CONNOLLY [Slavic/Eastern])
From my involvement with the Domesday Project, as user, adapter and
evaluator, I have also been kept informed about a similar Canadian project,
namely the Jean Talon project, which seeks to have the next Canadian census
follow the Domesday mode of collection and publication (Domesday was a
stock-taking of British life in the '80s). This type of project requires
the combining of data and text from all disciplines, visual and cartographic
material to accompany same, and well-designed programs to integrate same and
present it in an interface that can be used by journalists, officials,
businessmen, but primarily by teachers, researchers, and students. It is
an excellent example of what recent HUMANIST discussions have been seeking:
TEXT in CON-TEXT.
The moving force behind Jean Talon is:
Mr Victor B. Glickman, Regional Director
Statistics Canada
25 St Clair Avenue East
Toronto Ontario
M4T 1M4
tel: (416) 973-6591.
He will certainly be glad to send scholars information and to put them on his
'network' (unfortunately snail-mail).
One might like to see how HUMANIST and Jean Talon could link up or,
at very least, interact. The project is most ambitious, but Glickman seems
to be covering all the bases for funding sources, project organization,
and learning from others' mistakes. I can see the need for a good dose of
'humanistic' input here, though.
Prof M.J. Connolly
Slavic & Eastern Languages
Boston College / Carney 236
Chestnut Hill MA 02167
( U . S . A .)
<tel:> (617)552-3912 <email:> cnnmj@bcvax3.bitnet
=========================================================================
Date: 24 February 1988, 11:18:30 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Text retrieval & related programs for Macintoshes (26 lines)
FROM John J. Hughes <XB.J24@Stanford.BITNET>
Help needed from HUMANISTS!
Other than SONAR (Virginia Systems Software Services, Inc.) and
SQUARE NOTE (Union Software), what commercial and noncommercial
text retrieval, concording, and text analysis programs are
available for Macintoshes?
Thank you in advance for your help.
John J. Hughes
Bits & Bytes Computer Resources
623 Iowa Ave.
Whitefish, MT 59937
(406) 862-7280
XB.J24@Stanford.BITNET
=========================================================================
Date: 24 February 1988, 13:08:53 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROMs (21 lines)
----------------------------
From Joe Giampapa <GIAMPAPA@BRANDEIS>
I am asking this question out of curiosity ...
It sounds like a few HUMANISTS are using CD-ROM technology for saving their
texts. For those who are, may I ask what the process is that you use to
do so? Specifically, what company(ies) are involved (or is it on site?),
what do you do for the CD-ROM reader, and what is the cost of all this?
Joe Giampapa
giampapa@brandeis.bitnet
=========================================================================
Date: 24 February 1988, 13:11:19 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROM, etc. (31 lines)
----------------------------
From O MH KATA MHXANHN <MCCARTHY@CUA>
I noticed this morning in the February issue of Micro/Systems
the following jetsam among "Random Gossip & Rumors":
Later this year, Sony, Sharp, and Verbatim are
expected to introduce high-capacity, removable,
rewritable, optical disk drives that may challenge
Winchester hard disks as primary storage devices.
Sony's drive is expected to store 650 MB, have a
120-millisecond access time, use an SCSI interface,
and cost about $1,000.
I wonder if the digital cognoscenti of this group regard
this information as
(a) likely to be true
(b) optimistic
(c) vaporously induced phantasmagoria
(d) a lengthy typographical error
(e) all of the above
(f) none of the above.
=========================================================================
Date: 24 February 1988, 13:14:09 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: SNOBOL4/brain damage (42 lines)
----------------------------
From Richard Goerwitz <goer@sophist.uchicago.edu>
Since SNOBOL4 and Icon are languages particularly suited to Humanistic uses,
I don't think that this will be too much of a sidetrack.
In response to Lou Burnard's query about switching from SNOBOL/SPITBOL to
Icon, let me say that I actually sent a letter on this to Griswold (the
creator of Icon) at arizona.edu. I also sent a similar letter to Mark Emmer,
who markets a SNOBOL4 implementation for MS-DOS. Let me comfort you: Appar-
ently lots of folks have trouble re-thinking SNOBOL4 problems in Icon. The
reason is partly that Icon is much more procedurally oriented. More than
this, though, its string-scanning functions are much lower-level and better
integrated into the rest of the language. What this means is that you'll
need to write actual procedures called ARB, ARBNO, RARB, etc. To call them
at run-time, you'll need to use the "call-by-string" feature available on
Icon versions 6 and up.
This will be a pain until you get used to it. Once you get used to it, Icon
becomes a much more powerful tool to work with.
I guess the trouble with SNOBOL4 and Icon is that SNOBOL4 looks a little like
Icon in some respects - just enough to be dangerous!
If you want advice at any point, try emailing to the icon-project@arizona.edu.
They are busy with version 7 now, but generally they return mail within two
days. Apparently they enjoy a show of interest & questions.
-Richard L. Goerwitz
goer@sophist.uchicago.edu
!ihnp4!gargoyle!sophist!goer
=========================================================================
Date: 24 February 1988, 14:51:28 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Latin analysis software (21 lines)
----------------------------
From Bob Kraft <KRAFT@PENNDRLN>
Jean Schumacher at CETEDOC in Belgium (NETDOC@BUCLLN11) reminds me
that CETEDOC has been involved in analysis of Latin texts for about
two decades and is willing to explore ways in which its programs
and experience can be of assistance to others -- for example, files
might be sent electronically to CETEDOC for analysis and the results
returned in the same way. CETEDOC also supports the suggestion that
an inventory list of such programs and services would be helpful.
Bob Kraft (CCAT)
=========================================================================
Date: 24 February 1988, 18:34:13 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Snobol vs. Icon (21 lines)
----------------------------
From amsler@flash.bellcore.com (Robert Amsler)
I believe icon is not the clearcut step forward some would have us believe.
It solved a number of problems computer scientists had with snobol as
a language--but it seems unclear to me that these were problems that
non-computer scientists were experiencing. I believe snobol is excellent for
small programs that either do complex extractions or rewrites of data.
As the programs get larger, the programming language theory defects in
snobol may become unreasonable; I certainly wouldn't advocate it as the
best language in which to build complex systems with thousands of lines
of code--but frankly some of the changes between snobol and icon are
NOT steps toward making the language easier to use.
=========================================================================
Date: 24 February 1988, 18:41:04 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Re: Random Gossip and Rumors (about mass-storage media)
----------------------------
From amsler@flash.bellcore.com (Robert Amsler)
Optimistic, or possibly even ``run it up the flagpole and see if
anyone salutes''. The events are very desirable goals from the
vendors perspectives, but there current capabilities put them further
away from realizing these than the rumor would seem to suggest. If
you replaced later this year with within 3 years I'd find it more
believable. If you changed the price to $3000 (which might mean they
wouldn't make it) it would also be more reasonable.
So, how is this... Within 3 years Sony will be marketing a $3000,
1 Gigabyte erasable optical disc.
=========================================================================
Date: 25 February 1988, 09:28:59 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Random gossip and rumors about magneto-optical technology, cont.
----------------------------
From Robin C. Cover <ZRCC1001@SMUVM1>
The "rumor" alluded to by McCarthy is probably second generation, at least.
There was a report in PCWeek to the same effect: that Sony's magneto-optic
drive would cost $1000 this summer, have a data-transfer rate of 680K per
second, 650 megabytes of read/write 120 millisecond access time disk space.
It sounded too good to be true so we contacted Sony...raise that to $7500.
But apparently Sharp, Verbatim and Sony did demo such things at Comdex, and
I have heard of another vendor releasing a magneto-optic read/write drive
in "first quarter" this year, allegedly having 45 megabytes per side on the
disk, 30 millisecond access time, and costing around $1500. More dreaming?
If anyone knows anything reliable about magneto-optical, I'd like to hear it.
Robin C. Cover
ZRCC1001@SMUVM1.bitnet
=========================================================================
Date: 25 February 1988, 09:34:44 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Icon/Snobol (26 lines)
----------------------------
From R.J.Hare@EDINBURGH.AC.UK
Message-ID: <25 Feb 88 09:22:36 gmt 340163@EMAS-C>
Those interested in the Icon versus Snobol aspect of the Icon discussions may
be interested in the paper:
Griswold, R.E., "Implementing SNOBOL4 Pattern Matching in Icon", Compute r
Languages, Volume 8, pages 77-92 (funny - I don't have the date for that
one, only the volume).
Griswold, R.E. and Griswold, M.T, "High Level String Processing Languages:
COMIT, SNOBOL4 and Icon", Abacus, Volume 3, No 4, pages 32-44, Summer 1986.
If anyone were that interested, I could mail them a bibliography of about 30
Icon related items...
Roger Hare.
=========================================================================
Date: 25 February 1988, 10:08:06 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Hypertexpert systems (16 lines)
----------------------------
From Sheldon Richmond <S_RICHMOND@UTOROISE>
Is there anyone who could tell me something about
HypertExpert Systems produced by Knowledge Garden Inc?
Thanks.
Sheldon Richmond
=========================================================================
Date: 25 February 1988, 10:10:20 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: CD-ROM, etc. (16 lines)
----------------------------
From M.J. CONNOLLY (Slavic/Eastern) <CNNMJ@BCVMS>
Can't say too much on specs, but (a), likely to be true, is
closest. Removable 50MB optical read/write, e.g. Verbatim, may be here
as early as the summer. Watch for the usual 50>100>200Mb progression
in capacity. Too soon to speculate on pricing, SCSI most likely.
The rest is silence.
=========================================================================
Date: 25 February 1988, 10:50:57 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: TeX and the public domain (64 lines)
----------------------------
From dow@husc6.BITNET (Dominik Wujastyk)
No, TeX really *is* in the public domain, in two important senses of the
phrase. First, yes you can buy personal TeX from Lance Carnes, for $249.
What you pay for is not the programming that went into TeX (what would it cost
to hire Knuth for ten years!), but for the considerable work that went into
rewriting the Pascal source so that it would compile and run efficiently on a
PC or AT. And Carnes has done an excellent job. PCTeX runs as fast on a
good AT as on a medium loaded Vax. Plus you get the TeXbook, LaTeX manual,
and macros (LaTeX, AMS, Spivak's Vanilla) and installation, TFM files etc. etc.
In other words, you are paying for little more than the cost of putting the
package together, testing it, making it easy to run and install, and
documenting it. In fact, Carnes is doing the job for the PC community that
a sysop does on a mainframe machine. The full WEB source code of TeX
is available from Carnes either by mail or by downloading from the
PCTeX bulletin board.
Secondly, TeX for Unix, VMS, Tops-20, and most other systems is avaiable
for the cost of the tape, or the FTP. I expect that TeX is already
available on your mainframe somewhere, if you have not already discovered
it.
In a purer sense of PD, there is Monardo's Common TeX. This is the
translation of TeX into C. This is yours for the downloading from several
sources. There is even a ready-compiled PC version, complete with the
plain.fmt, available on several bulletin boards in the Boston area
(E.g., Channel One, (617) 354 8873, or Viking Magic (617) 354 2171), and
very probably across the country. There is another PD version, again based
on a C translation (done automatically this time), and the source of that
too is easily available. You would need to compile it yourself, though.
Both these versions are also excellent, but you have no documentation or
help in getting them up and going. Really, you have to have used TeX before
on some other system, so that you know where everything should go, and how
to use TeX. You also have to get your own fonts and drivers (also
available in PD from Nelson Beebe@science.utah.edu). The point is, someone
with the know-how and a modem could put together a perfectly good version
of TeX on a PC or AT without buying anything at all. It would just take
a bit of time and effort.
Incidentally, Monardo is offering a C version of Metafont for beta testing,
and the final version will be released into the PD very soon.
The other sense of PD that I have in mind is that TeX's algorithms are
freely available. I know of two commercial companies who use parts of TeX
in their systems and I am sure there are others. Anyone writing a serious
text processing program or word processor today is going to look very carefully
at TeX's source. XyQuest have used TeX's hyphenation algorithms in
their excellent word processor, XyWrite III plus. And Graham Asher of
Informat, a London typesetting company, has made TeX the heart of a major
professional typesetting system that his company uses and sells. (It is
used to set several of Gower Publications scientific journals.)
Dominik Wujastyk
=========================================================================
Date: 25 February 1988, 13:02:28 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: New item on the file-server
The file-server now contains a desultory bibliography on the Icon
programming language. It has been submitted by Roger Hare of Edinburgh,
who warns that it is simply what he has been able to gather in the last
12 months or so. Caveat emptor! (and let him or her remember that it's
free). Contributions to this bibliography can be sent to me.
The file is named ICON BIBLIOG.
Willard McCarty
mccarty@utorepas <Bitnet>
=========================================================================
Date: 26 February 1988, 12:09:53 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Mega-storage devices, and dreams, and things
----------------------------
From Eva Swenson <ESWENSON@UTORONTO>
I have found that promises of bigger and better eventually come
true, with emphasis on "eventually". It is just a matter of
time. The promise, of course, may be fulfilled with side effects
even though none of these were promised. And not all the side
effects are desirable.
So what else is new?
=========================================================================
Date: 26 February 1988, 12:13:04 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Snobol - Icon transition (17 lines)
----------------------------
From dow@husc6.BITNET (Dominik Wujastyk)
In the Icon program library that I received with the MSDOS version of Icon 6
from Arizona, there was a file containing Icon procedures which duplicate
many of the built in functions of Snobol, like LEN, BREAK, ARB and so on.
I hope everyone knows this already.
Dominik
=========================================================================
Date: 26 February 1988, 12:27:47 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Producing a CD-ROM at the PHI (48 lines)
----------------------------
From John Gleason <XB.M07@STANFORD.BITNET>
Here's what The Packard Humanities Institute and, as far as I know,
the Thesaurus Linguae Graecae do to produce a CD-ROM:
1. Imbed in the text files an extensive system of markers, to
permit access by author, section, etc.
2. Process these files through a humungous program that constructs
various directories of these markers.
3. Send the resulting tapes to a contractor who processes them into
CD-ROM-type files in the "High Sierra" format which is proposed as
standard by the National Information Standards Organization.
The contractor we have used is:
Publishers Data Service Corporation (PDSC)
2511 Garden Road, Bldg. C
Monterey, CA 93940
(408) 372-2812
4. The contractor then sends his tapes to a company which makes a
master CD ROM with a few copies for testing. Our contractor uses:
Digital Audio Disk Corporation
1800 North Fruitridge Ave.
Terre Haute, IN 47804
(812) 466-6821
5. After testing the sample CD ROM's, we order as many additional
copies as we need.
There are lots of detailed steps that I've omitted, but that's the
general outline.
John M. Gleason, The Packard Humanities Institute, xb.m07@stanford
=========================================================================
Date: 26 February 1988, 12:29:25 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Computer scientists and SNOBOL (45 lines)
----------------------------
From Richard Giordano <RICH@PUCC>
I remember a few comments by computer scientists regarding SNOBOL, (I
think they are in Wexelblat's HISTORY OF PROGRAMMING LANGUAGES), that
may (or may not, I don't know), have been 'solved' in ICON. Aside from
the whole GOTO question, there were two issues: the ambiguity regarding
the use of a space (they have two meanings); and there appeared to be
severe inefficiencies in execution time. I also think there might have
been some discontent with SNOBOL's YES/NO/UNCONDITIONAL GOTO structure
as well. One overwhelming criticism of the language is that its
strength is its greatest weakness--SNOBOL's terse structure makes its
programs very difficult to document. SNOBOL code written by one programmer
looks like randomly-strewn characters to the next.
I am not at all sure that I agree with Robert Amsler's comments on SNOBOL's
limitations as a language for systems regarding thousands of lines of
code. Who among us writes thousands of lines of code anyway?
That sort of thing is developed by teams, teams that are managed.
The selection of a programming language in a team effort has much more to
do with management decisions and concerns than it has to do with the
intrinsic merits of this or that particular language. This explains, in
part, why there are so many FORTRAN and COBOL shops around. Computer
scientists, and their opinions, usually count for little or nothing
in this equation. I also think that Amsler underestimates SNOBOL's
power. It can do far more than "complex extractions or rewrites of data".
I've written complex parsers in SNOBOL, as well as programs that do
pretty complicated manipulations, and analyses, of symbols. I agree
with Amlser that the problems non-computer scientists were experiencing were
different from those experienced by computer scientists. My problem with
SNOBOL is that it doesn't really have the data processing punch that
PL/I has, particularly when you want to pass parameters. So big deal.
I do have an objection to Amsler's implicit message that computer
scientists know best. They don't, but that's a different story...
Rich Giordano
Princeton University
=========================================================================
Date: 26 February 1988, 12:30:41 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Stemmatic analysis of Latin mss (43 lines)
----------------------------
From Norman Zacour <ZACOUR@UTOREPAS>
It has been suggested that I ask fellow Humanists for some advice about
a small programming project that I have become engaged (immersed?
bemired?) in. It has to do with the mechanical problems surrounding the
making of critical editions of (in this case) Latin texts. As the mss.
multiply and the variants begin to pile up, the difficulty of keeping
them all in order increases in geometrical proportion; they have to be
numbered and numbered again as new mss. are used, new variants found.
One answer is to embed the variant note in the text itself, right beside
its lemma, with the risk, ultimately, of introducing every kind of error
when it has to be retyped and numbered preparatory to submission to a
publisher. I have written a program to read a text file with such
embedded notes of variants, as well as embedded "fontes" (references to
sources such as the Bible, ecclesiastical authorities, etc). The program
copies the variant notes into a separate file, fishes out the lemma and
puts it with the note, copies the fontes into a second file, copies the
text itself, now newly formatted and shorn of notes, into a third file,
counts the line numbers of the new text file, and numbers both the
variant notes and the fontes with the number of the lines in the newly
formatted text to which they refer. It is purely a mechanical
operation, but is designed to preserve a semblance of sanity and
latinity. Depending on the speed of one's machine it will handle a
100,000 byte text in from 15 to 35 seconds. The next step is to have
the program examine the variants themselves, classify them according to
type, the purpose being to determine family relationships among the mss.
involved, and so to fashion the preliminaries of a stemma. Is there
anyone out there doing this sort of thing? If the response warrants it,
I shall be happy to post a summary on HUMANIST so that others can keep
abreast of what is going on.
Norman Zacour (Zacour@Utorepas)
Pontifical Institute of Medieval Studies
Toronto
=========================================================================
Date: 26 February 1988, 12:34:01 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Help on research project by novice (53 lines)
----------------------------
From PROF NORM COOMBS <NRCGSH@RITVAX>
I am a historian by training and only arrived recently ;by the back door
in the field of communications. I have been using a computer conference
system to teach distance learners. They learn material from watching videos
and reading texts, but then they check into the college VAX system weekly
to join a class discussion. The conference is asynchronous which allows
maximum time flexibility. Most students found they needed very little computer
knowledge. Those with a PC and modem who could access the system from home
or work came to "love" it. We did have a lot of participation, and I felt
the studetns shared more personal items than they do in my classroom meetings.
Now I have a record of last fall's class. There were 56 topics with 35
to 45 replies to each. The students also wrote essay exams and submitted
them by computer. It seems to me, though I am not a communications specialist,
that this body of data could be useful. I intend to analyze it during the
spring and hope to find useful results by summer to share with a wider
scholarly community.
Here are some of the items I had intended to examine. (I expect to run
the data through Writers Workbench.)
1. compare conference replies with essay exams to see effect of different
situation on writing. e.g. formal vs informal. Sophistication. Length
of sentence and length of word.
2. Compare first and last week replies in conference for any changes in
style.
3. Chart how much the discussion merely answered the professor's topic
questions and how much involved interaction with other participants' comments.
As I confessed previously, I am new in studying communications, and I would
certainly appreciate any good hints about what might be done with this data
and what kinds of tools could be helpful. Any ideas are welcomed.
I will be away for a week and have had my Humanist mail stopped for the
duration. Therefore direct mailings would be best as they will get through.
NRCGSH@RITVAX.BITNET
Norman Coombs
=========================================================================
Date: 26 February 1988, 14:50:37 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject ODA SGML list (46 lines)
Announcing the creation of an ODA/SGML mailing list.
The ISO 8613 ODA/ODIF has recently been made into an
International Standard. This, and the growing interest
in both ODA and SGML is cause enough for a mailing list.
In case you don't know, ODA stands for Office Document
Architecture, ODIF for Office Document Interchange Format,
and SGML for Standard Generalized Markup Language.
If you are interested in these standards, or like myself
are trying to use them in future products, then this
mailing list is for you. Lets trade horror stories :-)
To join the mailing list send mail to:
oda-request@trigraph
or ...utzoo!trigraph!oda-request
Thanks,
Michael Winser
--
...utscri!trigraph!michael Michael Winser
michael@trigraph.UUCP Trigraph Inc.
5 Lower Sherbourne St. #201
(416) 363-8841 Toronto,Ontario M5R 3H8
----------------------------------------
=========================================================================
Date: 26 February 1988, 14:53:22 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: British natural language processing? (25 lines)
----------------------------
From Grace Logan <LOGAN@VAX.OXFORD.AC.UK>
I have received an urgent request from my home university
for information "about the Natural Language Processing
which the British Government are busy implementing."
Now I would very much like to help out the folks back
home, but Natural Language Processing is not something
with which I have a great deal of experience.
I wonder if my fellow HUMANISTs have more of an idea
than I do about where to start to collect information
on the topic.
I should be very grateful.
Grace Logan
=========================================================================
Date: 26 February 1988, 15:28:59 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: TeX and the public domain (19 lines)
----------------------------
From ked%garnet.Berkeley.EDU@jade.berkeley.edu (Charles Faulhaber)
One of the slickest WYSIWYG text formatters around is
Arbortext's Publisher, currently available only for
the Sun. Essentially it is a user-friendly front end
for TeX with SGML style templates for various kinds
of documents. It gives the end user all of the power
of TeX without having to know anything about the
language at all. It still needs work but it is head
and shoulders above any text formatting system I know.
=========================================================================
Date: 26 February 1988, 15:31:50 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Stemmatic analysis of Latin mss. (14 lines)
----------------------------
From ked%garnet.Berkeley.EDU@jade.berkeley.edu (Charles Faulhaber)
The TUSTEP program written by Wilhelm Ott (Tuebingen) is designed to
handle these kinds of problems. Francisco Marcos Marin (Madrid)
also has a mainframe IBM program for this.
=========================================================================
Date: 26 February 1988, 15:33:58 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: ODA SGML list (38 lines)
Announcing the creation of an ODA/SGML mailing list.
The ISO 8613 ODA/ODIF has recently been made into an
International Standard. This, and the growing interest
in both ODA and SGML is cause enough for a mailing list.
In case you don't know, ODA stands for Office Document
Architecture, ODIF for Office Document Interchange Format,
and SGML for Standard Generalized Markup Language.
If you are interested in these standards, or like myself
are trying to use them in future products, then this
mailing list is for you. Lets trade horror stories :-)
To join the mailing list send mail to:
oda-request@trigraph
or ...utzoo!trigraph!oda-request
Thanks,
Michael Winser
--
...utscri!trigraph!michael Michael Winser
michael@trigraph.UUCP Trigraph Inc.
5 Lower Sherbourne St. #201
(416) 363-8841 Toronto,Ontario M5R 3H8
----------------------------------------
=========================================================================
Date: 26 February 1988, 21:57:46 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Snobol comments (53 lines)
----------------------------
From amsler@flash.bellcore.com (Robert Amsler)
Curious. I was deliberately striving to say that computer scientists
DON'T know all that much about ease of use--or rather that concerns
about formal syntax, theoretical power and such might get in the way
of concerns about simplicity of learning, etc. Another good example
of this is BASIC. BASIC is a fine language for simplicity of
understanding--which was its intended goal; however, I cringe at the
thought of someone writing complex system in BASIC.
I am a computational linguist. It is QUITE reasonable for some massive
projects to be carried out in academia. They could even be done by
a lone individual. I do feel that today someone should not undertake
such a project in Snobol. When one gets to doing things like writing
mechanical translation systems or creating symbolic algebra
interpreters or developing text understanding systems--the need is
for a suitable contemporary language. These projects ALSO should not
be done in Fortran or C or Pascal. They probably should be done in
LISP or Prolog. They MAY be done in Fortran or C or Pascal at
commercial shops because they expect to sell the resultant software
to people who can only run in those environments--but in research labs
or academic institutions this isn't even typically the case.
Finally, I didn't intend the somewhat stronger statement that Snobol
is only good for rewrites or extractions. These happen to be the two
broadest classes of tasks I can think of for its use. Parsing IS a
rewrite system, incidentally. So, parsing isn't something I'd have
excluded in that even IF I had meant it in the strongest sense. If I
were to try and imagine what tasks are not rewrites or extractions
I'd probably have to say numerical computations. A concordance is a
rewriting task; automatic indexing is an extraction task. These seem
perfectly suited to Snobol, being rather simple procedures. Ah,
there is one other class of programs--generation systems. Snobol
would also be excellent there.
The main point of my message was that I was trying to describe the
justifications I could see for someone using Snobol RATHER THAN any
other language for some tasks. If one assumed that someone didn't
know any programming language and was prepared to learn a language;
under what circumstances should the language they learn be Snobol
rather than Icon, C, Fortran, Basic, Lisp, Pascal, etc. I believe
there are reasons this is true. I also believe there are tasks in
which they should not learn Snobol, but should instead learn Icon,
etc.
=========================================================================
Date: 28 February 1988, 12:42:21 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Correction of address for SGML list (14 lines)
On 26 February I circulated a notice about a ListServ list devoted to
SGML. Interested people not using the UNIX network were told to
subscribe by sending a request to "oda-request@trigraph". The address
should have been "oda-request@trigraph.uucp".
Willard McCarty
mccarty@utorepas <Bitnet>
=========================================================================
Date: 28 February 1988, 12:47:03 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: More on computer scientists and SNOBOL (83 lines)
----------------------------
From Joe Giampapa <GIAMPAPA@BRANDEIS>
This note is in response to Richard Giordano's note, "Computer scientists
and SNOBOL".
He made a couple of points which I would not agree with. Part of Giordano's
argument was as follows:
Who among us writes thousands of lines of code anyway? That sort
of thing is developed by teams, teams that are managed. The
selection of a programming language in a team effort has much
more to do with management decisions and concerns than it has
to do with the intrinsic merits of this or that particular language.
This explains, in part, why there are so many FORTRAN and COBOL
shops around. Computer scientists, and their opinions, usually count
for little or nothing in this equation.
I do not see the connection between the "thousands of lines of code" and
the "teams that are managed" statements. Thousands of lines of code could be
written by one individual, or written by a team. Even if written by a team,
it does not change the problem of a large program's readability and
manageability, as embodied by that language.
The criteria by which programming languages are selected, I agree, are not
always reduced to the concerns of an optimal language. Future system support,
the availability of coders and implementation of a language on a system, and
the cost of maintaining such a system are important managerial concerns.
However, it is ridiculous to state that in a way which factors out the opinions
of computer scientists (or, pragmatically, the program coders). There is no
way a manager can make effective project decisions without computer know-how.
Neither is it intelligent to expect cost-effective work from programmers
who have to work with a language which was chosen without their concerns in
mind. Managers and programmers have to work together in the best interests
of the project -- not in the mutually exclusive interest of one side. It
disappoints me to feel I have to make such an obvious claim.
"This explains, in part, why there are so many FORTRAN and COBOL shops around."
I do not know much about COBOL, but I know that FORTRAN is around because it
has had support of magnitude unrivaled by any other language. Most user
libraries for scientific computing were written and maintained in FORTRAN,
and FORTRAN is the unrivaled best optimizing compiler language. It makes no
sense to rewrite everything in C (which was designed for writing programmer-
optimized code).
Finally, I would like to look at Giordano's closing paragraph:
I do have an objection to Amsler's implicit message that computer
scientists know best. They don't, but that's a different story...
It is good that HUMANIST discussions express the author's emotional involvement
in his/her side. However, we should be a little more conscious of when our
emotions overtake our arguments and have no bearing on the matter. Whether
Rich Giordano thought that Amsler had vested interest in making exaggerated
claims about computer scientists, or not, or whether Amsler did in fact make
those claims (I do not know --- how was the originally provocative letter
phrased?) are beyond the issue of Giordano's preferred style of responding to
them. If Rich Giordano wanted to direct those comments to Amsler, he should
have done so directly. Not only did Giordano miss the target (Amsler replies
that he is a computational linguist), but he succeeded in alienating computer
scientists with his irrelevant comment.
As a computer science student and professional, I cannot allow such a
baseless claim to go unheeded. HUMANIST is an open forum, with the message-
poster assuming full responsibility for her/his statements. It is also
academic in nature, permitting the uneditted expression of opinions and
insights. It would be a travesty to see it reduced to the rubble of a forum
for expressing crass generalizations and to defame any profession or area of
study.
Joe Giampapa
giampapa@brandeis.bitnet
=========================================================================
Date: 28 February 1988, 19:34:34 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Icon and Snobol (31 lines)
----------------------------
From Richard Goerwitz <goer@sophist.uchicago.edu>
Richard Giordano's note admittedly exaggerates some points, as I see it, and
does not fully explain the facts surrounding others. But I do understand the
points he was trying to make. If taken in context - as responses to equally
one-sided remarks made by previous posters - they stand as an interesting cor-
rective. It therefore seemed a bit out of place to see his ideas labled as
a case of emotions run wild, or as "crass generalizations" a "travesty" and
various and sundry uncomplementary things. The Humanist is indeed an open
forum. This, however, does not mean that we have to demean each other when
we get a little out of line....
-Richard L. Goerwitz
goer@sophist.uchicago.edu
!ihnp4!gargoyle!sophist!goer
P.S. I retain the subject heading, since this does actually come as a followup
to a discussion concerning two computer languages that are well suited to
the needs of Humanists, namely Icon and Snobol.
=========================================================================
Date: 28 February 1988, 23:49:55 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Call for papers, 4th Waterloo New OED Conference (69 lines)
----------------------------
From Maureen Searle <msearle@watsol.UWaterloo.ca>
UNIVERSITY OF WATERLOO
CENTRE FOR THE NEW OXFORD ENGLISH DICTIONARY
4TH ANNUAL CONFERENCE
CALL FOR PAPERS - CALL FOR PANELISTS
INFORMATION IN TEXT
October 27-28, 1988
Waterloo, Canada
This year's conference will focus on ways that text stored as electronic
data allows information to be restructured and extracted in response to
individualized needs. For example, text databases can be used to:
- expand the information potential of existing text
- create and maintain new information resources
- generate new print information
Papers presenting original research on theoretical and applied aspects of
this theme are being sought. Typical but not exclusive areas of interest
include computational lexicology, computational linguistics, syntactic
and semantic analysis, lexicography, grammar defined databases, lexical
databases and machine-readable dictionaries and reference works.
Submissions will be refereed by a program committee. Authors should send
seven copies of a detailed abstract (5 to 10 double-spaced pages) by
June 10, 1988 to the Committee Chairman, Dr. Gaston Gonnet, at:
UW Centre for the New OED
University of Waterloo
Waterloo, Ontario
Canada, N2L 3G1
Late submissions risk rejection without consideration. Authors will be
notified of acceptance or rejection by July 22, 1988. A working draft
of the paper, not exceeding 15 pages, will be due by September 6, 1988
for inclusion in proceedings which will be made available at the
conference.
One conference session will be devoted to a panel discussion entitled
MEDIUM AND MESSAGE: THE FUTURE OF THE ELECTRONIC BOOK. The Centre invites
individuals who are interested in participating as panel members to submit
a brief statement (approximately 150 words) expressing their major
position on this topic. Please submit statements not later than
June 10, 1988 to the Administrative Director, Donna Lee Berg, at the above
address. Selection of panel members will be made by July 22, 1988.
The Centre is interested in specialists or generalists in both academic and
professional fields (including editors, publishers, software designers and
distributors) who have strongly held views on the information potential of
the electronic book.
PROGRAM COMMITTEE
Roy Byrd (IBM Corporation) Michael Lesk (Bell Communications Research)
Reinhard Hartmann (Univ. of Exeter) Beth Levin (Northwestern University)
Ian Lancashire (Univ. of Toronto) Richard Venezky (Univ. of Delaware)
Chairman: Gaston Gonnet (Univ. of Waterloo)
=========================================================================
Date: 29 February 1988, 08:55:52 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Re: Snobol comments (26 lines)
----------------------------
From Hans Joergen Marker <DDAHM@NEUVM1>
Robert Amsler's note on Snobol made me curious as well. I don't
understand what kind of tasks are so much better handled in
Prolog and Lisp than in C -- so that these languages are usable
for solving problems in humanities and C is not.
Mind you I am asking out of ignorance.
I am only experienced in a few languages, and after I have
learned C, I have no intention of learning another language.
I feel that anything I want to do is done very comfortably
in C, especially when you make use of some of the
many available libraries.
Perhaps I should recommend a book: Herbert Schildt: Artificial Intelligence
using C. It was that book which convinced me that AI methods
might actually be of practical use anyway.
=========================================================================
Date: 29 February 1988, 09:00:06 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: British natural language (21 lines)
----------------------------
From Sebastian Rahtz <spqr@CM.SOTON.AC.UK>
I believe the British Government 'natural language processing'
that Grace Logan refers to may be the Prime Minister saying
"the National Health Service is safe in our hands" on election,
and then proceeding to dismantle it as fast as she can go.
I understand a number of other governments have been doing
similar research
sebastian rahtz
=========================================================================
Date: 29 February 1988, 09:03:15 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Public domain programs (36 lines)
----------------------------
From Sebastian Rahtz <spqr@CM.SOTON.AC.UK>
I sympathise with Dominik W. in his views on the excellent support
for TeX vs. the minimal support from big companies. But mega-fan though
I am of TeX, I cannot really agree with his premise that the whole
system is there for the taking by the new punter. Agreed, there ARE
PD versions for the PC, Atari etc, and Unix/Vax/IBM etc people can
get the tape for a minimal cost; but:
a) the printer drivers are NOT generically in the public domain
as TeX itself is; I know Beebe etc give away their drivers, but they
might not one day
b) the work required to build oneself a working TeX environment
is considerable, unless you spend money. I just about maintain a TeX
system on our machine in conjunction with our systems programmer, and
we keep our heads above water only because we support about 10 users.
Just because it costs nothing to buy doesn't mean its free of
maintenance charges!
I'd support the suggestion that HUMANISTs out there who just want
to typeset their papers and books in conventional ways spend some
real cash and buy a system like Publisher and get on with what they
are paid for, writing & thinking, not typesetting!
I except people like Dominik whose Devanagari needs are not catered for
in standard software....
sebastian rahtz
=========================================================================
Date: 29 February 1988, 09:05:22 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: Ghettoes (41 lines)
----------------------------
From Sebastian Rahtz <spqr@CM.SOTON.AC.UK>
I haven't yet had time to take up Willard's gauntlet and find out what
HUMANISTs are interested in (I will have a go at it), but I did
quickly see what words they use in their biographies: these are the
'interesting' words that occur more than 10 times:
Philosophy 11 programming 15 database 27
Text 11 Information 16 IBM 27
medieval 11 Linguistics 16 Greek 30
YORK 11 mainframe 17 text 33
History 11 literary 18 texts 37
Hebrew 11 courses 18 French 38
Language 12 student 18 language 38
Macintosh 12 history 19 teaching 50
technology 12 VAX 21 Computer 54
Latin 12 Computers 21 English 56
concordance 13 applications 23 Humanities 58
music 13 writing 24 computers 63
German 14 teach 24 Computing 69
colleagues 15 languages 25 humanities 72
science 15 Science 26 computing 93
electronic 15 literature 26 computer 96
Doesn't prove a thing, does it? except maybe about history.
Sebastian
heres a *joke* for British HUMANISTs:
Q. what was the catchphrase in the Egyptian telephone company
privatisation?
A. Tell El-Amarna
=========================================================================
Date: 29 February 1988, 11:18:46 EST
Reply-To: MCCARTY@UTOREPAS
Sender: HUMANIST Discussion <HUMANIST@UTORONTO>
From: MCCARTY@UTOREPAS
Subject: SGML-based markup (65 lines)
----------------------------
From George M. Logan <LOGANG@QUCDN>
As the supervisors of Cheryl Fraser's thesis on an SGML-based standard for
encoding literary texts, we are pleased that Peter Roosen-Runge has found the
thesis to be a useful treatment of this subject. He gives an accurate summary
of the thesis:
I recently came across a Master's Thesis which gave me a
good introduction to the key ideas of SGML and what's involved
in applying them to the creation of a set of tags for literary
documents. An implementation in SCRIPT/VS is discussed,
there's a 90-page reference manual as an appendix which
gives a clear description of all the elements defined in
the "standard" proposed by the author, and she's provided
a sample markup and formatted output for a scene from Hamlet.
As Roosen-Runge says, the thesis is now available as a Technical Report from
the Department of Computing and Information Science at Queen's. We should add
that it has been fed into the discussions of the ACH working group on
text-encoding standards. There are also two follow-up papers. The first of
these--"Generalized Markup for Literary Texts"--will appear in the next issue
of Literary and Linguistic Computing. Co-authored by Cheryl and us, it offers
an overview of Cheryl's work and what we take to be its significance. The
second deals with two apparent problems with an SGML-based standard that were
discussed in the HUMANIST exchanges that followed the November 1987 Vassar
meeting on standards: (1) the fact that, whereas computer-assisted textual
studies often require the maintenance of multiple views of a document's
structure, SGML does not appear to be designed to easily accommodate such
views; (2) the fact that an SGML-based standard would appear to entail the
keyboarding of more markup than researchers are accustomed to, or are likely to
accept. This second paper, co-authored by the two of us, another MSc student,
and two members of Software Exoterica (which is developing an SGML parser),
discusses these problems and several solutions to them. It is currently under
consideration for journal publication, and is meanwhile available as a
Technical Report. The reference for the Technical Reports, then, are as
follows:
Fraser, Cheryl, A.
An Encoding Standard for Literary Documents
Technical Report 88-207
Department of Computing & Information Science,
Queen's University: January 1988
Barnard, David, et al.
SGML-Based Markup for Literary Text:
Two Problems and Some Solutions
Technical Report 87-204
Department of Computing & Information Science,
Queen's University: December 1987
David T. Barnard (barnard @ qucis.bitnet)
George M. Logan (logang @ qucdn.bitnet)
DEPARTMENT OF ENGLISH, QUEEN'S UNIVERSITY 613-545-2154
Kingston, Ontario K7L 3N6 Canada