[alicebot-archcomm] The Value of a Standard for AIML

[Noel Bush]

What is the real value of a standard for AIML?  Why should we donate our
energies to developing and maintaining this standard?  What relevance
should we expect the standard to have in the world?  Is our process for
maintaining and developing the standard optimal?

These questions and more considered in.....

THE FOLLOWING....

1. What is the real value of a standard for AIML?

1.1. A standard for AIML has potential value for implementors, vendors,
consultancies, and authors.

DEFI*: Implementors are those who create AIML-oriented bots.

DEFI: Vendors are those who sell AIML-oriented bot-related applications.

DEFI: Consultancies are businesses that do "bot customization".

DEFI: Authors are people who create bots for pleasure and/or profit.

(* "DEFI" is short for "definition", in honor of the time-tested
practice of needless obscure abbreviations. ;-) )

1.1.1. For implementors, a standard is valuable because it provides a
means of deciding when work is "done".  Being compliant with a standard
means that a list of particular functions are supposed to be supported
by an implementation.

1.1.2. For vendors, a standard is valuable as a selling point when
describing quality to customers.  "We use an x-compliant engine" means
that customers can check the functionality of a system against an
available description (well, if the standard is available).

1.1.3. For consultancies, a standard is valuable when planning training,
choosing tools, organizing processes, and selling services to customers.

1.1.4. For authors, a standard is valuable because it means the time
needed to learn how to use the technology can be predicted.

(1.1.) There are plenty of other reasons that a standard is valuable for
each of these categories, and probably several other significant
categories.

1.2. The value of a standard for AIML can be measured by looking at the
cost of a change in the standard for many of those who value it.  To use
the same examples as above:

1.2.1. Every change to a standard definitely means additional work for
an implementor.  The amount of work attached to a change in a standard
may vary wildly from one change to the next.  I.e., the cost is
definitely positive but not predictable.

1.2.2. For a vendor, every change to a standard weakens the usefulness
of the standard.  A vendor will cease to use standard compliance as a
selling point if it is widely known that the standard itself changes
rapidly.  The cost of a single change may be quantifiable; the cost of
too many changes may be a significant loss in investment when it becomes
necessary to switch to a more stable technology.

1.2.3. For consultancies, every change to a standard strikes a point
against using it further.  Not only is the internal education
requirement a factor, but the credibility with a customer comes into
play (as with vendors).  Good consultants will not recommend that their
clients adopt a standard that changes too frequently.

1.2.4. For authors, every change adds more learning time and increases
the likelihood that skills learned in one environment won't transfer to
another.

(1.2.) Again, these are just examples from a much longer list that could
be drawn up.

1.3. The value of a standard for AIML can be viewed in terms of the
purpose the A.L.I.C.E. AI Foundation.  If the "standard" changes too
rapidly, or if it is clear to the public at large that the process for
changing it is ill-defined, then a key pillar of strength for the
Foundation is seriously weakened.  "Maintaining a constantly-changing
standard" is "Maintaining an oxymoron".

2. Why should we donate our energies to developing and maintaining this
standard?

2.1. That depends on who we are.  If we are making our money from
AIML-related activities, or hope to do so, then depending on which of
the above categories we fit into we have obvious reasons.  If we are
working for the good of the Foundation, or working out of some other
interest in this technology, then we may also have reasons to support
standards work, although the likelihood is somewhat diminished.

2.2. But whoever we are, I think that a key factor in our continued
participation in the Architecture Committee should be an expressed
desire to support this standards process, and an attitude of seriousness
about it.  If the matters related to a standard are matters that we are
not deeply personally invested in, then this Committee is the wrong
place for us.

2.3. We should also expect that the Foundation's credibility will be
burnished with every obviously well-considered move with respect to the
published standard (and tarnished with every obviously hasty move; 
another way of saying this is: mistakes are allowed, but rashness
isn't).

3. What relevance should we expect this standard to have in the world?

3.1. QUITE A LOT IF:

* it has a sensible and publicized change control process.
* it is precise in specifying its scope and thorough in addressing all
matters that fall within that scope.
* it is publicly promoted and supported in a responsible way by the
members of the committee

3.2. NOT MUCH IF:

* its change control process is flawed.
* it is ambiguous in scope and leaves some matters up to be
"understood", and everybody seems to be happy with that.

3.3. A more pressing point might be this: Most bots are self-contained
applications.  They are not sharing AIML from different locations, and
so sharing a common data format with other bots in the world is not
really the topmost issue.  Reusability of AIML is a goal, not a fact of
the present day.

The relevance of a standard is actually a point that the Foundation
needs to sell *more*.  The world has not reached the stage yet where it
is patently obvious to everyone that they ought to abide by the AIML
standard as published by this group.  We may have a "vision" of this
central importance, as well as of networked sharing and other
applications of AIML, but we must understand that that vision is not
explicit, and is probably not going to have much success if the notion
of a standard is for us something that doesn't have a high priority to
begin with.

4. Is our process for maintaining and developing the standard optimal?

Well, I think no.  Each change to the AIML standard should not trigger a
new "version number".  This would be like releasing a new "version" of a
piece of software each time its creator had one new idea.  We already
look a little silly with "AIML 1.0.1".  The implication is that there
can be hundreds of versions of AIML.  The information conveyed by this
version number is absolutely useless.  Changes should be accumulated in
chunks of meaningful size, and the specification itself should proceed
not through "versions" but through different phases "working draft",
"proposal", "recommendation" -- see the W3C for a good example of this.

The process we've defined so far, and the way we've used it, are tending
toward a standard with no standard-ness: one that may change at any
moment (the 30-day "cool-off" really doesn't do the trick), and one
whose path is totally unclear.  As Rich has pointed out, the difference
between AIML 1.0 and 1.0.1 is that <if> was removed....a really
ridiculous fact, in my opinion.  It would be far better if AIML 1.0
stayed in "draft" form for a year or more, undergoing various public
revisions, always with the stipulation that it wasn't final, until it
really was final.  That way its designations make some sense.  Right now
they don't, really.  At some point we'll say that version 1.x.y is the
"real" one....is that the way to inspire confidence in *anyone* who uses
or is considering the use of AIML?