PSOATransRun Development Agenda

From RuleML Wiki
Jump to: navigation, search

This agenda complements the projects in PSOATransRun Development Tutorial, particularly Projects 1 and 4, as well as material in PSOA RuleML#Implementation. Most agenda items require knowledge of Java, several of ANTLR, some of Python. While some items are labeled to still be in the DESIGN phase, the other ones are understood to be ready for implementation. If you want to contribute to the open development of one of the below agenda items or to a new one, please contact Harold Boley.

Executable (with README):


1 Documentation

1.1 PSOATransRunComponents README

(Cf. and

Create quick setup hints.

Mention used version of ANTLR as the Java-integrated parser generator etc. (cf. #Technology-Stack_Maintenance).

1.2 Best Practices Page

  1. When editing a PSOA RuleML file:
    1. Use a pretty-print format, where, e.g., each clause is indented by the same amount of whitespace (maybe none)
    2. Put clauses (rules and facts) with free variables into Forall ... (. . .) wrappers
  2. Referring to #Unit_Tests, within new batch testing directories <testDir> such as testsynsem (for java -jar target\PSOATransRunLocal.jar --test -i <testDir>), in files of the form *-answerJ.psoa (do not use test's yes/no but) use Capitalized Yes/No (as displayed in the interaction loop)

2 Graph Orientation

Survey existing Knowledge Graph (KG)/Graph Database systems and compare them to PSOATransRun across numerous dimensions, such as efficiency and expressivity. Candidates for comparison could include:

The intended culmination of the survey is an adaptation of one of the systems as a PSOATransRun backend.

A possible point of comparison between PSOATransRun and existing graph databases is the performance of their SHACL implementations. Part of meeting this potential item is providing PSOATransRun with a working, robust SHACL implementation, which it currently does not have. SHACL, or Shape Constraint Language, is a formalism for describing conditions on graph databases as an RDF graph. Implementations of SHACL check SHACL-specified constraints/conditions against input graphs. AllegroGraph, GraphDB, Stardog, Apache Jena, and RDF4J all "have" SHACL implementations in varying senses (see Project evaluation draft for "Benchmark for Performance Evaluation of SHACL Implementations in Graph Databases").

A free book: Graph Databases.

3 Schemaless Checking

Realize (context-free, -sensitive, and semantic) schemaless checking [also in connection with schemaful validation (cf. #Signature_Level -- incl. of the XML serialization (cf. PSOA_RuleML#Specification)], e.g. for the presence and declaration/use match of Forall ... (. . .) wrappers (cf. #Best_Practices_Page):

  • When a Forall wrapper around a clause is present:
    • There must be a check whether the Forall declares all free variables of the clause, here those variables not in an embedded Exists wrapper (cf. PSOA RuleML#Family_1, Objectified source)
      • If a variable is declared in an embedded Exists, then it should not be included in the Forall and no Warning/Error should be printed/yielded when it's missing from the Forall
    • Print/yield (summary) Warning/Error for undeclared variables
    • [There can be declared variables not occurring in the clause]
  • Command-line option, "-f"/"--fAllWrap" (ForAll Wrapping), for requiring Forall wrappings to declare all free variables:
    • Without "-f"/"--fAllWrap" (default): Print Warning for undeclared variables
    • With "-f"/"--fAllWrap": Yield Error for undeclared variables

4 Signature Level

[DESIGN] Built on the metamodel (PSOA RuleML#Introduction), the signatures of predicates and functions should become optionally declared, which will allow more precise semantic top-down modeling but can also often be found automatically bottom-up (e.g. via "polymorphic type inference", ILP/IFP, and, generally, machine learning).

Declarations could be blended into the main KB ('homogeneous' KBs) or be concentrated on a newly introduced optional signature -- schema/TBox/... -- level ('heterogeneous' KBs). For the special case of sort declarations, there were proposals for 'heterogeneous' KBs in earlier versions of Common Logic and W3C RIF, but 'homogeneous' KBs were adopted in later versions. PSOA, like RIF, could keep member (#) and subclass (##) in the main KB (cf. #Taxonomy_Querying), but -- as assumed below -- add larger-scale signature features heterogeneously in a separate signature level: it makes sense to check the KB level against some separate level.

Aware of the multitude of approaches, the focus is on PSOA-specific signatures. In particular, PSOATransRun, before normalizing a KB, can load the KB's possible signatures, and check the KB's compliance to the signatures.

4.1 Related Work

4.1.1 Schema Languages

  • For schemaless checking, without a separate language, see #Schemaless_Checking
  • Syntactic (context-free and -sensitive) and semantic validation
  • Schema (RNC, XSD) -- incl. shape (e.g., SHACL rules) -- languages for documents, DBs, and KBs.

4.1.2 Modeling Languages UML, UML2, OCL, ...

4.1.3 Integrity Constraints/Rules

4.1.4 Rule-Ontology Combination

4.1.5 F-logic/Flora2 Signatures

4.1.6 RIF-FLD Signatures

4.1.7 Visual Prolog Signatures

4.1.8 POSL Signatures

Proposed in Integrating Positional and Slotted Knowledge on the Semantic Web, Section IV.

4.1.9 Signatures in Functional Languages

Standard ML,, ..., Shen.

4.2 Characterizations of the Signature Level

4.2.1 Decidability vs. Computational Completeness

The signature(-compliance) checker should be special-purpose and decidable, moreover have tractable complexity.

4.2.2 Scope and Refinement from KBs to KB Modules to KB Clauses

The scope of signature declarations could become increasingly granular from KBs to KB modules (cf. Import statement) to KB clauses, and the signature strengths could be hierarchically refined along the way.

4.2.3 Static vs. Dynamic Use

An earlier version of the signature checker could be statically applied to a KB. A later version could be dynamically applied to a KB and queries, e.g. for each query checking the compliance of its predicate arguments with those in the KB's clause heads.

4.3 [DESIGN] PSOA Signature Declarations

4.3.1 (Max) Number of Tuples and their Arities

4.3.2 (Max) Number of Slots and their Names

4.3.3 (Predicate) Dependencies of Tuples and Slots

4.3.4 Types of Tuple Elements and Slot Fillers

Can built-in types, e.g. based on unary ISO Prolog predicates (PSOA RuleML#Built-ins), and user-defined types, e.g. introduced via subclass (##), be specified in a uniform manner?

4.3.5 (Max) Number of Predicates (Multi-Membership) for an OID

4.3.6 Predicate vs. Function Names (Built-In/User-Defined)

In addition to the names' "#" vs. "^" occurrences?

4.3.7 [FUTURE] Modes (In/Out/Mixed) of Tuple Elements and Slot Fillers

4.3.8 [FUTURE] Determinism of Definitions

5 Functional Programming

5.1 Refine Functional Expressions

  • As usual, n-ary lists (RuleML/XML: slotless plexes, PSOA RuleML: single-tuple plex psoa expressions) can be realized as ('passive') binary cons (Relfun: cns) expressions, which ultimately could be given an n-ary surface syntax plex(e1 ... eN), i.e. plex(+[e1 ... eN]), also allowing rest parameters (RuleML/XML: repo, Prolog and Relfun: "|") as detailed for corresponding atoms in #Introduce_Tuple_Rests
  • [DESIGN] Flattening of (optionally: 'passive'; always: 'active') expressions could be modeled on, and possibly combined with, existing unnesting of atoms (cf. #Distinction_of_Atoms_and_Expressions), and for ('active'/'evaluable') nestings is defined in Chapter 5.7 (pages 119ff) of Translators for interoperating and porting object-relational knowledge
  • [FUTURE] (First-order) Functional Programming (with higher-order syntactic sugar) would then be possible (in a logic with (oriented) equality / rewriting) as in Hilog and Relfun

5.2 Introduce Tuple Rests

With KB

John#Student(Mon Tue Fri)


John#Student(+[Mon Tue Fri])

the query

John#Student(?d1 ?d2 ?d3)


John#Student(+[?d1 ?d2 ?d3])

gives answer


while queries

John#Student(?d1 ?d2)
John#Student(?d1 ?d2 ?d3 ?d4)

both fail.

Should we introduce 'unsigned' tuples (currently NOT used), for answer bindings that are 'neutral w.r.t. dependency' and tuple-rest variables (with Prolog/Relfun-like "|"),

tuple-rest-variable (?R) queries

John#Student(| ?R)
John#Student(?d1 | ?R)
John#Student(?d1 ?d2 | ?R)
John#Student(?d1 ?d2 ?d3 | ?R)


John#Student(+[| ?R])
John#Student(+[?d1 | ?R])
John#Student(+[?d1 ?d2 | ?R])
John#Student(+[?d1 ?d2 ?d3 | ?R])

would succeed with

?R=[_Mon _Tue _Fri]
?d1=_Mon,?R=[_Tue _Fri]

When not using 'unsigned' tuples, instead using plex expressions, these queries would succeed with

?R=plex(+[_Mon _Tue _Fri])
?d1=_Mon,?R=plex(+[_Tue _Fri])

For a psoa atom with multiple tuples, each would be allowed to have its own tuple rest.

Also see PSOA RuleML: Integrated Object-Relational Data and Rules, Section 6.

5.3 Alternative to External

[DESIGN] Consider realizing a PSOA RuleML 1.0 change, mandatorily or optionally replacing External wrappers around built-in predicate and function calls with a more concise syntax such as non-wrapped calls where 'built-in-ness' is detected as a property of a call's operator (predicate or function) much like, in a logic with equality, a function's 'user-defined-ness' is detected as the presence of an equation unifying with the non-wrapped function call.

Study consequences for PSOA RuleML#Monolithic_Syntax, PSOA RuleML#Semantics, and PSOA RuleML#Test_Cases:

  • External wrappers act on an entire call (i.e., term), whereas "#"/"^" act on a call's operator
  • Although for user-defined predicates, as in PSOA RuleML#Combining_Atoms_and_Expressions, (top-level or embedded) objectification is needed, for built-in predicates it is not; however, while External wrappers 'shield' (top-level) predicates from objectification, for non-wrapped predicate calls built-in-ness detection can prevent objectification
    • External wrapping could thus be brought back as the result of a transformation step from unwrapped calls and/or the External-wrapper counterpart could be kept in the ANTLR ASTs.
  • Conversely, while External wrappers 'demote' (by one level) the predicate/function distinction, non-wrapped operator calls bring it to the 'top-level' (in long form: as a "#"/"^" distinction)
    • E.g. with External variants for predicates vs. functions, External-wrapped calls would become (cognitively and computationally) as 'transparent' as non-wrapped calls

Optionality would allow omission of External wrappers by not only shortcutting external built-in pred calls like

> External(pred:numeric-equal(42 42))


> pred:numeric-equal(42 42)

but also External built-in func calls like in

>  42 = External(func:numeric-add(26 16))


>  42 = func:numeric-add(26 16)

[instead of current



[Also current:

>  ?res = func:numeric-add(26 16)
?res=+(26 16)


Like in Prolog's "is" and unlike in External-using PSOA or "(...)"-vs.-"[...]"-using Relfun, 'active' funcs would not be 'applied differently' from 'passive' funcs but would need to be recognized as such:

  1. [Questionable:] By occurring in the context of a "=" rhs or an arg or slot-filler position.
  2. [Preferable:] By being defined
    1. [System-level:] as built-ins
    2. [FUTURE][User-level:] via equations (in a logic with (oriented) equality / rewriting)

For funcs, External thus currently not only marks a built-in but also indicates an 'active' call. Relying on "pred:"/"func:" prefixes as a replacement for External would burden prefixes with this extra meaning in contrast to the more simple ('user-package') meaning of other prefixes.

Active-function recognition through

  1. item 1 is questionable since passive (constructor) functions can occur in the same context
  2. item 2 is preferable since
    1. subitem 2.1 is familiar from many programming languages
    2. subitem 2.2 is familiar from many logic languages

where subitem 2.1 overrides subitem 2.2 (reuse of a built-in name in an (oriented-)equation lhs might even be forbidden).

5.4 Distinction of Atoms and Expressions

This design for this item is at PSOA RuleML#Combining_Atoms_and_Expressions. Also see PSOA RuleML#PSOA2Prolog_Features_and_Restrictions.

For explicitly distinguishing expressions from atoms, given the above discussion of External, both passive (constructor) and active (system&user-defined) functions may use a caret prefix, ’^’, while predicates may use a hash prefix, ’#’.

Example, in four variants (third variant: nat-predicate-applying ’...(. . .)’ and s-function-applying ’^...(. . .)’):

Forall ?n (#nat(^s(?n)) :- #nat(?n))
Forall ?n (#nat(s(?n)) :- #nat(?n))
Forall ?n (nat(^s(?n)) :- nat(?n))
Forall ?n (nat(s(?n)) :- nat(?n))

The ’^’-prefixed ’^s’ of a function constant can be expanded using the ’^_’ prefix: ’^_s’ (making the same ‘local’ assumption as now established for individual constants; ‘global’ function constants need to be written explicitly using the ’^:’ prefix, ’^:s’, or the ’^’ prefix for a ’:’-infixed pair, e.g. ’^ex:s’). Syntax with ’^’ prefix to distinguish functions is useful also without applications, e.g. for passing functions to (higher-order) functions and predicates as well as not only for function names but also for function variables such as ’^?f’ and function formers such as ’^\?x (...)’ (lambda) and ’^compose(square double)’.

The ’^’ prefix occupies the syntactic position of the PSOATransRun-implemented ’#’ infix, pairing an OID with a predicate. In PSOA RuleML, there also is a predicate-indicating ’#’ prefix complementing the function-indicating prefix ’^’, both to be PSOATransRun-implemented. Objectification of ’#’-prefixed predicate applications establishes a semantic equivalence with, and implemented transformation to, the ’#’ infix, which provides a (virtual or named) OID and indicates that the construct or name on its right-hand side is a predicate.

Using the non-prefixed short form term from PSOA RuleML#Combining_Atoms_and_Expressions as a fact

p(f1(f2(a u+>v)) s+>g1(b c))

the query

p(?x s+>?y)

should print the ergonomically preferable short-form bindings

?x = f1(f2(a u+>v))
?y = g1(b c)

rather than, e.g., their long-form expansions

?x = ^f1(^f2(a u+>v))
?y = ^g1(b c)

[Likewise, local constants should be printed without "_" prefix when unambiguous.]

This syntax without need for OIDs as markers for nested atoms (distinct from -- always oidless -- expressions) allows psoa atoms to be objectified not only when occurring on the top-level but also, in-place (embedded), when occurring in other psoa terms (helps, e.g., representing nested framepoints (tree-shaped, rather than DAG-shaped) as (root) framepoints with embedded frameships, i.e. without considering (auxiliary names of) OIDs for unnesting those frameships.

Example (from Ref. 12):

Currently and after the revision, the non-prefixed ’f’ -- c-term-embedded, not having an OID -- is assumed to be a function, hence not itself being unnested, while its embedded atom o2#d is:

= And(o2#d o1#c(p->f(o2)))

After the revision, ’^f’ -- with the ’^’ prefix -- may also be explicitly marked to be a function:

= And(o2#d o1#c(p->^f(o2)))

After the revision, ’#f’ -- with the ’#’ prefix -- is indicated to be a predicate, hence to be (embedded-)objectified and unnested:

= Unnest(o1#c(p->o3#f(o2#d)))
= And(o2#d o3#f(o2) o1#c(p->o3))

Having done all such normalization transformations, the (e.g. Prolog-)conversion transformation can ignore the (AST counterpart of) embedded ’^’ prefixes.

5.4.1 Implementation Enabled by the Predicate Prefix

The predicate prefix ’#’ is needed for embedded objectification. The implementation is test-driven: Before starting any coding, create ('breadth-first') all relevant test cases (as exemplified below) and anticipate (as "%"-comments) their expected behavior. Already in the current version, test follow-up step(s), e.g. of unnesting based on manually provided embedded objectification.

  1. Parsing of the predicate prefix
    1. Reuse and create examples for embedded oidful atoms (with the ’#’ infix)
    2. Reuse and adapt examples for embedded oidless atoms (with the ’#’ prefix)
    3. Verify non-ambiguity of using ’#’ as a prefix as well as using it as an infix
    4. Study PSOATransRun's parsing of the ’#’ infix and of the ’:’ prefix
    5. Reuse parsing code for ’#’-as-prefix parsing
    6. Realize parsing
      • What is the (sub)tree that we want to generate? Is, e.g., adding psoa_rest (and create a node) as an alternative in internal_term a good starting point?
      • Create a new ANTLR token type, e.g., EMBATOM, to distinguish embedded atoms in subsequent tree transformation steps?
    7. Combination of ’#’ with ’_’ (local predicate constant) and ’:’ (global predicate constant)?
  2. Transforming for embedded objectification
    1. Reuse and create (e.g., for subitem 3.1) examples for objectification
    2. Study PSOATransRun's top-level objectification implementation with examples
    3. Fix kind of objectification: Ground-fact-differentiated objectification (i.e., otherwise undifferentiated)
    4. Adapt unnesting code (traversing ASTs to localize ’#’s) and top-level objectification code (rewriting subASTs to insert OIDs) for embedded objectification (embobj: PSOA RuleML#PSOA2Prolog_Features_and_Restrictions)
      • Realize case 2 (for undifferentiated objectification), i.e. with Exists (when targeting Prolog: replaced, in a later transformation step, by Skolem-function application)
        • While in top-level objectification Exists scopes just the atom whose OID it quantifies, in embedded objectification Exists scopes the entire nesting of atoms at least one of which has such a quantified OID (all OID variables are declared in one Exists, assuming later transformation steps, particularly unnesting, can handle that: try examples)
      • Realize case 1 (for ground-fact-differentiated objectification)
  3. Integrating into transformation sequence
    1. Study PSOATransRun's sequence of (AST) transformation steps (where output of one is input for the next) in Debug mode
    2. Integrate embobj before unnesting:
      1. Embedded Objectification
      2. Unnesting
      3. Top-level Objectification
      4. Skolemization
      5. Describution (Slotribution and Tupribution)
      6. Flattening
      7. Rule Splitting
    3. Perform tests
      1. (Re)try all (above) examples affected by embobj
      2. Compare unnesting of already oidful embedded atoms with those made oidful by embobj
      3. Try 'corner cases'

5.4.2 Implementation Enabled by the Function Prefix

[DESIGN] The function prefix ’^’ will be needed for functional-logic programming (PSOA RuleML#Combining_Atoms_and_Expressions) to distinguish functions on the top-level.

6 Advanced Querying

6.1 Inside and Outside Querying

[DESIGN] Controlling inside ('local') vs. outside ('global') interpretation of query constants.

6.2 Conjunctive Query Processing


6.2.1 TPTP

For "--targetLang tptp", conjunctions -- as in FOL -- should be commutative, so PSOATransRun's TPTP converter cannot help optimizing query processing by generating specific conjunction orders.

6.2.2 Prolog

For "--targetLang prolog", conjunctions -- like even in Pure Prolog (and unlike in Horn logic) -- are textually ordered (left-to-right). Currently, PSOATransRun's Prolog converter preserves the textual order between atoms, so KB (rule-condition) and Query authors could do Semantic Query Optimization via the source conjunction order. For memterm / [prd]tupterm / [prd]sloterm conjunctions resulting from the describution of atoms, PSOATransRun uses an order where the memterm (#) -- rather than staying first -- goes last @@@. Also see #omitNegMem_as_a_Possible_Default_Option.

6.2.3 CLP

For a new "--targetLang clp" (cf. Scryer Prolog's clp(...) libraries), conjunctions -- as in CLP -- could be constraint-propagating, thus approaching the best of both worlds.

6.3 Taxonomy Querying

[DESIGN] PSOATransRun currently supports only querying of first-order facts and via rules and taxonomies, not of rules or taxonomies. Each subclass (##) second-order fact contributing to a taxonomy is translated to a rule by PSOATransRun, which cannot be queried as a whole and requires at least one 'witness' instance to answer #-queries properly. Taxonomy querying to directly retrieve ##-second-order facts could be included in PSOATransRun.

7 Expressivity/Efficency

7.1 Allow All Permutations of Descriptors in Psoa Atoms

See (ANTLR Grammars, Parser Grammar Rewriting):

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

Left-tuple normal form/LTNF ([Baseline] PSOATransRun 1.4.3):

_John#_Student(_Mon _Tue _Fri _coursehours+>20 _dept+>_Math _gender->_male)
_John#_Student(-[1995 8 17])
_John#_Student(+[_Mon _Tue _Fri] -[1995 8 17] _coursehours+>20 _dept+>_Math _gender->_male)
_John#_Student(-[1995 8 17] +[_Mon _Tue _Fri] _coursehours+>20 _gender->_male _dept+>_Math)  % Not left-tuple, left-dependent normal form

Left-implicit-tuple normal form ([Done] PSOATransRun 1.4.4):

_John#_Student(_Mon _Tue _Fri _coursehours+>20 _dept+>_Math _gender->_male)
_John#_Student(-[1995 8 17])
_John#_Student(+[_Mon _Tue _Fri] -[1995 8 17] _coursehours+>20 _dept+>_Math _gender->_male)
_John#_Student(-[1995 8 17] +[_Mon _Tue _Fri] _coursehours+>20 _gender->_male _dept+>_Math)  % Not left-implicit-tuple, left-dependent normal form
_John#_Student(+[_Mon _Tue _Fri] _coursehours+>20 _dept+>_Math _gender->_male -[1995 8 17])  % Not left-tuple normal form
_John#_Student(_coursehours+>20 _dept+>_Math _gender->_male +[_Mon _Tue _Fri] -[1995 8 17])  % Not left-tuple normal form
_John#_Student(_coursehours+>20 _dept+>_Math _gender->_male +[_Mon _Tue _Fri])               % Not left-tuple normal form
_John#_Student(+[_Mon _Tue _Fri] _coursehours+>20 -[1995 8 17] _dept+>_Math _gender->_male)  % Not left-tuple normal form
_John#_Student(_coursehours+>20 _dept+>_Math +[_Mon _Tue _Fri] _gender->_male -[1995 8 17])  % Not left-tuple normal form

Right-tuple normal form ([Not TBD, Since To Be Subsumed By] Free form):

_John#_Student(_gender->_male _dept+>_Math _coursehours+>20 _Mon _Tue _Fri)
_John#_Student(-[1995 8 17])
_John#_Student(_gender->_male _dept+>_Math _coursehours+>20 -[1995 8 17] +[_Mon _Tue _Fri])
_John#_Student(_dept+>_Math _gender->_male _coursehours+>20 +[_Mon _Tue _Fri] -[1995 8 17])  % Not right-tuple, right-dependent normal form

Right-implicit-tuple normal form ([Not TBD, Since To Be Subsumed By] Free form):

_John#_Student(_gender->_male _dept+>_Math _coursehours+>20 _Mon _Tue _Fri)
_John#_Student(-[1995 8 17])
_John#_Student(_gender->_male _dept+>_Math _coursehours+>20 -[1995 8 17] +[_Mon _Tue _Fri])
_John#_Student(_dept+>_Math _gender->_male _coursehours+>20 +[_Mon _Tue _Fri] -[1995 8 17])  % Not right-implicit-tuple, right-dependent normal form
_John#_Student(-[1995 8 17] _gender->_male _dept+>_Math _coursehours+>20 +[_Mon _Tue _Fri])  % Not right-tuple normal form
_John#_Student(-[1995 8 17] +[_Mon _Tue _Fri] _gender->_male _dept+>_Math _coursehours+>20)  % Not right-tuple normal form
_John#_Student(+[_Mon _Tue _Fri] _gender->_male _dept+>_Math _coursehours+>20)               % Not right-tuple normal form
_John#_Student(_gender->_male _dept+>_Math -[1995 8 17] _coursehours+>20 +[_Mon _Tue _Fri])  % Not right-tuple normal form
_John#_Student(-[1995 8 17] _gender->_male +[_Mon _Tue _Fri] _dept+>_Math _coursehours+>20)  % Not right-tuple normal form

Free form ([TBD]):

% All examples from: Left-implicit-tuple normal form ([Done] PSOATransRun 1.4.4)

% All examples from: Right-implicit-tuple normal form ([Not TBD, Since To Be Subsumed By] Free form)

% More examples:

_John#_Student(_gender->_male -[1995 8 17] +[_Mon _Tue _Fri] _dept+>_Math _coursehours+>20)
_John#_Student(_gender->_male -[1995 8 17] _dept+>_Math _coursehours+>20 +[_Mon _Tue _Fri])
_John#_Student(-[1995 8 17] _gender->_male _dept+>_Math _coursehours+>20 +[_Mon _Tue _Fri])
_John#_Student(_Mon _Tue _Fri _gender->_male _dept+>_Math _coursehours+>20)
_John#_Student(_gender->_male _dept+>_Math _coursehours+>20 _Mon _Tue _Fri)
_John#_Student(_gender->_male _Mon _Tue _Fri _dept+>_Math _coursehours+>20)

7.2 Make KB Input via Command Line as Expressive as via Import Statement

Currently, command-line input (-i,--input) refers to a KB in a local file but cannot refer to a KB in a global URL. An Import statement can be employed within an empty-KB ("include"-style) document to refer to a URL. But it would be better to refer to that URL directly from the command line.

7.3 omitNegMem as a Possible Default Option

[DESIGN] Consider making memterm omission the default, thus changing this (in LP, "negative literals" refer to atoms in rule conditions and directly in REPL queries; in the context of Naf, we refer to these as "goals", so as to avoid confusion between two uses of the word "negation"):

 -z,--omitNegMem   Omit memterm in the slotribution@@@-?->@@@describution of negative occurrences
                   of psoa atoms with at least one dependent descriptor

@@@[Hint: for completeness it is necessary to keep positive occurrences, e.g. in facts, also enabling memterm use by other, independent atoms.]@@@

However, for target engines such as Prolog that process conjunctions (as resulting from slotribution) left-to-right, it might be better for efficiency to keep negative occurrences of (ground) memterms, in left-most positions, causing (type/class/predicate) failures as early as possible rather than spending unnecessary computation before encountering such failures further into conjunctions. Hence the current default, with possible Semantic Query Optimization in the form of conjunction reordering (#Conjunctive_Query_Processing), could be kept.

7.4 Add Generic Inequality

Generalizing the number inequality built-in, a possible string inequality built-in, etc., a generic predefined inequality should be added:

  1. mainly as another built-in via a prefix predicate
  2. [DESIGN] perhaps as a primitive via an FOL infix operator (~=) and/or maybe a CLP prefix operator (dif)

Similarly to other PSOA built-ins and the Prolog is primitive as well as PSOA's generic equality (=) infix operator, ~= should be able to evaluate expressions (at least) in its second argument or right-hand side, but also allow the use of non-numeric, non-string, etc. arguments, negating the result of their equality comparison. The (initial) built-in version of ~= should be restricted to testing (in conditions) its arguments for inequality, rather than a (later) primitive version of ~= or dif that also could generate (in conclusions) pairs of unequal terms.

7.5 Add Negation-as-failure

Since Negation-as-failure (Naf) is not affected by the kind of (generalized psoa) atoms in its scope, in PSOATransRun[PSOA2Prolog,...] instantiations it can be orthogonally added by augmenting the Prolog converter to translate Naf to Prolog's Not.

7.6 Extend towards Reaction RuleML

Make Pure Production Rules available in an extended PSOATransRun instantiated for targeting Prova (PSOA Prova).

7.7 Add support for membership declaration in the "Forall" wrappers

[DESIGN] This Many-sorted logic feature will allow to limit the domain of discourse of the variables-quantifiers. It will be especially helpful in cases of "free" variables which result in singleton variables and unwanted bindings. Furthermore, it improves the readability of the code, e.g instead of:

Forall ?x ?y (
   p1(s1->?x s2->?y) :- And(p2(?y v2) ?x#p3)

where ?x#p3 limits the possible bindings of the variable ?x, it will be possible to have the equivalent code:

Forall ?x#p3 ?y (
   p1(s1->?x s2->?y) :- p2(?y v2)

8 Usability Increase

8.1 Display Instantiation and Version

  • [Done] On startup, unconditionally display (command-line) instantiation variety and (released) version number of PSOATransRun such as PSOATransRun1.3[PSOA2Prolog,XSBProlog] (vs. PSOATransRun1.3[PSOA2TPTP,VampirePrime]) followed by PSOATransRun1.4[PSOA2Prolog,XSBProlog] (vs., e.g., PSOATransRun1.4[PSOA2Prolog,SWIProlog] and PSOATransRun1.4[PSOA2TPTP,VampirePrime])) and then in smaller increments like PSOATransRun1.4.1[...,...]
    • Also see:
      • ...\PSOATransRunComponents\PSOATransRun\src\main\java\org\ruleml\psoa\psoatransrun\
      • println("PSOATransRun 1.3"); // TODO: Define method in PSOATransRun class, called here to return version
  • Instead of hard-coding version into a print statement, use global variable(s) or constant(s), which later could also again be printed in interactive sessions (cf. Project 2)

8.2 Refine TPTP Instantiation

  • Explore running on Linux (very easy, currently via VirtualBox), macOS (very probable), Windows (very unlikely, since VampirePrime-needed C library is missing)
  • Expand the --test option examples that can be run using --targetLang tptp rather than --targetLang prolog (already all except [External-wrapped] built-ins)
  • [Done] Consider reactivating Web Hosting

8.3 Enable Multi-Line Query Input

[FUTURE] Currently, multi-line interactive query input is not allowed because the first end-of-line (via the ENTER key or the clipboard) immediately starts parsing. Since consoles cannot distinguish end-of-line from ENTER, a clean solution needs to bypass the console and directly handle keyboard events from end users in Java, like GUI-based programs such as Skype do, which can distinguish ENTER from SHIFT-ENTER and allows clipboard pasting of multi-line input, where 'inner ENTERs' are passivated.

8.4 Display Blank-Separated Bindings in Interaction Loop

[Done] In the interaction loop, consider displaying a substitution (a binding for each query variable) not in a ","-separated but in a (more light-weight) " "-separated manner, e.g. for query

?situation#own(Mary ?what)

display the substitution

?what=_XMLBible ?situation=_oidcons(_own _Mary _XMLBible)

which is also the format for *-answerJ.psoa files. Besides interaction/batch uniformity, this permits copy&paste from the interaction loop to a corresponding *-answerJ.psoa file. Moreover, in Prolog the comma already has two other meanings.

8.5 Allow Tracing

While the --echoInput (-e) option shows the translated KB and query, it would sometimes be helpful to see a computation trace on the same level. For the Prolog instantiation, this could just be a Prolog trace under the PSOATransRun system (a trace can already be viewed by invoking a separate (traced) XSB Prolog engine with translation results). For the TPTP instantiation, this would likely be more involved because of the complete search performed by TPTP engines (such as VampirePrime).

8.6 Introducing REPL Performatives

A Read–Eval–Print Loop (REPL) is considered here as an agent communicating with user agents via standardized performatives.

8.6.1 Generalize REPL Error Messages to REPL Performatives

Generalize the error messages of the PSOATransRun Read–Eval–Print Loop (REPL) to performatives similar to those employed by agents communicating via KQML (kqmlperformatives), Reaction RuleML, etc. The PSOATransRun REPL-performative core set (finding, warning, error) includes the novel finding performative, which informs users about a query/KB checking result while not judging that result (as exemplified by --checkLTNF for Left-Tuple Normal Form). These REPL performatives should uniformly communicate with users via standardized messages/exceptions, each employing a prefix for the top-level REPL performative category (PSOATransRun prefix core set: "Finding: ", "Warning: ", "Error: "):

  • The REPL performative categories "Finding" and "Warning" only print messages.
  • The REPL performative category "Error" also raises an exception.

For the PSOATransRun performative structure and more details see this taxonomy of performatives used by the REPL:

Taxonomy of PSOATransRun REPL Performatives
(ordered from least to most 'disruptive')

REPL Performative
  Notification (Message)
      Relationship atoms (allowed generally in Prolog)
      All other atoms (allowed specifically in PSOA)
  Error (Message + Exception)
     Explicitly Raised Exception (programmed by PSOATransRun developers)
     Implicitly Occurring Exception (printed as Java stack trace)

8.6.2 Command-Line Options for REPL Performatives

Consider possible connection of options --fAllWrap, --checkLTNF, etc. to option --denseErrorMsgs (for Java stack trace).

8.6.3 Refine Messages of REPL Performatives

  • Some msgs can be easily refined. Others (e.g., from multiple thrown exceptions received by a single catch) are not so easy.
  • Explain error texts like "node from line 0:0" or make them more comprehensive.

8.7 Revisit Encodings and Reserved Names

Addition to Project 4 on fixing issue with (<- Interprolog <- XSB Prolog) back-translation of constant encodings by single-quote surroundings (for '_'-prefixed PSOA constants and '"'-surrounded PSOA strings in XSB Prolog).

8.8 Preserve Comments in the Translated KB

Currently, comments are ignored by the parser, while the translated KB has no empty lines between blocks of code corresponding to a rule of the original KB. One possible solution is to preserve original comments (and possibly empty lines) in the translated KB, thus improving the readability of the generated Prolog/TPTP code. This will require changes to the ANTLR lexer, e.g. send COMMENT tokens to a dedicated channel. Then, they can be retrieved from e.g. CommonTokenStream which contains all the tokens, including the tokens of the dedicated channel. An important note is that it may be necessary to discard non whole-line comments.

Handling multi-line comments or empty lines would be also desired. One possible option for multi-line comment preservation is to also support the Prolog/TPTP-compatible block-comment based (/*...*/) comments, as their handling would be easier to implement.

9 Utility Programs

9.1 Refine Unit Test Program

For background see PSOA RuleML Unit Tests, which sketches Systematics, Vocabulary, and more.

[DESIGN] Consider refining the (Java) TestSuite program that runs X_Y_Z[I]-queryJ.psoa with expected X_Y_Z[I]-answerJ.psoa for X_Y_Z[I]-KB.psoa in subdirectory X_Y_Z[I] of the directory test, comparing each actual answer with the expected answerJ. Possibly generalize the program such that it can be used for structured directories like, for Specification of Deliberation RuleML 1.03#Testing_of_Relax_NG_Schemas, the 'test cases' in rnc-test-suites (also see the 'show cases' in exa), where the current functionality is applied to the innermost directories (of the above form), whose existing (e.g., *.ruleml, *.pl, and *.grailog) files, i.e. files other than *-queryJ.psoa, *-answerJ.psoa, and *-KB.psoa are ignored. This will help creating and maintaining #Test_Cases.

Besides having a test-collection directory containing test-case directories, as in the command (with the main test collection, which is simply called test)

--test -i ...\test

we should also allow an individual test-case directory, as in the command (with a test-case directory indivdir1)

--test -i ...\indivdir1

or in the command (assuming the test collection test contains a test-case directory indivdir2)

--test -i ...\test\indivdir2

A mid-term TestSuite-like program could relax the current file name conventions, so it could be applied to arbitrary *.psoa KBs: The "-KB" suffix for file names X_Y_Z[I]-KB.psoa would no longer be needed.

For a long-term TestSuite-like program, after (drawing on RuleML/XML) not only a <Query>-markup-corresponding syntax but also an <Answer>-markup-corresponding syntax is introduced for a "self-describing" presentation syntax inside files, the file names X_Y_Z[I]-queryJ.psoa and X_Y_Z[I]-answerJ.psoa would no longer be essential, but a (Reaction-RuleML-send-like) general messaging performative could be used. But then the queryJ/answerJ pairing would need to be done in another way, e.g. by combining queryJ/answerJ files into one messageJ file (disadvantage: sometime queryJ/answerJ could become useful in a decoupled way), or by pointing from the queryJ file to the answerJ file.

  • Also see:
    • ...\PSOATransRunComponents\PSOATransRun\src\main\java\org\ruleml\psoa\psoatransrun\test\
    • File[] testCases = dir.listFiles(); // TODO: listFiles could be generalized to structured directories.

9.2 Refine Benchmark Test Program

Refine the (Python) program, for chain and its variants, that (1) creates an enumeration of PSOA KBs of increasing size for a single query with an obvious answer and (2) provides the execution environment for probing PSOATransRun response times over them.

10 Upgrading PSOA RuleML Files

10.1 RuleML/Assert Use, ...:


10.2 Empty KB Allowance

Because some users don't want any Import and some may want to work off-line (rather than connecting to, the following should not be the default but the file EmptyKB.psoa should be provided in the PSOATransRun distribution for manual command-line use.

[DESIGN] Consider to allow starting without a KB option/parameter, to be automatically initialized as the empty KB (omitted Assert), EmptyKB.psoa (instead of error

C:\Users\...>java -jar PSOATransRunLocal.jar
No input KB specified


RuleML (  % Empty KB but allowing built-ins and libraries
  Prefix(pred: <>)
  Prefix(func: <>)
  Prefix(math: <>)
  Prefix(phys: <>)

11 Test Cases

11.1 Unit Tests

11.2 Benchmark Tests

Expand on the Ref. 18 benchmarks (including nat and two versions,, of chain).

11.3 Deliberation/PSOA RuleML Intersection Tests

Create tests, in PSOA Presentation Syntax, where PSOA RuleML/PS already semantically intersects with Deliberation RuleML/XML (later: PS generated from XML with PSOA RuleML API):

  1. (Purely) Relational KBs (e.g. for Project 3's case study "A Rule-Based Approach for Air Traffic Control ...")
    1. [Done] own.ruleml:
    2. [Done] discount_compact.ruleml:
    3. [Done] LoanProcessor.ruleml:
  2. [DESIGN] Cases where engines (e.g., PSOATransRun) for PSOA RuleML's slotribution produce answers equivalent to those of engines (e.g., OO jDREW) for Deliberation RuleML's slotted unification

11.4 Deliberation/PSOA RuleML Union Tests

[FUTURE] Similarly, add tests preparing (semantically) the union of Deliberation and PSOA features, e.g. multiple tuples with positional rests. Maybe use Prolog lists with "|" for PSOA argument sequences, but this would degrade performance.

12 Technology-Stack Maintenance

Also requires documentation in support of maintenance.

12.1 ANTLR

Deliberately using an earlier version (ANTLR v3).

12.2 Java

Recommended version range: @@@

12.3 Eclipse

Pop-ups about updates.

12.4 EGit

See tutorial.

12.5 GitHub

See Github Demo.

12.6 IBM Cloud

For the TPTP instantiation, the Web-based service (project PSOATransRunWebService) can be found at [cf. item 1) at PSOA_RuleML#TPTP_Instantiation].

12.7 InterProlog

See if new version, supporting SWI, is also relevant for XSB:

12.8 XSB Prolog

For Windows, install XSB 3.6 rather than the more recent 3.7 or 3.8: