Re: R: sws matchmaker contest

People,
	It is worth thinking about Matchmaking in the wider context than as  
an Information Retrieval task.  The notion of Matchmaking has been  
well explored already within the Multi-Agent Systems community as one  
of several ways of discovering services (or agent capabilities)  
within a dynamic *run-time* environment for autonomous systems.  Take  
a look at the folllowing papers:

	Klusch, M. and Sycara, K. 2001. Brokering and matchmaking for  
coordination of agent
	societies: A survey. In Coordination of Internet Agents, A. Omicini,  
F. Zambonelli,
	M. Klusch, and R. Tolksdorf, Eds. Springer.

	Sycara, K., Widoff, S., Klusch, M., and Lu, J. 2002. Larks: Dynamic  
matchmaking
	among heterogeneous software agents in cyberspace. Autonomous Agents  
and Multi-
	Agent Systems 5, 2, 173–203.


An important notion here is that of whether there is a user in the  
loop.  Consider the following:

1) There is a user that selects from matching services (relating to  
Tommaso's first point).
Discovering, ranking and returning matched services is a useful  
task.  The mechanism for comparing a given query with a corpus or  
repository of service descriptions is indeed important.  But also  
consider the following:
	* How was the query specified?  By the user?
	* How do they know the details of the available inputs that can be  
provided to the service?
	* Is this mediated by a tool?
	* Are there any human oriented annotations in the service  
descriptions?  Expecting novices to understand the details of a  
service from a piece of OWL is unrealistic (as is expecting a  
reasoner to understand an unstructured natural language description)...

Ok, so now we have the query, and we get a list of resources that  
best fulfil the query.
	* Can the user understand the resulting description?
	* Can the user understand *why* the match was made?
	* Can we ensure that the user's system has access to the knowledge  
that matchmaker has which was used to achieve the match, so they  
themselves can achieve the same reasoning between query and match?

Its all very well for a matchmaker to realise that a query matches an  
advert, but the user needs to understand *how* they match so that the  
service can subsequently be used!

2) There is no user in the loop, rather the service is used  
automatically (relating to Tommaso's second point).
Discovering and re-provisioning a service at run time is essential  
for dealing with failure and unexpected situations, and it is not  
always realistic to expect a user to be on hand to help select  
services when a runtime failure occurs.  But in which case:
	* How does the service requester determine which of the returned  
services fully fulfils the query, and which are acceptable but not  
ideal?
	* How is the raking performed, and can the requester define this  
(will the requester have to re-reason over the returned list)?
	* How do we identify cases where a partial match is acceptable in  
some cases, but not in others?
Here, I am assuming the requester is an automated process, rather  
than a user...

If we ignore these issues, we run the risk of developing great  
matching mechanisms, which may not be pragmatically usable.
Anyway, this is my two-penny worth :)

	Terry

P.S. Tommaso - what's been going on with the weather in Bari this  
summer?  I should have stayed in the UK!!! :)



On 25 Aug 2006, at 12:04, Tommaso Di Noia wrote:

