SWRL Tutorial 01
-
Upload
api-19981384 -
Category
Documents
-
view
145 -
download
8
Transcript of SWRL Tutorial 01
Adapted by Martin O’ConnorStanford Medical Informatics, Stanford University
FAST – NU, Islamabad, Fall 2008 2
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 3
Semantic Web Stack
FAST – NU, Islamabad, Fall 2008
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 5
Rule-based Systems are common in many domains
Engineering: Diagnosis rules Commerce: Business rules Law: Legal reasoning Medicine: Eligibility, Compliance Internet: Access authentication
FAST – NU, Islamabad, Fall 2008 6
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
FAST – NU, Islamabad, Fall 2008 7
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).
FAST – NU, Islamabad, Fall 2008
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.
FAST – NU, Islamabad, Fall 2008
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
FAST – NU, Islamabad, Fall 2008
SWRL Rule Format (1)
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.
Head
(Consequent)
Body
(Antecedant)
FAST – NU, Islamabad, Fall 2008
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
FAST – NU, Islamabad, Fall 2008
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.
FAST – NU, Islamabad, Fall 2008
Example SWRL Rule: Has uncle
14
hasParent(?x, ?y) ^ hasBrother(?y, ?z)
→ hasUncle(?x, ?z)
FAST – NU, Islamabad, Fall 2008 15
Example SWRL Rule with Named Individuals: Has brother
Person(Fred) ^ hasSibling(Fred, ?s) ^ Man(?s) → hasBrother(Fred, ?s)
FAST – NU, Islamabad, Fall 2008
Example SWRL Rule with Literals and Built-ins: is adult?
Person(?p) ^ hasAge(?p,?age) ^ swrlb:greaterThan(?age,17)
→ Adult(?p)
16
FAST – NU, Islamabad, Fall 2008 17
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
FAST – NU, Islamabad, Fall 2008
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.
FAST – NU, Islamabad, Fall 2008 20
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
FAST – NU, Islamabad, Fall 2008
SWRLTab: http://protege.cim3.net/cgi-bin/wiki.pl?SWRLTab
21
FAST – NU, Islamabad, Fall 2008 22
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
FAST – NU, Islamabad, Fall 2008
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.
26
FAST – NU, Islamabad, Fall 2008
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
FAST – NU, Islamabad, Fall 2008
Including SWRL Data in Protege
INSTANCES RULES
CLASSES
AP
PL
ICA
TIO
N
SW
RL
Ontology
Knowledge
Base
FAST – NU, Islamabad, Fall 2008
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.
FAST – NU, Islamabad, Fall 2008
Rule Engine Execution
RULES
FACTS
RULE ENGINE
New FACTS
FAST – NU, Islamabad, Fall 2008
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).
FAST – NU, Islamabad, Fall 2008
Actions for Execution of SWRL Rules based on Protégé Input
INSTANCES RULES
CLASSES
AP
PL
ICA
TIO
N
SW
RL
Ontology
Knowledge
Base
RULES
FACTS
RULE
ENGINE
New FACTS
(1)
(2)
(4)
(3)
FAST – NU, Islamabad, Fall 2008
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
FAST – NU, Islamabad, Fall 2008
Executing SWRL Rules
SWRL is a language specification Well-defined semantics Developers must implement
engine Or map to existing rule engines Hence, a bridge…
36
FAST – NU, Islamabad, Fall 2008
OWL
KB
+
SWRL
SWRL Rule
Engine Bridge
Data
Knowledge
Rule Engine
GUI
SWRL Rule Engine Bridge
FAST – NU, Islamabad, Fall 2008 38
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.
FAST – NU, Islamabad, Fall 2008
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.
39
FAST – NU, Islamabad, Fall 2008
42
43
44
46
FAST – NU, Islamabad, Fall 2008
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.
47
FAST – NU, Islamabad, Fall 2008 49
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.
FAST – NU, Islamabad, Fall 2008 50
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.
FAST – NU, Islamabad, Fall 2008 51
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
FAST – NU, Islamabad, Fall 2008
Example Implementation Class for Core SWRL Built-in Methods
52
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
FAST – NU, Islamabad, Fall 2008
Example Implementation for Built-in swrlb:stringEqualIgnoreCase
53
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
FAST – NU, Islamabad, Fall 2008 54
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.
FAST – NU, Islamabad, Fall 2008
Using SWRL to Express Protocol Constraints
55
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)
On days that both immunotherapy and omalzumab are administered,
omalzumab must be injected 60 minutes after immunotherapy.
FAST – NU, Islamabad, Fall 2008 57
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.
FAST – NU, Islamabad, Fall 2008 58
A SWRL ‘Query’
Person(?p) ^ hasAge(?p, ?age) ^ swrlb:greaterThan(?age, 17) -> swrlq:select(?p) ^ swrlq:orderBy(?age)
Return all adults in ontology:
FAST – NU, Islamabad, Fall 2008
SWRLQueryTab
FAST – NU, Islamabad, Fall 2008
SWRLQueryTab: Displaying Results
FAST – NU, Islamabad, Fall 2008 61
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
FAST – NU, Islamabad, Fall 2008
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
62
FAST – NU, Islamabad, Fall 2008 63
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!
FAST – NU, Islamabad, Fall 2008 65
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
FAST – NU, Islamabad, Fall 2008
Querying and Databases
66
FAST – NU, Islamabad, Fall 2008 67
Querying and Databases
FAST – NU, Islamabad, Fall 2008 68
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
FAST – NU, Islamabad, Fall 2008 69
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
Mapper
OWL
KB Bridge
User Interface
Data
Knowledge
Engine
FAST – NU, Islamabad, Fall 2008 71
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
FAST – NU, Islamabad, Fall 2008 72
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
FAST – NU, Islamabad, Fall 2008 73
Built-in Optimization
Person(?p) ^ hasAge(?p, ?age) ^ swrlb:greaterThan(?age, 17) -> swrlq:select(?p) ^ swrlq:orderBy(?age)
FAST – NU, Islamabad, Fall 2008 74
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
FAST – NU, Islamabad, Fall 2008 75
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?
FAST – NU, Islamabad, Fall 2008 76
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
FAST – NU, Islamabad, Fall 2008
Part A
Describe the Need for a Rule Engine
Describe the Generic Execution Procedure of Rules using a Rule Engine.
FAST – NU, Islamabad, Fall 2008
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
FAST – NU, Islamabad, Fall 2008
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?