Gopher Conference, Pt. II

[Public-Access at Mizzou1.Missouri.eduComputer]

From: "Tim Kambitsch, Butler University Libraries" <KAMBITSCH at BUTLERU.BITNET>
Subject: Trip notes from Internet Gopher 93 Conference (Part II)
Internet Gopher Conference 93 -- April 13, 1993 -- University of Minnesota

Eric Lease Morgan (a.k.a. Mr. Serials) showed his Pearl Script for
systematically collect E-journals.

Marie Christine Mahu of Yale described her use of Proc mail for collecting
Gopher data from contributors

Prentice Riddle reported on G-mail and GoForm.  GoForm has potential for
forms completion for ILL, reserve requests, electronic reference, and an
online suggestion box.

Mahesh Subramanya from Notre Dame presented Notre Dame's automated
administration of Gopher submissions.

Rich Wiggins and Dennis Boon of MSU reported on a number of innovative files
and directories at MSU.  These include a voice library, photo gallery, and
a log analyzer program.

David Singer announced the availability of an OS2 Gopher client.

One of the neatest tools was a demo of class schedules and relational
searching presented by Edward Moy at Stanford University.  Search results
from one query were used to as an intermediate set for the next query.  Data
elements included day(s) of the week, academic department, building, time of
day and instructor.)

The winning entry was Moo Gopher: Collaborative Information Retrieval presented
by Larry Masinter and Erik Ostrom from Mankato State University. MOO Gopher
has its heritage in the multi-user dungeons (MUD) role playing games.
Moo Gopher enables more than one person to view a gopher listing and
through messaging allow one user (mentor or librarian?) to instruct and lead
one or more other users through Gopherspace. MOO Gopher is located at
theory.cs.mankato.msus.edu port 1709.

After lunch three different tracks of programs were offered:

Track 1: Server Administration / Security and Authentication
Track 2: Cooking Your Own Gopher / Access to Structured Databases
Track 3: Resource Location and Classification / Organizing Subject-Matter
based gophers.

                RESOURCE LOCATION AND CLASSIFICATION

All Gopher administrators have to decide how to organize their own server.
Be ready to take some heat from users for whatever way you organize things.
Everyone has their own ideas of how information should be logically ordered.

The Used Bookstore model is easily understood by all users, but some users can
become lost when the number of entries grows too large.  The LC and Dewey
classification systems were almost  booed by the audience.

Sue Davis described the M-Link service out of the University of Michigan.  A
service for providing services for public libraries.  Go M-Link is the gopher
front-end for the service.  M-Link uses a public library analogy.  They use
very broad categories.  They get about 500 queries a day from public libraries
and end users around Michigan. She spoke about how they have gone around
government agencies to get them to !donate? data, but some have gotten so
excited by the concept they have started up their own gophers.  She also spoke
on how gopher administrators need to have collection policies based upon the
community being server.  To access M-Link you can point your Gopher client or
Telnet to: viennna.hh.lib.umich.edu

Nancy John (University of Illinois Library) made a rather eloquent description
of the library model, and how the tools of library cataloging and
classification may not be a satisfactory model for cataloging and classifying
Gopherspace.  She did think they may be good starting points.


                 ORGANIZING SUBJECT-MATTER BASED GOPHERS


A quick show of hands found that there were as many librarians in this session
as computing types.

There was consensus that you should let the experts in the field run the
subject-based gopher server.  They know the subject, the users and the
concerns.

Mike Macgirvin, at Stanford described how he was involved in creating Gopher
access to the Info-Mac Archives at Stanford and a medical archive.
He said setting up Gopher access to the Info-Mac stuff was easy.

The medical database was the harder one, because the diversity of interested
parties involved.  They felt that setting up a subject-based gopher is a
iterative process, getting feedback from users on how to get things up and
running.  Let users access the server, meeting again with the users and tuning
the Gopher based upon that feedback.

Nancy John, U. of Illinois gave a review of what people were doing with
subject based Gophers.  Most of the running subject based Gophers that she
reviewed had some structures but had very little data.

She offered some things to remember when starting a subject-based Gopher:
Subject based gophers are subjective to the people who set up the gopher.  You
cannot pick your audience.  What you think is clear in your gopher gets very
unclear after a Veronica Search.  You cannot take a frozen view of
subjectness.  Gopher is so grassroots, that she hopes that it keeps its
freshness.  Current schemes for cataloging and classifying other types of
resources are not appropriate for electronic information.  They can be a
starting point, but just that.

Look to the Gopher at:
riceinfo.rice.edu for the results of the link merger tool that Rice put
together for providing subject access to Internet resources.

While there were no ready solutions to finding all the material on a
particular subject available through Gopher (or elsewhere on the Internet for
that matter), a few ideas were offered, such as posting multi-level bookmark
files that could be collected and be researchers and shared with their
colleagues. Much as Reviews of the Literature essays give up to date
information about the state of research and knowledge in a given area, these
expanded bookmark files might be the first place to look when exploring a
particular subject.

                          COOKING YOUR GOPHER

Notes taken by Kirk Keller ENGKIRKK at MIZZOU1.missouri.edu

