You are currently browsing the category archive for the ‘Prolog as the model engine’ category.

Derivation is a popular example about symbolic computation, i.e. *symbolic analysis from the mathematical approach*.

This example demonstrates the expressive power and ease-of-use of symbolic manipulation in Prolog (more examples here: http://en.allexperts.com/e/p/pr/prolog.htm).

### Procedural approach to Prolog, Derivation

d(X,X,1) :- !. /* 1 x dx = 1 */

d(C,X,0) :- atomic(C). /* 2 c dx = 0 */

d(-U,X,-A) :- d(U,X,A). /* 3 -u dx = - d u dx */

d(U+V,X,A+B) :- d(U,X,A), d(V,X,B). /* 4 u+v dx = d u dx + d v dx */

d(U-V,X,A-B) :- d(U,X,A), d(V,X,B). /* 5 u-v dx = d u dx - d v dx */

d(C*U,X,C*A) :- C \= X, d(U,X,A), !. /* 6 c*u dx = c*d u dx */

d(U*V,X,B*U+A*V) :- d(U,X,A), d(V,X,B). /* 7 u*v dx = u*d v dx + v*d u dx */

d(U/V,X,A) :- d(U*V^(-1),X,A). /* 8 u/v dx = d (u*v)^-1 dx */

d(U^C,X,C*U^(C-1)*W) :- C \= X, d(U,X,W). /* 9 u^c dx = c*u^(c-1)*d u dx */

d(log(U),X,A*U^(-1)) :- d(U,X,A). /*10 ln(u) dx = u^-1 * d u dx */

### Derivation in Visual Prolog

d(int(_),_) = int(0). d(var(X),X) = int(1):- !. d(var(_),_) = int(0):-!. d(plus(U,V),X) = plus(d(U,X),d(V,X)). d(minus(U,V),X) = minus(d(U,X),d(V,X)). d(mult(U,V),X) = plus(mult(d(U,X),V),mult(U,d(V,X))). d(div_(U,V),X) = div_(minus(mult(d(U,X),V),mult(U,d(V,X))),mult(V,V)). d(ln(U),X) = mult(div_(int(1),U),d(U,X)). d(potens(E1,int(I)),X) = mult(mult(int(I),potens(E1,int(I-1))),d(E1,X)). d(sin(U),X) = mult(cos(U),d(U,X)). d(cos(U),X) = minus(int(0),mult(sin(U),d(U,X))). d(tan(U),X) = mult(potens(sec(U),int(2)),d(U,X)).

Starting derivation

differentiate(STR) = ResultStr:- InputExpression = diff::parse(Str,EXP), DifferentiatedExpression = diff::d(InputExpression,"x"), OutputExpression = diff::reduce(DifferentiatedExpression), ResultStr = diff::writeexp(OutputExpression).

### The Atomistic Correspondence for the Procedural Definition

Let’s assume **SE **to be the base class for all atomistic objects. It is then the definition for AHO. Let’s **Symbol **be the definition for the whole model semantics, here derivation.

Model Weaver to create the atomistic model:

differentiateExpression(Str) = OutputExpression:-

S = s::new(),

BuiltModel = sEModelBuilder::build(S:parse(Str)),

ResultExpression = BuiltModel:d("x"),

ResultElement = seData::new(ResultExpression),

OutputExpression = ResultElement:reduce().

Interface for the Symbol:

interface symbol domains exp = var(string); int(integer); plus(exp,exp); minus(exp,exp); … potens(exp,exp); ref(se). /* this is a reference to a symbolic element, AHO */ predicates parse: (string) -> exp determ. writeExp: (exp) -> string. end interface symbol

To convert a procedural Prolog-derivation model into an atomistic one, there is only one definition needed to add into the original code:

d(ref(SE),X) = SE:d(X).

### Architecture for the Derivation Example

### Summary

This application shows that it is possible to translate “procedural”, i.e. non-object-based programs into atomistic ones, when the semantics is formal.

### Some links

- About Prolog at AllExperts : http://en.allexperts.com/e/p/pr/prolog.htm

## SWRL:

SWRL is a Semantic Web Rule Language, which combines OWL and RuleML

**An OWL ontology in the abstract syntax contains a sequence of axioms and facts**. Axioms may be of various kinds, e.g., subClass axioms and equivalentClass axioms. It is proposed to extend this with rule axioms.

axiom ::= rule

A rule axiom consists of an antecedent (body) and a consequent (head), each of which consists of a (posibly empty) set of atoms. A rule axiom can also be assigned a URI reference, which could serve to identify the rule.

rule ::= 'Implies(' [ URIreference ] { annotation } antecedent consequent ')' antecedent ::= 'Antecedent(' { atom } ')' consequent ::= 'Consequent(' { atom } ')'

Informally, a rule may be read as meaning that if the antecedent holds (is “true”), then the consequent must also hold. An empty antecedent is treated as trivially holding (true), and an empty consequent is treated as trivially not holding (false). Rules with an empty antecedent can thus be used to provide unconditional facts; however such unconditional facts are better stated in OWL itself, i.e., without the use of the rule construct. Non-empty antecedents and consequents hold iff all of their constituent atoms hold, i.e., they are treated as conjunctions of their atoms. **As mentioned above, rules with conjunctive consequents could easily transformed into multiple rules each with an atomic consequent**. **This principles leads to an atomistic approach, similar to Symbolic Analysis.**

### OWL’s atom is like this:

atom ::= description '(' i-object ')' | dataRange '(' d-object ')' | individualvaluedPropertyID '(' i-object i-object ')' | datavaluedPropertyID '(' i-object d-object ')' | sameAs '(' i-object i-object ')' | differentFrom '(' i-object i-object ')' | builtIn '(' builtinID { d-object } ')' builtinID ::= URIreference

Let’s see AHO to compare it into the atom of Symbolic Analysis.

### Comparing RuleML and Prolog

Prolog:

discount(customer,product1,’5.0 percent’) :-

premium(customer),regular(product).

The corresponding XML-query in RuleML:

**Example:**

A simple use of these rules would be to assert that the combination of the `hasParent` and `hasBrother` properties implies the `hasUncle` property. Informally, this rule could be written as:

hasParent(?x1,?x2) and hasBrother(?x2,?x3) ==> hasUncle(?x1,?x3)

In the abstract syntax the rule would be written like:

Implies(Antecedent(hasParent(I-variable(x1) I-variable(x2)) hasBrother(I-variable(x2) I-variable(x3))) Consequent(hasUncle(I-variable(x1) I-variable(x3))))

From this rule, if John has Mary as a parent and Mary has Bill as a brother then John has Bill as an uncle.

In RuleML it is:

<ruleml:imp> <ruleml:_rlab ruleml:href="#example1"/> <ruleml:_body> <swrlx:individualPropertyAtom swrlx:property="hasParent"> <ruleml:var>x1</ruleml:var> <ruleml:var>x2</ruleml:var> </swrlx:individualPropertyAtom> <swrlx:individualPropertyAtom swrlx:property="hasBrother"> <ruleml:var>x2</ruleml:var> <ruleml:var>x3</ruleml:var> </swrlx:individualPropertyAtom> </ruleml:_body> <ruleml:_head> <swrlx:individualPropertyAtom swrlx:property="hasUncle"> <ruleml:var>x1</ruleml:var> <ruleml:var>x3</ruleml:var> </swrlx:individualPropertyAtom> </ruleml:_head> </ruleml:imp>

In Prolog it is:

hasUncle(X1, X3):-

hasParent(X1, X2), hasBrother(X2, X3).

### Comparison: Semantics of Semantic Web and Symbolic Analysis

Some differences between the Semantic Web policy and the one of Symbolic Analysis.

Atom | Condition on Interpretation |
---|---|

C(x) | S(x) ∈ EC(C) |

D(z) | S(z) ∈ EC(D) |

P(x,y) | <S(x),S(y)> ∈ ER(P) |

Q(x,z) | <S(x),L(z)> ∈ ER(Q) |

sameAs(x,y) | S(x) = S(y) |

differentFrom(x,y) | S(x) ≠ S(y) |

builtIn(r,z1,…,zn) | <S(z1),…,S(zn)> ∈ D(f) |

In Symbolic Analysis all definitions are clauses. The clause has its Prolog-based syntax, being a fact. However, the principles and the main goal have many similar features.

**Some links**

## OBS:

Atom is a system for distribution of information on the web (see http://semtext.org/atom/atom-semweb.htm). It is also a project that aims to create weblog and syndication formats and APIs that the developers can unite behind, allowing future progress in these fields without the political and technical problems that have plagued developers over recent years. The project was initiated by Sam Ruby, and is being developed collaboratively on a Wiki.

Computation is a step in the computer, here in the atomistic model, which evaluates one term of the model, at a time.

See the definition at Wiki: Computationis a general term for any type of information processing. This includes phenomena ranging from human thinking to calculations with a more narrow meaning. Computation is a process following a well-defined model that is understood and can be expressed in an algorithm, protocol, network topology, etc. Computation is also a major subject matter of computer science: it investigates what can or cannot be done in a computational manner.

Each computation, which traverses an atomistic model is a step in the corresponding automaton.

FIGURE 6.

A computation can be either a transformer or an acceptor (see autoamata theory).

The formalism of a register machine regarding a single source code element, which is the foundation for the ModelWare approach, is especially

interesting (FIGURE 6). If the logic of each element can be defined by a single structure, in the figure f, which has a number of arguments m1 to mk, then it is

possible to build an abstract machine for each mathematical function to execute the corresponding computation.

This computation model is useful for any deterministic expression. It is useful for any logic expression, too. This formalism can be extended to cover the

whole syntax of programming languages. However, there are some exceptions and problems in modeling logic paths and real-time programs. The

Entscheidungsproblem (Turing, 1936) is a well-known example; it indicates that it is not possible to show that any freely selected program with a given set of

inputs consisting of arguments m1…mk could terminate and produce a certain output value n.