Surprise: it's been done. But it hasn't been widely publicized yet
for a couple of reasons, one of which is that the guy doing it is
still working on it, since it's his PhD project.
It's called "Infoscope", it's written in Lisp and runs on Symbolics boxes.
There's a paper on it in "Human Factors in Computing Systems", Chicago 91
Conference Proceedings, which is published by the ACM. Look for
"Information Access in Complex, Poorly Structured Information Spaces"
by Gerhard Fischer and Curt Stevens. (Stevens in the grad student;
he's at CU-Boulder, in the CS dept...which is the same department that
developed the "netfind" service some of you may be aware of.)
Anyway, here's the oversimplified summary: Infoscope implements
virtual newsgroups that are custom-constructed for each user. Users see
threaded conversations (a la trn) even if the threads wander
around between different newsgroups. The real interesting part
are the "agents", which "watch over the user's shoulder" and accumulate
knowledge about the user's preferences. These agents can then
take actions such as prioritizing articles, suggesting threads to
read, or filtering articles/threads. Infoscope has a nifty GUI
and facilities for coping with conversations that move between
mail and news.
Of course, this is an AI project, it runs on a custom architecture,
it's written in Lisp, and so on. But it sure has some interesting
ideas...and it works.
Let's see...there's also the NewsClip stuff done by Templeton, Tyhurst
and I think Raymond; there's Rich Salz's query-reader parser (thanks
for sending that to me, Rich!); there's the ongoing development of
strn, a scoring-threaded-rn; and then there's whatever else I'm
not aware of. It sure seems as if a lot of us are thinking along
similar lines, when it comes to coping with information glut.
Heck, I banged out my own ideas and sent them off the Clifford
Adams (the fellow working on strn) a few weeks ago. I'm enclosing
a copy below--in a "p.s.", because I don't think this is really
relevant to this list; replies should probably be directed to
me rather than to usenet.hist.
---Rsk
p.s.
Thoughts on news filtering/threading, 11/27/92
Posit 1: There are lots of good reasons to include thread-following,
article-killing, and article-finding features in a newsreader.
But (Posit 2): The addition of these features bloats the size of
the newsreader and such features may wind up being implemented
differently in different newsreades (tin, (s)(t)rn, etc.)
And (Posit 3): It's unclear what features we need, but it's probably
true that we don't need every feature that everyone ever thought of.
A careful selection of a limited, orthogonal set of features might
just do the job at a considerable reduction in complexity. (Reduced,
say, from the C-like language of NewsClip, which is somewhat intimidating.)
So here's where this leads me. Maybe we should adapt the NewsClip
idea to build an engine that works like this:
__________ _____________ _________________
| News | | Filtering | | Newsreader or |
| Server | <--- NNTP ---> | Agent | <--- NNFP ---> | Remote Site |
|________| |___________| |_______________|
Where "NNFP" is, say, "Network News Filter Protocol".
The idea is that the newsreader doesn't have to know how to do filtering.
All it needs to know how to do is to tell the filtering agent what kind
of filtering it wants done; it's the responsibility of the filtering agent
to do it. Sure, the newsreader has to have some filter-related features:
it's got to allow the user to specify their filtering criteria actively
("Here, dink this thread") or passively ("Hmmm, the user has killed the
last 40 articles in this thread, I should probably consider killing the
next 10 as well"). NNFP would essentially be a superset of NNTP:
it would allow the newsreader to shove filtering criteria at the
filtering agent, and would allow the filtering agent to present articles
to the newsreader in compliance with the criteria.
I guess I see news-reading as a separate activity from news-filtering.
I also think that while killfiles, scorefiles, and newsclip programs
all have some interesting ideas, that the complexity is beginning
to grow disproprotionately to the functionality.
To put it another way: In A More Perfect World, the user would never
have to deal with the syntax and semantics of killfiles, scorefiles,
et.al; they would simply tell the newsreader, "here, go do this",
and the newsreader would have to worry about (a) telling the filtering
agent how to do this via NNFP and (b) saving the info for the next
time in whatever format it happens to use.
[ This is bordering on DWIM, I know. Perhaps I would be more accurate
if I said "the interface presented to users should be *very* simple.". ]
Of course, this has its downside as well: it requires designing NNFP.
It may require users to run two processes instead of one to read news.
It requires two programs that save state, instead of one. But on the
plus side, *anything* that speaks NNFP can be used to read news (or to
create a filtered newsfeed). No newsreader will have to implement its
own threading/filtering features; it'll just have to know how to tell
someone else to do the work. *If* NNFP is well-designed and if the
filtering agent is well-built, this would allow us to rip lots of
code out of (s)(t)rn, rather than adding to it. (These newsreaders
already have code which allows readers to specify actions; they also
have code which implements the actions. The latter could be ripped out.)
[ Well, the filtering process could run on the server, just as the
server side of an NNTP connection does now. Also, the newsreader
could take care of saving the newsfilter's state -- and probably should. ]
Clearly, this is an idea in its infancy. It could be really bogus.
But it seems to me that if one thinks the ideas of news-reading and
news-filtering are separable, then this is one way to go.
---Rsk
This page last updated on: Jul 1 09:16