Jack Park wrote:
>
> Of primary interest to an OHS is the idea that an information cell
> need not
> be cloned into several places for different views. Rather, one cell
> can be
> a member of an infinite number of 'threaded' views. That way, only one
> cell
> ever exists for a particular concept, and that lone cell, once
> modified, is
> immediately available to all views which would use it.
>
This is the basic idea of multiple-parenting. The core notion
is that structure is divorced for content. A structure consists
of a set of links:
Structure Link Node
+-> A -------------> A
| B -----------> B <--+
| C -----------> C |
| |
| so some other structure can |
| reuse the an existing node |
| Z... |
| B ----------------------+
| Q...
|
+----------------------------------+
|
or reuse a whole sub-structure |
M... |
A ---------------------------+
R...
Note that simple node-reuse is relatively easy.
It sounds as though the "cells and dimensions"
idea may be focused on that track (although I'm
not entirely sure that is the case).
The ability to reuse structures is quite a bit
harder, but of great importantance, imho.
The way I've seen to reuse structures is
to put the root of the subtree in a "wrapper",
that identifies it as different from "native"
nodes in the tree. That makes it possible to
add type information, to identify the kind of
information that is being included. That's
important so you can hide elements by type.
Note that the "type" of the element is related
to the purpose it serves in the current context,
and is not a function of the element itself.
For example:
A node contains information on the chemical
interactions of fatty acids in olive oil.
A "recipe" consists of a list of ingredients,
along with the health information of each.
In the context of that recipe, it is worth
distinguishing "health" information from
"how to" information, so the user can
selectively enable and disable the display.
But the original node that detailed the effects
of olive oil would likely not have anticipated
that use. (Even if did, making the target node
have the correct type is tantamount to requiring
a globablly-accepted ontology, so that all the
health-related nodes the recipe points to are
categorized the same way. That halcyon scenario
is implausible, if not impossible. "Context-
specific typing" makes a lot more sense.
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 Jan 25 2001 - 20:42:16 PST