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

Shawn Bowers bowers at sdsc.edu
Thu Jun 10 11:15:47 PDT 2004 

I probably don't have the authority to speak about the goals of SEEK 
either :-)

shawn


Ferdinando Villa wrote:

> I like the top-down vs. the bottom-up distinction... Having no
> authorities to speak about the goals of SEEK, I would just add that I
> think there are definite advantages in being able to recognize, e.g.,
> the Shannon index as a concrete subclass of the abstract "Ecological
> diversity" that sits in the core SEEK KB, both from the points of view
> of internal sotfware design and of communicating concepts and tools with
> our user base. Being a concrete class, you can use the Shannon index
> semantic type not only to tag a datases, but also to associate an
> implementation that can produce a workflow from a legal instance of it,
> defined in a suitable knowledge modelling environment, and whose
> complexity scales exactly with its conceptual definition - what the
> ecologist knows already, as opposed to the workflow's complexity. Also
> in terms of system maintenance, this characterization can use a more
> limited set of actors and would concentrate on extending the "tools" by
> extending the knowledge base rather than the processing environment.
> That's where I'm going with the IMA (with GrOWL as the modelling
> environment and with a lot of the "bottom-up" tools and concepts I
> learned from you guys) and I'm very much hoping that by
> cross-fertilizing approaches like this, we can find ourselves at the
> point of encounter before SEEK is over!
> 
> Ciao
> ferdinando
> 
> On Thu, 2004-06-10 at 13:51, Shawn Bowers wrote:
> 
>> 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
>>>>>
>>
>>_______________________________________________
>>kepler-dev mailing list
>>kepler-dev at ecoinformatics.org
>>http://www.ecoinformatics.org/mailman/listinfo/kepler-dev

More information about the Kepler-dev mailing list