FLEXIBLE SEMANTIC MATCHMAKING ENGINE
Simone A. Ludwig
Uxbridge, Middlesex UB8 3PH
Abstract the problems arising from service matchmaking. “Syntax
Discovering a service which satisfies a request matchmaking” service discovery techniques such as SLP
sufficiently is a major issue in any application process. As (Service Location Protocol), Jini etc. lack the ability of
a result, the motivation to develop a powerful and semantics, thus the need for capability matchmaking
customizable matchmaking engine becomes a very becomes crucial . The task of a matchmaking engine is
important criterion. Using semantic information for the to use its knowledge and its semantic understanding of the
matchmaking process achieves better results than advertisement and request to recognize the degree of
syntactic type matchmaking. In this paper an ontology- match. Furthermore, the matchmaking engine should
based service discovery tool, called retrieve the advertisements of services that match the
OntoServiceMatchmaker, is presented which performs request more closely. For this reason, the use of
flexible semantic matches of customized service requests. ontologies, which define a formal, shared and common
The matchmaking engine is capable of parsing understanding of a domain for knowledge-sharing and re-
DAML+OIL marked properties and allows the user to use has risen .
customize the matchmaking process accordingly. This
engine utilizes current semantic matchmaking techniques Effort has been made to define and develop ontology
to perform the service discovery. The description languages. Resource Description Framework Schema
properties and functional attributes of the ontology are RDF(S) is an ontology/knowledge representation
properties for the matching values. These properties found language which contains classes and properties, range and
by the ontology parser and reasoned by the inference domain constraints and subclass and subproperty
engine serve for the matchmaking process as input relations. But as RDF(S) is a relatively primitive
variables. The final selection is done by matching the language, more expressive power was necessary to
customized service request with the actual service describe resources in sufficient detail . These
advertisements provided in a registry. considerations led to the development of the Ontology
Inference Layer (OIL)  and later to the design of
Key Words DAML+OIL . DAML+OIL is a more recent proposal
Ontologies, Semantic Web, Matchmaking Engine, for an ontology representation language that has emerged
Service Discovery. from work under DARPA's Agent Markup Language
(DAML) initiative along with input from leading
members of the OIL consortium.
1. Introduction This paper is based on the current work being done for
the DataTAG  project. The goal of the DataTAG
The Semantic Web is an extension of the current Web project is to create a large-scale intercontinental testbed
in which information is given well-defined meaning. It for data-intensive Grids and to provide interoperability
also enables computers and people to work in between the Grid middleware layers.
cooperation. It is the idea of having data on the Web
defined and linked in a way that it can be used for more This paper is organized as follows. Section 2 gives an
effective discovery, automation, integration and reuse introduction to the requirements of the matchmaking
across various applications . mechanism in general. The architecture and design of the
OntoServiceMatchmaker (OSM) is described in detail in
An effort of automating service discovery to propose section 3. Section 4 presents the implementation and
interoperable standards such as XML to enable uniform explains the tools used. It also shows the application of
representation of service descriptions and capabilities was the OSM. In section 5, a comparison of other selection
made. However, lack of semantics and inherent non- approaches is discussed and finally, section 6 concludes
uniformity in these XML representations still make this paper.
human intervention necessary. Effective service discovery
is an important issue not only on the Web but also in
every application process where there is a need to tackle
2. Requirements of the Matchmaking Process • The matchmaking process should be efficient, which
means that it should not burden the requester with
excessive delays that would prevent its effectiveness.
An advertisement matches a request, when the
advertisement describes a service that is sufficiently
similar to the service requested. The problem of this
definition is to specify what “sufficiently similar” means. 3. Design and Architecture of the OSM
Basically, it means that an advertisement and a request are
“sufficiently similar” when they describe exactly the same With the advent of Ontology languages, service
service. This definition is too restrictive, because descriptions in DAML+OIL enable advertisement of
providers and requesters have no prior agreement on how service properties and capabilities for service discovery.
a service is represented and additionally, they have very The architecture of the OSM comprises the following
different objectives. A restrictive criterion on components, which are shown in Figure 1. These
matchmaking is therefore bound to fail to recognize components are input/output, process and resource unit.
similarities between advertisements and requests . The resources consist of auxiliary ontology, service
registry, application ontology, DAML+OIL parser, set of
It is necessary to allow matchmaking engines to rules, inference engine and a user selection. Commencing
perform flexible matches, those that recognize the degree with the user interface where the service request is made,
of similarity between advertisements and requests in order the request is forwarded to the process unit. Here, there
to provide a softer definition of “sufficiently similar”. are three selection stages which are [9,10]:
Service requesters should be allowed to decide the degree
of flexibility that they grant to the system. If they allow • Syntactic selection – The service request is compared
little flexibility, they reduce the likelihood of finding syntactically with the provided auxiliary ontology.
services that match their requirements, which means, they • Semantic selection – This selection is responsible of
minimize the false positives, while increasing the false matching any pair of request and advertisement
negatives. On the other hand, by increasing the flexibility semantically based on structural and semantic
of a match, they achieve the opposite effect, that is, they properties of the ontology. The semantic matchmaking
reduce the false negatives at the expense of an increase of is explained in detail in subsection 3.2.
false positives. • User selection – This stage compares the customized
service request with the service advertisement defined
An additional problem related with performing in the registry.
flexible matches is that the matchmaking engine is open
to exploitation from advertisements and requests that are
too generic in the attempt to maximize the likelihood of
matchmaking. For instance, a service may advertise itself
as a provider of everything, rather than to be precise with
what it does and similarly, the requester may ask for any
service, rather than specifying exactly what it expects.
The matchmaking engine can reduce the efficiency of
these exploitations by ranking advertisements based on
the degree of a match supplied with the request.
Considering all these criteria, the matchmaking engine
should satisfy the following:
• The matchmaking engine should support flexible Figure 1: Architecture of the OSM
semantic matching between advertisements and
requests based on the ontology available to the service The matchmaking process is designed with respect to
and the matchmaking engine. the criteria listed in section 2. The processing of a
• Despite the flexibility of the match, the matchmaking received request by the matchmaking engine is explained
engine should minimize false positives and false as follows. Depending on the specified selection stages
negatives. Furthermore, the requesting service should and the defined service ontology, a capability match is
have some control on the amount of matching done. Every pair of request and advertisement has to go
flexibility it allows to the system. through several different selection stages of the
• The matchmaking engine should encourage providers matchmaking process. The user is provided with selection
and requesters to be precise with their descriptions at parameters and after making the selection, the final match
the cost of either not being matched or being matched with the service registry is performed. Information is
inappropriately. provided to the service requester by sending a contact
address and related capability descriptions of the relevant DAML+OIL code facilitates effective parsing of service
service provider. capabilities through its use of generic RDF(S) symbols
compared to DAML+OIL specific symbols.
3.1 Architecture Role in Matching Criteria
The architecture fulfils the matching criteria listed in ="http://www.w3.org/2000/10/XMLSchema#"
section 2 as follows. The OSM supports flexible semantic xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-
matchmaking between advertisements and requests based syntax-ns#"
on the ontology available. Minimizing false positives and ="http://www.daml.org/2001/03/daml+oil#"
false negatives is achieved with three selection stages in xmlns:GridApplication
combination with the well-defined ontology. The ="http://www.brunel.ac.uk/ontology/Jobsubmiss
selection stages restrict the false positives and the xmlns:rdfs ="http://www.w3.org/2000/01/rdf-
ontology restricts the false negatives together with the schema#"
customized input parameters. The matchmaking engine xmlns
should encourage providers and requesters to be precise ="http://www.brunel.ac.uk/ontology/Jobsubmiss
with their descriptions. To achieve this, the service ...
provider follows an XML-based description, which is the <daml_oil:Class rdf:ID="JobSubmission">
ontology language DAML+OIL, to advertise its services <rdfs:comment>Job submission and
and the service requester generates a request in a specified management.</rdfs:comment>
format. Defining the ontology and the selection stages rdf:resource="#JobManagementServices"/>
precisely allows the matchmaking process to be efficient. </daml_oil:Class>
3.2 Semantic Matchmaking Engine rdf:resource="#JobSubmission"/>
The core of the matchmaking module comprises of hema#integer"/>
semantic and user selection, which is shown in Figure 2. </daml_oil:DatatypeProperty>
The application ontology is parsed by a DAML parser. <daml_oil:domain rdf:resource="#JobSubmission
With a defined set of rules, the following inference engine <daml_oil:range
reasons about the value parameters parsed from the rdf:resource="http://www.w3.org/2000/10/XMLSc
ontology. The output parameters of the inference process hema#integer"/>
are given to the user to make the final customized </daml_oil:DatatypeProperty>
selection in the user matching module. The output from <daml_oil:domain rdf:resource="#JobSubmission
the user matching module is the customized service "/>
<rdfs:comment>This ontology identifies the
job submission process of Grid applications.
Figure 3: DAML+OIL Code Fragments of the Application Ontology
An example chosen to demonstrate the DAML+OIL
code is the Job Submission process, which is shown in
Figure 2: Semantic Matchmaking Engine Figure 3. The Job Submission service is responsible for
the actual Job management operations such as
The DAML parser is capable of parsing DAML+OIL submission, cancellation and monitoring of jobs. The
code. The attributes and classes of DAML+OIL describe code is part of an example for a Job execution in a
the concept of the ontology. It characterizes the service heterogeneous computing environment, e.g. such as the
for advertisement, discovery and matchmaking. Parsing Grid . The customization process is made by parsing
the ontology results in extracted values that serve as input the DAML+OIL code which then provides the selection
parameters for the customized matchmaking process. The parameters for the matchmaking process. For example,
parameters such as fastest execution, highest reliability was chosen as a rule-based language .
and cheapest service are extracted. These attributes serve
as input parameters for the inference engine which
performs the match. (defquery query-classes
"Retrieve all daml:Class objects"
Depending on the parameters, the user makes the rdf-syntax-ns#type
choice with the user selection module and regarding these ?x
parameters the service request is matched with the http://www.daml.org/2001/03/daml+oil#Class)
services provided in the registry database. The selected
criteria are responsible for the match and return matched
Figure 4: JESS rule for finding all classes
values depending on a value ranking of the actual service
If datatypes (in Jess syntax PropertyValue) of a
defined class should be found, then the defquery in
The inference engine is capable of reasoning with
DAML+OIL ontologies. By abstracting the behavior it Figure 5 is invoked. The input parameter for the defined
expects from any inference engine, the semantic matching class is declared as variable x in the query. Referring to
module is able to interact with this engine. The the DAML+OIL code fragment shown in Figure 3,
matchmaking component compares a current rule to given defining x in Figure 5 as #JobSubmission results in
patterns. This set of rules can be divided into two the return values ExecutionTime, Reliability
categories. and Price.
One concerns the reasoning of instances of classes and
the other relates to terminological reasoning in order to "Find all types for a given object."
determine relationships between the classes themselves. (declare (variables ?x))
One of the most basic elements of the RDF and DAML (PropertyValue http://www.w3.org/1999/02/22-
languages are the rdfs:subClassOf and ?x
daml:subClassOf statements. These properties are ?y
used to specify a subclass relationship between two )
classes. One of the intuitive notions of this relation is that
any instance of a subclass is an instance of the parent Figure 5: JESS rule for finding all properties of a defined class
class. Utilizing the full power of semantic service
discovery requires inference on the relationships between With the queries shown above, reasoning classes and
classes which is called terminological reasoning. Through attributes of the ontology is achieved in order to provide
DAML’s underlying description logic semantics, objects the selection parameters to the user for the customized
and classes can be automatically compared, contrasted process match.
and reasoned based on the input ontologies.
One of the most common elements in such 4. Implementation of the OSM
descriptions is the definition of a class as the intersection
of a set of classes. This is called conjunction. A common The OSM (Figure 6) is a tool for service discovery
terminological inference is subsumption between such using an ontology-based matchmaking engine. The
intersections. The rule determines subclass relationships customization process is made by a parser which parses
between intersections of classes by implementing the DAML+OIL code and provides the selection
structural subsumption on classes consisting solely of parameters for the match to the user. After the user has
such intersections. Intuitively, the rule implements the selected one or more selection parameter(s), the
idea that a class composed of the intersection of a set of matchmaking engine performs the semantic match of the
classes is a subclass of a class composed of the requested web service with the provided web services.
intersection of a subset of those classes or subclasses of This allows close and flexible matches and permits
those classes. In the case where the two intersections are customization of the matchmaking process.
equivalent, each class will be asserted as a subclass of the
other. This reasoning can be executed for the given The implementation relates to the Job Submission
ontology. service which is part of a Grid environment. The Job
Submission service is responsible for the actual Job
Figure 4 shows a code fragment using the management operations such as submission, cancellation
daml_oil:DatatypeProperty class expression to and monitoring. For the Job Submission process match
define such a relationship. With this query-classes criteria such as fastest execution time, highest reliability
statement, all properties for all classes in the ontology are and cheapest service are available for selection. These
found and returned. Java Expert Systems Shell (JESS) properties are found by parsing the DAML+OIL code.
For this prototype there is no syntactic selection, only SCORE Enhancement Engine (SEE) is a component of a
the semantic and user selection are implemented. As Semantic Web technology called the Semantic Content
previously shown, for the service application ontology Organization and Retrieval Engine (SCORE). SEE
DAML+OIL was chosen as it provides a representative supports heterogeneous content as well as following up
notion of semantics for describing services. DAML+OIL automatic classification with extraction of contextually
allows subsumption reasoning on concept taxonomies. relevant, domain-specific metadata. Extraction of
Furthermore, DAML+OIL permits the definition of semantic metadata includes identification of relevant
relations between concepts. For the inference engine rules entities and also relationships within the context of
were defined using the JESS language. This API relevant ontologies.
(Application Programming Interface) is intended to
facilitate interpretation of information of DAML+OIL Retsina Matchmaker (RM) is another example of these
files, and allowing users to query on that information. It examples . RM is an information agent that helps make
leverages the existing RDF API to read in the connections between agents that request services and
DAML+OIL file as a collection of RDF triples. agents that provide services. The matchmaking engine
serves as a "yellow pages" of agent capabilities, matching
service providers with service requesters based on agent
capability descriptions. The Matchmaker system allows
agents to find each other by providing a mechanism for
registering each agent's capabilities. An agent's
registration information is stored as an "advertisement".
This provides a short description of the agent, a sample
query, input and output parameter declarations, and other
The difference between the OSM presented in this
paper with the SEE and the RM is that it allows a
customized matchmaking process by enabling selection of
input match values. The matchmaking process is therefore
more flexible and can serve better defined users’ needs.
Figure 6: Web User Interface of the OSM However, the main problem of dynamic matchmaking for
Web-based applications is to deal with the trade-off
This prototype system is based on web services between performance and quality of matchmaking.
technology standards. The implementation of the web Complex reasoning has to be restricted to allow
services was done in Java using WSDL (Web Service meaningful semantic matches of requests and
Description Language), XML (Extensible Markup advertisements in a reasonable time. The presented
Language) and SOAP (Simple Object Access Protocol). matchmaking process offers a flexible approach to satisfy
SOAP and WSDL are designed to provide descriptions of these matchmaking requirements.
message transport mechanisms in order to describe the
interface used by each service. A service registry, UDDI
(Universal Description, Discovery and Integration)  6. Conclusion
was used. UDDI is another emerging XML-based
standard to provide a registry of business by their physical With the phenomenal growth of electronically
attributes such as name, address and the services available information and the emergent e-commerce,
provided. In addition, UDDI descriptions are augmented ontology development environments will reduce system
by a set of attributes that are called TModels. They development time. This facilitates system interoperability
describe additional features such as the classification of through the use of a common methodology and a
services within taxonomies e.g. NAICS (North American corresponding representation.
Industry Classification System) or UNSPSC (United
Nations Standard Products and Services Code). The An ontology-based service discovery tool, called
UDDI registry is used for the final selection stage which OSM, which allows flexible and customized semantic
is the user selection. The actual service is matched with matches of service requests was presented. The
the modified and customized service request. matchmaking engine is capable of parsing DAML+OIL
marked properties and allows the user to customize the
matchmaking process accordingly. The description
5. Comparison of the OSM with other properties and functional attributes are properties for the
Matchmaking Approaches matchmaking values. These properties found by the
ontology parser serve for the matchmaking process as
A few projects address semantic service matchmaking input variables, where it defines the matchmaking criteria
issues such as the Semantic Enhancement Engine . for the matchmaking process. This facilitates semantic
and customized service discovery. Allowing a flexible  M. Klein and D. Fensel, Ontology versioning for the
matchmaking process most likely returns multiple service Semantic Web, In Proceedings of the International
matches. The selection and parameterization for the Semantic Web Working Symposium (SWWS),
inference process can reduce and customize the return California, USA (2001).
values. This concept has the advantage of the flexibility of  S. Bechhofer and C. Goble, Towards Annotation
ontology changes. Whenever the ontology changes, the using DAML+OIL, K-CAP 2001 Workshop on
reasoner provides the matching parameters for the user Knowledge Markup and Semantic Annotation,
selection process accordingly. Victoria B.C. (2001).
 D. Fensel, I. Horrocks, F. van Harmelen, S. Decker,
There is an obvious trade-off between the quality and M. Erdmann and M. Klein, OIL in a nutshell, In
efficiency of matchmaking of Web-based applications on Proceedings of EKAW-2000, LN AI (2000).
the Internet. This trade-off needs to be considered  DAML, Darpa Agent Markup Language Program.
carefully for every application process. http://www.daml.org.
 DataTAG Project.
7. Acknowledgement  M. Paolucci, T. Kawamura, T. R. Payne and K.
Sycara, Semantic Matching of Web Services
I would like to thank everyone supporting this work Capabilities, Proceedings International Semantic
and collaborating in the DataTAG project. This research Web Conference (ISWC 2002).
is funded by PPARC (Particle Physics and Astronomy  S.A. Ludwig and P. van Santen, A Grid Service
Research Council, UK) through the IST program of the Discovery Matchmaker based on Ontology
European Union (Grant IST-2001-32459) and forms part Description, Proceedings of the International
of work package 4 of the DataTAG project. EuroWeb 2002 Conference, Oxford, UK (2002).
 S.A. Ludwig, An Ontology-based Service Discovery
The author would like to thank Dr. M. Reyhani for his Matchmaking Framework, accepted for publication
helpful suggestions. Furthermore, I would like to thank in Special Issue on Semantic Grid and Knowledge
Prof. P. Clarke for his help. Grid, Future Generation Computer Systems (FGCS
 I. Foster, The Grid: Blueprint for a New Computing
References Infrastructure, Morgan-Kaufman (1999).
 JESS, Java Expert Systems Shell.
 W3C Semantic Web Activity Statement: W3C's http://herzberg.ca.sandia.gov/jess/docs/61/index.html.
Technology and Society domain (2001).  UDDI Technical White Paper.
 S.A. Ludwig, Review of various Service Discovery te_Paper.pdf.
Systems, Technical Report, TR-DGRG695,  B. Hammond, A. Sheth, K. Kochut, Semantic
Department of Electronic and Computer Engineering, Enhancement Engine: A Modular Document
Brunel University, UK (2002). Enhancement Platform for Semantic Applications
over Heterogeneous Content, Real World Semantic
Web Applications Journal, pp. 29-49, IOS Press