Re: [WSDL] Message Typing

On Feb 9, 2004, at 1:34 AM, David Martin wrote:

> Hi Bijan -

Hi David.

> Bijan Parsia wrote:
[snip]
>> However, in my OWL-S experience, people seem to want to describe the 
>> inputs and outputs (not necessarily the input *messages* and output* 
>> messages) of a services with OWL Classes. I've become a little 
>> confused, in general, as to what that *means*, especially for OWL 
>> that describes non-computational entities, but ok, be that as it may. 
>> No, wait, don't be that as it may. The issue is that in WSDL, the 
>> types describe the messages, and do we want to say that the first 
>> input message to a services is a wordnet:Person?
>
> It seems to me, from the OWL-S point of view, that yes, it's very nice 
> if one can say things like that.  For the record, that is the 
> intention of the current OWL-S approach to grounding with WSDL.  This 
> is still in the context of WSDL 1.1.  In our current approach, we rely 
> on WSDL extensibility to indicate that the type of a given message 
> part is some OWL type.  Here's an excerpt from an example:
>
>     <message name="CongoBuyInput">
>         <part name="BookName" 
> owl-s-wsdl:owl-s-parameter="congoOwl:In-BookName"/>
>         <part name="SignInInfo"
>               owl-s-wsdl:owl-s-parameter="congoOwl:In-SignInInfo"/>
>     </message>
>
> It has always been my understanding that the above usage is completely 
> legit with WSDL 1.1.

Well, it involves some extensions. I'm not really up on WSDL 1.1, but 
what I'm trying to gather is whether there is enough support for some 
facilities to push some stuff into WSDL 2.0's spec. (Or some one of the 
specs.)

> (Note that this is not the only way indicated by OWL-S documentation 
> to set up a correspondence between OWL-S process I/O types and WSDL 
> message parts, but it's the only way I'm discussing in this message.)
>
> I for one would like to retain something like this in the context of 
> WSDL 2.0, if at all possible.  It seems only natural, if in fact a Web 
> service is prepared to take an OWL instance as an input, that it 
> should be declared in the most straightforward manner;

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

> that is, mention the OWL class of inputs that are expected.  I
> recognize there may be problems (such as the "Decker question") that 
> we never came to grips with, and I'm glad you're raising them now.  (I 
> guess :-).

Heh. Blame Stefan.

[snip]
>> The simplest proposal that might not work is to allow for OWL Classes 
>> (or rdfs, whatever) to be exposed in the Types section as a series of 
>> URIs (do we need non class individuals or properties? We can always 
>> use a nominal singleton class for either, I suppose, though, for the 
>> latter, that'd automatically shove you in owl full), and introduce an 
>> attribute that refers to them. What gets passed over the wire, in a 
>> message, is, by default, the identifier of relevant individual who is 
>> a member of the appropriate class.
>
> I assume you're deliberately suggesting that the identifier (and not a 
> serialization of the individual) gets passed over the wire.  Passing 
> the identifier sounds fine, but could you say little more about why we 
> should not also allow that a serialization of the individual could be 
> passed?

Essentially, the Decker problem. There is no "serialization of the 
individual" in RDF or OWL. There are serializations of *descriptions* 
of individuals, and we have no way to specify the completeness (or even 
the groundness) of these descriptions.

>  I can imagine lots of simple cases where that would seem like a 
> perfectly reasonable thing to do.

I think all the reasonable cases require at least an implicit solution 
to the Decker problem. My modest proposal would require a URI which has 
the following virtues:
	1) it's in some sense complete (i.e., no bnodes!)
	2) it's minimal
I would claim that it solves the Decker problem only in the minimum 
sense that if the message type is an owl class, it is acceptable to 
invoke that service on a identifier of that class. Any other 
information must be separately negotiated. So I solve the problem by 
bailing on it ;) But I believe this is about all OWL and RDF alone can 
give you, at least if you want to declare parameters as having type 
class.

There are further, somewhat *ad hoc* solutions. For example, one could 
use a class definition as a sort of data template. E.g., if property 
firstName has a domain of Person, and the input has a type of Person, 
then any message sent as that input must have a ground assertion of the 
form :individual firstName ____. Aside from being odd from an OWL 
standpoint (and likely to distort ontology engineering), it's unlikely 
to be satisfactory once you have reasonably complex and interconnected 
ontologies.

I suspect that a sensible solution is something akin to the current 
OWL-S XSLT hack. Type the messages as *data*, and have a way of 
specifying a certain message's data as a function of the state of a kb. 
Note that this is the *inverse* motivation that led to the current 
OWL-S XSLT hack.

Of course, we could come up with an OWL ontology of messages and 
message parts. That might be useful in describing WSDL messages. But 
maybe not :)

Of course, another way to specify a set of inputs is using bnodes. An 
rdf graph with a set of Bnodes will be entailed by all of the instances 
of that graph, and, perhaps most interesting for us, by all the ground 
instances of that graph:

(http://www.w3.org/TR/2003/PR-rdf-mt-20031215/#graphdefs for ground 
graph and instance of graph and
http://www.w3.org/TR/2003/PR-rdf-mt-20031215/#entail for simple 
entailment)

So, if we make the parameter typing constrain be that an actual input 
must be a ground instance f the input's type, we may have a workable 
(if wacky) solution. I'll be interested, but surprised, if this appeals 
to anyone!

So, to sum up this ramble:
	1) There is no "message" element in WSDL 2.0 (From the Part 1 change 
log: 20030804 JCS
	     Removed Message component per 30 July-1 Aug meeting.)
	2) The Decker problem needs to be solved!
	3) The Service as Process with Parameters vs. Service with Operations 
that are message
	     exchanges gap got wider.
	4) I'm leaning toward thinking that my minimal solution doesn't really 
help anyone.

Cheers,
Bijan Parsia.

Received on Monday, 9 February 2004 07:59:44 UTC