Some notes about translation from TMKL into the Ectropic DTD. - Some things translate fairly directly: concepts to classes, tasks to resposibilities. - Methods are translated into the structure of scenarios. For each interesting path through a method, there needs to be one scenario which exemplifies it. Of course, interestingness is subjective. - I'm not sure I really understand collaborators in practice. In the examples I've seen they seem to indicate flow of control (i.e., method information). On the other hand, these seems to look wierd conceptually. That wierdness may come from not having the right classes for some responsibility (and thus its collaborator); see the next three bullet points. - The big problem with translation is the assignment of functionality to specific classes; this is a major paradigm shift. - Decomposing goals into subgoals has proven trickier than I expected. In general, tasks are translated into responsibilities, each of which links to at most one goal. However, there is a distinction in TMK between a task having one method with two subtasks and a task having two methods with one subtask each. A task with two methods which each have two subtasks is even more problematic. Fortunately, the scenarios can help resolve these ambiguities. - The above point is made even more problematic when different subtasks get mapped to goals for responsibilities in different classes. For example, if task T has subtasks X, Y, and Z (in that order) and these tasks get mapped to classes A, B, C, and D respectively, then responsibility A:T would have a collaborator B with link B:X, and B:X would have collabororator C with Link C:Y, and C:Y would have collaborator D with link D:Z. Note the fact that the decomposition is lost here: this winds up looking more like a sequence T, X, Y, Z then a decomposition of T into the sequence X, Y, Z. This may just be a poor translation. Again, also, the scenarios may be able to resolve this. Another possibility: maybe there should be two different kinds of subgoals, AND-subgoals (meaning to accomplish P do both Q and R) and OR-subgoals (meaning to accomplish P do either Q or R). - Translating task information into goals is problematic. The input, output, given, and makes slots of a task all represent aspects of what we call "goals". For now, I have just loosely translated into text. Something more formal which could support automated reasoning would require a lot more. - One thing which appears in Scenic scenarios but not in the Ectropic DTD scenarios is "Actor Instances". The "Actors" are in the Ectropic DTD scenarios indirectly (because the epsiodes link to resposibilities which exist within classes). However, the Actor Instances are not there at all. Having these instances could make the Ectropic scenarios more concrete (e.g., having specific URL's in the web browser scenarios). - Follow-up point: Here's a quote from my analysis of ScenicView (c. end of MORALE). This may be relevant, particularly if you read "class" for Actor, "responsibility" for Task, and "goal" for Objective: "I think that Actions should be removed from the system altogether and that Actor Instances, Task Instances, and Objective Instances should be made optional or dropped altogether (in particular, the Actor Instances may be useful optionally but Task Instances and Objective Instances are probably best dropped). Consider this example: Scenario: Monkey Gets the Bananas ... Episode: Episode in which Monkey1 Grabs Bananas1 Action: Monkey1 Monkey1 Grabs Bananas1 Task Instance: Monkey1 Grabs Bananas1 Task: Grab Actor: Monkey Actor: Object Actor Instance: Monkey1 Actor: Monkey The biggest problem here is that the episode of Monkey1 grabbing Bananas1 has to have an action of Monkey1 grabbing Bananas1 for the episode to connect to a task instance of Monkey1 grabbing Bananas1 in order for the episode description to indicate that the episode involves the Grab task. From the meeting scheduler example, this seems to result in a use in which episodes which conceptually seem to be instantiations of actions, but are not represented as actions (perhaps) because it would just be too tedious to do so. The above example could be redone as: Scenario: Monkey Gets the Bananas ... Episode: Monkey Grabs Bananas Task: Grab Actor: Monkey Actor: Object Actor: Monkey Actor Instance: Bananas Actor: Object Here the episode is directly linked to the task that it's exemplifying. This approach seems problematic if we expect Episodes to involve many different Tasks because there would not be an indication of which Actors in an Episode are involved in which Tasks. However, it seems that if an Episode involves many Tasks involving different actors, then it probably ought to be divided into multiple episodes. In fact, I don't think there would be much lost if we restricted each Episode to involve at most one Task. The episodes also link to all of the actors involved in it, including Monkey (to which it simply refers to the generic "Monkey" Actor) and Bananas (to which it refers to a specific "Bananas" Actor Instance because it is actually important here to identify which Object we're considering). Note that the link from "Monkey Grabs Bananas" to "Monkey" is redundant because the task also provides that link. It appears above because I want to explicitly distinguish between a generic link to an Actor (as in the case of Monkey) and a specific link to an Actor Instance (as in the case of Bananas). It might be better (but potentially more difficult to make clear in the interface) to have some sort of "binding" objects which bind the Actors Instances of an Episode to the Actors of a Task. For example, we could see something like: Scenario: Monkey Gets the Bananas ... Episode: Monkey Grabs Bananas Task: Grab Actor: Monkey Actor: Object Binding: Object - Bananas It's not clear what user interface would be appropriate for that sort of representation."