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

>>> Nick: If you wish to actually convince someone of something, you are going to have to work a little to show them that you are worth listening to... .
>> Neo:) Sometimes a picture is better than words. >> ww.xrdb.com/Example/Ex039.asp shows the last Food Judging Example. .
> Nick: And sometimes it is not. The page you reference simply reiterates the stuff you've been writing in this thread.

:) Sometimes its the simple stuff that needs to be reiterated. Did you not see the Karate Kid?

> You have not addressed the inability of your system to actually produce a viable mechanism for using the information that you are able to store.

The referred page's simply demonstrates a particular example. I haven't asserted dbd's inability as a viable mechanism for using the information that it is able to store.

> RM does not require this mechanism because of the nature of the structured and methodological design paradigm that is used to normalize information.

Great, I even hear RM has a rigorous mathematical foundation, is based on set theory and prediate logic, was created by a really smart person named E.F. Codd and is endorsed by even smarter people like Date and Pascal, taught by professors at colleges, learned by students, used by thousands of developers and engineers around the world for many year. So why not replicate that above example with RM, and I will demonstrate why dbd is more general/flexible/systematic and "normalized" at representing things.

> You have no such paradigm. You view that as a strength, and you have made your point.

:) I don't know your shoe size and neither have you told me. And if you couldn't/wouldn't currently, I could conclude, you must view that as a strength and not have any shoes!

> However, in lieu of these 'restrictions', you need to provide a framework for the use of information that your system stores.

And dbd provides a framework for storing, retreiving and maninpulating data that it stores. Storing and retrieving were demonstrated in various examples through out this thread and others are documented at website.

> querying for clearly available data is a trivial illustration not much more
> advanced than 'Hello World.'

Ah, but what isn't so trivial, is to represent things in as general/flexible/systematic manner as dbd, that is as resilient to future unknown requirements. If you still doubt this, please post an alternate solution to above example so we can proceed to verify again.

> You need to be able to model the universe of information and illustrate how your system can be used to not only capture it, but how systems can be developed to retrieve the information in a useful manner.

How systems (what do you consider a system) can be developed to retrieve data stored in dbd wasn't the focus of this thread. If the system is a user, he can retreive data by browsing the tree/tables or by submitting select expressions (ie select john like *) which highlight the appropriate nodes. If the system is an app, it can retreive data via the DLL interface to the db. There are old examples of this at www.xrdb.com/Example/Ex006b.asp , www.xrdb.com/Example/Ex004b.asp and www.xrdb.com/Example/Ex010b.asp

> Examples like this one do very very little to further your cause.

So far, it has demonstrated that Prolog can't represent things in as general/flexible/systematic manner. If you still doubt this, please post Prolog's solution to above example and we can proceed to verify again.

> Let me know when you have submitted a paper to the ACM or IEEE/CS for resentation at a conference, and I will gladly either attend the symposia or purchase a copy of the proceedings. Until then, you have nothing of interest.

Nick it seems, you are going to hide behind institutions like ACM and IEEE/CS. Until you realize the value of a very general/flexible/systematic method of representing things and that no existing well-known methodology implemented on PCs can match dbd, I have nothing of interest for you. Received on Thu May 18 2006 - 21:30:18 CEST