From OpenCog

The ExecutionLink provides a way of denoting functions and their values. To invoke scheme, python or C++ code to execute a function (or symbolize its output value if its execution is undefined) see ExecutionOutputLink. ExecutionLinks can also be thought of as a way of recording the results of an execution that was performed.


Its general abstract structure is of the form:

     SchemaNode schema-name
         SomeInputAtom arg_1
         OtherInputAtom arg_2
     SomeOutputAtom result

Conceptually, if the output is meant to be a truth value, rather than an atom, then the EvaluationLink should be used in place of the ExecutionLink, and the PredicateNode in place of the SchemaNode.

Some earlier thoughts on ExecutionLink semantics, apparently not yet obsolete, are here: OpenCogPrime:FunctionNotation#Execution_Links

Conceptual comments

The ExecutionLink construct is intended to cover the two cases of SchemaNode, which are

In the former case, the OpenCog system has a procedure for executing the process referred to by the GroundedSchemaNode; so in this case the ExecutionLink is actually a record of a function application (a procedure execution) that the system has done already...

In the latter case, indeed, the OpenCog system doesn't know how to actually execute any process corresponding to the SchemaNode in question, so it's just recording input/output values. In this case the ExecutionLinks pertaining to a SchemaNode S, are basically denoting elements of the "graph" of the function S, that is, as a set of ordered pairs (x, f(x)).

Part of the thinking in designing it this way was that sometimes a SchemaNode might move from ungrounded to grounded, in the lifetime of a single OpenCog instance; and in this case the same ExecutionLinks could persist.... Also, some example of execution of a schema could come from actually running a corresponding procedure; whereas others could come from inference (and have appropriately weighted truth values), or hearsay, etc.