limit about parameter description?

Hi all,
I was reasonin about parameter description in the semantic web services: 
according to what i know (and what Evren Sirin told me some time ago) 
the description of the IO must be done using concepts and not 
properties. Example:
if i have a service that takes the security social number and returns 
the name and the surname of the person who owns it, i must have a 
concept for SSN (with property number)and the "usual" concept for person 
(with properties name, surname and others) Then i must use a XSL 
Transformation in order to extract info from the concept SSN (get the 
number and fetch it in the standard ws) and another transformation in 
order to create a "person" individual and fill the properties with 
values fetched from the original ws. That's ok, no problem about it, but 
this is my doubt:
If we have another service, that does the same job, but returns more 
infos about the person (name, surname, address and so on), how can we 
differentiate between the two services? I dont think creating two 
different concept for "person" would be the right way to go (they're 
semantically the same) so we should need some mechanism to specify the 
real usage of concepts. Is there a way to specify this or it's not 
possible? Some kind of way to express "requirements" of properties for 
inputs and "resulting" properties for outputs

I think there are two problems if this is not possible:
-talkin about inputs, the agent could think that it needs more info than 
required (i.e. an input is specified as concept XYZ, this concept has 10 
properties but only two of them are used to invoke the service);
-talkin about outputs, the agent cannot understand that service B is 
(probably) better than service A because it returns more infos



-- 
Norberto Carnelli
E-mail: <norberto.carnelli@poste.it>
GPG Key ID: 0xBD2BB3E2 (available on keyservers)

Received on Monday, 28 March 2005 10:00:33 UTC