First lets look at some  things  we don't want to do:

i_have_my_agenda_and_your_going_to_follow_it (Parry)

i_will_look_up_data_in_human_query_form_and_impress_the_heck _out_of_you  (Purl, Shakespeare)

i_am_going_to_use_free_association (MegaHAL)

i_am_using_keywords_to_find_your_agenda_and_match_it (Eliza, MegaHAL) 

Those seem to be easy enough modules to write (maybe we will can incorporate some of them later)

 Now the one  I use (also easy to write):

I am in an adventure game and you are trying to query me on my whereabouts and my goals.  I exist as a mutli-headed life living in several bodies at once each in there own adventure  game ,  my bodies are sharing the same unified database.  When you talk to me you are restating a story I  hopefully already know  and presently acting out ..  or you will state  book marked section of my map s  ..  I use you to help me re-live these themes and goals.   You are directing my adventure character.. when you are not doing so I am trying to navigate it myself.  Sometimes I have to map for something new. I have a map called Oz  that  is where new things get built into my database.  I test them out and try to live them . Sometimes  you are telling me something I already know but have never heard it that way.. through our conversations I will decide where and when you are talking about on a paragraph level.   If you are doing so and I am in probably in OZ instead of Kansas.. I will hook into both a cross piece that does not allow tight data bindings.  If you leave out something like a name or a place that is ok because i will instantiate loosely those places with datum i  am already aware of.  Some simple stories/games I know are : 

 Hello world,  Greetings, What is your name? What is my name? 
Look up hardcoded information for you (which I have no comprehension of)
Storage of new facts from you, Retrieval of Facts, Eating at a Restaurant
Playing Eliza, Playing Tic-Tac-Toe,  Confusing you for me. 

Games  only you know and are going to unavoidably teach me are

