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

>> Neo: But on a related note, as the original and serveral other posts indicated, an app/android using dbd can create a new function (ie createWRR or getRoot) on-the-fly, at run-time simply by adding data to the db using the existing functions such as create, select, etc. The app/andriod can then use the new function in yet another new function and so on, all at run-time. Can Prolog or LISP do similar? Since there is still a lot of development to do in this area, I can only demo simple functions at this time.

> Nick: Yes, Prolog can assert new facts and relationships to allow entirely new
deductions and deduction models.

Ok, but can it accept new things (facts, relationship, and functions) at run time or does one need to update the original source file, recompile and then run? If so, this is not equivalent to what I am describing above. Can a Prolog-based andriod add new things (facts, relationship, functions, etc) on-the-fly or does he need to be halted, so that someone can update the script file, recompile it and then start the droid back up again?

> I find it fascinating that your model is so mathematically frail that you needed to add statements to the compiler in order to support simple mechanisms, rather than simply defining a function in the language.

First, the addition of a convenience function by compiling it in when a db is being implemented isn't necessarily an indicator of mathematical frailty. After all, near all mature products have gone thru similar cycles. Second, dbd is primarily a database not a programming environment like LISP or Prolog (at this time).

> I have a challenge for you.

:) Sure, but you never did attempt the Food Judge C Example which was designed to exhibit Prolog's weaknesses (ie things without names, things with multiple names and queries to find relators/verbs, etc).

> Assume that you want to represent the following information:
>
> Tony has a dog and a bird
> Joe has a bird
> Mary has a dog
> Bird owners enjoy a hot bath
> Dog owners that are not bird owners enjoy taking long walks
> Dog owners prefer cold showers
> On Tuesday, Dog owners who are also bird owners buy groceries
> On all other days, bird owners who are not dog owners buy groceries
>
> In this case, most ordinary programming languages struggle. Prolog shines.

:) I don't doubt it (but dbd isn't a programming language).

> Every statement above is a single statement in Prolog.

If you are saying that succinctness of representation is the basis of evaluation, then I gladly admit Prolog's superiority right now :)

> Finding people who like cold showers is simple. Finding people who enjoy both a hot bath and prefer a cold shower is also simple. Finding people who take long walks is simple.

If you are saying that simpleness of representation or simpleness of finding things is the basis of evaluation, then I would probably admit Prolog's superiority right now :)

> I'm sure that most or all of these items is also quite doable in your db language. The point is that your language does not exceed Prolog.

:) And luckily, I never asserted that my language exceeds Prolog. Let me restate what I have asserted before: dbd provides the most general/flexible/systematic method of representing things. Note that I agree that currently RM, Prolog and LISP provide much more functionality in processing whatever data they can represent.

> If you are lucky, you are on par with Prolog in many cases.

I expect to demonstrate that the dbd's method of representing things is more generic/systematic/flexible than any other, including Prolog's, especially as I extend the above example later, when I add unnamed things, things with multiple names, names that have multiple spellings, and queries that access the data stored in Prolog's function names.

> For that, I applaud you. It is difficult to create a KR mechanism that is flexible.

I don't claim to have created a flexible Knowledge Representation mechanism specifically. I claim dbd's method of representing things is the more general/flexible/systematic compared to Prolog, LISP and RM's.

> That you did it without using formal logic or a grounding in horn calculus is quite impressive. But it doesn't make your system any better, and in fact, it is unlikely to exceed Prolog in design and elegance because simple equations cannot be easily reduced. Prolog succeeds in this area because of its simplicity, not its superiority.

Again, I don't assert dbd is better than Prolog or that dbd exceeds Prolog in design and elegance becasue of its simple equations which cannot be easily reduced. I assert that dbd's method of representing things is more general/flexible/systematic.

> As I said before, ultimate flexibility yeilds almost nothing.

I believe that a very general/flexible/systematic method of representing things is important to achieving some of the capabilities displayed by the human mind.

> While Prolog can represent everything that your system can, history did not prove it to be ultimately successful. Clearly, the problem isn't the lack of flexibility in representing knowledge... now is it?

Thus far Prolog is not as general/systematic/flexilbe in representing a few things, such as the data that end up as a function's name and the name of atoms. I have already posted such examples and can post them again. Some of them are in Food Judge Example C which no one has implemented in Prolog. I also showed how Prolog is similar to RM in that new things (data) has a bigger impact on existing schema, scripts, data, etc than in dbd. For example, when the "john like mary" example was extend twice, each time existing data/structure in Prolog had to be revised but was unaffected in dbd. This characteristics is important for AI apps because furture requiments are typically unknown and we would like the droid to have the least difficult in adapting to it, by itself.

I'll get started on your "challenge" above. I will name the dogs "fido" and "barky"; the birds "tweetie" and "polly". Also some of your queries use the equivalent of NOT. Currently I can only find things john likes and not the things john does not like (I haven't developed such functions). If you could reform the queries without NOT, that would be great. Please post Prolog's actual solution so I know more accurately what to represent/query. And again, thanks for engaging in these examples :)

PS. Warning! Warning! Will Robinson! I intend to show how dbd's method of representing things is more general/systematic/flexible by extending this example later. Received on Tue May 02 2006 - 21:35:08 CEST