Re: [WSDL] Message Typing

** Clarification of something I said ..below

David Martin wrote:
> 
> Hi Bijan -
> 
> Bijan Parsia wrote:
> 
>>
>> Hey folks,
>>
>> In WSDL 2.0, an operation is a message exchange pattern (MEP) 
>> instantiated to a set of specific message "types" for each place in 
>> the MEP (with a few other things). The types in question (intuitively) 
>> describe the content of the message (there's some ongoing wrangling 
>> about headers, but, let's ignore them for the moment ;)).
>>
>> At the moment, WSDL 2.0 only has built in support for XML Schema 
>> element declarations (as types of messages), and has non-normative 
>> support for DTDs and RELAX-NG. So, there are two issues here:
>>
>> 1) Whether to add, normative or not, support for "Semantic Web" type 
>> systems, e.g., OWL and RDFS
>> 2) How these types should be used to describe messages.
>>
>> These correspond, roughly, to additions made to the {types} component 
>> (section 3 or appendix D) and the {message reference} component 
>> (section 2.4).
>>
>> (URIs for these sections;
>>     Section 2.4, Message Reference:
>>         http://www.w3.org/TR/wsdl20/#MessageReference_details
>>     Section 3, Types:
>>         http://www.w3.org/TR/wsdl20/#eii-types
>>     Appendix D, Examples of Specifications of Extension Elements for 
>> Alternative Schema Language Support:
>>         http://www.w3.org/TR/wsdl20/#other-schemalang
>> )
>>
>> Now, I want to put aside the question of normativity for the moment, 
>> mostly because I think there are a series of technical issues that I'd 
>> like to get a better handle on.
>>
>> First question: What to (current) semantic web services deployers and 
>> consumers *want*? For some sorts of services, e.g., query or inference 
>> services, it seems like the current proposal is sufficient. If you are 
>> passing in a OWL ontology and expecting to get back entailments, it 
>> makes sense to use an rdf:RDF element for the input and an rdf:RDF 
>> *element* for the output. If you want to use a different serialization 
>> (say, the owl presentation syntax, or the DIG xml syntax) then you 
>> still are passing elements. We might want to distinguish RDF/XML 
>> documents by their owl species (perhaps via mimetype), but, again, 
>> this seems to be solvable with the current system. Non XML 
>> serializations could be handled now by, for example, elements of 
>> simple type, e.g., <n3>:a :b _:c</n3>. (This might be used for 
>> services that covert between RDF/XML and N3.)
>>
>> 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.  

congoOwl:In-BookName in the example below is an OWL instance, not a class.  It's an 
instance of the OWL-S class Input.  The instance belongs to an OWL-S process 
description and, in turn, mentions an OWL class as its type.  (And of course I'm 
aware that mention of the class is something that puts the process description into 
OWL Full, which is controversial.  Just describing the example as it currently 
exists :-).

- David

> 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.
> 
> (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; 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 :-).
> 
> more below ...
> 
>> Or do we want to leave messages (at the WSDL level) described by 
>> elements (or simpleTypes) and layer OWL individuals and classes above 
>> that (something similar to how OWL-S does now)?
>>
>> Second question: Do we want to deal with the "Decker question"? That 
>> is, what information *must* be passed, and what information *must not* 
>> be passed between services. For example, if I claim that a services 
>> requires a Parent as input, and Parents are Persons, and Persons all 
>> haveParents, how much of the ancestory tree must I pass? (It could get 
>> quite large!) It really depends on the service. Similarly, knowing 
>> that someone is a Parent means that you know that he or she has at 
>> least one child. For some services, you might not need to know 
>> anything more about the children, for others, the actually number of 
>> children is critical, and yet for others, the number and names and 
>> perhaps other information is critical.
>>
>> In some distributed systems, this might not be quite a problem. E.g., 
>> in a linda/tuplespace like system, there information may be all shared 
>> (though, still, you might want to know what information a service will 
>> examine *before* you invoke it). In a chatty agent setting, you might 
>> expect the inital message to merely start the conversation, and futher 
>> information to be requested on demand (that still leaves the you might 
>> want to know in advance what will be required, either for efficiency 
>> or privacy).
>>
>> It would be nice if we had some means of specifying the information 
>> that must be communicated. Designing such a means is definitely out of 
>> scope of the WDSL group, at least for this go around. It might be 
>> right for some Query group. If, however, what we're passing in 
>> messages is results of queries (for example), then it would seem that 
>> the message's type *isn't* naturally an OWL Class. At least not the 
>> obvious OWL class of "Person".
>>
>> *********
>> 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?  I can imagine lots of simple cases where that would seem like a 
> perfectly reasonable thing to do.
> 
> Thanks,
> David
> 
>> There is some care needed to identify by which KB/ontology this 
>> individual is known to be of that class (or, for example, an RDFS 
>> agent might send a cat where the disjoint class of dog was required 
>> because it couldn't detect the contradiction).
>>
>> Thoughts, comments, data points? Screams of pain still welcome.
>>
>> Cheers,
>> Bijan Parsia.
>>
>

Received on Monday, 9 February 2004 01:53:00 UTC