PSOATransRun Development Tutorial

From RuleML Wiki
Jump to: navigation, search

Authors: Gen Zou, Harold Boley, Tara Athan


PSOA RuleML, as described in the recent PSOAPerspectivalKnowledge paper, is a novel language for integrated object-relational data and knowledge. PSOATransRun is the PSOA RuleML reference implementation realized by high-level source-to-source translation using PSOA-to-PSOA transformation followed by PSOA-to-TPTP or PSOA-to-Prolog conversion that targets, e.g., the XSB Prolog engine for runtime execution.

PSOATransRun (which you can try with examples given or referenced in PSOA_RuleML, e.g. PSOARuleMLInvitedTutorialExamplesRW2015) has been developed by the first author over several years and has reached main Version 1.3 (current Version: PSOA RuleML#Prolog_Instantiation). While PSOA_RuleML#PSOATransRun gives an overview, and the README at http://psoa.ruleml.org/transrun/1.3/local/ gives a (brief) user introduction for PSOATransRun 1.3, the current 5-session tutorial addresses (open source) developers who desire a deeper understanding of PSOATransRun, e.g. because they are working on similar systems and/or consider contributing to future releases.

The tutorial is being continued by open-source project meetings (see descriptions in Session 5):

  • Project 3: Mon, 15 Jan 2018, 7am Pacific / 10am Eastern / 11am Atlantic / 3pm UK / 4pm Central Europe / 5pm Greece
  • Project 1: Tue, 16 Jan 2018, 10am Pacific / 1pm Eastern / 2pm Atlantic / 6pm UK / 7pm Central Europe / 8pm Greece
  • Project 4: Wed, 17 Jan 2018, 7am Pacific / 10am Eastern / 11am Atlantic / 3pm UK / 4pm Central Europe / 5pm Greece

If you want to participate and do not know the Skype details, please send an email with your Skype ID to Harold Boley (address via above homepage).

To get the most out of this tutorial and the open-source projects, there are two levels of installation and use:

(Across the two READMEs, the same JDK, containing JRE, should be used for both of these bullets.)

More links to information about PSOA RuleML 1.0 and PSOATransRun 1.3 are in the Newsbar item of 2017-12-11.

1 Overview

(Tue, 19 Dec 2017, 2pm Eastern)

The architectural big (data- and control-flow) picture of the PSOATransRun 1.3 instantiation targeting Prolog, as implemented with GitHub-documented components in Java and ANTLR, and kept in the repository https://github.com/RuleML/PSOATransRunComponents:

  1. Translator parts
    1. PSOA RuleML 1.0 text-to-tree parser
    2. Normalization: Chain of tree-to-tree transformers
    3. Conversion: Final tree-to-text generator for XSB Prolog
  2. Runtime part

Advanced features of PSOATransRun as shown by

java -jar PSOATransRunLocal.jar --longhelp

include the automated PSOATransRun (unit-)testing environment.

Development infrastructure: Eclipse comes with the plugin EGit, a light-weight Git client (with a connection to users' GitHub accounts). Directory structure (same between GitHub and website). How to compile with Eclipse on the level of all directories and files. How to manage *.java (source) vs. *.jar (executable), e.g. GitHub no longer has separate download pages for *.jar files. What you may want to know on a low ("nuts and bolts") level. How to maintain the system, as it interacts with RuleML's virtual host (e.g., should something break such as a cron job no longer working).

2 PSOATransRun Workflow

(Thu, 21 Dec 2017, 2pm Eastern)

The overall workflow of PSOATransRun in Java, partly generated from ANTLR grammars. PSOATransRun uses ANother Tool for Language Recognition (ANTLR v3) to: 1. parse PSOA RuleML texts, 2. normalize the resulting trees (analogous to XSLT over XML DOM trees etc.), and 3. generate, from them, the targeted (e.g., XSB Prolog) texts.

3 Parsing PSOA into ASTs

(Wed, 3 Jan 2018, 2pm Eastern)

This session covers ANTLR use 1 -- parsing a KB and query from PSOA RuleML 1.0 Presentation Syntax (PS) into an Abstract Syntax Tree (AST). The next sessions will cover ANTLR uses 2 and 3.

4 Normalizing ASTs

(Fri, 5 Jan 2018, 2pm Eastern)

This session discusses the normalization of ASTs, e.g. for the central describution step of an oidful atom normalized into a conjunction of single-descriptor atoms with the same OID such as in PSOAPerspectivalKnowledge, where the (KB2) atoms describing the OID John are normalized to (KB1) atoms.

5 Generating Prolog from Normalized ASTs and Defining Projects for Enhancing PSOATransRun

(Tue, 9 Jan 2018, 11am Eastern)

This session first discusses AST normalization and conversion to Prolog.

  • Prolog runtime predicates for PSOA RuleML 1.0: memterm, sloterm, tupterm, prdsloterm, prdtupterm
  • Generating Prolog with runtime predicates from the transformed trees

We will then discuss project proposals for enhancing PSOATransRun.

All versions of PSOATransRun through 1.3 had required explicit underscore prefixes to mark local constants (individuals, functions, predicates, and slot names). In PSOA RuleML's abridged presentation syntax (used as the de facto 'publication syntax'), underscores are understood -- and can be discovered and reconstructed -- for relevant non-prefixed names.

The first author (performing a preliminary project on local-constant discovery) has automated, in Java and ANTLR, a basic PSOATransRun 1.3 upgrade for the discovery of relevant names and the reconstruction of their omitted underscores as a tokenizer-level 'pre-processing' translation, realizing the central part of an abridged-to-unabridged PSOA RuleML transformation.

Basically, a non-prefixed name is tokenized as if it was _name with the notable exceptions of name being one of the following:

  • Special predicates: Top, ...
  • Primitive predicates: External [might be deprecated after PSOA RuleML 1.0 release], ...
  • Datatype individuals: Integers, ...
  • Translator directives: Prefix, Import, ...

The exceptions should be represented in a declarative, easily maintainable and reusable manner. E.g., the PSOA RuleML 1.0 prerelease may thus be augmented by new special individuals:

  • Special individuals: ..., False [for Or()], True [for And()]

Building on the results of the preliminary local-constant discovery project, two PSOATransRun-evolution projects are proposed, Project 1 preparing Project 2. Based on orthogonal platform considerations, PSOATransRun-evolution Project 3 is proposed. For further evolution, Project 4 is proposed. Moreover, several PSOATransRun-application projects have emerged, including the Loan Processor decision model transcribed from POSL to PSOA (LoanProcessor) and a medical-legal classification of devices formalized from an EU Regulation (Medical Devices Rules).

Project 1: PSOATransRun Parameterization: [Done] Allow, even as the default, executing PSOATransRun with a KB and queries using abridged local-constant syntax from which unabridged syntax will be reconstructed (one or more local-constant occurrences may already be unabridged). Add an optional parameter -c with long form --explicitLocalConstants for the explicitly specified case of no local-constant reconstruction but rigid syntax checking:

java -jar PSOATransRunLocal.jar -c ...

[ToDo] See if further helpful parameterizations could be easily added such as for targeting the XSB vs. SWI engine (cf. Project 3).

Project 2: PSOATransRun GUI: [ToDo] Bring the top-level loop, e.g. loading different KBs, from the command-line console into a GUI for the PSOATransRun[PSOA2Prolog,XSBProlog] instantiation such that users can more easily vary selected parameters without need for quitting and re-entering the system. For the convenience of all users, employ the same command-line names -short with long form --long (e.g., -c with long form --explicitLocalConstants) also in the GUI, and make them additionally available as graphic (e.g., drop-down menu) actions later. Hence, for an initial GUI-preparing extension, after the input prompt, ">", rather than expecting queries only, the enriched version can parse "-"- and "--"-prefixed commands (reusing the command-line parser) and perform the associated command actions (reusing the command-action executer): While such 'minus' and 'double-minus' prefixes can be avoided as the first characters of queries (e.g., in unit tests), a refined command/query-separated version can be developed later. The starting point for the GUI extension is the file PSOATransRunCmdLine (https://github.com/RuleML/PSOATransRunComponents/blob/master/PSOATransRun/src/main/java/org/ruleml/psoa/psoatransrun/PSOATransRunCmdLine.java). Take into account that the GUI should ultimately be Web-based (cf. PSOATransRun_Development_Agenda#Openshift), e.g. informed by the earlier PSOATransRun[PSOA2TPTP,VampirePrime] instantiation (i.e., by http://wiki.ruleml.org/index.php/PSOA_RuleML#TPTP_Instantiation).

Project 3: PSOATransRun SWI: [ToDo] Explore the use of SWI Prolog for PSOATransRun, i.e. how PSOATransRun[PSOA2Prolog,XSBProlog] can be changed to PSOATransRun[PSOA2Prolog,SWIProlog], where declarations for XSB Prolog's predicate tabling may be adapted for SWI Prolog's tabling. Already without a tabling substitute this will facilitate porting the relational case study "A Rule-Based Approach for Air Traffic Control in the Vicinity of the Airport" by Theodoros Mitsikas, Petros Stefaneas, and Iakovos Ouranos from POSL to PSOA. Since this case study currently employs POSL (on OO jDREW) and SWI Prolog in a (purely) relational manner, its version employing PSOA (on PSOATransRun) and SWI Prolog can also help exploring the behavior of PSOATransRun 1.3's static/dynamic OID virtualization for larger relational KBs. Generalized KB clauses can then be added, such as by extending aircraft modeling from (oidless) relationships to psoa atoms with OIDs for unique tracking and slots for optional properties. At that time, SWI Prolog's tabling may become unavoidable. See MitsiCash's own fork: https://github.com/MitsiCash/PSOATransRunComponents

Project 4: PSOATransRun Maintenance: [ToDo] Utilizing the automated (unit-)testing environment (see the README.txt at the bottom of https://github.com/RuleML/PSOATransRunComponents/tree/master/PSOATransRun/test), construct further PSOATransRun test cases in PSOA RuleML, some of which could become the seeds of later applications. For test cases that pinpoint an issue whose resolution is agreed upon, plan and implement fixes.

[Done] To exemplify, for #KB_with_Queries, the test cases

> _Student(+[_Mon _Tue _Fri])    % Relational query with explicit tuple, marked as predicate-dependent
line 1:100 mismatched character '<EOF>' expecting '\n'
Answer(s):
Yes

> _Student(+[_Mon _Tue _Fri])    %
line 1:32 no viable alternative at character '<EOF>'
Answer(s):
Yes

pinpoint that "%"-inline-commented queries yield correct Answer(s) but have an <EOF> issue. Since "%"-comment parsing inadvertently 'eats up' its terminating newline, \n, the resolution is to skip characters that are not \n in a "%"-prefixed line (even if empty).

For all projects, practice the PSOATransRun Production Cycle (e.g., towards PSOATransRun 1.4, as planned in PSOATransRun Development Agenda):

  1. Prepare unit testing with current counter-examples (cf. Project 4)
    1. Create test (-KB, -query, -answer) files for testing environment
    2. Execute test files with expected presence of errors
  2. Do Java and ANTLR changes with instant inline documentation
  3. Perform unit testing with what now should be examples (cf. Project 4)
    1. Reuse or augment test files of 1.1
    2. Execute test files with expected absence of errors
    3. Go to 2 if any error persists
  4. Document (I)
    1. Add more inline documentation
    2. Update README
  5. Publish on GitHub with expressive Commit message
  6. Document (II)
    1. Update/Create MediaWiki page(s)
    2. Update/Create LaTeX paper(s)

6 KB with Queries

The KB with queries of Rich TA Explorations in PSOA Perspectivity provide a use scenario for the tutorial.