Re: WSDL grounding

Mithun -

Thanks for these excellent observations.  You are correct that there is 
a not-fully-resolved issue here.  Actually, I believe the intention of 
the current DAML-S/OWL-S spec is in accord with your solution 1).  More 
below...

Sheshagiri, Mithun wrote:
> Hi all,
> 
> There seems to be problem when grounding DAML-S in WSDL. If one describes
> a atomic process with conditional output like congoProcess:LocateBook,
> then there seems to be no straight forward way of implementing this in
> WSDL.
> 
> When describing operation in WSDL, a single input and a single output can
> be specified for the Request-Response transmission primitive. What we need
> is a primitive that would let us specify two outputs and the actual output
> can be oneOf the two outputs. Also note that there could be scenarios
> where the two outputs could be different data-structures.
> 
> Consider the following service:
> 
> input: BookName
> output: oneOf(output1,output2)
> condition: BookInStock
> output1: BookInfo
> output1: BookNotInStock
> 
> If BookInStock is grounded to True then, BookInfo is the output else the
> output is an message BookNotInStock.
> 
> 
> These are some ways of grounding the service:
> 1. Make daml-s-parameter point to the ConditionalOutput class of the
> AtomicProcess. To do this, we will need a module that inspects the content
> of the message received and disambiguates the outputs for the upper
> layers.

As I say above, the intention of the current DAML-S/OWL-S spec is in 
accord with your above solution.  daml-s-parameter already points to the 
output property, from which a tool can easily identify the conditional 
output class (the range of the property).  But yes, as you say, some 
module will need to determine which output type is coming back.


> 
> 2. Use the wsdl:fault to define BookNotInStock
> Not a good option since the semantics of fault is too strong and not
> appropriate to describe something like BookNotInStock output, but there
> can easily be other cases where this construct can be useful. In general a
> service could have two non-faulty outputs and WSDL:fault cannot capture
> this.
> 
> 3. Ground an AtomicProcess to two WSDL:operations. One with output as
> BookInfo and other with the output BookInStock. At the moment, each
> AtomicProcess grounds to a single WSDL:operation.
> 
> 4. Describe services to eliminate conditional outputs/effects altogether.
> The checking of the Condition can be defined as an AtomicProcess and then
> define two more atomic processes that handle the True and False cases of
> the Condition.
> 
> Comments/Clarifications?

I think all of the above are worth considering, and lead to potential 
improvements to OWL-S, so we'll take a look at this.

Also, thanks for your corrections below.  1) has just been put on the 
release page, and one of our members is  going to look at the other 2.

Regards,
David Martin

> 
> 
> Some minor corrections
> 1. File: CongoProcess.daml and CongoProcess.owl
> 
> <rdf:Property rdf:ID="nameBookInCatalogue">
>   <daml/owl:domain rdf:resource="#BookInCatalogue"/>
>   <daml/owl:range rdf:resource="&xsd;#string"/>
> </rdf:Property>
> 
> BookInCatalogue in the above bit should be BookInCatalogueP
> 
> 
> 2. File: CongoProcess.daml and CongoProcess.owl
> In the LocateBook AtomicProcess:
> LocateBook is defined as the disjointUnionOf LocatedBookOutput and
> NotFoundBookOutput. LocatedBookOuput is the ConditionalOutput with
> coCondition-InCatalogueBook and  NotFoundBookOutput is the
> ConditonalOutput with coCondition-NotInCatalogueBook. This linking between
> ConditionalOuput and the corresponding coCondition is not shown. I think
> you might want to be put property restrictions in the definition of
> LocatedBookOutput and OutInCatalogueBookDescription.
> 
> 3. The property conditionValue has been used to link Conditon and
> TestValue. However, the definition of the property conditionValue has
> range TestCondition which in turn is a subClassOf of Process.
> 
> 
> Thanks guys!
> mithun
> _http://www.cs.umbc.edu/~mits1_
> 
> 
> Mithun Sheshagiri
> HPLabs, Bristol
> _http://www.cs.umbc.edu/~mits1_
> Mobile: (044) 07787970209
>

Received on Tuesday, 29 July 2003 18:47:35 UTC