The following questions have been addressed for the
ECAI-96 Workshop on Adaptation in Case-Based Reasoning
(De)composition, incremental vs. simultaneous adaptation
with EADOCS, Deja Vu, Lyon
Case structure for different tasks
with PARIS, Lyon, INRECA, ReSYN/CBR, TOPO
with Lyon, ReSYN/CBR, TOPO
with PARIS, Deja Vu, EADOCS, ReSYN/CBR
Questions for each theme, or all themes:
- Can you apply the other approaches in your group to solve your task? Why (not)?
- Are there explicit levels of abstraction? Can or do they have special vocabularies?
- No. There isn't real abstraction of the solutions. However, as a full case is a large chunk of design knowledge that can refer to (i.e., describe how to design) a complete and complex engineered object, there is some abstraction embedded in the case. It represents problems and subproblems, contributing to the solution at different levels of abstraction.
- As the cases are pieces of DSPL, they do share vocabulary elements.
- What kind of knowledge is represented in different abstractions?
- Why is abstraction used?
- What is the additional knowledge acquisition overhead, how does it effect runtime, what are the advantages?
- What conditions must the domain, the case representation, and the adaptation technique satisfy in order to use abstractions?
- How does abstraction affect similarity and memory organization?
- Why do you (not) use a structural representation rather than a flat one?
- A flat organization of the individual complete cases will suffice, because of the small size of the case library.
- The solution is hierarchically structured. A case in its original form is hierarchically structured sub-cases. This representation of sub-cases facilitates retrieval of an entire sub-case hierarchy, provides the context of sub-cases, suggests adaptation(re-assembly) actions.
- How do you match structure? How do you improve efficiency?
- The matching is mainly performed on an unstructured (partial-ordered linear) list of features corresponding to the leaf components of the case structure. Structural similarity is used as a tie-breaker.
- Could you match by unification?
- No. The cases can't be described in predicates.
- What and how much do you transfer?
- Not clear what "transfer" means.
- Do you abstract from the original case representation to the structural representation? How can you translate the results back to the original format?
- The cases are used in their original format.
- What about the quality of the result? Can you predict it?
- It is hard to predict the quality of the result, a design problem-solving system. For a particular system, simulation is necessary.
Case structure for different tasks:
- What is decision support? Is it an analytic or a synthetic task?
- According to Voss' survey, decision support problems are like classification and diagnosis except that there is clearly known goal definition in advance. It is an analytic task.
- Our system involves both planning and design activities, a synthetic task.
- What is a suitable case representation for decision support, planning, design, configuration, classification, diagnosis?
- Solution can be obtained easily. Retrieval and adaptation techniques can be applied easily. Additional knowledge can be added easily.
- Should problem and solution parts be distinguished? Should cases be structured into sub-cases? What kind of sub-cases?
- No. In fact we even use part of the solution to identify the problem: the decomposition of the solution is compared with that of the given problem in case retrieval. In addition, most of the indexing features are embedded in the solution.
- We need to have cases structured into sub-cases for subproblems. In this manner, a case retrieved contains all its sub-cases.
- What preconditions allow to structure cases in these ways?
- The design problem is decomposable. The design parameters are known. The design process is a linear ordered decision making with some limited amount of local iterations and backtracking.
- What are the dis/advantages?
- It's captured most static information for a solution (design system), and obtaining pieces for subproblems is easy. On the other hand, runtime information such as design traces, and context dependent information is not provided.
- Does the case representation limit the tasks that can be solved?
- This representation suggests an effective solution, but there is no information about alternative solutions.
- How does case structure influence indexing, similarity and adaptation?
- The hierarchical case structure leads to indexing and similarity measurement on hierarchies as well. E.g. ordering and grouping are considered as indices. The adaptation strategy discussed below is designed for this structure too.
- What kind of similarity and indexing is required to retrieve cases without a separation?
- Design problem features such as object parameters, constraints and design requirements, the ordering and grouping of parameters during design are main indices. The parameters are matched by names, constraints by symbolic expressions, grouping by set similarity criteria, ordering by similarity of linear lists.
Decomposition, composition, incremental vs simultaneous adaptation:
- Why do you not use a static problem decomposition?
- There are two instances of problem decomposition in our system:
- One is explicit semi-static decomposition by the KDD system. KDD performs decomposition using static decomposition knowledge, while at the same time taking into account previous decomposition cases. The KDD decomposition is used as an indexing feature for retrieval, and can also be used directly as the target decomposition framework when there is no good complete DSPL case to provide this decomposition.
- Another is implicit decomposition happening while DSPL cases are reused. The DSPL cases and sub-cases consist of fixed decomposition hierarchies. When we use a DSPL case, the decomposition embedded in it is usually borrowed directly.
- When can decomposition cases (as e.g. in DEJA VU) be used?
- Decomposition cases are used by KDD as in parallel with other knowledge sources to provide estimations of subproblem interactions.
- Under which conditions can cases be retrieved simultaneously?
- Basically there should be multiple adaptation targets, and the retrieval and adaptation of them should be sufficiently independent of each other.
- What adaptation techniques allow simultaneous case adaptation?
- Any techniques could be possible on each individual case, while the problem allows simultaneous adaptation.
- How do you achieve consistency of the solution?
- Syntactic inconsistencies and some of semantic inconsistencies such as dependency violations can be detected during case retrieval and evaluation, and fixed in adaptation stage. Yet this does not guarantee that the design system (the solution) generated, especially one generated via composing pieces from different cases, will work with no runtime conflicts among its components.
- How to select the next case for incremental adaptation? How do you achieve convergence?
- Subproblems at higher decomposition level are always tackled first. The result will determine whether lower level subproblems have been solved in adapting theirs super-problems, and when not, which of them need to be worked on further.
- The convergence is guaranteed by the finite number of subproblems for a given problem. At worst each of the subproblems go through the CBR process once.
- What are the stop criteria for incremental adaptation?
- This process stops when no pending subproblem to be adapted.
- Can you adapt both incrementally and simultaneously? Why not?
- Yes. In our situation, subproblems at the same decomposition level can be adapted simultaneously, with some communications and interactions that are usually not of a synchronizing nature. Global adaptation after each adapation is done may be possible, and small number of iterations of such a global-local adaptation may be possible.
- Can you predict the risk and the quality of adaptation?
- This strategy for applying adaptation attempts to reduce the amount of adaptation, by preferring reuse of larger cases to their smaller sub-cases even though some small cases match the problem better. The intention is to keep as much as possible the context of the cases, so that the cases need less adaptation to fit in the new context. There is a risk that this would miss opportunities of converting small cases to form a solution of better quality. But it is hard to predict the system performance accurately enough to help choose between using big cases and small cases.
- Is there a common framework for these strategic options?
email@example.com / Thu Sep 12 20:41:12 EDT 1996