The PSOA RuleML language and its PSOATransRun engine provide cross-paradigm deductive querying.
Knowledge representation in PSOA RuleML is explored with a progression of data and rules built from relations (tables), objects (graphs), as well as their systematic integration and extension.
All kinds of data from this PSOA systematics are visualized by generalized (hyper)graphs in an extended Grailog.
Building on relational Herbrand models, objectal and object-relational Herbrand models are presented as a novel model-theoretic semantics for such data and rules.
Comprehensive PSOATransRun query & answer pairs for the same PSOA knowledge bases exemplify the proof-theoretic semantics.
General notions are illustrated by varieties of transitive closure as high-level knowledge about blockchains like Gridcoin and Chia Network.

By installing PSOATransRun, a hands-on learning experience can be obtained through copy & paste of these KBs and tests with the provided queries, where the queries and then the KBs can be modified and extended.

2 A Single-Blockchain Scenario

Consider a scenario of a single blockchain, represented

without going into the internal structure of blocks but

by focusing on linkages between blocks and the composition of such links into chains, where

blocks are straightforwardly used as OID nodes linking to other block nodes, e.g. in Section 3.2, or

link arcs become '(user-)objectified' in OID nodes, e.g. in Sections 5.2 and 5.3.

The following diagram series of directed labeled graphs[8] shows a blockchain growing -- from a "genesis block", Block1 -- left-to-right with two, three, and four blocks linked (green arrows) in a linear fashion[9], along with all of their possible chains (red arrows):

The scenario is now stated symbolically in a -- moderately -- controlled natural language (here, a subset of English).

