Organizing gophers
David Green <david@rsbs13.anu.edu.au> Fri, 09 July 1993 07:33 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00614; 9 Jul 93 3:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00610; 9 Jul 93 3:33 EDT
Received: from sun2.nsfnet-relay.ac.uk by CNRI.Reston.VA.US id aa01898; 9 Jul 93 3:33 EDT
Via: uk.ac.mailbase; Fri, 9 Jul 1993 08:33:21 +0100
Received: from [+JANET.000040010500/FTP.MAIL] by uk.ac.mailbase; Fri, 9 Jul 1993 08:29:25 +0100
Received: from anu.anu.edu.au by sun3.nsfnet-relay.ac.uk with Internet SMTP id <sg.09214-0@sun3.nsfnet-relay.ac.uk>; Fri, 9 Jul 1993 08:28:59 +0100
Received: from rsbs13.anu.edu.au by anu.anu.edu.au (4.1/SMI-4.1) id AA05476; Fri, 9 Jul 93 17:28:51 EST
Received: from life.anu.edu.au by rsbs13.anu.edu.au (4.1/SMI-4.1) id AA10924; Fri, 9 Jul 93 17:27:31 EST
Date: Fri, 09 Jul 1993 17:27:31 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: David Green <david@rsbs13.anu.edu.au>
Message-Id: <9307090727.AA10924@rsbs13.anu.edu.au>
To: nir@mailbase.ac.uk
Subject: Organizing gophers
Cc: david@life
Original-Sender: david@rsbs13.anu.edu.au
Reply-To: David Green <david@rsbs13.anu.edu.au>
X-Orig-Sender: nir-request@mailbase.ac.uk
I wrote the following comments in response to a query on another list. However I thought that subscribers to NIR may also find this of some interest, as it reflects some of my experiences in the "front lines" of network information. It's unfortunate that discussions of network information tend to focus almost exclusively on hardware and software. The issues involved in actually organizing the information are just as great, and are rapdily becoming more critical as the user base of Gopher, WWW etc expands. Cheers .. David Green -------------------------------------------- Dora writes ... > I think it would be interesting to begin a discussion on how > to organize this mass of information using a gopher network ... A number of us who run gopher services have been thinking about this problem for a long time now. While the number of servers, and the amount of information, is relatively small the problem is not too bad. Most managers have adopted much the same approach as I have, namely create a list of "other sites", so that people can explore for themselves. However this approach soon bogs down because most sites provide information on a variety of topics, so it can take users a long time to sift the "wheat from the chaff". The following are the steps that I have taken in order to help users: 1. I've tried to place the infromation that users really want as close as possible to the top level menu. Hence I provide a series of thematic menu options on subjects that I try to support, e.g. biodiversity, landscape ecology, molecular biology, ... 2. I've tried to build some redundancy into the system by providing alternative paths to the same information. e.g. the path ~/biodiversity/other_sites leads to the same information as ~/other_sites/biodiversity. 3. Instead of just providing pointers to "other sites", I also try to "pick the eyes" out of each site by providing direct pointers to useful information at those sites. An extreme case of this is my medical folder - I maintain almost no relevant data locally at all (except virus taxa database), but have collated a series of pointers to major databases. This may sound parasitic to some of you, but it serves some very basic, but important functions: (a) information is maintained at its source; (b) collating live pointers to services, not just sites, is an EXTREMELY helpful indexing service for users. (c) it helps draw attention to sites that may be overlooked otherwise - users tend to go back to the "big" sites again and again. (d) There's mountains of material out there. No single site can hold everything, as many are now discovering. In my view is that there is at present far too little of this sort of sifting network information. Obviously the sifting requires a lot of effort by the system manager. However users should realize that an important contribution they can make is to compile "live" lists of links around specialist themes. All you have to do is compile a host of bookmarks. There are lots of newsgroup FAQs about, but very few of us seem to be compiling this sort of information into live links. Many would see that this sort of activity is irrelevant, given the power of Veronica searches, but as with "other sites", veronica searches take a long time to sift through. I would be very happy to hear from users who have compiled live links information and would be happy to create some specialist folders out of such material. The main difficulties with this approach are that servers often reorganize, or delete material without notice, so links sometimes become dead without warning. Also, as network traffic increases the need to "mirror" rather than merely provide pointers becomes more important. For example, I pull down weather images for various parts of the world each day, so that (Australian) users won't be continually transferring satellite images across the Pacific. Here automation is the key - a few cron scripts go a long way! 4. The next stage beyond (3) is to develop coordinating projects for specialist themes. My idea is that sites willing to provide support for a particular topic become "nodes" in a thematic information network. Here "support" means (a) maintain on-line information; (b) accept contributions from users; (c) coordinate with other nodes. My first experiment with this approach is "FireNet", which we hope will grow into a world-wide information network for everyone interested in landscape fires. I am currently developing material for other such themes, including palynology, viruses, and complex systems. The principle is that the information stored at all nodes in a thematic network becomes a truly distributed information system. Each node would provide pointers, or mirrors, for information on other nodes. Moreover the directory/menu structure should be consistent across all nodes in the system. Other sites can, of course, provide access to the system simply by pointing at one of the nodes. 5. The above issues become even more critical as we move beyond gopher to hypermedia information stored under World Wide Web. Here I have adopted the principle of providing "home pages" for each topic that I support. Thus I have home pages for biodiversity, FireNet, pollen, weather and global change, Landscapes, etc to parallel the gopher menus. These include gopher links, of course, but also pointers to other hypertext documents. Again the key is to provide lots of thematic trails through all the documents you provide. Finally, I should say that I see myself very much in the role of network publisher. Indeed I am now literally obtaining ISBN and ISSN codes for some of the material that I place on the system. It's important that the user community come to recognize this and act accordingly. i.e. instead of being passive users, they should look at what they can contribute. Those of us who are trying to maintain systems cannot do the job on our own - it's intensely annoying to receive complaints of the kind "your info. is out of date" or "why aren't you providing ...". As the scale of the system becomes some user's need to play a far bigger role than they have to date. I hope that your readers will find the above comments of interest. I attach below contact details for my Bioinformatics information service for anyone interested. Cheers ... David Green ___________________________________________________________ name Dr David G. Green address Research School of Biological Sciences & Centre for Information Science Research Australian National University GPO Box 475 Canberra 2601 AUSTRALIA email David.Green@anu.edu.au phone 61-6-249-2490(or 5031) fax 61-6-249-4437 ___________________________________________________________ Access to to ANU Bioinformatics .... FTP : life.anu.edu.au Gopher : Name=ANU Bioinformatics Host=life.anu.edu.au Port=70 Path= Type=1 World Wide Web http://life.anu/edu/au:80/
- Organizing gophers David Green