Keith A. Pray - Professional and Academic Site
About Me
·
·
·
LinkedIn Profile Facebook Profile GoodReads Profile
Professional
Academic
Teaching
                                          
Printer Friendly Version

Intro ] [ 21-Cadet ] [ 22-Argo ] [ 23-Analogy Creativity Survey ]

Up: AI in Design ]

Critique: An Analogical Reasoning System for Solving Design Problems
Huhns & Acosta *

      It would seem that Argo is the first system we've looked at that directly addresses machine learning as a problem solving method for design. While this is an interesting angle, in general I found the article wrought with needless details requiring the reader to search for useful information about the system. Implementation details seem far less important than the techniques used for learning, abstraction, etc. in the system.

      When selecting rules to fire, Argo places each eligible rule in a conflict set. This term was slightly confusing at first since one needs a conflict for a conflict set to be non-empty, generally speaking of course. I don't know the likelihood of more than one rule being able to be fired in Argo, but since rules are selected by their level of abstraction in addition to the rule's condition being met, it is reasonable to think conflicts would not be common. While the name of the set may be irrelevant to the implementation of the system it plays a role in (not) helping readers understand it.

      The method by which Argo creates an abstract plan seems very limited. While it is possible to obtain different levels of abstraction, deleting all the leaf nodes from a plan, it precludes selective abstraction of plan branches. It is difficult to understand what is meant by following with "instantiations of some of the abstraction's trimmed rules." Does this mean that an abstract plan still has a record of the nodes that were removed to make it abstract in the first place? Could it mean that once following the plan and a leaf node is reached, if this node is not an instantiation, a rule is found to continue the design process? The synonymous use of "plan" and "rule dependency graph (RDG)" further confuses the explanation of these mechanisms.

      When forming macrorules the problem of the the macrorule's condition relying on the result of a rule this macrorule incorporates is not addressed. Since a macrorule can represent a large piece of a design plan it seems likely that this will happen. It could be that the problem is avoided through ensuring macrorules are formed from only independent subproblems. It could also be that the level of abstraction at which a macrorule is formed may prevent the need to apply rules to generate information beyond the problem statement. Either of these would need some explanation since it does not seem to be a trivial problem. Despite this not being discussed, the authors do give a nice summary of Argo's other limitations and problems.


* Michael H. Huhns & Ramon D. Acosta, Argo: A System for Design by Analogy, IEEE CAIA ** Top Paper, Fall 1988.

Intro
01-DPMED
02-Dominic
03-DSPL Air-Cyl
04-Pride
05-COSSACK
06-MICOM-M1
07-Configuration Survey
08-Dynamic CSP
09-MOLGEN
10-Failure Handling
11-VT
12-Conflict Resolution
13-Cooperative Negotiation
14-Negotiated Search
15-Multiagent Design
16-Prototypes
17-CBR Survey
18-PROMPT
19-A Design
20-Bogart
21-Cadet
22-Argo
23-Analogy Creativity Survey
24-Algorithm Design
25-AM
26-Edison
27-LEAP
28-Plan Compilation
29-ML Survey
30-Strain Gauge
31-Grammar
32-Config GA
33-Functional First
34-Functional CBR
35-Functional Survey
36-Models
37-First Principles
38-Config Spaces
39-Task Analysis

by: Keith A. Pray
Last Modified: August 13, 2004 8:20 PM
© 2004 - 1975 Keith A. Pray.
All rights reserved.

Current Theme: 

Kapowee Hosted | Kapow Generated in 0.009 second | XHTML | CSS