PSOA RuleML

From RuleML Wiki
Jump to: navigation, search

Authors: Harold Boley, Gen Zou, Theodoros Mitsikas, Mark Thom, Tara Athan, Rima Chaudhari


This is the main text about the multi-paradigm -- particularly, graph-relational -- data and rule language Positional-Slotted Object-Applicative RuleML (PSOA RuleML). If you are new to PSOA RuleML -- e.g., to its built-in paradigm bridging -- you may want to start at Learn PSOA RuleML.

PSOA RuleML permits an atom, i.e. a predicate application, to be [in an oidless/oidful dimension 1] without or with an Object IDentifier (OID) -- typed by the predicate -- and the arguments of the predicate to be [in an orthogonal (descriptor-)variety dimension 2] tupled, slotted, or tupled+slotted (a tuple has zero or more ordered elements while a slot is a pair of a name and a filler). Moreover, PSOA RuleML since Version 1.0 permits an atom to be [in an orthogonal (descriptor-)dependency dimension 3] independent (having only predicate-independent descriptors), dependent (having only predicate-dependent descriptors), or independent+dependent. The resulting positional-slotted object-applicative (psoa) atoms can be used as (oidless, tupled, dependent) relationship facts without an OID and with a dependent -- ordered -- sequence of arguments, as (oidful, slotted, independent) framepoint facts with an OID and with an -- unordered -- multiset of independent slots, and as all other kinds of facts from the 3D design space. For illustrating this systematics, the first section will present variations of a preview example regarding a business fact and rule. For another illustration see PSOA RuleML Explained with Blockchain Examples. Also, the slide Data in Perspective: The Rich TA Example as Grailog Visualization and PSOA RuleML Facts and the PSOAPerspectivalKnowledge paper focus on the dependency dimension as well as the broader notion of perspectivity (non-perspectival vs. perspectival).

Facts and rules over them are collectively referred to as clauses, and clauses are the main items in a Knowledge Base (KB). An atom/clause/KB is empty if it contains no descriptors/atoms/clauses. The following notions will be advanced:

Dimension of dependency
An (in)dependent atom/clause/KB is non-empty and has only (in)dependent descriptors/atoms/clauses; equivalently, an (in)dependent atom/clause/KB has at least one and has only (in)dependent descriptors/atoms/clauses. An independent+dependent atom has at least one independent descriptor and has at least one dependent descriptor, where each descriptor is either independent or dependent; an independent+dependent clause/KB has at least one independent atom/clause and has at least one dependent atom/clause or it has at least one independent+dependent atom/clause, where each atom/clause is either independent, dependent, or independent+dependent.
Characterization of perspectivity
A (non-)perspectival atom does (not) have some dependent descriptor; a (non-)perspectival clause/KB does (not) have some perspectival atom/clause.

Given these notions, two observations (and their reverses) can be made:

  1. If an atom/clause/KB is dependent then it is perspectival. (If an atom/clause/KB is perspectival then it is dependent or independent+dependent.)
  2. If an atom/clause/KB is independent then it is non-perspectival. (If an atom/clause/KB is non-perspectival then it is empty or independent.)

In the above-linked Rich TA Example, three clauses, all facts, constitute a perspectival and independent+dependent KB: The slot workload+>high is dependent on the predicate TA. The first fact is constituted by the single-slot atom John#TA(workload+>high), which is perspectival and dependent. The second fact is similar to the third. The slot gender->male is independent while the slots dept+>Physics and dept+>Math are dependent on, respectively, the predicates Teacher and Student. The third fact is constituted by the atom John#Student(... dept+>Math gender->male), equivalently John#Student(... gender->male dept+>Math), which is perspectival and independent+dependent.

These notions, e.g. perspectivity, can be further lifted from a single KB to knowledge representation with multiple KBs. Thus, perspectival knowledge representation makes use of at least one dependent descriptor in an atom of a clause of a KB. Moreover, there is a spectrum of perspectivalness from exactly one dependent descriptor (minimally perspectival knowledge) to only dependent descriptors (maximally perspectival knowledge, i.e. dependent knowledge).

Psoa KBs were given a first-order model-theoretic foundation (original paper and slides, revised paper and slides, as well as further revised paper and slides), allowing, e.g., to normalize -- via objectification -- any oidless atom of the systematics to an oidful atom, and -- via describution -- any oidful multi-descriptor atom to a conjunction of single-descriptor atoms (distributing the atom's OID over its descriptors). In order to support reasoning in PSOA RuleML, the PSOATransRun system has been developed, including a combination of 1) a normalizing translator PSOA2Prolog, from PSOA RuleML to a subset of the logic programming language ISO Prolog, with 2a) the highly efficient XSB Prolog engine or 2b) the very widespread SWI Prolog engine. See the Examples section for PSOATransRun-executable examples of PSOA RuleML knowledge bases, queries, and answers.

Contents

1 Presentation Preview

Using PSOA RuleML's presentation syntax, an example series can be demonstrated in the executable format of the reference implementation PSOATransRun (PSOATransRun Limitations will be designated). We will develop the example series based on relationship and framepoint versions of a business fact (about a purchase) -- and enabling corresponding versions of a business rule (about liability).

In PSOA RuleML's presentation syntax, a simple purchase predicate with three arguments, John, Mary, and Fido, can be represented as a relationship atom (the argument order is significant):

purchase(John Mary Fido)

In this implicit-tuple form, surrounded by the predicate-application parentheses of purchase(. . .), only the sequence of -- whitespace-separated -- arguments John Mary Fido is shown, but these are regarded as the elements of a single tuple dependent on the predicate. Moreover, it is an abridged version with all symbols considered local (to the current KB), which can be made explicit with underscores for the _purchase predicate as well as its three arguments, _John, _Mary, and _Fido (the optional underscore prefix, "_", indicates local symbols, in contrast to the colon prefix, ":", which indicates (IRI-)global symbols):

_purchase(_John _Mary _Fido)

This can be further expanded to the following explicit-dependent-tuple form, where the "+"-prefixed square-bracket construct +[...] makes explicit that there is a single predicate-dependent ("+") tuple:

_purchase(+[_John _Mary _Fido])

Since the order of the arguments and tuple elements is significant, the last two variants are not equivalent to, respectively, purchase(Mary John Fido) and purchase(+[Mary John Fido]). Intuitively speaking, the different 'hidden roles' in a relationship, here including the buyer and the seller, need to be kept track of, which becomes non-trivial when there are many arguments.

Motivated by this, the purchase predicate can be alternatively represented as a pairship atom, using slot names ('visible roles') buyer, seller, and item (the arrow infix, "+>", pairs a predicate-dependent slot name with its filler):

purchase(buyer+>John seller+>Mary item+>Fido)

Here, the three "+"-shafted arrow constructs name+>filler make explicit that there are multiple predicate-dependent ("+") slots.

While each slot is an (ordered) name/filler pair, the order between slots is immaterial, hence the above pairship is equivalent to any of its slot-permuted ones, including:

purchase(seller+>Mary buyer+>John item+>Fido)

More importantly, a query using such an atom with slots s1, ..., sM, e.g. (for M=3)

purchase(buyer+>John seller+>Mary item+>Fido)

posed against a fact using an atom with slots s1, ..., sM, sM+1, ..., sN, e.g. (for N=4)

purchase(buyer+>John seller+>Mary item+>Fido price+>700))

succeeds (for varying N there is no direct counterpart to this in relationship queries).

The pairship-querying success arises because:

(a) these (pairship) atoms are equivalent to objectified (pairpoint) versions employing an Object IDentifier (OID), for the query augmented with an existentially quantified OID variable ?o (the hash infix, "#", types an OID with its predicate, i.e. indicates membership),

Exists ?o (?o#purchase(buyer+>John seller+>Mary item+>Fido))

posed against the fact augmented with a system-generated Skolem constant (_1) OID,

_1#purchase(buyer+>John seller+>Mary item+>Fido price+>700)

(b) the pairpoint atoms are equivalent to descributed (here, slotributed) versions, i.e. to the conjunctive query

Exists ?o (
  And( ?o#purchase(buyer+>John)
       ?o#purchase(seller+>Mary)
       ?o#purchase(item+>Fido) ) )

posed against the conjunctive fact

And( _1#purchase(buyer+>John)
     _1#purchase(seller+>Mary)
     _1#purchase(item+>Fido)
     _1#purchase(price+>700) )

Employing a user-specified OID, transaction200, and changing the slots to predicate-independent, the earlier pairship atom becomes this framepoint atom (the arrow infix, "->", pairs a predicate-independent slot name with its filler):

transaction200#purchase(buyer->John seller->Mary item->Fido)

Perspectivity is exemplified by a situation where the same transaction200 OID also is member of a lease predicate whose lessee is John, whose lessor is Mary, and whose item is Kitty.

While the additional non-perspectival framepoint atom

transaction200#lease(lessee->John lessor->Mary item->Kitty)

would make item a multi-valued (2-valued) slot name with fillers Fido and Kitty -- introducing an ambiguity about which of the predicate-independent items is the one of the purchase and which is the one of the lease -- the corresponding perspectival pairpoint atoms

transaction200#purchase(buyer+>John seller+>Mary item+>Fido)
transaction200#lease(lessee+>John lessor+>Mary item+>Kitty)

disambiguate the situation with their purchase-vs.-lease-dependent item slots.

Rather than making the ordered purchase relationship slotted (obtaining a pairship) and then adding an OID and changing the slots to predicate-independent (obtaining a framepoint), the relationship can be kept ordered, an OID added, and its tuple changed to predicate-independent, arriving at a shelfpoint atom (the predicate-independent tuple is indicated by a minus-signed explicit pair of square brackets):

transaction200#purchase(-[John Mary Fido])

PSOA RuleML thus uses a systematics of atoms, as also exemplified by the ways a predicate can act:

  • In the above relationship, with no OID and no slots but a predicate-dependent tuple, the predicate purchase acts as a relator (between the three positional arguments of the predicate-dependent tuple).
  • In the above pairship, which can be seen as a dependent-tuple-to-dependent-slots-transformed relationship, with no OID and no tuple but dependent slots, the predicate will act as a class after objectification.
  • In the above framepoint, with an OID and independent slots but no tuple, the predicate acts as a class (of the OID).
  • In the above shelfpoint, which can be seen as an independent-slots-to-independent-tuple-transformed framepoint, with an OID and a predicate-independent tuple but no predicate-dependent tuple and no slots, the predicate acts as a class (of the OID).

For further refined versions of these purchase atoms, asserted as facts, along with characteristic queries, see the Purchase Facts Section; for their XML serialization see the Syntax Section.

While the atoms so far have been on the function-free level of Datalog, constants like Mary as arguments can be refined to functional expressions of -- possibly nested -- (constructor-)function applications. The following tupled expression exemplifies (PSOATransRun Limitation: The caret prefix, "^", explicitly indicating function symbols, is not implemented):

^store(asset(Mary) place(TimesSquare NYC))

This is the short form with the two embedded terms -- but not the top-level term (hence in need for a "^"-prefixed function symbol, ^store) -- understood as expressions, which can be made explicit by expanding it thus:

^store(^asset(Mary) ^place(TimesSquare NYC))

Substituting it for just Mary leads to the function-employing level of Horn logic, e.g. for relationship and framepoint atoms (no need for a "^" prefix on embedded store occurrences, understood as expressions):

purchase(John store(asset(Mary) place(TimesSquare NYC)) Fido)
transaction200#purchase(
  buyer->John
  seller->store(asset(Mary) place(TimesSquare NYC))
  item->Fido)

This short form can again be expanded:

purchase(John ^store(^asset(Mary) ^place(TimesSquare NYC)) Fido)
transaction200#purchase(
  buyer->John
  seller->^store(^asset(Mary) ^place(TimesSquare NYC))
  item->Fido)

The ^store application's one function-dependent argument tuple, which can be made explicit in

^store(+[asset(Mary) place(TimesSquare NYC)])

-- and expanded to ^store(+[^asset(Mary) ^place(TimesSquare NYC)]) -- may be replaced by two function-dependent slots as in the following slotted expression:

^store(possession+>asset(Mary) location+>place(TimesSquare NYC))

This can again be embedded into relationships and framepoints:

purchase(John store(possession+>asset(Mary) location+>place(TimesSquare NYC)) Fido)
transaction200#purchase(
  buyer->John
  seller->store(possession+>asset(Mary) location+>place(TimesSquare NYC))
  item->Fido)

As a function, ^store can only be applied to form expressions without an OID and with function-dependent descriptors (here, dependent slots).

As a predicate, #store can, however, be applied to form atoms with or without an OID and with predicate-dependent or -independent descriptors (e.g., slots). All resulting atoms can still be embedded into other atoms.

For example, the oidless (frameship) short-form atom with two predicate-independent slots

store(possession->asset(Mary) location->place(TimesSquare NYC))

expanded to

#store(possession->asset(Mary) location->place(TimesSquare NYC))

-- and further expandable to the long-form atom #store(possession->^asset(Mary) location->^place(TimesSquare NYC)) -- can also be embedded into the earlier relationship and framepoint atoms (the second atom thus becomes a framepoint with an embedded frameship, avoiding an embedded framepoint having a user-invented auxiliary 'subobject' OID):

purchase(John #store(possession->asset(Mary) location->place(TimesSquare NYC)) Fido)
transaction200#purchase(
  buyer->John
  seller->#store(possession->asset(Mary) location->place(TimesSquare NYC))
  item->Fido)

Objectification of oidless atoms, on the top-level or embedded (case 1), for ground facts will introduce fresh system-generated OID constants, e.g. _1 and _2 (the first atom thus becomes a relationpoint with an embedded framepoint; the second atom thus becomes a nested framepoint; for both atoms, the embedded framepoint has a guaranteed unique auxiliary 'subobject' OID):

_2#purchase(John _1#store(possession->asset(Mary) location->place(TimesSquare NYC)) Fido)
transaction200#purchase(
  buyer->John
  seller->_1#store(possession->asset(Mary) location->place(TimesSquare NYC))
  item->Fido)

Unnesting can then extract the oidful embedded atom into a conjunction, in general reconstructing the meaning of a nested atom from that of the conjunction of all of its -- recursively -- embedded atoms and of the top-level atom co-referenced via fresh constants from _1, _2, ...:

And(
  _1#store(possession->asset(Mary) location->place(TimesSquare NYC))
  _2#purchase(John _1 Fido)
)
And(
  _1#store(possession->asset(Mary) location->place(TimesSquare NYC))
  transaction200#purchase(
    buyer->John
    seller->_1
    item->Fido)
)

PSOA RuleML permits to create rules over all kinds of atoms. The main parts of a rule are its condition, typically an atom or a conjunction of atoms, and its conclusion, typically an atom.

For example, a ground (variableless) rule can make an earlier purchase relationship into the condition of a liability relationship as the conclusion, formalizing the English sentence "John is liable for Fido if John purchases Fido from Mary" (the colon-dash infix, ":-", indicates the "if", i.e. "is-implied by"):

liability(John Fido) :-
  purchase(John Mary Fido)

Similarly, an earlier purchase framepoint can be used as the condition of a ground rule whose liability-framepoint conclusion adds another OID, registration800, and slot names, bearer and item (again allowing the two slots to appear in any order):

registration800#liability(bearer->John item->Fido) :-
  transaction200#purchase(buyer->John seller->Mary item->Fido)

Instead of the conclusion-OID constant registration800, an OID ground expression like dutyFunc(transaction200) can be used, where the (constructor-)function dutyFunc indicates determination of the conclusion OID by the condition OID, transaction200 (since the expression is embedded as the OID operand of the "#" infix, its function does not require a "^" prefix):

dutyFunc(transaction200)#liability(bearer->John item->Fido) :-
  transaction200#purchase(buyer->John seller->Mary item->Fido)

A corresponding non-ground (variableful) relationship:-relationship rule can universally (Forall) abstract the constant John to the variable ?b, Mary to ?s, and Fido to ?i (the question-mark prefix, "?", indicates variables):

Forall ?b ?s ?i (
  liability(?b ?i) :-
    purchase(?b ?s ?i)
)

Likewise, a corresponding non-ground framepoint:-framepoint rule can additionally abstract the OID constant transaction200 to the OID variable ?t and replace the OID constant registration800 or ground expression dutyFunc(transaction200) with the non-ground OID-function application dutyFunc(?t) (indicating OID determination by ?t):

Forall ?b ?s ?i ?t (
  dutyFunc(?t)#liability(bearer->?b item->?i) :-
    ?t#purchase(buyer->?b seller->?s item->?i)
)

Given the earlier purchase relationship and framepoint facts, the relationship and framepoint rules can be used to answer liability relationship and framepoint queries, respectively. While, for these rule applications, the purchase(?b ?s ?i) relationship condition could not be shortened to purchase(?b ?i), the ?t#purchase(buyer->?b seller->?s item->?i) framepoint condition could be shortened to ?t#purchase(buyer->?b item->?i). However, for direct correspondence with the relationship condition, we keep the seller also in the framepoint condition, which is justified because it ensures that there is a seller in the purchase before deriving the buyer's liability.

PSOA RuleML permits relational Negation-as-failure (Naf), which is able to scope relationship atoms as well as (And, Or, etc.) formulas containing them. Moving beyond a PSOATransRun Limitation, an object-relational Naf is being explored, which should be able to also scope (certain uses of) framepoints and other psoa atoms as well as formulas containing them.

RuleML in general assumes no default semantics, instead permitting semantic profiles, as explained in Specification of RuleML 1.03. This allows the definitive introduction of constructs with multiple semantics such as the relational Naf as well as, in PSOA RuleML, their exploratory extension such as by proceeding to an object-relational Naf.

Naf is illustrated here for relationship:-Naf(relationship) and framepoint:-Naf(framepoint) rules.

For example, the Naf negation of an earlier liability relationship can be made into the condition of a rule with an exempt relationship as the conclusion:

Forall ?b ?i (
  exempt(?b ?i) :-
    Naf(liability(?b ?i))
)

Likewise, the Naf negation of a corresponding framepoint similar to an earlier liability framepoint should become the condition of a rule with an exempt framepoint as the conclusion:

