[kepler-dev] Re: [seek-kr-sms] UI

[Ferdinando Villa]

Hi Deana,

I've started thinking along these lines some time ago, on the grounds
that modeling the high-level logical structure (rather than the workflow
with all its inputs, outputs and loops) may be all our typical user is
willing to do. Obviously I'm biased by interacting with my own user
community, but they're probably representative of the wider SEEK user
community. So I fully agree with you here. 

However, I don't think that we can achieve such an high-level paradigm
simply by augmenting the actors specifications. For the IMA I've done a
pretty thorough analysis of the relationship between the logical
structure of a model/pipeline/concept and the workflow that calculates
the states of the final "concept" you're after; as a result of that, I'm
pretty convinced that they don't relate that simply. In Edinburgh (while
not listening to the MyGrid presentation) I wrote down a rough
explanation of what I think in this regard (and what I think that my
work can contribute to SEEK and Kepler), and circulated to a small group
for initial feedback. I attach the document, which needs some patience
on your part. If you can bear with some dense writing with an Italian
accent, I think you'll find similarities with what you propose, and I'd
love to hear what you think.

Cheers,
ferdinando

On Tue, 2004-06-08 at 17:04, Deana Pennington wrote:
> In thinking about the Kepler UI, it has occurred to me that it would 
> really be nice if the ontologies that we construct to organize the 
> actors into categories, could also be used in a high-level workflow 
> design phase.  For example, in the niche modeling workflow, GARP, neural 
> networks, GRASP and many other algorithms could be used for that one 
> step in the workflow.  Those algorithms would all be organized under 
> some high-level hierarchy ("StatisticalModels").  Another example is the 
> Pre-sample step, where we are using the GARP pre-sample algorithm, but 
> other sampling algorithms could be substituted.  There should be a 
> high-level "Sampling" concept, under which different sampling algorithms 
> would be organized.  During the design phase, the user could construct a 
> workflow based on these high level concepts (Sampling and 
> StatisticalModel), then bind an actor (already implemented or using 
> Chad's new actor) in a particular view of that workflow.  So, a  
> workflow would be designed at a high conceptual level, and have multiple 
> views, binding different algorithms, and those different views would be 
> logically linked through the high level workflow.  The immediate case is 
> the GARP workflow we are designing will need another version for the 
> neural network algorithm, and that version will be virtually an exact 
> replicate except for that actor.  Seems like it would be better to have 
> one workflow with different views...
> 
> I hope the above is coherent...in reading it, I'm not sure that it is  :-)
> 
> Deana
>  
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SEEK_concepts.doc
Type: application/msword
Size: 43520 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20040608/0253ece7/SEEK_concepts.doc