PSOA RuleML

From RuleML Wiki
Jump to: navigation, search

Authors: Gen Zou, Harold Boley


Positional-Slotted Object-Applicative 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 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 1.0 permits an atom to be [in an orthogonal perspectivity dimension 3] perspeneutral (having only predicate-independent descriptors), perspectival (having only predicate-dependent descriptors), or perspeneutral+perspectival. The resulting positional-slotted object-applicative (psoa) atoms can be used as (oidless, tupled, perspectival) relationship facts without an OID and with a dependent (ordered) sequence of arguments, as (oidful, slotted, perspeneutral) frame facts with an OID and with an (unordered) multiset of independent slots, as well as in various other ways. For illustrating this systematics, the first section will present variations of a preview example regarding a business fact and rule. Also, the slide Data in Perspective: The Rich TA Example as Grailog Visualization and PSOA RuleML Facts focuses on the perspectivity dimension.

Such psoa facts and rules over them 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 2) the well-known efficient XSB Prolog engine. See the Examples section for PSOATransRun-executable examples of PSOA RuleML knowledge bases, queries, and answers.

Contents

1 Presentation Preview

We will develop a relationship and a frame version of a business rule (about liability) on top of corresponding versions of a business fact (about a purchase).

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)

This is a fully 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):

_purchase(_John _Mary _Fido)

This is a partially abridged version of the following unabridged form, where the "+"-prefixed square-bracket construct +[...] moreover 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 'implicit 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.