Forall ?b ?i ?o (
  ?o#exempt(citizen->?b item->?i) :-
    Naf(?o#liability(bearer->?b item->?i))
)

These build on the earlier purchase/liability relationship and framepoint facts/rules. The Naf-conditioned relationship rule can be used to answer exempt relationship ground queries. Likewise, the Naf-conditioned framepoint rule is explored for answering exempt framepoint ground queries.

Examples are the failing exempt(John Fido) and succesful exempt(Mary Fido) relationship queries as well as the explored failing dutyFunc(transaction200)#exempt(citizen->John item->Fido) and succesful dutyFunc(transaction200)#exempt(citizen->Mary item->Fido) framepoint queries.

For refined versions of some of the purchase-conditioned rules, along with characteristic queries, see the Purchase-Conditioned Ground Rules Section and Purchase-Conditioned Non-Ground Rules Section; for their XML serialization see the Syntax Section.

2 Introduction

In AI, the Semantic Web, and IT at large, data can be modeled in the contrasting paradigms of relationships having a relation applied to an ordered tuple of positional arguments (e.g., in relational databases and Datalog) or framepoints having an Object IDentifier (OID), usually typed by a class, and an unordered multiset of slotted arguments (e.g., in graph databases and RDF). On top of such data atoms, rules may use just relationship atoms (e.g., SQL views -- i.e., Datalog rules -- and Prolog rules -- i.e., Horn rules) or just framepoint atoms (e.g., SPARQL/SPIN and N3 rules). In PSOA RuleML, rules may also synergize both relationship atoms and framepoint atoms within their -- atom-conjoining -- conditions as well as across their conditions and conclusions (e.g., PSOA rules translating between relational and graph atoms for interoperation purposes, see Refs. 7 and 21).

Further synergizing the paradigms of relationships (oidless, tupled, dependent) and framepoints (oidful, slotted, independent), the orthogonal dimensions characterizing PSOA RuleML atoms also allow for the complementary pairship atoms (oidless, slotted, dependent), shelfpoint atoms (oidful, tupled, independent), as well as oidless/oidful atoms having both tupled and slotted arguments, as summarized in the independent and dependent "psoa tables" using, with 1≤I≤6, systematic names inI for independent cells and deI for dependent cells as well as common names for -- possibly further constrained -- cells such as "shelfpoints" (thus "subspacing" -- in the sense of Ref. 29 -- the full metamodel of Ref. 15 to the medium metamodel by omitting the independent+dependent table and simplifying it by omitting the dimension numbers, as well as using "single-tuple" for the constraint m=1):

independent oidless oidful
tupled in1. single-tuple: shelfships in2. single-tuple: shelfpoints
slotted in3. frameships in4. framepoints
tupled+slotted in5. single-tuple: shelframeships in6. single-tuple: shelframepoints
dependent oidless oidful
tupled de1. single-tuple: relationships de2. single-tuple: relationpoints
slotted de3. pairships de4. pairpoints
tupled+slotted de5. single-tuple: relpairships de6. single-tuple: relpairpoints

Further subspacing the above metamodel by omitting the tupled+slotted rows, we arrive at the core metamodel of 8 kinds of atoms exemplified in PSOAMetamodelGrailogWedding.pdf, in the context of the full, 18-atom, PSOA metamodel cube, as well as used for interoperation in PSOA RuleML Bridges Graph and Relational Databases and for illustration in PSOA RuleML Explained with Blockchain Examples.

As a final extension of atoms, more than a single tuple of positional arguments is allowed, leading to multi-tuple psoa atoms.

For terminological simplification, the common names encode the dimension of oidless vs. oidful atoms as suffixes "...ships" vs. "...points", as in "relationships" vs. "relationpoints" and "frameships" vs. "framepoints", cutting the number of substantially different names into half.

Moreover, users do not need to know any of the names for psoa atoms because they can refer to them in a faceted, dimension-parameterized manner, as in relationship = atom(oidless,single-tupled,dependent) and framepoint = atom(oidful,slotted,independent), reducing the need for names from names for the eighteen cells to (systematic) names for the values of the three dimensions.

The full PSOA metamodel cube is dynamically visualized in PSOAMetaViz (cf. Ref. 23).

Let us mention here the one part that is mandatory for psoa atoms ("what atoms must have"): a predicate, although it may be degenerated to the vacuous Top predicate.

Then, as an alternative visualization, the distinctions for the optional parts of psoa atoms ("what atoms may have") can be seen as a tree with a root-level OID/descriptor fork and, for the descriptor subtree, a variety/dependency fork:

Distinctions for Parts of Atoms
  OID         descriptor
                variety              dependency
                  tuple                independent
                  slot                 dependent

Employing and combining these distinctions, the dimensions for whole atoms ("what atoms may be") can also be visualized as the following "psoa tree":

Dimensions for Whole Atoms
  OID         descriptor
    oidless     variety               dependency
    oidful        tuple(d)              independent
                  slot(ted)             dependent
                  tuple(d)+slot(ted)    independent+dependent

Now, the cells of the psoa tables become paths left-to-right across leaves from different branches of the psoa tree. For example, for the complementary landmark atoms:

relationships: oidless-->tuple(d)-->dependent
framepoints:   oidful-->slot(ted)-->independent

The oidful atoms in the second columns of the psoa tables -- and in the oidful leaf of the OID fork of the psoa tree -- describe an OID, often visualized as a node in a -- for items 2 and 3: generalized -- graph, with

  1. slots (first table, second row: framepoints), visualized as directed labeled arcs, each having a name/label and leading to a filler/node,
  2. tuples (first table, first row: shelfpoints), visualized as directed unlabeled hyperarcs, each connecting a sequence of nodes,
  3. or a combination of both (first table, third row: shelframepoints).

(For various such visualizations see the Rich TA Example in Refs. 14 and 15, the PSOA tutorial data model, the Music Album knowledge base, and the Grailog family example.) Hence, the graph formalism underlying framepoints is directed labeled graphs (DLGs) while the graph formalism underlying shelfpoints is directed unlabeled hypergraphs (DUHs). When atoms of the psoa tables are stored as facts, their querying by corresponding non-ground atoms may fix only the OID (for atoms in the second column), realizing 'location-addressable' retrieval; alternatively, their querying may leave the OID open (for atoms in the second column) or not have an OID at all (for atoms in the first column), realizing 'content-addressable' retrieval. The latter alternative leads to a content-addressable memory, as often proposed for AI and cognitive architectures. Here, the general case of 'content addressing' is formalized by arbitrary-length shelfpoints (DUHs as in the PSOA tutorial, slide 25) or relationships (DUHs as in the PSOA tutorial, slide 23); the special case of 'associative addressing' is formalized by framepoints (DLGs as in the PSOA tutorial, slide 31), which can be regarded as length-2 shelfpoints (by encoding slot names / arc labels as first components of length-2 tuples / hyperarcs). This widely known special case leads to an associative memory (albeit based on labeled instead of unlabeled arcs), which might itself be implemented, e.g., by an artificial neural network. There are also overlaps between PSOA RuleML and JSON, key-value stores, and multi-model databases. In particular, PSOA RuleML generalizes the representation language of key-value stores in several ways, e.g. from Top-predicate (untyped) pairships to arbitrary psoa atoms.

Proceeding from fact retrieval to rule-based inference, any combination of these atoms may be used in rule conditions (as queries) and conclusions (possibly stored as new facts).

The PSOA RuleML language thus introduces the integrated notion of a positional-slotted object-applicative (psoa) term as a generalization of: (1) the positional-slotted term in POSL and (2) the "frame term" and the "class membership" term in RIF-BLD.

In PSOA RuleML Presentation Syntax (PSOA/PS), a psoa term s may thus have one of the following left-tuple normal forms, labeled ATOMOIDFUL, ATOMOIDLESS, and Expr to connect these introductory design patterns with their general definitions as nonterminals in #Monolithic_EBNF_for_PSOA_RuleML_Presentation_Syntax ("#" is used both as an infix and as a prefix; the prefixes "#"/"^" can be omitted if disambiguated by the syntactic context):

   ATOMOIDFUL:  o#f(+[t1,1 ... t1,n1] . . . +[tm,1 ... tm,nm] p1+>v1 . . . pk+>vk)
   ATOMOIDLESS:  #f(+[t1,1 ... t1,n1] . . . +[tm,1 ... tm,nm] p1+>v1 . . . pk+>vk)
   Expr:         ^f(+[t1,1 ... t1,n1] . . . +[tm,1 ... tm,nm] p1+>v1 . . . pk+>vk)

There is a predicate #f or function ^f, an optional OID o, and three kinds of associated information, where (2) and (3) make these design patterns specific to terms with dependent arguments (ATOMOIDFUL/ATOMOIDLESS: predicate-dependent; Expr: function-dependent): (1) The optional membership o#f represents OID o as an instance of predicate f; (2) each of the zero or more dependent tupled arguments +[ti,1 ... ti,ni] represents a sequence of terms; (3) each of the zero or more dependent slotted arguments pi +> vi represents a pair of an attribute term pi and its value term vi.

An atomic formula having the ATOMOIDFUL or ATOMOIDLESS form of a psoa term with f being a predicate (as, e.g., indicated by a "#"-infix or -prefix, respectively) is called a psoa atom. A logical expression having the Expr form of a psoa term with f being a function (as, e.g., indicated by a "^"-prefix) is called a psoa expression.

If a psoa term has just a single dependent tuple, the above explicit-tuple PSOA/PS specializes (with m=1) to

   ATOMOIDFUL:  o#f(+[t1,1 ... t1,n1] p1+>v1 . . . pk+>vk)
   ATOMOIDLESS:  #f(+[t1,1 ... t1,n1] p1+>v1 . . . pk+>vk)
   Expr:         ^f(+[t1,1 ... t1,n1] p1+>v1 . . . pk+>vk)

which can be shortened to this implicit-tuple PSOA/PS, directly using the single tuple's sequence of elements as a sequence of arguments:

   ATOMOIDFUL:  o#f(t1,1 ... t1,n1 p1+>v1 . . . pk+>vk)
   ATOMOIDLESS:  #f(t1,1 ... t1,n1 p1+>v1 . . . pk+>vk)
   Expr:         ^f(t1,1 ... t1,n1 p1+>v1 . . . pk+>vk)

From these constructions, the following restrictions apply, which will be formalized for the general definitions in #Monolithic_EBNF_for_PSOA_RuleML_Presentation_Syntax:

  1. A psoa term can have at most one implicit tuple.
  2. If a psoa term has an implicit tuple, it can have no explicit tuples.

Psoa atoms can be asserted as psoa facts and retrieved by look-up psoa queries. Such atoms can also be combined into more complex formulas, e.g. using constructs from the Horn-like subset of first-order logic, mainly conjunction and implication. Implication (written 'backward' as a ":-" infix) can be used for rules, e.g. of this conjunctive-condition form, where each si is a psoa atom:

   Forall ... ( s0 :- And(s1 . . . sz) )

Generally, psoa rules can be used to derive psoa atoms on demand, through deductive psoa queries.

The page for the PSOATransRun Demo gives introductory examples while the page PSOARuleMLInvitedTutorialExamplesRW2015 proceeds to advanced examples. The papers and slides in the References provide details. These include the award-winning Refs. 1., 3., and 26. as well as the invited tutorial Ref. 7., the challenge Ref. 13. (also presented as part of an invited tutorial), the arXiv-maintained Ref. 15, and the keynote Ref. 29.

There are further connections between PSOA RuleML and Graph Databases as well as between PSOA RuleML and Relational Databases. Since PSOA RuleML allows for both objectal and relational knowledge/data modeling, it can support the specification of all kinds of object-relational transformations between the global and local schemas in Ontology/Rule-Based Data Access (OBDA/RBDA). Similarly, SQL-PSOA-SPARQL interoperation is discussed in Ref. 7., Section 5, which is also focused in PSOAObjRelDataRules-AWoSS2015.

A visualization for PSOA RuleML has been developed in Grailog, permitting integrated object-relational knowledge (InteropGraphRel and PSOAObjRelDataRules). This has been updated such that all 18 oidless/oidful, tupled/slotted, independent/dependent atoms of the PSOA metamodel cube (from Ref. 15, Appendix A) are systematically visualized in Grailog (some of which illustrated in PSOA RuleML Explained with Blockchain Examples): http://ruleml.org/talks/PSOAMetamodelGrailogWedding.pdf

3 Specification

The original specification of the PSOA RuleML presentation syntax and semantics is given in Ref. 1. An explanation of the PSOA RuleML serialization syntax in XML, mapped from the presentation syntax, and of the semantics are given in Ref. 7. The semantics is revised to directly accommodate oidless psoa terms in Ref. 12. The syntaxes and semantics are further revised for the dependency dimension in Ref. 15 (PSOAPerspectivalKnowledge), leading to the release of PSOA RuleML 1.0, presented at RuleML+RR 2017 (http://ruleml.org/talks/PSOAPerspectivalKnowledge-talk.pdf). To create a synchronization point with the Specification of Deliberation RuleML 1.03, the release following PSOA RuleML 1.0 is PSOA RuleML 1.03. An introduction focusing on the PSOA RuleML 1.03 serialization syntax is given in Ref. 35 (SpecPSOARuleMLXML103), presented at RuleML+RR 2019 (http://ruleml.org/talks/SpecPSOARuleMLXML103-talk.pdf). The subsections below elaborate the specification of PSOA RuleML 1.03, consisting of presentation and serialization syntaxes as well as semantics.

The Release of Deliberation PSOA RuleML 1.03 was announced on 2020-03-11.

3.1 Syntaxes

In this text, the word "syntax" (singular) is employed generically while "syntaxes" (plural) emphasizes variations. In particular, the "presentation syntax" and the "serialization syntax" are utilized for different purposes; but both allow variations where "normal-form syntaxes" simplify equality comparisons of equivalent "non-normal-form syntaxes".

For PSOA RuleML’s implementations and use cases, its (plain-text) presentation syntax has mostly been utilized. The PSOA RuleML presentation syntax modifies and extends the one of RIF-BLD. However, data and knowledge validation, transformation, interchange, and reuse benefit from serialization (XML) syntaxes as provided by RuleML. The PSOA RuleML/XML serialization syntax adapts the one of Deliberation RuleML/XML. For illustrating the XML representation, the first subsection will serialize variations of the preview example series.

For oidful (multi-)tupled and/or (multi-)slotted psoa terms having only dependent tuples and/or dependent slots, (multiple occurrences of) <tupdep><Tuple> edge-node element pairs and/or (multiple) <slotdep> edge elements are allowed. Such a (multiple-)dependent-tuple, (multiple-)dependent-slot psoa term can be used as an atomic formula (Atom) having the following pure (Ref. 7, Section 6: tuple-rest-prohibiting) PSOA left-tuple (equivalently, right-slot) normal form (for the most general kind of psoa terms-as-atoms see Ref. 15 and below). Here, the primed meta-variables t'i,j etc. indicate recursive XML serializations of their presentation-syntax versions in the #Introduction (the style attribute can be used with the value "http://ruleml.org/1.03/profiles/HornPSOA-Tarski" to specify PSOA semantics with built-in describution, i.e. slotribution and tupribution):

   <Atom style="http://ruleml.org/1.03/profiles/HornPSOA-Tarski">
     <oid><Ind>o</Ind></oid>
     <op><Rel>f</Rel></op>
     <tupdep><Tuple>t'1,1 ... t'1,n1</Tuple></tupdep>
     . . .
     <tupdep><Tuple>t'm,1 ... t'm,nm</Tuple></tupdep>
     <slotdep>p'1 v'1</slotdep>
     . . .
     <slotdep>p'k v'k</slotdep>
   </Atom>

For an extended (Ref. 7, Section 6: tuple-rest-allowing) PSOA version again see this RW 2015 tutorial on PSOA RuleML, where, however, the left-tuple normal form was replaced with a right-tuple normal form.

The mapping between the PSOA RuleML presentation syntax and the PSOA RuleML/XML serialization syntax is given in Ref. 7, Section 6, and Ref. 15, Section 4.2.

For oidless (multi-)tupled and/or (multi-)slotted psoa terms having only dependent tuples and/or dependent slots, (multiple occurrences of) <tupdep><Tuple> edge-node element pairs and/or (multiple) <slotdep> edge elements are also allowed. Such a (multiple-)dependent-tuple, (multiple-)dependent-slot psoa term can be used as an expression (Expr) having the following left-tuple normal form (this is the most general kind of psoa terms-as-expressions). Again, the primed meta-variables t'i,j etc. indicate recursive XML serializations of corresponding presentation-syntax versions in the #Introduction:

   <Expr>
     <op><Fun>f</Fun></op>
     <tupdep><Tuple>t'1,1 ... t'1,n1</Tuple></tupdep>
     . . .
     <tupdep><Tuple>t'm,1 ... t'm,nm</Tuple></tupdep>
     <slotdep>p'1 v'1</slotdep>
     . . .
     <slotdep>p'k v'k</slotdep>
   </Expr>

In the subsections following the serialization preview, the PSOA RuleML 1.03 presentation and serialization syntaxes are developed.

3.1.1 Serialization Preview

Using PSOA RuleML's serialization syntax, the presentation-syntax example series from the Presentation Preview can be represented in the XML-specification format as demonstrated with selected parts here. The headers instantiate the terminological pattern {relation, frame}{ship, point} of the metamodel for atoms in the #Introduction, adding expressions. The XML 'indentation trees' below can be seen as parse trees of the corresponding presentation syntax.

Implicit-(dependent-)tuple relationship atom:

(Fully striped) normal form (Stripe-skipped) compact form
<Atom>
  <op><Rel>purchase</Rel></op>
  <arg index="1"><Ind>John</Ind></arg>
  <arg index="2"><Ind>Mary</Ind></arg>
  <arg index="3"><Ind>Fido</Ind></arg>
</Atom>
<Atom>
  <Rel>purchase</Rel>
  <Ind>John</Ind>
  <Ind>Mary</Ind>
  <Ind>Fido</Ind>
</Atom>

Explicit-(dependent-)Tuple relationship atom in (fully striped) normal form:

<Atom>
  <op><Rel>purchase</Rel></op>
  <tupdep>
    <Tuple>
      <arg index="1"><Ind>John</Ind></arg>
      <arg index="2"><Ind>Mary</Ind></arg>
      <arg index="3"><Ind>Fido</Ind></arg>
    </Tuple>
  </tupdep>
</Atom>

(Independent-slot) framepoint atom in (fully striped) normal form:

<Atom>
  <oid><Ind>transaction200</Ind></oid>
  <op><Rel>purchase</Rel></op>
  <slot><Ind>buyer</Ind><Ind>John</Ind></slot>
  <slot><Ind>seller</Ind><Ind>Mary</Ind></slot>
  <slot><Ind>item</Ind><Ind>Fido</Ind></slot>
</Atom>

Implicit-(dependent-)tuple expression:

<Expr>
  <Fun>store</Fun>
  <Expr>
    <Fun>asset</Fun>
    <Ind>Mary</Ind>
  </Expr>
  <Expr>
    <Fun>place</Fun>
    <Ind>TimesSquare</Ind>
    <Ind>NYC</Ind>
  </Expr>
</Expr>

(Dependent-)slot expression:

<Expr>
  <Fun>store</Fun>
  <slotdep>
    <Ind>possession</Ind>
    <Expr>
      <Fun>asset</Fun>
      <Ind>Mary</Ind>
    </Expr>
  </slotdep>
  <slotdep>
    <Ind>location</Ind>
    <Expr>
      <Fun>place</Fun>
      <Ind>TimesSquare</Ind>
      <Ind>NYC</Ind>
    </Expr>
  </slotdep>
</Expr>

Implicit-(dependent-)tuple relationship atom containing implicit-(dependent-)tuple expression:

<Atom>
  <Rel>purchase</Rel>
  <Ind>John</Ind>
  <Expr>
    <Fun>store</Fun>
    <Expr>
      <Fun>asset</Fun>
      <Ind>Mary</Ind>
    </Expr>
    <Expr>
      <Fun>place</Fun>
      <Ind>TimesSquare</Ind>
      <Ind>NYC</Ind>
    </Expr>
  </Expr>
  <Ind>Fido</Ind>
</Atom>

Implicit-(dependent-)tuple relationship atom containing (dependent-)slot expression:

<Atom>
  <Rel>purchase</Rel>
  <Ind>John</Ind>
  <Expr>
    <Fun>store</Fun>
    <slotdep>
      <Ind>possession</Ind>
      <Expr>
        <Fun>asset</Fun>
        <Ind>Mary</Ind>
      </Expr>
    </slotdep>
    <slotdep>
      <Ind>location</Ind>
      <Expr>
        <Fun>place</Fun>
        <Ind>TimesSquare</Ind>
        <Ind>NYC</Ind>
      </Expr>
    </slotdep>
  </Expr>
  <Ind>Fido</Ind>
</Atom>

(Independent-slot) framepoint atom containing implicit-(dependent-)tuple expression:

<Atom>
  <oid><Ind>transaction200</Ind></oid>
  <Rel>purchase</Rel>
  <slot><Ind>buyer</Ind><Ind>John</Ind></slot>
  <slot>
    <Ind>seller</Ind>
    <Expr>
      <Fun>store</Fun>
      <Expr>
        <Fun>asset</Fun>
        <Ind>Mary</Ind>
      </Expr>
      <Expr>
        <Fun>place</Fun>
        <Ind>TimesSquare</Ind>
        <Ind>NYC</Ind>
      </Expr>
    </Expr>
  </slot>
  <slot><Ind>item</Ind><Ind>Fido</Ind></slot>
</Atom>

(Independent-slot) framepoint atom containing (dependent-)slot expression:

<Atom>
  <oid><Ind>transaction200</Ind></oid>
  <Rel>purchase</Rel>
  <slot><Ind>buyer</Ind><Ind>John</Ind></slot>
  <slot>
    <Ind>seller</Ind>
    <Expr>
      <Fun>store</Fun>
      <slotdep>
        <Ind>possession</Ind>
        <Expr>
          <Fun>asset</Fun>
          <Ind>Mary</Ind>
        </Expr>
      </slotdep>
      <slotdep>
        <Ind>location</Ind>
        <Expr>
          <Fun>place</Fun>
          <Ind>TimesSquare</Ind>
          <Ind>NYC</Ind>
        </Expr>
      </slotdep>
    </Expr>
  </slot>
  <slot><Ind>item</Ind><Ind>Fido</Ind></slot>
</Atom>

Implicit-(dependent-)tuple relationship atom containing (independent-slot) frameship atom:

<Atom>
  <Rel>purchase</Rel>
  <Ind>John</Ind>
  <Atom>
    <Rel>store</Rel>
    <slot>
      <Ind>possession</Ind>
      <Expr>
        <Fun>asset</Fun>
        <Ind>Mary</Ind>
      </Expr>
    </slot>
    <slot>
      <Ind>location</Ind>
      <Expr>
        <Fun>place</Fun>
        <Ind>TimesSquare</Ind>
        <Ind>NYC</Ind>
      </Expr>
    </slot>
  </Atom>
  <Ind>Fido</Ind>
</Atom>

(Independent-slot) framepoint atom containing (independent-slot) frameship atom:

<Atom>
  <oid><Ind>transaction200</Ind></oid>
  <Rel>purchase</Rel>
  <slot><Ind>buyer</Ind><Ind>John</Ind></slot>
  <slot>
    <Ind>seller</Ind>
    <Atom>
      <Rel>store</Rel>
      <slot>
        <Ind>possession</Ind>
        <Expr>
          <Fun>asset</Fun>
          <Ind>Mary</Ind>
        </Expr>
      </slot>
      <slot>
        <Ind>location</Ind>
        <Expr>
          <Fun>place</Fun>
          <Ind>TimesSquare</Ind>
          <Ind>NYC</Ind>
        </Expr>
      </slot>
    </Atom>
  </slot>
  <slot><Ind>item</Ind><Ind>Fido</Ind></slot>
</Atom>

Implicit-(dependent-)tuple relationpoint atom containing (independent-slot) framepoint atom:

<Atom>
  <oid><Ind>2</Ind></oid>
  <Rel>purchase</Rel>
  <Ind>John</Ind>
  <Atom>
    <oid><Ind>1</Ind></oid>
    <Rel>store</Rel>
    <slot>
      <Ind>possession</Ind>
      <Expr>
        <Fun>asset</Fun>
        <Ind>Mary</Ind>
      </Expr>
    </slot>
    <slot>
      <Ind>location</Ind>
      <Expr>
        <Fun>place</Fun>
        <Ind>TimesSquare</Ind>
        <Ind>NYC</Ind>
      </Expr>
    </slot>
  </Atom>
  <Ind>Fido</Ind>
</Atom>

(Independent-slot) framepoint atom containing (independent-slot) framepoint atom:

<Atom>
  <oid><Ind>transaction200</Ind></oid>
  <Rel>purchase</Rel>
  <slot><Ind>buyer</Ind><Ind>John</Ind></slot>
  <slot>
    <Ind>seller</Ind>
    <Atom>
      <oid><Ind>1</Ind></oid>
      <Rel>store</Rel>
      <slot>
        <Ind>possession</Ind>
        <Expr>
          <Fun>asset</Fun>
          <Ind>Mary</Ind>
        </Expr>
      </slot>
      <slot>
        <Ind>location</Ind>
        <Expr>
          <Fun>place</Fun>
          <Ind>TimesSquare</Ind>
          <Ind>NYC</Ind>
        </Expr>
      </slot>
    </Atom>
  </slot>
  <slot><Ind>item</Ind><Ind>Fido</Ind></slot>
</Atom>

Ground implicit-(dependent-)tuple relationship rule in (fully striped) normal form:

<Implies>
  <if>      <!-- _purchase(_John _Mary _Fido) -->
    <Atom>
      <op><Rel>purchase</Rel></op>
      <arg index="1"><Ind>John</Ind></arg>
      <arg index="2"><Ind>Mary</Ind></arg>
      <arg index="3"><Ind>Fido</Ind></arg>
    </Atom>
  </if>     
  <then>    <!-- _liability(_John _Fido) -->
    <Atom>
      <op><Rel>liability</Rel></op>
      <arg index="1"><Ind>John</Ind></arg>
      <arg index="2"><Ind>Fido</Ind></arg>
    </Atom>
  </then>
</Implies>

Ground (independent-slot) framepoint rule in (fully striped) normal form:

<Implies>
  <if>      <!-- _transaction200#_purchase(_buyer->_John _seller->_Mary _item->_Fido) -->
    <Atom>
      <oid><Ind>transaction200</Ind></oid>
      <op><Rel>purchase</Rel></op>
      <slot><Ind>buyer</Ind><Ind>John</Ind></slot>
      <slot><Ind>seller</Ind><Ind>Mary</Ind></slot>
      <slot><Ind>item</Ind><Ind>Fido</Ind></slot>
    </Atom>
  </if>     
  <then>    <!-- _registration800#_liability(_bearer->_John _item->_Fido) -->
    <Atom>
      <oid><Ind>registration800</Ind></oid>
      <op><Rel>liability</Rel></op>
      <slot><Ind>bearer</Ind><Ind>John</Ind></slot>
      <slot><Ind>item</Ind><Ind>Fido</Ind></slot>
    </Atom>
  </then>
</Implies>

Non-ground implicit-(dependent-)tuple relationship rule in (fully striped) normal form:

<Forall>
  <declare><Var>b</Var></declare>
  <declare><Var>s</Var></declare>
  <declare><Var>i</Var></declare>
  <formula>
    <Implies>
      <if>      <!-- _purchase(?b ?s ?i) -->
        <Atom>
          <op><Rel>purchase</Rel></op>
          <arg index="1"><Var>b</Var></arg>
          <arg index="2"><Var>s</Var></arg>
          <arg index="3"><Var>i</Var></arg>
        </Atom>
      </if>     
      <then>    <!-- _liability(?b ?i) -->
        <Atom>
          <op><Rel>liability</Rel></op>
          <arg index="1"><Var>b</Var></arg>
          <arg index="2"><Var>i</Var></arg>
        </Atom>
      </then>
    </Implies>
  </formula>
</Forall>

Non-ground (independent-slot) framepoint rule in (fully striped) normal form:

<Forall>
  <declare><Var>b</Var></declare>
  <declare><Var>s</Var></declare>
  <declare><Var>i</Var></declare>
  <declare><Var>t</Var></declare>
  <formula>
    <Implies>
      <if>      <!-- ?t#_purchase(_buyer->?b _seller->?s _item->?i) -->
        <Atom>
          <oid><Var>t</Var></oid>
          <op><Rel>purchase</Rel></op>
          <slot><Ind>buyer</Ind><Var>b</Var></slot>
          <slot><Ind>seller</Ind><Var>s</Var></slot>
          <slot><Ind>item</Ind><Var>i</Var></slot>
        </Atom>
      </if>     
      <then>    <!-- ^dutyFunc(?t)#_liability(_bearer->?b _item->?i) -->
        <Atom>
          <oid>
            <Expr>
              <op><Fun>dutyFunc</Fun></op>
              <arg index="1"><Var>t</Var></arg>
            </Expr>
          </oid>
          <op><Rel>liability</Rel></op>
          <slot><Ind>bearer</Ind><Var>b</Var></slot>
          <slot><Ind>item</Ind><Var>i</Var></slot>
        </Atom>
      </then>
    </Implies>
  </formula>
</Forall>

3.1.2 Combining Atoms and Expressions

Atoms and expressions can be combined in a complementary manner: not only expressions but also atoms can be embedded in atoms and expressions. There can be embeddings in the positions of tuple elements and slot fillers as well as in the positions of slot names and OIDs. Embedded atoms may undergo embedded objectification, possibly followed by unnesting. To distinguish atoms and expressions, context-free long and context-sensitive short forms can be used. The presentation syntax offers long and short forms while the serialization syntax offers a long form.

3.1.2.1 Presentation Syntax Long and Short Forms

As illustrated in the #Presentation Preview, the PSOA RuleML presentation syntax allows two forms for both Atoms (with predicates as operators) and Expr(ession)s (with functions as operators): short (no prefixes for predicates/functions) and long (prefixes "#"/"^" for predicates/functions), where the use of the short forms for both requires context to distinguish all Atoms and Exprs (cf. #Monolithic_EBNF_for_PSOA_RuleML_Presentation_Syntax).

For embeddings in the positions of tuple elements and slot fillers, systematically varied examples are employed for demonstrating the main ways to distinguish Atoms and Exprs of PSOA RuleML KBs and queries in presentation syntax (PSOATransRun Limitation: The prefix "^" is not implemented). For comparability across Atoms and Exprs, these examples use only dependent descriptors (note: Atoms with corresponding independent descriptors can be easily added, as shown for independent slots at the end of this subsection).

  1. For all Atoms and Exprs: the long forms can be used in a context-free manner (similarly to the serialization syntax long form)
    1. Top-level Atom with embedded Exprs (prefixed top-level predicate, prefixed embedded functions): #p(^f1(^f2(a u+>v)) s+>^g1(b c))
    2. Top-level Atom with embedded Atoms (prefixed top-level predicate, prefixed embedded predicates): #p(#p1(#p2(a u+>v)) s+>#q1(b c))
    3. Top-level Expr with embedded Exprs (prefixed top-level function, prefixed embedded functions): ^f(^f1(^f2(a u+>v)) s+>^g1(b c))
    4. Top-level Expr with embedded Atoms (prefixed top-level function, prefixed embedded predicates): ^f(#p1(#p2(a u+>v)) s+>#q1(b c))
  2. For terms with a non-prefixed operator, their context -- at the top-level vs. embedded in other terms -- is required to distinguish Atom vs. Expr terms, where embedded occurrences are term operands as elements of an implict or explict tuple or as slot fillers:
    1. For top-level Atoms and for embedded Exprs: the short forms may be used (here, f1(f2(a u+>v)) is used as an implict one-element tuple of p, corresponding to the explict dependent one-element tuple +[f1(f2(a u+>v))], while g1(b c) is used as an s-slot filler)
      1. Top-level Atom with embedded Exprs (non-prefixed top-level predicate, non-prefixed embedded functions): p(f1(f2(a u+>v)) s+>g1(b c))
    2. For top-level Exprs and for embedded Atoms: the long forms must be used
      1. Top-level Atom with embedded Atoms (non-prefixed top-level predicate, prefixed embedded predicates): p(#p1(#p2(a u+>v)) s+>#q1(b c))
      2. Top-level Expr with embedded Exprs (prefixed top-level function, non-prefixed embedded functions): ^f(f1(f2(a u+>v)) s+>g1(b c))
      3. Top-level Expr with embedded Atoms (prefixed top-level function, prefixed embedded predicates): ^f(#p1(#p2(a u+>v)) s+>#q1(b c))

Highlighting "#" as a prefix, rather than an infix, the examples use only oidless psoa atoms (psoa expressions being always oidless). However, the two examples with embedded Atoms can also be used to demonstrate the expansion of the "#" prefix to an infix by embedded objectification (embobj), here exemplified for case 3 (introducing anonymous-variable ("?") OIDs):

p(#p1(#p2(a u+>v)) s+>#q1(b c))
~~embobj~~>
p(?#p1(?#p2(a u+>v)) s+>?#q1(b c))
^f(#p1(#p2(a u+>v)) s+>#q1(b c))
~~embobj~~>
^f(?#p1(?#p2(a u+>v)) s+>?#q1(b c))

Another example shows embobj, here exemplified for case 2 (introducing existentially scoped (by a single Exists) OID variables ?1, ?2, ?3, ?4), in preparation for unnesting (unnest); the latter allows -- in its "maximal" form (Ref. 12) -- Atoms to be unnested not only from within other Atoms but also from within Exprs (note: while the above sample Atoms use dependent slots, the below ones use independent slots):

p(f1(#p1(#p2(a u->v)))
  s->g1(#q1(g2(#q2(g3(b c))))))
~~embobj~~>
Exists ?1 ?2 ?3 ?4 (
  p(f1(?1#p1(?2#p2(a u->v)))
    s->g1(?3#q1(g2(?4#q2(g3(b c))))))
)
~~unnest~~>
Exists ?1 ?2 ?3 ?4 (
  And(
    ?2#p2(a u->v)
    ?1#p1(?2)
    ?4#q2(g3(b c))
    ?3#q1(g2(?4))
    p(f1(?1)
      s->g1(?3))
  )
)

For embeddings in the positions of slot names and OIDs, the same variations are possible. For example, reconsider the above systematically varied examples.

In the slot-filler-position embeddings, s+>^g1(b c) can be replaced by the slot-name-position embeddings ^g1(b c)+>t as well as s+>#q1(b c) by #q1(b c)+>t and s+>g1(b c) by g1(b c)+>t.

For the OID-position embeddings, the above systematics can be restricted such that only top-level Atoms but not top-level Exprs (whose functions do not have OIDs) are used. The following examples are constructed from a subset of the above examples by moving the element of the implict tuple into the OID position.

  1. For all Atoms and Exprs: the long forms can be used in a context-free manner
    1. Top-level Atom with embedded Exprs (infix-expanded top-level predicate, prefixed embedded functions): ^f1(^f2(a u+>v))#p(s+>^g1(b c))
    2. Top-level Atom with embedded Atoms (infix-expanded top-level predicate, prefixed embedded predicates): #p1(#p2(a u+>v))#p(s+>#q1(b c))
  2. For terms with a non-prefixed operator, their context is required to distinguish Atom vs. Expr terms, where embedded occurrences are OIDs:
    1. For embedded Exprs: the short forms may be used
      1. Top-level Atom with embedded Exprs (infix-expanded top-level predicate, non-prefixed embedded functions): f1(f2(a u+>v))#p(s+>g1(b c))
    2. For embedded Atoms: the long forms must be used
      1. Top-level Atom with embedded Atoms (infix-expanded top-level predicate, prefixed embedded predicates): see 1.2.


In the read–eval–print loop of a PSOA system such as an extended #PSOATransRun, Exprs -- with "^"-prefixed functions -- on the top-level of terms posed against a KB as "function queries" (e.g., ^factorialFun(squareFun(3))) would complement PSOA's default Atoms -- with non-prefixed predicates -- as "predicate queries" (e.g., factorialPred(9 ?f) or And(squarePred(3 ?s) factorialPred(?s ?f))). This Atom/Expr-distinguishing approach would create a bridge to functional-logic programming, e.g. to the Atom/Expr-integrating approach in Relfun.

3.1.2.2 Serialization Syntax Long Form

As illustrated in the #Serialization Preview, the PSOA RuleML serialization syntax context-freely -- like the presentation syntax long form -- separates <Atom>s (with "#"-like <Rel>ation tags as operators) and <Expr>essions (with "^"-like <Fun>ction tags as operators). This is shown here for embeddings in the positions of tuple elements and slot fillers, by serializing their four long-form examples in PSOA RuleML/XML:

<Atom>               <!-- #p(^f1(^f2(a u+>v)) s+>^g1(b c)) -->
  <Rel>p</Rel>
  <Expr>
    <Fun>f1</Fun>
    <Expr>
      <Fun>f2</Fun>
      <Ind>a</Ind>
      <slotdep>
        <Ind>u</Ind>
        <Ind>v</Ind>
      </slotdep>
    </Expr>
  </Expr>
  <slotdep>
    <Ind>s</Ind>
    <Expr>
      <Fun>g1</Fun>
      <Ind>b</Ind>
      <Ind>c</Ind>
    </Expr>
  </slotdep>
</Atom>
<Atom>               <!-- #p(#p1(#p2(a u+>v)) s+>#q1(b c)) -->
  <Rel>p</Rel>
  <Atom>
    <Rel>p1</Rel>
    <Atom>
      <Rel>p2</Rel>
      <Ind>a</Ind>
      <slotdep>
        <Ind>u</Ind>
        <Ind>v</Ind>
      </slotdep>
    </Atom>
  </Atom>
  <slotdep>
    <Ind>s</Ind>
    <Atom>
      <Rel>q1</Rel>
      <Ind>b</Ind>
      <Ind>c</Ind>
    </Atom>
  </slotdep>
</Atom>
<Expr>               <!-- ^f(^f1(^f2(a u+>v)) s+>^g1(b c)) -->
  <Fun>f</Fun>
  <Expr>
    <Fun>f1</Fun>
    <Expr>
      <Fun>f2</Fun>
      <Ind>a</Ind>
      <slotdep>
        <Ind>u</Ind>
        <Ind>v</Ind>
      </slotdep>
    </Expr>
  </Expr>
  <slotdep>
    <Ind>s</Ind>
    <Expr>
      <Fun>g1</Fun>
      <Ind>b</Ind>
      <Ind>c</Ind>
    </Expr>
  </slotdep>
</Expr>
<Expr>               <!-- ^f(#p1(#p2(a u+>v)) s+>#q1(b c)) -->
  <Fun>f</Fun>
  <Atom>
    <Rel>p1</Rel>
    <Atom>
      <Rel>p2</Rel>
      <Ind>a</Ind>
      <slotdep>
        <Ind>u</Ind>
        <Ind>v</Ind>
      </slotdep>
    </Atom>
  </Atom>
  <slotdep>
    <Ind>s</Ind>
    <Atom>
      <Rel>q1</Rel>
      <Ind>b</Ind>
      <Ind>c</Ind>
    </Atom>
  </slotdep>
</Expr>

For the PSOA RuleML serialization syntax, there is no short form corresponding to the one of the presentation syntax.

3.1.3 Round-Tripping Between RuleML/XML and RuleML/JSON

As introduced in RuleML in JSON, RuleML/XML can be converted to RuleML/JSON in a round-trippable fashion, i.e. without information loss, so that the RuleML/XML source (usually without XML comments and with a different prettty-print) can be recovered by an inverse converter. Applicable to RuleML/XML's (fully striped) normal form (satisfying the edge-child assumption), the free JSON-object-centric XML to JSON and JSON to XML converter online combines both directions of conversion, where XML's attributes and children in JSON are distinguished by encoding attributes with a "-" prefix. The XML-to-JSON ("-->") direction of the converter is exemplified below by two RuleML/JSON target instances converted from the two final RuleML/XML source instances in #Serialization_Preview. Its JSON-to-XML ("<--") direction, recovering the two #Serialization_Preview sources, completes these round-trips.

Non-ground implicit-(dependent-)tuple relationship rule in (fully striped) normal form -- Converted to object-centric RuleML/JSON:

{
  "Forall": {
    "declare": [
      { "Var": "b" },
      { "Var": "s" },
      { "Var": "i" }
    ],
    "formula": {
      "Implies": {
        "if": {
          "Atom": {
            "op": { "Rel": "purchase" },
            "arg": [
              {
                "-index": "1",
                "Var": "b"
              },
              {
                "-index": "2",
                "Var": "s"
              },
              {
                "-index": "3",
                "Var": "i"
              }
            ]
          }
        },
        "then": {
          "Atom": {
            "op": { "Rel": "liability" },
            "arg": [
              {
                "-index": "1",
                "Var": "b"
              },
              {
                "-index": "2",
                "Var": "i"
              }
            ]
          }
        }
      }
    }
  }
}

Non-ground (independent-slot) framepoint rule in (fully striped) normal form -- Converted to object-centric RuleML/JSON:

{
  "Forall": {
    "declare": [
      { "Var": "b" },
      { "Var": "s" },
      { "Var": "i" },
      { "Var": "t" }
    ],
    "formula": {
      "Implies": {
        "if": {
          "Atom": {
            "oid": { "Var": "t" },
            "op": { "Rel": "purchase" },
            "slot": [
              {
                "Ind": "buyer",
                "Var": "b"
              },
              {
                "Ind": "seller",
                "Var": "s"
              },
              {
                "Ind": "item",
                "Var": "i"
              }
            ]
          }
        },
        "then": {
          "Atom": {
            "oid": {
              "Expr": {
                "op": { "Fun": "dutyFunc" },
                "arg": {
                  "-index": "1",
                  "Var": "t"
                }
              }
            },
            "op": { "Rel": "liability" },
            "slot": [
              {
                "Ind": "bearer",
                "Var": "b"
              },
              {
                "Ind": "item",
                "Var": "i"
              }
            ]
          }
        }
      }
    }
  }
}

However, as discussed in XML in JSON Revisited, instead of mapping XML elements to JSON objects, an order-preserving mapping to JSON arrays would be preferable, reserving JSON objects for XML attributes. The JSON-array-centric compactifying XML-to-JSON mapping proposed there is exemplified below by two RuleML/JSON target instances for the same source instances used above.

Non-ground implicit-(dependent-)tuple relationship rule in (fully striped) normal form -- Mapped to array-centric RuleML/JSON:

["Forall",
  ["declare", ["Var", "b"]],
  ["declare", ["Var", "s"]],
  ["declare", ["Var","i"]],
  ["formula",
    ["Implies",
      ["if",
        ["Atom",
	  ["op", ["Rel", "purchase"]],
          ["arg", {"index":"1"},
            ["Var", "b"]],	
          ["arg", {"index":"2"},
            ["Var", "s"]],
          ["arg", {"index":"3"},
            ["Var", "i"]]]],
      ["then", 
        ["Atom",
	  ["op", ["Rel", "liability"]],
          ["arg", {"index":"1"},
            ["Var", "b"]],	
          ["arg", {"index":"2"},
            ["Var", "i"]]]]
    ]
  ]
]

Non-ground (independent-slot) framepoint rule in (fully striped) normal form -- Mapped to array-centric RuleML/JSON:

["Forall",
  ["declare", ["Var", "b"]],
  ["declare", ["Var", "s"]],
  ["declare", ["Var","i"]],
  ["declare", ["Var","t"]],
  ["formula",
    ["Implies",
      ["if",
        ["Atom",
          ["oid", ["Var","t"]],
	  ["op", ["Rel", "purchase"]],
          ["slot",
            ["Ind", "buyer"],
            ["Var", "b"]],
          ["slot",
            ["Ind", "seller"],
            ["Var", "s"]],
          ["slot",
            ["Ind", "item"],
            ["Var", "i"]]]],
      ["then",
        ["Atom",
          ["oid",
            ["Expr",
	      ["op", ["Fun", "dutyFunc"]],
              ["arg", {"index":"1"},
		["Var","t"]]]],
	  ["op", ["Rel", "liability"]],
          ["slot",
            ["Ind", "bearer"],
            ["Var", "b"]],
          ["slot",
            ["Ind", "item"],
            ["Var", "i"]]]]]]]

Such mappings may be used for "deployment conversion" of RuleML/XML (instances, RNGs, XSDs, XSLTs) to RuleML/JSON after our XML-based (transformation and validation) tool chain has been applied.

3.1.4 Monolithic Syntax

Like in RIF-BLD's EBNF, the Condition Language represents FORMULAs (e.g., an Atom or an And of Atoms) that can be used as queries or as premises of PSOA RuleML rules, while the Rule Language represents entire RuleML documents including Implies CLAUSEs whose premises are such Condition FORMULAs. This convenient top-level Condition/Rule bi-partitioning does not prevent the syntax from being monolithic (the grammar's productions could be united or could be partitioned differently) and does not constitute the starting point of PSOA RuleML's multi-partitioned modularization.

3.1.4.1 Monolithic EBNF for PSOA RuleML Presentation Syntax

Left-Tuple Normal Form (LTNF) Grammar

Rule Language:

RuleML ::= 'RuleML' '(' Base? Prefix* Import* (Assert | Query)* ')'
Base ::= 'Base' '(' ANGLEBRACKIRI ')'
Prefix ::= 'Prefix' '(' Name ANGLEBRACKIRI ')'
Import ::= 'Import' '(' ANGLEBRACKIRI PROFILE? ')'
Assert ::= 'Assert' '(' (RULE | Assert)* ')'
Query ::= 'Query' '(' FORMULA ')'
RULE ::= ('Forall' Var+ '(' CLAUSE ')') | CLAUSE
CLAUSE ::= Implies | HEAD
Implies ::= HEAD ':-' FORMULA
HEAD ::= ATOMIC | 'Exists' Var+ '(' HEAD ')' | 'And' '(' HEAD* ')'
PROFILE ::= ANGLEBRACKIRI

Condition Language:

FORMULA ::= 'And' '(' FORMULA* ')' |    % Main start symbol: formulas
            'Or' '(' FORMULA* ')' |
            'Exists' Var+ '(' FORMULA ')' |
            ATOMIC |
            'External' '(' Atom ')' |
            'Naf' '(' FORMULA ')'  % Atoms contained in FORMULAs can be relationships (for general exploration: framepoints and other psoa atoms) 
ATOMIC ::= Atom | Equal | Subclass
Atom ::= ATOMOIDLESS | ATOMOIDFUL  % Atoms can be oidless or oidful
Equal ::= TERM '=' TERM
Subclass ::= TERM '##' TERM  % Subclass is pars pro toto for Subpredicate
PSOA ::= Atom | Expr                    % Extra start symbol: psoa terms
ATOMOIDLESS ::= ATOMOIDLESSSHORT | ATOMOIDLESSLONG
ATOMOIDLESSSHORT ::= TERM '(' (TERM+ | TUPLEDI*) SLOTDI* ')'  % Left-tuple normal form
ATOMOIDLESSLONG ::= '#' ATOMOIDLESSSHORT
ATOMOIDFUL ::= TERM '#' ATOMOIDLESSSHORT
Expr ::= EXPRSHORT | EXPRLONG
EXPRSHORT ::= TERM ’(’ (TERM+ | TUPLED*) SLOTD* ’)’           % Left-tuple normal form
EXPRLONG ::= ’^’ EXPRSHORT
TUPLEDI ::= ('+' | '-') '[' TERM* ']'
SLOTDI ::= TERM ('+>' | '->') TERM
TUPLED ::= ’+’ ’[’ TERM* ’]’
SLOTD ::= TERM ’+>’ TERM
TERM ::= Const | Var | Atom | Expr | 'External' '(' Expr ')'
Const ::= '"' UNICODESTRING '"^^' SYMSPACE | CONSTSHORT
Var ::= '?' PN_LOCAL?
SYMSPACE ::= ANGLEBRACKIRI | CURIE
CONSTSHORT ::= ANGLEBRACKIRI | CURIE | '"' UNICODESTRING '"'
                                         | NumericLiteral | '_' PN_LOCAL?

The disambiguation of the LTNF grammar's ATOMOIDLESSSHORT and EXPRSHORT nonterminals was indicated in #Combining_Atoms_and_Expressions.

The LTNF grammar's ATOMOIDLESSSHORT and EXPRSHORT productions cause it to specify the left-tuple normal form through the order of the two kinds of (parenthesized) descriptors. For example, for ATOMOIDLESSSHORT: On the left, there either is an implicit dependent tuple, TERM+, or there are explicit Tuples, TUPLEDI*, each dependent (D) or independent (I). On the right, there are explicit slots, SLOTDI*, each D or I. Swapping the left and right sides, the symmetric right-tuple normal form can be obtained.

The ATOMOIDLESSSHORT and EXPRSHORT productions, as well as all their below modifications, also cause the LTNF grammar, as well as all its below variants, to realize two restrictions mentioned in the #Introduction: 1. All psoa terms can only have a single implicit tuple. 2. If it is present, there can be no explicit tuples.

The LTNF grammar can be generalized to the left-implicit-tuple normal form, as supported by PSOATransRun starting with Version 1.4.4, which restricts an implicit tuple to occur on the left of all slots, but does not restrict where explicit tuples occur. For this, the ATOMOIDLESSSHORT and EXPRSHORT productions are modified:

ATOMOIDLESSSHORT ::= TERM '(' (TERM+ SLOTDI*) | (TUPLEDI | SLOTDI)* ')'  % Left-implicit-tuple normal form
EXPRSHORT ::= TERM '(' (TERM+ SLOTD*) | (TUPLED | SLOTD)* ')'            % Left-implicit-tuple normal form

This 'mostly free' normal form is convenient for input of KBs and queries. It can be symmetrically complemented by a right-implicit-tuple normal form, which only restricts an implicit tuple to occur on the right of all slots, modifying the above (TERM+ SLOTD[I]*) to (SLOTD[I]* TERM+). Both of these can be further generalized to a free form, where an implicit tuple, as in POSL, can have slots on both of its sides, via modification to (SLOTD[I]* TERM+ SLOTD[I]*).

Conversely, the LTNF grammar can be specialized to the left-tuple, left-dependent normal form by a modified ATOMOIDLESSSHORT production that uses the new TUPLESDEIN (TUPLES DEpendent followed by INdependent) and SLOTSDEIN (SLOTS DEpendent followed by INdependent) productions for dependent-independent-ordered descriptor sequences:

ATOMOIDLESSSHORT ::= TERM '(' (TERM+ | TUPLESDEIN) SLOTSDEIN ')'  % Left-tuple, left-dependent normal form
. . .
TUPLESDEIN ::= ('+' '[' TERM* ']')* ('-' '[' TERM* ']')*
SLOTSDEIN ::= (TERM '+>' TERM)* (TERM '->' TERM)*

This (equivalently, right-slot, right-independent) normal form is used in the normative PSOA RuleML#Modular_Syntax. It can again be complemented by a right-tuple, right-dependent normal form in a symmetric manner.

The seven above forms constitute the following symmetric implication (generalization) hierarchy, where "... form => *** form" and "*** form <= ... form" represent "If an atom is in ... form then it is in *** form" (i.e, taxonomically, "The *** form generalizes the ... form"):

left-tuple, left-dependent normal form
  =>
    left-tuple normal form
      =>
        left-implicit-tuple normal form
          =>
            free form
          <=
        right-implicit-tuple normal form
      <=
    right-tuple normal form
  <=
right-tuple, right-dependent normal form

For example, "If an atom is in left-tuple normal form then it is in left-implicit-tuple normal form" (i.e, "The left-implicit-tuple normal form generalizes the left-tuple normal form") holds because the restrictions on atoms in left-tuple normal form [implicit and explicit tuples go left] include the restriction on atoms in left-implicit-tuple normal form [implicit tuples go left].

3.1.4.2 From PSOA RuleML Presentation Syntax to Serialization Syntax

For the left-tuple, left-dependent normal form of the core (dependent and independent) descriptor-defining EBNF-grammar productions of the Condition Language part of the presentation syntax (reproduced with a "P(resentation):" label), we give below corresponding EBNF-like productions bridging to the serialization syntax (introduced with an "X(ML):" label).

Condition Language descriptors in left-tuple, left-dependent normal form (Presentation to Serialization):

P:  TUPLESDEIN ::= ('+' '[' TERM* ']')* ('-' '[' TERM* ']')*
X:  TUPLESDEIN ::= tupdep*              tup*                 % Different edges
X:  tupdep ::= Tuple                                         % lead into same
X:  tup ::= Tuple                                            % Tuple Node

P:  SLOTSDEIN ::= (TERM '+>' TERM)* (TERM '->' TERM)*
X:  SLOTSDEIN ::= slotdep*          slot*                    % Different edges
X:  slotdep ::= TERM TERM                                    % lead into same
X:  slot ::= TERM TERM                                       % pair of TERM Nodes
3.1.4.3 Monolithic RNC for PSOA RuleML Serialization Syntax (Informative: Derived from Normative PSOA Modules)

Neither maintaining the top-level bi-partitioning nor the PSOA-specific nonterminal names of the earlier EBNF(-like) productions, the informative monolithic Relax NG (Compact) schema

https://github.com/RuleML/deliberation-ruleml/blob/1.03-psoa/simplified/naffologeqPSOA_normal.rnc

has been derived from the normative PSOA RuleML#Modular_Syntax.

While there is no PSOA RuleML schema counterpart to the earlier Deliberation RuleML supremum schema nafhologeq_normal.rnc (in Deliberation PSOA RuleML still a maximal schema), the above-linked PSOA maximal schema naffologeqPSOA_normal.rnc defines the most expressive language of the simplified (mostly w.r.t. modularization) Relax NG schemas that are at https://github.com/RuleML/deliberation-ruleml/tree/1.03-psoa/simplified.

The explanations and caveats of Specification of Deliberation RuleML 1.03#Appendix_2:_Simplified_Relax_NG_for_Deliberation_RuleML apply here as well.

3.1.5 Modular Syntax

The normative modular RNC for the PSOA RuleML serialization syntax corresponding to the informative monolithic RNC maximal schema in Monolithic RNC for PSOA RuleML Serialization Syntax (Informative: Derived from Normative PSOA Modules), and to two non-maximal anchor schemas, has been developed from the modular Deliberation RuleML 1.03 RelaxNG Directory and is available at the "...PSOA" rows of the "Schema Drivers for Anchor Languages" table in the

Adapting three normalized pre-PSOA anchor languages (datalog_normal, which specializes hornlog_normal, which itself specializes the non-maximal naffologeq_normal), three corresponding normalized PSOA anchor languages are defined (datalogPSOA_normal, which specializes hornlogPSOA_normal, which itself specializes the maximal naffologeqPSOA_normal).

The PSOA maximal-schema row "naffologeqPSOA" for naffologeqPSOA_normal in the above-linked table is in addition to the pre-PSOA maximal-schema row "nafhologeq" for nafhologeq_normal (where "fol" becomes "hol"): the PSOA-adapted Deliberation RuleML language semilattice has two maximal elements.

The PSOA adaptations concern the construct of Atoms (for all anchor languages), and the constructs of Atoms, Expressions, and Plexes (for anchor languages from Horn logic up to FOL). Within these constructs, the adaptations consist of

  • complementing pre-PSOA independent slots with dependent slots (slotdeps), and complementing a single pre-PSOA (dependent) implicit tuple of arguments with multiple independent (tup) and dependent (tupdep) explicit Tuples of arguments, as well as
  • omitting pre-PSOA positional rests (repo), which can be brought back as in the extended PSOA version of the RW 2015 tutorial (Ref. 7, Section 6), and slotted rests (resl), which are not needed for Atoms in the presence of PSOA's "describution", earlier called "distribution" (Ref. 7, Section 6).

Some sample instances may be found here:

For this development, the GitHub repository deliberation-ruleml was augmented with the branch 1.03-psoa.

3.1.5.1 Generating the Relax NG Schema Drivers

Each Relax NG schema driver file consists of include statements for schema modules, from which it composes a specific schema. For generating these driver files, the MYNG engine has been updated in 1.03-psoa for dependent slots and explicit tuples, as well as for Subclass. [Likewise, updates for "Configuring the Relax NG Schema Drivers" could be done by realizing the corresponding 1.03-psoa extensions of the MYNG GUI.] The PSOA anchor languages datalogPSOA_normal, hornlogPSOA_normal, and naffologeqPSOA_normal as well as many more PSOA non-anchor languages are configured from shared schema modules, including for slotdep (slotdep_expansion_module.rnc), tup (tup_expansion_module.rnc), tupdep (tupdep_expansion_module.rnc), and Tuple (tuple_expansion_module.rnc), as well as Subclass (subclass_expansion_module.rnc).

The resulting Relax NG schemas are available here (along with Relax NG-derived XSD schemas and their XSD-derived visual HTML Schemadocs):

For details see SpecPSOARuleMLXML103, Sections 3.1, 4, and 5, as well as Appendix A.

3.1.5.2 Testing of Relax NG Schemas

The RuleML instances used to test the Relax NG schemas are available in the rnc-test-suites directory, while the Bash scripts for testing are in the bash directory. The script used to validate the instances contained in rnc-test-suites is batch_rnc-test-suite.sh . All the scripts for testing the Relax NG schemas are designed to run offline in a clone of the Github repository, using the Jing engine to validate the test instances against local copies of the Relax NG schemas. The build_myng2rnc.sh master script executes the batch_rnc-test-suite tests as well as the following additional tests:

3.1.6 XSLT-Based Schematron Patterns

The XSLT-based Schematron is employed to check for patterns in XML trees. While the productions starting with Expr in #Monolithic_EBNF_for_PSOA_RuleML_Presentation_Syntax specify the restrictions of psoa expressions (relative to psoa atoms) in an 'inclusive' manner ("What is allowed?"), the corresponding Schematron <Expr> patterns below specify them in an 'exclusive' manner ("What is forbidden?"). To formalize the three constraints over psoa terms that are psoa expressions (rather than psoa atoms), the PSOA RuleML/XML specification employs three Schematron patterns.

A psoa expression cannot have

[PsoaExpressionConstraint1:]
an OID (it must be oidless),
[PsoaExpressionConstraint2:]
any independent slots (it can have dependent slots),
[PsoaExpressionConstraint3:]
any independent tuples (it can have dependent tuples).

Violations of these psoa-expression constraints are reported by the following Schematron formalization (also available as the stand-alone document PsoaExpressionConstraintsNoNS.sch and integrated into PsoaExpressionConstraints.sch):

<schema xmlns="http://purl.oclc.org/dsdl/schematron">
    <pattern id="PsoaExpressionConstraint1">
        <rule context="Expr">
            <report test="oid">Constraint violation: A psoa expression cannot have an OID.</report>
        </rule>
    </pattern>
    <pattern id="PsoaExpressionConstraint2">
        <rule context="Expr">
            <report test="slot">Constraint violation: A psoa expression cannot have any independent slots.</report>
        </rule>
    </pattern>
    <pattern id="PsoaExpressionConstraint3">
        <rule context="Expr">
            <report test="tup">Constraint violation: A psoa expression cannot have any independent tuples.</report>
        </rule>
    </pattern>
</schema>

The constraints apply to all PSOA RuleML languages:

  1. They are trivially fulfilled by RuleML languages that do not contain <Expr> such as the anchor language datalogPSOA and candidate instances such as the #Serialization_Preview's "(Independent-slot) framepoint atom in (fully striped) normal form".
  2. They may or may not be fulfilled by RuleML languages that do contain <Expr> such as the anchor languages hornlogPSOA and naffologeqPSOA and candidate instances such as the #Serialization_Preview's constraints-fulfilling "(Independent-slot) framepoint atom containing (dependent-)slot expression".

For both 1. and 2., a Schematron implementation such as the Free Online XML Validator (Schematron) of Liquid Technologies and the Schematron environment of the Oxygen XML editor can be used to detect any constraint violations.

If candidate instances have an xmlns attribute indicating the ruleml namespace such as the #Serialization_Preview's above-mentioned framepoint <Atom> extended to <Atom xmlns="http://ruleml.org/spec"> (or, if an enclosing element is correspondingly extended such as the document root to <RuleML xmlns="http://ruleml.org/spec" ...>), in the Schematron <schema ...> the namespace must be declared with an <ns/> child element and its ruleml: prefix used for all references to elements from the candidate instance (see explainSchematron), obtaining the following extended Schematron formalization (also available as the stand-alone document PsoaExpressionConstraintsNS.sch and integrated into PsoaExpressionConstraints.sch):

<schema xmlns="http://purl.oclc.org/dsdl/schematron">
    <ns uri="http://ruleml.org/spec" prefix="ruleml"/>
    <pattern id="PsoaExpressionConstraint1">
        <rule context="ruleml:Expr">
            <report test="ruleml:oid">Constraint violation: A psoa expression cannot have an OID.</report>
        </rule>
    </pattern>
    <pattern id="PsoaExpressionConstraint2">
        <rule context="ruleml:Expr">
            <report test="ruleml:slot">Constraint violation: A psoa expression cannot have any independent slots.</report>
        </rule>
    </pattern>
    <pattern id="PsoaExpressionConstraint3">
        <rule context="ruleml:Expr">
            <report test="ruleml:tup">Constraint violation: A psoa expression cannot have any independent tuples.</report>
        </rule>
    </pattern>
</schema>

Then, again a Schematron implementation can be used to detect constraint violations.

The README-documented schematron directory contains the three *.sch-schema variants and a *PSOA_fail.ruleml counter-example instance, as well as a pointer to exa/*PSOA/*PSOA.ruleml instances.

3.1.7 XSLT-Based Formatters

The PSOA RuleML/XML specification provides an XSLT transformation defining a normalizer, the most fundamental formatter, as a reference implementation (also providing a foundation for the compactifiers PSOA-adapting those in Specification of Deliberation RuleML 1.03#XSLT-Based_Compactifiers).

3.1.7.1 XSLT-Based Normalizer

The Specification of Deliberation RuleML 1.03#XSLT-Based_Normalizer is modified, on the level of atoms, to the Deliberation PSOA RuleML 1.03 Normalizer (importing normalizer_module.xslt and pretty-print_module.xslt) by canonically ordering slots and tuples as follows:

  1. Any tuples are put before any slots
  2. Any dependent tuples (slots) are put before any independent tuples (slots)

For details see SpecPSOARuleMLXML103, Sections 3.2, 4.3, and 6, as well as Appendix B.

3.1.7.2 XSLT-Based Compactifiers

The compactifier XSLTs specify formatters mapping into a compact serialization, which has fewer elements (i.e. is more compact) than the normalized serialization. Two variations of this formatter specification are provided due to some limitations of XSD schemas.

  1. The full compactifier specifies the removal of all skippable RuleML stripes, after first applying the normalizer to sort the child nodesets into the canonical order.
  2. The ifthen compactifier specifies the removal of all skippable RuleML stripes except the <if> and <then> edges within <Implies>, after first applying the normalizer to sort the child nodesets into the canonical order.

3.1.8 Online Tools for Extended Normalidation

The following online tools can be applied to candidate PSOA RuleML instances (e.g., to the valid sample instances linked in the lead paragraphs of #Modular_Syntax) for -- required parts of -- an "extended normalidation" workflow performing "first normalization with XSLT, second validation with RNC (or XSD), third validation with Schematron (based on XSLT)":

  1. SpecPSOARuleMLXML103, Appendix B: Normalizing a PSOA Instance via an XSLT Stylesheet.
  2. SpecPSOARuleMLXML103, Appendix A: Validating a PSOA Instance against an RNC Schema.
  3. #XSLT-Based_Schematron_Patterns, Free Online XML Validator (Schematron) of Liquid Technologies: Validating a PSOA Instance against a Schematron Schema.

3.2 Semantics

RuleML as a system of families of languages does not provide a default semantics but allows the specification of semantic profiles (see Specification of RuleML 1.03). PSOA RuleML as a subsystem of RuleML narrows the space of semantic profiles as specifed by the model-theoretic semantics below. PSOA RuleML's reference implementation PSOATransRun, in particular PSOATransRun[PSOA2Prolog,XSBProlog], operationalizes a parameterized semantic profile by queries and answers defining its procedural semantics.

The original specification of the PSOA RuleML Tarski-model-theoretic semantics is given in Ref. 1, Section 3. This semantics is explained, also in comparison to RIF-BLD, in Ref. 7, Section 7. A revised specification is introduced for object virtualization in Ref. 12, Section 3. A further revised specification is provided for perspectivity, in particular dependency (in/dependent-tuple, in/dependent-slot psoa terms) in Ref. 15, Section 5. Its version [v3], with the compatibility-assuring transformations embobj and remcrt of #PSOA2Prolog_Features_and_Limitations, constitutes the semantics of PSOA RuleML 1.03. For PSOA Naf languages, an adaptation of RIF's stable model (answer set) semantics is explored (also see ASP RuleML).

A Herbrand-model-theoretic semantics is exemplified in Ref. 29.

4 Implementations

4.1 PSOATransRun

In order to support reasoning in PSOA RuleML, we have implemented the open-source PSOATransRun system (Ref. 36: poster), whose evolution is structured by the PSOATransRun Development Agenda. PSOATransRun combines two parts. The first, PSOA2i, for translation from PSOA presentation syntax to an intermediate language i. The second, r, for some runtime engine executing the language i. The system can have multiple instantiations using different intermediate languages, where different combinations of a translator PSOA2i and a runtime engine r are employed. Three PSOATransRun[PSOA2i,r] instantiations are available: PSOATransRun[PSOA2TPTP,VampirePrime], for online and (Linux-based) local use, and PSOATransRun[PSOA2Prolog,XSBProlog] and PSOATransRun[PSOA2Prolog,SWIProlog], for local use.

Online, Web-based service (targeting only TPTP): https://psoademo-chatty-cat.eu-gb.mybluemix.net/
Local, downloadable executable (targeting TPTP or Prolog): http://psoa.ruleml.org/transrun/1.5.1/local/

Project Repository (sources): https://github.com/RuleML/PSOATransRunComponents

The directory "local" for the current release indicates that the release can be executed on a local machine (in contrast to the Web-based release). In our project repository, the "PSOATransRun" project includes both (1) the sources for combining the translator and the runtime engine and (2) the sources of the command line interface for the downloadable executable. The "PSOATransRunWebService" project is a wrapper of "PSOATransRun" for the Web-based service.

Examples: See the Examples section.

4.1.1 TPTP Instantiation

The TPTP instantiation employs the popular TPTP format, supported by many first-order logic reasoners, as the intermediate language. This PSOATransRun[PSOA2TPTP,VampirePrime] combines PSOA2TPTP and VampirePrime into a RESTful API.

It was started as a Semantic Web Techniques Course Project (Fall 2011) version and evolved to the version of the Prerelease of PSOA RuleML 1.03 and Release of PSOATransRun 1.4.3 with Web-based Service.

Workflow of using this online PSOATransRun (illustrated with a pre-entered KB and query for a workmix-extended RichTA example, while further sample KBs and queries can be obtained from the Examples section):

1) load the PSOATransRun Web-based Service page;

2) enter a KB into the "KB Source" textbox (ignore this step if you use the sample KB pre-entered by the system);

3) click "Translate KB" (takes you to the "KB Target + Query" tab and the "KB Target" in the TPTP format is shown);

4) enter a query into the "Query Source" textbox (for example, John#Teacher(coursehours+>20) or use the sample query pre-entered by the system);

5) click "Translate Query" (leaves you on the "KB Target + Query" tab, and the "Query Target" in the TPTP format is appended after the "Query Source");

6) click "Execute" (takes you to the "Execution Result" tab and the result is shown).

4.1.1.1 PSOA2TPTP

PSOA2TPTP is a translator mapping knowledge bases and queries in the PSOA RuleML presentation syntax to TPTP (as used for the above-described PSOATransRun Web-based Service). The translator, currently composed of a lexer, a parser, and tree walkers, is generated by the ANTLR v3 parser generator tool from the grammars we developed. Details can be found in Ref. 3.

4.1.1.1.1 VampirePrime

VampirePrime is Alexandre Riazanov's first-order logic reasoner. Since VampirePrime is written in C++, linking some libraries that are not on current Linux distributions, a compiled version, called vkernel, had to be used. For maintenance and portability, once compatible versions of the C++ libraries are identified, the VampirePrime C++ sources from the Software by Alexandre Riazanov, "VampirePrime reasoner", need to be recompiled.

4.1.1.2 PSOA2TPTP Features and Limitations

The implementation of PSOATransRun's TPTP instantiation has the following features and limitations (the limitations in #PSOA2Prolog_Features_and_Limitations also apply here):

  • Terms
    • Constants
      • Local constants: constant names that have only digits with a prefix '_', such as _1 and _2, are disallowed since they are reserved for objectification
      • Integers
    • Variables: variable name ?obj is disallowed since it is reserved for objectification
    • Psoa terms: any form of psoa terms acting as atomic formulas are supported while psoa terms acting as function applications are not
      • Syntactic sugar supported: (1) omission of '[' and ']' for single tuple psoa terms; (2) omission of '(' and ')' for psoa term with only type information
      • Objectification for OID-less psoa terms is supported
  • Formulas
    • Conjunction
    • Existential quantification
    • Universal quantification
    • Built-ins are not supported
    • Naf is not supported

4.1.2 Prolog Instantiation

The Prolog instantiation employs the widely used logic programming language Prolog as the intermediate language, supported by many engines. This PSOATransRun[PSOA2Prolog,XSBProlog] combines PSOA2Prolog and XSB Prolog. PSOATransRun Version 1.4 introduced PSOATransRun[PSOA2Prolog,SWIProlog] as an additional instantiation, combining PSOA2Prolog and SWI Prolog.

Releases:

http://psoa.ruleml.org/transrun/0.7/local/

http://psoa.ruleml.org/transrun/0.8/local/

http://psoa.ruleml.org/transrun/1.0/local/

http://psoa.ruleml.org/transrun/1.1/local/

http://psoa.ruleml.org/transrun/1.2/local/

http://psoa.ruleml.org/transrun/1.3/local/

http://psoa.ruleml.org/transrun/1.3.1/local/

http://psoa.ruleml.org/transrun/1.3.2-a/local/

http://psoa.ruleml.org/transrun/1.3.2-b/local/

http://psoa.ruleml.org/transrun/1.3.2/local/

http://psoa.ruleml.org/transrun/1.4/local/

http://psoa.ruleml.org/transrun/1.4.1/local/

http://psoa.ruleml.org/transrun/1.4.2/local/

http://psoa.ruleml.org/transrun/1.4.3/local/

http://psoa.ruleml.org/transrun/1.4.4/local/

http://psoa.ruleml.org/transrun/1.4.5/local/

http://psoa.ruleml.org/transrun/1.5/local/

http://psoa.ruleml.org/transrun/1.5.1/local/

4.1.2.1 PSOA2Prolog

PSOA2Prolog is a translator mapping knowledge bases and queries in the PSOA RuleML presentation syntax to Prolog. The translator, currently composed of a lexer, a parser, and tree walkers, is generated by the ANTLR v3 parser generator tool from the grammars we developed. The tree walkers first normalize the input knowledge base or query within PSOA RuleML and then convert the normal form to Prolog.

4.1.2.1.1 XSB Prolog

XSB Prolog is a Prolog engine that allows tabling of facts to improve reasoning efficiency and avoid certain infinite loops of the traditional top-down Prolog execution model.

4.1.2.1.2 SWI Prolog

From PSOATransRun v1.4 onward, SWI Prolog is also supported. SWI Prolog is a widespread Prolog engine with many available libraries. It offers a smooth installation procedure for many operating systems and enjoys good community support. However, despite allowing tabling, this support is not yet mature and the user should expect a speed disadvantage compared to XSB Prolog. Also, date-related predicates and functions of the physics library are not supported.

4.1.2.2 PSOA2Prolog Features and Limitations

The implementation of PSOATransRun's Prolog instantiation Version 1.5.1 has the following features and limitations (the limitations also apply to #PSOA2TPTP_Features_and_Limitations):

The features mainly extend those of #PSOA2TPTP_Features_and_Limitations by #Built-ins and, since Version 1.4.5 (PSOATransRun 1.4.5 RELEASE NOTES), varieties of Naf.

A purposeful limitation is the following:

  • The implemented expressions can have only one dependent tuple and no dependent slots

Three atom/expression features and limitations are the following (they also apply to #PSOA2TPTP_Features_and_Limitations):

  1. Besides the implemented (oidful) hash infix, "#", the syntactic indication of predicates -- hence atoms -- with the (oidless) hash prefix, "#", is implemented
  2. The syntactic indication of functions -- hence expressions -- with the caret prefix, "^", is not implemented
  3. To distinguish embedded expressions from embedded atoms, the latter must either be oidful, thus using a hash infix (cf. Ref. 12) or, if oidless, use a hash prefix (triggering embedded objectification), where both hash uses allow subsequent embedded-atom unnesting

As of Version 1.5 (PSOATransRun 1.5 RELEASE NOTES), the presentation-syntax distinction of embedded expressions from embedded oidless atoms has been sufficiently implemented -- via the atom/expression features 1. and 3. -- to also allow the 1.5 implementation of embedded objectification (embobj) of embedded oidless atoms, which, in turn, has made the pre-1.5 implementation of unnesting generally applicable (even without user-provided OIDs).

The above atom/expression features and limitations 1. and 2. are demonstrated by the following subset of the only allowed examples from the systematic variations of #Presentation_Syntax_Long_and_Short_Forms:
For embeddings in the positions of tuple elements and slot fillers:
1.2.:   #p(#p1(#p2(a u+>v)) s+>#q1(b c))
2.1.1.: p(f1(f2(a u+>v)) s+>g1(b c))
2.2.1.: p(#p1(#p2(a u+>v)) s+>#q1(b c))
For embeddings in the positions of tuple elements and slot names:
1.2.:   #p(#p1(#p2(a u+>v)) #q1(b c)+>t)
2.1.1.: p(f1(f2(a u+>v)) g1(b c)+>t)
2.2.1.: p(#p1(#p2(a u+>v)) #q1(b c)+>t)
For embeddings in the positions of OIDs and slot fillers:
1.2.:   #p1(#p2(a u+>v))#p(s+>#q1(b c))
2.1.1.: f1(f2(a u+>v))#p(s+>g1(b c))
2.2.1.: see 1.2.

Embedded objectification, exemplified with an embedded #store atom in the Presentation Preview (As a predicate) and with embedded atoms in #Presentation_Syntax_Long_and_Short_Forms, is a semantics-preserving transformation of t(. . . #f(...) . . .) to Exists ?i ( t(. . . o#f(...) . . .)), where the new existential scope is needed only for case 2 and o is chosen as in top-level objectification: case 1., as a fresh local constant from o=_1, o=_2, ..., for a ground fact; case 2., as a new, existentially scoped variable o=?i, for a non-ground fact or an atomic formula in a rule conclusion; case 3., as an anonymous variable (o=?), for a query or a rule condition (Refs. 1, 12, 15).

The following compatibility-assuring transformations can be defined on the query's and the KB's embedded terms:

[embobj] perform embedded objectification on the embedded oidless terms with a hash prefix (i.e., on the embedded oidless atoms)
[remcrt] raise an exception for terms with a top-level caret prefix (top-level functions are not implemented), and remove any caret prefixes from the embedded terms

Before running a PSOA RuleML 1.03 query/KB pair on the PSOATransRun 1.5.1 system, it need to undergo the compatibility-assuring transformation remcrt or some equivalent.

A gradually relaxed limitation is the following:

  • The relationship-atom-only Naf is extended for (certain uses of) framepoints and other psoa atoms

A quantifier-syntax limitation has been the following:

  • For Exists quantifiers inside rule conditions, the quantified variables have to be uniquely named, where, additionally, Exists quantifiers can be replaced by equivalent Forall quantifiers around entire rules
4.1.2.3 Built-ins

The Prolog instantiation of PSOATransRun provides built-in mathematical predicates and functions. To use the compact IRI form of a built-in in a KB, its prefix needs to be declared at the beginning of the KB, e.g.

Prefix(isopl: <https://www.iso.org/standard/21413.html#>)

Built-ins are regarded as externally defined terms and need to be called using an External(...) wrapper. Built-in predicates are called directly, e.g.

External(isopl:eq(42 42))

Built-in functions are called using an equality, e.g.

?X = External(isopl:add(41 1))

The list of all supported built-ins is shown in the following.

Predicates

RIF predicates uses the pred: prefix, declared as

Prefix(pred: <http://www.w3.org/2007/rif-builtin-predicate#>)
numeric-equal 
pred:numeric-equal(num1 num2) yields true iff both arguments, num1 and num2, are numerically equal.
numeric-not-equal 
pred:numeric-not-equal(num1 num2) yields true iff both arguments, num1 and num2, are not numerically equal.
numeric-greater-than 
pred:numeric-greater-than(num1 num2) yields true iff num1 is numerically greater but not equal to num2.
numeric-greater-than-or-equal 
pred:numeric-greater-than-or-equal(num1 num2) yields true iff num1 is numerically greater or equal to num2.
numeric-less-than 
pred:numeric-less-than(num1 num2) yields true iff num1 is numerically less than but not equal to num2.
numeric-less-than-or-equal 
pred:numeric-less-than-or-equal(num1 num2) yields true iff num1 is numerically less then or equal to num2.
is-literal-double 
pred:is-literal-double(num) yields true iff the argument num is of form double.
is-literal-integer 
pred:is-literal-integer(num) yields true iff the argument num is of form integer.

Functions

RIF functions uses the func: prefix, declared as

Prefix(func: <http://www.w3.org/2007/rif-builtin-function#>)
numeric-add 
func:numeric-add(num1 num2) yields the sum of the 2 arguments, num1 and num2, passed to the function.
numeric-subtract 
func:numeric-subtract(num1 num2) yields the remainder of the 2 arguments, num1 and num2, passed to the function.
numeric-multiply 
func:numeric-multiply(num1 num2) yields the product of the 2 arguments num1 and num2.
numeric-divide 
func:numeric-divide(num1 num2) yields the quotient of 2 arguments, num1 and num2, num1 being divided by num2.
numeric-integer-divide 
func:numeric-integer-divide(num1 num2) yields the quotient of the integer-division of 2 integer arguments, num1 and num2, the first argument num1 being the dividend and the second argument num2 being the divisor.
numeric-mod 
func:numeric-mod(num1 num2) yields the remainder of num1 divided by num2. The sign of the result is the same as num1.


ISO Prolog predicates and functions use the isopl: prefix, declared as

Prefix(isopl: <https://www.iso.org/standard/21413.html#>)

Predicates

integer 
isopl:integer(num) yields true iff the argument num is of form integer.
float 
isopl:float(num) yields true iff the argument num is a float number.
number 
isopl:number(num) yields true iff the argument num is a number of any form.
eq 
isopl:eq(num1 num2) yields true iff both numeric arguments, num1 and num2, are numerically equal.
not_eq 
isopl:not_eq(num1 num2) yields true iff both arguments, num1 and num2, are not numerically equal.
greater_than 
isopl:greater_than(num1 num2) yields true iff num1 is numerically greater but not equal to num2.
greater_than_or_eq 
isopl:greater_than_or_eq(num1 num2) yields true iff num1 is numerically greater or equal to num2.
less_than 
isopl:less_than(num1 num2) yields true iff num1 is numerically less than but not equal to num2.
less_than_or_eq 
isopl:less_than_or_eq(num1 num2) yields true iff num1 is numerically less then or equal to num2.

Functions

add 
isopl:add(num1 num2) yields the sum of the 2 arguments, num1 and num2, passed to the function.
sub 
isopl:sub(num1 num2) yields the remainder of the 2 arguments, num1 and num2, passed to the function.
mul 
isopl:mul(num1 num2) yields the product of the 2 arguments, num1 and num2.
int-div 
isopl:int-div(num1 num2) yields the quotient of the integer-division of 2 integer arguments, the first argument num1 being the dividend and the second argument num2 being the divisor.
div 
isopl:div(num1 num2) yields the quotient of 2 numeric arguments, num1 being divided by num2.
abs 
isopl:abs(num) yields the absolute value of a single numeric argument num.
rem 
isopl:rem(num1 num2) yields the remainder of num1 divided by num2. The sign of the result is the same as num1.
mod 
isopl:mod(num1 num2) yields the remainder of num1 divided by num2. The sign of the result is the same as num2.
sign 
isopl:sign(num) yields -1, 0 or 1 for negative numbers, zero or positive numbers respectively based on the sign of the single numeric argument num.
float 
isopl:float(num) yields the single argument num in form of a float number. If the argument num is already a float number, it is not changed.
truncate 
isopl:truncate(num) yields the integer part of the single float number argument num, yields the argument if it is of form integer.
round 
isopl:round(num) yields the result of rounding the single numeric argument num.
floor 
isopl:floor(num) yields the result of rounding down the single numeric argument num.
ceiling 
isopl:ceiling(num) yields the result of rounding up the single numeric argument num.
power 
isopl:power(num1 num2) yields the result of the first numeric argument num1 raised to the power of the second numeric argument num2.
sin 
isopl:sin(num) yields the sine of the single numeric argument num in radians, where the argument is also expressed in radians.
cos 
isopl:cos(num) yields the cosine of the single numeric argument num in radians, where the argument is also expressed in radians.
atan 
isopl:atan(num) yields the arc tangent of the single numeric argument num in radians, where the argument is also expressed in radians.
sqrt 
isopl:sqrt(num) yields the square root of the single numeric argument num.
exp 
isopl:exp(num) yields the result of the exponential function 'e^x' with x being the single numeric argument num.
log 
isopl:log(num) yields the result of the natural logarithm 'ln(x) with x being the single numeric argument num.
4.1.2.4 PSOA Libraries

Besides built-ins, we have developed libraries in PSOA RuleML containing predicates that can be reused by other PSOA KB developers, which can be found at http://psoa.ruleml.org/lib/. To use a library, we need to import the specific library file, e.g. phys.psoa, using, e.g., the following statement

Import(<http://psoa.ruleml.org/lib/phys.psoa>)

To use the compact IRI form of a predicate in a library, a prefix declaration need to be added, e.g.

Prefix(phys: <http://psoa.ruleml.org/lib/phys#>)

Unlike built-ins, predicates from the libraries are directly called without using an External(...) wrapper.

phys:tryDate(phys:date(2017 12 31))

Currently, PSOA RuleML offers 2 libraries: 'math' and 'physics'.

  • Math library

Math library predicates use the math: prefix, declared as

Prefix(math: <http://psoa.ruleml.org/lib/math.psoa#>)
lessThan 
math:lessThan(num1 num2) yields true iff num1 is numerically less than but not equal to num2.
greaterThan 
math:greaterThan(num1 num2) yields true iff num1 is numerically greater but not equal to num2.
lessEq 
math:lessEq(num1 num2) yields true iff num1 is numerically less than or equal to num2.
greaterEq 
math:greaterEq(num1 num2) yields true iff num1 is numerically greater or equal to num2.
sum 
math:sum(num1 num2 num3) yields true iff num1 is equal to the arithmetic sum of num2 through num3. If the first argument is a variable then it will be bound to the result of the arithmetic sum of the second argument through the last argument.
diff 
math:diff(num1 num2 num3) yields true iff num1 is equal to the arithmetic difference of num2 minus num3. If the first argument is a variable then it will be bound to the result of the arithmetic difference of the second argument minus the last argument.
prod 
math:prod(num1 num2 num3) yields true iff num1 is equal to the arithmetic product of num2 through num3. If the first argument is a variable then it will be bound to the arithmetic product of the second argument through the last argument.
quot 
math:quot(num1 num2 num3) yields true iff num1 is equal to the arithmetic quotient of num2 divided by num3. If the first argument is a variable then it will be bound to the arithmetic quotient of the second argument divided by the third argument.
  • Physics library

Physics library predicates and functions use the phys: prefix, declared as

Prefix(phys: <http://psoa.ruleml.org/lib/phys.psoa#>)

Date and time testing predicates

tryDate 
phys:tryDate(d) yields true if argument d is of form phys:date(year month day) where the year, month and day are integers. Yields an error if the argument d is not of the right format.
tryTime 
phys:tryTime(t) yields true if argument t is of form phys:time(hour minute second) where the hour, minute and second are integers. Yields an error if the argument t is not of the right format.
tryDatetime 
phys:tryDatetime(dt) yields true if argument dt is of form phys:datetime(year month day hour minute second) yields true for the date and time part of the argument. Yields an error if the argument d is not of the right format.

Date comparison predicates

lessThanDate 
phys:lessThanDate(d1 d2) yields true if both phys:date arguments evaluate true for phys:tryDate(d), and d1 is less than d2.
lessEqDate 
phys:lessEqDate (d1 d2) yields true if both phys:date arguments evaluate true for phys:tryDate(d), and d1 is less than or equal to d2.
greaterThanDate 
phys:greaterThanDate(d1 d2) yields true if both phys:date arguments evaluate true for phys:tryDate(d), and d1 is greater than d2.
greaterEqDate 
phys:greaterEqDate(d1 d2) yields true if both phys:date arguments evaluate true for phys:tryDate(d), and d1 is greater than or equal to d2.
eqDate 
phys:eqDate(d1 d2) yields true if both phys:date arguments evaluate true for phys:tryDate(d), and d1 is equal to d2.

Time comparison predicates

lessThanTime 
phys:lessThanTime(t1 t2) yields true if both phys:time arguments evaluate true for phys:tryTime(t), and t1 is less than t2.
lessEqTime 
phys:lessEqTime(t1 t2) yields true if both phys:time arguments evaluate true for phys:tryTime(t), and t1 is less than or equal to t2.
greaterThanTime 
phys:greaterThanTime(t1 t2) yields true if both phys:time arguments evaluate true for phys:tryTime(t), and t1 is greater than or equal to t2.
greaterEqTime 
phys:greaterEqTime(t1 t2) yields true if both phys:time arguments evaluate true for phys:tryTime(t), and t1 is greater than or equal to t2.
eqTime 
phys:eqTime(t1 t2) yields true if both phys:time arguments evaluate true for phys:tryTime(t), and t1 is equal to t2.

Datetime comparison predicates

lessThanDatetime 
phys:lessThanDatetime(dt1 dt2) yields true if both phys:datetime arguments evaluate true for phys:tryDatetime(dt), and dt1 is less than dt2.
lessEqDatetime 
phys:lessEqDatetime(dt1 dt2) yields true if both phys:datetime arguments evaluate true for phys:tryDatetime(dt), and dt1 is less than or equal to dt2.
greaterThanDatetime 
phys:greaterThanDatetime(dt1 dt2) yields true if both phys:datetime arguments evaluate true for phys:tryDatetime(dt), and dt1 is greater than dt2.
greaterEqDatetime 
phys:greaterEqDatetime(dt1 dt2) yields true if both phys:datetime arguments evaluate true for phys:tryDatetime(dt), and dt1 is greater than or equal to dt2.
eqDatetime 
phys:eqDatetime(dt1 dt2) yields true if both phys:datetime arguments evaluate true for phys:tryDatetime(dt), and dt1 is equal to dt2.

Date yielding predicates

currentDatetime 
phys:currentDatetime(dt) yields the current date-and-time value dt on the local system in the form of phys:datetime(year month day hour minute second).
currentDatetimeUTC 
phys:currentDatetimeUTC(dt) yields the current date-and-time value dt for the current UTC date in the form of phys:datetime(year month day hour minute second).
currentDate 
phys:currentDate(d) yields the current date value d on the local system in the form of phys:date(year month day).
currentDateUTC 
phys:currentDateUTC(d) yields the current date value d for the current UTC date in the form of phys:date(year month day).
currentTime 
phys:currentTime(t) yields the current time value t on the local system in the form of phys:time(hour minute second).
currentTimeUTC 
phys:currentTimeUTC(t) yields the current time value t for the current UTC date in the form of phys:time(hour minute second).

4.2 cl-psoatransrun

As the second realization for reasoning in PSOA RuleML, in a joint project with RuleML, Mark Thom has implemented the open-source cl-psoatransrun system in Common Lisp, following the paradigm of functional programming for the central transformation steps.

Releases (official RuleML forks):

https://github.com/RuleML/cl-psoatransrun/releases/tag/cl-psoatransrun-v1.0 (https://github.com/RuleML/cl-psoatransrun/blob/cl-psoatransrun-v1.0/README.md)


5 Examples

6 Test Cases

The following examples serve to test different instantiations of the PSOATransRun implementation. A comment is given for each copy&paste-ready query line that fails or successfully returns variable bindings. A ground query without any comment is also assumed to succeed. A structured directory of related test cases employed by our unit-test system can be found at https://github.com/RuleML/PSOATransRunComponents/tree/master/PSOATransRun/test.

6.1 Equality Primitive with Psoa Constants

  • Knowledge Base (Empty Document)
Document ()
  • Queries
42 = 42
57 = 42            % Fail
-42 = -42
-57 = -42          % Fail
3.1 = 3.1
2.7 = 3.1          % Fail
_art = _art
_abc = _art        % Fail
"art" = "art"
"abc" = "art"      % Fail
"a r t" = "a r t"
"art" = "a r t"    % Fail
"a b c" = "a r t"  % Fail
"a b c" = "a b c"
"a r t a b c" = "a r t a b c"
<http://example.org> = <http://example.org>
<http://example.org> = <http://example.com>  % Fail

6.2 Equality Primitive with Psoa Constants having Prefixes

  • Knowledge Base (Groupless Document)
Document (
  Prefix(: <http://psoa.ruleml.org/test#>)  % Empty prefix
  Prefix(ex: <http://example.org/example#>)
)
  • Queries
:art = :art
:abc = :art        % Fail
ex:try = ex:try
ex:tst = ex:try    % Fail

6.3 Equality Primitive with Psoa Variables

  • Knowledge Base (Empty Document)
Document ()
  • Queries
?x = 42
?x = 57
And(?x = 42 ?x = 57) % Fail
And(?x = 42 ?x = 42)
And(?x = 57 ?x = 57)
And(?x = 42 ?y = 57)


6.4 Equality Primitive with Psoa Functions

  • Knowledge Base (Empty Document)
Document ()
  • Queries
_f(42) = _f(42)
_f(57) = _f(42)         % Fail
_f(?x) = _f(42)         % ?x=42
_g(42 57) = _g(42 57)
_g(42 42) = _g(42 57)   % Fail
_g(42 ?y) = _g(42 57)   % ?y=57
_g(?x ?y) = _g(42 57)   % ?x=42 ?y=57
_g(?x ?x) = _g(42 57)   % Fail
_g(_f(42) 57) = _g(_f(42) 57)
_g(_f(?x) ?x) = _g(_f(42) 42)  % ?x=42
_g(_f(?x) ?x) = _g(_f(42) 57)  % Fail
And(_g(_f(?x) ?x) = _g(_f(42) 42) _h(?x _f(?x)) = _h(42 _f(42)))  % ?x=42

6.5 External Primitive for Predicate Arithmetic Built-Ins

  • Knowledge Base (Groupless Document)
Document (
  Prefix(pred: <http://www.w3.org/2007/rif-builtin-predicate#>)
)
  • Queries
External(pred:numeric-equal(42 42))
External(pred:numeric-equal(42 +42))
External(pred:numeric-equal(+42 42))
External(pred:numeric-equal(+42 +42))
External(pred:numeric-not-equal(42 57))
External(pred:numeric-less-than(42 57))
External(pred:numeric-greater-than(42 57))            % Fail
External(pred:numeric-less-than-or-equal(42 42))
External(pred:numeric-less-than-or-equal(42 57))
External(pred:numeric-greater-than-or-equal(42 42))
External(pred:numeric-greater-than-or-equal(42 57))   % Fail

6.6 Equality Primitive with External Primitive for Functional Arithmetic Built-Ins

  • Knowledge Base (Groupless Document)
Document (
  Prefix(func: <http://www.w3.org/2007/rif-builtin-function#>)
)
  • Queries
42 = External(func:numeric-add(26 16))
57 = External(func:numeric-add(26 16))               % Fail
?x = External(func:numeric-add(26 16))               % ?x=42
?x = External(func:numeric-subtract(57 15))          % ?x=42
?x = External(func:numeric-multiply(21 2))           % ?x=42
?x = External(func:numeric-integer-divide(126 3))    % ?x=42
?x = External(func:numeric-integer-divide(128 3))    % ?x=42
?x = External(func:numeric-divide(126 3))            % ?x=42.0
?x = External(func:numeric-divide(126.8 4))          % ?x=31.7
?x = External(func:numeric-divide(127 4))            % ?x=31.75
?x = External(func:numeric-divide(-126 4))           % ?x=-31.5
?x = External(func:numeric-mod(128 3))               % ?x=2
?x = External(func:numeric-mod(-128 3))              % ?x=-2

6.7 Purchase Facts

  • Knowledge Base
Document (
  Group (
                    _purchase1a(_John _Mary _Fido)                          % oidless
    _transaction100#_purchase1b(_John _Mary _Fido)                          % oidful
    
                    _purchase2a(_buyer->_John _seller->_Mary _item->_Fido)  % oidless
    _transaction200#_purchase2b(_buyer->_John _seller->_Mary _item->_Fido)  % oidful
    
                    _purchase3a(_John _Mary _item->_Fido)                   % oidless
    _transaction300#_purchase3b(_John _Mary _item->_Fido)                   % oidful
  )
)
  • Queries
   _purchase1a(?b ?s ?i)          % ?b=_John ?s=_Mary ?i=_Fido
?o#_purchase1a(?b ?s ?i)          % Extra binding: ?o=_oidcons(_purchase1a _John _Mary _Fido)  (Implementation-specific fresh name)
   _purchase1b(?b ?s ?i)          % ?b=_John ?s=_Mary ?i=_Fido   
?o#_purchase1b(?b ?s ?i)          % Extra binding: ?o=_transaction100
   _purchase2a(_buyer->?b _seller->?s _item->?i)  % ?b=_John ?s=_Mary ?i=_Fido
?o#_purchase2a(_buyer->?b _seller->?s _item->?i)  % Extra binding: ?o=_1  (Implementation-specific fresh name)
   _purchase2b(_buyer->?b _seller->?s _item->?i)  % ?b=_John ?s=_Mary ?i=_Fido
?o#_purchase2b(_buyer->?b _seller->?s _item->?i)  % Extra binding: ?o=_transaction200  (Implementation-specific fresh name)
   _purchase2a(_buyer->?b _item->?i _seller->?s)  % ?b=_John ?s=_Mary ?i=_Fido
?o#_purchase2a(_buyer->?b _item->?i _seller->?s)  % Extra binding: ?o=_1  (Implementation-specific fresh name)
   _purchase2b(_buyer->?b _item->?i _seller->?s)  % ?b=_John ?s=_Mary ?i=_Fido
?o#_purchase2b(_buyer->?b _item->?i _seller->?s)  % Extra binding: ?o=_transaction200  (Implementation-specific fresh name)
   _purchase2a(_buyer->?b)         % ?b=_John
?o#_purchase2a(_buyer->?b)         % Extra binding: ?o=_1    (Implementation-specific fresh name)
   _purchase2b(_buyer->?b)         % ?b=_John
?o#_purchase2b(_buyer->?b)         % Extra binding: ?o=_transaction200
   _purchase3a(?b ?s _item->?i)    % ?b=_John ?s=_Mary ?i=_Fido
?o#_purchase3a(?b ?s _item->?i)    % Extra binding: ?o=_2    (Implementation-specific fresh name)
   _purchase3b(?b ?s _item->?i)    % ?b=_John ?s=_Mary ?i=_Fido
?o#_purchase3b(?b ?s _item->?i)    % Extra binding: ?o=_transaction300
   _purchase3a(?b ?s)              % ?b=_John ?s=_Mary
?o#_purchase3a(?b ?s)              % Extra binding: ?o=_2    (Implementation-specific fresh name)
   _purchase3b(?b ?s)              % ?b=_John ?s=_Mary
?o#_purchase3b(?b ?s)              % Extra binding: ?o=_transaction300

6.8 Purchase-Conditioned Ground Rules

  • KB
Document(
  Group(
    _purchase1(_John  _Mary  _Fido)
    _transaction200#_purchase2(_buyer->_John _seller->_Mary _item->_Fido)

    _liability1(_John _Fido) :-
      _purchase1(_John  _Mary  _Fido)
    _registration800#_liability2(_bearer->_John _item->_Fido) :-
      _transaction200#_purchase2(_buyer->_John _seller->_Mary _item->_Fido)
  )
)
  • Queries
   _liability1(?b ?i)                   %  ?b=_John ?i=_Fido
?o#_liability1(?b ?i)                   %  Extra binding: ?o=_oidcons(_liability1 _John _Fido)  (Implementation-specific fresh name)
   _liability2(_bearer->?b _item->?i)  %  ?b=_John ?i=_Fido
?o#_liability2(_bearer->?b _item->?i)  %  Extra binding: ?o=_registration800

6.9 Purchase-Conditioned Non-Ground Rules

  • KB
Document(
  Group(
    _purchase1(_John  _Mary  _Fido)
    _transaction200#_purchase2(_buyer->_John _seller->_Mary _item->_Fido)

    Forall ?b ?s ?i (
      _liability1(?b ?i) :-
        _purchase1(?b ?s ?i)
    )
    Forall ?b ?s ?i ?t (
      _liability2ID(?t)#_liability2(_bearer->?b _item->?i) :-
        ?t#_purchase2(_buyer->?b _seller->?s _item->?i)
    )
  )
)
  • Queries
   _liability1(?b ?i)                   %  ?b=_John ?i=_Fido
?o#_liability1(?b ?i)                   %  Extra binding: ?o=_oidcons(_liability1 _John _Fido)  (Implementation-specific fresh name)
   _liability2(_bearer->?b _item->?i)  %  ?b=_John ?i=_Fido
?o#_liability2(_bearer->?b _item->?i)  %  Extra binding: ?o=_liability2ID(_transaction200)

6.10 Single-Tuple Psoa Term

  • Knowledge Base
Document (
  Group (
    _o1#_p(_a1 _a2)
  )
)
  • Queries
_o1#_p(?x _a2)        % ?x=_a1
_o1#_p(?1 _a2)        % ?1=_a1 (variable-name portion of ?1 happens to be an integer)

6.11 Multi-Slot Psoa Term

  • Knowledge Base
Document (
  Group (
    _o1#_p(_a->1 _b->2)
  )
)
  • Queries
_o1#_p(_a->1)
_o1#_p(_a->?x)        % ?x=1  (slot-filler query)
_o1#_p(?1->1)         % ?1=_a (slot-name query)
_o1#_p(?2->?3)        % ?2=_a ?3=1; ?2=_b ?3=2

6.12 Multi-Valued Slot

  • Knowledge Base
Document (
  Group (
    _Adam#_Person(_father->_John)
    _Jack#_Person(_father->_John)
    _Tom#_Person(_father->_John)

    Forall ?Ch ?M
    (
       ?M#_Male(_child->?Ch) :- ?Ch#_Person(_father->?M)
    )
  )
)
  • Queries
_John#_Male(_child->?c1)  % ?c1=_Adam; ?c1=_Jack; ?c1=_Tom
_John#_Male(_child->?c1 _child->?c2)  % {_Adam, _Jack, _Tom} × {_Adam, _Jack, _Tom}
_John#_Male(_child->?c1 _child->?c2 _child->?c3)   % {_Adam, _Jack, _Tom} × {_Adam, _Jack, _Tom} × {_Adam, _Jack, _Tom}

6.13 Psoa Terms with Slots and Tuples

  • Knowledge Base
Document (
  Group (
    _f1#_family(_John _Mary _child->_Tom)
    _f2#_family([_Tom _Jane] _income->100000)
    _f3#_family([_Mike _Jessie] [1951] _child->_Fred _child->_Jane)
    _Jane#_Person([_female] [_bcs _mcs _phd] _job->_engineer)
  )
)
  • Queries
_f1#Top(_John _Mary)
_f2#_family(?1->?2)                     % ?1=_income ?2=100000
_f3#_family(_Mike _Jessie _child->?c)   % ?c=_Fred; ?c=_Jane
_Jane#_Person([_bcs _mcs _phd] _job->_engineer)

6.14 Class Membership

From http://www.w3.org/2005/rules/wiki/Class_Membership

  • Knowledge Base
Document (
  Prefix(fam: <http://example.org/family#>)

  Group ( 
    Forall ?X ?Y ( 
      fam:isFatherOf(?Y ?X) :- And(fam:isChildOf(?X ?Y) ?Y#fam:Male  )
    )

    fam:isChildOf(fam:Adrian fam:Uwe)
    fam:Adrian#fam:Male
    fam:Uwe#fam:Male 
  )
)
  • Queries
fam:isFatherOf(fam:Uwe fam:Adrian)

6.15 Family 1

  • Knowledge Base (Non-objectified source)
Document (
  Group (
    Forall ?Hu ?Wi ?Ch (
      _family(_husb->?Hu _wife->?Wi _child->?Ch) :-
        And(_married(?Hu ?Wi) _kid(?Hu ?Ch))
    )
    Forall ?Hu ?Wi ?Ch (
      _family(_husb->?Hu _wife->?Wi _child->?Ch) :-
        And(_married(?Hu ?Wi) _kid(?Wi ?Ch))
    )
    _married(_Joe _Sue)
    _kid(_Sue _Pete)
  )
)
  • Knowledge Base (Objectified source)
Document (
  Group (
    Forall ?Hu ?Wi ?Ch (
      Exists ?obj1 (?obj1#_family(_husb->?Hu _wife->?Wi _child->?Ch)) :-
        And(Exists ?obj2 (?obj2#_married(?Hu ?Wi))
            Exists ?obj3 (?obj3#_kid(?Hu ?Ch)) )
    )
    Forall ?Hu ?Wi ?Ch (
      Exists ?obj1 (?obj1#_family(_husb->?Hu _wife->?Wi _child->?Ch)) :-
        And(Exists ?obj2 (?obj2#_married(?Hu ?Wi))
            Exists ?obj3 (?obj3#_kid(?Wi ?Ch)) )
    )
    _1#_married(_Joe _Sue)
    _2#_kid(_Sue _Pete)
  )
)
  • Queries
_married(_Joe _Sue)
_family(_husb->_Joe _wife->_Sue _child->?Ch)   % ?Ch=_Pete

6.16 Family 2

  • Knowledge Base (With both oidless and oidful atoms)
Document (
  Group (
    Forall ?Hu ?Wi (
      _family(_husb->?Hu _wife->?Wi) :-
              _married(?Hu ?Wi)
    )
    Forall ?Hu ?Ch ?o (            % Accommodates single-parent families ('husb'-only)
      ?o#_family(_child->?Ch) :-
        And(?o#_family(_husb->?Hu)
            _kid(?Hu ?Ch))
    )
    Forall ?Wi ?Ch ?o (            % Accommodates single-parent families ('wife'-only)
      ?o#_family(_child->?Ch) :-
        And(?o#_family(_wife->?Wi)
            _kid(?Wi ?Ch))
    )
    _married(_Joe _Sue)
    _kid(_Sue _Pete)
    _kid(_Joe _Tom)
  )
)
  • Queries
_family(?p->?v)    % ?p=_husb ?v=_Joe; ?p=_wife ?v=_Sue; ?p=_child ?v=_Pete; ?p=_child ?v=_Tom
_family(_husb->_Joe _child->?Ch)    % ?Ch=_Pete; ?Ch=_Tom
_family(_husb->?Hu _wife->?Wi _child->?Ch)    % ?Hu=_Joe ?Wi=_Sue ?Ch=_Tom; ?Hu=_Joe ?Wi=_Sue ?Ch=_Pete
And(_family(_husb->_Joe _wife->_Sue _child->?Who) _kid(_Sue ?Who))    % ?Who=_Pete
Exists ?1 (?1#_family(?p->?v))    % ?p=_husb ?v=_Joe; ?p=_wife ?v=_Sue; ?p=_child ?v=_Pete; ?p=_child ?v=_Tom
Exists ?1 (?1#_family(_husb->_Joe _child->?Ch))    % ?Ch=_Pete; ?Ch=_Tom
Exists ?1 (?1#_family(_husb->?Hu _wife->?Wi _child->?Ch))    % ?Hu=_Joe ?Wi=_Sue ?Ch=_Tom; ?Hu=_Joe ?Wi=_Sue ?Ch=_Pete
And(Exists ?1 (?1#_family(_husb->_Joe _wife->_Sue _child->?Who)) _kid(_Sue ?Who))    % ?Who=_Pete
?1#_family()    % ?1=_skolem1(_Joe _Sue)   (Implementation-specific fresh name)

6.17 Family 2'

  • Knowledge Base (With only oidful atoms)
Document (
  Group (
    Forall ?Hu ?Wi (
      Exists ?obj1 (?obj1#_family(_husb->?Hu _wife->?Wi)) :-
             Exists ?obj2 (?obj2#_married(?Hu ?Wi))
    )
    Forall ?Hu ?Wi ?Ch ?o (
      ?o#_family(_child->?Ch) :-
        And(?o#_family(_husb->?Hu _wife->?Wi)
            Exists ?obj3 (?obj3#_kid(?Hu ?Ch)) )
    )
    Forall ?Hu ?Wi ?Ch ?o (
      ?o#_family(_child->?Ch) :-
        And(?o#_family(_husb->?Hu _wife->?Wi)
            Exists ?obj4 (?obj4#_kid(?Wi ?Ch)) )
    )
    _m1#_married(_Joe _Sue)
    _k1#_kid(_Sue _Pete)
    _k2#_kid(_Joe _Tom)
  )
)
  • Queries
_family(?p->?v)    % ?p=_husb ?v=_Joe; ?p=_wife ?v=_Sue; ?p=_child ?v=_Pete; ?p=_child ?v=_Tom
_family(_husb->_Joe _child->?Ch)    % ?Ch=_Pete; ?Ch=_Tom
_family(_husb->?Hu _wife->?Wi _child->?Ch)    % ?Hu=_Joe ?Wi=_Sue ?Ch=_Tom; ?Hu=_Joe ?Wi=_Sue ?Ch=_Pete
And(_family(_husb->_Joe _wife->_Sue _child->?Who) _kid(_Sue ?Who))    % ?Who=_Pete
Exists ?1 (?1#_family(?p->?v))    % ?p=_husb ?v=_Joe; ?p=_wife ?v=_Sue; ?p=_child ?v=_Pete; ?p=_child ?v=_Tom
Exists ?1 (?1#_family(_husb->_Joe _child->?Ch))    % ?Ch=_Pete; ?Ch=_Tom
Exists ?1 (?1#_family(_husb->?Hu _wife->?Wi _child->?Ch))    % ?Hu=_Joe ?Wi=_Sue ?Ch=_Tom; ?Hu=_Joe ?Wi=_Sue ?Ch=_Pete
And(Exists ?1 (?1#_family(_husb->_Joe _wife->_Sue _child->?Who)) _kid(_Sue ?Who))    % ?Who=_Pete
?1#_family()    % ?1=_skolem1(_Joe _Sue)   (Implementation-specific fresh name)

6.18 Startup A

  • Knowledge Base
Document (
  Group (
    Forall ?CEO ?CTO ?E (
      _startup1(_ceo->?CEO _cto->?CTO _employee->?E) :- 
          And(_cofounders(?CEO ?CTO) _hire(?CEO ?E))
    )
   
    Forall ?CEO ?CTO ?E (
      _startup2ID(?CEO ?CTO ?E)#_startup2(_ceo->?CEO _cto->?CTO _employee->?E) :- 
          And(_cofounders(?CEO ?CTO) _hire(?CEO ?E))
    )
    
    Forall ?CEO ?CTO ?E (
      _startup3ID(?CEO ?CTO)#_startup3(_ceo->?CEO _cto->?CTO _employee->?E) :- 
          And(_cofounders(?CEO ?CTO) _hire(?CEO ?E))
    )
    
    Forall ?CEO ?CTO ?E (
      _startup4(?CEO ?CTO _employee->?E) :- 
          And(_cofounders(?CEO ?CTO) _hire(?CEO ?E))
    )
   
    Forall ?CEO ?CTO ?E (
      _startup5ID(?CEO ?CTO ?E)#_startup5(?CEO ?CTO _employee->?E) :- 
          And(_cofounders(?CEO ?CTO) _hire(?CEO ?E))
    )
    
    Forall ?CEO ?CTO ?E (
      _startup6ID(?CEO ?CTO)#_startup6(?CEO ?CTO _employee->?E) :- 
          And(_cofounders(?CEO ?CTO) _hire(?CEO ?E))
    )
    
    _cofounders(_Ernie _Tony)
    _hire(_Ernie _Kate)
    _hire(_Ernie _Fred)
  )
)
  • Queries
_startup1(_ceo->?X _cto->?Y _employee->?Z)     % ?X=_Ernie ?Y=_Tony ?Z=_Fred; ?X=_Ernie ?Y=_Tony ?Z=_Kate
?O#_startup1(_ceo->?X _cto->?Y _employee->?Z)  % Extra bindings: ?O=_skolem1(_Ernie _Tony _Fred); ?O=_skolem1(_Ernie _Tony _Kate) (Implementation-specific fresh names)
_startup2(_ceo->?X _cto->?Y _employee->?Z)     % ?X=_Ernie ?Y=_Tony ?Z=_Fred; ?X=_Ernie ?Y=_Tony ?Z=_Kate
?O#_startup2(_ceo->?X _cto->?Y _employee->?Z)  % Extra bindings: ?O=_startup2ID(_Ernie _Tony _Fred); ?O=_startup2ID(_Ernie _Tony _Kate)
_startup3(_ceo->?X _cto->?Y _employee->?Z)     % ?X=_Ernie ?Y=_Tony ?Z=_Fred; ?X=_Ernie ?Y=_Tony ?Z=_Kate
?O#_startup3(_ceo->?X _cto->?Y _employee->?Z)  % Extra bindings (same object): ?O=_startup3ID(_Ernie _Tony); ?O=_startup3ID(_Ernie _Tony)
_startup4(?X ?Y _employee->?Z)     % ?X=_Ernie ?Y=_Tony ?Z=_Fred; ?X=_Ernie ?Y=_Tony ?Z=_Kate
?O#_startup4(?X ?Y _employee->?Z)  % Extra bindings: ?O=_skolem1(_Ernie _Tony _Fred); ?O=_skolem1(_Ernie _Tony _Kate) (Implementation-specific fresh names)
_startup5(?X ?Y _employee->?Z)     % ?X=_Ernie ?Y=_Tony ?Z=_Fred; ?X=_Ernie ?Y=_Tony ?Z=_Kate
?O#_startup5(?X ?Y _employee->?Z)  % Extra bindings: ?O=_startup5ID(_Ernie _Tony _Fred); ?O=_startup5ID(_Ernie _Tony _Kate)
_startup6(?X ?Y _employee->?Z)     % ?X=_Ernie ?Y=_Tony ?Z=_Fred; ?X=_Ernie ?Y=_Tony ?Z=_Kate
?O#_startup6(?X ?Y _employee->?Z)  % Extra bindings (same object): ?O=_startup6ID(_Ernie _Tony); ?O=_startup6ID(_Ernie _Tony)
?O#_startup6(?X ?Y _employee->?Z1 _employee->?Z2)  % Four answers for same _startup6ID(_Ernie _Tony), including ?Z1=_Fred ?Z2=_Kate

6.19 Startup B

  • Knowledge Base
Document (
  Group (
    Forall ?CEO ?CTO (
       _startup(?CEO ?CTO) :- 
           _cofounders(?CEO ?CTO)
    )
     
    Forall ?O ?CEO ?CTO ?E (
       ?O#Top(_employee->?E) :-
           And(?O#_startup(?CEO ?CTO)
               _hire(?CEO ?E))
    )
    
    _cofounders(_Ernie _Tony)
    _hire(_Ernie _Kate)
    _hire(_Ernie _Fred)
  )
)
  • Queries
?O#_startup(?X ?Y)                   % ?O=_skolem1(_Ernie _Tony) ?X=_Ernie ?Y=_Tony  (Implementation-specific fresh name _skolem1(...))
?O#_startup(_employee->?Z)           % ?O=_skolem1(_Ernie _Tony) ?Z=_Fred; ?O=_skolem1(_Ernie _Tony) ?Z=_Kate  (Implementation-specific fresh name _skolem1(...))
?O#_startup(?X ?Y _employee->?Z)     % Extra bindings: ?X=_Ernie ?Y=_Tony; ?X=_Ernie ?Y=_Tony

6.20 Rules over Ground and Non-Ground Psoa Terms

  • Knowledge Base
Document (
  Group (
    _a#_C(_o _b _p3->_v3) :- _o#_R4(_a _b)
    _o#_R4(_a _b) :- _o#_R3(_a _b _p1->_v1)
    Forall ?X ?1 (
      ?1#Top(_p1->_v1) :- And(?1#_R3(?X _b) ?1#_R2())
    )
    _o#_R3() :- And(_o#_R2() _o#_R1(_p2->_v2))

    _o#_R2(_a _b _p2->_v2)
    _o#_R1()
  )
)
  • Queries
_a#_C(_o _b)
_o#?r(_a _b)      % ?r=_R1; ?r=_R2; ?r=_R3; ?r=_R4
_o#Top(?p->?v)    % ?p=_p2, ?v=_v2; ?p=_p1, ?v=_v1

6.21 Rules over Non-Ground Psoa Terms

  • Knowledge Base
Document (
  Group (
    Forall ?X ?Y ?1 (
      ?1#_R4(?X ?Y) :- ?1#_R3(?X ?Y _p2->_v2)
    )
    Forall ?X ?Y ?1 (
      ?1#_R3(?X ?Y) :- And(?X#_C2(_p3->_v3) ?1#_R2(?X ?Y))
    )
    Forall ?1 ?X ?Y (
      ?1#_R2(?X ?Y _p1->_v1 _p2->_v2) :- ?1#_R1(?X ?Y)
    )
    Forall ?1 (
      ?1#_C2() :- ?1#_C1()
    )

    _a1#_C1()
    _o1#_R1(_a1 _b1)
    _a2#_C1(_p3->_v3 _p4->_v4)
    _o2#_R1(_a2 _b2)
    _a3#_C1()
    _o3#_R1(_a3 _b3 _c3)
  )
)
  • Queries
_a1#_C2()
_o1#_R1(_p1->_v1)
_o2#_R3(_a2 _b2)
_o2#_R4(_a2 _b2 _p1->_v1 _p2->_v2)
?1#_R3(_a2 ?Y)           % ?1=_o2 ?Y=_b2
?2#_R4(?X ?Y)            % ?2=_o2 ?X=_a2 ?Y=_b2
_o2#_R1(_a2 _b2 ?p->?v)  % ?p=_p1 ?v=_v1; ?p=_p2 ?v=_v2
?3#_R4(?X ?Y ?p->?v)     % ?3=_o2 ?X=_a2 ?Y=_b2 ?p=_p1 ?v=_v1; ?3=_o2 ?X=_a2 ?Y=_b2 ?p=_p2 ?v=_v2
_o2#?r(_a2 _b2)          % ?r=_R1; ?r=_R2; ?r=_R3; ?r=_R4
_o3#_R1(_p1->_v1)        % Fail

6.22 Conjunctive Query of Non-Ground Fact

From http://www.w3.org/2005/rules/wiki/EntailEverything

  • Knowledge Base
Document (
  Prefix(ex: <http://example.org/example#>)

  Group (
    Forall ?x ( ex:A(?x) )
  ) 
)
  • Queries
And(
  ex:A(2)
  ex:A("any string")
  ex:A(<http://some.example.org>)
)

6.23 Multiple Entailment

  • Knowledge Base
Document (
  Group (
    Forall ?x (_o1#_p(_a ?x))
    Forall ?x (_o1#_p(?x _b))
  )
)
  • Queries
_o1#_p(_a _b)
_o1#_p(_b _a)    % Fail


6.24 Objectification of Relational Psoa Terms

  • Knowledge Base
Document (
  Group (
    Forall ?x ?y (
      _g(?y ?x) :- _f(?x ?y)
    )
    _f(_a _b)
  )
)
  • Queries
_g(_b _a)
And(_f(_a _b) _g(_b _a))


6.25 Recursion

  • Knowledge Base
Document (
  Group (
    Forall ?anc ?par ?des (
      _isDescendentOf(?des ?anc) :- And(_isChildOf(?des ?par) _isDescendentOf(?par ?anc))
    )
    Forall ?par ?ch (
      _isDescendentOf(?ch ?par) :- _isChildOf(?ch ?par)
    )
    _isChildOf(_Pete _Sue)
    _isChildOf(_Sue _John)
    _isChildOf(_John _Tom)
    _Pete#_Person(_sex->_Male _age->24)
    _Sue#_Person(_sex->_Female _age->47)
    _John#_Person(_sex->_Male _age->77)
  )
)
  • Queries
_isDescendentOf(_Sue _Tom)
And(_isDescendentOf(?Who _Tom) ?Who#_Person(_sex->_Male _age->?Age))  % ?Who=_Pete ?Age=24; ?Who=_John ?Age=77

6.26 Subclass 1

  • Knowledge Base
Document (
  Group (
    _o1#_c1(_a1 _a2)
    _o2#_c1(_p->_v)
    _c1##_c2
  )
)
  • Queries
_o1#_c2(_a1 _a2)
_o2#_c2(_p->_v)
?1#_c2(_a1 ?2)   % ?1=_o1 ?2=_a2
?1#_c2(_p->?2)   % ?1=_o2 ?2=_v

6.27 Subclass 2

  • Knowledge Base
Document (
  Group (
    _o1#_c1(_p->_v1)
    _o2#_c3(_p->_v2)
    _o3#_c5(_p->_v3 _q->_w0)
    _c1##_c2
    _c1##_c3
    _c2##_c4
    _c3##_c4
    _c4##_c6
    _c5##_c6
  )
)
  • Queries
_o1#?c                 % ?c=_c1; ?c=_c2; ?c=_c3; ?c=_c4; ?c=_c6
?o#_c4                 % ?o=_o1; ?o=_o2
?o#_c6(_p->?v)         % ?o=_o1 ?v=_v1; ?o=_o2 ?v=_v2; ?o=_o3 ?v=_v3
?o#_c6(_p->?v _q->?w)  % ?o=_o3 ?v=_v3 ?w=_w0


6.28 Factorial with Relational Arithmetic Tables

  • Knowledge Base
Document (
  Group (
    Forall ?x ?y ?fx ?fy (
      _factorial(?y ?fy) :- 
         And(_factorial(?x ?fx) _multiply(?fx ?y ?fy) _sum(?x 1 ?y))
    )
    _factorial(0 1)

    _sum(0 1 1)
    _sum(1 1 2)
    _sum(2 1 3)
    _sum(3 1 4)

    _multiply(1 1 1)
    _multiply(1 2 2)
    _multiply(2 3 6)
    _multiply(6 4 24)
  )
)
  • Queries
_factorial(4 24)
_factorial(?x ?fx)   % ?x=0 ?fx=1; ?x=1 ?fx=1; ?x=2 ?fx=2; ?x=3 ?fx=6; ?x=4 ?fx=24

6.29 Factorial with Eq-Functional Arithmetic Tables

  • Knowledge Base
Document (
  Group (
    Forall ?x ?y ?fx ?fy (
      _eq(?fy _factorial(?y)) :- 
         And(_eq(?fx _factorial(?x)) _eq(?fy _multiply(?fx ?y)) _eq(?y _sum(?x 1)))
    )
    _eq(1 _factorial(0))

    _eq(1 _sum(0 1))
    _eq(2 _sum(1 1))
    _eq(3 _sum(2 1))
    _eq(4 _sum(3 1))

    _eq(1 _multiply(1 1))
    _eq(2 _multiply(1 2))
    _eq(6 _multiply(2 3))
    _eq(24 _multiply(6 4))
  )
)
  • Queries
_eq(24 _factorial(4))
_eq(?fx _factorial(?x))   % ?x=0 ?fx=1; ?x=1 ?fx=1; ?x=2 ?fx=2; ?x=3 ?fx=6; ?x=4 ?fx=24

6.30 Factorial 3

  • Knowledge Base
Document (
  Prefix(pred: <http://www.w3.org/2007/rif-builtin-predicate#>)
  Prefix(func: <http://www.w3.org/2007/rif-builtin-function#>)
 
  Group (
    Forall ?N ?F ?N1 ?F1 (
      _factorial(?N ?F) :-  
         And(External(pred:numeric-greater-than(?N 0)) 
             ?N1 = External(func:numeric-subtract(?N 1)) 
             _factorial(?N1 ?F1) 
             ?F = External(func:numeric-multiply(?N ?F1)) )
    )
    _factorial(0 1)
  )
)
  • Queries
_factorial(5 120)
_factorial(5 ?X)    % ?X=120


6.31 Concatenation

  • Knowledge Base (Source)
Document (
  Group (
    Forall ?first ?rest ?x ?y (
      _concat(_cns(?first ?rest) ?x _cns(?first ?y)) :- _concat(?rest ?x ?y)
    )
    Forall ?x ( _concat(_nil ?x ?x) )
  )
)
  • Knowledge Base (Objectified)
Document (
  Group (
    Forall ?first ?rest ?x ?y ?2 (
      Exists ?1 (?1#_concat(_cns(?first ?rest) ?x _cns(?first ?y)))
        :- ?2#_concat(?rest ?x ?y)
    )
    Forall ?x ( Exists ?1 (?1#_concat(_nil ?x ?x)) )
  )
)
  • Queries
_concat(_cns(1 _cns(3 _nil)) _cns(1 _nil) ?x)                    % ?x=_cns(1 _cns(3 _cns(1 _nil)))
_concat(_cns(1 _cns(3 _nil)) ?x _cns(1 _cns(3 _cns(2 _nil))))    % ?x=_cns(2 _nil)

6.32 Music Album

  • Knowledge Base

A fragment of http://www.cs.unb.ca/~boley/papers/MusicAlbumKB.txt (Executable http://www.cs.unb.ca/~boley/papers/MusicAlbumKB.psoa)

Document (
  Prefix (: <http://psoa.ruleml.org/example/music_album#>)
  
  Group (
    :o1#:albsplitObj( :artist->"Van Morrison"   :title->"Astral Weeks"              :favorite->"Madame George"     )
    :o2#:albsplitObj( :artist->"Beatles"        :title->"Sgt. Pepper's"             :favorite->"A Day in the Life" )
    :o3#:albsplitObj( :artist->"Beatles"        :title->"Abbey Road"                :favorite->"Something"         )
    :o4#:albsplitObj( :artist->"Rolling Stones" :title->"Sticky Fingers"            :favorite->"Brown Sugar"       )
    :o5#:albmergeObj( :artist->"Eagles"                :tivorite->"Hotel California"                               )
    :o6#:albmergeObj( :artist->"Elton John"            :tivorite->"Goodbye Yellow Brick Road"                      )
    :albmergeObj##:albsplitObj
    Forall ?OID ?Tivorite
    (
      ?OID#:albsplitObj(:title->?Tivorite :favorite->?Tivorite)  :-  ?OID#:albmergeObj(:tivorite->?Tivorite)
    )
  )
)
  • Queries
?OID#:albsplitObj(:artist->?Artist :title->?Title)  % OIDs {:o1, ..., :o6} and corresponding artist and title slot fillers are returned
?OID#:albsplitObj(:title->?Title :artist->?Artist)  % Same as above
?OID#:albsplitObj(:favorite->?Favorite)             % OIDs {:o1, ..., :o6} and corresponding favorite slot fillers are returned
?OID#:albsplitObj(:artist->?Artist :title->?Title :favorite->?Favorite)  % OIDs {:o1, ..., :o6} and corresponding slot fillers are returned
?OID#:albmergeObj(:artist->"Elton John" :favorite->?Favorite)   % ?OID=<http://psoa.ruleml.org/example/music_album#o6> ?Favorite="Goodbye Yellow Brick Road"
:o6#:albsplitObj(:artist->"Elton John" :favorite->?Favorite)    % ?Favorite="Goodbye Yellow Brick Road"

6.33 Slotribution 1

  • Knowledge Base
Document (
  Group (
    Forall ?X ( ?X#_block(_color->_blue _size->_big) )
    _b1#_book
    _b2#_book(_title->"Java Programming")
    _o#_albmergeObj( _artist->"Elton John" _tivorite->"Goodbye Yellow Brick Road" )
    Forall ?OID ?Tivorite
    (
      ?OID#_albsplitObj(_title->?Tivorite _favorite->?Tivorite) :- ?OID#_albmergeObj(_tivorite->?Tivorite)
    )
  )
)
  • Queries
_a#_block(_color->_blue)
_b1#_block(_color->_blue)
?B#_book(_title->?T)   % ?B=_b2 ?T="Java Programming"

6.34 Slotribution 2

  • Knowledge Base
Document (
  Prefix(: <http://psoa.ruleml.org/test#>)
  Prefix(func: <http://www.w3.org/2007/rif-builtin-function#>)
 
  Group (
    %  The meaning of the :captial slot varies when it is used with the :Country and :Startup predicates.
    %  This does not lead to problems since the set of OIDs of :Country and :Startup are disjoint. 
    %  However, generally, such predicate-dependent slots should be handled with care.

    Forall ?C ?X (
      ?C#:Country(:capital->?X) :-
                  :geo-in(:government(?C) ?X)
    )

    Forall ?S ?X ?F ?V (
      ?S#:Startup(:capital->?X) :-
                  And(:founder-capital(?S ?F)
                      :venture-capital(?S ?V)
                      ?X = External(func:numeric-add(?F ?V)))
    )
   
    :geo-in(:government(:Canada) :Ottawa)
    :founder-capital("XYZ Inc." 100000)
    :venture-capital("XYZ Inc." 200000)
  )
)
  • Queries
?C#:Country(:capital->?X)  % ?C=<http://psoa.ruleml.org/test#Canada> ?X=<http://psoa.ruleml.org/test#Ottawa>
?S#:Startup(:capital->?X)  % ?S="XYZ Inc." ?X=300000

6.35 Mixed Use of Psoa Terms with and without OIDs

  • Knowledge Base
Document (
  Prefix (: <http://psoa.ruleml.org/test#>)
  
  Group (
    Forall ?X ?Y ( 
      :isFatherOf(?Y ?X) :- And( :isChildOf(?X ?Y) ?Y#:Male )
    )

    :c1#:isChildOf(:Adrian :Uwe)
    :Adrian#:Male
    :Uwe#:Male

    Forall ?X ?Y ?C ( 
      :isMotherOf(?Y ?X) :- And( ?C#:isChildOf(?X ?Y) ?Y#:Female )
    )
    :isChildOf(:Adrian :Emily)
    :Emily#:Female
  )
)


  • Queries
:isFatherOf(?X1 ?X2)  % ?X1=<http://psoa.ruleml.org/test#Adrian> ?X2=<http://psoa.ruleml.org/test#Uwe>
:isMotherOf(?X1 ?X2)  % ?X1=<http://psoa.ruleml.org/test#Adrian> ?X2=<http://psoa.ruleml.org/test#Emily>

6.36 Subclass Axiomatization

  • Knowledge Base
Document (
  Prefix (: <http://psoa.ruleml.org/test#>)

  Group (
    Forall ?X
    (
      ?X#:c1 :- ?X#:c2
    )
    Forall ?X
    (
      ?X#:c1(:p1->:v1) :- ?X#:c2(:p2->:v1)
    )
    :o1#:c2
    :o2#:c2(:p2->:v1)

    Forall ?X
    (
      ?X#:c1 :- ?X#:c3
    )
    Forall ?X
    (
      ?X#Top(:p1->:v1) :- ?X#:c3(:p2->:v1)
    )
    :o3#:c3(:p2->:v1)
  )
)
  • Queries
:o1#:c1
:o2#:c1
:o1#:c1(:p1->:v1)
:o2#:c1(:p1->:v1)
:o3#:c1(:p1->:v1)

7 Use Cases

Besides the above Test Cases, the following PSOA RuleML use cases have been developed.

7.1 Port Clearance Rules

Uses rules for encoding ship regulations motivated by the Decision Management Challenge March-2016 as well as ship test facts, all copy&paste-ready as the Port Clearance Knowledge Base and documented with query examples in Ref. 13.

7.2 Geospatial Rules

Uses rules for enhancing geospatial data in a geographic information system (GIS) or a GIS combination (Geospatial Rules).

7.3 OfficeProspector

Uses rules for helping companies find suitable office suites (Ref. 18).

7.4 Medical Devices Rules

Uses rules for formalizing the Regulation (EU) 2017/745 on medical devices (Medical Devices Rules and Refs. 24, 28, 33).

7.5 GDPR Checking Rules

Uses rules for checking the General Data Protection Regulation (GDPR) (EU) 2016/679 (GDPRChecking).

7.6 Air Traffic Control KB

Uses rules for Air Traffic Control (ATC) according to FAA and ICAO regulations (ATC KB, described in award-winning Ref. 26 and in Ref. 34).

7.7 Exoskeletons' CE marking Rules (ExosCE)

Uses rules for formalizing the Regulations on exoskeletons' CE marking (ExosCE) (ExosCE Rules and Refs. 42).

8 Major Changes

8.1 PSOA RuleML Changes

[2018-11-11] Changed terminology for common names from "frame" to "framepoint", "shelf" to "shelfpoint", and "shelframe" to "shelframepoint", complementing newly introduced "relationship"-like common names "frameship", "shelfship", and "shelframeship"
[2019-08-03] Revised terminology and metamodel for the third dimension, from "perspeneutral" vs. "perspectival" (old notion of "perspectivity") to, respectively, "independent" vs. "dependent" (new notion of "dependency"), correspondingly changed shortcuts for systematic names from "pnI", "pvI", "ppI" to, respectively, "inI", "deI", "idI", and introduced a broader characterization of "non-perspectival" vs. "perspectival" (new notion of "perspectivity")
[2020-01-08] Restricted psoa expressions to be without an OID and only with dependent descriptors
[2020-01-27] Transferred the explicit distinction of predicates and functions via, resp., Rel and Fun (within, resp., Atom and Expr) in the serialization syntax to the presentation syntax via, resp., the absence and presence of a caret (^) prefix for operators, preparing embedded objectification (2020-05-11: Updated the distinction to, resp., the presence of a hash (#) prefix and the presence of a caret prefix, as explained in #Combining_Atoms_and_Expressions, thus confining the need for (hash) prefixing to the less common embedded Atoms instead of needing (caret) prefixes within the more common embedded Exprs)

8.2 PSOATransRun Changes

  • Changed translation of o#f() from member(o,f) to memterm(o,f), employed by both PSOA2Prolog and PSOA2TPTP, because member is a built-in predicate in some Prolog engines, e.g. SWI Prolog

9 Acronym Details

"PSOA", the acronym used throughout this text for "Positional-Slotted Object-Applicative", is typically employed as part of "PSOA RuleML", although "RuleML" is often left implicit in the context (for other meanings of "PSOA" see acronymfinder.com/PSOA.html). As started in the lead paragraphs, we use the all-upper-case "PSOA" as a reference to the language and the all-lower-case "psoa" for its terms (atoms and expressions). As seen from its expanded form, "PSOA" mostly refers to two dimensions of the metamodel:

  • "Object-Applicative" refers to Dimension 1 of oidless/oidful psoa atoms as well as to each atom's oidless/oidful application of a predicate to arguments and each expression's oidless application of a function to arguments
  • "Positional-Slotted" refers to Dimension 2 of argument variety, where "positional" is now usually called "tupled", and instead of "multi-positional" we speak of "multi-tupled"

10 References

1. Harold Boley, A RIF-Style Semantics for RuleML-Integrated Positional-Slotted, Object-Applicative Rules. In Nick Bassiliades, Guido Governatori, and Adrian Paschke, editors, RuleML Europe, volume 6826 of LNCS, pp. 94–211. Springer, 2011. SpringerLink: Abstract. Preprint: http://www.cs.unb.ca/~boley/papers/SemanticsPsoaRules.pdf. Slides for IJCAI 2011 Best Papers from Sister Conferences Track: http://www.cs.unb.ca/~boley/talks/SemanticsPsoaRules-talk-IJCAI2011.pdf. Slides with maximum details from paper: http://www.cs.unb.ca/~boley/talks/SemanticsPsoaRules-talk-UNB2011.pdf

2. Zou, G., Peter-Paul, R., Boley, H., Riazanov, A.: PSOA2TPTP: A Reference Translator for Interoperating PSOA RuleML with TPTP Reasoners. In: Bikakis, A., Giurca, A. (eds.) RuleML 2012. LNCS, vol. 7438, pp. 264–279. Springer, Heidelberg (2012). Preprint: http://www.cs.unb.ca/~boley/papers/DirectPSOA2TPTP.pdf. Slides: http://www.cs.unb.ca/~boley/talks/DirectPSOA2TPTP-talk.pdf

3. Zou, G., Peter-Paul, R., Boley, H., Riazanov, A.: PSOATransRun: Translating and Running PSOA RuleML via the TPTP Interchange Language for Theorem Provers. 6th International Rule Challenge, RuleML 2012. Preprint: http://www.cs.unb.ca/~boley/papers/PSOATransRun.pdf. Slides for Invited Demo: http://www.cs.unb.ca/~boley/talks/PSOATransRun-talk.pdf

4. Al Manir, M.S., Riazanov, A., Boley, H., Baker, C.J.O.: PSOA RuleML API: A Tool for Processing Abstract and Concrete Syntaxes. In: Bikakis, A., Giurca, A. (eds.) RuleML 2012. LNCS, vol. 7438, pp. 280–288. Springer, Heidelberg (2012). Preprint: http://www.cs.unb.ca/~boley/papers/PSOA_RuleML_API.pdf. Slides: http://www.cs.unb.ca/~boley/talks/PSOA_RuleML_API-talk.pdf

5. Zou, G., Boley, H.: A Translator Framework for the Interoperation of Graph plus Relational Data and Rules on the Web. 5th Atlantic Workshop on Semantics and Services, February 2014, Slides: http://www.cs.unb.ca/~boley/talks/InteropGraphRel-AWoSS2014-talk.pdf

6. Boley, H.: A Music Album Knowledge Base in the Relational and Object-Centered Paradigms of the PSOA RuleML Language. RuleML Memo, 25 October 2014, http://www.cs.unb.ca/~boley/papers/MusicAlbumKB.txt

7. Boley, H.: PSOA RuleML: Integrated Object-Relational Data and Rules. In Wolfgang Faber and Adrian Paschke, editors, Reasoning Web. Web Logic Rules (RW2015) - 11th International Summer School 2015, Berlin, Germany, July 31-August 4, 2015, Tutorial Lectures, volume 9203 of Lecture Notes in Computer Science, pp. 114-150. Springer, 2015. SpringerLink: Abstract. Postprint: http://www.cs.unb.ca/~boley/papers/PSOAObjRelDataRules.pdf. Presented in the Computational Logic Seminar – MUGS, 27 May 2015, the SRI AIC Seminar Series, 9 June 2015, plus RW2015, 31 July - 4 August 2015. Slides for RW2015: http://www.cs.unb.ca/~boley/talks/PSOAObjRelDataRules-talk-RW2015.pdf. Slides with maximum details from paper: http://www.cs.unb.ca/~boley/talks/PSOAObjRelDataRules-talk.pdf. PSOARuleMLSQLSPARQL (pdf, docx) subset of slides for AWoSS 2015: http://www.cs.unb.ca/~boley/talks/PSOAObjRelDataRules-AWoSS2015-talk.pdf. Copy&paste-ready examples: PSOARuleMLInvitedTutorialExamplesRW2015

8. Zou, G., Boley, H.: PSOA2Prolog: Object-Relational Rule Interoperation and Implementation by Translation from PSOA RuleML to ISO Prolog. In Bassiliades, N. and Gottlob, G. and Sadri, F. and Paschke, A. and Roman, D. (eds.) RuleML 2015. LNCS, vol. 9202, pp. 176-192. Springer, 2015. SpringerLink: Abstract. Preprint: http://ruleml.org/papers/PSOA2Prolog.pdf and http://www.cs.unb.ca/~boley/papers/PSOA2Prolog.pdf. Slides: http://www.cs.unb.ca/~boley/talks/PSOA2Prolog-talk.pdf

9. Zou, G.: PSOA RuleML Integration of Relational and Object-Centered Geospatial Data, In Bassiliades, N., Fodor, P., Giurca, A., Gottlob, G., Kliegr, T., Nalepa, G. J., Palmirani, M., Paschke, A., Proctor, M., Roman, D., Sadri, F. and Stojanovic, N. (eds.) Joint Proceedings of the 9th International Rule Challenge, the Special Track on Rule-based Recommender Systems for the Web of Data, RuleML2015 Industry Track and the 5th RuleML Doctoral Consortium. Paper: http://ceur-ws.org/Vol-1417/paper14.pdf. Slides: http://ruleml.org/talks/GeoIntegrationPSOA-talk.pdf

10. Zou, G.: The PSOATransRun 1.0 System for Object-Relational Reasoning in RuleML. 6th Atlantic Workshop on Semantics and Services, December 2015, Abstract: http://ruleml.org/talks/AWoSS2015/PSOATransRun1.0-AWoSS2015.pdf, Slides: http://ruleml.org/talks/AWoSS2015/PSOATransRun1.0-AWoSS2015-talk.pdf.

11. Boley, H.: The RuleML Knowledge-Interoperation Hub. In volume 9718 of Lecture Notes in Computer Science, pp. 19-33. Springer, 2016. SpringerLink: Abstract. Preprint: http://ruleml.org/papers/RuleMLKnowleropHub.pdf and http://www.cs.unb.ca/~boley/papers/RuleMLKnowleropHub.pdf. Slides: http://ruleml.org/talks/RuleMLKnowleropHub-talk.pdf and http://www.cs.unb.ca/~boley/talks/RuleMLKnowleropHub-talk.pdf.

12. Zou, G., Boley, H.: Minimal Objectification and Maximal Unnesting in PSOA RuleML. In volume 9718 of Lecture Notes in Computer Science, pp. 130-147. Springer, 2016. SpringerLink: Abstract. Preprint: http://ruleml.org/papers/MinObjMaxUnnPSOARuleML.pdf and http://www.cs.unb.ca/~boley/papers/MinObjMaxUnnPSOARuleML.pdf. Slides: http://www.cs.unb.ca/~boley/talks/MinObjMaxUnnPSOARuleML-talk.pdf.

13. Gen Zou, Harold Boley, Dylan Wood, Kieran Lea: Port Clearance Rules in PSOA RuleML: From Controlled-English Regulation to Object-Relational Logic. In Nick Bassiliades, Antonis Bikakis, Stefania Costantini, Enrico Franconi, Adrian Giurca, Roman Kontchakov, Theodore Patkos, Fariba Sadri, William Van Woensel (eds.) Proceedings of the Doctoral Consortium, Challenge, Industry Track, Tutorials and Posters @ RuleML+RR 2017 hosted by International Joint Conference on Rules and Reasoning 2017 (RuleML+RR 2017), July 2017. Paper: http://ceur-ws.org/Vol-1875/paper6.pdf. Slides: http://ruleml.org/talks/PortClearanceRulesPSOARuleML-talk.pdf. KB: http://psoa.ruleml.org/usecases/PortClearance/PortClearance.psoa. Extended to tutorial for: OnTheMove Federated Conferences & Workshops (OTM 2017), Industry Case Studies Program (ICSP 2017), October 2017. Abstract: http://www.otmconferences.org/index.php/program/30-tutorials-2017/83-harold-boley. Slides: http://ruleml.org/talks/FactBasedModel4PortClearanceRulesPSOARuleML-talk.pdf (with link to above RuleML+RR slides as continuation).

14. Harold Boley, Gen Zou: Data in Perspective: The Rich TA Example as Grailog Visualization and PSOA RuleML Facts. Started: April 28, 2017. Reused: Ref. 15 (Fig. 1). Updated (membership uses an element-symbol arrow head for distinction from length-1 relationship): June 10, 2018, http://ruleml.org/talks/RichTAGlance.pdf.

15. Harold Boley, Gen Zou: Perspectival Knowledge in PSOA RuleML: Representation, Model Theory, and Translation. ArXiv e-prints arXiv:1712.02869 [cs.AI], [v1] 7 December 2017, [v2] 2 May 2018, [v3] 21 July 2019, http://arxiv.org/abs/1712.02869. Slides of earlier version presented in Standards Session, RuleML+RR 2017, July 12-15, 2017: http://ruleml.org/talks/PSOAPerspectivalKnowledge-talk.pdf. Copy&paste-ready examples: Rich TA Explorations in PSOA Perspectivity

16. Gen Zou, Harold Boley, Tara Athan: PSOATransRun Development Tutorial (Starting Open-Source Projects and PSOATransRun Development Agenda), 19 Dec 2017 - 17 Jan 2018, http://wiki.ruleml.org/index.php/PSOATransRun_Development_Tutorial.

17. Sofia Almpani: Medical Devices Rules. RuleML Technical Memo, February 2018, http://wiki.ruleml.org/index.php/Medical_Devices_Rules. PSOATransRun Development Telecon Presentation, 15 February 2018‎.

18. Gen Zou: Translators for Interoperating and Porting Object-Relational Knowledge. PhD Thesis, UNB Computer Science, 26 March 2018, https://unbscholar.lib.unb.ca/islandora/object/unbscholar%3A9279. RuleML Webinar, 27 April 2018, http://ruleml.org/talks/GenZou-TransInterPortObjRelKnowledge-RuleMLWebinar-2018-04-27.pdf.

19. Harold Boley: PSOA RuleML Meets Relational Databases. RuleML Technical Memo, May 2018, http://wiki.ruleml.org/index.php/PSOA_RuleML_Meets_Relational_Databases.

20. Harold Boley: PSOA RuleML Meets Graph Databases. RuleML Technical Memo, May 2018, http://wiki.ruleml.org/index.php/PSOA_RuleML_Meets_Graph_Databases.

21. Harold Boley: PSOA RuleML Bridges Graph and Relational Databases. RuleML Technical Memo, July 2018, http://wiki.ruleml.org/index.php/PSOA_RuleML_Bridges_Graph_and_Relational_Databases. ALP Newsletter, Feature Articles, July 6, 2018, https://www.cs.nmsu.edu/ALP/2018/07/psoa-ruleml-bridges-graph-and-relational-databases/.

22. Harold Boley: Data Systematics: The PSOA RuleML Metamodel Illustrated by Grailog Visualization of Wedding Atoms. Started: 13 July 2018, Updated: RULES: Logic and Applications (RulesLogApps 2019). Workshop, NTUA, Athens, Greece, 16-17 December 2019, http://ruleml.org/talks/PSOAMetamodelGrailogWedding.pdf.

23. Harold Boley, Alexander Kienzle, Scott Bateman: PSOAMetaViz Explained: The PSOA RuleML Metamodel in a GUI for Dynamic Visualization. Faculty of Computer Science, University of New Brunswick, Canada, 17 July 2018 (Revised: 12 October 2019), http://psoa.ruleml.org/metaviz/html/PSOAMetaVizExplained.html. Software: http://psoa.ruleml.org/metaviz/.

24. Sofia Almpani, Petros Stefaneas, Harold Boley, Theodoros Mitsikas, Panayiotis Frangos: Computational Regulation of Medical Devices in PSOA RuleML. In: Benzmüller C., Ricca F., Parent X., Roman D. (eds) Rules and Reasoning. RuleML+RR 2018. Lecture Notes in Computer Science, vol 11092. Springer, 2018. SpringerLink: Abstract. Preprint: http://ruleml.org/papers/CompRegMedDevPSOA.pdf. Slides: http://ruleml.org/talks/CompRegMedDevPSOA-talk.pdf.

25. Lukas Grätz, Harold Boley, Adrian Paschke: PSOA Prova: PSOA Translation of Pure Production Rules to the Prova Engine. In Wolfgang Faber, Paul Fodor, Giovanni De Gasperis, Adrian Giurca, Kia Teymourian (eds.) Proceedings of the Doctoral Consortium and Challenge @ RuleML+RR 2018 hosted by 2nd International Joint Conference on Rules and Reasoning (RuleML+RR 2018), September 2018. Paper: http://ceur-ws.org/Vol-2204/paper8.pdf. Slides: http://ruleml.org/talks/PSOAProvaPureProductionSlides.pdf.

26. Theodoros Mitsikas, Sofia Almpani, Petros Stefaneas, Panayiotis Frangos, Iakovos Ouranos: Formalizing Air Traffic Control Regulations in PSOA RuleML. In Wolfgang Faber, Paul Fodor, Giovanni De Gasperis, Adrian Giurca, Kia Teymourian (eds.) Proceedings of the Doctoral Consortium and Challenge @ RuleML+RR 2018 hosted by 2nd International Joint Conference on Rules and Reasoning (RuleML+RR 2018), September 2018. Rule Challenge best demo award (http://2018.ruleml-rr.org/challenge.html). Paper: http://ceur-ws.org/Vol-2204/paper9.pdf. Slides: https://easychair.org/smart-slide/slide/9f2P#. Code: http://users.ntua.gr/mitsikas/ATC_KB/.

27. Harold Boley: PSOA RuleML: Lightweight Ontologies with Multi-Membership for Perspectival Data and Rules. OMG Technical Meeting, Ontology Platform Special Interest Group (PSIG) Plenary Session, Ottawa, Canada, 27 September 2018, https://www.omg.org/events/ottawa-18/agendas/Ontology-PSIG.pdf. Slides: http://ruleml.org/talks/PSOALightweightOntologiesPerspectival.pdf (with links to other slides).

28. Sofia Almpani, Petros Stefaneas, Harold Boley, Theodoros Mitsikas and Panayiotis Frangos. Object-Relational Rules for Medical Devices: Classification and Conformity. In: Panetto H., Debruyne C., Proper H., Ardagna C., Roman D., Meersman R. (eds.) On the Move to Meaningful Internet Systems. OTM 2018 Conferences. OTM 2018. Lecture Notes in Computer Science, vol 11230. Springer.

29. Harold Boley: PSOA RuleML Explained with Blockchain Examples: Grailog Visualizations, Herbrand Models, and PSOATransRun Queries. RuleML Technical Report, December 2018, http://wiki.ruleml.org/index.php/PSOA_RuleML_Explained_with_Blockchain_Examples:_Grailog_Visualizations,_Herbrand_Models,_and_PSOATransRun_Queries. Abstract: RuleML Blog & Social Mediazine, http://blog.ruleml.org/post/psoa-ruleml-explained-with-blockchain-examples--155573753. Extended from: Learn PSOA RuleML: Object-Relational Data and Rules Illustrated by Blockchains; Bits & Bites series hosted by CS Square of the Faculty of Computer Science at UNB, 29 October 2018, https://www.unb.ca/fredericton/cs/cs-square/bits-bites.html. Keynote of Workshop on Rules: Logic and Applications, 19-20 December 2018, National Technical University of Athens (NTUA), http://fsvg.math.ntua.gr/rulesworkshop.html.

30. Harold Boley: Graph-Relational Data, Ontologies, and Rules. RuleML Technical Memo, February 2019, Updated: March 2019, http://wiki.ruleml.org/index.php/Graph-Relational_Data,_Ontologies,_and_Rules. Abstract: RuleML Blog & Social Mediazine, http://blog.ruleml.org/post/graph-relational-data-ontologies-and-rules-161477298.

31. Harold Boley: Rules and Reasoning for Graph Data. Introductory Talk, Rules and Reasoning Session, W3C Workshop on Web Standardization for Graph Data -- Creating Bridges: RDF, Property Graph and SQL, 4-6 March 2019, Berlin, Germany, http://ruleml.org/talks/RulesAndReasoningForGraphData.pdf.

32. Harold Boley: Exploring the PSOA RuleML Space of Core Atoms. RuleML Technical Memo, April 2019, http://wiki.ruleml.org/index.php/Exploring_the_PSOA_RuleML_Space_of_Core_Atoms.

33. Sofia Almpani, Petros Stefaneas, Harold Boley, Theodoros Mitsikas and Panayiotis Frangos: A Rule-Based Model for Compliance of Medical Devices Applied to the European Market. International Journal of Extreme Automation and Connectivity in Healthcare (IJEACH) 1(2), 2019, doi:10.4018/IJEACH.2019070104. IGI Global: Abstract.

34. Marjolein Deryck, Theodoros Mitsikas, Sofia Almpani, Petros Stefaneas, Panayiotis Frangos, Iakovos Ouranos, Harold Boley, and Joost Vennekens: Aligning, Interoperating, and Co-executing Air Traffic Control Rules Across PSOA RuleML and IDP. In: Fodor P., Montali M., Calvanese D., Roman D. (eds) Rules and Reasoning. RuleML+RR 2019. Lecture Notes in Computer Science, vol 11784. Springer, 2019. SpringerLink: Abstract. Preprint: http://ruleml.org/papers/PSOA_IDP_Interoperation_ATC.pdf. Slides: http://ruleml.org/talks/PSOA_IDP_Interoperation_ATC-talk.pdf.

35. Tara Athan, Harold Boley, Rima Chaudhari: Specifying PSOA RuleML/XML 1.03: MYNG-modularized Schemas for the RNC & XSD Validation of XSLT-normalized Data and Knowledge. Proceedings of the 13th RuleML+RR 2019 Doctoral Consortium and Rule Challenge, September 16-19, 2019, Bolzano, Italy. Paper: http://ruleml.org/papers/SpecPSOARuleMLXML103.pdf and http://ceur-ws.org/Vol-2438/paper7.pdf. Slides: http://ruleml.org/talks/SpecPSOARuleMLXML103-talk.pdf.

36. Harold Boley, Gen Zou, Theodoros Mitsikas: Graph-Relational PSOATransRun Reasoners at RuleML.com/.org. Joint poster session of BRAIN 2019, collocating RuleML+RR 2019, DecisionCAMP 2019, and GCAI 2019. http://ruleml.org/posters/GraphRelPSOATransRunReasonersRuleMLComOrg.pdf.

37. Theodoros Mitsikas: A Hands-on PSOA RuleML Tutorial: Relationship & Framepoint Facts and Rules. RULES: Logic and Applications (RulesLogApps 2019). Workshop, NTUA, Athens, Greece, 16-17 December 2019. Slides: http://fsvg.math.ntua.gr/RulesLogApps/2019/TheodorosMitsikas-PSOARuleMLTutorial.pdf.

38. Sofia Almpani: ExosCE: A Legal Framework System for Exoskeleton Compliance. RULES: Logic and Applications (RulesLogApps 2019). Workshop, NTUA, Athens, Greece, 16-17 December 2019. Slides: http://fsvg.math.ntua.gr/RulesLogApps/2019/SofiaAlmpani-ExoskeletonsRules.pdf.

39. Harold Boley: XML in JSON Revisited. RuleML Technical Memo, April 2020, http://wiki.ruleml.org/index.php/XML_in_JSON_Revisited.

40. Harold Boley: RuleML Controlled Language. RuleML Technical Memo, June 2020, Updated: August 2020, http://wiki.ruleml.org/index.php/RuleML_Controlled_Language.

41. Mark Thom, Harold Boley, Theodoros Mitsikas: Invertible Bidirectional Metalogical Translation Between Prolog and RuleML for Knowledge Representation and Querying. In: Gutiérrez Basulto V., Kliegr T., Soylu A., Giese M., Roman D. (eds) Rules and Reasoning. RuleML+RR 2020. SpringerLink: Abstract. Preprint: http://ruleml.org/papers/RuleMLXMLBiDirTransScryer.pdf.

42. Sofia Almpani, Theodoros Mitsikas, Petros Stefaneas, & Panayiotis Frangos (2020). ExosCE: A legal-based computational system for compliance with exoskeletons’ CE marking, Paladyn, Journal of Behavioral Robotics, 11(1), 414-427. doi: https://doi.org/10.1515/pjbr-2020-0026


Please send your PSOA entries to webmaster {A T} ruleml.org as they appear, so they can be listed here.