Re: Generalised approach to storing address details

JOG wrote:
> paul c wrote:
>

>>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.)
>>>
>>>
>>>Hi Paul. Remember that hierarchies are just a subset of the big picture
>>>given they are composed of binary relations. Given the RM is a
>>>generalized model, handling n-ary relations, surely the question is
>>>/why would it/ provide support for the special case of diadic
>>>relationships? If RM natively supported transitive operation would it
>>>still be an algebra? And if it did what would applying transitive
>>>closure to a ternary relation mean exactly?
>>>...
>>
>>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.

I didn't mean to suggest otherwise, but thanks for reinforcing what I thought.

> ancestry is transitive, parentage is not for example (my parent's
> parent is not in turn my parent too. Well lets hope not eh.). If we
> just have a parentage heirarchy, we externally know a semantic
> relationship between parentage and ancestry that allows us to infer who
> ancestors are - but vitally we are applying two extra inference rule
> from our external knowledge:
>
> 1) Parent(x,y) => Ancestor(x,y)
> 2) Ancestor(x,y) & Ancestor(y,z) => Ancestor(x,z)
> ...

Yes, that is roughly what I remember from my brief Prolog days.

> These rules could still be encoded and applied relationally. The tools
> do not currently exist to do this without recursive querying, but
> (without thinking to hard about it ) I don't envisage a theoretical
> reason why they could not be encoded as part of the predicate for a
> virtual table, generated from the parentage table itself. Good idea for
> a research paper maybe.
> ...

That is some encouragement even though I had an engine in mind rather than a research paper. Since I doubt if I have many engines left in me, I do agree that an engine ought to be accompanied by a coherent and consistent theory.

p Received on Wed Dec 13 2006 - 01:46:20 CET