Re: [WSDL] Message Typing

On Feb 9, 2004, at 4:39 PM, Drew McDermott wrote:

> 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.

Yep, that's part of what I elided :) I would take the examples of 
parent and person with a grain of salt...they're just easy to think 
about from the kb perspective. You get the same problem with, oh, say, 
lists.

>   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.

Yes. But a lot of services (especially in OWL-S) describe their 
parameters with (perhaps odd) OWL classes. Although an Address seems 
like a good example. Right now, we have some left over ambiguity about 
whether an owl-s parameter describes a message (or corresponds to a 
message or part thereof and if so how). We've tussled on this. I don't 
necessarily disagree with you that a sharp distinction would be nice, I 
just really disagree that we already have it.

> 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.

Yep.

> 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.)

Stefan presented me with the problem at the DAML PI meeting on Captiva. 
I then dubbed it the Decker problem :)

> 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.

Actually, how much is just one aspect as you point out. I believe I 
mentioned that even if you send the whole of your graph, since OWL KBs 
can contain loads of incomplete knowledge (you may know that I'm a 
parent, and thus I have at least one child, but you don't know who it 
is, or how many, or their names...).

And it's not just sending, it's knowing that you have have met the 
published contract of the service *before* you try to invoke it. There 
are many reasons why that's important, especially in a net/web 
environment, which, I trust, are obvious.

>  There is no obvious kernel whose boundaries
> are fuzzy.

Yes.

> The right answer (I always assumed) is that what services expect are
> literal data that are functions of more abstract entities.

That is sort of what we have available in OWL-S, but, as David 
exhibited, many people don't consider that the prime or only mechanism.

>   The
> literal data are sufficient for identification of an entity

Or the relevant assertions.

>  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

Yep.

> 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?

Nothing? It's probably too much to push into WSDL at the moment 
(especially with the elimination of  message and parts). There are 
details of course :)

> 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?

At the moment, I believe WSDL2.0 doesn't itself provide a mechanism for 
this, though WDSL 1.1 did. Of course, any mapping mechanism from 
XML/XML Schema to OWL-S will permit this, in principle.

But this opens up the possibility that inputs might be aggregates of 
extracts of multiple messages, etc. Perhaps this doesn't bother you, 
either.

> However, I am always happy to be happy in a good cause.

My cause is the best cause.

Cheers,
Bijan Parsia.

Received on Monday, 9 February 2004 20:15:41 UTC