Scribd
Upload
55 views

Module 3

This document provides an overview of the Datalog query language. It begins with definitions of key terminology used in Datalog, such as variables, constants, facts, and rules. It then gives examples of how to write Datalog rules and queries to retrieve information from a database. The document also discusses important Datalog concepts like safety and recursion. Overall, it serves as a good introduction to the basics of the Datalog language.

Uploaded by

Viji Rajendran
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
55 views

Module 3

This document provides an overview of the Datalog query language. It begins with definitions of key terminology used in Datalog, such as variables, constants, facts, and rules. It then gives examples of how to write Datalog rules and queries to retrieve information from a database. The document also discusses important Datalog concepts like safety and recursion. Overall, it serves as a good introduction to the basics of the Datalog language.

Uploaded by

Viji Rajendran
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 167

Module 3

Semantic Web
• Rule Languages
o Introduction
o Usage Scenarios for Rule Languages
o Datalog
o RuleML
o SWRL
o TRIPLE. 
• Semantic Web Services
o Introduction
o Web Service Essentials
o OWL-S Service Ontology
o An OWL-S Example.
What is Datalog?

Datalog is a nonprocedural query language based


on the logic-programming language Prolog.
A user describes the information desired without
giving a specific procedure for obtaining that
information.
Datalog simplifies writing simple queries and
makes query optimization easier.
Terminology
Variable
A variable is like a variable in a mathematical equation, it represents
some constant that has yet to be determined.
By convention variables always start with an upper case letter,
e.g., City, Firstname,Code, A, B, C, etc
Constant
A constant is an attribute value.
By convention all constants begin with lower-case letters such as:
sammy, joe, xxy2003, etc
fact
A fact is the same things a tuple in a relation. A fact has the following
structure. (called Ground facts, because there are no variables)
<predicate name>(<list of constants>)
Rules
A rule is a way to derive new facts. It is part of a query.
enrolledIn
JOE CP2001

SUE CP2001

JOE CP2003

The major difference in the representation is that in the Datalog facts


the attributes are not named. So there is nothing to tell us that the first
attribute is a Name and the second is a Code.

Example: Facts about student enrollment:


The following set of facts shows some students and the subjects in
which they are enrolled.
enrolledIn(joe, cp2001)
enrolledIn(sue, cp2001)
enrolledIn(joe, cp2003).
In relational database terms, it would be the same as the following
relation. enrolledIn
Syntax of Datalog Rules
A rule has the following form
<head> :-<body>
Head is a single predicate and the body is a list of predicates. Each
predicate has the form
positive literal:
<relation name>(<list of constants or variables>)
negative literal:
not <relation name>(<list of constants or variables>)

What does :- mean?


Assume we have a rule: Q :- P
Then :- means, if P is true then Q is true
Example: A rule about students
The following rule identifies courses students are enrolled in.

result(Name, Code, Phone) :- student(Name, Phone), enrolledIn(Name, Code).

enrolledIn

student Name Code


joe CP2004
Name Phone
sue CP2001
joe 408-489-5454
joe CP2003

Test every combination of student and enrooledIn that unifies


student(joe,408-489-5454), enrolledIn(joe, CP2004)
student(joe,408-489-5454), enrolledIn(sue, CP2001)
student(joe,408-489-5454), enrolledIn(joe, CP2003)

Result:
result(joe, CP2004, 408-489-5454)
result(joe, CP2003, 408-489-5454)
Safety
It may be possible to write rules that generate an an infinite number of
answers. For example: employee(X,Y) :- X>Y
Since the relation defining > is infinite, this rule would generate an infinite
number of facts for the relation employee. Also the use of negation can cause
similar problems. For example: not-in-loan(L, B, A) :- not loan(L, B, A)
We want to retrieve all tuples that are not in the loan relation but if account
numbers, branch-name and balance is infinite then the relation not-in-loan
would also be infinite.
To avoid such problems Datalog rules are required to satisfy the following
safety conditions:

1. Every variable that appears in the head of the rule also appears in a non
arithmetic positive literal in the body of the rule
2. Every variable appearing in a negative literal in the body of the rule also
appears in some positive literal in the body of the rule.
Recursion in Datalog
Suppose now that we want to find out which employees are supervised,
directly or indirectly by a given manager, "Jones".
(1) People whose manager is "Jones"
(2) People whose manager is supervised by "Jones“
Ex. Tim manager is Jones
Kelly manager is Tim
employee-jones(X) :- manager(X, "Jones")
employee-jones(X) :- manager(X,Y), employee-jones(Y)
Procedure
I = set of facts in the database
repeat
Old_I = I
I = I U infer( R, I)
until I = Old_I
employee-jones(X) :- manager(X, "Jones")
employee-jones(X) :- manager(X,Y), employee-jones(Y)

manager relation
employee-name manager-name
Alon Barinsky
Barinsky Estovar
Corbin Duarte
Duarte Jones
Estovar Jones
Jones Klinger
Rensal Klinger

Iteration Tuples in employee-jones


0
1 (Duarte), (Estovar)
2 (Duarte), (Estovar), (Barinsky), (Corbin)
3 (Duarte), (Estovar), (Barinsky), (Corbin), (Alon)
4 (Duarte), (Estovar), (Barinsky), (Corbin), (Alon)
Relational Operations in Datalog

student(Name,StudentID)
courses(Cname, StudentID)

Relational Algebra: names = Πname(student)


Datalog Rule: names(Name) :- student(Name,_)

Relational Algebra: joeInfo = ΠstudentID(σname="joe"(student))


Datalog Rule: joeInfo(StudentID) :- student(joe,StudentID)

Relational Algebra: ΠcoursName(σname="joe"(student |><| courses))


Datalog Rule:
joeInfo(Name,Cname) :- student(joe, StudentID), courses(Cname, StudentID)
Examples
Relational Algebra: joeInfo = ΠstudentID(σname="joe", studentID > 25(student))
Datalog Rule: joeInfo(StudentID) :- student(joe,StudentID), StudentID > 25

Relational Algebra: ΠcName(courses) |><| Πname (student)


Datalog Rule:
joeInfo(Name,Cname) :- student(Name, StudentID), courses(Cname, StudentID)

Relational Algebra: ΠstudentID(σname "joe", studentID > 25(student))


Datelog Rule:
joeInfo(StudentID) :- student(Name,StudentID), StudentID > 25, Name <> joe
Meaning of Rules
• A variable appearing in the head is called
distinguished ; otherwise it is nondistinguished.
• Rule meaning: The head is true of the
distinguished variables if there exist values of
the nondistinguished variables that make all
subgoals of the body true.
– Distinguished variables are universally quantified
– Non-distinguished variables are existentially
quantified
13
Datalog Terminology: Atoms
• An atom is a predicate, or relation name with variables
or constants as arguments.
• The head is an atom; the body is the AND of one or
more atoms.
• Conventions:
– Databases: Predicates begin with a capital, variables begin
with lower-case. Example: P(x,’a’) where ‘a’ is a constant, i.e.,
a data item.
– Logic Programming: Variables begin with a capital, predicates
and constants begin with lower-case. Example: p(X,a).

14
Datalog
Terminology:
p  q, not r. or p :- q, not r.
is a rule, where p is the head, or conclusion, or
consequent, and q, not r is the body, or the
conditions, or the antecedent. p, q and r are atoms.

A rule without body, indicated as


p . or p.
Is called a unit rule, or a fact.

This kind of rules ale also called Horn Clauses.

15
Datalog
Terminology:
p  q, not r

Atoms in the body can be called subgoals. Atoms


which occur positively in the body are positive
literals, and the negations are negative literals.

