SWRL Tutorial 01

Adapted by Martin O’Connor
Stanford Medical Informatics, Stanford

University
Outline
 Rules and the Semantic Web: OWL

+ SWRL
 SWRLTab: a Protégé-OWL
development environment for
SWRL
 Knowledge-driven Querying
 Relation-to-OWL mapping
FAST – NU, Islamabad, Fall 2008 2

Semantic Web Stack

Limitations in OWL
 The OWL reasoning tools are mostly related

to classes and classification.
 OWL reasoning is able to compute all the
property values that are implied by the
property characteristic.
 In OWL it is not possible to establish that a
person is the boss of a secretary, only that
the person is a boss.
FAST – NU, Islamabad, Fall 2008

Rule-based Systems are common
in many domains
 Engineering: Diagnosis rules

 Commerce: Business rules
 Law: Legal reasoning
 Medicine: Eligibility, Compliance
 Internet: Access authentication

Rule Markup (RuleML)
Initiative
 Effort to standardize inference rules.
 RuleML is a markup language for
publishing and sharing rule bases on
the World Wide Web.
 Focus is on rule interoperation between
industry standards.
 RuleML builds a hierarchy of rule
sublanguages upon XML, RDF, and OWL,
e.g., SWRL

What is SWRL?
 SWRL is an acronym for Semantic

Web Rule Language.
 SWRL is intended to be the rule
language of the Semantic Web.
 SWRL includes a high-level abstract
syntax for Horn-like rules.
 All rules are expressed in terms of
OWL concepts (classes, properties,
individuals).

SWRL: Combining Ontologies
and Rules
 Semantic Web Rule Language (SWRL)
 A proposal to combine ontologies
and rules:
 Ontologies: OWL-DL
 Rules: RuleML
 SWRL = OWL-DL + RuleML

 OWL-DL: variable free
 corresponding to SHOIN(D)
 RuleML: variables are used.

Why Do We Need a Rule
Language?
 A rule language is needed for
several reasons:
 The existing rule sets can be reused.
 Expressivity can be added to OWL
 Although expressivity always comes
with a price, i.e.Decidabilit
 It is easier to read and write rules
with a rule language.
 Rules are called syntactic sugar;
 True in some cases but not in all
situations
SWRL Rule Format (1)
Head Body
(Consequent) (Antecedant)
 SWRL rules have the form of an implication

between an antecedent (body) and
consequent (head).
 The intended meaning can be read as:

whenever the conditions specified in the
antecedent hold, then the conditions
specified in the consequent must also hold.
 Both the antecedent (body) and consequent

(head) consist of zero or more atoms.
SWRL Rule Format (2)
 An empty antecedent is treated as
trivially true (i.e. satisfied by every
interpretation), so the consequent must
also be satisfied by every interpretation;
 An empty consequent is treated as

trivially false (i.e., not satisfied by any
interpretation), so the antecedent must
also not be satisfied by any
interpretation.
 Multiple atoms are treated as a

conjunction

SWRL Rules : Summary
 Summarizing, SWRL rules can be

described as follows:
 antecedent → consequent
 in which the antecedent and
consequent consist of one or multiple
atoms.
 Typical SWRL reasoning occurs on

property and instance levels.

Example SWRL Rule: Has
uncle
hasParent(?x, ?y) ^ hasBrother(?y, ?z)

→ hasUncle(?x, ?z)

Example SWRL Rule with Named
Individuals: Has brother
Person(Fred) ^ hasSibling(Fred, ?s) ^ Man(?s) →

hasBrother(Fred, ?s)

Example SWRL Rule with Literals
and Built-ins: is adult?
Person(?p) ^ hasAge(?p,?age) ^
swrlb:greaterThan(?age,17)
→ Adult(?p)

SWRL Characteristics
 W3C Submission in 2004:
http://www.w3.org/Submission/SWRL
 Based on OWL-DL
 Has a formal semantics
 Rules saved as part of ontology
 Increasing tool support: Bossam,
R2ML, Hoolet, Pellet, KAON2,
RacerPro, SWRLTab
 Can work with reasoners