For this reason, the _purchase predicate can be alternatively represented as a pairship atom, using slot names ('explicit 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 all of its slot-permuted ones, including:

_purchase(_seller+>_Mary _buyer+>_John _item+>_Fido)

Changing the slots to predicate-independent and adding an Object IDentifier (OID), _transaction200, the representation becomes a frame atom (the hash infix, "#", types an OID with its predicate, i.e. indicates membership; the arrow infix, "->", pairs a predicate-independent slot name with its filler):

_transaction200#_purchase(_buyer->_John _seller->_Mary _item->_Fido)

Rather than making the ordered _purchase relationship slotted (obtaining a pairship) and then changing the slots to predicate-independent and adding an OID (obtaining a frame), the relationship can be kept ordered, its tuple changed to predicate-independent and an OID be added, arriving at a shelf 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 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 predicate-dependent tuple, the predicate will act as a class after objectification.
  • In the above frame, with an OID but no predicate-dependent tuple, the predicate acts as a class (of the OID).
  • In the above shelf, which can be seen as an independent-slots-to-independent-tuple-transformed frame, with an OID but no predicate-dependent tuple, 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.

PSOA RuleML permits to create rules over such 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 the above _purchase relationship 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, the above _purchase frame can be used as the condition of a ground rule whose _liability-frame conclusion adds another OID, _registration800, and slot names, _citizen and _item (again allowing the two slots to appear in any order):

_registration800#_liability(_citizen->_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 ?c, _Mary to ?s, and _Fido to ?i (the question-mark prefix, "?", indicates variables):

Forall ?c ?s ?i (
 _liability(?c ?i) :-
   _purchase(?c ?s ?i)
)

Likewise, a corresponding non-ground frame:-frame rule can additionally abstract the OID constant _transaction200 to the OID variable ?t and replace the OID constant _registration800 with the OID-(constructor-)function application _liabilityID(?t) (indicating OID determination by ?t):

Forall ?c ?s ?i ?t (
 _liabilityID(?t)#_liability(_citizen->?c _item->?i) :-
   ?t#_purchase(_buyer->?c _seller->?s _item->?i)
)

For refined versions of these _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 frames having a globally unique 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 frame atoms (e.g., SPARQL/SPIN and N3 rules). In PSOA RuleML, rules may also blend both relationship atoms and frame 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 blending the paradigms of relationships (oidless, tupled, perspectival) and frames (oidful, slotted, perspeneutral), the orthogonal dimensions characterizing PSOA RuleML atoms also allow for the complementary pairship atoms (oidless, slotted, perspectival), shelf atoms (oidful, tupled, perspeneutral), as well as oidless/oidful atoms having both tupled and slotted arguments, as summarized in the perspeneutral and perspectival "psoa tables" using, with 1≤I≤6, systematic names pnI for perspeneutral cells and pvI for perspectival cells as well as common names for -- possibly further constrained -- cells such as "shelves" (thus simplifying the metamodel of Ref. 15 by omitting the perspeneutral+perspectival table and the dimension numbers, as well as using "single-tuple" for the constraint m=1):

perspeneutral oidless oidful
tupled pn1. pn2. single-tuple: shelves
slotted pn3. pn4. frames
tupled+slotted pn5. pn6. single-tuple: shelframes
perspectival oidless oidful
tupled pv1. single-tuple: relationships pv2.
slotted pv3. pairships pv4.
tupled+slotted pv5. single-tuple: relpairships pv6.

Further simplifying the above metamodel by omitting the tupled+slotted rows, we arrive at a core of 8 kinds of atoms exemplified in PSOAMetamodelGrailogWedding.pdf, in the context of the full, 18-atom, PSOA metamodel cube, and used for interoperation in PSOA RuleML Bridges Graph and Relational Databases. The PSOA metamodel cube is dynamically visualized in PSOAMetaViz (cf. Ref. 23).

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

The oidful atoms in the second columns of the psoa tables describe an OID, often visualized as a node in a graph, with

  • slots (first table, second row: frames), visualized as directed labeled arcs, each having a name/label and leading to a filler/node,
  • tuples (first table, first row: shelves), visualized as directed unlabeled hyperarcs, each connecting a sequence of nodes,
  • or a combination of both (first table, third row: shelframes).

(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 frames is directed labeled graphs (DLGs) while the graph formalism underlying shelves 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 shelves (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 frames (DLGs as in the PSOA tutorial, slide 31), which can be regarded as length-2 shelves (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 can thus have the following right-slot normal form (for the most general form see Ref. 15):

   o#f(+[t1,1 ... t1,n1] . . . +[tm,1 ... tm,nm] p1->v1 . . . pk->vk)

Here, o is the object identifier (OID) described by three kinds of information: (1) The membership o # f makes o an instance of predicate f; (2) each dependent tupled argument +[ti,1 ... ti,ni] represents a sequence of terms associated with o; (3) each independent slotted argument pi -> vi represents a pair of an attribute pi and its value vi associated with o.

An atomic formula having the form of a psoa term is called a psoa atom. 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 using constructs from the Horn-like subset of first-order logic: conjunction, disjunction in negative positions, as well as existential and universal quantifiers in certain positions. 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 inferential 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 two award-winning Refs. 1. and 3. as well as the invited tutorial Ref. 7., the challenge Ref. 13. (also presented as part of an invited tutorial), and the arXiv-maintained Ref. 15.

There are various connections between PSOA RuleML and Relational Databases. Since PSOA RuleML allows for both object-centered 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, perspeneutral/perspectival atoms of the PSOA metamodel cube (from Ref. 1, Appendix A) are systematically visualized in Grailog: 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 syntax and semantics are further revised for the perspectivity dimension in Ref. 15. The following subsections are set up to elaborate the specification.

3.1 Syntax

The PSOA RuleML presentation syntax modifies and extends the one of RIF-BLD. The PSOA RuleML/XML serialization syntax extends the one of Hornlog RuleML/XML. For illustrating the XML representation, the first subsection will serialize variations of the preview example.

For (multi-)tupled and/or (multi-)slotted psoa terms having only dependent tuples and/or independent slots, (multiple occurrences of) <tupdep><Tuple> edge-node element pairs and/or (multiple) <slot> edge elements are allowed (for the most general psoa terms see Ref. 15). Such a psoa term used as an atomic formula has the following pure PSOA right-slot normal form. Here, the primed meta-variables t'i,j etc. indicate recursive XML serializations of their above presentation-syntax versions (the style attribute uses the value "http://ruleml.org/1.03/profiles/HornPSOA-Tarski" to specify PSOA semantics with built-in 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> . . . <Tuple>t'm,1 ... t'm,nm</Tuple></tupdep>
     <slot>p'1 v'1</slot> . . . <slot>p'k v'k</slot>
   </Atom>

For an extended PSOA version see the RW 2015 tutorial on PSOA RuleML (Ref. 7, Section 6), where the right-slot normal form is replaced with a left-slot normal form.

A complete XML Schema for PSOA RuleML, the PSOA RuleML API, and their use for generating PSOA RuleML presentation syntax from the PSOA RuleML/XML serialization are described in PSOA RuleML API.

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

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

3.1.1 Serialization Preview

In PSOA RuleML's serialization syntax, the presentation-syntax examples from the Presentation Preview can be represented as follows.

Implicit-dependent-Tuple relationship fact:

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

Frame fact 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 ground relationship rule in (fully striped) normal form:

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

Ground frame rule in (fully striped) normal form:

<Implies>
  <then>    <!-- _registration800#_liability(_citizen->_John _item->_Fido) -->
    <Atom>
      <oid><Ind>registration800</Ind></oid>
      <op><Rel>liability</Rel></op>
      <slot><Ind>citizen</Ind><Ind>John</Ind></slot>
      <slot><Ind>item</Ind><Ind>Fido</Ind></slot>
    </Atom>
  </then>
  <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>     
</Implies>

Implicit-dependent-Tuple non-ground relationship rule in (fully striped) normal form:

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

Non-ground frame rule in (fully striped) normal form:

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

3.1.2 Monolithic Syntax

Like in RIF-BLD, 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.2.1 Monolithic EBNF for PSOA RuleML Presentation Syntax

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 ')'
ATOMIC ::= Atom | Equal | Subclass
Atom ::= ATOMOIDLESS | ATOMOIDFUL  % Atoms can be oidless or oidful
ATOMOIDLESS ::= PSOAOIDLESS        % Oidless atoms are oidless psoa terms
ATOMOIDFUL ::= PSOAOIDFUL          % Oidful atoms are oidful psoa terms
Equal ::= TERM '=' TERM
Subclass ::= TERM '##' TERM  % Subclass is pars pro toto for Subpredicate
PSOA ::= PSOAOIDLESS | PSOAOIDFUL       % Extra start symbol: psoa terms
PSOAOIDLESS ::= TERM '(' (TERM+ | TUPLEDI*) SLOTDI* ')'  % Right-slot normal form
PSOAOIDFUL ::= TERM '#' PSOAOIDLESS
TUPLEDI ::= ('+' | '-') '[' TERM* ']'
SLOTDI ::= TERM ('+>' | '->') TERM
TERM ::= Const | Var | ATOMOIDFUL | Expr | 'External' '(' Expr ')'
Expr ::= PSOAOIDLESS               % Exprs are oidless psoa terms
Const ::= '"' UNICODESTRING '"^^' SYMSPACE | CONSTSHORT
Var ::= '?' PN_LOCAL?
SYMSPACE ::= ANGLEBRACKIRI | CURIE
CONSTSHORT ::= ANGLEBRACKIRI | CURIE | '"' UNICODESTRING '"'
                                         | NumericLiteral | '_' PN_LOCAL?

The grammar's PSOAOIDLESS production specifies the right-slot normal form through the order of the two kinds of (parenthesized) descriptors: First, there either is an implicit dependent tuple, TERM+, or there are explicit Tuples, TUPLEDI*, each dependent (D) or independent (I). Second, there are explicit slots, SLOTDI*, each D or I.

The grammar can be strengthened to the right-slot, right-independent normal form by a modified PSOAOIDLESS 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:

PSOAOIDLESS ::= TERM '(' (TERM+ | TUPLESDEIN) SLOTSDEIN ')'  % Right-slot, right-independent normal form
. . .
TUPLESDEIN ::= ('+' '[' TERM* ']')* ('-' '[' TERM* ']')*
SLOTSDEIN ::= (TERM '+>' TERM)* (TERM '->' TERM)*

This grammar can then be preprocessed for the Relax NG schema modularization, where TERMSORTUPLESDEIN (TERMS OR TUPLESDEIN) may be just TERMS (TERM+), abbreviating a single dependent (non-empty) tuple containing those terms in sequence:

PSOAOIDLESS ::= TERM '(' TERMSORTUPLESDEIN SLOTSDEIN ')'  % Right-slot, right-independent normal form
. . .
TERMSORTUPLESDEIN ::= (TERM+ | (('+' '[' TERM* ']')* ('-' '[' TERM* ']')*))
SLOTSDEIN ::= (TERM '+>' TERM)* (TERM '->' TERM)*
3.1.2.2 From PSOA RuleML Presentation Syntax to Serialization Syntax

For the right-slot, right-independent normal form of the core (dependent and independent) descriptor-defining EBNF-grammar productions of the above 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 strengthened 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

Condition Language Descriptors in preprocessed form (Presentation to Serialization):

P:  TERMSORTUPLESDEIN ::= (TERM+ | (('+' '[' TERM* ']')* ('-' '[' TERM* ']')*))
X:  TERMSORTUPLESDEIN ::= (TERM+ | (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.2.3 Monolithic RNC for PSOA RuleML Serialization Syntax

This preliminary Relax NG schema has been developed in RNC from a further simplified version (e.g., omitting all XML attributes) of the simplified monolithic RNC for Deliberation RuleML.

Rule Language:

start =
  RuleML
# | ...
  | Atom
# | ...
  | Implies
# | ...
RuleML =                   # Document
  element RuleML {
    act*
  }
act =
  element act {
    (Assert
#    | ...
    )
  }
Assert =
  element Assert {
    formula*
  }
formula =
  element formula {
#     ...  Full version has "& (..." instead of "," NEWLINE "(..."
      (Atom
       | Uniterm
       | Equal
#      | ...
       | Implies
#      | ...
       | Forall
       | Exists
#      | ...
       | Rulebase)
  }
# Base = ...
# Prefix = ...
# Import = ...
Rulebase =                 # Group
  element Rulebase {
    formula_7*
  }
formula_7 =                # Only (omitted) attributes differ across formula_i
  element formula {
#     ...  Full version has "& (..." instead of "," NEWLINE "(..."
      (Atom
       | Uniterm
       | Equal
#      | ...
       | Implies
#      | ...
       | Forall
       | Exists)
  }
Implies =
  element Implies {
    if,
    then
  }
Forall =
  element Forall {
    declare+,
    formula_5
  }
formula_5 =                # Only (omitted) attributes differ across formula_i
  element formula {
#     ...  Full version has "& (..." instead of "," NEWLINE "(..."
      (Atom
       | Uniterm
       | Equal
#      | ...
       | Implies
#      | ...
       | Forall
       | Exists)
  }
Exists =
  element Exists {
    declare+,
    formula_6
  }
formula_6 =                # Only (omitted) attributes differ across formula_i
  element formula {
#     ...  Full version has "& (..." instead of "," NEWLINE "(..."
      (Atom
       | Uniterm
       | Equal
#      | ...
       | Implies
#      | ...
       | Forall
       | Exists)
  }

Condition Language:

And =
  element And {
    formula_3*
  }
formula_3 =                # Only (omitted) attributes differ across formula_i
  element formula {
#     ...  Full version has "& (..." instead of "," NEWLINE "(..."
      (Atom
       | Uniterm
       | Equal
#      | ...
       | Implies
#      | ...
       | Forall
       | Exists)
  }
Atom =
  element Atom {
    oid?,
#   ...
    op,
    ((arg+, repo?) | TUPLESDEIN),  # Added TUPLESDEIN for PSOA RuleML's multi-<Tuple> psoa atoms, with  EITHER...
    SLOTSDEIN,                     # ...arg+, repo?: 1 implicit dependent tuple having >= 1 args and optional repo...OR...
    resl?                          # ...TUPLESDEIN:  >= 0 explicit dependent followed by independent <Tuple>s each containing >= 0 args and optional repo
  }
Uniterm =
  element Uniterm {
    oid?,
#   ...
    op,
    ((arg+, repo?) | TUPLESDEIN),
    repo?,
    SLOTSDEIN,
    resl?
  }
Equal =
  element Equal {
    left,
    right
  }
left =
  element left {
#     ...  Full version has "& (..." instead of "," NEWLINE "(..."
      (# ...
         Const
       | Ind
       | Data
       | Var
       | Expr
       | Uniterm_2
       | Plex)
  }
right =
  element right {
#     ...  Full version has "& (..." instead of "," NEWLINE "(..."
      (# ...
         Const
       | Ind
       | Data
       | Var
       | Expr
       | Uniterm_2
       | Plex)
  }
Uniterm_2 =
  element Uniterm {
    oid?,
    op_2,
    ((arg+, repo?) | TUPLESDEIN),
    repo?,
    SLOTSDEIN,
    resl?
  }
Tuple =                        # Tuple added for PSOA RuleML's multi-tuple psoa terms
  element Tuple {
    arg*,                      # Normal form (fully striped Tuple) contains <arg> edges
    repo?                      # RW 2015 tutorial on PSOA RuleML also allows <repo> edge
  }
op =
  element op {
    & (Rel
#      | ...
       | Var
       | Expr
       | Uniterm_2
       | Plex)
  }
Rel =
  element Rel {
    xsd:token
  }
Var =
  element Var {
    xsd:token
  }
Expr =
  element Expr {
    op_2,
    ((arg+, repo?) | tupdep),  # Added tupdep for PSOA RuleML's single-dependent-<Tuple> psoa exprs, with  EITHER...
    SLOTSDEIN,                 # ...arg+, repo?: 1 implicit dependent tuple having >= 1 args and optional repo ...OR...
    resl?                      # ...tupdep:      1 explicit dependent <Tuple> containing >= 0 args and optional repo
  }
op_2 =
  element op {
    & (Fun
#      | ...
       | Var
       | Expr
       | Uniterm_2
       | Plex)
  }
Fun =
  element Fun {
    xsd:token
  }
repo =
  element repo {
    & (Var | Plex_3)
  }
Plex_3 =
  element Plex {
    arg*,
    repo?
  }
resl =
  element resl {
    & (Var | Plex_2)
  }
Plex_2 =
  element Plex {
    slot*,
    resl?
  }
oid =
  element oid {
#     ...  Full version has "& (..." instead of "," NEWLINE "(..."
      (# ...
         Const   # EBNF has
       | Ind     # only one
       | Data
       | Var
       | Expr
       | Uniterm_2
       | Plex)
  }
arg =
  element arg {
#   ...  Full version has "& (..." instead of "," NEWLINE "(..."
    (# ...
       Const   # EBNF has
     | Ind     # only one
     | Data
     | Var
     | Expr
     | Atom  # Generalizes both Deliberation RuleML/XML (not allowing any embedded atoms) and PSOA RuleML/PS (unnesting all oidful terms, interpreted as atoms): This generality (enabled by explicit <Atom> serialization) avoids sth like Atom_oidful patterns in Relax NG and can be exploited for a semantic profile allowing "embedded objectification"
     | Uniterm_2
     | Plex)
  }

TUPLESDEIN = tupdep*, tup*                            # Different edges
tupdep = element tupdep { Tuple }                     # lead into same
tup    = element tup { Tuple }                        # Tuple Node

SLOTSDEIN = slotdep*, slot*                           # Different edges
slotdep = element slotdep { slot-name, slot-filler }  # lead into same
slot    = element slot    { slot-name, slot-filler }  # pair of name/filler Nodes

#   ...  Full version has "& (..." instead of "," NEWLINE "(..."
slot-name =
    (Const | Ind | Data | Expr | Uniterm_2 | Plex)
slot-filler =
    (# ...
       Const   # EBNF has
     | Ind     # only one
     | Data
     | Var
     | Expr
     | Uniterm_2
     | Plex)

3.1.3 Modular Syntax

The modular RNC for the PSOA RuleML serialization syntax corresponding to the monolithic RNC above has been developed from the modular RNC for Deliberation RuleML 1.03. A development release is available at RNC for PSOA Deliberation RuleML 1.03.

Three PSOA anchor languages are defined as enrichments of corresponding pre-PSOA anchor languages (datalog_normal, hornlog_normal, and naffologeq_normal).

The enrichments 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 enrichments consist of complementing pre-PSOA independent slots with dependent slots, and complementing a single pre-PSOA implicit (dependent) tuple of arguments with multiple explicit (dependent and independent) Tuples of arguments.

Some sample instances may be found here:

The schemas in Relax NG (and XSD) are available here:

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

3.2 Semantics

The original specification of the PSOA RuleML 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/dependent-tuple, in/dependent-slot psoa terms) in Ref. 15, Section 5.

4 Implementation

4.1 PSOATransRun

In order to support reasoning in PSOA RuleML, we have implemented the PSOATransRun system, which 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. Two PSOATransRun[PSOA2i,r] instantiations are available: the initial PSOATransRun[PSOA2TPTP,VampirePrime], for online use, and the current PSOATransRun[PSOA2Prolog,XSBProlog], for local use.

Current Release (downloadable executable): http://psoa.ruleml.org/transrun/1.3.2/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.

Semantic Web Techniques Course Project (Fall 2011) Version: http://scaryponens.github.io/PSOA-to-TPTP/build/html/index.html

Workflow of using PSOATransRun (sample KBs & queries can be obtained from the Test Case section):

1) load the PSOATransRun page;

2) enter a KB into the rulebase textbox (ignore this step if you use the sample KB provided by the system);

3) click "Translate Rulebase" (takes you to the "TPTP Rulebase" pane and the translated KB in the TPTP format is shown);

4) enter a query into the query textbox (for example, _k1#_kid(_Sue _Pete));

5) click "Translate Query" (leaves you on the "TPTP Rulebase" pane, and the translated query in the TPTP format is appended to the end of the translated KB);

6) click "Execute" (takes you to the "VampirePrime Reasoner" pane and the result is shown. If the query is successful, the proof procedure for each answer will be shown in the TPTP format).