We say that p depends on q and not r.

The same atom can occur in a rule both as a


positive literal, and inside a negative literal
(e.g. rule p  not p). 16
Datalog Programs

• A Datalog theory, or “program”, is a


collection of rules.
• In a program, predicates can be either
1. EDB = Extensional Database = facts.
2. IDB = Intensional Database = relation defined by
rules.

S. Costantini / Datalog 17
Datalog Theory, or Program: Example
p(X) r(X),q(X).
r(Z)  s(Z).
s(a).
s(b).
q(b).

• In every rule, each variable stands for the same


value.
• Thus, variables can be considered as
“placeholders” for values.
• Possible values are those that occur as constants
in some rule/fact of the program itself.

S. Costantini / Datalog 18
Datalog
Datalog Theory (or “Program”)
p(X) r(X),q(X).
r(Z)  s(Z).
s(a).
s(b).
q(b).

Its grounding can be obtained by:


• considering the constants, here a,b.
• substituting variables with constants in any possible
(coherent) way)
• E. g., the atom r(Z) is transformed by grounding
over constants a, b into the two ground atoms r(a),
r(b).
S. Costantini / Datalog 19
Grounding
p(X) r(X),q(X).
r(Z)  s(Z).
s(a).
s(b).
q(b).

• E. g., the atom r(Z) is transformed by grounding


over constants a, b into the two ground atoms r(a),
r(b).
• Rule r(Z)  s(Z). is transformed into the two rules
r(a)  s(a).
r(b)  s(b).

S. Costantini / Datalog 20
Datalog

Grounding of the program


p(a)  r(a),q(a).
p(b)  r(b),q(b).
r(a)  s(a).
r(b)  s(b).
s(a).
s(b).
q(b).

Semantics: Least Herbrand Model


M = {s(a),s(b),q(b),r(a),r(b),p(b)}

S. Costantini / Datalog 21
Datalog

A shortcut of the grounded program


p1  r1,q1.
p2  r2,q2.
r1  s1.
r2  s2.
s1.
s2.
q2.

M = {s1,s2,q2,r1,r2,p2}
S. Costantini / Datalog 22
Datalog semantics

• Without negation (no negative literal in the body of rules):


Least Herbrand Model
– The head of a rule is in the Least Herbrand Model only if the
body is in the Least Herbrand Model.
– The head of a rule is concluded true (or simply concluded) if all
literals in its body can be concluded.
– Equivalently, the head of a rule is derived if all literals in its body
can be derived.

• With negation: several proposals.


S. Costantini / Datalog 23
Least Herbrand Model: How to find it
p g,h.
g  r,s.
m  p,q.
r  f.
s.
f.
h.

Step 1: facts
M0 = {s,f,h}
Step 2: M1 = M0 plus what I can derive from facts
M1 = {s,f,h,r}
Step 3: M2 = M1 plus what I can derive from M1
M2 = {s,f,h,r,g}
Step 4: M3 = M2 plus what I can derive from M2
M3 = {s,f,h,r,g,p}
If you try to go on, no more added conclusions: fixpoint

S. Costantini / Datalog 24
Datalog and Transitivity
• Rule
in(X,Y):- part_of(X,Z),in(Z,Y)
defines in as the transitive closure of part_of

• In the example: Least Herbrand Model


{in(alan,r123), part_of(r123,cs_building),
in(alan,cs_building)}

S. Costantini / Datalog 25
Arithmetic Subgoals

• In addition to relations as predicates, a


predicate for a subgoal of the body can be an
arithmetic comparison.
– We write such subgoals in the usual way, e.g.: x <
y.

S. Costantini / Datalog 26
Example: Arithmetic

• A beer is “cheap” if there are at least two bars


that sell it for under $2.
cheap(Beer) :- sells(Bar1,Beer,P1),
sells(Bar2,Beer,P2), p1 < 2.00
p2 < 2.00, bar1 <> bar2

S. Costantini / Datalog 27
Negated Subgoals

• We may put not in front of a subgoal, to


negate its meaning.
• Example: Think of arc(a,b) as arcs in a
graph.
– s(X,Y) says that:
• there is a path of length 2 from X to Y
• but there is no arc from X to Y.
s(X,Y) :- arc(X,Z), arc(Z,Y), not arc(X,Y)

S. Costantini / Datalog 28
Negation
• Negation in Datalog is default negation:
– Let a be a ground atom, i.e., an atom where every
variable has a value.
– Assume that we are not able to conclude a.
– Then, we assume that not a holds.

• We conclude not a by using the Closed World


Assumption: all the knowledge we have is
represented in the program.
S. Costantini / Datalog 29
Safe Rules

• A rule is safe if:


1. Each distinguished variable,
2. Each variable in an arithmetic subgoal,
3. Each variable in a negated subgoal,
also appears in a nonnegated,
relational subgoal.
• We allow only safe rules.

S. Costantini / Datalog 30
Example: Unsafe Rules

• Each of the following is unsafe and not


allowed:
1. s(X) :- r(Y).
2. s(X) :- r(Y), not r(X).
3. s(X) :- r(Y), X < Y.
• In each case, too many x ’s can satisfy the
rule, in the first two rules all constants
occurring in the program. Meaningless!
S. Costantini / Datalog 31
Expressive Power of Datalog

• Without recursion, Datalog can express all


and only the queries of core relational
algebra (subset of P).
– The same as SQL select-from-where, without
aggregation and grouping.
• But with recursion, Datalog can express
more than these languages.
• Yet still not Turing-complete.
S. Costantini / Datalog 32
Recursion: Example
parent(X,Y):- mother(X,Y).
parent(X,Y):- father(X,Y).
ancestor(X,Y):- parent(X,Y).
ancestor(X,Y):- parent(X,Z),ancestor(Z,Y).
mother(a,b).
father(c,b).
mother(b,d).
… other facts …

• A parent X of Y is either a mother or a father (disjunction as


alternative rules);
• An ancestor is either a parent, or the parent of an ancestor (the
ancestor X of Y is the parent of some Z who in turn is an ancestor
of Y).

S. Costantini / Datalog 33
Stratified Negation

• Stratification is a constraint usually placed on


Datalog with recursion and negation.
• It rules out negation wrapped inside recursion.
• Gives the sensible IDB relations when negation
and recursion are separate.

S. Costantini / Datalog 34
Problematic Recursive Negation
p(X) :- q(X), not p(X)
q(1).
q(2).
Try to compute Least Herbrand Model:
Initial: M = {q(1),q(2) }
Round 1: M = {q(1), q(2), p(1), p(2)}
Round 2: M = {q(1),q(2) }
Round 3: M = {q(1), q(2), p(1), p(2)}, etc., etc. …
S. Costantini / Datalog 35
Strata
• Intuitively, the stratum of an IDB predicate P is
the maximum number of negations that can be
applied to an IDB predicate used in evaluating P.
• Stratified negation = “finite strata.”
• Notice in p(x) <- q(x), not p(x), we can negate p
an infinite number of times for deriving p(x) (loop
on its negation: p depend on not p that depends
on p that depends on not p…).
• Stratified negation: a predicate does not depend
(directly or indirectly) on its own negation.
S. Costantini / Datalog 36
Monotonicity

• If relation P is a function of relation Q (and


perhaps other relations), we say P is
monotone in Q if inserting tuples into Q
cannot cause any tuple to be deleted from
P.
• Examples:
– P = Q UNION R.
– P = SELECTa =10(Q ).
S. Costantini / Datalog 37
Nonmonotonicity

• Example:
usable(X):- tool(X), not broken(X).
tool(computer1).
tool(my_car).

