Professional Documents
Culture Documents
Relational Databases
using OWL and SWRL
Martin O’Connor
Stanford Medical Informatics, Stanford University
Talk Outline
• Rules and the Semantic Web: OWL
+ SWRL
• SWRLTab: a Protégé-OWL
development environment for SWRL
• Knowledge-driven Querying
• Relation-to-OWL mapping
2
Semantic Web Stack
3
Rule-based Systems are common
in many domains
4
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
5
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).
6
Example SWRL Rule: Has
uncle
7
Example SWRL Rule with
Named Individuals: Has brother
8
Example SWRL Rule with Literals
and Built-ins: is adult?
9
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
10
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
11
SWRLTab: http://protege.cim3.net/cgi-bin/wiki.pl?SWRLTab
12
What is the SWRL Editor?
18
SWRL Rule Engine Bridge
GUI
OWL
KB SWRL Rule
Engine Bridge Rule Engine
+
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.
20
We used the 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.
21
24
25
26
28
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.
29
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.
30
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.
31
Example: defining stringEqualIgnoreCase
from Core SWRL Built-ins Library
32
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.*;
33
Example Implementation for Built-in
swrlb:stringEqualIgnoreCase
return argument1.equalsIgnoreCase(argument2);
} // stringEqualIgnoreCase
34
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.
35
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)
36
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.
37
A SWRL ‘Query’
38
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
• Will be available as part of Protégé-OWL
SWRLTab in a few weeks
41
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
42
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!
43
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
44
Querying and Databases
45
Querying and Databases
46
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
47
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
48
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
50
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
51
Built-in Optimization
52
Two Approaches