Re: Data-flow redux

Drew,

I have to confess,  I still do not understand the need of tagged 
parameters.  Can you please explain?

--- Massimo


Drew McDermott wrote:

>   [Massimo Paolucci]
>
>   During the last DAML-S teleconference we decided to drop the use of
>   sameAs and we adopted the idea that data-flow is controlled by a link
>   from one parameter to the next one.
>
>   Here is how it plays out:
>
>It's good, but dataflows are not properties of parameters; they are
>properties of parameters of particular (tagged) steps, which we can
>call ParameterSpecs:
>
><owl:Class rdf:ID="ParameterSpec">
></owl:Class>
>
><rdf:Property rdf:ID="psParam">
>   <rdfs:domain rdf:resource="#ParameterSpec"/>
>   <rdfs:range rdf:resource="#Parameter"/>
></rdf:Property>
>
><rdf:Property rdf:ID="i-or-o">
>   <rdfs:domain rdf:resource="#ParameterSpec"/>
>   <rdfs:range>
>      <owl:oneOf rdf:parseType="Collection">
>          <owl:Thing rdf:ID="inputP"/>
>	  <owl:Thing rdf:ID="outputP"/>
>      </owl:oneOf>
>   </rdfs:range>
></rdf:Property>
>   
><rdf:Property rdf:ID="psStep">
>   <rdfs:domain rdf:resource="#ParameterSpec"/>
>   <rdfs:range rdf:resource="#StepTag"/>
></rdf:Property>
>
>The class StepTag referred to here is defined thus:
>
><owl:Class rdf:ID="StepTag">
></owl:Class>
>
><rdf:Property rdf:ID="tagName">
>   <rdfs:domain rdf:resource="StepTag"/>
>   <rdfs:range rdf:resource="&xsd;string"/>
></rdf:Property>
>
>The next draft of the surface syntax will spell all this out,
>coherently I hope.
>
>Anyway, I would change every occurrence of Parameter to ParameterSpec
>(marked with a **):
>
>   <!-- This class represents a data-flow link from one parameter to 
>   another -->
>   <owl:Class rdf:ID="DataFlow"/>
>
>
>   <!-- ................................... Source -->
>
>   <owl:ObjectProperty rdf:ID="source">
>     <comment>
>       This property links a data flow link to a parameter (the writer)
>       This property is defined functional to guarantee that there is
>       only one sorce of information for each data-flow link
>     </comment>
>     <rdf:type rdf:resource="&owl;#FunctionalProperty"/>
>     <rdfs:domain rdf:resource="#DataFlow"/>
>     <rdfs:range rdf:resource="#ParameterSpec"/>    <<--- **
>   </owl:ObjectProperty> 
>
>
>
>
>   <owl:ObjectProperty rdf:ID="sourceOf">
>     <comment>
>      Inverse relation used to relate a parameter with all the data-flow
>      it writes into.
>     </comment>
>     <owl:inverseOf rdf:resource="#source"/>
>   </owl:ObjectProperty>
>
>   <!-- ................................... Destination -->
>
>   <owl:ObjectProperty rdf:ID="destination">
>     <comment>
>       This property links a data flow link to a parameter (the reader).
>       For the time being, this property is defined functional to guarantee 
>   that there is
>       only one recepient of the information for each data-flow link.
>       This constraints forces us to add one data link for each parameter
>       pair that are connected, which is not too bad.  An alternative
>       could be to relax the functional constraint and allow the data to
>       be "sprayed" to many parameters.  There is no difference between
>       the two models other than personal preference.
>
>Even if you make 'destination' functional, you can't rule out multiple
>flows without ruling out multiple dataflow objects attached to a given
>ParameterSpec, which is tricky.
>
>You're right, though, that allowing multiple sources and destination
>would give you "fan in" and "fan out" in a nice way.  How would we
>indicate that in the surface syntax?  Maybe   s => <d1, d2> ?  
>     </comment>
>     <rdfs:domain rdf:resource="#DataFlow"/>
>     <rdfs:range rdf:resource="#ParameterSpec"/>   <<--- **
>   </owl:ObjectProperty>
>
>
>   <owl:ObjectProperty rdf:ID="destinationOf">
>     <owl:inverseOf rdf:resource="#destination"/>
>     <comment>
>      Inverse relation used to relate a parameter with all the data-flow
>      it reads from.  The property is functional to impose that there is
>      only one source of information.
>     </comment>
>     <rdf:type rdf:resource="&owl;#FunctionalProperty"/>
>   </owl:ObjectProperty>
>
>
>   During the teleconference we noted that there are at least three types
>   of data-flow: 
>
>       output-input: the output of a process feeds into the input of another
>       output-output: as when the output of a process is returned to some
>		      parent process
>       input-input: as when the input of a process is propagated to some
>		    substeps
>
>   also it was suggested a fourth type:
>
>       input-output: I did not really understand this, but I my
>		     recollection si that it means the relation between
>		     input/output within a process
>
>
>   The four types of classes are defined below.  The names can be easily
>   changed, just suggest what you want.
>
>I like the names, but we have to subclass ParameterSpec, yielding
>InputSpec and OutputSpec, which would replaced Input and Output:
>
><owl:Class rdf:ID="InputSpec">
>   <rdfs:subClassOf rdf:resource="#ParameterSpec"/>
>   <rdfs:subClassOf>
>       <owl:Restriction>
>          <owl:onProperty rdf:resource="#i-or-o"/>
>	  <owl:hasValue rdf:resource="inputP"/>
>       </owl:Restriction>
>   </rdfs:subClassOf>
></owl:Class>
>
><owl:Class rdf:ID="OutputSpec">
>   <rdfs:subClassOf rdf:resource="#ParameterSpec"/>
>   <rdfs:subClassOf>
>       <owl:Restriction>
>          <owl:onProperty rdf:resource="#i-or-o"/>
>	  <owl:hasValue rdf:resource="outputP"/>
>       </owl:Restriction>
>   </rdfs:subClassOf>
></owl:Class>
>
>Again, I've marked where the changes go:
>
>   <owl:Class rdf:ID="ResultFlow">
>     <comment>
>       ResultFlow implements the output/input pattern flowing from an
>       output to an input.
>     </comment>
>     <rdfs:label>resultFlow</rdfs:label>
>     <rdfs:subClassOf rdf:resource="DataFlow"/>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="#source"/>
>       <owl:allValuesFrom rdf:resource="#OutputSpec"/>  <<--- **
>     </owl:Restriction>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="#destination"/>
>       <owl:allValuesFrom rdf:resource="#InputSpec"/>   <<--- **
>     </owl:Restriction>
>   </owl:Class>
>   .
>
>   <owl:Class rdf:ID="ReturnFlow">
>     <comment>
>       ReturnFlow implements the output/output pattern flowing
>       (typically) from the output of a process to the output of a parent
>       process.  Loosely speaking, this is similar to a return statement
>       in programming languages. 
>     </comment>
>     <rdfs:label>resultFlow</rdfs:label>
>     <rdfs:subClassOf rdf:resource="DataFlow"/>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="#source"/>
>       <owl:allValuesFrom rdf:resource="#OutputSpec"/>   <<--- **
>     </owl:Restriction>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="#destination"/>
>       <owl:allValuesFrom rdf:resource="#InputSpec"/>   <<--- **
>     </owl:Restriction>
>   </owl:Class>
>   .
>
>   <owl:Class rdf:ID="ArgumentFlow">
>     <comment>
>       ArgumentFlow implements the input/input pattern flowing
>       (typically) from the input of a process to the input of a child
>       process.  Loosely speaking, this is similar to argument passing
>       between the declaration of a function and the steps of the
>       function.
>     </comment>
>     <rdfs:label>resultFlow</rdfs:label>
>     <rdfs:subClassOf rdf:resource="DataFlow"/>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="#source"/>
>       <owl:allValuesFrom rdf:resource="#InputSpec"/>   <<--- **
>     </owl:Restriction>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="#destination"/>
>       <owl:allValuesFrom rdf:resource="#InputSpec"/>    <<--- **
>     </owl:Restriction>
>   </owl:Class>
>
>   .
>
>   <owl:Class rdf:ID="ValueFlow">
>     <comment>
>       ValueFlow implements the input/output pattern flowing
>       (typically) from the input of a process to an output. 
>     </comment>
>     <rdfs:label>resultFlow</rdfs:label>
>     <rdfs:subClassOf rdf:resource="DataFlow"/>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="#source"/>
>       <owl:allValuesFrom rdf:resource="#InputSpec"/>    <<--- **
>     </owl:Restriction>
>     <owl:Restriction>
>       <owl:onProperty rdf:resource="#destination"/>
>       <owl:allValuesFrom rdf:resource="#OutputSpec"/>    <<--- **
>     </owl:Restriction>
>   </owl:Class>
>
>   The main problem of this approach is that there is no way to impose a
>   relation between the values of the source parameter and the values of
>   the target parameter.  For example, it could still be possible that
>   the link connects an output parameter "Ticket" with an input parameter
>   "Appointment".    I do not know how we can avoid it.
>
>I don't think it can be avoided; it's another special-purpose module
>of the OWL-S syntax/type checker.
>
>   --------------------------------------------------------------------
>   After thought
>
>   Upon writing this document, I realized that there may be an even
>   simpler solution by providing just a property writeTo that connects
>   outputs to input and readsFrom that connects input to outputs (this
>   model is of course assuming the output/input pattern).
>
>   Basically we do not need the DataFlow class anymore, but just the
>   following two properties:
>
>   <owl:ObjectProperty rdf:ID="writeTo">
>     <rdfs:domain rdf:resource="#Output"/>
>     <rdfs:range rdf:resource="#Input"/>
>   </owl:ObjectProperty>
>
>   <owl:ObjectProperty rdf:ID="readFrom">
>     <rdfs:label>readFrom</rdfs:label>
>     <rdf:type rdf:resource="&owl;#FunctionalProperty"/>
>     <rdfs:domain rdf:resource="#Input"/>
>     <rdfs:range rdf:resource="#Output"/>
>   </owl:ObjectProperty>
>
>   Similarly we could define properties such as argumentTo/From and
>   returnedTo/From.
>
>This has the same problem as above: the flows are properties of
>ParameterSpecs, not Parameters.
>
>With that change, there's nothing wrong with this alternative, except
>that it's asymmetrical.  In some cases, that might be clearer.
>
>At a few places above, you imply that flows can have "fan out" but not
>"fan in."  But there are places where that's exactly what we need.
>Reverting to the surface syntax:
>
>   (Sequence
>      (If-Then-Else
>         :ifCondition C
>	 :then (tag tfoo (Atomic A :results (a)))
>	 :else (tag foof (Atomic B :results (b))))
>      (Atomic C (arg <= (a(^ tfoo)))
>		(arg <= (b(^ foof)))))
>
>(The "^" is an uparrow, meaning "output" param.)  Although the 'arg'
>input to C (declared in the definition of C) is set just once, on any
>given execution of the sequence it will be set by either the true
>branch or the false branch of the conditional.
>
>                                             -- Drew
>
>  
>

Received on Saturday, 11 October 2003 18:38:53 UTC