Computer Engineering Department Sharif University of Technology Rules in SW Semantic Web - Spring 2006 Computer Engineering Department Sharif University of Technology

Outline Introduction to the rules and their usage in Web RuleML SWRL Existing rule engines Jess jDrew

Introduction Rules as an important aspect of Internet e-business: rule-based business policies & business processes, for B2B & B2C. represent seller’s offerings of products & services, capabilities, bids; map offerings from multiple suppliers to common catalog. represent buyer’s requests, interests, bids; → matchmaking. represent sales help, customer help, procurement, authorization/trust, brokering, workflow. high level of conceptual abstraction; easier for non-programmers to understand, specify, dynamically modify & merge. executable but can treat as data, separate from code potentially ubiquitous; already wide: e.g., SQL views, queries. Rules in communicating applications, e.g., embedded intelligent agents.

Introduction (cont.) Rules are being used for many interconnected purposes, capturing regularities in application domains such as the following: Engineering: Diagnosis rules Commerce: Business rules (including XML versions such as the Business Rules Markup Language (BRML) of IBM's Business Rules for Electronic Commerce project) Law: Legal reasoning (Robert Kowalski and Marek Sergot have been formalizing legal rules in an Imperial College group) Internet: Access authentication (Tim Berners-Lee proposed registration engines that use authentication rules such as the following: Any person who was some time in the last 2 months an employee of an organization which was some time in the last 2 months a W3C member may register.)

Expert Systems… Are a branch of artificial intelligence. Simulate human reasoning in some domain. “Reason” by heuristic or approximate methods. Explain and justify solutions in user-friendly terms. A human expert must also explain how he/she arrived at a particular solution.

Types Of Expert Systems Neural Networks Blackboard Systems Belief (Bayesian) Networks Case-Based Reasoning Rule-Based Systems Neural Nets are the quintessential expert system of science fiction fame – Hal 9000 for example. Non-structured data redundantly linked via multiple paths and massively parallel processed by multiple CPUs. The Blackboard metaphor is an interesting approach that models a collection of domain experts all trying to solve a complex problem. Each expert module tries to solve parts of the problem specific to its domain. Belief (Bayesian) Networks were originally researched as an approach to modeling natural language. Use a probabilistic approach to finding solutions. Case-Based Reasoning uses pattern-matching mimicking the way humans recall previously previous problem solutions. Derived solutions are based on similarity to an existing solution that best fits the problem parameters. Successful solutions are integrated into the case-base. Example would be chess masters who recall patterns of previous games and stratagems rather than calculate from first principles. Rule-Based Systems are the oldest and most researched form of expert system architecture. They simulate the reasoning that human experts use to arrive at conclusions by using first principles or “rules of thumb” called heuristics.

Rule-Based Expert Systems Originated from AI research in the 70s and 80s. Problem data stored as facts. “Reason” using IF…THEN…ELSE rules. Can “reason” deductively (forward-chaining) or inductively (backward-chaining). The DENDRAL Project (1965-83) One of the earliest expert systems. DENDRAL began as an effort to explore the mechanization of scientific reasoning and the formalization of scientific knowledge by working within a specific domain of science, organic chemistry. Think of a fact as a “truth McNugget”. :-D

When to Use Rule-Based Systems Problem Domain = narrow, well-understood domain theory Knowledge Representation = facts and rules Output = recommendation Explanation = rule firing trace Learning Ability = generally no (but…) Problem domain: one of the usage problems with rule based systems is that you have to “know” the solution to the problem beforehand. In other words, a finite collection of facts must result in a particular, reproducible solution. The problem has to be solvable by reasoning along axioms or principles. The problem space needs to be quantifiable in terms of facts and the domain knowledge must be quantifiable in terms of rules. The output is in the form of a terse or verbose recommendation, the explanation of which is typically a trace of all the rules that fired. Now, most rule systems don’t have the capacity to autonomously “learn” as it solves problems (i.e., neural nets, case-based system can do this…by adding nodes or cases.) However, rule-based systems that use a decision-tree metaphor can simulate “learning” by adding nodes to the decision network. A classic example is the animal guessing program. (demo)

Inference Process Rules and facts compared using pattern matcher. Matched rules activated into a conflict set. Conflict set resolved into agenda (process called conflict resolution). Rule engine fires on agenda. Engine cycles until all rules are satisfied. The interesting thing is that rules can add, delete, or alter facts in the working memory. They can also call other code (Jess functions or Java methods) The rule engine fires only once on any given set of facts in working memory.

Rules in SW

Example rules The discount for a customer is 5.0 percent if the customer is premium and the product is regular A customer is premium if their spending has been min 5000 euro in the previous year Those who are members of CE can access CE portal

RuleML Rather than reinventing rule principles and markups in each community, the idea of RuleML is to 'package' the rule aspect of any domains make it available as an (XML) namespace, .../RuleML, can be mixed with a namespace for natural-language (XHTML) texts and possible domain-specific namespaces (much like MathML is mixed into such domain texts).

RuleML initiatives Dozens of institutions (~35), researchers; esp. in US, EU Mission: Enable semantic exchange of rules/facts between most commercially important rule systems Standards specification: 1st version 2001; basic now fairly stable A number of tools (~12 engines, translators, editors), demo applications Successful Workshop on Rules at ISWC was mostly about RuleML / LP Has now a “home” (www.ruleml.org) Initial Core: Horn Logic Programs KR …Webized (in markup)… and with expressive extensions

Type of rules possible in RuleML Derivation rules Deriving new facts Maybe evaluated bottom-up as in deductive databases Top-down as in Logic Programming Example: dynamic inclusion of derived facts in a html response Reaction rules Also called ECA (Event-Condition-Action) or Triggers Example: Specification of behavior in response to browser events

RuleML top-level hierarchy Integrity constraints are considered as "denials" or special reaction rules whose only possible kind of action is to signal inconsistency when certain conditions are fulfilled. Derivation rules are considered as special reaction rules whose action happens to only add or 'assert' a conclusion when certain conditions (premises) are fulfilled. Facts are considered as special derivation rules that happen to have an empty (hence, 'true') conjunction of premises.

Application direction General reaction rules can only be applied in the forward direction in a natural fashion, observing/checking events/conditions and performing an action if and when all events/conditions have been perceived/fulfilled. Integrity constraints are usually also forward-oriented, i.e. triggered by updates, mainly for efficiency reasons. Derivation rules, on the other hand, can be applied in the forward direction as well as in a backward direction, the latter reducing the proof of a goal (conclusion) to proofs of all its subgoals (premises). Since in different situations different application directions of derivation rules may be optimal (forward, backward, or mixed), RuleML does not prescribe any one of these. For facts or 'unit clauses' it makes little sense to talk of an application direction.

RuleML toturial Peter Miller's spending has been min 5000 euro in the previous year. <Atom> <Rel>spending</Rel> <Ind>Peter Miller</Ind> <Ind>min 5000 euro</Ind> <Ind>previous year</Ind> </Atom> This is a fact

RuleML toturial (cont.) "spending" is marked up as the relation name (table name) for the fact. "Peter Miller", "min 5000 euro", and "previous year" are marked up as individual constants that are the three arguments (table columns) of the relation. The entire relation application constitutes an atomic formula, marked up by <Atom> ... </Atom>.

Representing as tree

An example rule A customer is premium if their spending has been min 5000 euro in the previous year <Implies> <head> <Atom> <Rel>premium</Rel> <Var>customer</Var> </Atom> </head> <body> <Rel>spending</Rel> <Var>customer</Var> <Ind>min 5000 euro</Ind> <Ind>previous year</Ind> </body> </Implies>

In tree form

Non-atomic constructs The discount for a customer buying a product is 7.5 percent if the customer is premium and the product is luxury <Implies> <head> <Atom> <Rel>discount</Rel> <Var>customer</Var> <Var>product</Var> <Ind>7.5 percent</Ind> </Atom> </head> <body> <And> <Rel>premium</Rel> <Var>customer</Var> <Rel>luxury</Rel> </And> </body> </Implies>

OO RuelML Extension of RuleML in three dimensions: User-level roles is to allow ‘object-centered’ sets of role-filler slots – much like the role-type slots of classes and role-value slots of their instances; because of the unorderedness of slot sets, the inheritance of slots will be easier than that of ordered argument sequences. URI grounding is the provision of URIs as unique object identifiers (OIDs) for facts – much like instances – and for rules – much like methods. Order-sortedness is making taxonomies available as declarative inheritance pathways for term typing – much like class hierarchies.

Object centering via user-level roles In KR there has been two paradigms Position-keyed (predicate-centered or pKR):one predicate or relation symbol is focused, and applied to positionally. In Web it is implemented by languages based on XML (Parent is focused and Childs are accessed with positions) Role-keyed (object-centered or rKR): one object identifier is focused, and associated via property roles, unordered, with other objects as arguments. In Web it is implemented by languages based on RDF In RuleML version 0.8 a pKR-rKR-unifying data model that generalizes the data models of both XML and RDF to express clauses (facts and rules) is introduced It is based on differentiating type and role elements in XML, where role tags (distinguished by a leading underscore) accommodate RDF properties.

Example offer(Ecobile,special,20000) (pKR): <fact> <_rlab><ind>pKR fact 1</ind></_rlab> <_head> <atom> <_opr><rel>offer</rel></_opr> <ind>Ecobile</ind> <ind>special</ind> <ind>20000</ind> </atom> </_head> </fact> fact type has a head role associating it with an atom type. The atom, however, uses a role, opr, only for its operator association with the rel(ation) type. The three arguments of type ind(ividual) are immediate atom children ordered in the spirit of XML and pKR. Thus, while the opr role can be moved from the prefix position to a postfix position without changing its meaning, the ind types are semantically attached to their relative positions.

Example Now positions of the three arguments is not important. offer(name->Ecobile;category->special;price->20000) (rKR): <fact> <_rlab><ind>rKR fact 1</ind></_rlab> <_head> <atom> <_opr><rel>offer</rel></_opr> <_r n="name"><ind>Ecobile</ind></_r> <_r n="category"><ind>special</ind></_r> <_r n="price"><ind>20000</ind></_r> </atom> </_head> </fact> Now positions of the three arguments is not important. A processor doesn’t need to process them as an ordered tree. Having role names (e.g. name, category and price), a processor can process this rule without any concern on positions

Exmale: combining pKR and rKR offer(Ecobile, special, 20000; expiry->2003-12-31; region->North America). <fact> <_rlab><ind>prKR fact 1</ind></_rlab> <_head> <atom> <_opr><rel>offer</rel></_opr> <ind>Ecobile</ind> <ind>special</ind> <ind>20000</ind> <_r n="expiry"><ind>2003-12-31</ind></_r> <_r n="region"><ind>North America</ind></_r> </atom> </_head> </fact>

Example: Using variables Discount rule applies for customers of “gold” status and for offers in “special” category: discount(offer name->?off; customer name->?cust; awarded amount->10) :- offer(name->?off; category->special; price->_), customer(name->?cust; status->gold).

Example: Using variables (cont.) <imp> <_rlab> <ind>rKR rule 1</ind> </_rlab> <_head> <atom> <_opr> <rel>discount</rel> </_opr> <_r n="offer name"><var>off</var></_r> <_r n="customer name"> <var>cust</var> </_r> <_r n="awarded amount"><ind>10</ind></_r> </atom> </_head> <_body> <and> <atom> <_opr><rel>offer</rel></_opr> <_r n="name"><var>off</var></_r> <_r n="category"><ind>special</ind></_r> <_r n="price"><var/></_r> </atom> <_opr><rel>customer</rel></_opr> <_r n="name"><var>cust</var></_r> <_r n="status"><ind>gold</ind></_r> </and> </_body> </imp>

URI Grounding

Term Typing via Ordered Sorted Taxonomies

Term Typing via Ordered Sorted Taxonomies

OWL extension for rules (SWRL) A recommendation to extend OWL to create a Rule language

The Java Expert System Shell Developed at Sandia National Laboratories in late 1990s. Created by Dr. Ernest J. Friedman-Hill. Inspired by the AI production rule language CLIPS. Fully developed Java API for creating rule-based expert systems. Jess came along when Java was very young! According to Dr. Friedman-Hill, Jess was nearly implemented in a hacked kind of C! CLIPS was developed by the Johnson Space Center at NASA in the early 80s. BTW - There is also an Object-Oriented version of CLIPS called COOL (CLIPS Object Oriented Language)

Rule-Based Expert System Architecture Rule Base (knowledge base) Working Memory (fact base) Inference Engine (rule engine) This is the typical architecture common to rule-based systems.

Inference (Rule) Engines Pattern Matcher – decides what rules to fire and when. Agenda – schedules the order in which activated rules will fire. Execution Engine – responsible for firing rules and executing other code. This mechanism underscores a key difference between procedural programming and declarative programming.

How Does Jess Work? Jess matches facts in the fact base to rules in the rule base. The rules contain function calls that manipulate the fact base and/or other Java code. Jess uses the Rete (ree-tee) algorithm to match patterns. Rete network = an interconnected collection of nodes = working memory. So this is an overview of how Jess operates.

Jess Architecture Diagram WORKING MEMORY INFERENCE ENGINE EXECUTION ENGINE PATTERN MATCHER RULE BASE Here you can see how all the parts fit together. AGENDA

jDREW an easily configured, powerful deductive reasoning engine for clausal first order logic (facts and rules) Knowledge-based systems to process the declarative information and rules can use jDREW as an embedded reasoning engine through its various application programmer's interfaces (APIs). jDREW can be easily deployed as part of a larger Java system, on a server or, with its small memory footprint, on a client. jDREW was designed to be flexible also in its capabilities; It currently provides modules to process rules in Prolog and RuleML format.

A sample applet

References http://www.semanticweb.org/SWWS/program/full/paper20.pdf RuleML.org http://www.semanticweb.org/SWWS/program/full/paper20.pdf http://www.cs.man.ac.uk/~horrocks/DAML/Rules/ http://www.cs.unb.ca/~boley/ruleml/ruleml-rgs.pdf http://herzberg.ca.sandia.gov/jess/ http://www.jdrew.org/jDREWebsite/jDREW.html

The End