- From: Drew McDermott <drew.mcdermott@yale.edu>
- Date: Mon, 9 Feb 2004 16:39:00 -0500 (EST)
- To: public-sws-ig@w3.org
This is in response to the conversation involving Bijan, David, and Mithun. I don't really see how a process or service can literally expect a Person as a message or parameter, no matter how abstract the characterization of that process or service. By contrast, a service might literally expect something like a package. For instance, a retailer might expect unsatisfactory products to be sent back, in which case it wants the actual object, not some description of it. But this has nothing to do with _web_ services as described by WSDL, where the only entities that can be sent and received are messages, some of which describe objects. One might suppose that some objects have standard descriptions about which there is no conceivable ambiguity. A literal, for instance, is normally described by presenting the literal itself, although there are alternative ways one could dream up to describe it. A Person, however, emphatically has no such standard description. There seems to be an idea floating around that some collection of RDF or Owl stuff could serve as a description of a person, in which case we get the "Decker problem," that we don't know when to stop adding to the collection. (This is the first I have heard of this problem being associated with Decker; I hope he doesn't mind.) The Decker problem is a reductio ad absurdum of the idea, but it calls our attention to the wrong thing. The problem is not _how much_ stuff to send, but _which_ stuff to send. There is no obvious kernel whose boundaries are fuzzy. The right answer (I always assumed) is that what services expect are literal data that are functions of more abstract entities. The literal data are sufficient for identification of an entity in the context the service operates in. For instance, in country X, a service S that is expected to deal only with citizens of X can require the X-government identity number of the person as an input. Now consider a service S' whose purpose is to identify criminal suspects using data gathered by the police. S' might ask for the person's stated name, fingerprints, and mug shots. As far as the police are concerned, these data constitute a large part of the description of the suspect. The service might check to see if the stated name is a known alias of someone whose fingerprints resemble the suspect's, and send back the X-government identity number and criminal record of that person. The point is that just saying a service wants a "Person" as input is meaningless. The input to one service might be completely different from the input to another, even though both want a "Person" as input. The service description should say (for instance) that a particular parameter is the surface-mail address of a person P, and that if the service completes then every month a book will be sent to that address in P's name, and P will have the obligation to pay the service owners some amount of money (these details being dependent on other parameters). Note that the customer is here identified as the person of a certain name residing at a certain place, which is yet another way of describing a person. All of these statements are in the service description. The grounding then says which fields of the messages contain the surface-mail address. What, if anything, is wrong with this idea? A much more specific issue: > [Bijan] > But note the ambiguity: In OWL-S a Web service is a *process* and it > has *input parameters*, one or more of which maybe encoded in a single > "input" message. Conceptually, I believe, a WSDL message reference > message attribute describes the type of the *message* not the > parameter. So perhaps there is some loss of functionality (i.e., being > able to pick apart messages). > So, it'd be a consequence, unfortunately, of this approach that > mulitiple input processes would require multiple input messages :(, at > least in the straightfoward case. > > Drew, perhaps, would be happy at this alignment ;) I don't really understand what is supposed to make me happy here, or even what's at issue. Suppose a WSDL message has two parts, Z and I, one of type string and one of type integer. Is there a problem with an Owl-S grounding specifying that parameter Pz of process P1 comes from the first part, and parameter Pi of process P2 comes from the second part, of the message? However, I am always happy to be happy in a good cause. -- Drew -- -- Drew McDermott Yale University CS Dept.
Received on Monday, 9 February 2004 16:39:15 UTC