- From: Drew McDermott <drew.mcdermott@yale.edu>
- Date: Sat, 13 Nov 2004 00:27:01 +0000 (GMT)
- To: public-sws-ig@w3.org
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
-----
-- Drew McDermott
Yale University
Computer Science Department
Received on Saturday, 13 November 2004 00:27:33 UTC