Module 3
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?
SUE CP2001
JOE CP2003
enrolledIn
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
student(Name,StudentID)
courses(Cname, StudentID)
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.
15
Datalog
Terminology:
p q, not r
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).
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).
S. Costantini / Datalog 20
Datalog
S. Costantini / Datalog 21
Datalog
M = {s1,s2,q2,r1,r2,p2}
S. Costantini / Datalog 22
Datalog semantics
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
S. Costantini / Datalog 25
Arithmetic Subgoals
S. Costantini / Datalog 26
Example: Arithmetic
S. Costantini / Datalog 27
Negated Subgoals
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.
S. Costantini / Datalog 30
Example: Unsafe Rules
S. Costantini / Datalog 33
Stratified Negation
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
• Example:
usable(X):- tool(X), not broken(X).
tool(computer1).
tool(my_car).
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 )
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>
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)
<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
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
Static
WWW Semantic Web
URI, HTML, HTTP RDF, RDF(S), OWL
The Vision
Bringing the web to its full potential
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
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
• 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
HTTP/HTTPS
Semantics
TCP/IP-SSL
Web Process Architecture
Web service Semantic Annotation
METEOR-S
WSDL
Semantics
DAML-S
SOAP Semantics
XML
SOAP
WSDL WSDL
SOAP
XML
SOAP
XML
Abstract
Description
Concrete
Description
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
How ?
Borrow from schema matching
Semantic disambiguation between terms in XML
messages represented in WSDL and concepts in
ontology
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
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
• 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)
• 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
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)
151
Semantic Web Services
• What should S+WS and service ontologies provide?
(Partly) Automation of the Usage Process:
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
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
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
168