Hallazgos sobre la categoría de perfil de los estudiantes

The rst two points give some general guidelines for the level and kind of granular-ity that is desirable when constructing model component representations of physical domains. As such, the advice remains relevant when dealing with domains other than mechanics. The last suggestion addresses overall knowledge-base organization, and while specic to mechanics, it is based on reasons that may also prove useful beyond the eld's immediate scope. The following discussion explores each of the above suggestions in more detail

Level of Granularity

It should be fairly clear why one should decompose knowledge into units small enough to be assembled into models of any physical situations of interest. Note, however, that instead of advocating some specic level of granularity, this guideline suggests that a program's knowledge-base should be tuned to the types of systems it is supposed to reason about.

For example, higher level abstractions and more specialized approaches prove useful in reasoning about the subset of mechanics that deals with machinery. En-gineered artifacts like mechanical devices have highly constrained behavior, and are constructed largely from standard parts. Knowledge representations that address typ-ical collections of objects as functional units as opposed to arbitrary congurations of individual parts allow ecient reasoning about problems this subeld.

Although representing small pieces of domain knowledge tends to improve mod-ularity and support generality in a reasoner, there is a lower bound beyond which decomposing knowledge any further becomes counterproductive. Keeping knowledge in as large units as possible without compromisinggenerality has the eect of reducing the amount of reasoning required to build models. More importantly, however, is that larger units of knowledge illustrate the regularities within a domain more clearly. Of course there is a limit to this: units of knowledge can be too large, even though they may be capable of modeling all situations of interest. If model components start to have redundant content, this hints at common behaviors underlying dierent pieces of knowledge. In such cases, the representation should reect this structure for both

73

compactness and clarity.

Representing Qualitative Behaviors

When designing AMES, it was extremely useful to examine the terminology of the domain to guide organization of the program's domain knowledge. The reason is simply that, people have a great deal of both formal and intuitive knowledge about physical systems. These often reect underlying regularities of the domain that form modular units suitable for representation as model components. Furthermore, some human domain knowledge is explicit enough to more or less directly translate into model components. For example, each of Newton's laws translates into a separate piece of knowledge in AMES.

Aside from helping to assemble complete descriptions of knowledge in the domain, representing the concepts and methods that people use allows the knowledge-base to be easier to understand and debug. Nearly all of AMES' domain knowledge came directly from studying standard human reasoning abstractions and making them more explicit. This suggests that the domain has structure that model components can capture in an intuitive fashion.

Representing Object Semantics Using Point Mass Mechanics

Mechanics texts provide very explicit descriptions of mechanics at the free body di-agram level: the behavior of isolated point masses. They oer much less concise information about to interpret the interactions between entities such as extended rigid bodies and ropes, however. Part of the reason for this is that intuition sup-plies much of the necessary information. Unfortunately, it also hides much of the knowledge needed to allow computers to do similar reasoning.

In organizing mechanics domain knowledge, it seems useful to keep knowledge about point mass mechanics separate from knowledge about the behavior of the var-ious extended object classes. The reason is that the two kinds of information are distinct in two important ways. By keeping them separated, one can reap the usual benets of modular design: ease of both comprehension and maintenance.

74

The rst way in which the two kinds of knowledge are distinct is that they re-ect dierent levels of abstraction: all objre-ect interactions in the mechanics domain can be expressed in terms of the kinematics and dynamics of point masses. Further-more, conventional wisdom in mechanics advocates organizing problem solving in this manner, explicitly reducing all high level behavior to free body diagrams.

The second reason for separating the two bodies of knowledge is that, as mentioned above, point mass mechanics have lent themselves to more explicit description than the behavior of extended objects. Separating the two kinds of knowledge therefore helps contain the portion of the knowledge-base that is likely to require the most modication.