Concepts

What a Knowledge Base System Is

You may have met the term Knowledge Base System — or Knowledge Based System — in a textbook or a vendor brochure, and concluded that the concept was too broad to be of practical use. You may even have heard the joke: knowledge-based engineering, as opposed to ignorance-based engineering? Fair enough. Our own definition is deliberately narrow, and it is the one this page uses throughout.

Everything else on this page follows from that sentence. Caching means that once the system has computed something, it will not generally repeat the computation if the same question is asked again. Dependency tracking is the other side of the coin: it ensures that when a cached result has gone stale, it is recomputed the next time it is demanded, so what comes back is always fresh.

The wider engineering literature defines knowledge-based engineering as a technology for capturing and systematically re-using product and process engineering knowledge, with the goal of cutting the time and cost of product development — by automating the repetitive, non-creative parts of design, and by supporting multidisciplinary design optimization throughout the process rather than only at the end. We have no quarrel with that definition. We would add only that it stands or falls on whether the underlying engine gets the next three things right.

Caching and Dependency Tracking

The engine memoizes what it computes — both computed slot values and instantiated objects — so that results are reused rather than recalculated. The dependency tracker records what each cached value was derived from. When something upstream changes, every value downstream of it is marked stale and unbound. Nothing is recomputed at that moment; the recomputation happens later, if and when the value is demanded again.

This is what makes associative modeling work. Suppose the shape of a wing rib is defined in terms of the wing's aerodynamic surface. Modify that surface, and the rib instance — together with every attribute and every child object that depended on it — is invalidated automatically. The replacement rib is not built eagerly; it appears at the moment someone asks for it.

Note what is absent. There is no rebuild step to run, no dirty flag to maintain, no observer to wire up, no ordering convention that a future maintainer has to know about. You cannot forget to invalidate something, because you never wrote the invalidation in the first place.

Demand-Driven Evaluation

GDL evaluates only those chains of expressions needed to answer the question actually asked. Request the weight of that wing rib, and the rib object is instantiated because the weight needs it; the reference surface is generated because the rib needs it; and so on, backwards through the dependencies, until the request can be satisfied — and no further.

This matters at scale, and scale is the normal case. A production object tree can run to hundreds of branches and thousands of attributes. The ability to evaluate one specific attribute on one specific branch, without evaluating the entire model from its root, is frequently the difference between a problem that is tractable and one that is not. Ask for a bill of materials and you pay for a bill of materials — not for the geometry, the drawings, and the analyses that nobody requested.

Declarative Form: Relationships, Not Call Order

When you put together a GDL application you think and write mainly in terms of objects, their properties, and how those properties depend on one another. You do not have to track in your head which object will call which other object, or in what order. There is no main loop and no evaluation sequence to maintain: the engine derives the order it needs from the dependency graph, at the moment of demand.

The practical consequence is that you can add a rule in the middle of a large model without first deciding where in an execution sequence it belongs. The definition reads as a statement about the product rather than as a recipe for computing it, which is why GDL source stays legible years later — to a colleague picking it up, and increasingly to a language model asked to extend it.

None of this costs you the machine. GDL is a superset of ANSI Common Lisp and compiles down to native code; the stack, and the code-expansion that gets you there, are covered on the Technology page.

You Have Seen This Model Before

The combination — declarative form, a dependency graph, demand-driven recomputation — has been independently reinvented several times in other corners of computing. That is usually a sign that a model is right rather than merely old.

• •Spreadsheets. Excel is the most widely used declarative, dependency-tracking, demand-driven engine on earth. You state relationships between cells; the tool works out what has to be recomputed, and when.
• •Build systems. Make, Bazel and their descendants take a declared dependency graph and rebuild only what has gone stale.
• •Reactive user interfaces. Signals in modern UI frameworks, and notebook environments such as Observable, are memoized dependency graphs recomputed on demand.
• •Modelica. Declarative and acausal: you state relationships among physical quantities instead of an order in which to evaluate them.

Each of these rediscovered one facet of the model for its own domain. GDL has had the whole of it — with a real object hierarchy, real geometry, and a real compiler underneath — since the 1990s. That makes the engine early rather than legacy, and it goes some way toward explaining why it takes so naturally to being driven by an AI agent.

The Object-Oriented Paradigm Meets the Functional Paradigm

In order to model very complex products and efficiently manage large bodies of knowledge, a KB system taps the object-oriented nature of its underlying language. "Object" here means an instantiated data structure of a particular assigned type. From that you get what you would expect of any object-oriented environment:

• •A clean separation between the definition of an object and an instance of it
• •High levels of data abstraction
• •Inheritance — one definition building on others, including mixins
• •The ability to use an object without concern for its under-the-hood complexities

But unrestricted modification of object state is the well-known road to systems that are difficult to debug and impossible to maintain. A KB system manages that risk by strictly constraining the ability to change state. What it produces at runtime is a tree of inspectable objects, analogous to the function call tree of a pure functional program — except that it persists, and you can walk it, query it, and display it.

Where mutation is genuinely called for, as when a user changes an input in a web interface, it is confined to slots explicitly declared settable, and the dependency tracker deals with the consequences. GDL supports the message-passing style of object orientation, with some extensions; full ANSI CLOS is always available alongside it, so the generic-function style is there when it suits the problem better.

What GDL Is Good For

• •Organizing and integrating large amounts of information in ways which are impractical using conventional languages, CAD systems, or database technology alone
• •Evaluating many design or engineering alternatives, and performing optimizations within a specified design space — very rapidly
• •Capturing the procedures and rules used to solve repetitive tasks in engineering and other fields
• •Applying those rules to produce intermediate and final outputs, which may include wireframe, surface and solid geometry, reports, and documents
• •Building targeted applications — in effect special-purpose CAD systems, aimed at a specific rule-based set of design tasks, as distinct from a general-purpose interactive modeler

What GDL Is Not

• •A CAD system — although it operates on and generates geometric entities, and can generate applications which amount to special-purpose CAD systems
• •A drawing program — although, again, geometry goes in and comes out
• •An artificial intelligence system — although it is an excellent environment in which to develop capabilities which could qualify as such
• •An expert system shell — although one could easily be embedded within it

Further Reading

• •Gianfranco La Rocca, Knowledge Based Engineering: Between AI and CAD, Advanced Engineering Informatics 26(2), 2012 — a survey of the field, and the source of the standard definitions paraphrased above.
• •David J. Cooper, Jr., Basic Lisp Techniques — a short, practical introduction to Common Lisp for programmers arriving from other languages.
• •Paul Graham, ANSI Common Lisp, and Peter Seibel, Practical Common Lisp — both cover the two models of object orientation, message passing and generic functions, in useful detail.

Where to Go Next