human-nets@ucbvax.ARPA (03/03/85)
From: Charles McGrew (The Moderator) <Human-Nets-Request@Rutgers>
HUMAN-NETS Digest Sunday, 3 Mar 1985 Volume 8 : Issue 9
Today's Topics:
Responses to Queries - Network Directories &
Information on Xerox NoteCards,
Computer Networks - Stargate (2 msgs),
Computers and People - Re: Interesting Net Anecdotes,
Information - Message Systems Symposium Announcement
----------------------------------------------------------------------
Date: 24 February 85 13:23 EST
From: RMXJITRY%CORNELLA.BITNET@Berkeley
Subject: Re: Request for informatio
Originally sent from: RMXJITRY@CORNELLA
Originally sent to: VINCE.FULLER@CMU-CS-C.ARPA
Hi,
Have you tried asking NIC @ SRI-NIC.ARPA They maintain the ARPAnet
Network Information Desk - so they should have what you are looking
for.
-- Gligor Tashkovich
RMXJITRY%CORNELLA.BITNET@WISCVM.ARPA
------------------------------
Date: 1 Mar 85 17:41 PST
From: Halasz.pa@XEROX.ARPA
Subject: Information on Xerox NoteCards
To: Info-Mac@SUMEX-AIM.ARPA, AIList@SRI-AI.ARPA
This description of the Xerox NoteCards system is a response to
inquiries that have recently appeared on several Arpanet discussion
lists.
A. Background: NoteCards is part of an ongoing research project in
the Intelligent Systems Lab at Xerox PARC investigating "idea
processing" tasks, such as interpreting textual information,
structuring ideas, formulating arguments, and authoring complex
documents. The NoteCards system provides an on-line environment for
carrying out this research. The principal reasearchers involved in
this project are Frank Halasz, Tom Moran, and Randy Trigg.
NoteCards is implemented in Interlisp-D and runs on the Xerox 1108
family of Lisp processors.
B. The System: NoteCards is intended primarily as an idea structuring
tool, but it can also be used as a fairly general database system for
loosely structured information. The basic object in NoteCards is an
electronic note card containing an idea-sized unit of text, graphics,
images, or whatever. Different kinds of note cards are defined in an
inheritance hierarchy of note card types (e.g., text cards, sketch
cards, query cards, etc.). On the screen, multiple cards can be
simultaneously displayed, each one in a separate window having an
underlying editor appropriate to the card type.
Individual note cards can be connected to other note cards by
arbitrarily typed links, forming networks of related cards. At
present, link types are simply labels attached to each link. It is up
to each user to utilize the link types to organize the note card
network. Within a note card, a link is represented by a small, active
icon. Clicking with the mouse in the icon, retrieves the target card
and displays it on the screen.
NoteCards includes a filing mechanism built around a special type of
card called a FileBox. In each FileBox are filed (i.e., linked by a
Filing link) zero or more note cards as well as zero or more other
FileBoxes. FileBoxes serve as a kind of categorization hierarchy for
filing note cards by "topics".
Browser cards contain node-link diagrams (i.e., maps) of arbitrary
pieces of the note card network. Each node in a Browser's node-link
diagram is an active icon that can be used to retrieve the indicated
card. Spatially organized information is also available in the form
of Sketch cards that allow the user to lay out line drawings, text,
and link icons in an arbitrary, zoomable 2-D space.
NoteCards is an environment that integrates several packages already
available in the Interlisp-D system, e.g., TEdit, Grapher, and Sketch.
NoteCards has a full programmer's interface. All of the functionality
in NoteCards is accessible through a set of well-documented Lisp
functions, allowing the user to create new types of note cards,
develop programs that monitor or process the note card network, and/or
integrate new Interlisp packages into the NoteCards environment.
C. Research directions: NoteCards was designed primarily as a
research vehicle. The following are some of the research topics that
we are pursuing using the NoteCards system.
1) User tailorability -- a system description language that a
non-programming user could edit in order to tailor the system to his
or her task and/or interaction style.
2) Argumentation -- use of a "truth-maintenance" mechanism to help
users develop and manipulate alternative argument structures.
3) Psychological issues -- investigations of the ways in which
NoteCards does or does not support real-world tasks.
4) Visual summaries of large networks -- investigations of other ways
to display network maps, including fish-eye graphs, trimmed graphs, 3D
graphs, indented outline, etc.
5) Multi-window management -- investigations of various abstractions
for building general multi-window management tools that take advantage
of inter-card dependencies.
6) Querying networks of cards -- design of a querying interfaces that
allow users to ask questions about the contents and structure of a
network.
7) Multiple user, interlinked NoteFiles -- providing
distributed/shared NoteFiles with links between different NoteFiles.
8) Alternative documents -- explore alternative document concepts,
such as guided tours (i.e., suggested paths through a network of
cards).
9) Text retrieval -- investigate several methods for doing text
retrieval based on full-text search and statistical matching.
10) Object-oriented implementation -- we are investigating the
possibility of rewriting NoteCards in Loops.
D. How to get more info:
A technical paper on Notecards is in progress. For information about
the research issues surrounding NoteCards contact Halasz.pa@Xerox or
Trigg.pa@Xerox.
NoteCards is not at this time a Xerox product. However, Xerox Special
Information System's Vista Laboratories offers a limited licensing
agreement aimed at distributing NoteCards to groups doing related
research (Contact: NoteCardsInfo.pasa@Xerox)
------------------------------
Date: Thu, 21-Feb-85 14:57:19 PST
From: Lauren Weinstein <vortex!lauren@rand-unix>
Subject: more on Stargate
I said I wasn't going to discuss this here, so I'll just say
the following. ALL of the points that people are bringing up
have already been hashed out in excruciating detail over on Usenet.
The issues involving moderation revolve around a number of very
complex topics, including (but not limited to):
1) Resource allocation -- The bandwidth of the satellite channel
is limited. There wouldn't be the room to send all the
stuff from the growing Usenet for long even if it were
completely legal or we wanted to.
2) Info and Costs -- The quality of material on Usenet has been
going downhill rapidly as more and more people have joined
in. Short, meaningless messages, long repetitious messages
that include the full text of other long messages only
to add a one line "I agree" at the end, personal attacks,
possibly libelous or copyrighted materials, etc.
More and more people have been dropping more and more newsgroups
since they don't have the time to wade through all the muck
to find an occasional gem. People would have to pay something
for Stargate (as they pay for Usenet phone calls now). Many major
sites are fed up with paying many, many thousands of dollars
for junk and would appreciate the option of instead subscribing
to something with a bit higher quality. Those of you who only
know how things work on ARPANET don't know how bad things can
get in a gigantic, almost totally unmoderated forum like Usenet
which is undergoing uncontrolled and explosive growth--and where
virtually every message that every user posts to netnews goes
to ALL sites.
3) Liability issues are not clear. The telco model is not
appropriate -- broadcasting models appear closer to the mark.
Given that there is no way with the current Usenet to authenticate
the author of a message, the responsibility goes back to the
entity making the postings possible. Lawyers who have looked
into these issues have noted that while there are a number
of possibilities, it is unclear how things might finally turn out.
In the meantime, nobody associated with the project has the money
to get into court battles that would almost certainly be
appealed by the losers to higher and higher courts--so that
sorta lets out trying to get definitive rulings regarding
communications responsibility from this project. Court battles
in that area will wage on for years. Let some entity with
lots of bucks and lawyers fight that out. While they're at
it, they can fight out peripheral issues such as whether or
not public key cryptosystems represent legal user authentication
in all cases.
In the meantime, my own opinion is that Stargate should be
run something like a publishing operation. Just as any newspaper,
magazine, or newsletter takes responsibility (and takes suitable
precautions) for what they print, this might be the model for
an operational "service" (right now we have a "simple" experiment,
not a service). It is the price that is paid to publish meaningful
and useful information instead of an endless stream of random
and repetitious writings, from anyone and everyone who wants
to see their name in print in front of lots of people. Even the
ARPANET digest moderators are taking on some responsibility. Of
course, these nets have pretty low visibility right now, but
something like a Stargate Service would have much higher visibility
and thus be a much more likely target for people disturbed over the
content of transmitted materials, regardless of the actual
legal liability issues.
All of the factors above are important and must be considered when
looking at this topic.
I will now fade out of this discussion in this list. I hope.
--Lauren--
P.S. An interesting situation (purely addressing the liability
issue) is computer BBS's. While the recent MOG-UR case was
dropped, it appears that the people who think this represents
some sort of general "victory" for anyone are probably mistaken.
The case was dropped by the prosecution (reluctantly) since it
was only based on a single offending message. It appears likely
that cases will still be filed if there is a pattern of
abusive messages. They just didn't have enough evidence
in the PARTICULAR case under discussion. There are also
some other interesting cases already underway, including
one involving BBS's being used by anonymous Neo-Nazis
for various purposes. Both Canada and the U.S. are involved
in this latter case, which once again addresses complex
liability issues that will take many years to straighten out.
--LW--
------------------------------
Date: 26 February 85 18:11 EST
From: RMXJITRY%CORNELLA.BITNET@Berkeley
Subject: (copy) mail volume, etc.
Originally sent from: RLK@MIT-OZ
Originally sent to: RMXJITRY@CORNELLA
Date: Tuesday, 26 February 1985, 15:53-EST
From: Robert L. Krawitz <RLK%MIT-OZ@MIT-MC.ARPA>
Subject: mail volume, etc.
To: info-nets%MIT-OZ@MIT-MC.ARPA
I've received a fair number of replies to my inquiry about mail
volume. Here are my conclusions.
1) There are a fair number of people who do in fact have problems with
mail volume. There are lots of us who don't, but I think that as a
matter of courtesy we try respect the needs of the entire list.
2) Most people are not in favor of a digest (those that have
responded, anyway). Some people just don't like digests, some can't
undigestify them. It seems to be bitnet people who have the most
problems; can anyone on bitnet undigestify messages? (Can anyone run
a digest?)
3) Most people seem to like the idea of people voluntarily restricting
their mail. The problem here is individual cooperation.
My responses to the problem are:
1) I personally like the idea of people voluntarily reducing their
output. I am willing to meet them halfway by collecting all all
inquiries and batch-mailing them to the list, say, every week. They
won't be in digest format, so you'll just have to look through them
somehow if you want to answer questions. This would be a special
mailbox, say info-nets-inquiries, and I'd just mail the accumulated
mail file every week and delete it, making no promises.
2) I particularly find distasteful the repeated mailing of requests
(such as happens occasionally). What I think happens is that the
original inquiry doesn't show up in someone's mailbox as quickly as
s/he thinks it should, and impatiently remails the inquiry. This is
very thoughtless. Mail sometimes is slow, say when oz or mc goes down
(which isn't that infrequently).
3) I urge people not to reply to inquiries to the entire list, unless
they are things that are of interest to the entire list, or a
significant fraction thereof. Specifically, replies of the form
"Here's how to mail to site foo on net bar". Just reply to the
sender.
4) Please don't send mail of a general flamy nature to this list.
There is another list that specializes in flamage about networks
called human-nets (requests to human-nets-request@rutgers.arpa). No
one ever gave me permission to give out that, but I doubt anyone will
care too terribly much. That includes things such as is it
politically the right thing to restrict access, etc.
Comments should be addressed to info-nets-request. I hope that people
will think seriously about this, as I don't like to see people forced
to leave because of excessive, unnecessary mail volume.
Robert Krawitz
info-nets-request@mit-mc
------------------------------
From: Eugene Miya <eugene@AMES-NAS.ARPA>
Date: 1 Mar 1985 1720-PST (Friday)
Subject: Thank you, note
I would like to thank those members of the Usenet and
human-nets-digest who respond to my posting for interesting network
stories. Today I was informed by my Division chief that approval of
my invitation to China was turned down. The justification was that
the benefit to NASA did not match the cost. I was invited on an
office automation delegation whereas NASA's chief engineer was invited
on a space delegation [note: OA is not my area of research, I only
have an interest]. In my place, because of this newsgroup, Doug
Englebart and his wife are able to attend. Doug has had a long
standing interest in China, and because a fellow mutual friend give my
net address to Doug, he received a special invitation. An interesting
net story in itself. I will pass the information I have collected on
to Doug if he wants it. Meanwhile, I have to scramble to get an
abstract to the Cray User Group meeting ... in Stockholm... in my
research area, cheaper and easier to justify. Thanks again.
--eugene miya
NASA Ames Research Center
emiya@ames-vmsb
{hplabs,ihnp4,hao}!ames!aurora!eugene
------------------------------
Date: 25-Feb-85 22:45 PST
From: William Daul - Augmentation Systems - McDnD <WBD.TYM@OFFICE-2.ARPA>
Subject: The Second International Symposium On Computer Message
Subject: Systems Announcement
The following was reproduced (without permission) from an outline sent
to the IFIP Working Group 6.5 members from:
Ronald P. Uhlig
Northern Telecom, Inc.
2100 Lakeside Boulevard
Richardson, Texas 75081
USA
If you are interested in submitting a paper, please send the proposed
title and proposed authors to Mr. Uhlig, ASAP. Full papers for review
will be require no later than 15 April 1985.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The Second International Symposium On Computer Message Systems will be
held in Washington, D.C., 4-6 September 1985. Since the first
symposium, held in Ottawa, Canada in 1981, very significant progress
has been made in the field of message systems. In 1981, IFIP Working
Group 6.5 had just defined a basic mail/messaging model. The X.400
series of standards for Message Handling Systems (MHS), based on the
IFIP Model, has now been developed by CCITT, and comparable standards
have emerged from ISO. This has opened up the possibility of creating
a worldwide network of interconnected message systems. Many new
systems, both public and private have come into being since 1981, and
the electronic mail industry is growing rapidly. On going work in
IFIP, CCITT, ISO, and other bodies in Directory Services, Document
Exchange, and other areas promise to make MHS and the new standards
even more important in the future.
Since we are now entering a new era in electronic mail, the time is
right to hold a major international symposium on Message Systems. The
purpose of the symposium is to exchange information, discuss
technical, economic, and legal issues, and explore impacts of message
systems on the people and organizations which use them. Papers are
desired in the following topic areas:
Interconnection of Computer Based Message Systems (CBMS)
Interconnection of Public & Private Message Systems
Interworking among systems following standards
Interworking between existing systems and new systems
Interworking of CBMS and Telematic Services
Interworking with TWX/Telex and physical delivery
Document & Message Architectures
Document Structuring: Revisable forms and final forms
Document Interchange & Document Content Conversion
Message Exchange Protocols
Message Content Protocols
Voice Messaging
Integrated voice and text messaging
Multimedia CBMS
Multimedia Message (Data, Voice and Image)
Graphics vs. Facsimile in messages
Multimedia Message Workstations
Multimedia Message standards and protocols
Interworking of multimedia systems with single media systems
Multimedia message demands on subnetworks
Message content conversion (voice<-->text)
Use of MHS Standards as a Foundation for Other Services
Message Systems as base for distributed office system applications
Extensions to MHS, e.g. Conferencing, Electronic Publishing,
Business Data Interchange ...
Vertical CBMS Applications
Industry specific standards
Electronic Funds Transfer
Applications in transportation, law, medicine and travel
Directory Services, Naming and Addressing
Public Policy Issues In Computer Messaging
Privacy, Confidentiality, Authentication and Security
Legal Status of CBMS
Social and Behavioral Impacts of Message Systems
Impacts on Developing Nations
Corporate/Organizational Messaging Systems
Multinational private message systems
Internal corporate standards and strategy
Efficiency and Cost/Benefit
Impact on Administration and Management
User Environment
User Interface Issues
Message Editing
Messaging for the Handicapped
Human Factors
Integration with Office Automation Tools
CBMS Implementations & Experiments
Experiments and Evaluation of P1, P2, & P3 protocols
New Products and Services
CBMS as an Industry
Microeconomics
Macroeconomics
Industry projections--domestic & international
Other topics relevant to Computer Based Message systems will
receive full consideration.
PROGRAM CHAIRMAN: Ronald Uhlig -- USA
PROGRAM VICE-CHAIRMAN: Richard Miller -- USA
------------------------------
End of HUMAN-NETS Digest
************************