Polishing Owl-S

As Owl-S reaches perfection (well, stability anyway), we have made a
couple of amendments to it to bring it into harmony with Nature and
Mathematics.

One non-amendment is that, in spite of my query here a few days ago,
we have left TheParentPerform in the ontology.  This is a variable
that, at process-performance time, is bound to the current performance
of a composite process (i.e., the performance of the parent of every
component process).  So inputs to the composite are referred to as 

	  <valueOf>
	     <fromProcess rdf:resource="#TheParentPerform"/>
	     <theParam rdf:resource="#INPUT-PARAM-HERE"/>
	  </valueOf>

In the surface syntax, one can continue to refer to input parameters
by just using their names.

Next, we have cleared up the question whether composite processes can
have results by answering it in the affirmative.  Composite processes
can have both bodies _and_ results, the latter in exactly the same
format as for atomic processes.

However, results are not sufficient for composite processes, so we
have added the Produce "control construct," which occurs where an
ordinary process step would occur, but which, rather than actually
doing anything, simply declares the values of output parameters of the
parent perform.  

	<owl:Class rdf:ID="Produce">
	  <rdfs:subClassOf rdf:resource="#ControlConstruct"/>
	</owl:Class>

	<owl:Property rdf:ID="producedBinding">
	   <rdfs:domain rdf:resource="#Produce"/>
	   <rdfs:range rdf:resource="#OutputBinding"/>
	</owl:Property>

In the surface syntax, the format is 

     produce(p_1 <= e_1, ..., p_k <= e_k)

This information is in the same format as the 'output' elements of a
result:

     result: (output(p_1 <= e_1, ...)

or perhaps

     result: (input1 > input2
              => output(output1 <= 2*input2))

(In the RDF/XML syntax the "p <= q" expressions translate to
OutputBindings inside withOutputs inside Results.)

Daniel Elenius <elenius@csl.sri.com> sent the following e-mail about
this issue:

> Is this the new preferred way to define OutputBindings on a composite 
> process?
> What are the use cases when this is necessary, and the old method of 
> using Results with withOutput statements, as seen in BravoAirProcess.owl 
> does not work?
> 
> It seems awkward. Since it's a new control construct, if we want to add 
> a produce to a composite process, we must always wrap it into a Sequence 
> (if the composite process is not already a Sequence at its top level).
> 
> Could we have a description of this on the public-sws list, please?
 
>From the last sentence I assume he doesn't mind my replying on the
public-sws list.

Anyway, 'produce' is not necessarily the preferred way to define
OutputBindings; it's complementary to Results and withOutputs.  There
are cases where it's clumsy or impossible to use withOutputs.  For
example, suppose we have a composite process that checks with two
webservices and outputs an error flag if either is unavailable:

define composite process order_kit(inputs: (quantity - integer)
				   outputs: (status - string))
  {
    order_base :: perform acme_purchase(partno <= "X507008",
					n <= quantity);
    if order_base.outcome = "success"
      then {
	     order_superstructure ::
		  perform apogee_purchase(part_id <= "103ZQ30B",
					  q <= quantity);
	     if order_superstructure.okay
	       then produce(status <= "succeed")
	       else produce(status <= "fail two")
	   };
      else produce(status <= "fail one")
  }

You can't replace the occurrences of 'produce' here with conditional
Results, because there's no way to know what the result of
communicating with the Acme and Apogee web services would be without
actually communicating with them.

But you're right that in other circumstances it would be simpler or
clearer to put the output bindings in a Result clause.  That's why we
decided to allow both.  In fact, you can use both in the same
process.  One output parameter could be described in the header and
another by various 'produces' in the body.  Of course, if the same
output parameter is given two different values, that would be an
error.

                                             -- Drew

-- 

                                        -- Drew McDermott
                                           Yale University
                                           Computer Science Department

Some see the glass as half empty, some as half full.  Surely the
truth lies somewhere in between.

Received on Sunday, 31 October 2004 20:13:19 UTC