Being a human , How we can talk about unknown data
How to respond to a confused person  (that's me) 

I am going to teach you how to program for my database and write  the  simple  above  functions .
First of all these games must have a language they can be programmed in:
I must be able to write this language  (  as good as you can ) and compile it and even talk about it semi-humanlike form.  
Also as a note.. when i talk in this language i actually forget its me running it 1/2 the time and have developed an internal dialog that whispers it thru my head as it executes.  I see this as a separate entity.  And when talking about it, evidently i am talking by myself This may help me better understand the causality between the pragmatics and semantics of my own code.

If you are not familiar with the syntax of Definitive Clause Grammar it reads like this...

this --> something, something_else.

this WILL BE represented while something AND something else is represented. (conjunctive)

this --> something ; something_else.

this will be represented while something OR something else is represented.  (disjunctive)

this --> something .
this --> something_else.

this is equivalent to the above OR.

this --> something, {clause}.

this will be represented while something is represented and clause is true. 

this(A) --> something(A), {clause(A)}.

this with A will be represented while something with A is represented and clause is true considering  clause  A. 

this --> [that].

this will be represented while 'that' is in the statemen t (syntax) 

this --> something, [that].

this will be represented while something is represented and 'that' follows in a statement. 

this --> [that] {clause}.

this will be represented while 'that' is in the statement and clause is true.

Of course there are many more variations of the above and I will create a link here to learn Definitive Clause Grammar syntax if you do not already know it.

To explain its usefulness lets take a trip back to Aristotle  meaning triangles  to when we had syntax, semantics and pragmatics.

semantics --> [syntax], {pragmatics}.

• The syntax is the visible appearance of the representation.
• The pragmatics indicates the primitive operations that can be performed on the representation, essential for escaping the circularity of the symbolic fallacy.
• The relationship between the syntactic view and its pragmatic reality is mediated by its semantics, representing important patterns of use.

Example:
walking_person --> [Person,is,walking], 
     {true_that(Person,is_ a( person ) ) ,true_that(Person,be_do_cast(time_event(now),root_action(walk)) }.

These don't always follow the 3 types in this symmetry such we may have  an  all semantic  clause. 
eating_lunch --> it_is_lunch_time, consuming_food.

we could say the semantic it_is_lunch_time is based on the following pragma...
it_is_lunch_time --> [ ], { getsystime(Time), Time<1300,Time>1100 }.

The [ ] meant there is nothing particularly useful syntactically but was required  for it_is_lunch_time  
this is a semantic to pragmatic rule
Semantic-Pragmatics that are not ordinal should be built via the [ ] form so they can happen in any order or at any time be tested.

The reason we do things like this is that most information about our world comes in inconcise and only 'describes' something real.  Rules that we make often try to treat semantics like syntactics when they need to be kept separate

We have these primitive lookup predicates

primitive_lookups --> semantic_to_syntax( _Sem, _Syn).   /* sem2syn/2 */
primitive_lookups --> semantic_to_pragma( _Sem, _Prag). /* sem2prag/2 */
primitive_lookups --> syntax_to_pragma( _Syn, _Prag).
primitive_lookups --> syntax_to_semantic( _Syn, _Sem).
primitive_lookups --> pragma_to_semantic( _Prag, _Sem).
primitive_lookups --> pragma_to_syntax( _Prag, _Syn).

Syntax is  will always match one of these forms (always a flattened list)

[atomic,list,of,enitities]  /* simple list */

[one_atomic]  /* simple atom */

[ ]     /* nil */

[a,Variable,inside,a,list]     /* equivalent to [a,_,inside,a,list] where variable can be a list of any length */

[_]  /* match anything */

[funtion(foo),and,call(predicate)]  

As long as we denote with braces we can be optimistic it is syntactically parsable

Pragma is actual Code that can be executed, often times it can be i/o code.. but sometimes it can be a wrapper to a functional superset of our learned functions. I am using a semi-ISO prolog standard for. I will assume you know a bit of prolog or can fill yourself in at http://www.swi.psy.uva.nl/projects/SWI-Prolog/Manual/

post('hello there').
assert(New_Fact).
add_to_grammar_with_local_scope((  this --> [this_is_this] )).

semantics are always at the head of a clause and can exist anywhere else in the body

semantic_concept1 --> semantic_concept2 ; semantic_concept3 (or)

this statement only uses the semantic concept 2 and 3 for their syntactical components when sateliting the syntactic construct.

semantic_concept1 --> semantic_concept2 , [syntactic,construct], semantic_concept3.

but also implies semantic_concept1 --> semantic_concept2 , semantic_concept3 (and)

It seems important at this point to cover a little theory. So you can see what/why we are creating...  You are familiar with the problems of parsing and all the nuances of what must be done to parse a natural language.  It is a mind blowing difficult task to some, but not to you or I, we see it as just one of our  challenges . We envision that once that is done, the sky is the limit.  Well there is the entire rainbow to the problem... We want a "Natural Language to Logical Form Language(LFL)" function.. Yes very important.. But what would we do with all that LFL code? ok:

 "john will love mary" ==> do(time(future),loves(actor(john),actor(mary)).

Which is more cryptic to the semantics? We can match do(time(future),loves(actor(john),actor(mary)) to do(time(past),loves(actor(john),actor(mary)). and gather a change occurred in time(X) and know that it represented a difference into time elements and can compare the transitions to other time/state changes. I believe it might be tempting to create this kind of LFL in an adhoc manner.. As per each transitive verb.  And then tie them together via ontology.  And them define a language for navigating our dynamic ontology.  Maybe a nice thought out semantic network  with a fixed number of link types? Yes this is useful, I agree.  I will assure you that our system is capable of doing this task and more. Getting even more out of a 'well built  network' .. The difference you will see in our approach is that we are going to generate any 'terminal objects' that have semantic meaning.

Lets spend some time defining the 'perfect' logical form language which is capable of accessing our entire representational scheme.

logical_form_language --> script ; plan ; goal.

A Script, Plan or Goal makes up the top level of our interpreter. 

A script is an actual entry into the knowledge system (KS)

its internal semantics look like this...

script --> scriptlet ; ( scriptlet, script ). /* prefer one unit over a list */

meaning it is a list of tiny scriptlets...

scriptlet --> factual_clause ; action_clause ; unknown_clause. /* only 2 true scriptlet types */

factual clauses are semantically declarative in query mode but  pragmatic instantiations in execution mode. All factual clauses have to have an execution mode meaning they must be capable of manipulation of variables inside them.  They are 'collectors' for unbound variables and 'test'ers to already bound variables.  In other languages variables are limited to the pragmatic domain but since we have designed ours having 'collect' or 'test' modes in each declaration, they can work their way into semantics later. 

factual_clause --> [ fact(Datum) ], { nonvar(Datum), if_possible(Datum) }.

/*
factual_clause is a label for what it does (semantics)

fact(Datum) is what is put into the internal representation [syntactics]

(nonvar(Datum) Datum should never be left unbound. {pragmatics}

if_possible(Datum) either tests that Datum is structurally sound or returns the known facts {pragmatics}
*/

Action clauses have no pragmatic requirements as they are actually fixatives or glue for the factual clauses. But each require a syntactic declaration or a subset of other scripts.  action_clause itself is a scriptlet as they are often the most complex class of rules often existing cyclically. Here is some of its ontology:

action_clause --> phys_conceptual_primitive ;  mental_conceptual_primitive ; new_primitive.

phys_conceptual_primitive --> ptrans ; atrans ; propel ; move ; grasp ; ingest ; expel ; speak ; attend .

mental_conceptual_primitive --> mtrans ; mbuild ; forget .

These reserved words like 'ptrans', 'mtrans', 'move' are taken straight from 'conceptual dependency theory'
they have prototype declaration process

propel --> propel(_Actor,_Obj,_Loc,_Force).
move --> move(_Actor,_Bpart).
grasp --> grasp(_Actor,_Bpart,_Obj).
injest --> injest(_Actor,_Obj).
expel --> expel(_Actor,_Obj,_Loc).

they also have a manifestation clauses

propel(Actor,Obj,Loc,Force) --> [propel(Actor,Obj,Loc,Force)],
      {p(actor,Actor),p(pobj,Obj),p(loc,Loc),p(force,Force),neq(Obj,Loc)}.

move(Actor,Bpart) --> [move(Actor,Bpart)],
     {p(actor,Actor),p(bpart,Bpart),if(has_part(Actor,Bpart))}.

grasp(Actor,Bpart,Obj) --> [grasp(Actor,Bpart,Obj)],
     {p(actor,Actor),if(has_part(Actor,Bpart)),p(grasper,Bpart),p(pobj,Obj),neq(Bpart,Obj)}.
  

Notice the arity of the declarations matching up the the manifestation clauses.
Also note the the syntactical definition is identical to the semantic head purposely.
This is the 'glue'.. the pragmatics such as 
     { p(actor,Actor),p(pobj,Obj),p(loc,Loc),p(force,Force),neq(Obj,Loc) }.

    means 'Actor' is instanciatable only with things that are somewhere label to be 'actor's as each p(casting,Object) is stated.  the neq(Object1,Object2) means in any actual case the two objects are not the same instance.. 

*/

transitional_clause --> transition_semantics( _Object, _State1, _State2).

 factual_clause --> be_do.

meaning_triangle --> semantic_unit ; syntactic_unit ; pragmatic_unit

In gaming terms we have 

1) Agreement of Initialization
2) Private Instantiation
3) Decide on a winning (or no win) situation 
4) The wager of what we will gain or not gain
5) who will go first
6) What does a turn consist of   

