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

> Hello Neo,

Hello Nick,

> You have a tedious habit ...

We all have "tedious" habits. Even you have some tedious habits. Not that a tedious habit is in of itself good or bad. Some are actually good within a certian scope.

> ... of attempting to respond to every sentence, ...

I find this the best way to reponsed to certain posts, especially those where each sentence seems to require an individual response.

> rather than the questions I ask.

I believe I have attempted to answered all the relevant questions that you have asked. If you feel I haven't, ask it again. Which question do you feel I haven't responded to?

> It makes me wonder if you are actually reading the entire message before responding.

You don't have to wonder. I will tell you. Not only do I usually read the entire post before responding, I usually read it several times and also any other posts from the same person that I haven't responded to. Such was the case in responding to the post in question. This doesn't guarantee anything, especially that you will like my response or style of response, but this is the typical process that I take before responding.

>>> Nick: I find it curious that you chose to implement 'Joe owns Polly' but not 'Joe owns a Bird'... .
>> Neo: :) I was trying to let you focus on the initial problem and make it easier on Prolog since it is unsystematic when dealing with names of things... .
> Nick: That Prolog has a different system does not imply that it is unsystematic. Saying so earns you lower credibility.

That two methodologies have two different systems to represent the name(s) for a thing, in of itself does not imply one is more systematic than the other and neither have I asserted this. However Prolog's system of representing the name(s) for a thing is less systematic than dbd's. By you not realizing this (or going thru the steps to verify this) even after I have posted explanations and examples (including Food Judge Example C) that demonstrate this point, earns you lower credibility. In case you missed them before, I will re-demonstrate three cases below with dbd's abbreviated script:

(; Case 1)
(; Represent an unnamed person whose color is red)
(; Note that (it) refers to last thing create by (new))
(create person instance (new))
(create (it) color red)

(; Following queries returns nothing since the person is unnamed)
(select (it) name *)
(select (and (select person instance *) (select * color red)) name *)

