Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site k.cs.cmu.edu.ARPA Path: utzoo!linus!decvax!ucbvax!ucdavis!lll-crg!seismo!rochester!pt.cs.cmu.edu!k.cs.cmu.edu!tim From: tim@k.cs.cmu.edu.ARPA (Tim Maroney) Newsgroups: net.news Subject: Re: Information Overload and What We Can Do About It Message-ID: <589@k.cs.cmu.edu.ARPA> Date: Mon, 7-Oct-85 14:39:40 EDT Article-I.D.: k.589 Posted: Mon Oct 7 14:39:40 1985 Date-Received: Fri, 11-Oct-85 06:35:12 EDT References: <10551@ucbvax.ARPA> Organization: Carnegie-Mellon University, Networking Lines: 56 The idea of some means for "reviewing" messages and using others' "reviews" as a filter will be in the bulletin board system for VICE. However, since it will be on VICE, there will be only one copy of the articles for the whole campus, so it doesn't take broadcasting issues into account. For a situation like USENET's, the best solution is to designate "reviewers" for each newsgroup. A finite set of reviewers would exist for each newsgroup. Each would rank (either by a Boolean worth reading/not worth reading scale, or from one to ten) each message, although since this would be a volunteer activity, everyone would not be expected to rank each message. Users would set up combinations of reviewers in a file to be used together with the current .newsrc file. For instance, you could specify, "I want to read everything which Andy and Betty thought was interesting in net.pets.fishheads, but which Chuck disliked". The reviews would be propagated by a new sort of control message. Each machine would keep a database of articles and reviews. This could be done easily in dbm, although some machines would have to fall back on a two-field text file (in classic slow UN*X style). Another database would keep track of reviewers. Reviewers would be selected by the informal method currently used to select moderators. Additional control messages could be used to maintain the database of reviewers. There would be little security due to the ease of putting a message with a false sender address onto USENET (and the insecurity of requiring a password to be sent around), but I doubt this would be a serious problem. Overall, you'd need these pieces of code: (1) store/retrieve operations for article-review database (2) store/retrieve operations for reviewer database (3) code to receive and handle new control messages (4) a user interface for reviewers (extension of readnews or rn) (5) a program to help users set up their preferences (possibly within readnews or rn) (6) code within readnews and rn to determine whether any article fits the user's review criteria (7) code to remove the reviewer information of an article when it's cancelled or it expires This effort could be split up among several people if we can arrive at a more specific set of specs for each part. I'd be willing to write a few parts myself. The idea could also be elaborated on to assuage the problem of storing the news. For instance, a majority of reviewers giving thumbs down on a message could be equivalent to a cancellation, or "expire" could run every day and eliminate all articles N days old or older which have M/(number of revewers for its groups) or fewer thumbs up ratings, as well as deleting anything more than a certain age. -=- Tim Maroney, CMU Center for Art and Technology ARPA: Tim.Maroney@CMU-CS-K uucp: seismo!cmu-cs-k!tim CompuServe: 74176,1360 audio: shout "Hey, Tim!"