A couple of specific block linkages are stated as facts.
Two general principles of block chaining based on such linkages are stated as "conclusion if condition" rules. (The diagrams' color coding is extended to the symbolic form by using green for facts and their rule-condition counterparts while using red for rule conclusions and their -- recursive -- rule-condition counterpart.)

Facts

"Block1 links to Block2."

"Block2 links to Block3."

Rules

"x chains to y if x links to y."

"x chains to z if x links to y and y chains to z."

Note: The facts are specialized to three blocks (the above center diagram) and the rules are general (defining an infinite series of such diagrams).

from an "And"-prefixed condition conjunction-of-atoms, here from And( Link(...)Chain(...) ).

This results in a KB using the following abridged syntax:

Facts

Link(Block1 Block2)

Link(Block2 Block3)

Rules

Chain(?X ?Y) :- Link(?X ?Y)

Chain(?X ?Z) :- And( Link(?X ?Y)Chain(?Y ?Z) )

These rules define the transitive closure, Chain, over a base relation, Link:[12]

The first rule specifies the base case for Chain applied to two arguments, ?X ?Y, as being implied by Link applied to the same two arguments in the same order.

The second rule specifies the recursive case for Chain applied to two arguments, ?X ?Z, as being implied by Link applied to the first argument, ?X, and an intermediate argument, ?Y, and by Chain recursively applied to ?Y and ?Z.

until these iterations reach a (least) fixpoint as a steady state (and the rules -- after having made the implicit knowledge explicit -- would no longer be required).

Here (we italicize ground facts from which new ones are derived), the fixpoint is reached in iteration [3] (where neither of the rules can derive new ground facts), which is the Herbrand model:

[1] the [0]-generated (initial) ground facts:

{ Link(Block1 Block2),

Link(Block2 Block3) }

[2] the [1]-generated ([0]-generated or [1]-derived) ground facts:

{ Link(Block1 Block2),

Link(Block2 Block3),

Chain(Block1 Block2),

Chain(Block2 Block3) }

[3] the [2]-generated ([1]-generated or [2]-derived) ground facts:

{ Link(Block1 Block2),

Link(Block2 Block3),

Chain(Block1 Block2),

Chain(Block2 Block3),

Chain(Block1 Block3) }

3 PSOA Representation and Querying of Single Blockchain

The following three subsections will discuss PSOA characteristics using transitive closure as an example in the single-blockchain scenario.
Semantically, we start with a relational Herbrand model -- since PSOA subsumes relational logics such as the Horn clauses of Pure Prolog -- and move on to objectal and object-relational Herbrand models with graph-node OIDs, graph-arc slots, etc.[13]

3.1 Binary Relationships: No OID; Dependent 2-Tuple

In the diagram form of Section 2, the green Link arrows visualize the facts as directed arcs of directed labeled subgraphs (which happen to be linear, i.e. without branchings).

To allow smooth generalization from binary to n-ary relationships, the facts can also be visualized as directed hyperarcs of directed labelnode hypergraphs (for the special case n=2), where arc labels such as Link become labelnodes that start arrows cutting through intermediate nodes of the -- implicit -- argument n-tuple (for n=2, there is n-1=1 intermediate node).[14]

The Link labelnode and the argument node Block2 are shared across the two hyperarcs, although the diagrams in this document keep such node copies -- for simplicity, modularity, and proximity to the symbolic form -- rather than merging them:

Proceeding to the symbolic form, in its KBs, PSOA -- like W3C RIF -- makes the quantifiers for variables explicit -- here, by Forall quantifiers wrapping each rule separately -- such that in

Forallvariables(rule)

the scope of the variables is clearly delineated (by the parentheses) to be the rule.[15]

Hence -- also including the RuleML root and an Assert performative -- this is the presentation syntax of the KB in Section 2 ready for copy & paste into a document used as input to PSOATransRun (inline comments are prefixed with a "%"):

This KB's abridged syntax from the previous section and its presentation syntax right above have the same semantics, as formalized by the same Herbrand model (just omitting the Link/Chain color coding), which we will call a relational Herbrand model since it contains only relationships:

{ Link(Block1 Block2),

Link(Block2 Block3),

Chain(Block1 Block2),

Chain(Block2 Block3),

Chain(Block1 Block3) }

The KB can be queried without variables (ground) or with variables (non-ground) as shown below. Like in the Herbrand semantics, through such querying the rules make the implicit knowledge explicit. However, query answering employs backward / top-down applications of rules, which usually need only parts of a KB.

A PSOA query can be an atom or a conjunction (or, although not used here, a disjunction).
The query variables of a non-ground query are indicated by their free occurrence(s) -- particularly no wrapping with Exists quantifiers -- in the query.

A PSOA answer (each expected after a "%") displays,

for a ground query, Yes or No, and,

for a non-ground query,

as an implicit Yes, the bindings -- printed in one (possibly wrapped-around) line -- of the query variables or

an explicit No (in which case there can be no bindings).

When there are multiple bindings for one or more variables, these "non-deterministic" bindings are printed in multiple lines.

The (comment-introduced) groups of query & answer pairs below and in later (sub)sections thus

The last group consists of a single, "totally non-ground" atomic query, that is (without repeating any variable name)

it even uses a variable for its predicate -- i.e., higher-order (here, second-order) syntactic sugar --

besides using variables for each of its arguments.

In this unusual case, all facts and rules are needed to enumerate all answers, and the answer lines of bindings for the variables can be re-substituted into the query to obtain the Herbrand model.[17]

In the following, query & answer interactions with PSOATransRun are slightly condensed and some non-deterministic bindings are reordered for expository purposes (the order does not carry any semantics):

The above KB and queries are on the Datalog (function-free Horn logic) level of expressiveness, further restricted to Binary Datalog by employing only 2-argument (binary) predicates.

3.2 Framepoints: OID; Independent Slots

To visualize framepoints, the alternative diagram form of typed directed labeled graphs is introduced:

OID nodes, which have zero or more outgoing slot arrows, are explicitly typed by one or more incoming member arrows from classes, in PSOA from predicates, here from Block, acting as a class.

Member arrows (implicitly labeled with "hasInstance") have an inverse-member head pointing from a predicate to the OIDs it types, here to Block1 and Block2.

Slot arrows (explicitly labeled with a slot name) have a regular head representing slots that point from an OID to slot fillers, here to Block2 and Block3, respectively.

For the facts, the only slot name (explicit arc label) is link:

In the corresponding symbolic form, instead of the binary predicate Link (capitalized) between blocks in the previous subsection, the first block becomes the OID (typed by Block) of a framepoint and the second block becomes the filler of its slot, indicated by a "->" infix, named link (not capitalized).[18]

Analogously, the framepoint rules, instead of the binary predicate Chain, use a chain slot.
Moreover, they use variables in the OID and slot-filler positions corresponding to, respectively, the first and second arguments of the Link/Chain predicates of the relationship rules in the previous subsection.

The link/chain slots become multi-valued when representing branching blockchains.
The chain slot becomes multi-valued also when deducing its OID's chains of different lengths (increasing lengths, for top-down querying).

The blockchain-constant OIDs Block1 and Block2 as well as the blockchain-variable OIDs ?X and ?Y become members, indicated by a "#" infix, of the predicate Block acting as their class.

As a counterpart to the KB in the previous subsection composed only of relationships, this is the KB composed only of framepoints (these two "homogeneous" compositions are in contrast to the "hybrid" composition in the next subsection):

Note: Whereas the recursive rule of the previous subsection was indicated by two occurrences of the Chain predicate, in the current recursive rule the three occurrences of the Block predicate provide OID-variable typing, while it is the two occurrences of the chain slot that indicate recursion.

The semantics of this KB can be formalized by an objectal Herbrand model containing

single-slot framepoint atoms, each with an OID and an independent slot, as well as

while the two framepoint-incorporated Block memberships become separate -- KB-level -- OID-coreferenced conjuncts (to keep track of the source's atomic facts, the two subconjunctions resulting from them are shown on the same lines, although element order does not matter in sets).

Objectal Herbrand model:

{ Block1#Block, Block1#Top(link->Block2),

Block2#Block, Block2#Top(link->Block3),

Block1#Top(chain->Block2),

Block2#Top(chain->Block3),

Block1#Top(chain->Block3) }

The PSOA realizations by PSOATransRun perform corresponding normalizations, which include transformations from objectal KBs and queries to relational ones.[20]

The below graph query & answer interactions with PSOATransRun are the exact counterparts to the relational ones in the previous subsection, employing corresponding queries and producing identical answers.

Thus changing the queries while maintaining the answer set exemplifies how PSOA bridges across the relational and graph paradigms -- the opposite sides of a spectrum (see PSOA RuleML Bridges Graph and Relational Databases) -- within the same language.

4.1 Proceeding to a Multiple-Blockchain Scenario

Multiple blockchains may arise, for instance, within a cryptocurrency -- e.g., in Nano -- or across pairs of cryptocurrencies -- e.g., as assumed here, for Gridcoin and Chia Network.

To accommodate multiple blockchains in our modeling, each Blocki is given a unique blockchain prefix bch, resulting in bchBlocki. In the following examples, bch=Grid, for Gridcoin, leads to GridBlocki while bch=Chia, for Chia Network, leads to ChiaBlocki.

In some of the examples, ('elementary' and later 'structured') OIDs will be used for (user-)objectified atoms.

4.2 Ternary Relationships: No OID; Dependent 3-Tuple

In this relational modeling, an oidless, dependent-tupled representation is employed.
Here, each oidless atom applying a predicate to a tuple constitutes a relationship.

A unique constant name for each blockchain is added as an extra argument (here, as a new first argument) to the Link facts of Section 3.1, and

a corresponding extra-argument variable, ?W, is added to the Chain rules, making the Link and Chain predicates 3-ary (ternary), i.e. proceeding to Ternary Datalog.

For example -- even when represented in one KB -- the Gridcoin and Chia Network (represented by Chiantwk) blockchains can be distinguished via the first arguments as shown below.

The facts can be visualized as directed hyperarcs for 3-ary relationships,
demonstrating genuine n-ary hyperarc visualization (for the case n=3):

4.3 Separating the Blockchain and Block Parameters

While the arguments of the binary predicates of the single-blockchain KB are of the same kind, namely blocks,
the arguments of the ternary predicates of the multiple-blockchain KB are of different kinds, namely blockchains and blocks.

To avoid this argument heterogeneity, the predicates can be kept binary and the blockchain parameter can be separated and put somewhere outside the tuple of block arguments using one of the methods discussed in the following Subsection 4.4 and Section 5.

4.4 Higher Order: No OID; Parameterized Predicate

In this modeling, an oidless, (syntactically) higher-order representation is employed.
The binary predicates Link and Chain become parameterized with a blockchain constant -- e.g., Link(Gridcoin) -- or variable -- e.g., Chain(?W).
This leads to facts like Link(Gridcoin)(GridBlock1 GridBlock2)
and to rules with implications like Chain(?W)(?X ?Y) :- Link(?W)(?X ?Y).
Such parameterized predicates are allowed in the PSOA RuleML language but are not (yet)
realized in the PSOATransRun engine (cf. PSOATransRun Development Agenda), although they are in the Relfun engine, employing -- for this fact and rule -- the following syntax:

link[gridcoin](gridBlock1,gridBlock2).
chain[W](X,Y) :- link[W](X,Y).

5 Multiple Blockchain Names and Links/Paths in OIDs

The following subsections will explain PSOA representations where OIDs constitute separate blockchain names (first subsection) and then are expanded to 'structured' OIDs augmenting those names with links/paths (subsequent two subsections).

5.1 Binary Relationpoints: OID; Dependent 2-Tuple

In this modeling, an oidful, dependent-tupled representation of relationpoints is employed, systematically referred to as "pv2".

Instead of using an extra argument or a parameterized predicate,

the unique blockchain constant -- e.g., Gridcoin and Chiantwk -- is added as an OID to the Link facts, and

a corresponding OID variable, ?W, is added to the atoms of the Chain rules.

Generally, the OID of an oidful atom 'objectifies' the atom in a declarative manner (as formalized in PSOA's model theory, see PSOAPerspectivalKnowledge, Section 5).
This object-centered representation supports modular elaboration of the atom by providing further descriptors (objectal: slots; object-relational: slots and tuples) via retrieval, inheritance, or general deduction (e.g., a deduced length slot will be added in Section 5.3).

The blockchain-constant and -variable OIDs become members, indicated by the "#" infix, of the binary predicates Link and Chain.

The blockchain OIDs are described by the 2-tuples from these predicates, e.g. connecting GridBlock2 with GridBlock3 but not (cyclically) with GridBlock2.

For example -- again in one KB -- the Gridcoin and Chia Network blockchains can now be distinguished via the OIDs as shown below.

The facts can be visualized with arrows starting at Link, having an OID as member, and continuing as a directed hyperarc for a binary relationship, where the OID-cutting continuation indicates predicate dependence of the 2-argument tuple (an inverse-member arrow head points to, hence distinguishes, the OID while a regular arrow head points to the last relational argument):

The four facts in this KB can be regarded as the result of transforming -- via PSOATransRun-realized "tupribution" (see PSOAPerspectivalKnowledge, Section 3.1) -- two facts that describe the OIDs Gridcoin and Chiantwk with multiple -- two for each -- tuples (the "+" prefixes indicate the standard "predicate dependence" of tuples, similar to the one to be introduced later for the "+>" infixes of slots):

The semantics of this KB -- and of its multi-tuple variant -- can be formalized by an object-relational Herbrand model containing only relationpoints, i.e. atoms that are themselves object-relational by having an OID as well as a single dependent tuple:

{ Gridcoin#Link(GridBlock1 GridBlock2),

Gridcoin#Link(GridBlock2 GridBlock3),

Chiantwk#Link(ChiaBlock1 ChiaBlock2),

Chiantwk#Link(ChiaBlock2 ChiaBlock3),

Gridcoin#Chain(GridBlock1 GridBlock2),

Gridcoin#Chain(GridBlock2 GridBlock3),

Chiantwk#Chain(ChiaBlock1 ChiaBlock2),

Chiantwk#Chain(ChiaBlock2 ChiaBlock3),

Gridcoin#Chain(GridBlock1 GridBlock3),

Chiantwk#Chain(ChiaBlock1 ChiaBlock3) }

The KB -- and its multi-tuple variant -- can be queried in ways that expand or generalize the queries of our modeling in Section 3.1.

We prefer the dependence of the src/trg-named slots on the predicates Link vs. Chain to either

using these slot names in a predicate-independent manner (although this would make only a subtle difference for the slots src/trg, unlike for the slot len in Section 5.3 and the slot dept in the Rich TA example of PSOAPerspectivalKnowledge), or

introducing new names for predicate-independent slots such as

utilizing predicate-independent slots with hard-coded predicate-specific names like srcLink/trgLink vs. srcChain/trgChain (a compactification of the general encoding src@Link/trg@Link vs. src@Chain/trg@Chain according to PSOAPerspectivalKnowledge, Section 2.2.), or

where answers would redundantly deduce srcLink/trgLink or srcImmediate/trgImmediate pairs from the Link facts, srcChain/trgChain or srcUltimate/trgUltimate pairs from the Chain rule's base case, as well as mixed pairs.

To maintain the connection between each tuple's two elements also in the slotted representation,

explicit link names are introduced;

the OIDs are expanded to an oid-constructor function applied both to a blockchain name and to a link or a path of links/paths (with these 'structured' OIDs, the level of expressiveness moves from Datalog to Horn logic).

Even if, in the facts, the link names are unique already without the blockchain names, the oid-constructor function is needed, in the rules, for the recursive accumulation of links/paths to paths.

Thus, while -- in Gridcoin -- GridBlock2 occurs as a src as well as a trg, no cyclic connection is represented, since
these occurrences are for different links, GridLink2 and GridLink1, which are parameters of the src/trg-described different OIDs, oid(Gridcoin GridLink2) and oid(Gridcoin GridLink1), respectively.

The facts can be visualized with arrows starting at the predicate Link, having an OID (retained as a symbolic oid-constructor-function application) as member, and continuing as directed arcs for slots labeled with the slot names, where the OID-cutting segment indicates predicate dependence of the slots (the inverse-member arrow head points to the OID while the regular arrow head points to the slot fillers).

The resulting directed labeled graph, visualized as a directed labelnode hypergraph, has structured-OID nodes typed by the shared (copied) predicate labelnode Link and consists of four subgraphs among whose other nodes two (GridBlock2 and ChiaBlock2) are shared across pairs of subgraphs (where the diagram again keeps node copies rather than merging them):

The semantics of this KB can be formalized by an object-relational Herbrand model containing single-slot pairpoint atoms, each with a -- structured -- OID and a dependent slot.[22]
Since this KB uses atoms with two slots, these are normalized, via describution, to -- KB-level -- OID-coreferenced conjuncts of atoms with one slot each (to keep track of the source's atomic facts, the ten subconjunctions resulting from them are again shown on the same lines):

The KB can be queried in ways similar to the queries of our previous modeling,
demonstrating characteristic differences such as the sensitivity to the order of elements within the previous tuple vs. the insensitivity to the order between the current slots.

5.3 Binary Relpairpoints: OID; Dependent 2-Tuple; Dependent Slots

In this modeling, an oidful, dependent-tupled+slotted representation of relpairpoints is employed, systematically referred to as "pv6".

The modeling can be seen as modifying parts of the two previous subsections and combining them.

Modifications in the facts:

From Subsection 5.1, we refine the OIDs and keep the tuples.

From Subsection 5.2, we keep the OIDs and replace the src/trg slot pairs with tuples.

The facts can be visualized accordingly:

Modifications in the rules:

From both modelings, we maintain the conclusion atoms' perspectivalness by extending the tuples dependent on the predicate Chain with also Chain-dependent length slots, which are not used for the predicate Link.

The semantics of this KB can be formalized by an object-relational Herbrand model containing (single-tuple) relationpoint atoms and single-slot pairpoint atoms, each with a -- structured -- OID as well as, respectively, a dependent tuple and a dependent slot.

Since this KB uses atoms with both a tuple and -- for extra information -- a slot, these are normalized, via describution, to -- KB-level -- OID-coreferenced conjuncts of atoms with one tuple or one slot each (to keep track of the derived atomic facts on the source level, the six subconjunctions resulting from them are again shown on the same lines).

We assume that an equivalent for the (finitely implemented) External built-in numeric-add function is available in model generation, e.g. in the form of a (finite) extensional addition-function table, of which only a row corresponding to numeric-add(1 1) = 2 is needed for the given facts.

(novel: objectal and object-relational) Herbrand models for the model-theoretic semantics and via

(hands-on: reproducible, modifiable, and extensible) PSOATransRun sample dialogs for the proof-theoretic semantics, as well as

illustrated by modeling transitive closure as a high-level aspect of blockchains like Gridcoin and Chia Network.

Future work includes:

PSOA RuleML and PSOATransRun:

GitHub-based improvements/extensions to the PSOATransRun engine as it co-evolves with the PSOA RuleML language (structured in PSOATransRun Development Agenda).

Completion of the Relax NG schema specification of the PSOA RuleML/XML serialization syntax.

Synthesis of the object-relational PSOA and the relational-functional Relfun, which both are semantically first-order (specifically, Horn-logic-level) integrations, into an object-relational-functional integration (cf. Footnote 8):

A semantically first-order 3-way integration could be conceived as a PSOA extended mainly by allowing oriented equalities in the KB and expression flattening (combinable with unesting).

A semantically higher-order 3-way integration could be based on Henkin Semantics as used, e.g., for TPTP THF.

on the level of Horn logic, for which translators from/to a controlled natural language such as the FODAL-expressive SBVR could then be realized;

on the level of semantically higher-order logic (cf. sub-item 1.3.2.), leading to a Higher-Order Modal Logic (HOML), where HOML RuleML/XML can already be translated to HOML TPTP (HOMLRuleML2TPTP).

Realization of a visualizer translating PSOA RuleML to SVG, covering the Grailog diagrams of this document as special cases of those in PSOAMetamodelGrailogWedding by adapting the Grailog KS Viz 2.0 visualizer for Hornlog RuleML with Equality.

Creation of more material for exploring PSOA RuleML and PSOATransRun (made available via Learn PSOA RuleML).

7 Footnotes

↑"PSOA RuleML" can be regarded as the concatenation of two acronyms for "Positional-Slotted Object-Applicative Rule Markup Language".

↑In a nutshell, "relational" formulas and Herbrand models consist of relationships (applying a predicate to one tuple of zero or more positional arguments) while -- on the opposite side of the PSOA design space -- "objectal" formulas and Herbrand models consist of framepoints (describing a typed object identifier by a bag of one or more name->filler slots) plus memberships (like framepoints but having zero slots). The whole being more than the sum of its parts, "object-relational" formulas and Herbrand models include framepoints as well as relationships, span the formulas and Herbrand models in between (e.g., frameships as well as relationpoints), and cover the entire design space.
As in the psoa tables of PSOA RuleML#Introduction, the suffix "ship" -- generalized from "relationship" -- uniformly indicates that a formula is not centered on an object identifier whereas the suffix "point" -- reminiscent of a graph node -- uniformly indicates that a formula is centered on an object identifier.

↑The orthogonality of the psoa-atom features in the 3D design space permits reasoning by analogy according to the schema a1 : b1 = a2 : b2, e.g. relationships : relationpoints = frameships : b2, where the solution b2=framepoints is obtained by transferring "oidfulness". Because such 'orthogonal analogy' permits the unique reconstruction of the -- core/comprehensive -- metamodel from its oidless (left columns of the psoa tables) or its oidful (right columns) half, the metamodel can be compactified to either of these halves. Since this compactification includes the names of atom kinds ("...ships" vs. "...points"), it also leads to terminological simplification.

↑While some of the slot-like pairs in other systems, e.g. JSON's "name/value pairs", constitute self-contained data collections (which can be represented as special expression-like Plexes in RuleML), PSOA RuleML 1.0's slots are descriptors in atoms. Although we will not detail predicate-independent tuples, both predicate-dependent and -independent slots will be exemplified.

↑The graph atoms called "pairpoints" have earlier only been referred to as "pv4", using PSOA's systematics of atoms (see the -- core -- psoa tables above and -- comprehensive -- in PSOA RuleML#Introduction, the metamodel in PSOAPerspectivalKnowledge, Appendix A, and the dynamic cube visualization in PSOAMetaViz). Like all psoa atoms of this 3D design space, pairpoints share two features with their distance-1 (immediate) neighbors: OIDs with relationpoints (pv2) and framepoints (pn4); slots as the only descriptors with pairships (pv3) and framepoints (pn4); the predicate dependence of all descriptors (referred to as the atom's "perspectivalness") with relationpoints (pv2) and pairships (pv3). Similarly, all psoa atoms (e.g.: pairpoints) share one feature (e.g.: perspectivalness) with their distance-2 neighbors (e.g.: relationships). Finally, they share no feature with their distance-3 neighbors (e.g.: pairpoints with shelfships; framepoints with relationships).

↑Using the most specific class/predicate in PSOA's (optional) subclass/subpredicate ("##") taxonomy (not further discussed in this document) achieves the highest precision, and vice versa. To represent an untyped OID, it is typed with the taxonomy's (predefined) unspecific root class/predicate (Top).

↑In PSOA RuleML Bridges Graph and Relational Databases, the tuple of relationships is first replaced with slots (arriving at pairships); then an OID is added (arriving at pairpoints). In the current document, relationships are first endowed with an OID (arriving at relationpoints, in the systematics referred to as "pv2"); then the tuple is replaced with slots (also arriving at pairpoints).

↑This example was adapted from the diagram on slide 227 of Functional-Logic Programming, connecting the current object-relational effort with functional-relational efforts for a possible 3-way object-relational-functional integration already prepared by PSOA employing a logic with (potentially, oriented) equality,
which in the current PSOATransRun engine is realized only for built-in function calls and unification (while the Relfun engine realizes "innermost narrowing"). Although Relfun and PSOA provide higher-order syntactic sugar, mostly by permitting operator variables (as exemplified here with predicate variables), they are semantically first-order.

↑Tree-shaped branching from the genesis-block root is typical for blockchains -- leading to "orphan blocks" -- and is covered by our link/chain representation, although it is not detailed here.

↑In databases, data without "NULL values" constitute ground facts while data with "NULL values" do not correspond to non-ground facts.

↑Unlike Prolog, PSOA generally also allows an "And"-prefixed conclusion conjunction of atoms, but this will not be needed here.

↑ Chain, as a transitive relation between ?X and ?Z, can be seen as an abstraction of what has been called a "transitive hash function" (Blockchain Explained) mapping ?X to ?Z.

↑While the non-relational Herbrand models in the current PSOA document correspond to the non-relational Tarski models in previous PSOA documents (e.g., in PSOAPerspectivalKnowledge, Section 5), the relational Herbrand models used -- for relational comparison and simplicity -- in the current PSOA document are actually also object-relationally generalized in the previous PSOA documents and in the PSOATransRun implementation: Objectification, not otherwise mentioned in the current document, endows even relational atoms with ('real' or 'virtual') OIDs, i.e. '(system-)objectifies' them, e.g. by wrapping OID existentials around oidless rule conclusions, so that object-relational querying is enabled in a uniform manner.

↑Such generalized graphs -- systematically used for PSOA atoms in PSOAMetamodelGrailogWedding -- are provided by Grailog, which can also be employed for the visualization of rules, composed from the visualization of atoms (as used for facts), but not shown here.

↑Logic Programming's (e.g., Prolog's) convention of omitting top-level Forall wrappers -- as in the abridged syntax of Section 2 -- is also optionally available in the current PSOATransRun, but KBs intended for reuse should always keep them.

↑For "(OID-)existential rules", i.e. rules whose conclusion is wrapped by an existential quantifier over an (OID) variable, we use Skolemization to eliminate the quantifier and replace the existential variable with a Skolem-function application.

↑In Sections 3.3 and 5.3 the Herbrand model cannot be represented as a single atomic query applying an arbitrary predicate to an arbitrary argument pattern, and the disjunction-like use of two non-ground atomic queries will be required to let top-down derivation perform model generation.

↑Such (OID-)typed framepoints with a single independent slot correspond to (subject-)typed extensions of RDF/SPARQL "triples", namely to a variety of quadruples.

↑These transformations target -- conjunctions of (applications of) -- reserved (relational) runtime predicates such as the binary memterm for memberships and the ternary sloterm for single-slot framepoints. Given these encodings with a handful of reserved names (PSOAPerspectivalKnowledge, Section 6), the transformations can be seen to be semantics preserving by establishing bijective mappings between each objectal Herbrand model and a relational Herbrand model used for its realization. For example, the blockchain KB's objectal Herbrand model corresponds, one-to-one, to the relational Herbrand model { memterm(Block1,Block), ..., sloterm(Block1,chain,Block3) }, using Prolog's ground-atom syntax except for allowing upper-cased constants. PSOATransRun's target engines for ISO Prolog and TPTP can then be seen as implementing this relational Herbrand semantics. Similar non-relational-to-relational transformations are done for all other non-relational PSOA atoms. Inverse transformations, e.g. mapping from relational to objectal Herbrand models, are also possible, such as when targeting objectal (graph) engines.

↑Using an extended PSOA with tuples that can have a positional rest (see PSOAObjRelDataRules, Section 6), such nestings of binary constructor-function applications could be avoided.

↑For such structured OIDs or for structured arguments -- moving from Datalog to Horn logic -- Herbrand models can become infinite, e.g. for KBs with cyclic Link facts (such as when replacing the second fact of the considered KB with oid(Gridcoin GridLink2)#Link(src+>GridBlock2 trg+>GridBlock1) to generate arbitrarily long -- nesting-represented -- paths cycling over GridBlock1 and GridBlock2), although these are not allowed in (DAG-shaped) blockchains.

↑For Chains that start with the genesis block, the lengths can be fed into a maximum computation for determining the "main chain".