"checklist" for NIR Report

"Karen R. Sollins" <sollins@lcs.mit.edu> Tue, 12 October 1993 00:46 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29813; 11 Oct 93 20:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29809; 11 Oct 93 20:46 EDT
Received: from sun2.nsfnet-relay.ac.uk by CNRI.Reston.VA.US id aa11880; 11 Oct 93 20:46 EDT
Via: uk.ac.mailbase; Tue, 12 Oct 1993 01:45:04 +0100
X-Version: Mailbase (TM) Enhanced List Manager Version 2.3
Received: from [+JANET.000040010500/FTP.MAIL] by uk.ac.mailbase; Tue, 12 Oct 1993 01:34:44 +0100
Received: from ZIPPY.LCS.MIT.EDU by sun3.nsfnet-relay.ac.uk with Internet SMTP id <sg.20013-0@sun3.nsfnet-relay.ac.uk>; Tue, 12 Oct 1993 01:34:23 +0100
Received: by zippy.lcs.mit.edu id AA13206; Mon, 11 Oct 93 20:42:10 -0400
Date: Mon, 11 Oct 93 20:42:10 -0400
Message-Id: <9310120042.AA13206@zippy.lcs.mit.edu>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Karen R. Sollins" <sollins@lcs.mit.edu>
Original-Sender: sollins@zippy.lcs.mit.edu
To: amarine@atlas.arc.nasa.gov
Cc: nir@mailbase.ac.uk, amarine@atlas.arc.nasa.gov
In-Reply-To: April Marine's message of Sun, 10 Oct 1993 14:37:39 -0700 <9310101743.aa27864@MINTAKA.LCS.MIT.EDU>
Subject: "checklist" for NIR Report
Original-Sender: sollins@zippy.lcs.mit.edu
X-List: nir@uk.ac.mailbase
Reply-To: "Karen R. Sollins" <sollins@lcs.mit.edu>
X-Orig-Sender: nir-request@mailbase.ac.uk
Precedence: list

I have found such categorizations incredibly useful.  In fact the
board in my office was covered with a sacrosanct one for many months.
I was a little confused about your meaning for some of those rows.  I
have a few questions and issues that I found important in addition,
perhaps to what you've included.

First, did any of the labels include the issue of whether the service
in question required importation of information in order to be
accessible?  The question is whether, for example, a particular
service sits on top of an existing set of NFS's and AFS's, accessing
information by going through the requisite file system, or whether the
files or other objects must be imported into the service in order to
be accessible through it.

There is another issue that I think is important in information
retrieval systems.  Some systems are designed specifically as single
user applications.  There may be several interfaces to them, such as a
window-based on or a dumb-terminal interface, or perhaps Xmosaic.  But
there is one set of functions that the system is designed to support
for users, so the applications are extremely limited.  Other systems
are designed to be infrastructure on top of which a variety of
applications might be built.  Of course, there will be vanilla
applications that provide somewhat direct browsing, but these systems
were designed with the idea in mind that they were multi-purpose,
perhaps browsing, editing, usable by other services to provide
enhanced (and perhaps at present unforseeable) services and

A third part of the table that I find a little confusing is the
section on platforms.  Especially in the case of clients there seems
to be a confusion between platforms and protocols.  It is definitely
important to understand which protocols each of these services runs on
top of, and perhaps that should be broken out of the other categories.
It may be that one needs an "other" for this, that simply is text
rather than X's.

All in all, I think this a great idea!