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

Text File | 1992-07-27 | 5.9 KB | 107 lines

Newsgroups: alt.gopher
Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!ux1.cso.uiuc.edu!news.cso.uiuc.edu!uxa.cso.uiuc.edu!bau50671
From: [e-mail] (Brygg Ullmer)
Subject: Re: index for all of gopherspace
References: <[e-mail]> <[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>
Originator: [e-mail]
Sender: [e-mail] (Net Noise owner)
Reply-To: [e-mail]
Organization: University of Illinois at Urbana
Date: Tue, 28 Jul 1992 05:36:26 GMT
Lines: 93

[e-mail] (Billy Barron) writes:

> [e-mail] (Daniel MacKay) writes:
>
> >Now, the WAIS thang works because all the people who run WAISs, have sent
> >in to the mother of all WAISs, an abstract for each database they've
> >published.
> >
> Not all.  I've found quite a few WAISs that are NOT in the master directory.
> This also is the biggest problem with WAIS.  The directory is flat and getting
> too big.                                     ---------------------------------
  -------

I agree... which is why the hierarchal structure of Gopher is so powerful.
While I certainly see a place for WAIS-searches of Gopher menu-entries
(note this has already been done at the site-level -- check out Paul Gibb's
server at UIUC, gopher.cso.uiuc.edu), it seems logical to me that one should
exploit the native structural assets of Gopher in conjunction with Gopher's
inter-system linking for a more immediately powerful combination.  This also
gives you the added bonus of seamlessly integrating data you have much less
control over... FTP-site archives, for instance.  The big problem I see is
the coordination of any such "master hierarchies" between sites. 'Tis simple
when you have an obvious central location that can develop a readily-agreed
upon list for universal distributed access, such as UMN's master Gopher server
list... but the case is very different with most distributed-data, distributed
data indexing as occurs in Gopherspace.

Perhaps we could work together to develop something of a downscaled,
extensible counterpart to the Dewey Decimal system of the library world...
this might give very fixed, meaningful locations for the data we enter, and
allow sites to much more effectively share their indexing and data-gathering
efforts.  Another very nice feature might be the automagic incorporation of
data source redundancy.  If you link to one system for your recipe data, and
this site goes down, it would be nice to cultivate a situation where sites
with similar data might automagically fill in.

I've been working heavily on my own server at bigcheese.math.scarolina.edu
which is distributed through and through.  I'm basically adding data from
scratch on only a single topic of very restricted interest, but have
spent a great deal of time shooting links off every which direction, both
to other points in Gopherspace and to large FTP-site collections which I've
tried to partially order.  (I hadn't planned to mention the server for another
week so I'd have the chance to add another hundred entries or so, but hey....)
As a result, I think bigcheese offers a nice (rapidly growing) general spread of
information for the computer literate as well as relatively computer illiterate
user spanning gigabytes of data access with less than five megs of local data.
As far as application of the distributed access... a nine year old using Gopher
for the first time was able to find the recipe for Garlic Scampi unassisted
in less than five minutes, somewhere between the hundreds of options spanning
Internet RFC's, Human Genome Project indices, and Wavelet papers.

However, there's no way a single individual or location is going to put
together a data collection that is all things to all people, this is clear...
while links rather than data replications allow data to stay relatively
up-to-date, the proliferation of larger hierarchies at individual sites
(like bigcheese) will make it very difficult for scavengers to find new
information, unless there is a more efficient mechanism for sites to
collaborate with large-scale data indexing.

> : This could be done.  Actually, I don't really care to make this a "user"
> : feature.  It would involve some major coding and maybe a protocol change.
> : Just something us sysadmins use to figure out where we would like to place
> : links to.
>
> I think making it only a gopher administrator's resource sort of
> defeats the purpose.

I fully agree.

> I think it would be a very useful thing indeed if Joe Random
> Entomologist had some way to go out and find some bug databases without
> requiring me to explicitly support a link to them (bugs give me the
> willies).  Sort of an archie server for gopher/wais/www resources is
> what I have in mind (possibly with hooks to automagically "go there" in
> various clients or servers).

I think a few minor extensions to the Bookmarks capability of Gopher 1.0x
would help in this direction.  I'd like to see the .gopherrc handle directories
in bookmark-land as well as user-specified local and FTP'able data.  This way,
we can offer sample configurations of data oriented towards different
users... a linkage of data a kindergartner might use, collections
appropriate for high school students, undergrads, Entymologists, businessmen
and housewives, all fully user configurable and extensible.  As I think
you'll see, the physical implementation of this is trivial and practically
completed with the 1.01 release with the possible exception of an efficient
user interface for data additions.  Gopher already allows the user to
name data as he wishes, link data seemlessly wherever this data may be.
Especially with the development of documents like the Child's Garden of the
Internet, which gently provide new users with the know-how to approach the
net, it seems there's a real calling for this sort of configurable, seamless
access, a role Gopher is well on the way towards filling...

Brygg Ullmer ([e-mail])