Re: [WSDL] Message Typing: Example and Comments

Hi -

one quick comment below ...

Mithun Sheshagiri wrote:

> Hello all,
>             Some time back, I wanted to deploy a set of web services which uses RDF/XML 
> for input and output and I essentially adopted the technique suggested by Bijan in his 
> first question. Below is a service that takes in a keyword and returns a list of items 
> that match the keyword. There are certain problems with this approach though. The example 
> service takes in a keyword as an input and produces a list of Items in an ItemList.
> 
> - keyword - string
> - ItemList
> 	- member
> 		- Items
> 
> Even for such simple class descriptions, the schema is obscenely verbose. I had to embed the schema 
> definitions for keyword and ItemList using the <xsd:choice>. If anyone has a more concise way of describing
> this thing, please let us all know. Also, it will interesting to see if one could design a tool that takes
> in class definitions in OWL and convert them into an XML schema.
> 
> <xsd:schema targetNamespace="http://stuff/IProvider.xsd" <http://stuff/IProvider.xsd>
>                  xmlns:xsd="http://www.w3.org/2001/XMLSchema" <http://www.w3.org/2001/XMLSchema>
>                  xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" <http://schemas.xmlsoap.org/soap/encoding/>
>                  xmlns:effects="http://effects.com/" <http://effects.com/>>
>        <xsd:element name="RDF" targetNamespace="http://www.w3.org/1999/02/22-rdf-syntax-ns#" <http://www.w3.org/1999/02/22-rdf-syntax-ns#>>
>          <xsd:complexType>
>            <xsd:choice>
>              <xsd:element name="ItemList" targetNamespace="http://effects.com/" <http://effects.com/>
>                           form="qualified">
>                <xsd:complexType>
>                  <xsd:sequence>
>                    <xsd:element name="member" minOccurs="0" maxOccurs="unbounded"
>                                 targetNamespace="http://effects.com/" <http://effects.com/>
>                                 form="qualified">
>                      <xsd:complexType>
>                        <xsd:attribute ref="rdf:resource" type="xsd:string"
>                                       form="qualified"/>
>                      </xsd:complexType>
>                    </xsd:element>
>                  </xsd:sequence>
>                  <xsd:attribute ref="rdf:ID" type="xsd:string" form="qualified"/>
>                </xsd:complexType>
>              </xsd:element>
>              <xsd:element name="keyword" type="xsd:string" nillable="false"
>                           targetNamespace="http://effects.com/" <http://effects.com/> 
> 			  form="qualified"/>
>            </xsd:choice>
>          </xsd:complexType>
>        </xsd:element>
>      </xsd:schema>
> 
>   <message name="ItemLookUp0Request">
>      <part name="req" element="rdf:RDF"/>
>    </message>
>    <message name="ItemLookUp0Response">
>      <part name="resp" element="rdf:RDF"/>
>    </message>
> 
> 
> The service accepts a keyword and outputs ItemList. The SOAP response 
> looks like this:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <soapenv:Envelope 
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" <http://schemas.xmlsoap.org/soap/envelope/> 
> xmlns:xsd="http://www.w3.org/2001/XMLSchema" <http://www.w3.org/2001/XMLSchema> 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <http://www.w3.org/2001/XMLSchema-instance>>
>   <soapenv:Body>
>    <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" <http://www.w3.org/1999/02/22-rdf-syntax-ns#>>
>     <ns2:ItemList ns1:ID="instanceOfItemList" 
> xmlns:ns1="http://www.w3.org/1999/02/22-rdf-syntax-ns#" <http://www.w3.org/1999/02/22-rdf-syntax-ns#> 
> xmlns:ns2="http://effects.com/" <http://effects.com/>>
>      <ns2:member ns1:resource="http://thisone"/ <http://thisone>>
>      <ns2:member ns1:resource="http://thistwo"/ <http://thistwo>>
>     </ns2:ItemList>
>     <ns3:keyword xsi:nil="true" xmlns:ns3="http://effects.com/"/ <http://effects.com/>>
>    </RDF>
>   </soapenv:Body>
> </soapenv:Envelope>
> 
> As can be seen, the xml fragment within the <Body> element is valid 
> RDF/XML syntax if one moves the xsi namespace declaration into the RDF 
> element.
> Incidentally, this message is generated by Apache AXIS and some hacking 
> probably can remove the <keyword> element in the above message altogether.
> 
> 
> 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?  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)? 
> 
> We think that the industry might not be very interested in services that 
> produce RDF/XML as output; especially the ones who have already deployed 
> web service based systems (that use XML) and have a mature 
> infrastructure for managing and using web services. We probably should 
> look at ways by which semantics could be plugged-in to an existing 
> system. This is also OWL-S position (XSLT templates to convert XML to 
> RDF/XML) as Bijan has mentioned.

That's not the whole story.  As I indicated in my last message, the OWL-S grounding 
specifies a way in which a WSDL document can mention an OWL-S object (an instance of 
process:Input or process:Output) as an indication of the "type" of a (WSDL 1.1) 
message part.  This approach actually predates the use of XSLT templates.

Regards, David

> 
> However, when RDF becomes an houseold name :) , maybe people might be 
> interested in services that produce OWL entailments as the output.
> 
> regards,
> mithun
> 
>>
>>
>> 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 Monday, 9 February 2004 01:55:34 UTC