- From: David Martin <martin@ai.sri.com>
- Date: Sun, 08 Feb 2004 22:55:09 -0800
- To: Mithun Sheshagiri <mits1@cs.umbc.edu>
- Cc: Bijan Parsia <bparsia@isr.umd.edu>, public-sws-ig@w3.org, skw@hp.com
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