Learn PSOA RuleML: Object-Relational Data and Rules Illustrated by Blockchains

From RuleML Wiki
Jump to: navigation, search

Author: Harold Boley
RuleML Technical Memo


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 objects (graphs), relations (tables), as well as their systematic integration and extension. Querying of such representations is 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 rows of tables), e.g. in SQL, have been ubiquitous,
  • objects (defined by nodes with outgoing labeled arcs of graphs), 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.

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 "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 "independent" of, or "dependent" on, the predicate;[2] our focused FOL fragment of Horn logic provides -- non-atomic -- implication formulas as rules.
  • The notion of a relational database as a set of tables will be adapted by prefixing each table row (e.g., a tuple), becoming an atomic fact, with the relation name of its table becoming the predicate acting as a relator, so that -- throughout Sections 2, 3.1, and 4 to 7 -- the finest level of granularity is achieved with such relational atoms (for one dependent tuple: to be called "relationships").
  • The notion of an atom's Object IDentifier (OID) will correspond -- not yet in Sections 2 or 3.1 but in Sections 3.2, 3.3, and 9 -- 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", and to be called "framepoints"; for dependent slots: to be called "pairpoints"[3], as a bridge between "pairships" and "framepoints").
  • Characteristic -- symbolic -- 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 begin with (relator-headed, tuple-applied) "relationships" for relational KBs, with PSOA's predicates acting as relators, and proceed to (OID-headed, slot-applied) "framepoints" and "pairpoints" for graph KBs (cf. knowledge graphs), where all OIDs are typed by PSOA's predicates acting as classes -- enabling taxonomic precision[4] -- and where framepoint / pairpoint slots are independent of / dependent on those predicates,

We 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 augmented.

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 (hyper)arcs become 'reified' as OID nodes, e.g. in Section 9.

The following diagram series of directed labeled graphs[6] 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[7], 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 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)[8] 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[9], 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:[10]

  • 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, i.e. the set including (only)

  • the KB's initial ground facts (directly given or ground-instantiated from non-ground facts) as well as
  • all ground facts
    • derivable from the initial ground facts by any rules,
    • all ground facts derivable from the initial plus derived ground facts by any rules,
    • and so on,
  • until the (least) fixpoint is reached (and the rules -- after having made the implicit knowledge explicit -- are no longer needed).

Here, the fixpoint is reached in two iterations and this is the Herbrand model:

Link(Block1 Block2),
  Link(Block2 Block3),
  Chain(Block1 Block2),
  Chain(Block2 Block3),
  Chain(Block1 Block3) }

3 PSOA Representation and Querying

The following three subsections will discuss PSOA characteristics using transitive closure as an example in the single-blockchain scenario.

3.1 Binary Relationships: No OID; Dependent 2-Tuple

In the above diagram form, the green Link arrows visualize the facts as directed arcs of directed labeled subgraphs (which happen to be linear).

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

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

Hence -- also including the RuleML root and an Assert performative -- this is the presentation syntax of the above KB 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 color coding):

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, where the rules, like in the Herbrand semantics, make the implicit knowledge explicit.

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 query & answer steps thus exemplify PSOA RuleML's procedural / proof-theoretic semantics (for its model-theoretic semantics we use Herbrand models here and Tarski models in PSOAPerspectivalKnowledge, Section 5, both being equivalent on the level of Horn logic).

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

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

In the alternative diagram form of typed directed labeled graphs, nodes with outgoing regular arrows are explicitly typed by some class, in PSOA by a predicate, here Block, acting as a class. Arrows with an inverse-member head point from the predicate to the OIDs it types, here to Block1 and Block2, while arrows with a regular head represent slots pointing from an OID to slot fillers, here to Block2 and Block3, respectively. For the facts, the only slot name (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).[13]

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

3.3 Hybrid Rules: Relationship Conclusion; Framepoint Condition

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

These compositions can be hybrid (as in the current subsection) or homogeneous (as everywhere else in this document).

In a merger 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) )
    )

  )
)

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

4 Advancing 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, an OID will be used for enriched atoms.

5 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 (e.g., 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) )
    )

  )
)

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

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

6 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 put somewhere outside the block parameters using one of the following methods.

7 Interlude: 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 (PSOATransRun Development Agenda), although they are in the Relfun engine, employing syntax like -- for this fact and rule -- link[gridcoin](gridBlock1,gridBlock2). and chain[W](X,Y) :- link[W](X,Y).

8 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 'reifies' 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 (tuples and slots) via retrieval, inheritance, or general deduction (e.g., a deduced length slot will be added in Section 10).

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

  )
)

Remark: The four facts 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])

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

% 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=Gridcoin ?A=GridBlock1 ?B=GridBlock3
% ?O=Chiantwk ?A=ChiaBlock1 ?B=ChiaBlock2
% ?O=Chiantwk ?A=ChiaBlock2 ?B=ChiaBlock3
% ?O=Chiantwk ?A=ChiaBlock1 ?B=ChiaBlock3

9 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 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 10 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 derive 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)[14].

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

  )
)

This 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(Gridcoin path(GridLink1 GridLink2)) ?A=GridBlock1 ?B=GridBlock3
% ?O=oid(Chiantwk ChiaLink1) ?A=ChiaBlock1 ?B=ChiaBlock2
% ?O=oid(Chiantwk ChiaLink2) ?A=ChiaBlock2 ?B=ChiaBlock3
% ?O=oid(Chiantwk path(ChiaLink1 ChiaLink2)) ?A=ChiaBlock1 ?B=ChiaBlock3

10 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 sections and combining them.

Modifications in the facts:

  • From Section 8, we refine the OIDs and keep the tuples.
  • From Section 9, 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 extend the tuples with a length slot dependent on the predicate Chain, and not used for the predicate Link.
    • Unlike for an independent len slot, the 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).

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)[15]

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

  )
)

This KB can be queried in ways similar to the queries of our two previous modelings.

% 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

11 Conclusions

PSOA RuleML permits using a single language for deductive modeling in

  • the object-centered (graph-based) and
  • relational (table-based) paradigms as well as
  • their combinations and with further systematically constructed atoms.

Object-relational characteristics of PSOA RuleML were illustrated by modeling high-level aspects such as transitive closure of the blockchains 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 6):
      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 7) and determining the main chain (cf. Footnote 15).
      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

12 Footnotes

  1. "PSOA RuleML" can be regarded as the concatenation of two acronyms for "Positional-Slotted Object-Applicative Rule Markup Language".
  2. 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-independent and -dependent slots will be exemplified.
  3. 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 system, 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).
  4. 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).
  5. 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).
  6. 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, they are semantically first-order.
  7. 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.
  8. In databases, data without "NULL values" constitute ground facts while data with "NULL values" do not correspond to non-ground facts.
  9. Unlike Prolog, PSOA generally also allows an "And"-prefixed conclusion conjunction of atoms, but this will not be needed here.
  10. 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.
  11. 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.
  12. 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.
  13. Such (OID-)typed framepoints with a single independent slot correspond to (subject-)typed extensions of RDF/SPARQL "triples", namely to a variety of quadruples.
  14. 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.
  15. For Chains that start with the genesis block, the lengths can be fed into a maximum computation for determining the "main chain".