NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/alt/gopher/1103

Text File | 1992-07-27 | 4.1 KB | 79 lines

Newsgroups: alt.gopher
Path: sparky!uunet!cs.utexas.edu!mercury.unt.edu!sol!billy
From: [e-mail] (Billy Barron - VAX/UNIX Systems Manager)
Subject: Re: index for all of gopherspace
Message-ID: <[e-mail]>
Sender: [e-mail] (UNT USENet Adminstrator)
Organization: University of North Texas
References: <[e-mail]> <[e-mail]>
Distribution: na
Date: Tue, 28 Jul 1992 04:53:06 GMT
Lines: 66

[e-mail] (Peter Deutsch) writes:

>In article <[e-mail]> [e-mail] (Billy
>I think this is an excellent blend of technologies, making use of the
>strengths of each component. If only all our work could blend so smoothly.
>I trust you feel better now? :-)

Yes.

>BTW, the point I was making by calling for a Gopher Index at the top of
>each server was that, like hypertext, I don't hold out much hope that
>the "single sea of information" model of a single Gopherspace can possibly
>scale to include millions of machines and hundreds of millions of users
>(which is where we are undoubtably heading). I like the idea of
>"communities", and coming "into" a community for services, info etc. As
>part of this, I see "information servers" (such as archie) being
>a part of this.

The "single sea of information" model is what libraries can provide today.
I am convinced it can be done with computers as well.  There are two roads
to head down (I think both oughta be attempted and see what happens) IMHO.
The first is to try to get information providers to specialize in various
areas.  Let's say I take on the task of maintaining Sports Journals and then
divide up the GopherSpace into little chucks.  Each person is the SOURCE
for a particular piece of information instead of the mass chaos we have today.

The other road is to use "information servers" as a catalog to somewhat
front-end things.  While this helps the situation quite a bit, it is still
a kludge approach unless the client software can deal with the searches
of the "information servers" and transparently pass the user onto the
appropiate Gopher link(s).  This will require quite a bit of rewriting of
code and possibly protocol changes.

>I guess it comes down to what my information model is that I want to
>present to the user. I thought it would be okay to offer up the
>occasional "informational gas station" to users, rather than ask them to
>remember where everything resides themselves. Users can simply pull in, ask a
>few quick questions and be on their way. The suggestion to add one to the top
>of each Gopher tree was merely standardizing to allow users to become
>comfortable about where the will find the gas stations when entering a strange
>town (or do you object to _all_ gateway services?)

This model suffers from the problem of "which" gas station they need to go
to for which pieces of information (unless, of course, all gas stations have
the same information).  The problem is that your knowledgable users can handle
the "gas station" approach just fine.  The goal of Gopher here at UNT (and if
you talk to most librarians, the goal of a virtual library) is to let the user
find the information with as few gas stations as possible.

The gas stations are needed, but they should not be seen as an alternative
to organizing things as well as possible to start with.  I agree that no matter
how well things are organized some people will get lost and need that gas
station.  The gas station is not the solution.  It is an aid for those times
when the solution does not work.

By the way, I misunderstood your last letter somewhat.  I was thinking you
were advocating links to the top of the other Gophers as opposed to linking
directly to the revelant areas (that was why I was puking so bad).  Yes, the
gas stations do belong at the top unless things turn out like Mike Schwartz
thinks where there are multiple gas stations and then we have a directory
of gas stations.

By the way, I wouldn't mind standardizing on the term "gas station" for this.
It's the first one I've heard that makes sense.  :-)