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.

阅读全文(6850) | 回复(3) | 编辑 | 精华


I liked it better when you said that the client's owning of the tickets would be an effect of doing business with the service.I don't see how in general you could interpret "Y is an output"to mean "A new Y exists and the client owns it."  Outputs are just pieces of information, aren't they?  Even if you did want to allow physical outputs, you would still have lots of extra information about the details of the transfer of ownership.  If I buy a house from a web realtor, is the house an output?  An input?  Suppose I buy a corn future?  Don't I have to spell out somewhere what is that I own and in what sense?  Given the need for all that extra information, it doesn't seem worthwhile to complicate the concept of outputs to avoid having to say "Effect: the client owns Y."


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.


  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

» 1 »

验证码:  (不区分大小写,请仔细填写,输错需重写评论内容!)


«April 2021»
blog名称:World Wide Web Watch
站点首页 | 联系我们 | 博客注册 | 博客登陆

Sponsored By W3CHINA
W3CHINA Blog 0.8 Processed in 0.031 second(s), page refreshed 144565553 times.
《全国人大常委会关于维护互联网安全的决定》  《计算机信息网络国际联网安全保护管理办法》