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

Re: Suitable OWL-S profile

From: csp <cspriese@gmx.de>
Date: Sat, 13 Nov 2004 22:19:16 +0100
Message-ID: <0ce901c4ca81$fcce0a90$6ea3fea9@claus14>
To: <public-sws-ig@w3.org>

----- 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 Sunday, 14 November 2004 19:42:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:13 UTC