PSOA RuleML Explained with Blockchain Examples: Grailog Visualizations, Herbrand Models, and PSOATransRun Queries

From RuleML Wiki
Jump to: navigation, search

Author: Harold Boley
RuleML Technical Report


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.

1 Introduction

PSOA RuleML[1], or PSOA for short, is a language for representing data (facts) and knowledge (mainly, rules).

PSOA's reference engine PSOATransRun can be used for querying facts directly ("retrieval") or indirectly via rules ("deduction").

PSOA RuleML and PSOATransRun have been used for building deductive query-answering prototypes, which can become components of, e.g., (Geospatial, Medical, and Legal) AI systems.

Since facts can be regarded as special rules with a trivially true (hence usually omitted) condition, we will emphasize rules; in this view, knowledge bases (KBs) subsume databases.

For knowledge -- hence data -- representation, while:

  • relations (defined by table rows), e.g. in SQL, have been ubiquitous,
  • objects (defined by graph nodes with outgoing labeled arcs), e.g. in RDF/SPARQL (where an arc's source node is called "subject" and its target is called "object"),
    • have also been increasingly used, and
    • the PGQL/G-CORE/Cypher-fused property graph query language GQL is being proposed as an industry standard.

We will discuss PSOA's cross-paradigm object-relational KBs in a step-wise manner,

  • visualizing relations, objects, etc. with generalized (hyper)graphs in an extended Graph inscribed logic (Grailog),
  • using
    • relational Herbrand models
(over given relational formulas) and
introducing
  • objectal and object-relational Herbrand models
(over normalized objectal and object-relational formulas, respectively)[2]
for an intuitive model-theoretic semantics, as well as
  • querying KBs, demoing the answers from the PSOATransRun realization,
for an interactive proof-theoretic semantics.

Outline of basic notions:

  • The notion of an atomic formula (atom) from first-order logic (FOL) will be extended by allowing its predicate to be applied
    • not only to a (usually implicit) "tuple" of arguments
    • but also to "slots" pairing selector-style "names" with the proper arguments as "fillers" (cf. "attribute-value pairs", "key-value pairs", etc.),
    • where the interpretation of such tupled and slotted "descriptors" can be "dependent" on, or "independent" of, the predicate.[3]
Our focused FOL fragment of Horn logic provides assertions of
  • such atoms as facts, and of
  • implication formulas containing such atoms as rules.
  • The notion of a relational database as a set of tables will be adapted
    • by prefixing
      • each table row (here, a tuple), becoming an atomic fact,
      • with the relation name of its table as the predicate (acting as a relator),
    so that -- throughout Sections 2, 3.1, and 4.2 -- the finest level of granularity is achieved
    • via facts asserting relational atoms (for one dependent tuple: to be called "relationships").
  • The notion of an atom's Object IDentifier (OID) -- not yet in Sections 2 or 3.1 but in Sections 3.2, 3.3, and 5.2 -- will correspond to
    • a graph node where the atom's slots correspond to directed labeled arcs to other nodes,
so that
  • an arbitrary directed labeled graph is constituted by a set (KB) of such graph atoms:
    • for independent slots: earlier called "frames", henceforth to be called "framepoints";
    • for dependent slots: to be called "pairpoints"[4], as a bridge between "pairships" and "framepoints".

Characteristic -- symbolical -- notions for all kinds of atoms will be -- analogically -- visualized by generalized graphs using Grailog's extension for PSOA's atom systematics (PSOAMetamodelGrailogWedding), where

[perhaps surprisingly] relational tuples become directed (predicate-)labelnode-started hyperarcs and
[rather unsurprisingly] slots become directed (slot-name-)labeled arcs.

We will show

[relator-headed, tuple-applied] "relationships" for relational KBs, with PSOA's predicates acting as relators, in contrast to
[OID-headed, slot-applied] "pairpoints" and "framepoints" for graph KBs (cf. knowledge graphs), where
  • all OIDs are typed by PSOA's predicates acting as classes -- enabling taxonomic precision[5] -- and
  • pairpoint / framepoint slots are dependent on / independent of those predicates.

This will

We will develop KB examples modeling aspects of blockchains on a high level, illustrated by the environmentally aware 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[7] 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[8], along with all of their possible chains (red arrows):

LinkChainTransitiveClosureA.png LinkChainTransitiveClosureB.png LinkChainTransitiveClosureC.png

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).

PSOA KBs employ formal-logical representations of such natural-language statements.

The representations are built from atoms, each basically applying a predicate to arguments:

  • Facts are atoms (usually, ground, i.e. not containing variables)[9] that apply
    • a predicate, here Link,
    • to arguments, here
      • to Block1 followed by Block2 and
      • to Block2 followed by Block3.
  • Rules are of the form conclusion :- condition (usually, non-ground, i.e. containing variables), with the Prolog-like infix ":-" corresponding to the above "if",
    • deducing a conclusion atom[10], here Chain(?X ...), with "?"-prefixed variables ?X etc.,
      • from a condition atom, here from Link(...), or
      • 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:[11]

  • 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.

The semantics of a KB like this can be formalized by its (least) Herbrand model (cf. Foundations of Logic Programming), i.e. the set containing (only)

  • the KB's initial ground facts (directly given or ground-instantiated from non-ground facts) as well as
  • all ground facts derived, by (1-step, forward / bottom-up applications of) all rules, from
    [1] the [0]-generated (initial) ground facts,
    [2] the [1]-generated ([0]-generated or [1]-derived) ground facts,
    [3] the [2]-generated ([1]-generated or [2]-derived) ground facts,
    . . .,
    [i+1] the [i]-generated ([i-1]-generated or [i]-derived) ground facts (i ≥ 1),
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.[12]

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).[13]

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:


