[WSDL] Message Typing

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?  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. 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 Sunday, 8 February 2004 11:09:46 UTC