Combining OWL reasoning and
SWRL reasoning
 OWL has inference capabilities through the
OWL characteristics of properties, like
inversion, symmetry and transitivity.
 SWRL has inference capabilities through the
SWRL rules.
 In order to avoid the necessity of iteration
between OWL inferences and SWRL
inferences, it would be good if rule engines
could also apply the OWL characteristics.
 This implies that OWL characteristics would
be ‘translated’ to a SWRL equivalent.
 In SWRL it is perfectly possible to define
rules for symmetry, inversion, or transitivity
characteristics.

SWRLTab
 A Protégé-OWL development
environment for working with
SWRL rules
 Supports editing and execution of
rules
 Extension mechanisms to work
with third-party rule engines
 Mechanisms for users to define
built-in method libraries
 Supports querying of ontologies
SWRLTab:
http://protege.cim3.net/cgi-
bin/wiki.pl?SWRLTab

What is the SWRL Editor?
 The SWRL Editor is an extension to

Protégé-OWL that permits the
interactive editing of SWRL rules.
 The editor can be used to create
SWRL rules, edit existing SWRL
rules, and read and write SWRL
rules.
 It is accessible as a tab within
Protégé-OWL.
23
24
25
SWRL Java API
 The SWRL API provides a mechanism to create
and manipulate SWRL rules in an OWL
knowledge base.
 This API is used by the SWRL Editor. However,
it is accessible to all OWL Plugin developers.
 Third party software can use this API to work
directly with SWRL rules and integrate rules
into their applications
 Fully documented in SWRLTab Wiki.

Limitations of
SWRLTab/Protégé
 SWRLTab is a very convenient tool
for editing SWRL rules since it
supports automatic completion of
the properties and class names and
checks the syntax of the entered
rules.
 Rules are considered as instance
data in Protégé.
 Protégé, even in the combination
with SWRLTab, does not support
SWRL rule execution.
Need of a Rule Engine
Including SWRL Data in
Protege
CLASSES
APPLICATION
Ontology
SWRL
Knowledge
Base
INSTANCES RULES

Need for Rule Engine
 The execution of SWRL rules requires the
availability of a rule engine.
 The most general picture of a rule engine :

 The rule engine can perform reasoning using a set
of rules and a set of facts as input.
 Any new facts that are inferred are used as input to
potentially fire more rules (in forward chaining).
 Rules and facts should be available in a

format that is accessible to the rule engine.

Rule Engine Execution
RULES
RULE ENGINE
FACTS
New
FACTS

Provision of Rules to Rule
Engines
 Translations that are necessary in the
current state-of-the-art to be able to run
SWRL rules on a Protégé data set.
 The rules have to be translated and introduced
in the rule engine (1).
 Afterwards, the ontology and the knowledge
base have to be translated and introduced into
the rule engine (2).
 After reasoning (3),
 the results of the reasoning should be
translated back into the Protégé format (4).

Actions for Execution of SWRL
Rules based on Protégé Input
(3)
CLASSES
APPLICATION
RULES
Ontology
(1)
SWRL
RULE
Knowledge (2) ENGINE
FACTS
Base
INSTANCE (4) New
S RULES FACTS

Reasoning Methods
 the two reasoning methods are forward
chaining and backward chaining.
 Forward Chaining
 In forward chaining, the input and input changes
are used to select the rules that need to be fired,
 and the inferred changes are treated as input
changes (so they can lead to the firing of rules,
too).
 Backward Chaining
 In backward chaining an assertion is put or a query
is set and the rule engine reasons back to the
conditions, implied by the assertion or the query,
that need to be applied to the data.
 The rule engine returns an answer to the assertion
or to the query based on that data.

SWRL JESS INTEGRATION
Executing SWRL Rules
 SWRL is a language specification

 Well-defined semantics
 Developers must implement
engine
 Or map to existing rule engines
 Hence, a bridge…

SWRL Rule Engine
Bridge
GUI
OWL
KB SWRL Rule
Rule Engine
+ Engine Bridge
SWRL
Data
Knowledge
SWRL Rule Engine Bridge
 Given an OWL knowledge base it will extract SWRL

