Re: Generalised approach to storing address details

JOG wrote:
>
> On Dec 11, 11:19 pm, paul c <toledobythe..._at_oohay.ac> wrote:
>

>>Neo wrote:...
>>
>>
>>>>You think that RM can't handle hierachies after I answered your demand on the *Brothers and Sisters* thread with a simple structure that perfectly met your criterias?
>>
>>>It is not that RM can't handle hierarchies, ...I would like to know how the RM handles hierarchies, without the aid of
>>
>>a builtin such as TTM's TCLOSE that is essentially outside the scope of
>>the RM (eg., it seems to me that it does a transformation that can't be
>>couched in fundamental RM terms.)

Thanks, those three questions are put better than mine and I especially like the last one. (I may have misunderstood the intent of Neo's statement, eg., "handle" can be taken in various ways, but it struck a nerve with me.)

> When we draw a hierarchy on paper we are constructing a handy shortcut
> (google hasse diagrams for their generalization), and if we enumerated
> the underlying relation mathematically we would end up listing _all_ of
> the ancestry ordered pairs, not just the local ones. So I reply mu and
> unask your question. The RM can represent hierarchy more than happily,
> but it is not imo the responsibility of a generalized data model to
> handle the extra idiosyncracies and shortcuts of binary relations
> specifically.

Yes, can't argue with that and I would say that my understanding is that the RM can happily represent (by represent, I think I mean materialize pairs) one hierarchy at a time, ie., not two at a time, eg., parents and their children or ancestors and their descendents.

p Received on Tue Dec 12 2006 - 15:44:53 CET