A FRAME is a data structure representing a STEREOTYPED SITUATION — a collection of attributes (SLOTS) and their values, describing an entity in the world. Minsky's motivation: when you enter a room you do not perceive it from scratch. You bring a "room" frame with expectations — walls, a floor, a door, a light switch near the door — and perception fills in and corrects the defaults. FRAMES ARE ABOUT EXPECTATION AS MUCH AS ABOUT STORAGE. THE ANATOMY: FRAME NAME identifies the frame SLOTS the attributes FILLERS the values in the slots. A filler may be: a specific value a DEFAULT value, overridable a RANGE or type constraint another FRAME (giving structure) a PROCEDURE (see facets below) FACETS properties OF a slot — metadata rather than data: value the current filler default used if nothing else is known range / type constraints on legal values cardinality how many values allowed if-needed a PROCEDURE run to compute the value on demand if-added a procedure run when a value is inserted if-removed a procedure run on deletion THE IF-NEEDED AND IF-ADDED FACETS ARE THE INTERESTING PART, and they are what distinguishes a frame from a plain record: PROCEDURAL ATTACHMENT means the knowledge base can COMPUTE rather than only store, and can maintain its own consistency when values change. A DEMON is the general name for such a procedure. A WORKED FRAME SYSTEM: FRAME: Person isa: Mammal name: (type String) age: (type Integer, range 0..130) residence: (type Place) handedness: (default Right) FRAME: Student isa: Person ← inherits above institution: (type Institution) year: (type Integer, range 1..5) exam-date: (type Date) topics-done: (type Set of Topic, default {}) progress: (if-needed: count(topics-done) / count(syllabus)) FRAME: Ram instance-of: Student name: "Ram Bahadur" age: 21 institution: Pulchowk-Campus year: 4 topics-done: {ACtE0901-0, ACtE0901-1, …} ANSWERING QUERIES: Q: What is Ram's handedness? No slot on Ram → inherit via instance-of Student → isa Person → default Right. ANSWER: Right (a DEFAULT, so it could be wrong, and could be overridden by adding the slot to Ram). Q: What is Ram's progress? The slot has no stored value but has an IF-NEEDED procedure, so the value is COMPUTED on demand from topics-done. ANSWER: computed, never stale. Q: Can Ram's age be set to 200? No — the range facet inherited from Person forbids it. THE CONSTRAINT IS PART OF THE KNOWLEDGE, and it detects the error at the point of entry. NOTE THAT THE `progress` SLOT IS THE DERIVED-ATTRIBUTE IDEA from the software design unit, arriving here by a different route: storing it would let it drift out of agreement with topics-done, so it is computed instead.

