W3C home > Mailing lists > Public > public-sws-ig@w3.org > November 2004

RE: Suitable OWL-S profile

From: Katia Sycara <katia+@cs.cmu.edu>
Date: Mon, 1 Nov 2004 16:09:24 -0500
To: 'Monika Solanki' <monika@dmu.ac.uk>, 'Charlie Abela' <charlie@semantech.org>, public-sws-ig@w3.org
Cc: katia@cs.cmu.edu
Message-ID: <00b201c4c057$126eb730$d1bd0280@cimds.ri.cmu.edu>
Charlie,

 In OWL-S 1.1 the kind of concepts you are referring to are included in the
"product/service" part of the profile. The thinking is that the product of a
travel service is to provide travel (or travel information, it depends on
how you model it). So, subsumption inference can be done on the product. The
new profile ontology (that includes the product concept) will be uploaded
within the next couple of days. As far as your example with the objective
being travel reservation, this is not very well defined since it is not
clear whether the objective is for the web service to make a reservation for
you, or to give you alternative travel possibilities or display you
information about travel to Europe (and of course it is not clear whether
you only want information or reservations on airlines, or airlines and
hotels etc). So, in your example the objective is underspecified. Now if you
were to say that the input was a travel date (for going and returning), a
destination and an origin and the output was an airline reservation, with an
associated price, then it would mean that you wanted only information about
flights from the origin to the destination on the particular dates. If in
addition, in the output you had a confirmation/invoice, then it would mean
that you wanted the service to actually buy you a ticket. 

 

Concerning the inputs and outputs, the philosophy (and practice) in OWL-S is
that the I/O is in terms of functional capability not low level details like
account number and password. In other words, the inputs and outputs should
differentiate one service (e.g. buying a tennis racket) from another (e.g.
buying shoes) whereas giving a credit card or a password does not
differentiate between the two services. It is the role of the process model
in OWL-S to break down the buying of a tennis racket into a login atomic
process where account number and password are needed, and then the selection
part where the particular type of tennis racket is input, and then the
actual buying part where your credit card is input.

 

Notice also that OWL-S allows for preconditions and effects that further
refine and characterize the description of the objective. In your travel
example, if you indeed wanted to buy a ticket (rather than be shown flights
to Europe), you would have the invoice as an output, but you could further
specify as an effect possession of a ticket and possibly the system could
show you as a additional effect the fact that your bank account was debited
the ticket price.

 

 

 

-----Original Message-----
From: public-sws-ig-request@w3.org [mailto:public-sws-ig-request@w3.org] On
Behalf Of Monika Solanki
Sent: Monday, November 01, 2004 3:20 PM
To: Charlie Abela; public-sws-ig@w3.org
Subject: 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  <mailto:monika@dmu.ac.uk> <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
**>><<**>><<**>><<**>><<**>><<**>><<**>><<**

 
Received on Monday, 1 November 2004 22:41:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 16 March 2008 00:10:58 GMT