Project

// From POSL to d-POSL: Making the // // Positional-Slotted Language Defeasible //

The Positional-Slotted Language (POSL) provides a human-oriented syntax for a subset of RuleML/XML. POSL is specified in EBNF and as an ANTLR grammar. A POSL<-->RuleML converter relieves users from writing RuleML in XML. Some rule engines (including OO jDREW) use POSL for rule and query editing. Defeasible RuleML (d-RuleML) permits the prioritization of rules and the presence of non- monotonicity. The current POSL 0.91 shall be upgraded to POSL 1.0 (crucial difference: separator between a variable and its type changed from ":" to "^^", e.g. from ? product:EBizProd to ? product^^EBizProd ) and extended (with IRI namespace prefixes, built-in calls, etc.), in sync with RuleML 1.0.. On top of this, Defeasible POSL (d-POSL) shall be upgraded from 0.91 to 1.0. An expert, Efstratios ( Stratos ) Kontopoulos, and software tools are available as part of a collaboration between RuleML and Aristotle University Thessaloniki.

POSL 1.0 and d-POSL 1.0 will be made available, open source, e.g. via the RuleML website. POSL:

0.85: __ [] __

(contains many features, although not up-to-date)

0.91: [|www.cs.unb.ca/~boley/cs6795swt/poslintweb-talk.pdf]

1.0: []

(POSL grammar in appendix) d-POSL:

__ [|www.cs.unb.ca/~boley/talks/RuleResponderAgentsVO-2010-09-10.ppt] __ (slide 43)

__ [] __ (links to code for the d-POSL editor)

__ [] __ POSL-RuleML converter (in Java Web Start): __ [] __

__ [] __ ANTLR: __ [|http://www.antlr.org] __ Source code of previous project:

__ [] __

//**Phase one, generate a compiler for the extensions to posl and d-posl**// //**Phase 2 extend oojdrew with new semantics for posl and dposl**// //**Extending oojdrew with dposl, it already does posl**//

Before you get to do the semantics of the language, you have to convert the text into a form that's easy to operate on. This process is called [|parsing] and the semantic representation is called an [|abstract syntax tree] (AST). A simple recursive descent parser for Prolog might be hand written, but it's more common to use a parser toolkit such as [|Rats!] or [|Antlr]

l Resolving a fact against a condition in a rule is called forward reasoning – attends(Student, Course) ¬ passes(Student, Course) – Resolvent: attends(‘Fang’, cs6999) l Usually a derivation tree is viewed with given facts at the bottom and derived facts at the top – so forward reasoning also called bottom up reasoning l Prolog does top-down, backward reasoning – starting from a negative clause, called a query

6. What are the main data structures used in jDREW?
There are three important data structures of jDREW.
 * 1) SymbolTable: a symbol table is an array of print names and arities of symbols. For instance in //p(f(g­1), h, h(g2))//, //p// has arity 3, //f// has 1, //g­1//, //g2// has arity 0. There are two different symbols //h//, with arity 0 and with arity 1. The symbol table for this atom will appears as follows:
 * || name || arity  ||
 * 1 || //p//  ||  //3//  ||
 * 2 || //f//  ||  //1//  ||
 * 3 || //g1//  ||  //0//  ||
 * 4 || //g2//  ||  //0//  ||
 * 5 || //h//  ||  //0//  ||
 * 6 || //h//  ||  //1//  ||
 * 1) DefiniteClause: DefiniteClause is a Java class that is used to internally represent atoms and clauses. DefiniteClause uses flatterms [1] to represent altoms and clauses. A flatterm is a pair of arrays of short integers: symbol and length. Each predicate symbol, function symbol and variable in the formular has a position in these arrays. The first array of the flatterm, symbol, contains the symbol table index for predicate or function symbol in this position. The second array, length, contains the length of the subformular beginning at this position. In jDREW, the scope of a variable only covers a clause and no further. The variables in each clause are numbered with negative indices starting at –1, and there is no confusion with variables from other clauses. The following two flatterms represents //p(f(g­1), h, h(g2))// and //p(f(h(X)), h(Y), f(X), Y)// using the above symbol table.
 * || symbol || length ||  ||   || symbol || length ||
 * 1 || 1  ||  7  ||^   || 1 ||  1  ||  9  ||
 * 2 || 2  ||  2  ||^   || 2 ||  2  ||  3  ||
 * 3 || 3  ||  1  ||^   || 3 ||  6  ||  2  ||
 * 4 || 5  ||  1  ||^   || 4 ||  -1  ||  1  ||
 * 5 || 6  ||  2  ||^   || 5 ||  6  ||  2  ||
 * 6 || 4  ||  1  ||^   || 6 ||  -2  ||  1  ||
 * 7 || 3  ||  1  ||^   || 7 ||  2  ||  2  ||
 * ||^  || 8 ||  -1  ||  1  ||
 * //p(f(g­1), h, h(g2))// ||^  || 9 ||  -2  ||  1  ||
 * ||^  ||||||  //P(f(h(X)), h(Y), f(X), Y)//  ||
 * 1) DiscTree: DiscTree implements the discrimination tree [2] data structure. The discrimination tree is used in jDREW to find atoms that are likely to unify with a given goal atom. The flatterm of each definite clause are organized in the DiscTree according to its index atom. The following figure shows the a fragment of the discrimination tree for two clauses whose index atoms are //p(f(g­1), h, h(g2))// and //p(f(h(X)), h(Y), f(X), Y).// Each internal node of the discrimination tree contains a function or predicate symbol that occurs somewhere in the index atom. All variables are replaced by * and are treated as the same symbol. If two atoms have the same symbols in positions //1// to //n//, but a different symbol in position //n+1// then the node corresponding to the first //n// positions will have (at least) two children. At each leaf of the discrimination tree we store the clause whose index atom corresponds to the path from the root.