SWRL Tutorial - Spring 2009

SEMANTIC WEB RULE LANGUAGE
(SWRL)
BY AMNA BASHARAT
FAST – NU (SPRING 2009)
Adapted by Martin O’Connor
Stanford Medical Informatics, Stanford University
FAST -NU Spring 2009 - Amna Basharat 1
Outline
Rules and the Semantic Web: OWL +

SWRL
SWRLTab: a Protégé-OWL
development environment for SWRL
Knowledge-driven Querying
Relation-to-OWL mapping

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.

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.

SWRL EXAMPLE

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

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.

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.
EXECUTION OF SWRL RULES
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
(4)
New FACTS
INSTANCES RULES

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 RULE ENGINE BRIDGE
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.

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 AND QUERYING

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!

QUERYING AND DATABASES

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

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
KB Bridge Engine
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

GROUP EXERCISE
CUM
GROUP QUIZ

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 - Spring 2009

Uploaded by

Document Information

Original Description:

Original Title

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 - Spring 2009

Uploaded by

Copyright:

Available Formats

SEMANTIC WEB RULE LANGUAGE

Rules and the Semantic Web: OWL +

FAST -NU Spring 2009 - Amna Basharat 2

FAST -NU Spring 2009 - Amna Basharat 3

The OWL reasoning tools are mostly related

FAST -NU Spring 2009 - Amna Basharat 4

Engineering: Diagnosis rules

FAST -NU Spring 2009 - Amna Basharat 5

Effort to standardize inference rules.

FAST -NU Spring 2009 - Amna Basharat 6

SWRL is an acronym for Semantic Web Rule

FAST -NU Spring 2009 - Amna Basharat 7

Semantic Web Rule Language (SWRL)

SWRL = OWL-DL + RuleML

FAST -NU Spring 2009 - Amna Basharat 8

A rule language is needed for several

FAST -NU Spring 2009 - Amna Basharat 9

SWRL rules have the form of an implication between an

The intended meaning can be read as: whenever the

Both the antecedent (body) and consequent (head) consist

FAST -NU Spring 2009 - Amna Basharat 10

An empty antecedent is treated as trivially

An empty consequent is treated as trivially

Multiple atoms are treated as a conjunction

Summarizing, SWRL rules can be described

Typical SWRL reasoning occurs on property

FAST -NU Spring 2009 - Amna Basharat 12

FAST -NU Spring 2009 - Amna Basharat 13

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

FAST -NU Spring 2009 - Amna Basharat 14

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

FAST -NU Spring 2009 - Amna Basharat 15

FAST -NU Spring 2009 - Amna Basharat 16

W3C Submission in 2004:

FAST -NU Spring 2009 - Amna Basharat 17

FAST -NU Spring 2009 - Amna Basharat 18

FAST -NU Spring 2009 - Amna Basharat 19

A Protégé-OWL development environment

FAST -NU Spring 2009 - Amna Basharat 20

FAST -NU Spring 2009 - Amna Basharat 21

The SWRL Editor is an extension to Protégé-

FAST -NU Spring 2009 - Amna Basharat 22

The SWRL API provides a mechanism to

SWRLTab is a very convenient tool for

Need of a Rule Engine

FAST -NU Spring 2009 - Amna Basharat 28

FAST -NU Spring 2009 - Amna Basharat 29

The execution of SWRL rules requires the availability of

The most general picture of a rule engine :

Rules and facts should be available in a format that is

FAST -NU Spring 2009 - Amna Basharat 30

FAST -NU Spring 2009 - Amna Basharat 31

Translations that are necessary in the

FAST -NU Spring 2009 - Amna Basharat 33

FAST -NU Spring 2009 - Amna Basharat 34

SWRL JESS INTEGRATION

FAST -NU Spring 2009 - Amna Basharat 35

SWRL is a language specification

FAST -NU Spring 2009 - Amna Basharat 36

Given an OWL knowledge base it will extract

FAST -NU Spring 2009 - Amna Basharat 38

Jess is a Java-based rule engine.