[alicebot-archcomm] topic attribute

[Noel Bush]

I'm glad you like my suggestion.  I've decided to comment on your rant.
:-)

> I took the following tag examples (some deprecated) from the AIML 1.0
> table... and I wonder if every instance of the word "name" below means
> the same thing, or are some "name"s different animals from other
> "name"s?
> 
>      <name/> (deprecated)
>      <condition name="XXX" value="YYY"> </condition>
>      <get name="xxx"/> 
>      <getname/> (deprecated)
>      <li name="XXX" value="YYY"> 
>      <set name="name"> </set>
>      <set name="topic">  </set>
>      <set name="XXX"> </set>
>      <topic name="XXX"> </topic>
>      <if name="XXX" value=YYY"> </if>

Well, if you throw out the deprecated items, then 'name' as an attribute
means the same thing everywhere except in topic, where it means exactly
the opposite of what it usually means.  <if> is completely rejected, by
the way.

> This way requires no thinking:
>      <name/> (deprecated)
>      <condition variable="XXX" value="YYY"> </condition>
>      <get variable="xxx"/> 
>      <getname/> (deprecated)
>      <li variable="XXX" value="YYY"> 
>      <set variable="_botname"> </set>
>      <set variable="_topic"> </set>
>      <set variable="XXX"> </set>
>      <topic value="YYY"> </topic>
>      <if variable="XXX" value=YYY"> </if>
> 
> Reasons include: 
> 1) Consistency between naming 'containers' and 'things that 
> are put into
> containers'.

<set name="rant">red hot</set> does *not* put "red hot" into a
"container" "called" "rant".  It associates two things, "rant" and "red
hot", with each other.

The sense of "predicate" in AIML is not the sense of "the object of a
sentence" that you mentioned.  It is the sense of "predicate" used in
first-order logic or predicate calculus.  One way of looking at what an
AIML predicate is is to say that it is something like

Pnv

where what P means isn't really specified (just an association), and n
and v are the two terms of the predicate.  Or, if you like,

P(name, value)

But there is still some discussion going on (at least in my head) about
what the real form of these predicates is, in whatever "ur-AIML" may
underlie AIML.

> 2) The fact that the word "name" comes up in discussions of the
> construction of tags and attributes so much that when we talk about
> AIML, we confuse 'name' (the english word we use to 
> generically refer to
> any thing's title) with ' "name" ' (the title of a type of AIML
> attribute).

Somehow a similar feeling on my part led me to ask about other kinds of
predicates, like those expressed by <get pattern=""/>.  But I think that
the word "name" is appropriate for the first term in the get that we all
know and love.  It may just be that our examples suffer from too often
using the name value of "name", as in <get name="name"/>.  <get
name="favoritefood"/> seems less confusing.  But the point is still that
you are not "getting" some "thing" "called"
"favoritefood"...."favoritefood" is not the name of something;
"favoritefood" is the value of some name associated with some value.

> 3) It (apparently) can have different meanings in different tags.

Only when we consider the deprecated examples.  I would very much prefer
to make those "deprecated" examples "obliterated".

> 4) The syntax <set name="variable-name"> looks a lot like it 
> means "Set
> the variable called 'name' to be equal to the string 
> "variable-name". I
> swear, every time I look at the <set> tag, I have to spend an extra
> second or two to clear that thought out of my head. It's like we
> deliberately switched our Hot Water and Cold Water faucets and we have
> to remember every time we wash our hands that the handles are 
> reversed.

See above.  Not so.  The value of the name attribute is not the name of
a variable.  It is the value of the name term of the predicate.

> 5) (I saved the best for last) When building a bot, "name" should mean
> "The name of the bot". That's what most people will think. 

Except in all other languages than English and German.  :-)

> <superrant>
> It's like AIML goes out of its way to NOT conform to normal 
> programming
> language conventions out of some theory that programming languages are
> hard or intimidating for normal people to learn. But instead of making
> it clearer than computer code, we just made up hip, cryptic, 
> alternative
> names for what should be straightforward concepts. What's 
> wrong with the
> word "variable" or "var"? "Predicate" is such a weird example of AIML
> contortionism: every time I see that word I have to spend a second or
> two to remind myself that it does not mean "the predicate of a
> sentence".
> Sometimes I think the cure is worse than the disease. If it aint broke
> don't fix it. Etc. 
> </superrant>

I don't think that the use of the notion of a predicate is really "hip"
-- I think "hip" is more like the "code now, think later" approach that
produced some of the mess that the world is still trying to recover
from.  I don't think it's "cryptic", either, but I do think it is not
well documented.  I also don't think these are "alternative names
for...straightforward concepts"; I think these are alternative concepts
that are well-grounded in several centuries of thought.

> Out of everyone who participates regularly on this committee, I think
> it's safe to say that I have the *absolute least* computer programming
> experience. I'm a total amateur/dilettante, a hobbyist newbie 
> simpleton.
> Trust me when I say some of this stuff is going to confuse 
> the heck out
> of people. 
> </rant>

I agree that eliminating confusion should be our goal, but not at the
expense of erasing the particularity of the approach.  I don't mean to
suggest that you want to eliminate the particularity of the approach,
and I appreciate your comments as a very good indicator of where we are
with respect to clarity in explanation of how to use AIML.