4.1.1.1 PSOA2TPTP

PSOA2TPTP is our reference translator mapping knowledge bases and queries in the PSOA RuleML presentation syntax to TPTP. 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.2 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.3 Implemented feature list and restrictions
  • Terms
    • Constants
      • Local constants: constant names that has only digits with a prefix '_', such as _1, _21, 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 are supported
  • Formulas
    • Conjunction
    • Existential quantification
    • Universal quantification

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.

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/


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 do a syntactic transformation from PSOA RuleML to Prolog.

4.1.2.2 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.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.
atMost 
math:atMost(num1 num2) yields true iff num1 is numerically less then or equal to num2.
atLeast 
math:atLeast(num1 num2) yields true iff num1 is numerically greater or equal to num2.
  • 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).

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(_citizen->_John _item->_Fido) :-
      _transaction200#_purchase2(_buyer->_John _seller->_Mary _item->_Fido)
  )
)
  • Queries
   _liability1(?c ?i)                   %  ?c=_John ?i=_Fido
?o#_liability1(?c ?i)                   %  Extra binding: ?o=_oidcons(_liability1 _John _Fido)  (Implementation-specific fresh name)
   _liability2(_citizen->?c _item->?i)  %  ?c=_John ?i=_Fido
?o#_liability2(_citizen->?c _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 ?c ?s ?i (
      _liability1(?c ?i) :-
        _purchase1(?c ?s ?i)
    )
    Forall ?c ?s ?i ?t (
      _liability2ID(?t)#_liability2(_citizen->?c _item->?i) :-
        ?t#_purchase2(_buyer->?c _seller->?s _item->?i)
    )
  )
)
  • Queries
   _liability1(?c ?i)                   %  ?c=_John ?i=_Fido
