- From: Mithun Sheshagiri <mits1@cs.umbc.edu>
- Date: Sun, 08 Feb 2004 16:43:18 -0500
- To: Bijan Parsia <bparsia@isr.umd.edu>
- Cc: public-sws-ig@w3.org, skw@hp.com
- Message-ID: <4026AD76.1090109@cs.umbc.edu>
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.
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 Sunday, 8 February 2004 16:43:34 UTC