===================================================================
VENDOR OPTIMIZER AND ELICITOR: AUTOMATED SELECTION OF VENDOR ORDERS
===================================================================

Proposed SOW for Year 4

Date of last revision: 10/28/2007

We describe the tasks involved in the development and evaluation of
the learning strategies related to Vendor Optimizer, and discuss the
related integration and version-control issues. The focus of this work
is new learning techniques; it does not involve work on optimization,
since we have already build the related optimizer during Year 3.


----------
Main tasks
----------

() We will integrated Vendor Optimizer with Space-Time Module. This
optimizer will run after each schedule optimization; it will identify
the best possible vendor orders, and determine the changes required
for converting the current orders into the best possible orders.

() We will implement an optional mechanism for placing vendor orders
automatically through the web-based vendor portal, so that the user
will be able to accept all suggested order changes with a single
click, rather than placing them manually. The user will also have an
option to select specific changes, and invoke automated placement of
the selected changes.

() We will integrated Vendor Optimizer with Richard's NLP mechanism
for parsing the order-related e-mail messages, which will enable the
system to keep track of the placed orders. It will also enable the
system to learn about available vendors, items offered by each vendor,
and their prices from e-mail messages. Richard has already developed
the related NLP mechanism during Year 3, so this work will not require
significant investment of his time.

() We will extend the related elicitor, which will generate questions
about unknown vendors and their prices; however, we expect that it
will generate only a few questions, since the system will extract most
relevant information from e-mail messages.

() We will build a new elicitor for learning the correspondence
between specific conference needs and offered items. For example, it
will be able to learn which meals can serve as lunch, and which
services fulfill the security needs. It will enable the system to
start with no knowledge about vendors, item types, and their matches
to conference needs, and obtain this knowledge through elicitation.


-----------
Integration
-----------

The main modifications related to the new functionality and its
integration with the Radar architecture will be within Space-Time
module. We expect that we will need only two modifications affecting
components outside Space-Time Module, and that we will be able to do
most of the related implementation ourselves.

First, we will need to implement a mechanism for automated placement
of selected vendor orders through the vendor portal. Since we do not
yet have access to the vendor portal, we have not yet developed a
detailed plan of this work, but we expect that we will be able to
implement it ourselves. In the worst case, if we are unable to
implement it, we can test the system without it, by instructing the
subjects to place all suggested orders by hand.

Second, we will need an extension to the current GUI for answering
questions about vendors during the war games. If Andrew is unable to
help with this work, we will implement the related user interface
ourselves. Since this interface is only for training the system, and
not for the use by the subjects during tests, we can implement a
minimal user interface for the "in-house" use.


---------------
Version control
---------------

We will maintain three separate code bases of Space-Time Module,
called "Final Year-3," "Test Year-4," and "Experimental."

FINAL YEAR-3: Version compatible with the Year-3 Radar architecture,
which may include post-test bug fixes and minor software extensions,
but no new functionality; it is currently available for the download
at www.cs.cmu.edu/~eugene/Radar/Code/st14-bin.zip.

TEST YEAR-4: Version compatible with the Year-4 Radar architecture,
which will include software-engineering extensions required for Year-4
integration, and possibly functionality extensions suggested by
Jordan, but no new experimental functionality related to Vendor
Optimization; it is currently identical to "Final Year-3."

EXPERIMENTAL: Version with all new functionality related to Vendor
Optimization, which will not be part of the official Year-4 tests. We
do not yet have a working version with the new functionality, so it is
not yet available for the download.