Re: Generalised approach to storing address details

> Yes, can't argue with that and I would say that my understanding is that
> the RM can happily represent ... one hierarchy at a time ...

One couldn't agrue (very well) if RM is happy or sad when representing heirarchies, but one can point out when a hierarchy is represented unsystematically according to the Information Principle. For example, in the table below, user is implying john's child is jim and jim's parent is john.

T_Hierarchy
Parent Child
john jim

However by generalizing it as shown below, one can see that such information is implicitly derived by the user and not explicitly expressed by the data:

T_Table
Attrib1 Attrib2
val1 val2

Information Principle says the only thing the above data expresses is that tuple1's attrib1's value is val1 and tuple1's attrib2's value is val2. To say that val1's attrib2 is val2 violates IP. To say that val2's attrib1 is val1 violates IP. Representing hierarchies as above is unsystematic and violates IP.

Then there is the issue of RM not being able to determine verbs/relator of relationships which limits it ability manage data in general. For example, in the following dbd script, user creates a verb, describes it as transitive (or symmetric, reflective, etc), uses the new verb to relate john to mary, and then later retrives the type of the verb that relates john to mary to make a decision. How can one do this in RM in a general/systematic manner?

(new 'xyz 'verb)
(set xyz vbType transitive)
(set john xyz mary)

(if (= (get (get john * mary) vbType *) transitive)

   (then ....)
   (else ....)
) Received on Tue Dec 12 2006 - 17:57:06 CET