LinkOIDlessTupleBinary.png


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

Forall variables ( rule )

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

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 "%"):

RuleML (
  Assert (

    % Facts
    Link(Block1 Block2)
    Link(Block2 Block3)

    % Rules
    Forall ?X ?Y (
      Chain(?X ?Y) :- Link(?X ?Y)
    )
    Forall ?X ?Y ?Z (
      Chain(?X ?Z) :- And( Link(?X ?Y) Chain(?Y ?Z) )
    )

  )
)

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

  • exemplify PSOA RuleML's proof-theoretic semantics,
  • complementing its model-theoretic semantics using
(both model theories are equivalent on the level of Horn logic)[15].

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.[16]

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):

% Ground queries of facts

Link(Block1 Block2)
% Yes

Link(Block2 Block1)
% No

Link(Block2 Block3)
% Yes

Link(Block1 Block3)
% No

And( Link(Block1 Block2) Link(Block2 Block3) )
% Yes
% Non-ground queries of facts

Link(Block1 ?B)
% ?B=Block2

Link(Block2 ?B)
% ?B=Block3

Link(?A ?B)
% ?A=Block1 ?B=Block2
% ?A=Block2 ?B=Block3

And( Link(Block1 ?B) Link(?B Block3) )
% ?B=Block2

And( Link(?A ?B) Link(?B ?C) )
% ?A=Block1 ?B=Block2 ?C=Block3
% Ground queries of rules
Chain(Block1 Block2)
% Yes

Chain(Block2 Block3)
% Yes

Chain(Block1 Block3)
% Yes
% Non-ground queries of rules

Chain(Block1 ?B)
% ?B=Block2
% ?B=Block3

Chain(Block2 ?B)
% ?B=Block3

Chain(?A ?B)
% ?A=Block1 ?B=Block2
% ?A=Block2 ?B=Block3
% ?A=Block1 ?B=Block3
% Totally non-ground query, with predicate variable, of all facts and rules

?P(?A ?B)
% ?P=Link ?A=Block1 ?B=Block2
% ?P=Link ?A=Block2 ?B=Block3
% ?P=Chain ?A=Block1 ?B=Block2
% ?P=Chain ?A=Block2 ?B=Block3
% ?P=Chain ?A=Block1 ?B=Block3

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:


BlockOIDfulSlotIndep.png


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).[17]

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):

RuleML (
  Assert (

    % Facts
    Block1#Block(link->Block2)
    Block2#Block(link->Block3)

    % Rules
    Forall ?X ?Y (
      ?X#Block(chain->?Y) :- ?X#Block(link->?Y)
    )
    Forall ?X ?Y ?Z (
      ?X#Block(chain->?Z) :- And( ?X#Block(link->?Y) ?Y#Block(chain->?Z) )
    )

  )
)

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
  • membership atoms, each with an OID and a predicate.

Since the KB uses atoms with only predicate-independent slots,

  • their predicate, Block, is normalized, via describution (here, slotribution), to the root predicate, Top[18],
  • 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.[19]

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.

% Ground queries of facts

Block1#Block(link->Block2)
% Yes

Block2#Block(link->Block1)
% No

Block2#Block(link->Block3)
% Yes

Block1#Block(link->Block3)
% No

