- From: Mithun Sheshagiri <mits1@cs.umbc.edu>
- Date: Mon, 09 Feb 2004 00:38:31 -0500
- To: Bijan Parsia <bparsia@isr.umd.edu>
- Cc: public-sws-ig@w3.org
Bijan,
Please read below...
> [snip]
>
>> 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/"
>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>> <soapenv:Body>
>> <RDF xmlns="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#"
>> xmlns:ns2="http://effects.com/">
>> <ns2:member ns1:resource="http://thisone"/>
>> <ns2:member ns1:resource="http://thistwo"/>
>> </ns2:ItemList>
>> <ns3:keyword xsi:nil="true" xmlns:ns3="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.
>
>
> Would you be happy (-ier, less happy) if you just described the
> service as consumign an ns3:keyword and returning an ns2:ItemList?
> Even if there were extraneous (or missing) information in the reply?
> [snip]
Actually, this is what I intended and the above xml-schema is the only
solution I could figure out. I was using the AXIS WSDL2Java tool to
generate stubs for the client. So with WSDL description it created a
Java class called RDF with inner class for ItemList and a field for
keyword. The input would the RDF class with only the keyword field
assigned a value at the client and the server would use the RDF class
with only the inner class ItemList instantiated. In both instances AXIS
builds the SOAP message from the instance of RDF class. When it finds
that keyword is null, it builds the SOAP message using the keyword
element with the nil attribute set to true rather than omitting the
element in the first place (this is where hacking will help). The same
holds when building the input message.
I know its too much detail but thought might be of help to someone.
>
>
>> 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.
>
>
> Of course, I'm not just interested in what industry in general wants
> :) The real issue is there a good reason to allow OWL classes as
> descriptors of messages. Does anyone want this?
I think, it is in the interest of the SWS committee to keep the industry
interested else they might spawn an initiative on their own to address
the issues we are trying to tackle. I think, we all want to see wide
acceptance of OWL-S. It would nice to adopt a two prong approach where
we support a system that uses only XML at the same time we also
elaborate how one could build a system that exclusively talks using a
SWL. Why would someone need it, I really haven't thought about it. But
practicality could be one. At the risk of repeating myself, if I have a
system that makes heavy use of SWLs, I would look for service that talks
in SWL rather than use a service that talks in plain XML and needs some
kind of transformation mechanism to convert into a SWL.
If OWL inputs and outputs are somehow made part of the WSDL
description, then one could determine suitable service (that uses only
IOs for matching) from the WSDL description itself. If we add
preconditions and effects, then we have essentially captured the atomic
process in the WSDL description. So assuming that my earlier statement
is correct, we have moved atomic process descriptions from the
processModel to the grounding (which is not just grounding anymore).
>
>
>> However, when RDF becomes an houseold name :) , maybe people might be
>> interested in services that produce OWL entailments as the output.
>
> [snip]
>
> If they are entailments, then they probably could be conveyed by some
> serialization (i.e., the return type be rdf:RDF). But again, this
> makes it rather difficult to verify messages.
Could please elaborate what did you mean by verifying messages? Did you
mean to ascertain the class from the instance. Also, what I meant in my
earlier message was "produce RDF/XML, N3,.... statements" and not just
"produce OWL entailments".
peace
Mithun
>
>
> Thanks for the reply.
>
> Cheers,
> Bijan Parsia.
>
Received on Monday, 9 February 2004 00:38:35 UTC