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

>> Tony has a dog [named fido] and a bird [named tweetie]...
.
> I find it curious that you chose to implement 'Joe owns Polly' but not 'Joe owns a Bird'. Not sure why. However, it is a moot point. Given what you have illustrated of your language, the query needed to determine that 'Joe owns a bird' is simple, right?

:) 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. In Prolog, an atom and it's name are basically inseperable. Thus it can cause the following situations:

1. Things that are unnamed or whose name is not known leads to bogus names similar to "no_name", "unnamed", "unknown", "a_bird", "bird", etc. Now the andriod will think a thing's name is actually no_name unless additional rules are added. If handled as such, what if droid actually encounters something named no_name? And how to handle additional unnamed things? no_name2, no_name3, ...? Supplying values for missing information leads to N-valued logic and is a no no as described by C. J. Date in Chapter 20 of his book "Intro to Db Systems", 6th Ed.
2. While an atom can have multiple names, an atom's first name will be represented differently than its remaining names, thus it is unsystematic.
3. Two atoms can't have the same name so the atoms for cat and person named mary might be mary_cat and mary_person and this leads to redundant data between the name of the class and name of things. I won't explain the pitfalls of redundancy as volumes have been written on it already with respect to data mgmt.

Dbd does not have these problems. In dbd, a thing can 0 to many names and they are represented/manipulated the same as any other thing that is represented. In fact, dbd even represents each symbol (a, b, c ...) the same as any other thing and while each symbol may be referenced many times, each symbol is represented just once, just as other things.

>> Did you want me to represent the actual constraint "Bird owners enjoy a hot bath" or the net effect on the data which would be that "Tony and Joe enjoy hot baths".
>
> very much so.

The question had an OR in it, so I still don't understand your intention. If you meant both, I can represent the net effect on current data and store the constraints but dbd itself does not enforce/implement the stored constraints on new data.

>> Neo: .. but can [Prolog] accept new things (facts, relationship, and functions) at run time or does one need to update the original source file, recompile and then run?
.
> Prolog can accept new things at run time, without opening up the file and recompiling. (I believe mAsterdam demonstrated this). It is simply the use of the 'assert' predicate. This is one of the key aspects of Prolog because the language was originally designed to be a system for capturing knowledge from unstructured data (like text documents) and be able to produce a logical body of knowledge from it, a body of knowledge that can be queried and consulted. Therefore, the system was designed to 'teach itself' things. The newly learned items were added to the body of knowledge and inference using the 'assert' predicate.

While it does seems Prolog can accept new parameters for functions/predicates defined in the original source file that is compiled and loaded, mAsterdam demo of assert/clause [?- assert(thing(relationship(john, hate, bob))), clause(thing(Thing), true).] didn't allow me to determine if Prolog can add predicates at runtime since the predicates relationship and thing were defined in source file prior to compiling and loading them.

According to the manual I have "SWI-Prolog offers three different database mechanisms. The first one is the common assert/retract mechanism for manipulating the clause database. As facts and clauses asserted using assert/1 or one of its derivatives become part of the program these predicates compile the term given to them. retract/1 and retractall/1 have to unify a term and therefore have to decompile the program. For these reasons the assert/retract mechanism is expensive. On the other hand, once compiled, queries to the database are faster than querying the recorded database discussed below. See also dynamic/1."

First off, when it refers to three different database mechanisms, this is unsystematic. 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?

>> Neo: ... Let me restate what I have asserted before: dbd provides the most general/flexible/systematic method of representing things.
.
> Nick: ...the statement 'dbd provides the most X' means that other systems provide less 'X' than dbd.

Yes, dbd provides a more general/flexible/systematic method of representing things than Prolog, LISP and RM; or any other methodologies that is implemented on PCs.

> Nick: In other words, you have not stated that dbd is 'greater than or equal to' the KR capabilities of Prolog and Lisp.

That is true. I have not asserted dbd is 'greater than or equal to' the KR capabilities of Prolog and LISP. In fact, I have agreed that whatever data Prolog, LISP and RM can represent, they can process much better (for now).

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

:) Yes, I can see. I meant it exceeds Prolog in the limited scope of representing things, not in processing of whatever is represented.

> Nick: ...you are clearly intending to exceed the collection of 'data' and move into the storage of 'knowledge.'

Eventually, but not until I have thoroughly verified dbd can represent anything in a very general/flexible/systematic manner.

> > Neo: 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
.
> Fascinating assertion. When you 'extended' your examples, you did so knowing that dbd already implemented a particular, quite uncommon, requirement.

Yes and no. I know that dbd can represent anything in a systematic manner. Once I found one of Prolog's weakness, I trailored the next requirement to show it.

> Had I been aware of this requirement, the first implementation of the Prolog
> app would not have needed restructuring.

Ah but, exact requirements are not known in advance in AI-type applications! Only general ones, like be able to represent/process anything.

> That you are able to create an example that shows something to be 'superior' by playing to its strengths, when the person you are discussing the issue with is not aware of those strengths, is a simple game that illustrates very little to me.

Yes, there is a catch-22 situation here. Without actually explaining dbd's data model (which I prefer not to at this time), how else can I demonstrate it's method is the most general/flexibile/systematic. And I can't demo it's inferiority at representing things because it isn't.

> Now that you have made it clear that you wish for the application to recognize and
> respond to the 'relators', .

This was implied when I said represent things, which includes relators :)

> I can easily create Prolog apps that do this let you respond, in the other thread, about why you consider this ability to important.

So now that one restructures the Prolog data as:

f2(x, f, y).

I would then tailor the example to deal with f2. Then one might restructure it as:

f3(x, f, y, isA, f2).

I would then tailor the example to deal with f3. This would go on until one would realize that dbd's method of representing things is more general/flexible/systematic as it is impacted little to none.

>> Neo: 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.
>
> 'Not' is part of the logic.

Whether NOT is or isn't part of logic, doesn't have much bearing on the ability to represent things in a general/flexibile/systematic manner.

> These are not queries. They are statements of fact... bits of knowledge that you need to store and retrieve and use for deduction. If you cannot store a relationship that understands 'not', then you may want to revisit your language (or, even better, read about the conceptual foundations of Knowledge Representation, as I continue to urge you to do).

It isn't a matter of being able to store NOT or queries with NOTs, but a matter of processing things that are NOT as specified. For example, suppose john likes mary and sue. Currently dbd can recall all the things that john likes (ie mary and sue). To NOT include mary in the result set requires some type of filtering/processing. Implementing the NOT function doesn't have anything to do with a data methodology's ability to representing things flexibily/sysematically. When implemented, it may look like the following:

(select john like (NOT * mary))
(NOT (select john like *) mary, barb, sally)

> //Tony has a dog and a bird
> owns(tony,bird).
> owns(tony,dog).
>
> //Joe has a bird
> owns(joe,bird).
>
> //Mary has a dog
> owns(mary,dog).

If the dog's name is actually dog, and the bird's name is actually bird, then the above is fine, but I think you really mean a bird who either doesn't have a name or it is unknown. If one wanted to classify them, it would look like dog(dog) and bird(bird) which seems strange unless those are their actually names. And would the second unnamed bird/dog be named bird/dog also?

> //Bird owners enjoy a hot bath
> enjoy( Person, hot_bath) :- owns( Person , bird).

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?

As I have stated previously, currently Prolog, LISP and RMDBs/SQL can process what they are able to represent, to a much greater degree than dbd. Received on Wed May 10 2006 - 20:50:45 CEST