And( Block1#Block(link->Block2) Block2#Block(link->Block3) )
% Yes
% Non-ground queries of facts

Block1#Block(link->?B)
% ?B=Block2

Block2#Block(link->?B)
% ?B=Block3

?A#Block(link->?B)
% ?A=Block1 ?B=Block2
% ?A=Block2 ?B=Block3

And( Block1#Block(link->?B) ?B#Block(link->Block3) )
% ?B=Block2

And( ?A#Block(link->?B) ?B#Block(link->?C) )
% ?A=Block1 ?B=Block2 ?C=Block3
% Ground queries of rules
Block1#Block(chain->Block2)
% Yes

Block2#Block(chain->Block3)
% Yes

Block1#Block(chain->Block3)
% Yes
% Non-ground queries of rules

Block1#Block(chain->?B)
% ?B=Block2
% ?B=Block3

Block2#Block(chain->?B)
% ?B=Block3

?A#Block(chain->?B)
% ?A=Block1 ?B=Block2
% ?A=Block2 ?B=Block3
% ?A=Block1 ?B=Block3
% Non-ground query, with predicate constant and slot-name variable, of all facts and rules

?A#Block(?n->?B)
% ?n=link ?A=Block1 ?B=Block2
% ?n=link ?A=Block2 ?B=Block3
% ?n=chain ?A=Block1 ?B=Block2
% ?n=chain ?A=Block2 ?B=Block3
% ?n=chain ?A=Block1 ?B=Block3

3.3 Hybrid Rules: Relationship Conclusion; Framepoint Condition

All atoms from PSOA's systematics can be freely composed to build rules.

Across rule conclusions and conditions, these compositions can be hybrid (as in the current subsection) or homogeneous (as everywhere else in this document).

In a synthesis of the KBs of the two previous subsections, a hybrid KB is built thus:

  • The Block-framepoint facts from Subsection 3.2 are reused without change.
  • The rules use
    • the Block-framepoint conditions from Subsection 3.2 and
    • the Chain-relationship condition and conclusions from Subsection 3.1.

The symbolic form is as follows:

RuleML (
  Assert (

    % Facts
    Block1#Block(link->Block2)
    Block2#Block(link->Block3)

    % Rules
    Forall ?X ?Y (
      Chain(?X ?Y) :- ?X#Block(link->?Y)
    )
    Forall ?X ?Y ?Z (
      Chain(?X ?Z) :- And( ?X#Block(link->?Y) Chain(?Y ?Z) )
    )

  )
)

The semantics of this KB can be obtained as an object-relational Herbrand model by synthesizing the Herbrand models of the two previous KBs

  • in Subsection 3.2, for the given facts containing framepoints and memberships, and
  • in Subsection 3.1, for the rule-derived facts containing relationships (although the rules' Block conditions will now be satisfied by the facts from Subsection 3.2).

Object-relational Herbrand model:

Block1#Block, Block1#Top(link->Block2),
  Block2#Block, Block2#Top(link->Block3),
  Chain(Block1 Block2),
  Chain(Block2 Block3),
  Chain(Block1 Block3) }

The KB can be queried by combining the querying of the two previous KBs,

  • for fact querying as in Subsection 3.2, and
  • for rule querying as in Subsection 3.1 (although the rules' Block conditions will now work as in Subsection 3.2).

Since these are the exact counterparts to the relationship and framepoint queries in the two previous subsections, they will produce identical answers.

We directly give the query & answer interaction group corresponding to the Herbrand model:

% Non-ground queries of all facts and rules
% (corresponding disjunctive query has union of answers)

?A#Block(link->?B)    % Fact querying only
% ?A=Block1 ?B=Block2
% ?A=Block2 ?B=Block3

Chain(?A ?B)          % Rule querying only
% ?A=Block1 ?B=Block2
% ?A=Block2 ?B=Block3
% ?A=Block1 ?B=Block3

4 Blockchain Names as Extra Arguments vs. Separate Parameters

The following subsections will proceed to multiple blockchains (first subsection), give a PSOA representation where an extra argument captures blockchain names (second subsection), introduce blockchain/block-parameter separation, and sketch parameterized predicates for such separation (fourth subsection).

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):


LinkOIDlessTupleTernary.png


The symbolic form of the entire KB adds corresponding rules:

RuleML (
  Assert (

    % Facts
    Link(Gridcoin GridBlock1 GridBlock2)
    Link(Gridcoin GridBlock2 GridBlock3)
    Link(Chiantwk ChiaBlock1 ChiaBlock2)
    Link(Chiantwk ChiaBlock2 ChiaBlock3)

    % Rules
    Forall ?W ?X ?Y (
      Chain(?W ?X ?Y) :- Link(?W ?X ?Y)
    )
    Forall ?W ?X ?Y ?Z (
      Chain(?W ?X ?Z) :- And( Link(?W ?X ?Y) Chain(?W ?Y ?Z) )
    )

  )
)

Note: The rules keep each Chain within one of the blockchains by employing the same variable, ?W, for all blockchain-name occurrences.

The semantics of this KB can be formalized by a relational Herbrand model:

Link(Gridcoin GridBlock1 GridBlock2),
  Link(Gridcoin GridBlock2 GridBlock3),
  Link(Chiantwk ChiaBlock1 ChiaBlock2),
  Link(Chiantwk ChiaBlock2 ChiaBlock3),
  Chain(Gridcoin GridBlock1 GridBlock2),
  Chain(Gridcoin GridBlock2 GridBlock3),
  Chain(Chiantwk ChiaBlock1 ChiaBlock2),
  Chain(Chiantwk ChiaBlock2 ChiaBlock3),
  Chain(Gridcoin GridBlock1 GridBlock3),
  Chain(Chiantwk ChiaBlock1 ChiaBlock3) }

The KB can be queried similarly to the single-blockchain KB of Section 3.1 by giving the blocks a blockchain prefix and augmenting the predicates with a first-argument blockchain constant or variable.

We again directly give the query & answer interaction group corresponding to the Herbrand model:

% Totally non-ground query, with predicate variable, of all facts and rules

?P(?M ?A ?B)
?P=Link ?M=Gridcoin ?A=GridBlock1 ?B=GridBlock2
?P=Link ?M=Gridcoin ?A=GridBlock2 ?B=GridBlock3
?P=Link ?M=Chiantwk ?A=ChiaBlock1 ?B=ChiaBlock2
?P=Link ?M=Chiantwk ?A=ChiaBlock2 ?B=ChiaBlock3
?P=Chain ?M=Gridcoin ?A=GridBlock1 ?B=GridBlock2
?P=Chain ?M=Gridcoin ?A=GridBlock2 ?B=GridBlock3
?P=Chain ?M=Chiantwk ?A=ChiaBlock1 ?B=ChiaBlock2
?P=Chain ?M=Chiantwk ?A=ChiaBlock2 ?B=ChiaBlock3
?P=Chain ?M=Gridcoin ?A=GridBlock1 ?B=GridBlock3
?P=Chain ?M=Chiantwk ?A=ChiaBlock1 ?B=ChiaBlock3

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):


LinkOIDfulTupleBinary.png


The symbolic form of the entire KB adds corresponding rules:

RuleML (
  Assert (

    % Facts
    Gridcoin#Link(GridBlock1 GridBlock2)
    Gridcoin#Link(GridBlock2 GridBlock3)
    Chiantwk#Link(ChiaBlock1 ChiaBlock2)
    Chiantwk#Link(ChiaBlock2 ChiaBlock3)

    % Rules
    Forall ?W ?X ?Y (
      ?W#Chain(?X ?Y) :- ?W#Link(?X ?Y)
    )
    Forall ?W ?X ?Y ?Z (
      ?W#Chain(?X ?Z) :- And( ?W#Link(?X ?Y) ?W#Chain(?Y ?Z) )
    )

  )
)

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):

Gridcoin#Link(+[GridBlock1 GridBlock2] +[GridBlock2 GridBlock3])
Chiantwk#Link(+[ChiaBlock1 ChiaBlock2] +[ChiaBlock2 ChiaBlock3])

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.

% Ground queries of Gridcoin facts

Gridcoin#Link(GridBlock1 GridBlock2)
% Yes

Gridcoin#Link(GridBlock2 GridBlock3)
% Yes

Gridcoin#Link(GridBlock1 GridBlock3)
% No

And( Gridcoin#Link(GridBlock1 GridBlock2) Gridcoin#Link(GridBlock2 GridBlock3) )
% Yes
% Ground queries of Chiantwk facts

Chiantwk#Link(ChiaBlock1 ChiaBlock2)
% Yes
% . . .
% Ground queries of mixed facts

Gridcoin#Link(ChiaBlock1 ChiaBlock2)
% No

Chiantwk#Link(GridBlock1 GridBlock2)
% No
% . . .
% Non-ground queries of Gridcoin and Chiantwk facts

Gridcoin#Link(GridBlock1 ?B)
% ?B=GridBlock2

?O#Link(GridBlock2 ?B)
% ?O=Gridcoin ?B=GridBlock3

?O#Link(?A ?B)
% ?O=Gridcoin ?A=GridBlock1 ?B=GridBlock2
% ?O=Gridcoin ?A=GridBlock2 ?B=GridBlock3
% ?O=Chiantwk ?A=ChiaBlock1 ?B=ChiaBlock2
% ?O=Chiantwk ?A=ChiaBlock2 ?B=ChiaBlock3

And( ?O#Link(GridBlock1 ?B) ?O#Link(?B GridBlock3) )
% ?O=Gridcoin ?B=GridBlock2

And( ?O#Link(?A ?B) ?O#Link(?B ?C) )
% ?O=Gridcoin ?A=GridBlock1 ?B=GridBlock2 ?C=GridBlock3
% ?O=Chiantwk ?A=ChiaBlock1 ?B=ChiaBlock2 ?C=ChiaBlock3
% Ground queries of rules with Gridcoin

Gridcoin#Chain(GridBlock1 GridBlock2)
% Yes

Gridcoin#Chain(GridBlock2 GridBlock3)
% Yes

Gridcoin#Chain(GridBlock1 GridBlock3)
% Yes
% Ground queries of rules with Chiantwk

Chiantwk#Chain(ChiaBlock1 ChiaBlock2)
% Yes
% . . .
% Non-ground queries of rules with Gridcoin and Chiantwk

?O#Chain(GridBlock1 ?B)
% ?O=Gridcoin ?B=GridBlock2
% ?O=Gridcoin ?B=GridBlock3

?O#Chain(GridBlock2 ?B)
% ?O=Gridcoin ?B=GridBlock3

?O#Chain(?A ?B)
% ?O=Gridcoin ?A=GridBlock1 ?B=GridBlock2
% ?O=Gridcoin ?A=GridBlock2 ?B=GridBlock3
% ?O=Chiantwk ?A=ChiaBlock1 ?B=ChiaBlock2
% ?O=Chiantwk ?A=ChiaBlock2 ?B=ChiaBlock3
% ?O=Gridcoin ?A=GridBlock1 ?B=GridBlock3
% ?O=Chiantwk ?A=ChiaBlock1 ?B=ChiaBlock3
% Totally non-ground query, with predicate variable, of all facts and rules

?O#?P(?A ?B)
% ?O=Gridcoin ?P=Link ?A=GridBlock1 ?B=GridBlock2
% ?O=Gridcoin ?P=Link ?A=GridBlock2 ?B=GridBlock3
% ?O=Chiantwk ?P=Link ?A=ChiaBlock1 ?B=ChiaBlock2
% ?O=Chiantwk ?P=Link ?A=ChiaBlock2 ?B=ChiaBlock3
% ?O=Gridcoin ?P=Chain ?A=GridBlock1 ?B=GridBlock2
% ?O=Gridcoin ?P=Chain ?A=GridBlock2 ?B=GridBlock3
% ?O=Chiantwk ?P=Chain ?A=ChiaBlock1 ?B=ChiaBlock2
% ?O=Chiantwk ?P=Chain ?A=ChiaBlock2 ?B=ChiaBlock3
% ?O=Gridcoin ?P=Chain ?A=GridBlock1 ?B=GridBlock3
% ?O=Chiantwk ?P=Chain ?A=ChiaBlock1 ?B=ChiaBlock3

5.2 Pairpoints: OID; Dependent Slots

In this pairpoint modeling, an oidful, dependent-slotted representation is employed, systematically referred to as "pv4".

  • Here, each oidful atom applying a predicate to its dependent slots -- of the form slotname+>slotfiller -- constitutes a pairpoint.
  • Similarly, with predicate-independent slots -- of the form slotname->slotfiller -- it would constitute a framepoint (in the initial version of PSOA RuleML Bridges Graph and Relational Databases called a frame.)

Instead of 2-argument tuples from Link and Chain:

  • We employ two predicate-dependent slots with slot names
    • src (source, with first argument as slot filler) and
    • trg (target, with second argument as slot filler).
  • We prefer the dependence of the src/trg-named slots on the predicates Link vs. Chain to either
    1. 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
    2. introducing new names for predicate-independent slots such as
      1. 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
      2. differentiating predicate-independent slots with specialized -- mnemonic -- names like srcImmediate/trgImmediate for Link vs. srcUltimate/trgUltimate for Chain,
      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):


LinkOIDfulSlots.png


The symbolic form of the entire KB adds corresponding rules.

For Chain:

  • The base-case rule passes through the Link condition's link parameter ?L unchanged.
  • The transitive-closure rule constructs a link path from ?L and the recursive Chain result ?M (right-recursively nested)[20].

The rules still keep each Chain within one of the blockchains by employing the same blockchain parameter ?W for all blockchain-name occurrences.

RuleML (
  Assert (

    % Facts
    oid(Gridcoin GridLink1)#Link(src+>GridBlock1 trg+>GridBlock2)
    oid(Gridcoin GridLink2)#Link(src+>GridBlock2 trg+>GridBlock3)
    oid(Chiantwk ChiaLink1)#Link(src+>ChiaBlock1 trg+>ChiaBlock2)
    oid(Chiantwk ChiaLink2)#Link(src+>ChiaBlock2 trg+>ChiaBlock3)

    % Rules
    Forall ?W ?L ?X ?Y (
      oid(?W ?L)#Chain(src+>?X trg+>?Y) :-
        oid(?W ?L)#Link(src+>?X trg+>?Y)
    )
    Forall ?W ?L ?M ?X ?Y ?Z (
      oid(?W path(?L ?M))#Chain(src+>?X trg+>?Z) :-
        And( oid(?W ?L)#Link(src+>?X trg+>?Y)
             oid(?W ?M)#Chain(src+>?Y trg+>?Z) )
    )

  )
)

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.[21] 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):

oid(Gridcoin GridLink1)#Link(src+>GridBlock1), oid(Gridcoin GridLink1)#Link(trg+>GridBlock2),
  oid(Gridcoin GridLink2)#Link(src+>GridBlock2), oid(Gridcoin GridLink2)#Link(trg+>GridBlock3),
  oid(Chiantwk ChiaLink1)#Link(src+>ChiaBlock1), oid(Chiantwk ChiaLink1)#Link(trg+>ChiaBlock2),
  oid(Chiantwk ChiaLink2)#Link(src+>ChiaBlock2), oid(Chiantwk ChiaLink2)#Link(trg+>ChiaBlock3),
  oid(Gridcoin GridLink1)#Chain(src+>GridBlock1), oid(Gridcoin GridLink1)#Link(trg+>GridBlock2),
  oid(Gridcoin GridLink2)#Chain(src+>GridBlock2), oid(Gridcoin GridLink2)#Chain(trg+>GridBlock3),
  oid(Chiantwk ChiaLink1)#Chain(src+>ChiaBlock1), oid(Chiantwk ChiaLink1)#Chain(trg+>ChiaBlock2),
  oid(Chiantwk ChiaLink2)#Chain(src+>ChiaBlock2), oid(Chiantwk ChiaLink2)#Chain(trg+>ChiaBlock3),
  oid(Gridcoin path(GridLink1 GridLink2))#Chain(src+>GridBlock1), oid(Gridcoin path(GridLink1 GridLink2))#Chain(trg+>GridBlock3),
  oid(Chiantwk path(ChiaLink1 ChiaLink2))#Chain(src+>ChiaBlock1), oid(Chiantwk path(ChiaLink1 ChiaLink2))#Chain(trg+>ChiaBlock3) }

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.

% Fact queries with ground OIDs and ground slots

oid(Gridcoin GridLink1)#Link(src+>GridBlock1 trg+>GridBlock2)
% Yes

oid(Gridcoin GridLink1)#Link(trg+>GridBlock2 src+>GridBlock1)
% Yes

oid(Gridcoin GridLink1)#Link(src+>GridBlock1 src+>GridBlock1 trg+>GridBlock2)
% Yes

oid(Gridcoin GridLink1)#Link(src+>GridBlock1 mid+>GridBlock1 trg+>GridBlock2)
% No

oid(Gridcoin GridLink1)#Link(src+>GridBlock1)
% Yes

oid(Gridcoin GridLink1)#Link(trg+>GridBlock2)
% Yes

oid(Gridcoin GridLink1)#Link()
% Yes
% Fact queries with non-ground OIDs and ground slots

oid(Gridcoin ?D)#Link(src+>GridBlock1 trg+>GridBlock2)
% ?D=GridLink1

oid(?I GridLink1)#Link(src+>GridBlock1 trg+>GridBlock2)
% ?I=Gridcoin

oid(?I ?D)#Link(src+>GridBlock1 trg+>GridBlock2)
% ?I=Gridcoin ?D=GridLink1

?O#Link(src+>GridBlock1 trg+>GridBlock2)
% ?O=oid(Gridcoin GridLink1)
% Fact queries with ground/non-ground OIDs and non-ground slots

oid(Gridcoin GridLink1)#Link(src+>GridBlock1 trg+>?B)
% ?B=GridBlock2

?O#Link(src+>GridBlock2 trg+>?B)
% ?O=oid(Gridcoin GridLink2) ?B=GridBlock3

?O#Link(src+>?A trg+>?B)
% ?O=oid(Gridcoin GridLink1) ?A=GridBlock1 ?B=GridBlock2
% ?O=oid(Gridcoin GridLink2) ?A=GridBlock2 ?B=GridBlock3
% ?O=oid(Chiantwk ChiaLink1) ?A=ChiaBlock1 ?B=ChiaBlock2
% ?O=oid(Chiantwk ChiaLink2) ?A=ChiaBlock2 ?B=ChiaBlock3
% Rule queries with ground OIDs and ground slots

oid(Gridcoin GridLink1)#Chain(src+>GridBlock1 trg+>GridBlock2)
% Yes

oid(Gridcoin GridLink1)#Chain(src+>GridBlock2 trg+>GridBlock3)
% No

oid(Gridcoin GridLink2)#Chain(src+>GridBlock2 trg+>GridBlock3)
% Yes

oid(Gridcoin GridLink1)#Chain(src+>GridBlock1 trg+>GridBlock3)
% No

oid(Gridcoin GridLink2)#Chain(src+>GridBlock1 trg+>GridBlock3)
% No
% Rule queries with non-ground OIDs and ground/non-ground slots

oid(Gridcoin ?D)#Chain(src+>GridBlock1 trg+>GridBlock3)
% ?D=path(GridLink1 GridLink2)

?O#Chain(src+>GridBlock1 trg+>GridBlock3)
% ?O=oid(Gridcoin path(GridLink1 GridLink2))

?O#Chain(src+>GridBlock1 trg+>?B)
% ?O=oid(Gridcoin GridLink1) ?B=GridBlock2
% ?O=oid(Gridcoin path(GridLink1 GridLink2)) ?B=GridBlock3

?O#Chain(src+>GridBlock2 trg+>?B)
% ?O=oid(Gridcoin GridLink2) ?B=GridBlock3

?O#Chain(src+>?A trg+>?B)
% ?O=oid(Gridcoin GridLink1) ?A=GridBlock1 ?B=GridBlock2
% ?O=oid(Gridcoin GridLink2) ?A=GridBlock2 ?B=GridBlock3
% ?O=oid(Chiantwk ChiaLink1) ?A=ChiaBlock1 ?B=ChiaBlock2
% ?O=oid(Chiantwk ChiaLink2) ?A=ChiaBlock2 ?B=ChiaBlock3
% ?O=oid(Gridcoin path(GridLink1 GridLink2)) ?A=GridBlock1 ?B=GridBlock3
% ?O=oid(Chiantwk path(ChiaLink1 ChiaLink2)) ?A=ChiaBlock1 ?B=ChiaBlock3
% Non-ground query, with predicate variable, of all facts and rules

?O#?P(src+>?A trg+>?B)
% ?O=oid(Gridcoin GridLink1) ?P=Link ?A=GridBlock1 ?B=GridBlock2
% ?O=oid(Gridcoin GridLink2) ?P=Link ?A=GridBlock2 ?B=GridBlock3
% ?O=oid(Chiantwk ChiaLink1) ?P=Link ?A=ChiaBlock1 ?B=ChiaBlock2
% ?O=oid(Chiantwk ChiaLink2) ?P=Link ?A=ChiaBlock2 ?B=ChiaBlock3
% ?O=oid(Gridcoin GridLink1) ?P=Chain ?A=GridBlock1 ?B=GridBlock2
% ?O=oid(Gridcoin GridLink2) ?P=Chain ?A=GridBlock2 ?B=GridBlock3
% ?O=oid(Chiantwk ChiaLink1) ?P=Chain ?A=ChiaBlock1 ?B=ChiaBlock2
% ?O=oid(Chiantwk ChiaLink2) ?P=Chain ?A=ChiaBlock2 ?B=ChiaBlock3
% ?O=oid(Gridcoin path(GridLink1 GridLink2)) ?P=Chain ?A=GridBlock1 ?B=GridBlock3
% ?O=oid(Chiantwk path(ChiaLink1 ChiaLink2)) ?P=Chain ?A=ChiaBlock1 ?B=ChiaBlock3

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:


LinkOIDappTupleBinary.png


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.
    • Unlike for a possible independent len slot, the actual len dependence on Chain prevents that Chain's base-case rule will make Link queries display a len (of 1) although the Link facts' structured ground OIDs like oid(Gridcoin GridLink1) are 'subsumed' by the base-case rule's structured non-ground OID oid(?W ?L).
    • While an OID like oid(Gridcoin GridLink1) as a member of Chain thus has a -- derived -- len slot dependent on Chain, this OID as a member of Link has no -- given -- len slot.

The len slot captures the length of each (sub)Chain between arbitrary pairs of blocks (which need not start with the genesis block of a blockchain)[22]

For Chain:

  • In the base case, len records the length of 1 for one Link.
  • In the recursive case, the len filler ?J is computed by adding 1 to the recursive result ?I (using a Prefix declaration, the func: numeric-add built-in refers to a W3C RIF namespace).
RuleML (
  Prefix(func: <http://www.w3.org/2007/rif-builtin-function#>)
  Assert (

    % Facts
    oid(Gridcoin GridLink1)#Link(GridBlock1 GridBlock2)
    oid(Gridcoin GridLink2)#Link(GridBlock2 GridBlock3)
    oid(Chiantwk ChiaLink1)#Link(ChiaBlock1 ChiaBlock2)
    oid(Chiantwk ChiaLink2)#Link(ChiaBlock2 ChiaBlock3)

    % Rules
    Forall ?W ?L ?X ?Y (
      oid(?W ?L)#Chain(?X ?Y len+>1) :-
        oid(?W ?L)#Link(?X ?Y)
    )
    Forall ?W ?L ?M ?X ?Y ?Z (
      oid(?W path(?L ?M))#Chain(?X ?Z len+>?J) :-
        And( oid(?W ?L)#Link(?X ?Y)
             oid(?W ?M)#Chain(?Y ?Z len+>?I)
             ?J=External(func:numeric-add(1 ?I)) )
    )

  )
)

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.

oid(Gridcoin GridLink1)#Link(GridBlock1 GridBlock2),
  oid(Gridcoin GridLink2)#Link(GridBlock2 GridBlock3),
  oid(Chiantwk ChiaLink1)#Link(ChiaBlock1 ChiaBlock2),
  oid(Chiantwk ChiaLink2)#Link(ChiaBlock2 ChiaBlock3),
  oid(Gridcoin GridLink1)#Chain(GridBlock1 GridBlock2), oid(Gridcoin GridLink1)#Chain(len+>1),
  oid(Gridcoin GridLink2)#Chain(GridBlock2 GridBlock3), oid(Gridcoin GridLink2)#Chain(len+>1),
  oid(Chiantwk ChiaLink1)#Chain(ChiaBlock1 ChiaBlock2), oid(Chiantwk ChiaLink1)#Chain(len+>1),
  oid(Chiantwk ChiaLink2)#Chain(ChiaBlock2 ChiaBlock3), oid(Chiantwk ChiaLink2)#Chain(len+>1),
  oid(Gridcoin path(GridLink1 GridLink2))#Chain(GridBlock1 GridBlock3), oid(Gridcoin path(GridLink1 GridLink2))#Chain(len+>2),
  oid(Chiantwk path(ChiaLink1 ChiaLink2))#Chain(ChiaBlock1 ChiaBlock3), oid(Chiantwk path(ChiaLink1 ChiaLink2))#Chain(len+>2) }

The KB can be queried in ways similar to the queries of our two previous modelings, but with an extra len slot for Chain.

% Fact queries with ground/non-ground OIDs and ground tuple plus slot

oid(Gridcoin GridLink1)#Link(GridBlock1 GridBlock2)
% Yes

oid(Gridcoin GridLink1)#Link(GridBlock1 GridBlock2 len+>1)
% No

oid(Gridcoin ?D)#Link(GridBlock1 GridBlock2)
% ?D=GridLink1

oid(?I GridLink1)#Link(GridBlock1 GridBlock2)
% ?I=Gridcoin

oid(?I ?D)#Link(GridBlock1 GridBlock2)
% ?I=Gridcoin ?D=GridLink1

?O#Link(GridBlock1 GridBlock2)
% ?O=oid(Gridcoin GridLink1)
% Fact queries with ground/non-ground OIDs and non-ground tuples

oid(Gridcoin GridLink1)#Link(GridBlock1 ?B)
% ?B=GridBlock2

?O#Link(GridBlock1 ?B)
% ?O=oid(Gridcoin GridLink1) ?B=GridBlock2

?O#Link(GridBlock2 ?B)
% ?O=oid(Gridcoin GridLink2) ?B=GridBlock3

?O#Link(?A ?B)
% ?O=oid(Gridcoin GridLink1) ?A=GridBlock1 ?B=GridBlock2
% ?O=oid(Gridcoin GridLink2) ?A=GridBlock2 ?B=GridBlock3
% ?O=oid(Chiantwk ChiaLink1) ?A=ChiaBlock1 ?B=ChiaBlock2
% ?O=oid(Chiantwk ChiaLink2) ?A=ChiaBlock2 ?B=ChiaBlock3
% Rule queries with non-ground OID and ground/non-ground tuples plus slots

oid(Gridcoin ?D)#Chain(GridBlock1 GridBlock3)
% ?D=path(GridLink1 GridLink2)

oid(Gridcoin ?D)#Chain(GridBlock1 GridBlock3 len+>1)
% No

oid(Gridcoin ?D)#Chain(GridBlock1 GridBlock3 len+>2)
% ?D=path(GridLink1 GridLink2)

oid(Gridcoin ?D)#Chain(GridBlock1 GridBlock3 len+>?N)
% ?D=path(GridLink1 GridLink2) ?N=2

oid(Gridcoin ?D)#Chain(GridBlock1 ?B)
% ?D=GridLink1 ?B=GridBlock2
% ?D=path(GridLink1 GridLink2) ?B=GridBlock3

oid(Gridcoin ?D)#Chain(GridBlock1 ?B len+>?N)
% ?D=GridLink1 ?B=GridBlock2 ?N=1
% ?D=path(GridLink1 GridLink2) ?B=GridBlock3 ?N=2

oid(Gridcoin ?D)#Chain(GridBlock2 ?B len+>?N)
% ?D=GridLink2 ?B=GridBlock3 ?N=1

oid(Gridcoin ?D)#Chain(?A ?B len+>?N)
% ?D=GridLink1 ?A=GridBlock1 ?B=GridBlock2 ?N=1
% ?D=GridLink2 ?A=GridBlock2 ?B=GridBlock3 ?N=1
% ?D=path(GridLink1 GridLink2) ?A=GridBlock1 ?B=GridBlock3 ?N=2
% Non-ground queries, with predicate variables, of all facts and rules
% (corresponding disjunctive query has union of answers)

?O#?P(?A ?B)  % Totally non-ground
% ?O=oid(Gridcoin GridLink1) ?P=Link ?A=GridBlock1 ?B=GridBlock2
% ?O=oid(Gridcoin GridLink2) ?P=Link ?A=GridBlock2 ?B=GridBlock3
% ?O=oid(Chiantwk ChiaLink1) ?P=Link ?A=ChiaBlock1 ?B=ChiaBlock2
% ?O=oid(Chiantwk ChiaLink2) ?P=Link ?A=ChiaBlock2 ?B=ChiaBlock3
% ?O=oid(Gridcoin GridLink1) ?P=Chain ?A=GridBlock1 ?B=GridBlock2
% ?O=oid(Gridcoin GridLink2) ?P=Chain ?A=GridBlock2 ?B=GridBlock3
% ?O=oid(Chiantwk ChiaLink1) ?P=Chain ?A=ChiaBlock1 ?B=ChiaBlock2
% ?O=oid(Chiantwk ChiaLink2) ?P=Chain ?A=ChiaBlock2 ?B=ChiaBlock3
% ?O=oid(Gridcoin path(GridLink1 GridLink2)) ?P=Chain ?A=GridBlock1 ?B=GridBlock3
% ?O=oid(Chiantwk path(ChiaLink1 ChiaLink2)) ?P=Chain ?A=ChiaBlock1 ?B=ChiaBlock3

?O#?P(len+>?N)  % Non-ground with predicate variable and slot-name constant
% ?O=oid(Gridcoin GridLink1) ?P=Chain ?N=1
% ?O=oid(Gridcoin GridLink2) ?P=Chain ?N=1
% ?O=oid(Chiantwk ChiaLink1) ?P=Chain ?N=1
% ?O=oid(Chiantwk ChiaLink2) ?P=Chain ?N=1
% ?O=oid(Gridcoin path(GridLink1 GridLink2)) ?P=Chain ?N=2
% ?O=oid(Chiantwk path(ChiaLink1 ChiaLink2)) ?P=Chain ?N=2

6 Conclusions

PSOA RuleML permits using a single language

  • for cross-paradigm deductive modeling
    • in the objectal (graph-based) paradigm and
    • in the relational (table-based) paradigm, as well as
    • through their object-relational combinations,
covering PSOA's 3D design space of atoms,
whose most salient kinds were exemplified in this document.

Object-relational characteristics of PSOA RuleML were

  • visualized in a Grailog extension,
  • presented as
    • (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:

  1. PSOA RuleML and PSOATransRun:
    1. GitHub-based improvements/extensions to the PSOATransRun engine as it co-evolves with the PSOA RuleML language (structured in PSOATransRun Development Agenda).
    2. Completion of the Relax NG schema specification of the PSOA RuleML/XML serialization syntax.
    3. 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 7):
      1. 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).
      2. A semantically higher-order 3-way integration could be based on Henkin Semantics as used, e.g., for TPTP THF.
    4. Addition of an alethic logic, a deontic logic, or a combination of the two (e.g., FODAL RuleML Semantic Profile) to PSOA, for instance to facilitate the deontic formalization of obligations and permissions in smart contracts (cf. main item 2.):
      1. 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;
      2. 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).
    5. 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.
    6. Creation of more material for exploring PSOA RuleML and PSOATransRun (made available via Learn PSOA RuleML).
  2. Blockchains and smart contracts:
    1. Modeling other aspects of blockchains, e.g.:
      1. Proceeding from linear chains to tree-shaped branchings (cf. Footnote 8) and determining the main chain (cf. Footnote 22).
      2. Refining block names to OIDs whose descriptors represent the internal structure of blocks.
    2. Augmenting blockchains (e.g., modeled as KBs) by smart-contract KBs, in connection with related efforts such as:
      1. LegalRuleML Core Specification Version 1.0
      2. Medical Devices Rules
      3. Computable Contracts
      4. Logical Contracts

7 Footnotes

  1. "PSOA RuleML" can be regarded as the concatenation of two acronyms for "Positional-Slotted Object-Applicative Rule Markup Language".
  2. 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.
  3. 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.
  4. The graph atoms called "pairpoints" have earlier only been referred to as "pv4", using PSOA's systematics of atoms (see the psoa tables 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 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 (sometimes referred to as the atom's "perspectivalness") with relationpoints (pv2) and pairships (pv3).
  5. 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).
  6. 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).
  7. 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.
  8. 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.
  9. In databases, data without "NULL values" constitute ground facts while data with "NULL values" do not correspond to non-ground facts.
  10. Unlike Prolog, PSOA generally also allows an "And"-prefixed conclusion conjunction of atoms, but this will not be needed here.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. Such (OID-)typed framepoints with a single independent slot correspond to (subject-)typed extensions of RDF/SPARQL "triples", namely to a variety of quadruples.
  18. We may distinguish atoms with non-Top vs. Top predicates (PSOA RuleML Bridges Graph and Relational Databases, Section 2). For example, non-Top framepoints correspond to (F-logic-like) "typed frames"; Top framepoints, to (F-logic/RIF-like) "untyped frames". At the other end, non-Top relationships correspond to (logical) "non-universal-predicate applications"; Top relationships, to (logical) "universal-predicate applications" or, broadly, to ('content-addressing') "unspecific associations".
  19. 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.
  20. 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.
  21. 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.
  22. For Chains that start with the genesis block, the lengths can be fed into a maximum computation for determining the "main chain".