CMSC 491M/691M - Spring 2003

Discussion Questions for Class #10, February 26

Reading: Weiss Chap. 8, Levesque et al., Levesque and Reiter

Formal Methods

The chapter makes a distinction between "formal methods" and "ad hoc, quick-and-dirty approaches to system construction." Do you think there is a middle ground? What are the pluses and minuses of using formal methods in agent design?
FYI, from dictionary.com: "Deontic: Of, relating to, or concerning duties or obligations. (From the Greek deon, deont-, obligation, necessity).
Devil's advocate: It's hard enough to build a single intelligent agent; how can we possibly hope to coordinate them??
The section on communication talks about languages for inter-agent communication, but what about communication breakdowns? How would they influence, for example, the scheme for coordination given in 8.5?
What's an ontology?? (This is one of those "What's an agent?" questions, by the way...)

GOLOG

p. 2: "The presentation throughout is informal in nature; in a companion paper [14], we explore the more formal aspects of the work." Aren't you glad I didn't assign [14]? :-)
Situation Calculus 101:
- 471/671 pop quiz: What are the limitations of the situation calculus? (Hint: In section 5.3, the discussion of progressing the databases addresses part of the key problem.)
- What's a fluent?
- How are action preconditions and effects modeled? What's the meaning of the Poss operator?
- What's the frame problem? Are frame axioms an adequate solution? Is the "simple solution" they propose a good one? Why or why not?
Complex Actions 101: In class, we'll walk through the specifications for items 1-6 in section 3.
Semi-rhetorical question: Gee, it seems like GOLOG is just another programming language. So why not just write a program?
p. 10: "By opting to define programs as macros, we obtain a much simpler theory than if we were to reify these actions." Bonus credit to anybody who can clearly articulate what this means and why it's true.
p. 20, bullet 2: "Nondeterminism can be used to infer the missing details [in] sketchy plans." \ This is great! The planning problem is solved!\ True or false?
What are GOLOG's most significant strengths and weaknesses? (Hint: see p. 21 for some of the limitations.)
- Can you give some examples of domains or environments that would be particularly well or ill suited for a GOLOG application?
- What aspects of the elevator controller domain make it a good GOLOG domain? Do you think it would be possible to write a more sophisticated/"smart" controller (e.g., for a large building with many elevators, where utilization must be maximized and energy usage and wait time must be minimized)?
- How does GOLOG compare to Soar, ACT-R, Prodigy, and APEX in terms of its cognitive plausibility, usability for application design, verifiability, and expressiveness?