Re: Generalised approach to storing address details
Date: Thu, 14 Dec 2006 22:50:17 GMT
Message-ID: <Jykgh.480889$5R2.295359_at_pd7urf3no>
JOG wrote:
> 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.
>
Nor do I see any such reason but my impression is that the others here haven't said no to that. Personally I would find that approach more declarative assuming that it was able to hide any TCLOSE-like operator from users (at least from the users who desired it to be hidden). What I couldn't see is how to do it without having an additional operator that could not be defined in terms of the most otherwise minimal set of primitive algebraic operators (say, for argument's say, in terms of NAND and PROJECT). If the target were recursive support based on a minimal number of operators (don't ask me why, I just like the notion) then I imagine (at the least) that they would need to be fundamentally different than those two or at least NAND.
Also, as far as hierarchies or DAG's are concerned, I don't think having
a "=>" operator in a language is really any departure from having a
"TCLOSE" verb. For sure, Prolog's "=>" doesn't mean the same thing as
logical implication where everything is true except for two negatives,
eg., in the RM, in theory, one language ought to be able to produce
equal results to another if negation is supported and all operations are
performed on the logical complements of the intended relations. Maybe
another way of what I'm saying is that the RM enumerates all true facts
of interest, whereas a Prolog system doesn't bother.
p