rules and relevant OWL knowledge.
 Also provides an API to assert inferred knowledge.
 Knowledge (and rules) are described in non Protégé-
OWL API-specific way.
 These can then be mapped to a rule-engine specific
rule and knowledge format.
 This mapping is developer’s responsibility.

Example: SWRL Bridge to
Integrate Jess Rule Engine with
Protégé-OWL
 Jess is a Java-based rule engine.
 Jess system consists of a rule
base, fact base, and an execution
engine.
 Available free to academic users,
for a small fee to non-academic
users
 Has been used in Protégé-based
tools, e.g., JessTab.

42
43
44
46
Outstanding Issues
 SWRL Bridge does not know about

all OWL constraints:
 Contradictions with rules possible!
 Consistency must be assured by the
user incrementally running a reasoner.
 Hard problem to solve in general.
 Integrated reasoner and rule engine
would be ideal.
 Possible solution with KAON2.

SWRL Built-in Bridge
 SWRL provides mechanisms to add user-defined

predicates, e.g.,
 hasDOB(?x, ?y) ^ temporal:before(?y, ‘1997’)…
 hasDOB(?x, ?y) ^ temporal:equals(?y, ‘2000’)…
 These built-ins could be implemented by each rule engine.
 However, the SWRL Bridge provides a dynamic loading
mechanism for Java-defined built-ins.
 Can be used by any rule engine implementation.

Defining a Built-in in
Protégé-OWL
 Describe library of built-ins in OWL

using definition of swrl:Builtin
provided by SWRL ontology.
 Provide Java implementation of
built-ins and wrap in JAR file.
 Load built-in definition ontology in
Protégé-OWL. Put JAR in plugins
directory.
 Built-in bridge will make run-time
links.
Example: defining stringEqualIgnoreCase from
Core SWRL Built-ins Library
 Core SWRL built-ins defined by:

 http://www.w3.org/2003/11/swrlb
 Provides commonly needed built-
ins, e.g., add, subtract, string
manipulation, etc.
 Normally aliased as ‘swrlb’.
 Contains definition for
stringEqualIgnoreCase

Example Implementation
Class for Core SWRL Built-in
Methods
package edu.stanford.smi.protegex.owl.swrl.bridge.builtins.swrlb;
import edu.stanford.smi.protegex.owl.swrl.bridge.builtins.*;
import edu.stanford.smi.protegex.owl.swrl.bridge.exceptions.*;
public class SWRLBuiltInMethodsImpl implements SWRLBuiltInMethods

{
public boolean stringEqualIgnoreCase(List arguments) throws BuiltInException { ... }
....
} // SWRLBuiltInMethodsImpl

Example Implementation for Built-
in swrlb:stringEqualIgnoreCase
private static String SWRLB_SEIC = "stringEqualIgnoreCase";
public boolean stringEqualIgnoreCase(List arguments) throws BuiltInException

{
SWRLBuiltInUtil.checkNumberOfArgumentsEqualTo(SWRLB_SEIC, 2, arguments.size());
String argument1 = SWRLBuiltInUtil.getArgumentAsAString(SWRLB_SEIC, 1, arguments);

String argument2 = SWRLBuiltInUtil.getArgumentAsAString(SWRLB_SEIC, 2, arguments);
return argument1.equalsIgnoreCase(argument2);
} // stringEqualIgnoreCase

Invocation from Rule
Engine
 Use of swrlb:stringEqualIgnoreCase in
rule should cause automatic
invocation.
 SWRL rule engine bridge has an
invocation method.
 Takes built-in name and arguments
and performs method resolution,
loading, and invocation.
 Efficiency a consideration: some
