[kepler-dev] Can I use Ptolemy actors in Kepler?

[Bertram Ludaescher]

Tony:

You're absolutely right. And thanks for being an example of a
higher-order, functional workflow designer ;-)

Some (but clearly not all) workflow users have higher-order,
functional urges at times and for these and other reasons it would be
good to benefit from all Ptolemy goodies (while having capabilities to
hide them from non-suspecting, so-called "end-users" -- who are they
anyways ;-)

As evidence of my membership in the Church of Higher-Order Functions
(COHOF), please accept my humble link to this short paper full of
recycled, half-baked ideas:
    Scientific Workflows: More e-Science Mileage from
    Cyberinfrastructure, B. Ludäscher, et al.  Workshop on Scientific
    Workflows and Business workflow standards in e-Science at
    eScience'06, Amsterdam, December, 2006.
    http://daks.ucdavis.edu/~ludaesch/Paper/ludaescher-escience-wf-mileage.pdf

See Section 4 in particular. Also note the philosophical Figure 4. 
Apart from COHOF (Fig. 4b), it also introduces another new
denomination, i.e. Collection-Oriented Modeling and Design (COMAD).

Expect many converts to COMAD (away from PN, SDF, and even COHOF) once
the Kepler release is out on that.  
Basically it solves all the worlds problems (ok, maybe not cellulitis).
For a first preview on COMAD (I don't expect this to be the last thing
to be heard abou it) see the paper by Tim et al:

    Collection-Oriented Scientific Workflows for Integrating and
    Analyzing Biological Data, T. McPhillips et al. 3rd International
    Workshop on Data Integration in the Life Sciences (DILS'06),
    European Bioinformatics Institute (EBI), Hinxton, UK, July 20-22, 2006.
    http://daks.ucdavis.edu/~ludaesch/Paper/dils06.pdf


Thanks also to Dan for working on what some (sometimes disgruntled)
users want: having the cake and eating it (here: searching all actors w/o
loading them ...)

Bon apetit!

Bertram


>>> On Fri, 22 Jun 2007 12:43:39 +1000
>>> "Tony O'Hagan" <tohagan at itee.uq.edu.au> wrote: 
TO> 
>> From: Dan Higgins [mailto:higgins at nceas.ucsb.edu]
>> Sent: Friday, 22 June 2007 8:34 AM
>> To: Efrat Frank
>> Cc: Norbert Podhorszki; Tony O'Hagan; Kepler-Dev
>> Subject: Re: [kepler-dev] Can I use Ptolemy actors in Kepler?
>> 
>> Hi All,
>> 
>> Just for your information, I am working on a system for showing an
>> actor in the tree without loading it until it is dropped. I've still got
>> some work to go, however.
>> 
TO> 
TO> Hi All,
TO> 
TO> This sounds very promising Dan.  Thanks very much for considering the option
TO> of importing the Ptolemy actors.  I understand the issues in pulling it off
TO> at the moment.
TO> 
TO> In my application requirements I've got nested loops of indefinite length.
TO> I've found that I've had to bend my problem to fit the language (or my lack
TO> of knowledge of it!) by imposing firing count limits (non indefinite) on the
TO> outer loop at design time.  I'm then doing some weird linguistic yoga
TO> writing composite actors that emit functions in order to apply them on
TO> sequences of arrays. I would never expect non-IT scientists to pull off this
TO> kind of functional programming.  These FP workflows are also rather
TO> constrained to (mostly) using Kepler expression, constant and control flow
TO> actors so it works for my current app but I can see that they will break if
TO> in the future I needed to do things outside this space.
TO> 
TO> I finally realised that I was missing some of important Higher Order actors
TO> from Ptolemy that would have simplified my solution. In essence I think that
TO> Kepler either needs at least some of these actors in order to cover the
TO> bases in expressability or perhaps some more examples to show how to pull
TO> off complex iteration and control flow.  Of course there are also lots more
TO> goodies in the Ptolemy tool chest that I wish were available in Kepler. The
TO> sum would be definitely be far greater than the 2 parts as you'd continue to
TO> leverage new Ptolemy actors over time.
TO> 
TO> I still haven't got my complete workflow going yet. It's been a more painful
TO> process than I expected.  In part due to missing actors and actor features
TO> and in part due to unclear or missing documentation.  As a full-time
TO> research programmer I fully understand how & why this happens - I'm just on
TO> the receiving end this time :).
TO> 
TO> Thanks again!
TO> Tony
TO> 
TO> 
TO> 
TO> _______________________________________________
TO> Kepler-dev mailing list
TO> Kepler-dev at ecoinformatics.org
TO> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev