- From: Massimo Paolucci <paolucci@cs.cmu.edu>
- Date: Fri, 10 Oct 2003 17:41:14 -0400
- 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 UTC