Re: [WSDL] Message Typing

Bijan Parsia wrote:

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

Yes, this is a bit of a nuisance, but I'm not convinced yet that it has to be a 
showstopper.

Humph.  It seems that WSDL 2.0 is moving backwards with respect to the objective of 
extensibility.


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

Doesn't seem odd to me, although I'd want some further refinement.  In fact, I 
expect a variety of such "ad hoc" conventions are going to be needed to get the 
semantic web off the ground in a useful way, and because they're needed, they'll 
become adopted and widespread fairly readily.  Our recent discussion about unique 
names assumption (and other related assumptions motivated by practicality) is 
another area where selected ad hoc conventions are likely to become widespread.

Just because we can imagine something going wrong, doesn't necessarily mean we have 
to rule out the possibility of lots of things working right.  (I thought we were 
supposed to be working out useful 80/20 solutions in these early days, right?) 
Further, the problem you are raising is potentially a problem for many different 
applications of OWL.    Let's not take onto OWL-S the burden of fixing all general 
OWL issues.  Yes, let's raise them, but if the rest of the Semantic Web is going to 
go ahead without having them fixed, then I'd like OWL-S to be able to move ahead also.

Well, we can discuss on the telecon.

Regards,
David

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

Received on Tuesday, 10 February 2004 10:18:03 UTC