A Semantic Matchmaker for RDF/OWL-based Service Repositories

1
A Semantic Matchmaker for RDF/OWL-based Service
Repositories
Building a Tool for OWL-S Service Discovery and
Composition

• Mirza Said
• National Institute of Advanced Industrial Science
  and Technology (AIST)
• Grid Technology Research Center
• Japan

2
Outline

• Introduction
• OWL-S
• Semantic service matchmaking and main issues
• Proposed matchmaking system
• Summary and future work

3
Background

• Many Web services are available in the Web
• The number is rapidly increasing
• Google, Yahoo, Amazon, B2B, and etc.
• Main issue automatic and accurate discovery of
  target web services
• Semantic Interoperability is a major hurdle for
  Locating Services
• Different terms are used for advertisements and
  requests
• OWL-S An ontology of service concepts for
  describing the properties and capabilities of Web
  services in a machine interpretable form

4
OWL-S The Upper Ontology

• Consists of four main classes
• ServiceProfile for advertising and discovering
  services
• What organization provides the service (e.g.,
  contact information)
• What function the service computes (e.g., inputs
  and outputs)
• What characteristics the service has (e.g.,
  service category)

• ProcessModel a detailed description of a
  service's operation
• ServiceGrounding the details of how to access
  the service
• Service binds three classes via three object
  properties

5
An OWL-S Service A Car Selling Service

• hasInput Familycar Year
• hasOutput Price
• serviceProduct Used-vehicle
• textDescription used car shop in Tokyo

Year
Price
UNSPC ontology
hasOutput
hasInput
Car-shop
serviceProduct
hasInput
textDescription
A used cars shop locating in Tokyo
6
OWL-S Service Matchmaking
service repository matchmaker
provider
requester

• A provider describes advertised services using an
  OWL-S compliant ontology
• A requester queries the repository using the same
  ontology
• Repository matches the request and advertisements
  and returns matched advertisements in relevance
  order

7
Basic Principle of Matching (Paolucci et al.
ISWC02)
FLEXIBLE MATCH by defining degree of match
between two classes/concepts

• An advertisement matches a request when
• all request outputs are matched by advertisement
  outputs and
• all advertisement inputs are matched by request
  inputs
• Guarantees that the matched service provides all
  outputs requested by the requester, and that the
  requester provides all input required for correct
  operation to the matched service

8
Degree of Match
advertisement
hasInput Familycar year hasOutput
price serviceProduct used-vehicle textDescription
used car shop in Tokyo
request
hasInput sedan year hasOutput price
service repository matchmaker
query
register
provider
requester
inR a request input inA an advertisement input
degreeOfMatch(inA, inR) ? Paolucci et.al.
ISWC02 if inRinA then Exact if inA
immediateSubclassOf inR then Exact if inA
subclassOf inR then Plug-in if inR subclassOf
inA then Subsume otherwise Fail
Exact gt Plug-in gt Subsume gt Fail
9
Main Issues

• Using ontology as a service request
• Difficult to compose
• The repository usually only support simple
  queries
• Each matchmaking system uses a different matching
  engine
• Need a proprietary query engine
• Tighly-couple architecture

10
Goal
Using SPARQL as the query language!!

• Propose a matchmaking mechanism that
• Enables complex service matching
• e.g, optional pattern matching
• Has a loosely-couple architecture
• Matchmaker can switch from one RDF repository to
  another or send a simultaneous query to multiple
  repositories
• allows to use existing standard matching
  engines
• Not build and using another proprietary matching
  engine

?SPARQL pattern matching
?Repository SPARQL query engine
?Many free SPARQL query engines are available
11
SPARQL Entailments Matching
Query pattern
profilehasInput
rdftype
?profile
?in
autoSedan
RDF Graph
profilehasInput
rdftype
autoin
autop
autoHatchback

• SPARQL does not interpret RDF schema information
  or entailments
• (treats RDF graph purely as data)

12
Basic Architecture
register
query rewriting
client interface
service requester
SPARQL query engine
OWL-S/RDF data repository
SPARQL interface
result ordering
Matchmaker
RDF Repository System

• Requester sends a SPARQL query to Matchmaker
• Matchmaker rewrites the query and sends it to an
  OWL-S service (RDF) repository
• Matchmaker orders the results based on the degree
  of match between classes

13
Why Rewriting?
Rewrite the query s.t. the results will contain
the necessary info.
SPARQL query
register
query
query
query rewriting
rewritten query
client interface
service requester
SPARQL query engine
OWL-S/RDF data repository
SPARQL interface
unordered results ordering info.
result ordering
ordered results
ordered results
Matchmaker
RDF Repository System
Need to order results based on class subsumption
but they do not contain the information necessary
for result ordering
Results are unordered
14
Why Rewriting?Lack of Class Subsumption Info.
Query pattern
profilehasInput
rdftype
?profile
?in
autoSedan
Inferred graph (iGraph)
profilehasInput
rdftype
autop
autoin
autoHatchback
rdftype
rdftype
autoSedan

