Re: Suitable OWL-S profile

I see your point, but I would also argue that though these concepts  are 
critical and important from discovering a service point of view, they 
need not be described in the profile model(reason: profile is suppose to 
work alongside  process, which is again a low level of service 
matchmaking). I remember that  the earlier version of profile had a  lot 
of additional information that was later on moved to other areas 
(separation of concerns). Again,  the model is extensible. Services that 
want to facilitate that kind of discovery can provide such information 
by all means. The profile caters to the most intutive concepts needed 
for matchmaking and therefore, for the purpose of definitions, it is 
restricted to those only.

Charlie Abela wrote:

>Hi Monika,
>
>I did not actually mean matchmaking based on keywords, but a way for the profile
>to be more expressive and more near what a user would request from his agent.
>One should not think of a service by its I/Os only. It does not make sense from
>a user perspective to define a request to his agent which includes AccountName,
>Password or any other input or output(how will these be known before hand?).
>The profile should present features related to its usability, what is the nature
>of the service, what solution can it provide. Eventually if the user/or his
>agent are satisfied with these issues including other service parameters, then
>the I/Os can be considered.
>
>Charlie
>
>Quoting Monika Solanki <monika@dmu.ac.uk>:
>
>  
>
>>Hi Charlie,
>>
>>Here are my two cents. As far as I understand, you are talking about
>> matchmaking on the basis of keyword (or context)  i.e flights, travel
>>etc, which is supposed to be taken of by engines like google... :-)
>>
>>I think this is basically the problem of how fine (or coarse grained )
>>searches can be made. In most of the technical specifications that exist
>>, the objective is to go down at the very low level of matchmaking,
>>leaving the job of preliminary decision making to some other entity
>>(maybe something inherent provided by registry services..???? or
>>conventioanl search engines ). How to automate this process  via agents
>>etc. should be possible and probably loads of them already exists
>>
>>-Monika
>>
>>
>>
>>
>>
>>Charlie Abela wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>work on service matchmaking has focused mainly on matching the inputs and
>>>outputs that a requester presents with those that a service stored in the
>>>matchmaker provides.
>>>I want to discuss another aspect of the service matching phase. With the
>>>      
>>>
>>above
>>    
>>
>>>situation it seems that the agent searching for a service has to know which
>>>inputs/outputs the service has to provide, independently of what the service
>>>      
>>>
>>is
>>    
>>
>>>used for.
>>>I want to consider an example related to an airtravelling service (like the
>>>BravoAir service). I want to consider the following situations:
>>>1. suppose that the user is not making use of an agent to search for this
>>>service but is manually trying to find it tru a search engine, the keywords
>>>that this person enters could be similar to air travel and flights.
>>>2.suppose that now the user makes use of an agent, the same type of search
>>>      
>>>
>>would
>>    
>>
>>>apply, cause one cannot assume that the person requester knows apriori what
>>>      
>>>
>>the
>>    
>>
>>>inputs and outputs would be so he will not instruct his agent about these.
>>>Even though most examples I've seen state that the user will instruct his
>>>      
>>>
>>agent
>>    
>>
>>>tru a natural language interface, this solution seems to be quite far at the
>>>moment, given also that there is no means of capturing context.
>>>
>>>So given these situations, I would like to ask whether it would be more
>>>      
>>>
>>suitable
>>    
>>
>>>to provide a way for the user to be able to instruct his agent with info
>>>      
>>>
>>about
>>    
>>
>>>the type of service he requires and the objective he wants to reach and not
>>>      
>>>
>>by
>>    
>>
>>>providing the I/Os (the I/Os will be considered at a later stage of the
>>>matching phase, since most air travel services have similar I/Os).
>>>
>>>something along these lines:
>>>
>>>serviceCategory -> air travel (points to some standard classification:
>>>      
>>>
>>UNSPSC or
>>    
>>
>>>NAICS)
>>>Objective-> flight reservation (points to some air travel domain ontology)
>>>GeographicRadius->Europe
>>>QualityRating->some_rating
>>>
>>>Charlie
>>>
>>>
>>>
>>>----------------------------------------------------------------
>>>This message was sent using IMP, the Internet Messaging Program.
>>>
>>>
>>>
>>>      
>>>
>>--
>>**>><<**>><<**>><<**>><<**>><<**>><<**>><<**
>>Monika Solanki
>>Software Technology Research Laboratory(STRL)
>>De Montfort University
>>Gateway building, G4.61
>>The Gateway
>>Leicester LE1 9BH, UK
>>
>>phone: +44 (0)116 250 6170 intern: 6170
>>email: monika@dmu.ac.uk
>>web: http://www.cse.dmu.ac.uk/~monika
>>**>><<**>><<**>><<**>><<**>><<**>><<**>><<**
>>
>>
>>
>>    
>>
>
>
>--
>Charlie Abela
>Research Student,
>CSAI, Department,
>University of Malta
>
>----------------------------------------------------------------
>This message was sent using IMP, the Internet Messaging Program.
>
>  
>

-- 
**>><<**>><<**>><<**>><<**>><<**>><<**>><<**
Monika Solanki
Software Technology Research Laboratory(STRL)
De Montfort University
Gateway building, G4.61
The Gateway
Leicester LE1 9BH, UK

phone: +44 (0)116 250 6170 intern: 6170
email: monika@dmu.ac.uk
web: http://www.cse.dmu.ac.uk/~monika
**>><<**>><<**>><<**>><<**>><<**>><<**>><<**