Re: Generalised approach to storing address details
Date: 12 Dec 2006 10:14:52 -0800
Message-ID: <1165947292.024505.125180_at_n67g2000cwd.googlegroups.com>
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.)
> >> > handle the extra idiosyncracies and shortcuts of binary relations
> > 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
> > 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.
True, but parents and ancestors are two completely separate relations - 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:
- Parent(x,y) => Ancestor(x,y)
- Ancestor(x,y) & Ancestor(y,z) => Ancestor(x,z)
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.
>
> p
Received on Tue Dec 12 2006 - 19:14:52 CET