Re: Matchmaking and subsume/plugin filters

German,

sorry for my late answer, I did not monitor this list for a while.

gerhecar@alumni.uv.es wrote:

>I have some questions about this concepts which are mentioned 
>in "Semantic Matching of web services" from Paolucci&all in 2002. 
>I understand about plugin matching when the provider has a OutputA 
>more general than the OutputR from requester, and this classes hasn't 
>have a subclassOf relation.
>And the subsume relation is when the provider has a outputA more 
>specific (or restricted) than the OutputR from requester, and no 
>subclassOf relation between these classes.
>Is it ok??
>  
>
I don't think it is right.  In OWL (and in DAML+OIL which we used in the 
paper you cite)  a concept is more general than another  if there is a 
subsumption  (subclass) relation ,  or if the relation  can be  inferred 
by an inference engine.

>For example, I have the next Ontology:
>
>		Camera
>		  |
>           ----------------
>           |		  |
>      DigitalCamera    DigitalCamera_and_Flash
>
>DigitalCamera is subclassOf Camera and have one restriction: R1 --> 
>isDigitalCamera = Yes        DigitalCamera --> Camera & R1
>DigitalCamera_and_Flash  is subclassOf Camera and have two 
>restriction: R1 --> isDigitalCamera = Yes and R2--> hasFlash = 
>Yes        DigitalCamera_andFlash --> Camera & R1 & R2
>
>If in my profilerequest I request a DigitalCamera_and_Flash, and I 
>have 2 providers: Provider1 which offers Camera (more general) and 
>Providers2 which offers DigitalCamera.
>If you read the matching algorithm from the text of Paloucci&cia, 
>first it compare if OutputR == OutputP, 
>
This is correct.

>then if OutputR subclassOf 
>OutputA and the the plugin and subsume filter.
>The first filter in my example doesn't matching anything
>The second filter in my example matchs the provider1 because OutputR 
>issubclassOf OutputA.
>the third filter matchs the provider2 because OutputA is more general 
>(or minus restrictive) than OutputR. --> is it correct? Is this the 
>plugin concept and the correct behaviour of a matchmaker?
>
I am a bit confused here,  but the only match in your case is Provider1 
because it offers an output that is more general than what you asked.  
Provider2 is not matched by any of the filters because DigitalCamera is 
a sibling of DigitalCamera_and_Flash and therefore there is no 
subsumption relation.

>If it's correct, the third filter offers a better provider than 
>second, because the provider2 offers a digitalcamera (near my 
>request), and the provider1 provides a worst service (only offers 
>camera).
>Why a better filter (second filter) offers worst providers than a 
>plugin filter offers?
>  
>
I am not quite sure what you mean with first, second and third filter.  
But using your ontology Provider2 that provides DigitalCamera is never 
matched.

Note that your ontology and the assumptions that you make about it are 
not correct.  DigitalCamera_and_flash should be a subclass of 
DigitalCamera (essentially every instance of  DigitalCamera_and_Flash 
can be an instance of DigitalCamera.)  If the ontology is constructed 
this way than the request will match both Provider1 and Provider2.

>Another question: if I define DigitalCamera with the sameclassAs
>
>DigitalCamera is sameClassAs Camera and have one restriction: R1 --> 
>isDigitalCamera = Yes        DigitalCamera <--> Camera & R1
>When I use a reasoner (Fact,SeBOR in my case) , it puts 
>DigitalCamera_and_Flash as subClassOf DigitalCamera and when i have 
>the same providers and the same request, the filters only offers me 
>the provider2 (digitalCamera) (because filter2 detects the subClassOf 
>relation added by the reasoner)
>
I suspect that there is a bug somewhere in your code.  If Camera and 
DigitalCamera are the same concept, than provider1 and provider2 provide 
the same outputs and the matching engine should match either none of 
them or both of them in every case.

we have a matching engine running at www.daml.ri.cmu.edu/matchmaker,  
you can try your examples there.

Ciao,

--- Massimo

Received on Friday, 9 April 2004 10:35:03 UTC