W3C home > Mailing lists > Public > www-ws@w3.org > October 2003

Data-flow redux

From: Massimo Paolucci <paolucci@cs.cmu.edu>
Date: Fri, 10 Oct 2003 17:41:14 -0400
Message-ID: <3F87277A.7030503@cs.cmu.edu>
Cc: www-ws@w3.org


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:


<!-- 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="#Parameter"/>
</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.
  </comment>
  <rdfs:domain rdf:resource="#DataFlow"/>
  <rdfs:range rdf:resource="#Parameter"/>
</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.

<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="#Output"/>
  </owl:Restriction>
  <owl:Restriction>
    <owl:onProperty rdf:resource="#destination"/>
    <owl:allValuesFrom rdf:resource="#Input"/>
  </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="#Output"/>
  </owl:Restriction>
  <owl:Restriction>
    <owl:onProperty rdf:resource="#destination"/>
    <owl:allValuesFrom rdf:resource="#Input"/>
  </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="#Input"/>
  </owl:Restriction>
  <owl:Restriction>
    <owl:onProperty rdf:resource="#destination"/>
    <owl:allValuesFrom rdf:resource="#Input"/>
  </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="#Input"/>
  </owl:Restriction>
  <owl:Restriction>
    <owl:onProperty rdf:resource="#destination"/>
    <owl:allValuesFrom rdf:resource="#Output"/>
  </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.

--------------------------------------------------------------------
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.
Received on Friday, 10 October 2003 17:41:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:44 GMT