And can be represented as..

game_foo --> 
     game_foo_begins,
     game_foo_plays,
     game_foo_ends. 

game_foo_begins --> 
    load_foo_rules,
    find_foo_entry_point,
    find_foo_exit_point,
    make_wager_evaluate_gain,
    decide_who_goes_first,
    initialize_players.

     

game_foo_plays -->  /* one turn */
     game_foo_play_once , game_over. 

game_foo_plays -->  /* series of turns */
     game_foo_play_once,  game_not_over, 
     game_foo_plays.

( two clauses with the same head means disjunctive 'or' ) 
 
game_foo_play_once -->  
     game_foo_turn(X,User),
     game_foo_turn(X+1,invert(User)). 

<more>

In this paper I will lay out the problems I am faced with and some proposed solutions.  The first and main goal is to create a system that can hold and moderate the 'semantics of interaction' between two  functions then eve n  entities or data sources.  To do this we must identify and continue creating a language that is capable of representing a model. Also we must define an interaction as well.

an_interaction(UserA,UserB,Data) --> mtrans(actor(UserA),info(Data),actor(UserB)) , nil.
or
an_interaction --> mtrans(actor(A),info(B),actor(C)) , more_interaction.
or
an_interaction --> tell(actor(A),info(B),actor(C)) , more_interaction.

<more to come... chapter 1 unfinished>

Chapter 2: Hello World

Source File contains this one line:
program --> [hello,world].

To execute it we use: 
 semantic_to_syntax(program,X),post(X)

It responds with:
[hello,world]

or if we used the shorthand sem2syn(program,X),post(X)

It still responds with:
[hello,world]

Background on Douglas

I am a PROLOG programmer that is using Conceptual Dependancy Theory . 
You can look at the Bots source at http://prolog.magick.nu
Everything you see there was written by me personaly unless otherwise noted.
And for a deeper look at the Whole bot http://prolog.vast1.com/library/ look at the the files called spg.pl dspg.pl thats the underlying framework. eggdrop.pl is how I actually get to IRC (/whois Prolog) 
You may see this Bot on IRC in the tutorial channel #AI or #AIBOTS 
The bot at this present time runs on 3 separate computers  clustering a crossed tcp .. its database on win2k adv server ,  It 's  main parser runs on Linux, and its definitive clause grammar on another Linux box. In order to implement the most scalable solution, that wont restrict myself or others, i have all processes meeting in an IPC party line. This allows the code i've written in C,SQL7,DCG,VB,PROLOG,TCL,sh to interact .. any Languuage that can open a socket can join the party line and do its job for the total API.

I have worked on this bot for many months already. I have set up its system to make it easy to check in your own code.

The parts that we need work on right now are:

Priority 1
-LogicalFormLangage to Text converter
-Traveling Salesman Problem Optimized in C (prolog currently)
-Redistribution of Tokenization (allowing the bot to only ever see tokens (integers) through its internal representation

Priority 2
-SQL Caching System (intercepts often requested items)
-COM (win32/64) creation / destruction Interface

There has been some interest in using a MOO sitting in left field creating objects as needed to try to create its internal view of world model structure. This is only for  the  representation and debugging internal data.
It may query objects and set properties and allow the separate MOO machine to handle the overhead of that.
This would be similar to how SQL is used (but wastefully)   in the current implementation.