In conversation with Eugene, he's been asking
the question: Are multiple parents for a node
really necessary? Basically, if that concept
adds complexity, maybe we should plan on not
implementing it.
I have felt that it was vital, but so far have
not presented a compelling enough use case to
settle the argument. This message is an attempt
to do so. (And it led to another interesting
insight that prompted me to jot down my thoughts.)
MESSAGING BASIS FOR SYSTEM
--------------------------
I take it as a given that I want to interact
with the system in much the same fashion that I
interact with my email client -- only with much
more powerful capabilities. To me, the interchange
of messages is the right way to think about
designing a "front end" that captures knowledge
organically.
The basic problem with knowledge-storage systems
in general as that they are too inflexible, and
extremely difficult to right. Even when they do
sometimes get it right, the lack of flexibility
makes them less right over time, until they
eventually become useless. (John Lowrance at SRI
has some interesting war stories on the subject
that illustrate the point.)
So, the "email paradigm" is, to me, a given. The
system must allow users and the system to
interact. A user should be able to send a query
and get the system's idea of a response. Other
users should be able to review that response and
refine it, if necessary. In the process, they
should be making the system smarter, so it can
do a better job of generating answers in the
future (possibly by interacting with the originator
of the message, before the message is actually
sent).
MULTIPLE PARENTS
----------------
Thinking of the system as an "interactive, message-
based, knowledge repository" (IMKR?) leads to one
motivation for allowing a node to have multiple
parents: the drafts folder.
In my email system, I have a drafts folder that
keeps copies of messages I am working on. I
frequently use it to keep todo lists for various
projects I am working on. (I create the message,
but don't send it. I check things off as they're
complete, and occasionally send copies of the
message as a status report.)
That is a useful facility. But note that my draft
of things to do is in a different folder from the
project folder, where I have filed the various
messages and information tidbits that tell me how
to DO those tasks.
Now, it would be excellent if the todo list
contained links to those messages. We know we want
that. But it would also be useful if the todo list
itself could have dual membership, so that it
simultaneously exists in the Drafts folder and in
the folder for the project it applies to.
Looking in the Drafts folder would then show me
all the todo lists for every project I'm working
on. Looking in a given project would give me the
information relevant to that project, along with
the todo list. There is just no substitute for
having that todo list belonging to two folders!
SLASH and BACKSLASH
-------------------
Thinking of a message with dual membership led me
to an interesting question: How do you distinguish
messages that have the same title, though they
reside in different folders? How should they appear
in the Drafts folder, in other words, so it is
clear which one is which?
For example, suppose that Project A has a "ToDo"
message, and Project B has a "ToDo" message. How
do they appear in the Drafts folder? Clearly, the
system would need to add the folder information.
In other words, it should add as much parentage
information as necessary to distinguish two
otherwise equivalent messages.
It flashed on me then that here was a *perfect*
place to use the backslash. The Drafts folder
might then look like this:
Drafts
Questions
ToDo\Project A
ToDo\Project B
Of course, it should also be possible to put the
parent information on the left, and revert to
forward slashes. That would change the sort,
producing:
Drafts
Project A/ToDo
Project B/ToDo
Questions
Anyway, them's my thoughts for the day...
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 14:40:28 PST