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:
ExecutionLink SchemaNode schema-name ListLink SomeInputAtom arg_1 OtherInputAtom arg_2 ... SomeOutputAtom result
Some earlier thoughts on ExecutionLink semantics, apparently not yet obsolete, are here: OpenCogPrime:FunctionNotation#Execution_Links
The ExecutionLink construct is intended to cover the two cases of SchemaNode, which are
- plain old ungrounded SchemaNode
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.