Re: [WSDL] Message Typing

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.  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:34:43 UTC