Issues Raised by the PRODIGY Architecture

• Modularity

  While having independent and complete modules does seem wise from a software engineering perspective, such self-contained units do present a variety of problems. First, the modules must maintain a uniformity in the interface between separate modules. This is accomplished in PRODIGY with its uniform knowledge representation. However, this representation precludes modules taking advantage of differing, more natural (and perhaps more expressive; see below) representations for the individual modules. Secondly, it may be difficult to enable the modules to interact synergistically when insulated from one another. Both articles on PRODIGY (see references) mention the desire for this type of behavior. Finally, Minton discusses the uncertainty of deciding both when to create a module (grainsize) and if a new module is actually the right one (functional decomposition).

• Completeness Requirement for Domain Knowledge

  All domain knowledge is PRODIGY is assumed to be complete. Thus, PRODIGY can not be used in dynamic, unpredictable or rapidly changing environments.

• Expressivity of PDL

  The Prodigy Decision Language or PDL (based on first-order predicate calculus) suffers from a limitation in its expressibility. Chiefly, there is no way to introduce temporal extent. Operators must be applied serially and the effects of operators take place immediately. Secondly, although the use of STRIPS-like operators negates many of its repercussions, this representation is still subject to the frame problem. This occurs when secondary or tertiary effects of operators are not included in the operator add and delete lists. While this implies an oversight in the specification of operators, in practice it is impossible to anticipate every situation in which an operator may be applied in these complex domains beforehand.

• Domains Applicable to STATIC Analysis

  The STATIC module is superior to EBL for learning control rules as described by the authors, with only the caveat that STATIC may be inappropriate for some domains. Yet they do not address the following questions which are central to STATIC's utility:
  • How are domains in which STATIC may be used different from those that are not?
  • How common are domains in which STATIC may be used?
  • Can STATIC be further extended to additional domains or is this limitation a function of the architecture and/or representation?