>
> Matchmaking is a widely used term in a variety of frameworks,  
> comprising
> several --quite different-- approaches. With my group we defined  
> matchmaking
> and semantic matchmaking as follows:
>
> [Matchmaking] Matchmaking is an information retrieval task whereby  
> queries
> (in this case WS requests) and resources (in this case WSs) are  
> expressed
> using semi-structured text in the form of  advertisements, and task  
> results
> are ordered (ranked) lists of those resources BEST FULFILLING the  
> query.
>
> [Semantic Matchmaking] Semantic matchmaking is a matchmaking task  
> whereby
> queries and resources advertisements are expressed with reference to a
> shared specification of a conceptualization for the knowledge  
> domain at
> hand, i.e. an ontology.
>
> Then, semantic matchmaking is very useful in the discovery (which is
> preliminary to invocation) of WSs potentially satisfying the user  
> request
> for at least the following two main reasons:
>
> 1. In case a matchmaking system does not return any WS completely  
> satisfying
> her request, the user can look for something similar to her original
> request. This process is supported by the ranked nature of the  
> returned list
> of WSs.
>
> 2. Once the ranked list of WSs is returned, a system has a  
> criterion to
> automatically choose different WSs to be invoked in case of failure or
> unavailability of a WS.
>
> -- Tommaso  
>
>> -----Messaggio originale-----
>> Da: public-sws-ig-request@w3.org
>> [mailto:public-sws-ig-request@w3.org] Per conto di Xuan Shi
>> Inviato: venerdì 25 agosto 2006 6.26
>> A: dellava@cefriel.it; klusch@dfki.de
>> Cc: public-sws-ig@w3.org
>> Oggetto: Re: sws matchmaker contest
>>
>>
>> According to W3C specification @
>> http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/
>>
>> "Web service
>>
>> There are many things that might be called "Web services" in
>> the world at large. However, for the purpose of this Working
>> Group and this architecture, and without prejudice toward
>> other definitions, we will use the following definition:
>>
>> A Web service is a software system designed to support
>> interoperable machine-to-machine interaction over a network.
>> It has an interface described in a machine-processable format
>> (specifically WSDL). Other systems interact with the Web
>> service in a manner prescribed by its description using
>> SOAP-messages, typically conveyed using HTTP with an XML
>> serialization in conjunction with other Web-related standards."
>>
>> Semantic Web Services Challenge 2006 contest has complied
>> with the above W3C specification, but it seems the proposed
>> sws matchmaker contest may include other kind of "services".
>> I hope the organizors will pay attention to W3C's statement:
>> - There are many things that might be called "Web services"
>> in the world at large - otherwise people will be confused
>> again by such vague terminologies.
>>
>> The problem for the Semantic Web Services Challenge 2006 is,
>> the organizors used lots of "fake services". Such fake
>> services, for example, muller.wsdl, racer.wsdl, runner.wsdl,
>> walker.wsdl, etc. only provided a simplified interface like
>> "function F (inputObject): outputObject". However, in real
>> world practice, functional interface can be more complex.
>>
>> Given the following "fake services", three Web service
>> developers develop exactly the same kind of service/function
>> with the same service and function name, the same interface
>> structure (three input objects and 1 output object), and the
>> same input/output object name, but with different order of
>> the input objects documented in WSDL or OO diagram:
>>
>> service: function F(obj1, obj2, obj3):obj4
>> service: function F(obj3, obj2, obj1):obj4
>> service: function F(obj1, obj3, obj2):obj4 (...we can have
>> more different combinations of course)
>>
>> Can I say that by matchmaking, machine will understand that
>> all these three services and functions can do the same thing?
>> But can you say that such a result from matchmaking or
>> service composition will enable the dynamic invocation of
>> such services, i.e. "without any reprogramming, a software
>> system could have the flexibility to use various services
>> that do the same kind of job but have different APIs"
>> (Burstein 2004) - the last and final goal of SWS ? It seems
>> not because to invoke such services, we have to reprogram
>> something in such process as: obj4 = service.F(obj1, obj2,
>> obj3), or obj4 = service.F(obj3, obj2, obj1), or obj4 =
>> service.F(obj1, obj3, obj2), in case any of them does not
>> work we have to sue the other services.
>>
>> If adding semantic annotation into WSDL cannot enable the
>> dynamic invocation of services, the last and final goal of
>> SWS, such service matchmaking and compostion contest should
>> add some more challenges with a focus on the real world
>> practice and existing Web services to see how the result
>> contributes to the last and final goal of SWS.
>>
>> Regards,
>>
>> Xuan
>>
>>
>>
>>>>> Matthias Klusch <klusch@dfki.de> 08/24/06 1:17 PM >>>
>>
>> Dear Emanuele,
>>
>> thanks for your feedback!!
>>
>> We are of course aware of the sws challenge and in part
>> impressed by the results produced (only WSDL services were
>> provided for the scenarios).
>> however, the planned matchmaker contest aims at obtaining the
>> results of a comparative evaluation of the recall/precision,
>> and runtime performance of different owl-s / wsmo matchmaker
>> over a given owl-s / wsmo service retrieval test collection
>> (like TREC in the IR domain). if there is a chance to obtain
>> such results from the recent sws challenge, pls let us know.
>> another related event is at this year's ISWC, however, the
>> organisers told us that they want to focus on business sws
>> certification but not sws retrieval.
>>
>> cordial regards, matthias
>>
>> Emanuele Della Valle schrieb:
>>
>>> Dear Matthias,
>>>
>>> a similar activities is ongoing within the Semantic Web
>> Services the challenge discovery scenario [2] and the related
>> test cases.
>>>
>>> The solutions to the challenge collected in June are
>> available at [3]
>>>
>>> Best regards,
>>>
>>> Emanuele
>>>
>>> [1] http://sws-challenge.org/wiki/index.php/Main_Page
>>> [2]
>>> http://sws-challenge.org/wiki/index.php/Scenario:_Shipment_Discovery
>>> [3] http://sws-challenge.org/wiki/index.php/Workshop_Budva
>>>
>>> --
>>> Emanuele Della Valle
>>> CEFRIEL - Politecnico di Milano
>>> Via Fucini, 2 * 20133 Milano (Italy)
>>> p. +39 0223954324 e. dellavalle@cefriel.it f. +39 0223954524 w.
>>> http://swa.cefriel.it/ http://www.linkedin.com/in/emanueledellavalle
>>>
>>>
>>>> -----Original Message-----
>>>> From: public-sws-ig-request@w3.org
>>>> [mailto:public-sws-ig-request@w3.org]
>>>> On Behalf Of Matthias Klusch
>>>> Sent: mercoledì 23 agosto 2006 15.51
>>>> To: public-sws-ig@w3.org
>>>> Subject: sws matchmaker contest
>>>>
>>>>
>>>>
>>>> dear all,
>>>>
>>>> in due course of planning a semantic web service matchmaker
>> contest, i
>>>> am currently looking for
>>>>
>>>> * all kinds of *implemented* owl-s or wsmo matchmakers
>>>>   in particular those which have not been published yet,
>>>>   but might be interested in participating in such a contest.
>>>>
>>>> * partners that would be willing to initiate or further
>> develop service
>>>>   retrieval test collections for measuring the retrieval
>> performance of
>>>>   these matchmakers such as the owls-tc v2 for owl-s (i do not know
>>>>   yet of any wsmo test collection)
>>>>
>>>> any feedback is highly appreciated!
>>>>
>>>> cordial regards,
>>>> matthias
>>>>
>>>> __________________________________________________
>>>> Dr. Matthias Klusch
>>>> German Research Center for Artificial Intelligence
>> Stuhlsatzenhausweg
>>>> 3
>>>> 66123 Saarbruecken, Germany
>>>> Phone: +49-681-302-5297, Fax: +49-681-302-2235
>>>> http://www.dfki.de/~klusch/, klusch@dfki.de
>>>> __________________________________________________
>>>>
>>>>
>>>
>>>
>>
>> --
>> __________________________________________________
>> Dr. Matthias Klusch
>> German Research Center for Artificial Intelligence
>> Stuhlsatzenhausweg 3
>> 66123 Saarbruecken, Germany
>> Phone: +49-681-302-5297, Fax: +49-681-302-2235
>> http://www.dfki.de/~klusch/, klusch@dfki.de
>> __________________________________________________
>>
>>
>>
>
>



_______________________________________________________________________
Terry R. Payne, PhD.                | http://www.ecs.soton.ac.uk/~trp/ 
index.html
School of Elec. & Comp Sci       | Skype: cappuccinofreak         
[AIM: drcaphreak]
University of Southampton         | Voice: +44(0)23 8059 8343   [Fax:  
8059 2865]
Southampton, SO17 1BJ, UK    | Email: terry@acm.org /  
trp@ecs.soton.ac.uk

Received on Friday, 25 August 2006 10:53:44 UTC