Adding facts to broken can cause some tools to


be not usable any more.

S. Costantini / Datalog 38
Nonmonotonicity

• Example:
flies(X):- bird(X), not penguin(X).
bird(tweety).
Since we don’t know whether tweety it is a
penguin, we assume (by default negation) that
it is not a penguin.
Then we conclude that tweety flies.
If later we are told that tweety is a penguin, this
conclusion does not hold any more.
S. Costantini / Datalog 39
Datalog with negation (Datalog )

• How to deal with


– Unstratified negation
– Nonmonotonicity

• One possibility: don’t accept them

• Another possibility: extend the approach (e.g.,


Answer Set Semantics)
S. Costantini / Datalog 40
Datalog with negation (Datalog):
Answer Set Semantics
Inference engine: answer set solvers
 SMODELS, Dlv, DeRes, CCalc, NoMore,
etc.
interfaced with relational databases

Complexity: existence of a stable model NP-complete

Expressivity:
• all decision problems in NP and
• all search problems whose associated decision
problems are in NP

S. Costantini / Datalog 41
Introduction
• Rules are central to the Semantic Web
• Rule interchange in an open format
is important for e-Business
• RuleML is the de facto open language
standard for rule interchange/markup
• Collaborating with W3C (RIF), OMG (PRR, SBVR),
OASIS, DARPA-DAML, EU-REWERSE, and other
standards/gov'nt bodies

42
RuleML Enables ...
modelling
markup UML
translation RDF
Rule interchange in XML
execution ASCII
publication
archiving
43
RuleML Identifies ...
• Expressive sublanguages
– for Web rules
– started with
• Derivation rules: extend SQL views
• Reaction rules: extend SQL triggers
– to empower their subcommunities

44
RuleML Specifies ...
• Derivation rules via XML Schema:
– All sublanguages: (OO) RuleML 0.91
– First Order Logic: FOL RuleML 0.91
– With Ontology language: SWRL 0.7
• A Semantic Web Rule Language
Combining OWL (W3C) and RuleML
– With Web Services language: SWSL 0.9
• Translators in & out (e.g. Jess) via XSLT

45
Modular Schemas
“RuleML is a family of sublanguages
whose root allows access to
the language as a whole and
whose members allow to identify ...
customized subsets of the language.”
• RuleML: Rule Markup Language
– RuleML derivation rules (shown here) and production rules defined in
XML Schema Definition (XSD)
– Each XSD of the family corresponds to the
expressive class of a specific RuleML sublanguage
• The most recent schema specification of RuleML is always
available at http://www.ruleml.org/spec
• Current release: RuleML 0.91
• Previews: http://wiki.ruleml.org/XSD_Workplan 46
Schema Modularization
• XSD URIs identify expressive classes
– Receivers of a rulebase can validate applicability of
tools
(such as Datalog vs. Hornlog interpreters)
– Associated with semantic classes
(such as function-free vs. function-containing
Herbrand models)
• Modularization (Official Model)
– Aggregation:
e.g., Datalog part of Hornlog
– Generalization:
e.g., Bindatalog is a Datalog
47
• Rectangles are sublanguages
– Inheritance between schemas
• Ovals are auxiliary modules
– Elementary, including only
element and/or attribute definitions
– Become part of sublanguages

E.g., in http://www.ruleml.org/
0.91/xsd/hornlog.xsd
<xs:redefine
schemaLocation=
"datalog.xsd">
<xs:include
schemaLocation=
"modules/cterm_module.xsd"/>
48
Bring Datalog to the Semantic Web
• Start with n-ary relations (not binary properties)
• Keep Variable typing optional (reuse RDFS’
subClassOf taxonomies as sort lattices)
• Allow signature declarations of arities and types
• Employ function-free facts as well as Horn rules (rather
than 1st: RDF descriptions; 2nd: RDF rules)
• Use function-free Herbrand model semantics
(querying stays decidable)
• Provide three syntactic levels:
– User-oriented: Prolog-like, but with “?”-variables
– Abstract: MOF/UML diagrams
– XML serialization: Datalog RuleML
49
Business Rule: Positional
''The discount for a customer buying a product is 5 percent
if the customer is premium and the product is regular.''
<Implies>
<head>
<Atom>
Implies <Rel>discount</Rel>
<Var>customer</Var>
<Var>product</Var>
head body <Ind>5.0</Ind>
Atom And </Atom>
</head>
<body>
<And>
Atom Atom <Atom>
<Rel>premium</Rel>
discoun customer product 5.0
t <Var>customer</Var>
Rel Var Var Ind </Atom>
<Atom>
<Rel>regular</Rel>
premium customer regular product <Var>product</Var>
</Atom>
Rel Var Rel Var </And>
</body>
</Implies>

50
Extend Datalog for the Semantic Web (I)
• Allow slots as name->filler pairs in Atoms
(cf. F-logic’s methods and RDF’s properties)
• Extend optional types and signatures for slots
• Add optional object identifiers (oids) to atoms
• Separate Data literals from Individual constants

51
Business Rule: Slotted (for OO)
''The discount for a customer buying a product is 5 percent
if the customer is premium and the product is regular.''
<Implies>
<head>
<Atom>
Implies <Rel>discount</Rel>
<slot><Ind>buyer</Ind><Var>customer</Var></slot>
<slot><Ind>item</Ind><Var>product</Var></slot>
head body <slot><Ind>rebate</Ind><Data>5.0</Data></slot>
Atom And </Atom>
</head>
<body>
rebate <And>
buyer item Atom Atom <Atom>
<Rel>premium</Rel>
discoun customer product 5.0
t <Var>customer</Var>
Rel Var Var Data </Atom>
<Atom>
<Rel>regular</Rel>
premium customer regular product <Var>product</Var>
</Atom>
Rel Var Rel Var </And>
</body>
</Implies>

52
Extend Datalog for the Semantic Web (II)
• Permit IRI webizing for Data (XML Schema Part 2),
Individuals (RDF’s resources), Relations,
slot names, types (RDFS’ classes), and
oids (RDF’s about)
• Introduce Module (scope) construct for clauses
(cf. RDF’s named graphs)
• Add scoped-default (Naf), strong (Neg), scoped-default-
of-strong negation (unscoped: cf. ERDF)
• Integrate with Description Logics
– Homogeneous (SWRL, Datalog RuleML + OWL-DL)
– Hybrid (AL-log, DatalogDL, DL+log, ...)
53
Bring Horn Logic to the Semantic Web
• Augment Datalog with uninterpreted Functions
and their Expressions; also for extended Datalog
• Augment Datalog’s Herbrand model semantics with such
Functions (querying becomes undecidable)
• Extend Datalog syntaxes
– XML Schema of Hornlog RuleML inherits and augments XML
Schema of Datalog RuleML
• Add Equality and interpreted Functions (XML
serialization: attribute in="yes")
• Reuse XQuery/XPath functions and operators as built-ins
54
Specify a First-Order Logic Web Language
• Layer on top of either
– Disjunctive Datalog: Or in the head generalizing Datalog
– Disjunctive Horn Logic: Or in head of near-Horn clauses
• Alternatively, layer on top of either
– Disjunctive Datalog with restricted strong Negation
– Disjunctive Horn Logic with restricted strong Neg
• Permit unrestricted Or, And, strong Neg, and
quantifiers Forall and Exists to obtain FOL
• Use semantics of classical FOL model theory
• Extend Hornlog RuleML syntax to FOL RuleML

