Re: Storing data and code in a Db with LISP-like interface

From: Neo <neo55592_at_hotmail.com>
Date: 22 Apr 2006 14:26:00 -0700
Message-ID: <1145741160.625073.144920_at_g10g2000cwb.googlegroups.com>


>>>>>>>>>> Neo: I believe I have already surpassed RM. And as far as I can tell, linked-lists are not even as flexible as RM. Below is a simple example that stores a person named John who likes Mary and then finds who John likes. Could you or someone familiar with Prolog show how to do this...
>>>>>>>>> Alvin Ryder:Both Prolog and LISP can represent information and indeed knowledge well beyond the RM...
>>>>>>>> JOG: Prolog models a greater subset of predicate logic than relational theory due to its inclusion of negation and disjunction....
>>>>>>> Bob: Are you suggesting that NOT is not negation or that OR is not
disjunction?...
>>>>>> JOG: not the same as the use of negation in explicit declarations such as P(x) || ¬Q(y) (for instance)....
>>>>> Bob: The point is the relational model basically supports both with the one small requirement that one must specify one's universe...
>>>> JOG: The predicate behind the relation is: [¬clothing -> weather], and anyone interacting with the db must be aware of this in order to reform my original propositions...

>>> Bob: I see what you mean...

>> Neo: With all this brain power between you [Bob] and JOG, would either one of you be willing to demonstrate it by using RM to represent the data in the Judge example posted earlier in this thread using the experimental db? .
> Speaking from practical experience, conversion from one solution to a solution in a different framework is much harder than starting from requirements, and designing a solution within a specified framework.

:) In general, I would agree with your assessment; however it mostly does not apply to the situation at hand because:

First, the general requirements were initially specified by OP of recent thread title "Data Model" (you may want to skim it).

Second, if you had read the prior posts in this thread, you would be aware that Judge Example was initially specified by OP of another recent thread titled "Data Model" (you may want to skim posts above).

Third, I am not asking anyone to convert my solution to a solution in a different frame work. I am asking anyone using any other methodology to model/represent the same things (facts, data, relationships, etc) that I modelled in the Judge Example.

Fourth, it is now me, who is setting the requirements. The requirement is to represent the same things that my Judge Example does. For example, if a comment in my solution indicates something like, there is a Judge named Judy, one needs to model this with their methodology.

> Therefore, I reject the fundamental premise behind the challenges that you have been making for several years now. I'm speaking of your challenge that one of us should reimplement an example that you have posted using your experimental db. The idea behind your challenge is that, in the absence of a response, your experimental db stands unchallenged. I reject that.

The purpose of the challenges is so that you can verify, first hand, that RM's claim of being the most general/flexible data model is FALSE! The person most responsible for actively propogating this falsehood in c.d.t. is Bob Badour and many like you who back him up.

> From my point of view, reimplementing the judge example or any other using the RM, or any product purportedly derived from the RM, would be a lot of work, and a waste of time.

:) It was easy using the exp db (which has been renamed to Db for Dummies!), yet the data is fully "normalized".

> It's rather up to you to demonstrate for this newsgroup that your db fills a gap in our accustomed toolset, and to describe that gap adequately for us.

A discussion of the gaps (actually more like extensions) that the db fills are littered through out this thread, and I would direct you to read the ones with TopMind first. To verify if the db fills those extensions, requires someone like you to engage in one of the challenges. Will you engage?

Oh, I almost forgot, the Db for Dummies, allows dummies to model/represent things that most RM users can't and even most RM experts can't, in a completely normalized, NULL-less manner, without ever specifying a schema! Received on Sat Apr 22 2006 - 23:26:00 CEST

Original text of this message