- From: Moh.-Reza Tazari <Saied.Tazari@zgdv.de>
- Date: Fri, 06 May 2005 12:19:08 +0200
- To: public-sws-ig@w3.org
Hi,
considering iterations, I encountered a problem for which I would like
to propose a solution (see below). Hope that I'm not losing sight of
something regarding both the problem and the proposed solution.
Cheers,
-- Saied
The issue
---------
Considering the concept of 'Iterate', I believe that it would be wrong
to wrap the definition of, say, a 'whileProcess' in a named perform,
because each loop should result in a new perform instance.
A possible solution
-------------------
. Introduce the new concept 'LoopedPerform' as a subclass of
'Perform'.
. Add the new property 'loopedProcess' with domain 'Iterate'
and range 'LoopedPerform'.
. Omit the properties 'whileProcess' and 'untilProcess'.
The expected client behavior
----------------------------
A client encountering a LoopedPerform with ID 'x' must take this as a
"virtual" perform holding place for a number of actual performs with the
IDs 'x_1', 'x_2', ... and must setup the perform context for each call
accordingly.
The consequence
---------------
A standard variable could be introduced representing the perform
instance from the previous loop in an iteration.
P.S.
----
By the way, the following excerpt from
http://www.daml.org/services/owl-s/1.1/overview/:
<owl:Class rdf:ID="Iterate">
<rdfs:subClassOf rdf:resource="#ControlConstruct"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#components"/>
<owl:allValuesFrom rdf:resource="#ControlConstructBag"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
seems to be erroneous, because in
http://www.daml.org/services/owl-s/1.1/Process.owl the domain of
'components' is explicitly restricted to a union of which 'Iterate' is
no member (which is reasonable IMHO).
Received on Friday, 6 May 2005 10:19:37 UTC