?o#_liability1(?c ?i)                   %  Extra binding: ?o=_oidcons(_liability1 _John _Fido)  (Implementation-specific fresh name)
   _liability2(_citizen->?c _item->?i)  %  ?c=_John ?i=_Fido
?o#_liability2(_citizen->?c _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).

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

8 Acronym

"PSOA" is an acronym for "Positional-Slotted Object-Applicative", typically employed as part of "PSOA RuleML", where "RuleML" can often be understood from the context. We use the all-upper-case "PSOA" as a reference to the language and the all-lower-case "psoa" for its terms.

9 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://www.cs.unb.ca/~boley/papers/RuleMLKnowleropHub.pdf. Slides: 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, 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.

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, PSOATransRun Development Telecon Presentation, 15 February 2018‎, http://wiki.ruleml.org/index.php/Medical_Devices_Rules.

18. Gen Zou: Translators for Interoperating and Porting Object-Relational Knowledge. PhD Thesis, UNB Computer Science, April 2018, https://unbscholar.lib.unb.ca/islandora/object/unbscholar%3A9279.

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: 5 June 2018, Updated: 13 July 2018, 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, 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. RuleML+RR 2018: 2nd International Joint Conference on Rules and Reasoning, September 2018. Preprint: http://ruleml.org/papers/CompRegMedDevPSOA.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.

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, Panayiotis Frangos: Object-Relational Rules for Medical Devices: Classification and Conformity. ODBASE 2018, October 2018.

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