Re: Generalised approach to storing address details

vc wrote:
> JOG wrote:

[snips]
> >
> > This currently is unclear to me - an ancestor relation is a relation
> > like any other, and can be enumerated like any other. Take a domain D =
> > {grandfather, father, son}. The ancestor relation would be A = {
> > (Grandfather, father), (Grandfather, son), (father, son) }. What is so
> > inexpressible there? Given that the above is no doubt obvious to you,
> > if you have the inclination, perhaps you clarify/expand what you mean
> > by "the ancestor relation cannot be expressed in f.o.l. and r.a".
>
> Consider any set of which the ancestor relation is a subset. Any such
> set is also an "ancestor" relation because it satisfies your
> definitions. How would you pick up the correct one using only the
> first-order logic language ?
>

Well thanks for reiterating this (and Marshall for his clear explication). And yes, I understand that without recursion the RA is unable to generate transitive closure. However I was more interested in a response to the following:

JOG wrote:
> vc wrote:
> > JOG wrote:

[snips]
> > > 1) Parent(x,y) => Ancestor(x,y)
> > > 2) Ancestor(x,y) & Ancestor(y,z) => Ancestor(x,z)
> >
> > if read as a first-order logic implication, the above does not uniquely define
> > the Ancestor relation."
>
> No, but am I correct in thinking that the above statements could be used to define the
> set of propositions in an Ancestry table via a Recursive Definition, with the basis clause
> referencing the already established Parent relation?"

In prolog I think I can state those rules as: "ancestor(A,D) :- father(A,D)." , "ancestor(A,D) :- father(F,D), ancestor(A,F)." and it will generate the inferences for me. Now the RM is not an inference engine like Prolog, it's a database. But I see no theoretical reasons why I could not do the equivalent via a RDBMS by setting up a "recursive definition" for an Ancestors relation (perhaps via the DDL) - a virtual relation that depends on the parents relation for its derivation. Received on Thu Dec 14 2006 - 23:13:59 CET