RE: Suitable OWL-S profile

Drew,
 You said 
>In other words, if the service sells tickets, it should come with a
> description that says ... This service sells tickets.  Inferring this
> from the existence of an output is unnecessary and not even sound.

I certainly did not mean to imply that this should be inferred (ie that the
service sells tickets). So, what would be the description that says that the
service sells tickets? Certainly, one way of representing this description
is for the service to have tickets as ( one of ) is outputs.

As to csp's question, yes it is very possible that we will need ontologies
of human travel behavior. In past research (on human tasking of intelligent
agents for internet-based tasks such as buying tickets), we have called
these "task domain fragments", ie ontologies that characterize tasks in a
particular domain, such as travel. For example, one would like to know that
travel vehicles include ships, cars, trains, airplanes, that for business
travel, besides the travel vehicle tickets one also needs a hotel etc.

 --Katia

-----Original Message-----
From: public-sws-ig-request@w3.org [mailto:public-sws-ig-request@w3.org] On
Behalf Of csp
Sent: Saturday, November 13, 2004 4:19 PM
To: public-sws-ig@w3.org
Subject: Re: Suitable OWL-S profile



----- Original Message ----- 
From: "Drew McDermott" <drew.mcdermott@yale.edu>
To: <public-sws-ig@w3.org>
Sent: Saturday, November 13, 2004 1:27 AM
Subject: Re: Suitable OWL-S profile


>
>
> This is a somewhat tardy continuation of the dialogue started by
> Charlie Abela
>
>> 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).
>
> The gist of the replies to this message is that Owl-S provides a
> better way to think about this, and some parts of the problem have
> already been solved.  I'm sure some parts, or some close relatives, of
> the problem have been solved, but I also think that Charlie's main
> point has gone unaddressed.  It is indeed true that I/Os are
> relatively unimportant for someone looking for a service, and that
> what _is_ important varies from service to service.  As far as I know,
> there's no accepted theory about how a human user, the user's
> automated agents, and the web services are connected together.
>
> Katia Sycara had me worried when she said --
>
>> 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.
>
> but then she said --
>
>> 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.
>
> In other words, if the service sells tickets, it should come with a
> description that says ... This service sells tickets.  Inferring this
> from the existence of an output is unnecessary and not even sound.
>
> It seems to me that mapping the service's inputs to the information
> the user or his agents have, while crucial, is one of the last things
> the agents do.  First the candidate service is found, then what it can
> accomplish is measured against what the user wants to do, and finally
> the inputs and outputs are considered in detail.  It's that second
> step that will probably require some user participation for all but
> the most routine transactions.
>
>                                             -- Drew
>

To automate this second step some ontology for human
travel-behaviour would be required, right ?

Received on Monday, 15 November 2004 00:53:48 UTC