Query solution
No class subsumption info. Hatchback is an imm.
subclass of Sedan (prevent Exact Plug-in match
calc.)
?profile ?in
autop autoin
15
Why Rewriting?Cannot Match Superclass Instances
Query pattern
profilehasInput
rdftype
?profile
?in
autoFamilycar
Inferred graph (iGraph)
profilehasInput
rdftype
autoin
autop
autoCar
rdftype
autoAutomobile
Cannot match superclass instances (prevent
Subsume match calculation)
Query solution not exist
16
Why Rewriting?Lack of property inclusiveness
info.
Query pattern
profilehasInput
rdftype
?profile
?in
autoCar
Inferred graph (iGraph)
profilehasInput
rdftype
autop
autoin1
autoCar
rdftype
profilehasInput
autoyear
autoin2
Query solution
Do not know whether autop has only one input or
more (prevent Fail match calculation)
?profile ?in
autop autoin1
17
Query Rewriting Basic Principle

• Rewrite the requester query such that the
  matching results will include the lacking
  information
• Class subsumption
• Superclass instances
• Property inclusiveness

18
Query Rewriting The Rules

• A requester query

Type-matching pattern

• Rewrite each type-matching pattern

A graph pattern that matches k values of property
p while restricting values to those from
specific classes
19
(No Transcript)
20
SELECT ?s WHERE ?s presents ?o. ?o hasInput ?in1,
?in2. ?in1 a Familycar. ?in2 a Toyota.
Check whether hasInput is inclusiveness. i.e.,
whether it has only two values whose types are
the superclass/subclass of Familycar and Toyota
Get the immediate superclasses and subclasses of
Familycar and Toyota (rs rdfssubclassOf)
Get superclasses and subclasses of Familycar and
Toyota and binding them to variables (rs
rdfssubclassOf)
Get hasInput instances whose values are from the
superclasses and subclasses of Familycar and
Toyota
21
Extracting Info. from Binding Variables
22
Service Ordering

• Service functions (service inputs outputs)
• Service characteristics (service category,
  products and etc.)

23
Service Ordering (Service Function)

• Given a requester query q
• ?o hasInput ?in1 , , ?inm .
• ?in1 rdftype cin1. ?inm rdftype cinm.
• A matched service instance s
• p hasInput pin1 , , pinm .
• pin1 rdftype sin1. pinm rdftype sinm.
• Degree of match for service inputs
• din(q, s) DIN(cin1, sin1) DIN(cinm, sinm)
  
• Note if hasInput of s in non-inclusive then Fail
• Degree of match for service outputs
• dout(q, s)DOUT(cout1, sout1) DOUT(coutn,
  soutn)

24
Degree of Match Calculation
DOUT(outR, outA) if outRoutA return Exact if
outR immSubclassOf outA return Exact if outR
subclassOf outA return Plug-in otherwise
return Subsume

• DIN(inR, inA)
• if inRinA return Exact
• if inR immSuperclassOf inA
• return Exact
• if inR superclassOf inA
• return Plug-in
• otherwise return Subsume

25
Service Ordering (Service Characteristics)

• Given a requester query q, where p specifies a
  service characteristic
• ?o p ?var1 , , ?varm .
• ?var1 rdftype c1. ?varm rdftype cm.
• A matched service instance s
• psc p pc1 , , pcm .
• pc1 rdftype sc1. pcm rdftype scm.
• Degree of match for a service characteristic
• dp(q, s) DOUT(c1, sc1) DOUT(cm, scm)
• Degree of match for m properties

26
Overall Scoring

• The overall scoring
• d(q, s)ax df(q, s) (1-a) x dc(q, s) ,
• where 0a1
• When df(q, s) fails d(q, s) also fails
• Can be used to order general SPARQL query results
  by setting a0

27
Discussion and Conclusions

• Research achievements
• Using SPARQL as the query language for service
  requester
• Loosely-coupled architecture of the matchmaking
  system
• Lighweight matchmaker
• Complex service matching requests
• Major current challenge
• How to rewrite the requester query such that the
  matching results will contain the information
  necessary for result ordering

28
Discussion and Conclusions

• Future work
• Query rewriting rules for queries with SPARQL
  UNION connecting type-matching patterns
• Degree of match based on the relationship among
  classes and their property classes (e.g., c2 is a
  property of c1)
• Query rewriting rules for extracting the
  information