At first I was apprehensive about reading this given the last Sycara article. I was pleasantly surprised to see this was written rather well despite the parts that Sycara had obviously written.

      When presenting the steps of case-based design it is unclear what index transformation strategies are. Do they mean that they take the input specification and abstract them and then map to and index? I couldn't find an explanation in the article, but I've been known to miss things before.

      The fact that CADET uses structural or surface features as indices in addition to the abstract ones seem important enough to mention in the body of the introduction rather than in a footnote. It could change the whole point of view in which these ideas are presented. Since other systems have used structural information for indexing, CADET could be viewed as a system that explores the use of abstraction to augment rather than replace, which is the feeling I got from the introduction. When is one method of indexing used over another? Which performs better? How are they used together, rather than an either or strategy? How can one compare the results obtained by CADET and objectively give an indication of how much abstraction helps? Later on they do speak of structural features, but this seems different, listing things like pipe, nozzle, cylinder and relations which seem more abstract than a simple physical, surface view of a design. Is this simply a basis on to which an abstraction is built?

      I found it very odd that physical synthesis would be listed before verification in the list of steps of case-based design. While the authors do point out that these steps are interleaved, it seems very counter intuitive to physically make something before verification, simulation, etc. had been done if possible inside the design system. In the verification step it mentions repair if the design is not verified. Why not keep consistent terminology and say debugging, since that is the name of the next step to which they refer with the term "repair"?

      It is interesting yet obvious with some reflection how most cased-based reasoning systems use case-based reasoning recursively to handle not only the initial problem to be solved but the backtracking, repair, debugging, analysis, etc. that each system employs. It makes clear the usefulness and power of a general or weak solution such as case-based reasoning when applied with an appropriate knowledge base.

      It is unclear whether the authors intend the terms "design" and "case" to be synonymous. Can you call a case that has a high level of abstraction a design or should a design include every level of detail necessary to instantiate an artifact? This type of ambiguity seems to permeate throughout the article.

      When explaining qualitative and configuration spaces it is unclear how the authors mean "geometry". Do they mean geometry as related to mechanical design or do they mean the relations of various components and behaviors in the graphs presented, as in the geometry of the graph, not necessarily of the resulting artifact? One is a physical space view and the other is a more abstract representational view. This is further complicated by the use of "configuration space" to mean various states a single design can be in rather than the more common notion of configuration as a type of design activity.