home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / alt / gopher / 1110 < prev    next >
Encoding:
Text File  |  1992-07-28  |  4.5 KB  |  92 lines
  1. Newsgroups: alt.gopher
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!mips!sdd.hp.com!caen!destroyer!ubc-cs!utcsri!torn!csd.unb.ca!morgan.ucs.mun.ca!nstn.ns.ca!daniel
  3. From: daniel@nstn.ns.ca (Daniel MacKay)
  4. Subject: Re: index for all of gopherspace
  5. Message-ID: <1992Jul28.194722.19492@nstn.ns.ca>
  6. Organization: NSTN Network Operations Centre, Nova Scotia, Canada
  7. References: <1992Jul27.163746.974@nstn.ns.ca> <1992Jul27.180509.27470@mercury.unt.edu> <1992Jul27.201122.17017@msuinfo.cl.msu.edu>
  8. Date: Tue, 28 Jul 1992 19:47:22 GMT
  9. Lines: 81
  10.  
  11. Hello!
  12.  
  13. Billy Barron writes: 
  14. > This could be done.  Actually, I don't really care to make this a "user"
  15. > feature.  It would involve some major coding and maybe a protocol change.
  16. > Just something us sysadmins use to figure out where we would like to place
  17. > links to.
  18.  
  19. I certainly _was_ thinking of it as a user feature, and no, in my
  20. gedanken-design, it ran on existing gopher-ware.  The components:
  21.  - a wordy description of the resource for which your gopher is 
  22.    the authority, emailed to an administrator (hang on for an update 
  23.    of this idea), complete with a .link file to the resource.
  24.  - those descriptions dropped into a directory on the master Index server
  25.    and indexed.
  26.  - A search item on all gophers, that sent a query to the master server.
  27.    The master server would return pointers to the descriptions of the
  28.    resources, which you could browse.  (with a descriptor that possibly
  29.    gave you "headline" info about the resource, or its physical/net
  30.    location, if you care about such a thin).  When you had find the one 
  31.    you want, you point-and-shoot at the accompanying resource menu item 
  32.    itself.
  33.  
  34. Peter Deutsche writes:
  35. > While talking about indexing Gopherspace, the next release of archie 
  36. > will allow gathering of arbitrary collections of information and ...
  37. > [...]
  38. > and we plan to put
  39. > in pointers to the various Gopher servers as a proof of concept.
  40.  
  41. I was describing my idea to a visitor to my office, and he suggested
  42. exactly the same thing- there be a file with a well-known-name available on
  43. every gopher that is authoritative for some resource.  This file would have
  44. a wordy and search-rich description of the resources, i.e. an abstract for
  45. the resource written in a way that it will be full of keywords that people
  46. are likely to use when they're looking for it.  The one for the recipies
  47. database would have words like "recipies" "food" "cooking" (but would it
  48. contain an entry for "dessert" "entree"?  Hmm.)
  49.  
  50. Peter's, or someone's, robot could sweep through the gopher servers
  51. periodically, collect the files, and build the Index Into Gopherspace.
  52.  
  53. My point: there are not *that* many things in gopherspace once you take
  54. out all the redundancy.  If we only collect descriptions from people who
  55. are authoritative for their resource, the problem dwindles into something
  56. quite doable- think of how much smaller Peter's archie database would be if
  57. there was only one entry in it for every ftp'able resource!
  58.  
  59. Anyway, it results in an entity that's like a couple of things:
  60.  a) Peter's "whatis" project.
  61.  b) My gopherizing of the SRI NISC List-of-Lists, available on the
  62.     nstn.ns.ca gopher; check it out as 
  63.     Internet Resources
  64.        Mail Lists
  65.           Mail List Subject Search
  66.  
  67. The important thing is that the *name* of something usually doesn't tell
  68. you much about it.  So a robot indexing all the words of the menu items it
  69. finds in gopherspace is relatively useless.  Someone carefully writing a
  70. description of their resource, keeping in mind the kind of keywords a user
  71. might use when looking for it, is *much* better.  Yeah, writing it is work.
  72. But- garbage in, garbage out.  If you're authoritative for a resource,
  73. presumably you should be able to take the time to describe the resource
  74. once.
  75.  
  76. Peter continues:
  77. > Now, the missing link here seems to be a simple way to get the index
  78. > info out of Gopher.
  79. I don't think that's much of a problem.  *The* thing that gopher's best at
  80. is delivering documents.  And I think it's quite reasonable to have a
  81. Well-Known-Directory containing descriptions of the data for which that
  82. gopher is authoritative, (e.g. me and CA*Net news, Canadian Weather).
  83.  
  84. On a related topic- Peter, does that mean that the archie data and the
  85. whatis data will be integrated?  I had a complaint from a user the other
  86. day that my gopher/archie gateway didn't deliver whatis data, and I
  87. thought- right!  Why doesn't it?
  88. --
  89.     Daniel MacKay                daniel@nstn.ns.ca
  90.     NOC Manager, NSTN Operations Centre    902-494-NSTN
  91.     Dalhousie University, Halifax, Nova Scotia, Canada
  92.