DECLARATIVE KNOWLEDGE — KNOWING THAT States FACTS and RELATIONSHIPS about the world, without specifying how to use them. Kathmandu is the capital of Nepal. All men are mortal. A patient with a fever and a rash may have measles. parent(X, Y) :- father(X, Y). Represented as: logical sentences, semantic nets, frames, probability tables, database rows. PROCEDURAL KNOWLEDGE — KNOWING HOW Specifies the STEPS to accomplish something. The knowledge is in the sequence. To compute a square root: guess, divide, average, repeat. To find the capital: open the atlas, turn to the index… for (i = 0; i < n; i++) { … } Represented as: programs, procedures, production-rule sequences, learned neural network weights. THE OPERATIONAL TEST: CAN YOU USE THE KNOWLEDGE IN A DIRECTION IT WAS NOT WRITTEN FOR? Declarative: `parent(X, Y) :- father(X, Y)` answers "who is Ram's parent?", "who are Ram's children?", and "is Ram a parent of Sita?" — ONE STATEMENT, MANY QUESTIONS. Procedural: a function `findParent(child)` answers exactly one question. To ask the reverse you write another function. THAT MULTI-DIRECTIONALITY IS THE PRINCIPAL ADVANTAGE OF DECLARATIVE KNOWLEDGE, and the reason a database can answer queries nobody anticipated. THE COMPARISON — the examinable table: DECLARATIVE PROCEDURAL ───────────────────────────────────────────────────────────── WHAT is true HOW to do it order-independent order MATTERS usable in many directions one direction per procedure easy to inspect and verify behaviour must be traced easy to modify — add a fact change may break the sequence inefficient: a general engine efficient: control is explicit must search knowledge is REUSABLE across knowledge is tied to its tasks purpose the machine chooses the the author chose it strategy ───────────────────────────────────────────────────────────── A WORKED CONTRAST — the same knowledge both ways: DECLARATIVE (Prolog-style) ancestor(X, Y) :- parent(X, Y). ancestor(X, Y) :- parent(X, Z), ancestor(Z, Y). TWO CLAUSES. They answer: is A an ancestor of B? who are A's ancestors? whose ancestor is A? — and they express the recursion without saying how to search. PROCEDURAL function isAncestor(a, b) { queue = [b] while (queue not empty) { c = queue.pop() for each p in parentsOf(c) { if (p == a) return true queue.push(p) } } return false } MORE CODE, ONE QUESTION ANSWERED, and the search strategy (breadth-first, upward) is now fixed by the author. To answer "who are A's descendants?" you write a second function. BUT: the procedural version's performance is predictable and controllable, and the declarative version's depends entirely on the engine's search order — which in Prolog can loop forever if the clauses are ordered badly.

USE DECLARATIVE KNOWLEDGE WHEN: · the knowledge must be INSPECTED or AUDITED — a regulator can read a rule table and cannot read a call graph · NON-PROGRAMMERS must change it — the whole argument for the expert-system architecture · the same knowledge serves SEVERAL purposes · the knowledge is VOLATILE, changing more often than the program · you want the machine to OPTIMISE the strategy — a query optimiser rewrites SQL far better than most humans would · CORRECTNESS must be argued about formally USE PROCEDURAL KNOWLEDGE WHEN: · EFFICIENCY matters and the general engine's search is too slow · the SEQUENCE is itself the knowledge — a safety shutdown procedure in which order is critical · the task is inherently algorithmic: sorting, numerical integration, parsing · the knowledge is genuinely single-purpose · there is CONTROL FLOW no declarative formalism expresses naturally — retries, timeouts, transactions THE ARCHITECTURAL PATTERN THAT REAL SYSTEMS USE: DECLARATIVE KNOWLEDGE WITH PROCEDURAL ATTACHMENTS. · a frame system with if-needed and if-added demons (the frames topic) — declarative structure, procedural computation where needed · a rule base whose rule actions call procedures · SQL — a declarative query with user-defined functions · a Prolog program with `cut` and built-in predicates for control THE JUSTIFICATION: express the knowledge declaratively so it can be inspected and changed, and drop into procedure exactly where the declarative form is inadequate or too slow. THE MISTAKE IS TO CHOOSE ONE AND FORCE EVERYTHING INTO IT. A WORKED ARCHITECTURAL DECISION — a fee-calculation system: DECLARATIVE PART: the fee schedule. Rates by district and category, effective-dated, in a table. Changes monthly by ministry circular, and an auditor must be able to read it. MAKING THIS PROCEDURAL — an if-chain in code — would mean a deployment for every rate change and an auditor reading source code. That was exactly the mistake the software design unit's fee example illustrated. PROCEDURAL PART: the rounding algorithm, the currency arithmetic, the retry logic against the payment gateway. MAKING THIS DECLARATIVE would be perverse — "round half up to two decimal places" is a procedure, and expressing it as facts gains nothing. THE BOUNDARY: knowledge that CHANGES for business reasons is declarative; knowledge that changes only for technical reasons is procedural. THAT IS THE MOST USEFUL PRACTICAL RULE IN THIS TOPIC.

THE HISTORICAL DEBATE — worth knowing because the syllabus refers to it and because both sides were partly right. THE DECLARATIVIST POSITION (McCarthy, and the logicist tradition): knowledge should be stated as facts, and a general inference engine should figure out how to use it. Separating knowledge from control is what makes knowledge reusable, verifiable and modifiable. THE PROCEDURALIST POSITION (Minsky, Winograd, and the MIT tradition): knowledge of HOW to do something cannot always be reduced to facts, and pretending otherwise produces systems that are elegant and useless. Real intelligence includes knowing which method to try, which is control knowledge. THE RESOLUTION, which is not a compromise but a distinction: · they suit DIFFERENT KINDS OF KNOWLEDGE, and the KR issues topic's answer applies — choose per kind, not once for the system · CONTROL KNOWLEDGE IS ITSELF KNOWLEDGE. "Try the cheap test before the expensive one" is a fact about the domain, and a purely declarative system with no way to express it searches badly. Modern systems make control knowledge declarative too — rule priorities, heuristic orderings, elimination orders — which is the inferential-efficiency property from the KR properties topic. WHERE MACHINE LEARNING SITS, and this is the interesting modern question. A trained neural network is: NOT DECLARATIVE — you cannot read a fact off it, and it states nothing you can inspect or audit NOT PROCEDURAL in the ordinary sense — nobody wrote the steps, and the weights encode no sequence a human follows IT IS A THIRD THING: knowledge as a LEARNED FUNCTION. It has procedural knowledge's opacity and worse — a procedure can at least be read — and it has declarative knowledge's multi-directionality only partially. THE PRACTICAL CONSEQUENCE, which the AI applications topic already noted from the other direction: a learned model cannot be audited, cannot be edited by a domain expert, and cannot explain itself. WHERE THOSE PROPERTIES ARE REQUIRED — regulated lending, medical decisions, legal determinations — DECLARATIVE KNOWLEDGE IS STILL THE ONLY OPTION, however much more accurate a model might be. THAT IS WHY RULE ENGINES ARE STILL SOLD, and why "just use machine learning" is not an answer to every knowledge problem. THE SUMMARY WORTH REMEMBERING: declarative what is true inspectable, flexible, slower procedural how to do it efficient, opaque, single-purpose learned neither accurate, opaque, unauditable Each buys something and pays with something else, and no system of any size uses only one.