TWO KINDS OF FRAME, and the distinction is examined: CLASS FRAME (a generic frame) represents a category — Person, Student, Restaurant. Its slots describe what members of the class have. INSTANCE FRAME (an individual frame) represents a particular thing — Ram, this restaurant visit. Linked to its class by `instance-of`. Class frames link to each other by `isa`, forming a hierarchy down which slots and their facets are inherited — the same mechanism as semantic nets, which is unsurprising since frames can be seen as a semantic net with the arcs from each node gathered into one structure. MULTIPLE INHERITANCE is permitted: a Working-Student frame may be `isa Student` and `isa Employee`. THE CONFLICT PROBLEM IS THE SAME as the Nixon diamond — if both parents supply a different default for the same slot, the system needs a rule. The usual resolutions: · a declared ORDER of parents (as in programming languages' method resolution order) · the MOST SPECIFIC value wins where one parent is more specific · flag the conflict and require an explicit value NONE IS PRINCIPLED; all are conventions, which is the honest position. SLOT-FILLER INHERITANCE — what exactly is inherited: the SLOT ITSELF (so a Student has a `residence` slot even if empty) the DEFAULT value the RANGE and TYPE constraints the ATTACHED PROCEDURES AND THE RULE THAT MAKES DEFAULTS USEFUL: a value found lower in the hierarchy OVERRIDES one found higher, and the search stops at the first value found. Same mechanism, same non-monotonicity, same caveat as semantic nets. FRAMES VERSUS SEMANTIC NETS — the comparison: SEMANTIC NET FRAME SYSTEM ───────────────────────────────────────────────────────────── node + separate arcs all of a node's arcs collected into one structure knowledge is in the graph knowledge is in the record good for browsing relations good for describing an entity completely no natural place for facets give a place for metadata constraints and procedures no procedural attachment if-needed / if-added demons ───────────────────────────────────────────────────────────── THEY ARE THE SAME CONTENT ORGANISED DIFFERENTLY. A frame is a net node with its outgoing arcs tabulated; a net is a frame system with the slots drawn as edges. The frame view wins when you want everything about one entity in one place — which is why it became the object.

SCRIPTS — frames for SEQUENCES OF EVENTS (Schank and Abelson). A SCRIPT describes a stereotyped sequence of events in a particular context. Its components: ENTRY CONDITIONS what must be true for the script to apply ROLES the people involved PROPS the objects involved TRACKS variations of the script SCENES the sequence of activities RESULTS what is true after it completes THE RESTAURANT SCRIPT — the canonical example: ENTRY CONDITIONS the customer is hungry; the customer has money ROLES customer, waiter, cook, cashier, owner PROPS tables, menu, food, bill, money SCENES 1 ENTERING: enter, look for a table, sit 2 ORDERING: receive the menu, read, decide, signal the waiter, order 3 EATING: cook prepares, waiter brings, customer eats 4 EXITING: ask for the bill, pay, tip, leave RESULTS the customer has less money; the owner has more; the customer is no longer hungry WHY SCRIPTS MATTER: they support INFERENCE ABOUT UNMENTIONED EVENTS, which is exactly what language understanding needs. "Ram went to a restaurant. He left a large tip." A reader knows Ram ate, and paid, and was probably pleased — NONE OF WHICH WAS STATED. The script fills the gaps. THIS IS THE STRONGEST ARGUMENT FOR STRUCTURED KNOWLEDGE in natural language processing, and it is the problem that statistical methods handle differently rather than better — a language model produces the same inference from statistical association, without any explicit script. LIMITATIONS OF FRAMES: 1. DEFAULTS AND OVERRIDES ARE NON-MONOTONIC, so there is no clean logical semantics — the same objection as semantic nets. 2. MULTIPLE INHERITANCE CONFLICTS have no principled resolution. 3. NO STANDARD SEMANTICS for what a slot means or what may be inferred from it, so two frame systems may not be interoperable. 4. RIGIDITY: frames describe STEREOTYPES, and unusual cases fit badly. A restaurant where you pay before eating breaks the script, and the system has no graceful way to adapt. 5. NO NATURAL WAY TO EXPRESS NEGATION, DISJUNCTION OR QUANTIFICATION — the same representational inadequacy. 6. PROCEDURAL ATTACHMENT MAKES BEHAVIOUR HARD TO ANALYSE: once demons can run on access, the knowledge base's behaviour depends on execution order, which is the declarative-loses- to-procedural trade-off from the approaches topic. THE LINEAGE — worth stating because it is the most useful thing to remember about frames: FRAME → CLASS slot → field / attribute filler → value instance frame → object isa hierarchy → inheritance default filler → default field value range facet → type declaration if-needed procedure → a computed property / getter if-added procedure → a setter with side effects, or an observer demon → a trigger FRAMES ARE WHERE OBJECT ORIENTATION CAME FROM. And the criticisms above map onto criticisms of OO that the software engineering unit already made: multiple inheritance conflicts are the diamond problem, procedural attachment on access is a getter with side effects violating command-query separation, and "defaults with overrides" is exactly the fragile-base-class concern. THE SAME PROBLEMS, REDISCOVERED IN A DIFFERENT FIELD, which is a reasonable argument for studying both.