55
Equality for Functions
• Functional programming (FP) plays increasing
Web role: MathML, XSLT, XQuery
• Functional RuleML employs orthogonal notions freely
combinable with Relational RuleML
• Also solves a Relational RuleML issue, where the
following ‘child-of-parent’ elements are separated:
– Constructor (Ctor) of a complex term (Cterm)
– User-defined function (Fun) of a call (Nano)
• Proceed to a logic with equality

56
Function Interpretedness (I)
• Different notions of ‘function’ in LP and FP:
• LP: Uninterpreted functions denote unspecified values
when applied to arguments, not using function
definitions
• FP: Interpreted functions compute specified returned
values when applied to arguments, using function
definitions
• E.g.: first-born: Man  Woman → Human
– Uninterpreted: first-born(John, Mary) denotes first-born
– Interpreted: using first-born(John, Mary) = Jory, so
the application returns Jory
57
Function Interpretedness (II)
• Uninterpreted <Ctor> vs. interpreted <Fun>
functions now distinguished with attribute values:
<Fun in="no"> vs. <Fun in="yes">
• Function applications with Cterm vs. Nano
then uniformly become Expressions
• Two versions of example marked up as follows
(where "u" stands for "no" or "yes"):
<Expr>
<Fun in="u">first-born</Fun>
<Ind>John</Ind>
<Ind>Mary</Ind>
</Expr>
58
Unconditional Equations
• Modified <Equal> element permits both
symmetric and oriented equations
• E.g.: first-born(John, Mary) = Jory
can now be marked up thus:
<Equal oriented="yes">
<lhs>
<Expr>
<Fun in="yes">first-born</Fun>
<Ind>John</Ind>
<Ind>Mary</Ind>
</Expr>
</lhs>
<rhs>
<Ind>Jory</Ind>
</rhs>
</Equal>
59
Conditional Equations
• Use <Equal> as the conclusion of an <Implies>,
whose condition may employ other equations
• E.g.: ?B = birth-year(?P)  age(?P) = subtract(this-year(),?B)
<Implies>
<Equal oriented="no">
<Var>B</Var>
<Expr>
<Fun in="yes">birth-year</Fun>
<Var>P</Var>
</Expr>
</Equal>
<Equal oriented="yes">
<Expr>
<Fun in="yes">age</Fun>
<Var>P</Var>
</Expr>
<Expr>
<Fun in="yes">subtract</Fun>
<Expr>
<Fun in="yes">this-year</Fun>
</Expr>
<Var>B</Var>
</Expr>
</Equal>
</Implies>
60
Accommodate SWSL-Rules
• HiLog: Higher-order Variables, Constants, and Hterms
(complex terms and atomic formulas at the same time)
• Equal: As in Horn Logic with (unoriented) Equality
• Frames:
– Value molecules: Atoms with an oid, an optional Rel class, and zero
or more name->filler instance slots
– Signature molecules: name=>filler class slots, which
can have {min:max} cardinality constraints
• Reification: A formula (e.g., a rule) embedded in a Reify
element is treated (e.g., unified) as a term
• Skolems: Unnamed, represent new individual constants (like
RDF's blank nodes); otherwise, uniquely named ones
61
HiLog Examples: Hterms (I)
• First-order terms: f(a,?X)
<Hterm>
<op><Con>f</Con></op>
<Con>a</Con>
<Var>X</Var>
</Hterm>

• Variables over function symbols: ?X(a,?Y)


<Hterm>
<op><Var>X</Var></op>
<Con>a</Con>
<Var>Y</Var>
</Hterm>
62
HiLog Examples: Hterms (II)
• Parameterized function symbols: f(?X,a)(b,?X(c))
<Hterm>
<op>
<Hterm>
<op><Con>f</Con></op>
<Var>X</Var>
<Con>a</Con>
</Hterm>
</op>
<Con>b</Con>
<Hterm>
<op><Var>X</Var></op>
<Con>c</Con>
</Hterm>
</Hterm>
63
Equality Example
• Equality :=: in rule head: f(a,?X):=:g(?Y,b) :- p(?X,?Y).
<Implies>
<head>
<Equal>
<Hterm>
<op><Con>f</Con></op>
<Con>a</Con>
<Var>X</Var>
</Hterm>
<Hterm>
<op><Con>g</Con></op>
<Var>Y</Var>
<Con>b</Con>
</Hterm>
</Equal>
</head>
<body>
<Hterm>
<op><Con>p</Con></op>
<Var>X</Var>
<Var>Y</Var>
</Hterm>
</body>
</Implies>

64
Frame Example: Value Molecule
• Parameterized-name->filler slot: o[f(a,b) -> 3]

<Atom>
<oid><Con>o</Con></oid>
<slot>
<Hterm>
<op><Con>f</Con></op>
<Con>a</Con>
<Con>b</Con>
</Hterm>
<Con>3</Con>
</slot>
</Atom>

65
Reification Example: Reified Rule
• $Rule as slot filler: john[believes -> ${p(?X) implies q(?X)}].
<Hterm>
<oid>john</oid>
<slot>
<Con>believes</Con>
<Reify>
<Implies>
<body>
<Hterm>
<op><Con>p</Con></op>
<Var>X</Var>
</Hterm>
</body>
<head>
<Hterm>
<op><Con>q</Con></op>
<Var>X</Var>
</Hterm>
</head>
</Implies>
</Reify>
</slot>
</Hterm>
66
Skolem Examples (I):
• Named Skolem: holds(a,_#1) and between(1,_#1,5).

<And>
<Hterm>
<op><Con>holds</Con></op>
<Con>a</Con>
<Skolem>1</Skolem>
</Hterm>
<Hterm>
<op><Con>between</Con></op>
<Con>1</Con>
<Skolem>1</Skolem>
<Con>5</Con>
</Hterm>
</And>
67
Skolem Examples (II):
• Unamed Skolem: holds(a,_#) and between(1,_#,5).

<And>
<Hterm>
<op><Con>holds</Con></op>
<Con>a</Con>
<Skolem/>
</Hterm>
<Hterm>
<op><Con>between</Con></op>
<Con>1</Con>
<Skolem/>
<Con>5</Con>
</Hterm>
</And>
68
Proceed towards Modal Logics
• Modal operators generically viewed as special
Relations at least one of whose arguments is a
proposition represented as an Atom with an
uninterpreted Relation (including another modal
operator, but not an arbitrary formula)
– Alethicnecessary () and possible ()
– Deontic must and may (e.g., in business rules)
– Open for temporal (e.g., when planning/diagnosing reactive
rules), epistemic (e.g., in authentication rules), and further
modal operators
• Towards a unified framework for multi-modal logic
based on Kripke-style possible worlds semantics
69
Modal Examples: Alethic Operator
• Necessity:  prime(1)

<Atom>
<Rel modal="yes">necessary</Rel>
<Atom>
<Rel in="no">prime</Rel>
<Data>1</Data>
</Atom>
</Atom>

70
Modal Examples: Epistemic Operator
• Knowledge: knows(Mary,material(moon,rock))

<Atom>
<Rel modal="yes">knows</Rel>
<Ind>Mary</Ind>
<Atom>
<Rel in="no">material</Rel>
<Ind>moon</Ind>
<Ind>rock</Ind>
</Atom>
</Atom>
71
Modal Examples: Epistemic Reasoning
• Veridicality axiom: KnowsAgent proposition → proposition

KnowsMary material(moon,rock) →
material(moon,rock)

Serialization in previous slide


→
<Atom>
<Rel in="yes">material</Rel> <!-- "yes" is default -->

<Ind>moon</Ind>
<Ind>rock</Ind>
</Atom> 72
Modal Examples: Nested Operators
• Knowledge of Necessity: knows(Mary, prime(1))

<Atom>
<Rel modal="yes">knows</Rel>
<Ind>Mary</Ind>
<Atom>
<Rel modal="yes" in="no">necessary</Rel>
<Atom>
<Rel in="no">prime</Rel>
<Data>1</Data>
</Atom>
</Atom>
</Atom>
73
Protect Knowledge Bases by Integrity Constraints
• A knowledge base KB is a formula in any of our logic
languages
• An integrity constraint IC is also a formula in any
of our logic languages, which may be chosen
independently from KB
• KB obeys IC
iff
KB entails IC
(Reiter 1984, 1987)
– Entailment notion of 1987 uses epistemic modal operator
• Serialization: <Entails> KB IC </ Entails>
74
Integrity Constraint Example: Rule with -Head
• Adapted from (Reiter 1987):
IC = (x)emp(x)(y)ssn(x,y)
KB1 = emp(Mary) KB1 violates IC
KB2 = emp(Mary), ssn(Mary,1223) KB2 obeys IC
<Entails> KBi IC </Entails>
KB1: IC:
<Atom> <Forall>
<Rel>emp</Rel> <Var>x</Var>
<Ind>Mary</Ind> <Implies>
</Atom> <Atom>
<Rel>emp</Rel>
KB2: <Var>x</Var>
<Rulebase> </Atom>
<Atom> <Exists>
<Rel>emp</Rel> <Var>y</Var>
<Ind>Mary</Ind> <Atom>
</Atom> <Rel>ssn</Rel>
<Atom> <Var>x</Var>
<Rel>ssn</Rel> <Var>y</Var>
<Ind>Mary</Ind> </Atom>
<Data>1223</Data> </Exists>
</Atom> </Implies> 75
</Forall>
Approach Production and Reaction Rules
• Share Condition (C) part with earlier languages as
proposed for the RIF Condition Language
• Develop Action (A) part of Production Rules via a
taxonomy of actions on KBs (Assert, Retract, ...), on
local or remote hosts, or on the surroundings
• Develop Event (E) part of Reaction Rules via a
corresponding taxonomy
• Create CA and ECA families bottom-up and map to
relevant languages for Semantic Web Services
• Serialized: <Reaction> E C A </Reaction>
• See http://ibis.in.tum.de/research/ReactionRuleML TG
76
Semantic Web Rule Language (SWRL)
• W3C member submission rule language
• Extends OWL/OWL 2 DL with first-order rules to overcome the
limited expressivity of ontologies
– Function-free Horn logic, written in Datalog RuleML
• Allows class and property predicates to occur in the head and
body of a rule
– unrestricted combination of ontologies and rules
– follows the OWA and non-UNA
– … but it is undecidable
• DL-safe rules
– apply only on known individuals
– have limited expressivity but regain decidability
Rules in SWRL
• B1, …,Bn → A1, …, Am
– commas denote conjunction on both sides of the arrow
• A1, …, Am, B1, …, Bn can be
– C(x), P(x, y), sameAs(x, y), differentFrom(x, y)
– C is an OWL class description, P is an OWL property,
– x, y are Datalog variables, OWL individuals, or OWL data values.
• If the head of a rule has more than one atom the rule can
be transformed to an equivalent set of rules with one atom
in the head
– conjunction of atoms without shared variables
• A(X,Y)→ B(X), C(Y)
– A(X,Y)→ B(X) , A(X,Y)→ C(Y)
78
Complexity of SWRL
• Arbitrary OWL expressions (e.g. restrictions), can
appear in the head or body of a rule.
– This adds significant expressive power to OWL, but at the
high price of undecidability
– There can be no inference engine that draws exactly the
same conclusions as the SWRL semantics.
• SWRL vs. OWL 2 RL
– OWL 2 RL tries to combine the advantages of both languages
in their common sublanguage
– SWRL takes a more maximalist approach and unites their
respective expressivities.

79
Example SWRL Rules
• Reclassification
– Man(?m) → Person(?m) / subclassOf relation in OWL
– Person(?m)  hasSex(?m, male) → Man(?m)
• Possible in OWL – hasValue (sufficient) restriction
• Not all such reclassifications are possible in OWL
• Property Value Assignment
– hasParent(?x, ?y)  hasBrother(?y, ?z) → hasUncle(?x, ?z)
• Property chaining
• Possible in OWL 2 - Not possible in OWL 1.0
– Person(?p)  hasSibling(?p,?s)  Man(?s) → hasBrother(?p,?
s)
• Not possible in OWL
80
Example SWRL Rules: Built-ins
• Built-ins dramatically increase expressivity
– most rules are not expressible in OWL 1
– Some built-ins can be expressed in OWL 2

• Person(?p)  hasAge(?p, ?age) 


swrlb:greaterThan(?age, 17) → Adult(?p)

• Person(?p)  hasSalaryInPounds(?p, ?pounds) 


swrlb:multiply(?dollars, ?pounds, 2.0)
→ hasSalaryInDollars(?p, ?dollars)
81
The Vision
– 500 million users
– more than 3 billion pages

Static
WWW
URI, HTML, HTTP
The Vision
Serious Problems in
• information finding,
• information extracting,
• information representing,
• information interpreting and
• and information maintaining.

Static
WWW Semantic Web
URI, HTML, HTTP RDF, RDF(S), OWL
The Vision

Dynamic Web Services


UDDI, WSDL, SOAP Bringing the computer back as
a device for computation

Static
WWW Semantic Web
URI, HTML, HTTP RDF, RDF(S), OWL
The Vision
Bringing the web to its full potential

Dynamic Web Services Semantic Web


UDDI, WSDL, SOAP Services

Static
WWW Semantic Web
URI, HTML, HTTP RDF, RDF(S), OWL
The Problem
• Web
– Toward service provider
• Computers
– Moving inside devices
• Web usage
– Getting automated
• Web Page Change
– Needs an API Change

CSI5389 www.site.uottawa.ca/~afato092 86
The Solution
• Web Services need to be
– Computer-Interpretable
– Use-Apparent
– Agent-Ready
• Semantic Web Service is a Web Service
– Unambiguous and Machine-Understandable
• Properties, Capabilities, Interfaces, and Effects

CSI5389 www.site.uottawa.ca/~afato092 87
Realization

• AI-Inspired Content Markup Languages


– Ontology Interface Layer (OIL1)
– DARPA Agent Markup Language (DAML2)
• DAML +OIL3
• DAML –L4
• Still in Progress

CSI5389 www.site.uottawa.ca/~afato092 88
The Manual Web Service Usage
• Use a search engine to find a service
• Either read the web page associated with that
service or execute the service
• Fill out the forms and click the button
• Inform the user about possible compositions
• Interact with the user step by step
• …

CSI5389 www.site.uottawa.ca/~afato092 89
The Automatic Web Service Usage
• User just defines her objectives
– An agent does everything using
• WS Descriptions on WS Sites
• Ontology-Enhanced Search Engines
• Main Tasks in Automatic Mood
– Discovery
– Execution
– Composition and Interoperation

CSI5389 www.site.uottawa.ca/~afato092 90
Automatic Discovery
• Automatically Locating Web Services
– Given Particular Service and Its Properties
• Semantic Markup at the Web Sites
– To Specify the Service
• How to Find?
– Service Registry
– (Ontology-Enhanced) Search Engine

CSI5389 www.site.uottawa.ca/~afato092 91
Automatic Execution
• Automatically Executing a Web Service
– By a Computer Program or Agent
• Semantic Markup of Web Services
– A Declarative, Computer-Interpretable API for
Executing Services
– Tells the Agent What Input Is Necessary
– What Information Will Be Returned
– How to Execute and Interact With the Service

CSI5389 www.site.uottawa.ca/~afato092 92
Automatic Composition and Interoperation

• Automatic
– Selection
– Composition
– Interoperation
• Given a High-Level Description of the Objective
• Semantic Markup of Web Services
– A software can manipulate this markup
• Specification of the Objectives, Constraints, …

CSI5389 www.site.uottawa.ca/~afato092 93
State of the art
• Today they are not automatic
– Lack of Content Markup and a Suitable Markup
Language
• Academic Research
– Agent matchmaking research (Lark5)
• XML-based standards in industry
– UDDI, WSDL, ebXML, …

CSI5389 www.site.uottawa.ca/~afato092 94
How it works?
• User requests a generic procedure
• Agent populates its local KB
• adds the user’s constraints to its KB
• provides a logical encoding of the preconditions and
effects of the Web service actions
• ConGolog instantiates user request into
– a sequence of primitive actions
• Agent finds appropriate service for each action
• …

CSI5389 www.site.uottawa.ca/~afato092 95
References
1. F. van Harmelen and I. Horrocks, “FAQs on OIL: The Ontology Inference Layer,” IEEE Intelligent Systems,
vol. 15, no. 6, Nov./Dec. 2000, pp. 69–72.
2. J. Hendler and D. McGuinness, “The DARPA Agent Markup Language,” IEEE Intelligent Systems, vol. 15,
no. 6,Nov./Dec. 2000, pp. 72–73.
3. www.daml.org/2000/10/daml-oil
1. www.daml.org/2001/03/daml+oil-index.html
4. Somewhere in www.stanford.edu!
5. K. Sycara et al., “Dynamic Service Matchmaking among Agents in Open Information Environments,” J.
ACM SIGMOD Record, vol. 28, no. 1, Mar. 1999, pp. 47–53.
6. M. Ghallab et al., PDDL: The Planning Domain Definition Language, Version 1.2, tech. report CVC TR–
98–003/DCS TR–1165, Yale Center for Computational Vision and Control,Yale Univ.,New Haven, Conn.,
1998.
7. D.L. Martin, A.J. Cheyer, and D.B. Moran, “The Open Agent Architecture: A Framework for Building
Distributed Software Systems,” Applied Artificial Intelligence, vol. 13, nos. 1–2, Jan.–Mar. 1999, pp. 91–
128.
8. Jagadeesh Nandigam, Venkat N Gudivada and Mrunalini Kalavala. “SEMANTIC WEB SERVICES”
Proceedings of the CCSC: Midwestern Conference, JCSC 21, 1 (October 2005). pp. 50-63.

CSI5389 www.site.uottawa.ca/~afato092 96
The Basics

What are
Web Services,
Web Processes, and
Semantics?
Web Services: Definition
Web Services

“Web services are a new breed of Web application. They are


self-contained, self-describing, modular applications that
can be published, located, and invoked across the Web.
Web services perform functions, which can be anything from
simple requests to complicated business processes. …
Once a Web service is deployed, other applications (and
other Web services) can discover and invoke the deployed
service.”

IBM web service tutorial


Semantics for Web Processes
• Data/Information Semantics
– What: Formal definition of data in input and output messages of a web service
– Why: for discovery and interoperability
– How: by annotating input/output data of web services using ontologies

• Functional/Operational Semantics
– Formally representing capabilities of web service
– for discovery and composition of Web Services
– by annotating operations of Web Services as well as provide preconditions and effects; Annotating TPA/SLA
(future work)

• Execution Semantics
– Formally representing the execution or flow of a services in a process or operations in a service
– for analysis (verification), validation (simulation) and execution (exception handling) of the process models
– using State Machines, Petri nets, activity diagrams etc.

• QoS Semantics
– Formally describing operational metrics of a web service/process
– To select the most suitable service to carry out an activity in a process
– using QoS model [Cardoso and Sheth, 2002] for web services
Web Processes Architecture
How can semantics
…
be explored ???
Composition
Brokering

Discovery

UDDI
WSDL

SOAP

XML
Web Servers

HTTP/HTTPS

Semantics
TCP/IP-SSL
Web Process Architecture
WS9 Web page
Semantic Web servers

Associate ontology based


semantic layers to web resources

Semantic Web browsers

Making sense of page contents


Supporting the interpretation of web pages

Web Servers WS2 Web page

HTTP/HTTPS

Semantics
TCP/IP-SSL
Web Process Architecture
Web service Semantic Annotation

Associate ontological concepts


to Web service descriptions

METEOR-S
WSDL
Semantics
DAML-S
SOAP Semantics

XML

Adding Semantics to Web Services Standards , Semantic Annotation of Web Services


Semantics
Web Service

Web Services WSDL

SOAP

• WSDL defines services as collections XML


of network endpoints or ports. A port
is defined by associating a network
address with a binding; a collection of
ports define a service.

 SOAP is a message layout specification that defines a


uniform way of passing XML-encoded data. It also defines
a way to bind to HTTP as the underlying communication
protocol. SOAP is basically a technology to allow for “RPC
over the web”.
 XML was designed to describe data and to focus on what
data is.
Web Service

WSDL WSDL

SOAP

XML

• WSDL stands for Web Services Description


Language
• WSDL is an XML document
• WSDL is used to describe Web services
• WSDL is also used to locate Web services
Web Service
WSDL WSDL

SOAP

XML

Abstract
Description

Concrete
Description

From S. Chandrasekaran’s Talk


Semantic Annotation of Web Services
Annotation of Web Services

• To enhance the discovery, composition, and orchestration of


Web services, it is necessary to increase the description of
their interfaces.

• One solution is to annotate WSDL interfaces with semantic


metadata based on relevant ontologies.

An ontology is a specification of a representational vocabulary for a


shared domain of discourse.
Semantics at Description Layer
Description Layer:
Why:
• Unambiguously understand the functionality of the services
Flow and the semantics of the operational data

Discovery How:
• Using Ontologies to semantically annotate WSDL constructs
Publication (conforming to extensibility allowed in WSDL specification
version 1.2) to sufficiently explicate the semantics of the
– data types used in the service description and
Description – functionality of the service
Messaging
Present scenario:
Network • WSDL descriptions are mainly syntactic (provides operational
information and not functional information)
• Semantic matchmaking is not possible

Adding Semantics to Web Services Standards , Semantic Annotation of Web Services


How to Annotate ?
 Map Web service’s input & output data as well as functional
description using relevant data and function/operation
ontologies, respectively

 How ?
 Borrow from schema matching
 Semantic disambiguation between terms in XML
messages represented in WSDL and concepts in
ontology

Semantic Annotation of Web Services


Web Services
Interfaces

• A Web service (WS) invocation specifies:


– The number of input parameters that must be supplied for a
proper WS realization and
– The number of outputs parameters to hold and transfer the
results of the WS realization to other tasks.
– A function to invoke

Inputs Outputs
Receipt
Client
Itinerary
Local
Tourism

function_foo(x..y)
Web Ontology Language
for Service (OWL-S)
Introduction
• OWL-S
– OWL-based Web service ontology
– a core set of markup language constructs for
describing Web services in unambiguous,
computer-interpretable form
Introduction
• • OWL-S:
– An ontology of service
– As a part of DARPA Agent Mark-up Program

• Traditional systems:
– Lack of semantic description of Services
– Requirement of human assistant

21/12/2005 OWL-S: Ontology Web Language


for Services
Tasks that OWL-S
is expected to enable
– Automatic Web service discovery
• Automated location of web services that provides a particular
service and adhere to requested constraints

– Automatic Web service invocation


• Automated execution of an identified web service by a computer
program or agent

– Automatic Web service composition and interoperation


• Automatic selection, composition and interoperation of web
services to perform some task
Three essential types of knowledge about a
service
1. What does the service provide for
prospective clients?

• The answer to this question is given in the "profile"


which is used to advertise the service.

• To capture this perspective, each instance of the class


Service presents a ServiceProfile.
2. How is it used?

• The answer to this question is given in the "process


model“(also known as “service model”)
• This perspective is captured by the ServiceModel class.
• Instances of the class (called Service class) use the
property describedBy to refer to the service's
ServiceModel.
3. How does one interact with it?

• The answer to this question is given in the "grounding“

• A grounding provides the needed details about


transport protocols.

• Instances of the class Service have a supports property


referring to a ServiceGrounding
Three essential type of knowledge about a service
Service Profile
• Describes services capabilities

• Describes the services offered by the


providers, and the services needed by the
requesters.
Three basic types of information

1. What organization provides the service

• Contact information that refers to the entity that


provides the service
2. What function the service computes

• Specified in terms of:

– Inputs required by the service and outputs generated

– Preconditions required by the service and expected effects


that result from the execution of the service
3. A host of features that specify characteristics of the
service

• The category of a given service


• The quality rating of the service (some services may be very
good, reliable, and quick to respond)
• An unbounded list of service parameters that can contain
any type of information
1

2
3
Three types of information in Service Profile
Process Model
• A process is intended as a specification of the ways a
client may interact with a service

• A process can have two sorts of purpose:


– It can generate and return some new information.
• Information production is described by the inputs and outputs of
the process.

– It can produce a change in the environment.


• This transition is described by the preconditions (which must all
hold in order for the process to be successfully invoked) and
effects of the process
Inputs, Outputs Preconditions and Effects
(IOPE)
• Inputs
– specify the information that the process requires for its
execution.
• Outputs
– produced by the invocation of a process flow back to the client
as a single message.
• Preconditions
– a condition that must be true just before to the execution of
process.
• Effects
– describe conditions about the environment after process be
executed.
Simple process
• Simple processes are used as elements of
abstraction.
– A simple process may be used to provide:
• The simple process is realizedBy the atomic process
– A simplified representation of some composite process
• The simple process expandsTo the composite process

• Simple processes are not invocable


(not associated with a grounding)
Atomic process
• An atomic process corresponds to the behavior a
service can perform.
– Expects one message and returns one message in
response.

• Atomic processes are directly invocable (associated


with a grounding)

• Atomic processes have no sub-processes and execute


in a single step.
Composite process
• Composite processes are decomposable into other
non-composite or composite processes

• Their decomposition can be specified by using


control constructs (next page)

• A composite process is not a behavior of a service,


but a set of behaviors the client can invoke by
sending messages and receiving results.
Control Constructs
• Sequence
– A list of control constructs to be done in order.

• Split
– A bag of process components to be executed concurrently. Split
completes as soon as all of its component processes have been
scheduled for execution.

• Split-Join
– The process consists of concurrent execution of a bunch of process
components with barrier synchronization. Split+Join completes when
all of its components processes have completed.
• Any-Order
– Allows the process components (specified as a bag) to be executed in
some unspecified order but not concurrently. Execution and
completion of all components is required.

• Choice
– Execution of a single control construct from a given bag of control
constructs. Any of the given control constructs may be chosen for
execution

• If-Then-Else
– Conditionally executes process components , depending on the value
of a conditional expression.
• Iterate
– Is an "abstract" class, serves as the common
superclass of Repeat-While, Repeat-Until, and
potentially other specific iteration constructs.
• Repeat-While and Repeat-Until
– Iterate until a condition becomes false or true,
following the familiar programming language
conventions.
Process Model
Service Grounding
• Providing details on how to interoperate/access the
service
– Protocol, message formats, serialization, …
– A mapping from an abstract specification to a concrete
realization
• How the abstract inputs and outputs of an atomic
process are to be realized concretely as messages
(which carry these inputs and outputs)
– WSDL as a possible grounding approach
– Exploiting the extensibility elements of WSDL
f1(int a,b) int a=1,b=2;

e.g. f1(1, 2)

Mapping between OWL-S and WSDL


How WSDL definitions refer to
corresponding OWL-S declarations
• wsdlVersion:
– A URI that indicates the version of WSDL in use.

• wsdlDocument:
– A URI of a WSDL document to which this grounding refers.

• wsdlOperation:
– The URI of the WSDL operation corresponding to the given
atomic process.
• wsdlService, wsdlPort (optional):
– The URI of a WSDL service (or port) that offers the given operation.

• wsdlInputMessage:
– An object containing the URI of the WSDL message definition that
carries the inputs of the given atomic process.

• wsdlInput:
– An object containing a mapping pairs, for a message part of the WSDL
input message. Each pair is represented using an instance of
WsdlInputMessageMap.
• wsdlOutputMessage:
– Similar to wsdlInputMessage, but for outputs.

• wsdlOutput:
– Similar to wsdlInput, but for outputs.
Motivations for OWL-S
• Automatic Web Service Discovery

• Automatic Web Service Invocation

• Automatic Web Service Composition & Interoperation

• Automatic Web Service Execution Monitoring

21/12/2005 OWL-S: Ontology Web Language


for Services
Automatic Web Service Discovery
• E.g.: Selling Airline ticket accepting particular
credit card

Use Search engine


Read Web Page Satisfies the
Execute the service Manually constraints??

• Declarative advertisements of service


properties for automatic service discovery
21/12/2005 OWL-S: Ontology Web Language
for Services
Automatic Web Service Invocation
• Execution of Web service by computer program
or agent
• E.g.: Purchasing an airline ticket
•Fill a form
•Click button for execution Human
performs

• Machine understands what input, output, how


to execute the service
21/12/2005 OWL-S: Ontology Web Language
for Services
Automatic Web Service Composition
and Interoperation
• Automatic selection, composition and interoperation
• E.g. Travel Arrangement

Select the web service Human


Specify the composition manually
Check necessity of software for interoperation

• Declaring prerequisites and effect of service

21/12/2005 OWL-S: Ontology Web Language


for Services
Automatic Web Service Execution
Monitoring

• The ability to find out:


– Where the request is in the process
– The status of the request
– Be sure the service made
– Unanticipated exception

21/12/2005 OWL-S: Ontology Web Language


for Services
Parts of Service Ontology

Is Taken From [1]

21/12/2005 OWL-S: Ontology Web Language


for Services
Service Profile
• Describe the service what does
– Service name, Text Description and Contact Information
• Similar to yellow pages
• Gives information about the functionality
– IOPE s of Service
• Gives the characteristics features of the services
– Quality ratings of service
– Classification information
• Enables automatic discovery

21/12/2005 OWL-S: Ontology Web Language


for Services
OLW-S & UDDI Mapping

Is Taken From [2]

21/12/2005 OWL-S: Ontology Web Language


for Services
Service Model

• Describes how service works


• Includes Data and control flow of service
process
• Does not enforce the consistency with Service
Profile
– Traveling service in profile
– Book Service in service process model
• Process Model is subclass of Service Model
21/12/2005 OWL-S: Ontology Web Language
for Services
Process Ontology

Is Taken From [1]

21/12/2005 OWL-S: Ontology Web Language


for Services
Example: Process Sequence

Is Taken From [6]

21/12/2005 OWL-S: Ontology Web Language


for Services
Grounding

• Describes how to access the service


• Concrete description such as binding protocol,
address, message formats, etc.
• WSDL + OWL-S
– Type : Includes OWL-S class types
– Message: OWL-S inputs and OWL-S outputs
– Operation:OWL-S atomic process
– Binding: Encoding Style supplied

21/12/2005 OWL-S: Ontology Web Language


for Services
Semantic Web Services
=
Semantic Web Technology
+
Web Service Technology

150
Semantic Web Services (2)
Semantic Web:
• Ontologies - basic building block:
"Formal, explicit specification of a shared conzeptualization"
• Allow machine supported data interpretation
• Ontology Language Standards:
– RDF, RDFS … triples, graph based model
– OWL … DL (+extensions SWRL, full FOL)
– WSML … LP, F-Logic, …

i.e.
– instance data, plus relations between instances (RDF)
– modeling taxonomies (RDFS)
– richer inference rules and axioms over my instances and relations (OWL, OWL-
S, F-Logic, SWRL, WSML)

Semantic annotation shall enable machine-processable data and automation of


processing the data on the Web!

151
Semantic Web Services
• What should S+WS and service ontologies provide?
(Partly) Automation of the Usage Process:

– Publication: Make available the description of the capability of a service


– Discovery: Locate different services suitable for a given task
– Selection: Choose the most appropriate services among the available ones
– Composition: Combine services to achieve a goal
– Mediation: Solve mismatches (data, protocol, process) among the combined
– Execution: Invoke services following programmatic conventions
– Monitoring: Control the execution process
– Compensation: Provide transactional support and undo or mitigate unwanted effects
– Replacement: Facilitate the substitution of services by equivalent ones

152
OWL-S Ontology
• OWL-S is an OWL ontology to describe Web services
• OWL-S leverages on OWL to
– Support capability based discovery of Web services
– Support automatic composition of Web Services
– Support automatic invocation of Web services
"Complete do not compete"
– OWL-S does not aim to replace the Web services standards
rather OWL-S attempts to provide a semantic layer
• OWL-S relies on WSDL for Web service invocation (see Grounding)
• OWL-s Expands UDDI for Web service discovery (OWL-S/UDDI mapping)

153
OWL-S Upper Ontology

•Capability specification
•General features of the Service
• Quality of Service
• Classification in Service
taxonomies

• Mapping to WSDL
• communication protocol (RPC, HTTP, …)
• marshalling/serialization • Control flow of the service
• transformation to and from XSD to OWL • Black/Grey/Glass Box view
• Protocol Specification
• Abstract Messages

154
Service Profiles

Service Profile
– Presented by a service.
– Represents
what the service provides
– Two main uses:
1. Advertisements of Web Services
capabilities (non-functional
properties, QoS, Description,
classification, etc.)
2. Request of Web services with a
given set of capabilities

•Profile does not specify use/invocation!


155
OWL-S Service Profile
Capability Description
• Preconditions
– Set of conditions that should hold prior to service invocation
• Inputs
– Set of necessary inputs that the requester should provide to invoke the service
• Outputs
– Results that the requester should expect after interaction with the service provider is
completed
• Effects
– Set of statements that should hold true if the service is invoked successfully.
• Service type
– What kind of service is provided (eg selling vs distribution)
• Product
– Product associated with the service (eg travel vs books vs auto parts)

156
Process Model

• Process Model
– Describes how a service works:
internal processes of the service
– Specifies service interaction protocol
– Specifies abstract messages:
ontological type of information
transmitted
• Facilitates
– Web service invocation
– Composition of Web services
– Monitoring of interaction

157
Definition of Process
• A Process represents a transformation (function).
It is characterized by four parameters
– Inputs: the inputs that the process requires
– Preconditions: the conditions that are required for the process to run correctly
– Outputs: the information that results from (and is returned from) the execution o
the process
– Results: a process may have different outcomes depending on some condition
• Condition: under what condition the result occurs
• Constraints on Outputs
• Effects: real world changes resulting from the execution of the process

158
Example of an atomic Process
<process:AtomicProcess rdf:ID="LogIn">
<process:hasInput rdf:resource="#AcctName"/>
Inputs / Outputs <process:hasInput rdf:resource="#Password"/>
<process:hasOutput rdf:resource="#Ack"/>
Precondition <process:hasPrecondition isMember(AccName)/>
<process:hasResult>
<process:Result>
<process:inCondition>
<expr:SWRL-Condition>
Condition correctLoginInfo(AccName,Password)
</expr:SWRL-Condition>
</process:inCondition>
Result <process:withOutput rdf:resource=“#Ack“>
Output <valueType rdr:resource=“#LoginAcceptMsg”>
Constraints </process:withOutput>
<process:hasEffect>
<expr:SWRL-Condition>
loggedIn(AccName,Password)
Effect </expr:SWRL-Condition>
</process:hasEffect>
</process:Result>
</process:hasResult>
</process:AtomicProcess>

159
Ontology of Processes
Process

Atomic
Invokable
bound to grounding Simple
Provides abstraction,
encapsulation etc. Composite
Defines a workflow
composed of process perform

160
Composite Processes
•Composite Processes specify how processes work together to
compute a complex function
•Composite processes define
1.Control Flow
Specify the temporal relations between the executions of
the different sub-processes (sequence, choice, etc.)
2.Data Flow
Specify how the data produced by one process is
transferred to another process

161
Example of Composite Process
Control Flow Links
Airline Sequence Flight Specify order of
BookFlight execution

Data-Flow Links
Specify transfer of data

Perform Perform
Airline
Depart Flights Flights Flight
Get Flights Select
Arrive Flight

Perform statements
Specify the execution of a process

162
Process Model Organization
• Process Model is described as a tree structure
– Composite processes are internal nodes
– Simple and Atomic Processes are the leaves
• Simple processes represent an abstraction
– Placeholders of processes that aren’t specified
– Or that may be expressed in many different ways
• Atomic Processes correspond to the basic actions that the Web service
performs
– Hide the details of how the process is implemented
– Correspond to WSDL operations

~ related Process Definition Languages a la BPEL

163
Service Grounding

• Service Grounding
– Provides a specification of service access
information.
– Service Model + Grounding give
everything needed for using the service
– Builds upon WSDL to define message
structure and physical binding layer
• Specifies:
– communication protocols, transport
mechanisms, communication languages,
etc.

164
Mapping OWL-S / WSDL 1.1
• Operations
correspond to Atomic
Processes

• Input/Output
messages correspond
to Inputs/Outputs of
processes

165
Example of Grounding
Airline Sequence Flight
BookFlight

Perform Perform
Airline
Depart Flights Flights Flight
Get Flights Select
Arrive Flight

Arrive
Depart Get Flights Op Flights Flights Flight
Select
Airline Flight op
WSDL

166
Result of using the Grounding
• Invocation mechanism for OWL-S
– Invocation based on WSDL
– Different types of invocation supported by WSDL can be used with OWL-S
• Clear separation between service description and
invocation/implementation
– Service description is needed to reason about the service
• Decide how to use it
• Decide how what information to send and what to expect
– Service implementation may be based on SOAP an XSD types
– The crucial point is that the information that travels on the wires and the
information used in the ontologies is the same
• Allows any web service to be represented using OWL-S

Personal Remark: I do not completely believe this enables composition:


still different SOAP messages can be linked to the same service: ambiguities!
167
OWL-S: Language
Some superficial comments:
• OWL-S itself is an OWL Ontology,
• Combined with SWRL for preconditions and effects.
• Inputs/Outputs subclasses of SWRL variables
• Possible candidates for logicical language used: SWRL, SWRL-
FOL, (KIF, DRS)

• However: Dicsovery, composition approaches published so far


operate purely on description logic reasoning

168

You might also like