Re: Links, Types and Documents (Third time's a charm)
Dan Connolly (connolly@pixel.convex.com)
Mon, 22 Jun 92 14:38:26 CDT
Message-Id: <9206221938.AA17202@pixel.convex.com>
To: raisch@cthulhu.control.com (Robert Raisch)
Cc: jfg@dxcern.cern.ch, www-talk@nxoc01.cern.ch
Subject: Re: Links, Types and Documents (Third time's a charm)
In-Reply-To: Your message of "Mon, 22 Jun 92 13:30:55 EDT."
<9206221730.AA04308@control.com>
Date: Mon, 22 Jun 92 14:38:26 CDT
From: Dan Connolly <connolly@pixel.convex.com>
><!--
>
> I first posted this some weeks ago on the 'www-interest' list, and
> received only one reply, (complementing me on my reference to Rexx.)
>
I keep my copy of this posting handy and I check lots of ideas against it.
> I really had hoped that this post would start an interesting discussion
> on the topics I address, specifically the ideas of 'attention links'
> 'user documents' and 'transparent documents'.
>
I don't have any well defined systems (implementations or just specs.)
that address these issues. WWW is headed in this direction, but it's
a long way off.
> Are these ideas so obvious that they merit no discussion whatsoever?
>
No, it's more like they're so novel we haven't thought seriously enough
to comment yet.
><Query>
>One of the missing pieces here is the ability of creating new h-texts, and
>adding new links to old h-texts.
>
>Hypertext, and like systems, are of limited use if they do not support
>collaboration. I feel that this is a VERY important point.
>
>When might we expect extensions to WWW that support collaboration?
></Query>
You might look to Andrew for a more mature system in these regards.
While I think Andrew is a great breeding ground for ideas, I think
the resulting technology is too off-beat (for example, they implemented
their own object-oriented C preprocessor, and now C++ has come along
and writing Andrew code looks like a pain in comparison).
I'm toying with the idea of a FrameMaker inset editor to interface
Frame's direct-manipulation editing capabilities with global
hypertext on the internet. I shouldn't even mention it until I have
some sort of implementation, but it's an idea...
>I have a few recommendations regarding new link types in WWW. This is based
>on thinking about hyper-applications for almost 15 years, (ever since I
>first had the pleasure of hearing Ted Nelson speak in 1977.)
>
>Please keep in mind that these are 'front end' issues. They should not
>affect the manner in which documents are stored.
>
Well, we should be careful not to store documents in a way that
conflicts with these useful concepts.
>------------------
>
>There are 4 'minimal' link types which, I believe, a true hypertext applicatio
n
>*must* support.
>
> 1. Replacement
> -- when activated, replaces the current document
> with a new document, (this is what WWW offers
> today).
>
FrameMaker: gotolink
GNU Info: menus, notes
WWW: <A HREF=...>
EBT: link
> 2. Annotation
> -- when activated, overlays a new document on the
> current document, partially obscuring the original.
> (An annotation must be dismissed by the reader.)
>
FrameMaker: openlink
GNU Info: n/a
WWW: n/a
EBT: link window=new
> 3. Inclusion
> -- when the document is created, elements from other
> documents are collection to be included in the
> representation of the current document. (Quotes)
> (This is a non-interactive link. The user does
> not activate this link. It is activated before
> the document is presented to the user.)
>
FrameMaker: import by reference (bitmapped graphics ONLY)
GNU Info: n/a
WWW: n/a
EBT: n/a
> 4. Expansion
> -- when activated, new information is added to the
> current document, expanding the original scope.
>
FrameMaker: conditional text
GNU Info: n/a
WWW: n/a
EBT: change stylesheets so that HIDE property changes
>
>There are 3 further types which I believe are necessary to complete the
>function paradigm. (Of particular interest is the 'attention link'.)
>
>
> 6. Execution
>
> -- when activated, some arbitrary function is performed
.
> The point that was mentioned about the lack of an
> ubiquitious scripting language is well made. Lisp
> is too arcane for most. Shell languages are too
> platform specific. What is needed is a simple
> to understand, freely available scripting platform.
> Although I hesitate to mention it, REXX might be
> a reasonable choice due to it's broad availability.
>
Ah... if you want commentary, state an arguable thesis. No one can argue
against a platitude like "What is needed is a simple to undertand,
freely available scripting platform." I vote for some brand of Lisp, perhaps
XLisp or ELK.
But there's a larger issue: should documents be turing machines? Using SGML,
it is a well defined problem to determine whether a document is valid. As
soon as we allow documents to be programs (like TeX, nroff, or Lisp), we
run into the halting problem and we lose any hope of converting documents
from one representation to another. If a document is a program that, when run,
conveys its content, then we lose the ability to use that content in any
other way than the author originally intended.
> 5. Attention (a specialisation of the Execution type)
>
> -- when the current document is modified (a link is
> added, or removed, or the document is merely read)
> a message is sent to the 'owner' of the attention
> link. This message creates a new link in the 'user
> document' of the individual who placed the attention.
Hmmm... I need a clear explanation of the underlying model here. In the
model in my mind, a "document" is never modified. But the functionality
you describe is interesting. Certainly we want to be able to collect
usage statistics.
> 7. Collection (a non-local specialisation of the Execution type)
>
> -- when activated, a collection link leaves the current
> document, and 'travels' the docuverse, in search of
> other documents which satisfy it's internal criteria.
>
> This is the concept of a 'knowbot'.
>
It looks like a query to me. I need either 1) a good definition of the
capabilities of a knowbot, or 2) an implementation of a knowbot (any
sort of hack will do) to get a feel for the functionality. Until
then, it's just a very vague idea. Fortunately, there are some
implementations of this idea: cron/find, WAIS, USENET news (kill files, etc.)
>
> Transparent Documents --
>
> a transparent document is one which a user creates locally,
> and that is a new representation of an existing document.
>
> Transparent documents are used to create new local links on
> a document which I do not have permission to modify.
>
> Transparent documents can then be made available to others,
> (published) just as a "regular" document is, thus facilitating
> the creation of new works from old.
>
This looks like a local copy of a document to me. No?
> User Documents --
>
> a user document is where I keep my "bookmarks", links to
> local documents, links to messages from others, links to
> my "attention" links, (see below). User documents are where
> we, as navigators of the docuverse, are defined as individuals.
>
> They are also where we can keep links to other user documents
> which have been permitted to view/modify my own local documents
.
>
> Another function of the User document is to collect users into
> an abstract group. (Thus, based on my membership in user
> document 'Research Group', I am permitted access to materials
> 'owned' by that group. Of course, messages sent to an abstract
> group then become available to all members of that group.)
>
> (Please note that a User Document is nothing more or less than
> a collection of links, (as all documents are).)
>
Now we've opened up the whole PIM can of worms. Current implementations
include mail user agents (MH, Elm), news readers (with their .newsrc and
kill files, etc.) wais-questions, WWW home documents. I haven't looked
at the hyperbole model, but I understand it addresses this issue at length.
>So.....
>
> Scenerio:
>
I'd like to see how a MIME user agent would satisfy this scenario...
> I start my session with my hypertext-application, and open
> my user document.
>
I start my MIME UA.
> I notice that 17 of my attention links have been activated
> in the last day.
>
There are 17 mail messages (with certain tell-tale headers) in my inbox.
> I select the most interesting and activate the link which
> it created in my personal user document.
>
I read the message. It's a message/external-body type message that points
to an article in a USENET database at this site.
> I am now reading an article which I previously linked
that is, I had saved the article by creating a message/external-body
type message in my mail box.
> , and
> see that an annotation which I made some time ago
i.e. my followup article
> has been
> added to, by a colleague.
>
i.e. has been followed-up.
> The comments are pertinant to my current work, so I create
> a new local 'transparent' document to mirror the original
> work. (Or use the 'transparent' document I may have created
> previously.)
>
I just save a reference to the news artile, as above, in a message/external-body
type message.
> On this new document, I make a few new annotations
i.e. I follow up to the document. It would be nice to be able to do
some direct-manipulation style annotation to articles, ala FrameMaker.
> and decide
> to made this new work available to the research group of which
> I am leader. I place a link to it in the user document which
> represents my working group.
>
I mail a message/external-body style reference to the thread to the
alias that represents my working group.
I really think that Internet Mail, Usenet News, and WAIS could be
a great platform for CSCW. A MIME user agent that could make
WAIS and NNTP queries and act as a FrameServer client would
be a great start. If I have time, I'll try to cook something up.
Dan