RE: A few of my own : RE: Problems with Classifications

[David RR Webber <Gnosis_@compuserve.com>]

Len,

Having reviewed this I realize that my view of a classification
scheme is somewhat different from yours!  Now I need to
re-align and adjust my terminology here.

The first instance I realize I was seeing is really more of
an information model - aka a schema - that describes
the content associated with a class of information - 
hence my use of classification.

Now - that is in the singular - what you see is a linked 
list of multiple instances of this - an example would
be (countrycode, (currency, date, exchange rate)+).
The EDI world views these as Code Tables.

Mentioning linked lists (since I'm a big Prolog person)
the solution appears to be to associate link lists via
the GUID identifier - and since they are linked lists,
maintain this as an element to provide the connectiod.

We could get really fancy and borrow Prolog functionality
with the ability to bind results sets, and have backward 
chaining derive joins, and so forth, but for Version 2.0,
not Version 1.0!

In our Tel Conf on Thursday we had already discussed
the need to greatly amplify on the GUID concept - and to
refer that back to TA - this just emphasizes that need.

Looking at the issue here - if we re-instate Node (which
we clearly must do) and then associate a GUID with 
this - with the intent of creating linked lists - then this
will work.  It leaves open a functional policy decision
when an owner withdraws or deprecates an item
that someone else has linked to.  That should
trigger a warning to that person, and the owner,
a very familiar situation - ie. when you are about to
logoff a network and you have shared resources.

I suggest we document this and resolve this for
the next draft post PoC.

Thanks, DW.

==========================================
Message text written by "Nieman, Scott"
>>
>             M
>           / | \
>          /  |  \
>         P   W   O
>            / \
>           /   \
>          HW   SW
>
> The new definer creates the new nodes for M, P, and O, but wants to
> reference W for wood. There is no way the second definer can have W point
> to M as parent because W already has a null pointer for its parent
> attribute, and that node is owned by a different definer. So the definer
> will have to create a new node W' that points to M as its parent and
> somehow has a Ref to W as that portion of the hierarchy. We'll get the
> following representation:
>
>     (M, -)
>     (P, M)
>     (W',M) with Ref to W
>     (O, M)
>
<