Eugene,
The problem with categories is that they tend to rigidify the knowledge
repository, in which case I wonder how dynamic it will be. I was in a
conference on trans-disciplinarity a few months ago and one of the
presenters said that the the real threat to trans-disciplinarity was the
hardening of categories. I a collaborative software (not Knoware) we did in
our lab we moved from relying on categories to find information to using a
good search tool. We figured that whatever categorization scheme we could
come up with, it would be obsolete pretty fast. Having said that, I totally
agree that categories are essential but they should be implemented in a way
that preserves the dynamics of the system.
In Knoware, relationships have no meaning for the software but they do have
meaning to the users. The search tool searches for text in relationships as
well as in concepts.
Gil
-----Original Message-----
From: Eugene Eric Kim [mailto:eekim@eekim.com]
Sent: vendredi, 23. juin 2000 05:34
To: unrev-ii@egroups.com
Subject: [unrev-II] Augment + categories = OHS v0.1
Based on the discussions we had at our meeting today and some of the
discussions afterwards with Eric, Howard and others, I came up with the
following conclusions.
Fundamentally, our system consists of two things: nodes and links. The
difference between our system and the previous two revisions of Doug's
work is that our system allows us to categorize nodes. Categorizing nodes
is crucial, because it provides an additional semantic layer that is
crucial for knowledge management. Both the users of the system and the
system itself can take advantage of this additional layer.
For example, in order to adapt our system to accomodate IBIS-style
discussions, we add categories such as "question," "answer," and
"alternatives." With this information, we can search for all the
questions pertaining to a particular topic of discussion. Or, we can
write a system module that automatically compiles and presents an IBIS
view based on the current question and answer nodes.
Categorizing nodes allows us to provide some structure to discussion, even
if the discussion itself is unstructured. For example, if we're trying to
come up with a Use Cases document for a piece of software, I may propose
five different Use Cases in three different e-mails. However, if these
nodes are properly categorized in each node, then I can easily create a
Use Cases view that shows all of the Use Cases in one view, regardless of
when or where these were proposed.
I think there's still one open question that needs to be resolved for
version 0.1 of the OHS. That question is, are links categorizable? This
relates to some of Eric's previous questions regarding relationships. In
my opinion, a link is the way you represent a relationship. The question
is, should you be able to specify categories for a link.
My suspicion is yes. Even if this doesn't immediately affect system
behavior, I think it is a useful attribute to have in the data
structure. In Gil's Knoware, which he demonstrated last week, you can
label relationships, but those labels have no meaning. However, it should
be fairly easy to give those labels meaning in the system in the future,
which is one of the things Gil said he planned on doing. I see no reason
why we shouldn't take the same approach.
-Eugene
--
+=== Eugene Eric Kim ===== eekim@eekim.com ===== http://www.eekim.com/
===+
| "Writer's block is a fancy term made up by whiners so they
|
+===== can have an excuse to drink alcohol." --Steve Martin
===========+
----------------------------------------------------------------------------
------------------------------------------------------------------------------ -- 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 : Thu Jun 22 2000 - 23:52:38 PDT