For the most part, this session involved a walk-thru of how to set up
a gopher server and client (which is covered in the conference notebooks).

A couple of points concerning the MS-DOS gopher clients and servers:

The PC server does not appear to support indexing or any type of database
interface.

Also, the Minn. group will probably not work on a PC server until windows nt
begins to be used on PCs (i.e., it will be a Windows NT version).

Documentation that comes with the Clarkson tokenring packet driver has
incomplete information on how to set up the config.tel file for use with
NCSA's telbin.exe (which most folks will use in the PC client for telnet
sessions).

The PC server can be set up on a '286 machine with no problem.  We've had
no problem with the operation of our PC server.

Additional Notes taken by Carl Snow

MS-DOS gopher client could be run on a 286, but preferably on a 386
machine.  The client was written at Case Western Reserve University with
the software available from Boombox.  The following files should be down
loaded as binaries:  NOS192.zip, ee.com, ted3.zip.  PKZIP v2.04g should be
used to decompress the zip files.  The text editor ted3 seems to work
best.  Each directory is a Gopher directory.  Each directory has a GINFO
file that describes the files in that directory.  A GINFO file is much
like a .cap file.  The separator in a GINFO file line is a / , not \.  It
is best to dedicate a machine to a PC server -- do not expect to run the
server software in the background.

MAC servers are available from Boombox.  Two programs are available the
original and a program called FTPd.  FTPd is somewhat more powerful in
that it not only runs a Gopher server but can be used as an FTP server.
FTPd can also do binhexing on the fly.  Use Binhex 4 to decode the FTPd
files.  It also does site indexing on the Names of files.

The UNIX server is available at Boombox.  Paul Lindner pointed out that
more, telnet and TN3270 present significant security risks.  Secure
versions of these programs are available at boombox.  He also said that
NextStep 3.0 indexing will not work with Gopher and that users will need
to revert to NexStep 2.2.


            GOPHER SERVER'S ACCESS TO STRUCTURED DATABASES

Notes taken by: Ian Lumb ian at unicaat.yorku.ca

This special breakout session was the result of pre-conference,
electronic discussions which expressed a common interest in connecting
information retrieving and processing software.  Although there have
been efforts aimed at merging specific packages, complete connection is
not a present reality.

This session focussed on efforts to use various flat-file (e.g.  dBase)
and relational (e.g.  Oracle) database backends, as opposed to
filesystems, for gopher servers.  Perhaps the most fundamental concern,
is with regard to the state of the data provided to the gopher server
from the database package.  At one extreme, the data that is made
available to the gopher server is in a completely static or `frozen'
form.  While this has the benefit of allowing for relatively simple
gopher access, it also requires a duplication of information already
present in the database, and compromises the currentness of this
information.  Data that is available to the gopher server in a more
dynamic or `on-line' state from the database, avoids the duplication and
currentness problems, but is more difficult to mate with gopher.  In
practice, most database backends to gopher servers fall somewhere
inbetween these two extremes.

In his presentation, Stan Letovsky (Letovsky Associates) described his
use of Sybase output, which was indexed via wais (wide-area
information service), further organized (via the Unix awk utility),
and made available for a biologically-oriented gopherspace.  Letovsky
also indicated that the wais software, with the addition of
field-specific matches, hypertext links, and joins, might also
database-like functionality.  The notion of unified access via
pointers and searches, across various databases through the use of
gopher, was noted.

Aaron Reizes (Stanford) related experiences with interfacing Stanford's
own spires database package with gopher.  He also indicated that there
is ongoing work aimed at developing a single `gopherbase' that may use
the more advanced features of gopher+, and therefore support
multiple-view capabilities.

Paul Lindner (U.  of Minnesota) described his recent, successful efforts
aimed at using MetalBase (mbase) and gopher.  In his proof-of-concept
study, he illustrated how gopher data `shadowed' from mbase could be
used via gopher to build a query by clicking.  Lindner noted the
importance of maintaining gopher access to flat-file database
information, and alluded to his current efforts aimed involving Oracle.
Lindner's example can be explored via gopher by connecting to York's
main gopher server

        gopher.yorku.ca

and by selecting

        Faculties and Departments
           UNICAAT
              UNICAAT Administration
                 Electronic
                    Database
                       MetalBase <-> Gopher

In an earlier open session on New Gopher Uses and Tools, Edward Moy
(Berkeley) presented a live example of a relational information
processing using a perl script executed from within gopher.  In one
application of Moy's work, upcoming course offerings were processed
with respect to various user-specified parameters (fields).

Gopher+, the big brother/sister of gopher, offers increased
possibilities in this information-processing context.  Under gopher+,
the client application is afforded: a broader range of attributes
(item content descriptors); greater flexibility and usability through
the use of multiple views; greater interactive capabilities through
the use of forms for acquiring information interactively, and for
dynamic filesystem manipulations; and security through the use of an
aunthentication mechanism.  Also relevant in this discussion is
gopher+'s future plan to incorporate: uniform resource names (URNs)
and locators (URLs); a gateway into Z39.50 which is used in library
cataloguing; and user information using the whois++ database.