"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 1993 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
April, 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 applications. 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! Karen
- "checklist" for NIR Report April Marine
- "checklist" for NIR Report April Marine
- "checklist" for NIR Report Karen R. Sollins
- Re: "checklist" for NIR Report April Marine
- Re: "checklist" for NIR Report April Marine
- Re: "checklist" for NIR Report Ton Verschuren
- Re: "checklist" for NIR Report George Munroe
- Re: "checklist" for NIR Report George Munroe