methods should probably be
implemented natively by rule
engine, e,g., add, subtract, etc.
Using SWRL to Express Protocol
Constraints
On days that both immunotherapy and
omalzumab are administered,
omalzumab must be injected 60 minutes
after immunotherapy.
Patient(?p) ^
hasExtendedEvent(?p, ?eevent1) ^ hasExtendedEvent(?p, ?eevent2) ^ temporal:hasValue(?
eevent1, ?event1) ^ temporal:hasValidTime(?eevent1, ?event1VT) ^ temporal:hasTime(?
event1VT, ?event1Time) ^ temporal:hasValue(?eevent2, ?event2) ^
temporal:hasValidTime(?eevent2, ?event2VT) ^ temporal:hasTime(?event2VT, ?event2Time) ^
hasVisit(?event1, ?v1) ^ hasVisit(?event2, ?v2) ^
hasActivity(?event1, ?a1) ^ hasName(?a1, "Omalizumab") ^
hasActivity(?event2, ?a2) ^ hasName(?a2, "Immunotherapy") ^
temporal:before(?event2Time, ?event1Time) ^
temporal:durationMinutesLessThan(60, ?event2Time, ?event1Time)
-> NonConformingPatient(?p)
SWRL and Querying
 SWRL is a rule language, not a

query language
 However, a rule antecedent can
be viewed as a pattern matching
specification, i.e., a query
 With built-ins, language
compliant query extensions are
possible.

A SWRL ‘Query’
Return all adults in ontology:
Person(?p) ^ hasAge(?p, ?age) ^ swrlb:greaterThan(?age, 17)

-> swrlq:select(?p) ^ swrlq:orderBy(?age)

SWRLQueryTab

SWRLQueryTab:
Displaying Results

SWRLQueryTab
 Query functionality added with

built-ins
 Interactive query execution with
tabular results display
 Low-level JDBC-like API for use in
embedded applications
 Can use any existing rule engine
back end

Use of SWRL as Query Language
is Attractive
 Cleaner semantics than SPARQL

 OWL-based, not RDF-based
 Very extensible via built-ins, e.g.,
temporal queries using temporal
built-ins
 Can work with reasoners

Querying: Semantic Issues
 Syntactic SWRL conformance is

easy
 However, SWRL is based on OWL-
DL so assumes open world
semantics
 Querying closes the world, e.g.,
how many adults in ontology?
 Should not make inferences
based on query results –
nonmonotonicity!
Dealing with Relational
Data
 Almost all data are relational
 Relational queries are at the
database level not at the knowledge
level
 We would like results of queries and
analyses to be added to our store of
knowledge
 We need to bridge the gap
 Triple stores a longer term solution

Querying and
Databases

Querying and
Databases

Model Mismatch
 Relational n-ary tuples vs. RDF-triples

 Relational databases can store a lot of
knowledge; typically they don’t
 Some mappings can be inferred
 The more normalized the database, the
easier it is to infer mappings
 Manual user-driven mapping is usually
required

Solution Requirements
 A schema ontology to describe

schema of arbitrary relational
database
 A mapping ontology to describe
mapping of data from tuples to
triples
 Mapping software to dynamically
map
 A query language
 A query engine
User Interface
OWL
Bridge Engine
KB
Mapper
Data
Knowledge
Dynamic Relation-to-OWL
Mapping
 Bridge generates optimized
relational queries to retrieve data
 Current SPARQL-based systems
 D2RQ
 D2OMapper
 Approach used successfully in
BioSTORM project for surveillance
data

Optimization
 Current ontology tools not

scalable
 Databases are scalable: – offload
as much work to RDBMS as
possible
 Query engines must optimize
 Built-ins are a difficulty and an
opportunity

Built-in Optimization
Person(?p) ^ hasAge(?p, ?age) ^ swrlb:greaterThan(?age, 17)

-> swrlq:select(?p) ^ swrlq:orderBy(?age)

Two Approaches
 Built-in optimization by
annotating built-in definitions
and exploiting in query engine
 Numerical built-in optimizations
 Temporal built-in optimizations
 In-query optimization to avoid
redundant data requests
 Jess with Java Fact Storage Provider
Framework

Rule/Query Distinction
 Significant optimizations possible for

a queries
 Optimizations for entire rule bases
not as dramatic – however, still
possible, e.g.,
 Analyzing temporal ‘slices’
 Analyzing spatial regions
 Dealing with reasoners
 Database updates?

Lessons learned so far
 SWRL provides a useful though not
