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

[penningd@lternet.edu]

I think these are all excellent ideas, that we should follow up on.  These are
closely related to the whole UI issue.  Ferdinando and I have talked about
trying to generate a prototype of his IMA approach using the GARP workflow.  I
think we should do the same thing with GME.  Or maybe, if we look at them
together, they are closely linked and could be used together.  I think
"meta-model" really conveys the idea here, and that it is the level at which our
scientists are most likely to work.  Generating a working model from a
meta-model seems to be the difficult step, but that's where semantically-created
transformation steps would be extremely useful.  

Deana


Quoting Edward A Lee <eal at eecs.berkeley.edu>:

> 
> 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
> 
> _______________________________________________
> seek-kr-sms mailing list
> seek-kr-sms at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms
>