Re: Storing data and code in a Db with LISP-like interface
Date: Sat, 29 Apr 2006 23:10:42 +0200
Message-ID: <4453d64f$0$31640$e4fe514c_at_news.xs4all.nl>
Neo wrote:
[snip positional parameters]
>>>... if one andriod was built using "y x z" and the other >>>with "z x y", the [might] misinterpret each other. >>>Such type of misinterpretation would not occur if the >>>andriods were built with dbd.
>
>>Ah! A change of scenery: we now have /two/ droids wanting >>to communicate, and it looks like your solution to this >>is straight-forward sharing of data - which means they need >>share a common data-structure. This would mean ad-hoc >>'create' (SQL-DDL.create) is out.
>
> :) Not necessarily. Two humans can communicate things even if the
> actual data is stored differently, but the processing algorithms are
> powerful enough to compensate for this. But yes, the more commonality,
> the easier it will be to get two driods communicating initially.
So, SQL-DDL style 'create' is out. How does dbd.create cater for structural consequences (= impacting both droids' knowledge, not just the one in the previous version of the scenery)?
[snip positional parameters]
>>>like (john, mary) >>>hate (john, bob) >>>opposite (like, hate) /// Is this possible in Prolog ????
>
>>Yes, google for MI (meta-interpreters). >>They seem easy, and there is support for >>them in most prologs. >>I am not familiar with them, though.
>
> If you are not familiar with them and can't demonstrate it, then you
> probably shouldn't say "Yes" so quickly.
You are right, of course. Making unchecked claims is bad style.
> probably shouldn't say "Yes" so quickly. And the word "Meta" is a major
> no no in my book. To me it means data that is not stored using the
> system's fundamental data representation methodology and thus is not
> systematically stored, accessible, modifyable, relatable, etc.
>
> http://www.csupomona.edu/~jrfisher/www/prolog_tutorial/3_3.html
> decribes meta-interpreters, however it does not seem directly related
> to the situation here. If you can understand and apply it to the above
> case, please post it.
Not in a practical sense, at least not to come up with code of specific relevance. For that firstly I would need to know more about what your requirements (on 'thing', 'class', 'instance', 'relationship', 'verb', 'opposite') are and secondly probably need to have better prolog skills.
This is another page on
meta-interpreters: http://stud4.tuwien.ac.at/~e0225855/acomip/acomip.html
>>>>... two different methods [were used] to relate things:
>
>>>opposite (like,hate). >>>relationship (john,like,mary). >>>relationship (john,hate,bob).
>
>>Neo, by dismissing implementation strategies >>for the wrong reasons you piss people off who >>do know what they are talking about.
>
> mAsterdam, implementation strategies that are less systematic have less
Less systematic than what? According to which system?
> potential in AI-ish applications because the need to represent/process
> the unknown requires a very systematic method. If the reality of this
> pisses people off, please have them schedule a conference with God :)
Google for her agenda yourself.
>>Are you serious about getting multi-discplinary collaboration? >>What of "OK. I've done my part" didn't you get?
> :)
In an earlier part of this thread, you left this unanswered - maybe an oversight:
Neo wrote:
[snip agreement]
> > Ok, I didn't expect someone familiar with RM/RMDBs/SQL to have such > difficulties with 'create'.
Some of my difficulties originate from that familiarity. DML's 'insert' would be more innocent-looking. 'Create' is DDL: it changes the strucure of the database - alarm bells! 'Create' can be viewed as a catalog-insert.
[snip agreement]
>>>>> [ person (john) ] how does one determine the name of the relationship via code?
>>> >>> >>>> There is no [way], because I did not provide a name for thisrelationship.
>>> >>> >>> It seems there maybe yet another reason. Prolog may not provide a >>> method to determine the function given one set of parameter already >>> specified. Can some experiences Prologer correct me on this? >> >> >> Can you make your statement in a way which is more test-friendly? > > > > Enter the following relationships in prolog: > class (john, person). meaning one of john's class is person > instance (person, john). meaning one of person's instance is john
Are you stating the same fact in two ways or are these two facts?
> Then ask prolog, what is the relationship between john and person; and > vice versa, what is the relationship between person and john. You can > replace john, person, class, instance with other things that make more > sense to you, for instance: > > parent (johnny, john). meaning johnny's parent is john > child (john, johnny). meaning john's child is johnny
This clearly looks like you are stating the same fact in two ways - so I am going to assume that.
To prevent redundant solutions you can have one of them as ground fact, the other one as rule.
--------------neofam.pro part 1
has_parent(johnny, john). % meaning johnny's parent is john
has_parent(johnanna, john). % meaning johanna's parent is john
has_child(Parent, Child) :-
has_parent(Child, Parent). % to infer that e.g. john's
% child is johnny
sibling(S1, S2) :- % bonus :-)
has_parent(S1, P),
has_parent(S2, P),
S1 \= S2.
I had to (for now arbitrarily) choose which one to see as basic and which one as derived. That is a choice often coming up, I don't think it is a prolog-specific one.
> Then when prolog is asked, what is the relationship between john and > johnny, it should respond similar to "john's son johnny" and vice > versa.
It would have to know (be told or have the rules to infer) that johnny is male and that male children are sons.
> Here is how to do it in dbd: > > (create johnny parent john) > (create john child johnny) > > // Following displays parent. > (msgbox (& (select verb instance *) (select johnny * john)) ) > > // Following displays child. > (msgbox (& (select verb instance *) (select john * johnny)) ) > > In dbd, one can also represent the relationship between verbs, ie > parent and child as > > (create parent reciprocal child) > (create child reciprocal parent)
Are these two dbd.things or alternate formulations for one dbd.thing?
> Dbd's Food Judge Example C, relates like and likedBy similar to above, > thus when using the createWRR (create with reciprocal relationship > also), and user enters "(createWRR john like tomato1)", db > automatically creates the reciprocal relationship "(create tomato1 > likedBy john)". There is a query later that uses likedBy to find out > all the people who like tomato1 via the following query: "(select > tomato1 likedBy *)". Note the Food Judge Example C is posted in > response to master Prologer Alvin. > > >> Do we have the same concept of "thing"? > > > > Unlikely, my concept of thing is the most general possible. > > >> I have a hard time seeing a category as a thing. > > > > Your concept of thing is more limited than mine.
Yep.
>>> A relationship is just another thing that is represented in the dbd. The following displays "class": (msgbox (and (select verb instance *) (select john * person))). And the following display "instance": (msgbox (and (select verb instance *) (select person * john))). How would one do this in Prolog?
>> >> >> Why? > > > > So that one can determine the relationship between any two things. > > >>> So that the Prolog solution could answer the questions: what is the >>> relationship between john and person; and what is the relationship >>> between person and john. >> >> >> I'll re-ask: for what purpose do you need to know it? >> Which information need are you satisfying/preempting whith it? >> This would shed some light on what to record. > > > > Imagine an andriod is introduced to a group of humans. The droid is > told john's girlfriend is sally, sally mom is martha, martha's sister > is ellen, etc. Later when the droid happens to meet john and sally > together, it can query the relationship between the two, tailor the > conversation for them or make better sense of things in context of the > fact they are related as girlfriend/boyfriend :)
Nice scenery.
--------------neofam.pro part 2
human(john). % not needed for the specifically human(sally). % stated information needs. human(martha). human(ellen).
boy(john).
girl(sally).
has_mom(sally, martha).
has_sister(martha, ellen).
has_boyfriend(sally, john).
has_girlriend(Boy, Girl) :-
girl(Girl),
boy(Boy),
has_boyfriend(Girl, Boy).
--------------------------
?- has_girlfriend(Who1, Who2).
Who1 = john
Who2 = sally ;
No
Could you give a more specific situation where the droid would need "thing", "class", "relationship" or "instance"? Received on Sat Apr 29 2006 - 23:10:42 CEST