[Aiml-programr-developers] Activity diagram, explanation of the Graphmaster etc... (long email)
mauro at cicio.org
mauro at cicio.org
Tue Sep 11 02:42:45 EDT 2007
Hi there,
Great work, I thinks it sums up pretty well and briefly the great
amount of docs of the ALICE group. I strongly suggest that you resist
the temptation to rewrite it all!!! ;-)
Of course the current version of pR is based on the same docs and the
same readings, so it _should_ work all right. Why "should" and not
"does"? Because it is very likely that in the hurry to have something
working for Tiresia, things became less and less AIML specification
compliant.
Programming is fun, so the sooner we start coding, the better.
A good test suite frees us from the need of a precise design.
Of course we should have a fairly good idea of what we want to do, but
I believe this is already there for the three of us.
If you think so to, we should find the quickest path to the coding :-)
My suggestion follows.
As you know, Ruby has a "duck typing": if you behave like a duck, you
are a duck!
If pR behaves like an AIML bot, than it is an AIML bot.
What I want to say with this?
One interesting, and fun, way to proceed is to look for tests that pR
doesn't pass and fix pR. When pR passes all the tests, we are done,
regardless how the internal are implemented (we have the duck!).
Of course though the process of *continous refactoring*, the internals
will also get better and better, and so the design.
Where to start from?
The following tags are said
(http://projects.dottorsi.com/ki/programr/pages/Features)
to be supported in pR and there ***should be tests proving it as well***...
<category>
<pattern>
<template>
<srai>
<that>
<uppercase>
<system>
<lowercase>
<date>
<size>
<bot name="name"> (see notes)
<get>
<set>
<think>
<condition>
<formal>
<sentence>
<random>
<input>
<gender>
<star>
<thatstar>
<sr>
<topic>
<topicstar>
<person>
<person2>
Question: Is this true? Or are the tests too benevolent? How far is
this list from the complete one?
In this sense I believe that the most urgent thing to do is to design
and extend the test list.
Ideally, we want to have the list of tests in the task list and mark
them as done only when pR passes them.
"1 test = 1 task" is a nice way to split the work: anytime we have 30
minuets/1h, we just implement 1 or more tests. They are small enough
units in most cases.
Do you guys agree with the approach?
A question, Nicholas: would it make sense, as a start, just to dump
the list of tests of ProgramD?
What we need is not (necessary) the code, but, for each test:
- TestName
- Challange
- ExpectedReaction
If the ProgramD test suite is complete, than it would give us a great start.
If not, then let's begin with what we have...
In my experience, it has been much easier to go through the ALICE docs
while doing the tests (but I have implemented the first 10 or so
only).
UTF16 and Ruby: not a great thing, you are right.
You found a couple of my recipes on Ruby Cookbook
http://books.google.com/books?id=ANP-fUv3WTYC&dq=ruby+cookbook&pg=PP1&ots=FRREb0KCAR&sig=KOl8HuEws0Pgk8mShEDtwNABe3w&prev=http://www.google.com/search%3Fhl%3Den%26rls%3DGGGL,GGGL:2006-46,GGGL:en%26pwst%3D1%26sa%3DX%26oi%3Dspell%26resnum%3D0%26ct%3Dresult%26cd%3D1%26q%3Druby%2Bcookbook%26spell%3D1&sa=X&oi=print&ct=title
about it, but I am not sure there are gonna help...
I would rather work on the English version first, keeping in mind the
necessity to have modules which must be easy to rearrange (consider
that Tiresia is a project mainly for the Italian language!!!).
I look forward for your answer hoping to begin to code as soon as possible :-)
Ciao,
Mauro
On 10/09/2007, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> Guys,
>
> As promised, I've included images (and source there-of) as attachments
> to this email.
>
> I strongly suggest you read the "formal" AIML specification found here:
> http://www.alicebot.org/TR/2001/WD-aiml/
>
> Once you've digested and understood this document then you've pretty
> much got all the information you need and we will only (only?) have to
> worry about implementation of the standard. The summary I've written
> below is to be read as well as the standard and I hope it gives either a
> good introduction before reading the standard or clarifies things.
>
> Activity Diagram for a Request
> ---------------------------------------------------
>
> (BotLifecycle.* - UML on the left, example text on right)
>
> There are three broad steps in the life-cycle of a request to an AIML bot:
>
> 1. Normalization - prepare the raw input into a path to be fed into the
> Graphmaster.
> 2. Query the Graphmaster - search for a <template> using the normalized
> path as input.
> 3. Interpret / return the contents of the resulting <template> - output
> something coherent and update any data-stores.
>
> It is important to note that the Normalization process is very
> English-centric. I'm assuming that different languages would be
> best-normalized in different ways. As a result, it would be great if we
> could implement the normalization process as some sort of work-flow
> where steps could be re-arranged, added, removed and modified to the
> requirements of the language of the bot (for example, certain languages
> [such as French or German] might normalise by replacing accented
> characters with their unaccented version). An additional consideration
> is string encoding. Mauro: how good is Ruby's UTF16 support? It'd be
> great if Ruby had something as simple as u"My UTF encoded string in
> Python (notice the leading u)" to denote a UTF encoded string. I seem to
> remember UTF support was a problem/pretty poor?
>
> The querying of the graphmaster is explained below so I'll skip it here.
> Suffice to say that this is one of the cleverest parts of the bot AND I
> think the bog-standard graphmaster algorithm could be improved by making
> it more capable (but I think we should concentrate on getting the plain
> ol' graphmaster working properly before adding "features").
>
> The interpretation of the XML contained within the <template> tag is
> also clever but very easy to unit test as the specification is very
> clear about how the tags are to work. As an aside... we can use the
> <script> AIML tag to embed Ruby code into the <template> to be
> interpreted at run-time. Cool eh?
>
> Graphmaster
> ----------------------
>
> (Graphmaster.* files [created with graphviz])
>
> First of all, take a look at the picture.
>
> Now, I did write a long and complicated explanation of the graphmaster
> at this point. But when I checked it against the description in the AIML
> standards document I discovered my version was so long and the standard
> was so well written that I suggest you just skip to:
> http://www.alicebot.org/TR/2001/WD-aiml/#section-pattern-expression-matching-behavior
>
> It would be a good exercise to try to follow the route of the paths in
> the picture of the simple graphmaster I've attached:
>
> "Hello Mauro <that> * <topic> *"
> "Hello Ben <that> Hi ALICE <topic> *"
> "What is your favourite file <that> * <topic> *"
> "I live in Italy <that> * <topic> *"
>
> (Hint, the first two match the same route).
>
> Put simply:
>
> * Order of precedence is: "_", "word", "*".
> * Match a route of child nodes (starting at root) until a <template> is
> found (hint: you'll always find the path "* <that> * <topic> *").
> * Interpret and pass back the template.
>
> I'll write up the pseudo-code of Program#'s implementation (encapsulated
> within the Node.cs class) in a later email (otherwise this email will go
> on for pages).
>
> Also, I'm planning the tests for ProgramR. I'll put my thoughts in
> another email - again, so I don't end up clogging the list with emails
> longer than "War and Peace" :-)
>
> As always, comments, suggestions and criticism are most welcome, :-P
>
> Best wishes,
>
> Nicholas
>
>
>
>
>
>
>
> _______________________________________________
> Aiml-programr-developers mailing list
> Aiml-programr-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/aiml-programr-developers
>
>
>
More information about the Aiml-programr-developers
mailing list