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

[Edward A Lee]

Apologies for my ignorance, but what is "IMA"?

On a quick glance (hindered by lack of comprehension of TLA's),
these ideas strike me as related to some work we've been doing
on meta-modeling together with Vanderbilt University...  The notion
of meta-modeling is that one constructs models of families of models
by specifying constraints on their static structure...  Vanderbilt
has a tool called GME (generic modeling environment) where a user
specifies a meta model for a domain-specific modeling technique,
and then GME synthesizes a customized visual editor that enforces
those constraints.

Conceivably we could build something similar in Kepler, where
instead of building workflows, one constructs a meta model of a family
of workflows... ?

Just some random neuron firing triggered by Ferdinando's thoughts...

Edward


At 06:44 PM 6/8/2004 -0400, Ferdinando Villa wrote:
>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
> >
>--

------------
Edward A. Lee, Professor
518 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0455, fax: 510-642-2739
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal