Re: Data-flow redux

   [Massimo]
   I thought that we were to add a property "processOf" to the parameter 
   that allows us to find the process a parameter is related to.  The 
   property will tie parameters and processes together so that there is no 
   confusion which parameter of which process to refer to. 

The parameter can have a processOf property, but it won't solve the
problem, because we have to somehow refer to the parameter of a
particular _process instance_, not a process.

   [Massimo]
   I do not fully understand the last example, but I believe that tags are 
   no longer needed if we adopt this property.

Here's the example in question:

   >    (Sequence (tag s1 (toodle))
   >              (y(out s1) => x(in s2))
   >	          (toodle)
   >              (tag s2 (doo)))
   >

We have to have a way of indicating that we mean the 'x' belonging to
the call to (doo).  After all, if 's2' were a call to (toodle), then a
flow to parameter 'x' would be ambiguous.

Actually, your message has revealed a bug in my proposed RDF syntax.
You can't say 

  <Atomic rdf:ID="doo">    
      <arg>
	 <InputParameter rdf:ID="x"> 
	       <rdf:type>
		  <owl:Restriction>
		     <owl:onProperty rdf:resource="&owl-s;parameterValue"/>
		     <owl:allValuesFrom rdf:resource="&xsd;string"/>
		  </owl:Restriction>
	       </rdf:type>
	 </InputParameter>
      </arg>
  </Atomic>

because two processe are allowed to have InputParameters with the same
name.  So we can't use IDs as names.  We'll have to switch to
something like this:

  <Atomic>    
      <arg>
	 <InputParameter paramName="x"> 
              ...
	 </InputParameter>
      </arg>
  </Atomic>

So, in the example as given, if we suppose that (doo) and (toodle)
both have input parameters named "x," the data flow from the first
(toodle) to the (doo) would have to be indicated thus:

   <DataFlow>
      <source>
	 <ParameterSpec psParam="y" 
			i-or-o="&owl-s;outputP" 
			psStep="#s1"/>
      </source>
      <destination>
	 <ParameterSpec psParam="x"
			i-or-o="&owl-s;inputP"
			psStep="#s2"/>
      </destination>
   </DataFlow>

where "#s1" and "#s2" are tag names.  We might as well eliminate the
use of IDs to identify tagBound's as well, since it's less than
perspicuous. 

There are other ways to do all this.  We could just use variables:

	(Let ((y (toodle)))
	   (Sequence 
              (toodle)
	      (doo y)))

Dataflow annotations have these advantages:

- The fact that a given flow can be used at most once supports simpler
  reasoning about the values produced by processes (okay, I'm guessing).

- Dataflows supplement control constructs in a useful way, allowing
  them to be augmented with extra dependencies while one step waits
  for another to provide it with data.

Another possibility is to name the Dataflow object, and specify which
Dataflow object the results of a step go to, and which they come from:

   (With-dataflows (c1)
      (Sequence
          (toodle y => c1)
          (toodle)
          (doo x <= c1)))

This can be considered a variant of the variable concept, with the
disciplines imposed by dataflows easier to see.

                                             -- Drew

-- 
                                   -- Drew McDermott
                                      Yale Computer Science Department

Received on Sunday, 12 October 2003 22:19:12 UTC