W3C home > Mailing lists > Public > public-sws-ig@w3.org > May 2005

Performing an Iterate

From: Moh.-Reza Tazari <Saied.Tazari@zgdv.de>
Date: Fri, 06 May 2005 12:19:08 +0200
Message-ID: <427B449C.8060906@zgdv.de>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:14 UTC