magical increase in expressivity
 Suited well to some tasks, not to others
 Can work well as a query language
 Built-ins provide a very nice way to
increase expressivity
 Triple-stores are a longer term solution,
but dealing with relational data now is
crucial

Part A
 Describe the Need for a Rule

Engine
 Describe the Generic Execution
Procedure of Rules using a Rule
Engine.

Design Rules for your
Domain
 For your project:
 Describe using Pseudo-code, some
essential Rules
 Describe using SWRL syntax, the
same Rules
 Two Rules must contain the use of
Swrl built-ins
 Verify if the Rules are consistent
with your OWL Definitions and
Constraints

Essential Readings on
SWRL
 Supporting Rule System
Interoperability on the Semantic
Web with SWRL
 Martin O’Connor1, Holger
Knublauch1, Samson Tu1, Benjamin
Grosof2, Mike Dean3, William
Grosso4, Mark Musen1
 Semantic Web Tutorial –Vahid
2008
 How to Make SWRL Rules Safe?

SWRL Tutorial 01

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SWRL Tutorial 01

Uploaded by

Copyright:

Available Formats

Adapted by Martin O’Connor

Stanford Medical Informatics, Stanford

 Rules and the Semantic Web: OWL

FAST – NU, Islamabad, Fall 2008 2

FAST – NU, Islamabad, Fall 2008 3

 The OWL reasoning tools are mostly related

FAST – NU, Islamabad, Fall 2008

 Engineering: Diagnosis rules

FAST – NU, Islamabad, Fall 2008 5

FAST – NU, Islamabad, Fall 2008 6

 SWRL is an acronym for Semantic

FAST – NU, Islamabad, Fall 2008 7

 SWRL = OWL-DL + RuleML

FAST – NU, Islamabad, Fall 2008

 SWRL rules have the form of an implication

 The intended meaning can be read as:

 Both the antecedent (body) and consequent

 An empty consequent is treated as

 Multiple atoms are treated as a

FAST – NU, Islamabad, Fall 2008

 Summarizing, SWRL rules can be

 Typical SWRL reasoning occurs on

FAST – NU, Islamabad, Fall 2008

hasParent(?x, ?y) ^ hasBrother(?y, ?z)

FAST – NU, Islamabad, Fall 2008 14

Person(Fred) ^ hasSibling(Fred, ?s) ^ Man(?s) →

FAST – NU, Islamabad, Fall 2008 15

FAST – NU, Islamabad, Fall 2008 16

FAST – NU, Islamabad, Fall 2008 17

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008 21

 The SWRL Editor is an extension to

FAST – NU, Islamabad, Fall 2008 26

FAST – NU, Islamabad, Fall 2008

 The most general picture of a rule engine :

 Rules and facts should be available in a

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

FAST – NU, Islamabad, Fall 2008

 SWRL is a language specification

FAST – NU, Islamabad, Fall 2008 36

 Given an OWL knowledge base it will extract SWRL

FAST – NU, Islamabad, Fall 2008 38

FAST – NU, Islamabad, Fall 2008 39

 SWRL Bridge does not know about

FAST – NU, Islamabad, Fall 2008 47

 SWRL provides mechanisms to add user-defined

FAST – NU, Islamabad, Fall 2008 49

 Describe library of built-ins in OWL

 Core SWRL built-ins defined by:

FAST – NU, Islamabad, Fall 2008 51

public class SWRLBuiltInMethodsImpl implements SWRLBuiltInMethods

FAST – NU, Islamabad, Fall 2008 52

private static String SWRLB_SEIC = "stringEqualIgnoreCase";

public boolean stringEqualIgnoreCase(List arguments) throws BuiltInException

String argument1 = SWRLBuiltInUtil.getArgumentAsAString(SWRLB_SEIC, 1, arguments);

FAST – NU, Islamabad, Fall 2008 53

 SWRL is a rule language, not a

FAST – NU, Islamabad, Fall 2008 57

Return all adults in ontology:

Person(?p) ^ hasAge(?p, ?age) ^ swrlb:greaterThan(?age, 17)