(; Case 2)
(; Represent a person with two names)
(create person instance (new))
(create (it) color blue)
(create (it) name (word+ 'john))
(create (it) name (word+ 'johnnathan))

(; Following queries returns two seperate words)
(select (it) name *)
(select (and (select person instance *) (select * color blue)) name *)

(; Case 3)
(; Represent that the word "john" is an abbreviation of "johnnathan")
(create (word 'johnnathan) abbreviate (word 'john))

(; Find the relator between "johnnathan" and "john")
(; Returns abbreviate)
(select (word 'johnnathan) * (word 'john))

Please post Prolog's equivalent to show it is as systematic. Also note, as noted and described in some of my prior posts, a thing's name is related to a word. A word is related to a string. And a string is related to symbols. Dbd represents everything thing, including symbols, just the same way as any other thing. Some functions, such as "word+" are equivalent to multiple expressions.

> 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.

I believe I am doing that work by providing concrete examples.

> That means to carefully earn credibility and respect.

My goal isn't to earn your credibility and respect. It is to demonstrate that dbd's method of representing things is more general/flexible/systematic than others like Prolog, LISP and RM. Just asserting this automatically makes me incredible and disrespectful to most.

> You've done little of either [earn credibility and respect] in this entire thread.

Again, my goal isn't to earn credibility and respect. It is to demonstrate that dbd's method of representing things is more general/flexible/systematic than other methodologies implemented on PCs.

> I believe that you are intelligent, but I honestly believe that the greatest inventions are those where a good idea comes from an intelligent person who is able to convince others of its value.

Thank you for stating your belief. Since we are sharing beliefs, I will now state mine concerning the same topic. While I too would like to believe "that the greatest inventions are those where a good idea comes from an intelligent person who is able to convince others of its value", I don't know what exactly qualifies as a great invention, what is an invention, what is a good idea, what is an intelligent person, what is of value, etc. And none of these are my primary goal in this thread.

> You have not been able to convince me of the value of your system at all.

If via the various examples and extention of examples, including some that were not replicated with Prolog (ie Food Example C), you didn't observe that dbd's method of representing things handles new and unknown requirements with less impact on schemas/queries/code than other methodologies and that this is important in the scope of some applications such as AI where the unknown is to be expected, then either I have failed to convince you or you have failed to understand or some combination of both.

> Nick: My apologies. My response should have read "represent the constraint 'bird owners enjoy a hot bath' in a way where you can determine, through deduction, that 'Tony and Joe enjoy hot baths.' "

Currently dbd doesn't enforce/implement constraints. Currently it's scope is limited to representing things in the most general/flexible/systematic manner. Once I have thoroughly verified this, I will proceed to implementing higher level processing of represented things which will be probably be to implement a basic programming language (ie if, then, else, etc) and possibly to move some code into the db itself. Then maybe constraint will become an area of focus. So for now, dbd, by itself, has no way to enforce constraints as Prolog can.

>> Neo: First, [Prolog] refers to three different database mechanisms, this is unsystematic. .
> nonsense. Each mechanism is useful for different things.

I haven't asserted whether or not each mechanism is or isn't useful for different things, just as the hierarchal model is useful for some things and the relational model is useful for other things. What I asserted is that having three different methods of representing things is unsystematic. Why having three different methods of representing things is unsystematic should be obvious.

>> Neo: Second, if everthing can be done at run time, why does anyone first compile and load? Can I just enter your examples at run-time? Can I simply run Prolog and enter like(john, mary) using assert/clause? [Thus far, assert examples didn't add new predicates at run-time, only new parameters to existing predicates defined prior to run-time.] .
> Nick: yes. You can load the entire program at run time. Might be difficult to remember what you typed :-), but you can certainly do it. The earliest prolog interpreters, from what I understand, would simply take the input file and call 'assert' on each statement in it.

:) Well, I tried assert(like(john,mary)) in Prolog without loading any file and it took it and queried it fine. My earlier impression that Prolog can't add predicates at run-time was wrong.

Now I tried the following, keeping in mind that in AI apps, future requirements are unknown.

// We now learn that john likes mary, therefore one might enter: assert(like(john,mary)).

// We now learn that john hates bob, therefore one might enter: assert(hate(john,bob)).

// We now learn that hate is opposite of like // therefore one might enter:
assert(opposite(like,hate)).

We now want to find the person with whom john's relationship is opposite of that with mary. Logically, the query might look like "X(john,mary), opposite(X,Y), Y(john,Z)." However, the problem is that such a query is not possible since it operates on predicates. Now one needs to restructure the orginal data so that the new query is possible. Even after restructuring, the new predicate(s) are not systematically accessible, relatable, etc and this is an endless problem in Prolog. Such does not occur with dbd.

>>> Nick: You have stated that it is 'greater than'. Surely you can see where I drew the conclusion that you were asserting dbd to exceed Prolog. .
>> Neo: I meant it exceeds Prolog in the limited scope of representing things, not in processing of whatever is represented. .
> I would challenge this. Your system is quite good in some ways, exceeding Prolog on a point or two. It is not, however, more able to represent things and the relationships between them.

Again, I am not asserting that dbd's method is more able to represent things, but that it is the most general/flexible/systematic. For instance, it is theoretically possible to represent anything that the relational model can with the hierarchal model, however HM isn't as general/flexible/systematic/practical.

> I can now state this for a fact, given the answers you provided to the 'not' question below.

:) I previously assumed NOT in the sense of filtering things.

> You have repeatedly illustrated the notion that your system can store a bit of information like "John likes Mary" and "Mary hates Bob". However, you don't appear to have a way to say "Mary does not like John" and "Mary does not hate Bob".

(; Represent "Mary does not like John" in a systematic manner)
(create not modify like)
(create mary (select not modify like) john)

(; Find the person that mary does not like)
(; Finds john)
(select mary (select not modify like) *)

(; Represent "Mary does not hate Bob" in a systematic manner)
(create not modify hate)
(create mary (select not modify hate) bob)

(; Find the person that mary does not hate)
(; Finds bob)
(select mary (select not modify hate) *)

You may want read the recent thread titled "Modelling Complex Sentences".

>>> Nick: //Bird owners enjoy a hot bath >>> enjoy( Person, hot_bath) :- owns( Person , bird). .
>> Neo: Again, I can store this constraint (and remaining ones), but dbd doesn't enforce or implement it. Do you want me to represent the constraint or the net effect of the constraint on the current data or both?

> Nick: I want you to represent information in such a way that you can deduce the fact that a bird owner can be expected to enjoy a hot bath.

Ok, but you do understand that while dbd can represent such a constriant, dbd does not enforce/implement it. Did you want dbd to represent the net affect of the constraint on the initial things or not?

Below is dbd's script to represent the constraint "Bird owners enjoy a hot bath":
(create constraint instance *)
(create (it) name (word+ 'bird 'owners 'enjoy 'a 'hot 'bath))
(create (it) condition (create * own (create * class bird)))
(create (it) enforce (* enjoy (select hot modify bath)))

Did I not represent something you desired? By the way, can Prolog create, select, delete, update its constraints just like any other thing that is represented? (Actually, the above type of constriant does not appear to be too difficult to implement in a systematic manner. And I may attempt it, once dbd's basic capabilities have been verified) Received on Sun May 14 2006 - 23:12:21 CEST