Matchmaking Portal for the Discovery of Numerical and Symbolic
Services
Simone A. Ludwig1 , Omer F. Rana1 , William Naylor2 and Julian Padget2
1
School of Computer Science/Welsh eScience Centre, Cardiff University
2
Department of Computer Science, University of Bath
Abstract
A significant number of applications within eScience make use of numerical algorithms, developed as part of a project
or obtained from third parties such as numerical libraries from the Numerical Algorithms Group (NAG). The complexity
of such algorithms can vary from simple matrix solving to more complex data analysis functions such as clustering or
classification techniques. The ability to access such algorithms as Web Services allows easy integration of such capability
within existing applications while also providing a loose coupling between the application and the numerical algorithm.
The matchmaking portal developed focuses on the provision, discovery and use of mathematical services.
1
Introduction
The deployment of agent/Web Services is increasing this
creates a problem for software agents that is the analog of the
human user searching for relevant HTML pages. Humans
typically use Google, but they can filter out the irrelevant and
spot the useful, so while UDDI (the Web Services registry)
with keyword searching essentially offers something similar, it is a long way from being very helpful. Consequently,
there has been much research on matchmaking architectures,
such as Infosleuth [8], LARKS [10], and IBROW [6] and its
significance is underlined in the following quote:
”Matchmaking is an approach based on emerging information integration technologies whereby
potential producers and consumers of information
send messages describing their information capabilities and needs. These descriptions, represented in rich, machine-interpretable description
languages, are unified by the matchmaker to identify potential matches.” [7]
be available. The functionality being demonstrated comprises of the matchmaker for mathematical services. Service
descriptions including pre- and post-conditions are provided
in an XML-based language (OpenMath [11]). OpenMath
has been adopted as it is being widely used by developers of
mathematical libraries such as NAG. OpenMath is intended
to be a standard for representing mathematical objects, and
for exchanging them between computer programs. There
is a strong relationship with the MathML [9] recommendation from the Worldwide Web Consortium, and a large
overlap between the two developer communities. Whereas
MathML deals principally with the presentation of mathematical objects, OpenMath is solely concerned with their
semantic meaning or content.
2
2.1
Matchmaking Portal
Mathematical Service Description
Mathematical services are represented in OpenMath syntax.
OpenMath is based on the concept of Content Dictionaries
(CDs). These are definition repositories in the form of files
It is perhaps telling that much of the literature ap- defining a collection of related symbols and their meanings,
pears to focus on architectures for brokerage, which are as together with various Commented Mathematical Properties
such domain-independent, rather than concrete or domain- (for human consumption) and Formal Mathematical Propspecific techniques for identifying matches between a task erties (for machine consumption), In other words each CD
or problem description and a capability or service descrip- is a small, specialised ontology.
tion.
The matchmaking portal1 developed focuses on the proviOpenMath expressions are composed of a small number
sion, discovery and use of mathematical services. The portal of primitives. The definition of these may be found in [11],
assumes that in the future we are likely to see a service-rich but four of the more commonly used symbols are: OMA
environment where mathematical libraries as services will (OpenMath Application), OMI (OpenMath Integer), OMS
1 http://agentcities.cs.bath.ac.uk:8080/
genss axis/GENSSMatchmaker/index.htm
(OpenMath Symbol) and OMV (OpenMath Variable). Symbols are used to represent objects defined in the CDs, with at-
tributes cd to specify the CD and name to specify the symbol. Symbols may represent basic mathematical objects e.g.
Z (the integers) is represented by:2
<om:OMS cd="setname1" name="Z"/>
that is the symbol Z from the CD setname1. Or they may
represent more complex mathematical objects, e.g. the application of a function where the element is <om:OMA> with
the first child being the function and the rest being the arguments. OpenMath variables have a name attribute to specify
the name of the variable. OpenMath integers are just containers for an integral value. As an example, consider the
algebraic expression x2 − y 2 , this could be represented in
OpenMath as:
<om:OMOBJ>
<om:OMA>
<om:OMS cd="arith1" name="minus"/>
<om:OMA>
<om:OMS cd="arith1" name="power"/>
<om:OMV name="x"/>
<om:OMI>2</om:OMI>
</om:OMA>
<om:OMA>
<om:OMS cd="arith1" name="power"/>
<om:OMV name="y"/>
<om:OMI>2</om:OMI>
</om:OMA>
</om:OMA>
</om:OMOBJ>
where the symbols minus and power are defined in the
CD arith1.
2.2
Functionality and Architecture
The portal developed consists of an architecture which supports five kinds of match modes these include:
1. Basic structural match: this mode compares the XML
tree structure of the OpenMath describing the query
with that describing the service description (residing in
the repository).
2. Syntax and ontology match: this mode first performs
a structural match, and then performs a syntax match
based on the attribute values of the OMS elements, and
some inclusion rules referring to certain (set valued)
OpenMath symbols.
3. Algebraic equivalence match: this mode compares the
query with the service description by using algebraic
means. Algebraic equivalence in this context is primarily related to how mathematical expressions can be rewritten.
Figure 1: Sequence Diagram - Service Request
between the expressions for the task and capability.
Equivalence is determined if the difference returns 0.
This is not a deterministic process, however, as the values may have coincided with a root of the expression,
for a non identically zero expression. Effectively this
match is a Monte Carlo technique and can only guarantee correctness to a certain probability.
5. Decomposition match: in case an exact service match
cannot be found, the decomposition match will attempt
to discover an equivalent mathematical expression. Essentially, this involves dividing the query into subqueries, and trying to find a match for each decomposed
sub-query. The decomposition is supported by applying a set of rules that try to match each service description. The rules are applied recursively to decompose
a mathematical expression into a normal form with respect to the given set of rules.
The matchmaker uses the individual match scores from each
of the plug-ins above to compute a ranking of matched services.
The matchmaking architecture comprises the following:
• The Client interface: this is employed by the user to
specify their service request.
• The Matchmaker: this consists of a reasoning engine
and the matching module.
• Matching algorithms: where the logic of the matching
is defined.
4. Value substitution match: this mode compares numerical valued expressions in the task descriptions with
numerical valued expressions in the capability descriptions, by substituting suitable values into the difference
• Mathematical ontologies: eg. OpenMath Content Dictionaries (CDs), GAMS (General Algebraic Modeling
System), etc..
2 The prefix om is used to denote the namespace: http://www.
openmath.org/
• A registry service: this enables storage of the mathematical service descriptions.
Figure 2: List Services
• Mathematical Web Services: which are available on
third party sites, accessible over the Web.
Figure 3: Service Invocation
The sequence diagram in Figure 1 shows the interactions of
a search request as follows: (1) the user contacts the matchmaker, then (2) the matchmaker loads the matching algorithms specified by the user; in the case of an ontological
match, further steps are necessary (3) the matchmaker contacts the reasoner which in turn loads the corresponding ontology (4) having additional match values results in the registry being queried, to see whether it contains services which
match the request and finally (5) service details are returned
to the user via the matchmaker. The parameters stored in the
registry (a database) are service name, URL, taxonomy, input, output, pre- and post-conditions. Using contact details
of the service from the registry, the user can then invoke the
Web Service.
2.3
Portal Description
There are two things which can be done with the portal:
• List the services in the registery.
Figure 4: Search Services - Input Screen
• Search the available services for a given task description
The List services page, shown in Figure 2, lists all mathematical services stored in the repository displaying service
name and service URL. By clicking on the service name another screen opens displaying the service details. These are:
(i) the service name, (ii) the service URL, and (iii) the preand post-conditions in OpenMath syntax. By clicking on the
service URL another screen pops up allowing to invoke the
mathematical service (Figure 3).
The Search services page, shown in Figure 4, allows the
user to search for mathematical services expressing queries
in OpenMath syntax. This screen contains a section where
the number of pre- and post-conditions can be given in order
to provide the input fields for the pre- and post-conditions.
The match mode section provides the five matching modes
(structural, ontological, algebraic equivalence and substitution).
The Search for Matches button performs the matchmaking depending on the match mode chosen. The results of
matched services, shown in Figure 5, are displayed in the table Returned Matches showing the service details. These are
(i) the service name, (ii) service URL, (iii) match type and
(iv) three match score numbers for pre-, post-conditions and
overall respectively. We have registered three services with
the portal which are from disparate areas of mathematics and
therefore provide a useful test of our prototype. These services are:
• Factorisor – this performs factorisation of a square free
integer.
• Quad-Sieve – this performs a quadratic sieve on an integral interval.
• LU decomposition – this performs an LU decomposi-
Figure 5: Search Services - Matched Services
and platform-independent.
• The matchmaking service is implemented as a Web
service using WSDL (Web Service Description Language) and SOAP (Simple Object Access Protocol) [5].
WSDL provides a simple way for service providers to
describe the basic format of requests to their systems
regardless of the underlying protocol (such as SOAP
or XML) or encoding (such as Multipurpose Internet
Messaging Extensions).
• The matchmaking algorithms are themselves implemented as web services and are registered in a
UDDI [5] registry, a Web-based distributed directory
that enables businesses to list themselves on the Internet and discover each other, similar to a traditional
phone book’s yellow and white pages. This allows the
matchmaking service to dynamically load the different
matchmaking algorithms specified.
• The service registry is implemented as a database
to store the mathematical service descriptions using
MySQL [4] an open source database.
• The ontology service consists of an OWL ontology and
a JESS (Java Expert Systems Shell) [3] engine as a
reasoner. JESS was chosen as a rule-based language
for the matchmaker as it provides the functionality for
defining rules and queries in order to reason about the
ontologies specified.
• The Mathematical Web services provide the numerical
and symbolic services.
2.4.1
Differences to the JSR 168 and WSRP Standard
A portal is a Web application that typically provides end
users with personalisation, single sign-on, security and content aggregation from different sources. It is the responsibility of a portlet container to run portlets, providing them
with a runtime environment and managing their life cycles.
Figure 6: Matchmaking Portal Implementation
The container also persists portlet user preferences, enabling
a customized end-user experience. The Java Specification
Request for the Portlet Specification, standard JSR 168, articulated by the Java Community Process, aims to provide
tion of a matrix
a standard for portlets. The specification defines a contract
The user can then select and invoke a returned service by between a portlet and the portlet container that powers it. Arclicking on the link provided. If the Quad-Sieve service were eas covered by the APIs defined in the specification include
chosen then Figure 3 would be displayed.
topics such as aggregation, personalisation, presentation and
security. In order to enable interoperability between portlets
and portals these concepts needed to be addressed by a spec2.4 Implementation
ification. An example for an implemented JSR standard is
Figure 6 shows the implementation of the matchmaking por- GridSphere [1], which is a portal framework and provides
tal. This prototype system is based on the latest Web Service an open-source portlet based Web portal.
technology standards. It consists of the following compoThe standardisation of Web Services for Remote Portlets
nents:
(WSRP) goes one step further by specifying the remote ren• The Client portal is built as a web client using Java dering of portlets. WSRP enables the functionality of deServer Pages (JSPs) [2]. JSP provides a simplified, fast ploying portlets once delivering them anywhere. This allows
way to create dynamic web content and enables rapid bringing together third-party portlets and enhances interopdevelopment of web-based applications that are server- erability between portals from different vendors.
Both standardisation efforts moves the work of portals
and portlets towards a unified, federated portal framework,
where sharing portal componets paves the way for sharing
business services. Federated portals allow for increased flexibility in the sharing of content between different business
units and partners.
The matchmaking portal described here does not match
the JSR 168 standard in that it has no personalisation, no
sign-on and no security. This is because the portal primarily
focuses on a proof of concept prototype. However, signon and security issues must be considered in the case of a
more commercial usage, for example provision by NAG of
a mathematical service library.
3
Example - Factorisor Service
Figure 7: Factorisor Service
The Factorisor service was chosen as an example. This service finds all prime factors of an Integer. The Factorisor has
the following post-condition:
<om:OMS cd=’relation1’ name=’eq’/>
<om:OMA>
<om:OMS cd=’integer1’ name=’remainder’/>
<om:OMV name=’n’/>
<om:OMA>
<om:OMS cd=’list2’ name=’list_selector’/>
<om:OMV name=’i’/>
<om:OMV name=’lst_fcts’/>
</om:OMA>
</om:OMA>
<om:OMS cd=’alg1’ name=’zero’/>
</om:OMA>
</om:OMA>
</om:OMBIND>
</om:OMOBJ>
<om:OMOBJ>
<om:OMA>
<om:OMS cd =’relation1’ name =’eq’/>
<om:OMV name =’n’/>
<om:OMA>
<om:OMS cd =’fns2’ name =’apply_to_list’/>
<om:OMS cd =’arith1’ name =’times’/>
<om:OMV name =’lst_fcts’/>
</om:OMA>
</om:OMA>
</om:OMOBJ>
where n is the number a user wishes to factorise and
lst_fcts is the output list of factors.
The post-condition for the Factorisor service represents:
n=
l
Y
this represents the following mathematical statement:
∀i|1 ≤ i ≤ |lst fcts| ⇒ n mod lst fctsi = 0
(2)
where l = |lst fcts|
(1) which is equivalent to equation 1. A match should occur if
enough mathematical knowledge is available in the system.
In practice, this is only achievable in the algebraic equivaConsider the situation where a user specifies that he is
lence and substitution match modes. The user should get a
searching for a service with the following post-condition:
match with the Factorisor service which can then be invoked
<om:OMOBJ>
(Figure 7). The given input parameter is:
lst fctsi
i=1
<om:OMBIND>
<om:OMS cd=’quant1’ name=’forall’/>
<om:OMBVAR>
<om:OMV name=’i’/>
</om:OMBVAR>
<om:OMA>
<om:OMS cd=’logic1’ name=’implies’/>
<om:OMA>
<om:OMS cd=’logic1’ name=’and’/>
<om:OMA>
<om:OMS cd=’relation1’ name=’leq’/>
<om:OMS cd=’alg1’ name=’one’/>
<om:OMV name=’i’/>
</om:OMA>
<om:OMA>
<om:OMS cd=’relation1’ name=’leq’/>
<om:OMV name=’i’/>
<om:OMA>
<om:OMS cd=’list2’ name=’size’/>
<om:OMV name=’lst_fcts’/>
</om:OMA>
</om:OMA>
</om:OMA>
<om:OMA>
<om:OMI> 10403 </om:OMI>
and the returned values are the prime factors 101 and 103.
4
Conclusion
With the portal implementation we have presented an approach to matchmaking in the context of mathematical Web
services. The semantic description of mathematical services, expressed in OpenMath syntax, greatly assists in identifying suitable services in some cases, but also significantly
complicates matters in others, due to the inherent richness
of the mathematical description. Consequently, we have put
forward an extensible matchmaker architecture supporting
plug-in matchers that may employ a variety of reasoning
techniques, utilising theorem provers and computer algebra
systems as well as information retrieval from textual documentation of mathematical routines. Although our set of test
cases is as yet quite small, the results are promising and we
foresee the outputs of the project being of widespread utility
in both the e-Science and Grid communities, as well as more
generally advancing semantic matchmaking technology.
5
Acknowledgments
The work reported here is partially supported by the Engineering and Physical Sciences Research Council under the
Semantic Grids call of the e-Science program (grant reference GR/S44723/01).
References
[1] GridSphere Portal Framework.
Available
from
http://www.gridsphere.org/
gridsphere/gridsphere.
[2] J2EE JavaServer Pages Technology. Available from
http://java.sun.com/products/jsp/.
[3] Java Expert Systems Shell.
Available from
http://herzberg.ca.sandia.gov/jess/
docs/61/index.html.
[4] MySQL Database. Available from http://www.
mysql.com/.
[5] A.E. Walsh. UDDI, SOAP, and WSDL: The Web
Services Specification Reference Book, 2002. UDDIORG.
[6] V.R. Benjamins, B. Wielinga, J. Wielemaker, and
D. Fensel.
Towards Brokering Problem-Solving
Knowledge on the Internet. In Dieter Fensel and
Rudi Studer, editors, Proceedings of the 11th European Workshop on Knowledge Acquisition, Modeling
and Management (EKAW-99), volume 1621 of LNAI,
pages 33–48, Berlin, May 26–29 1999. Springer.
[7] D. Kuokka and L. Harada. Matchmaking for information integration. Journal of Intelligent Information Systems, Feb 1996.
[8] W. Bohrer M. Nodine and A.H. Ngu. Semantic brokering over dynamic heterogenous data sources in infosleuth. In Proceedings of the 15th International Conference on Data Engineering, pp. 358-365, 1999.
[9] MathML. Mathematical markup language (mathml)
version 2.0, www. Available from http://www.
w3.org/Math/.
[10] K. Sycara, S. Widoff, M. Klusch, and J. Lu. Larks: Dynamic matchmaking among heterogeneous software
agents in cyberspace. Journal of Autonomous Agents
and Multi Agent Systems, 5(2):173–203, June 2002.
[11] The OpenMath Society.
The OpenMath
Standard, October 2002.
Available from
http://www.openmath.org/standard/
om11/omstd11.xml.