[kepler-dev] Re: [seek-kr-sms] UI
Bertram Ludaescher
ludaesch at sdsc.edu
Sat Jun 19 01:06:57 PDT 2004
Part of the SEEK collaboration is IT research. There is no need to
"over-authoritize" research -- Just do it ;-) It's all about exchange
and refinement of ideas (sometimes competing), improving results etc.
Diversity in research is healthy ... Convergence on common visions and
approaches is also very helpful if it can be achieved in a
collaboration.
And when it comes to SEEK operation and development, there is always
the project manager to help prioritize =B-)
cheers
Bertram
Shawn Bowers writes:
>
> 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
>
> _______________________________________________
> 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