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

[Shawn Bowers]

 From my understanding of the goals of SEEK, I think what you describe 
below Ferdinando is very much the ultimate goal.  Although it has never 
been formally stated, I think we are working "bottom up" to achieve the 
goal; building the necessary infrastructure so operations as you 
envision below can be realized.  I believe that a driving factor for 
developing the system bottom up is because we are charged with 
"enlivening" legacy data and services.

To do what you suggest, we need ontologies, we need ontology interfaces 
and tools (so users can easily pose such questions, and generally work 
at the ontology level), we need datasets, we need datasets annotated 
with (or accessible via) ontologies (for retrieving, accessing, and 
combining the relevant data), we need workflows/analysis steps (that can 
be executed), and annotations for these as well (so they too can be 
retrieved and appropriated executed). [Note that in SEEK, we haven't yet 
proposed to model the calcuation of, e.g., a Shannon index, we have only 
proposed annotating such processes with instances from an ontology 
(e.g., that the process computes a biodiversity index), and semantically 
describing the types of input and output the process consumes and 
produces (i.e., that it takes proportional abundances, etc., the 
description acting much like a database schema annotated with ontology 
defs).]

Just as a note, what you suggest is also very much related to planning 
problems in AI (which obviously have some practical limitations). A 
benefit of pursuing this bottom-up strategy in SEEK is that we may make 
things easier for scientists and researchers, even if we cannot achieve 
(e.g., either computationally or in a reasonable amount of time) the 
scenario you describe below.


shawn

Ferdinando Villa wrote:

> It may be just semantic nitpicking, but I think what makes things
> complex are the names more than the concepts. As long as we model the
> Shannon index and not the process that calculates it, things are
> extremely simple. Instead of defining the analytical process that
> calculates the index, we recognize it as a concept and create an
> instance of it. Its definition (in the relevant ontology) guides the
> modeling and query process through all the required relationships. Then
> SMS/AMS - not the user - creates the "model". Can we envision what is
> the ultimate concept that the GARP process calculates? Distribution of a
> species? Modeling that concept (using a GARP-aware subclass of the base
> ecological concept) will guide the user through the retrieval of
> compatible data (incrementally narrowing the space/time context to
> search as new required data are added), then create a GARP pipeline and
> run it - and modeling a subclass of it that's defined in another way
> will create GARP version 2.... 
> 
> 2 more cents, of an Euro as always....
> ferdinando
> 
> On Thu, 2004-06-10 at 13:03, penningd at lternet.edu wrote:
> 
>>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
>>>