[kepler-dev] Additional menu items

Laura L. Downey ldowney at lternet.edu
Thu Jan 26 07:33:06 PST 2006


This sounds nice from a consistency and usability standpoint Edward.  Create
Component fits nicely with Create Composite Actor as two things to "create"
in a workflow.

But would the approach you describe below in which you say try instantiating
the entity first and then attribute if that doesn't work.... would this make
sense to programmers or would it be confusing?

As a possible alternative, would it make sense to have Create Component
cascade to two sub menu items of Actor and Director? Or would it make more
sense to retain the items Instantiate Entity and Instantiate Attribute as
sub-menu items of Create Component?

Laura L. Downey
Senior Usability Engineer
LTER Network Office
Department of Biology, MSC03 2020
1 University of New Mexico
Albuquerque, NM  87131-0001
505.277.3157 office
505.610.9657 mobile
505.277-2541 fax
ldowney at lternet.edu
 

-----Original Message-----
From: Edward A. Lee [mailto:eal at eecs.berkeley.edu] 
Sent: Tuesday, January 24, 2006 8:09 PM
To: Dan Higgins
Cc: Laura L. Downey; Kepler-dev at ecoinformatics.org
Subject: Re: [kepler-dev] Additional menu items


I agree with you and Laura that the terminology is strange,
and I think it could be improved (with some effort)...

The approach I would
take would be to try to instantiate the object as an entity,
and if that fails with a recognized exception, try to instantiate
it as an attribute.  This is not elegant, but it would work,
and then the menu item could be renamed something less jargony,
like "Create component".

A more elegant approach would augment MoML with an element
to create an instance without specifying whether it is a
subclass of Entity or Attribute, but this would never be used
except internally, and I hate to pollute MoML with elements
that are irrelevant to outside users...

If someone wants to propose an implementation of the above,
I'm happy to make a pass on it (if necessary) and put it in
the Ptolemy tree...  It's probably not much more than a few
lines of code that need to change...

Edward

At 02:37 PM 1/24/2006 -0800, Dan Higgins wrote:
>Laura,
>     I agree that the two menu  items are not really of use to the
>novice. However, it is not only the advanced programmer who may want to
>use them. Anyone trying to build or modifiy a workflow may need to add
>some new actor not in the release.
>
>     A technical point (which is due to Ptolemy specific technical
>factors) --- If we want to add an actor, then one uses 'Instantiate
>Entity', but to add a director, one uses 'Instantiate Attribute' ; I
>know this is a bit strange, but a director is technically an 'attribute'
>and not an 'entity' (while an actor is an entity) !
>
>
>Dan
>
>Laura L. Downey wrote:
>
> >Sorry been out of town so just seeing this.  I will leave the coding
> >discussion of re-use and taking advantage of new Ptolemy functionality
when
> >implemented and vice versa from the Kepler perspective, to the architects
> >and developers.
> >
> >Specifically to the two menu items that might have been mistakenly
removed
> >in the proposed re-design -- yes, from a design perspective, we can
easily
> >add them back.  And it sounds like with Matthew's implementation, that is
> >not a major coding issue.
> >
> >While in general, I think it is a good idea to stay away from computer
> >science centric terms (such as "Instantiate") because we have a
combination
> >of user groups that will use Kepler (both scientists and programmers), I
> >don't see the domain scientists or informatics scientists type of Kepler
> >users really using these items.  They are designed for people with coding
> >knowledge that will be creating and testing new actors and directors --
so
> >in that respect it would be programmers using Kepler that would most
likely
> >use the items of Instantiate Entity and Instantiate Attribute.
> >
> >For the moment, I'll suggest we add these two items to the proposed Tools
> >menu.  And I would like to also suggest we change "Instantiate Entity" to
> >"Instantiate Component" since we are calling actors and directors
workflow
> >components in Kepler.
> >
> >
> >Laura L. Downey
> >Senior Usability Engineer
> >LTER Network Office
> >Department of Biology, MSC03 2020
> >1 University of New Mexico
> >Albuquerque, NM  87131-0001
> >505.277.3157 office
> >505.610.9657 mobile
> >505.277-2541 fax
> >ldowney at lternet.edu
> >
> >
> >-----Original Message-----
> >From: kepler-dev-bounces at ecoinformatics.org
> >[mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Matthew
Brooke
> >Sent: Monday, January 23, 2006 5:04 PM
> >To: Christopher Brooks
> >Cc: Kepler-dev at ecoinformatics.org
> >Subject: Re: [kepler-dev] Additional menu items
> >
> >Just adding a little extra information, in the hope of allaying some of
> >Edward's and Bertram's fears...
> >
> >At first glance, the new kepler menu system may appear like a
> >"branching" of the ptii menu implementation, when in fact it is not - it
> >is merely a 'view' (in a loose sense) of the ptii menus. It enumerates
> >all the existing ptii menu items at runtime, and re-uses them,
> >rearranged (and optionally renamed) - all set via mappings in a
> >localizable resourcebundle properties (text) file.
> >
> >This means that if/when new menu items get added to ptii, they are
> >immediately available to kepler, just by adding the relevant text
> >mapping to the properties file. The fact that this still requires a
> >small amount of human intervention is not a bad thing - it avoids the
> >potentially problematic scenario whereby new ptii menu items
> >automatically appear in the kepler menus, possibly in places where
> >Kepler doesn't want them.
> >
> >m
> >
> >
> >Christopher Brooks wrote:
> >
> >
> >>All -
> >>
> >>Maybe we should talk some about the general problem of getting changes
> >>from Kepler in to Ptoelmy on Wednesday, February 8th?
> >>
> >>We should discuss it further via email, but we may need to discuss this
> >>face to face meeting.
> >>
> >>I'll demonstrate the new menu Kepler structure to Edward tomorrow at
> >>Ptolemy group lunch and get his feedback.
> >>
> >>In as much as possible, modulo Edward's opinion, I'd like to use the
> >>Kepler menu structure in Ptolemy II.
> >>
> >>Perhaps it would be nice to fold Matthew's menu work in to Ptolemy so
> >>that Ptolemy can use it?  Matthew's work makes it easier to configure
> >>the menus without necessarily adding a class.  We would need to make
> >>sure that Matthew and the Kepler project get lots of credit for this.
> >>We could consider creating a third cvs repository with common code,
> >>but this seems like overkill.  I'm also not sure when (if ever)
> >>would be a good time to move the code.  We might just want to change
> >>the menus in Ptolemy to better match the Kepler menus?
> >>
> >>I think the biggest issue with folding changes in to the Ptolemy tree
> >>is that the new code needs to follow the Ptolemy style guide and be
> >>well documented.  I'm more than willing to work on this.
> >>
> >>An issue for the Kepler group is that the Ptolemy style guide is
> >>probably not what you want.
> >>
> >>Another Kepler issue is that we don't want Ptolemy subsuming Kepler
> >>and getting credit for work done by the Kepler project.
> >>
> >>Another issue is that in the past Edward and I have spent a bunch of
> >>time cleaning up a contribution when maybe our time would have been
> >>better spent elsewhere.  I think the Kepler work is of much higher
> >>quality than the other contributions I've seen, but it is an issue
> >>that has come up.
> >>
> >>Anyway, I want to be flexible in how we proceed here, so I'm open to
> >>suggestions.
> >>
> >>
> >>_Christopher
> >>
> >>Betram wrotes:
> >>--------
> >>
> >>
> >>    Edward et al:
> >>
> >>    I am a strong advocate of an incremental approach (and have said so
> >>    before :-). I share the concern that we might be decoupled from new
> >>    developments in Ptolemy and thus should make every effort to make
> >>    "smooth" changes, so that Ptolemy can follow when it makes sense,
and
> >>    conversely, we can inherit new developments from Ptolemy..
> >>
> >>    Easier said than done, I know..
> >>
> >>    Bertram
> >>
> >>    >>> On Mon, 23 Jan 2006 09:19:36 -0800
> >>    >>> "Edward A. Lee" <eal at eecs.berkeley.edu> wrote:
> >>    EAL>
> >>    EAL> Instantiate Entity brings up a dialog into which you type a
class
> >>
> >>
> >name
> >
> >
> >>   .
> >>    EAL> The class can defined in Java or in MoML, and the command will
> >>
> >>
> >create
> >
> >
> >>    EAL> an instance of the class...
> >>    EAL>
> >>    EAL> This mechanism is very useful for experimenting with new actors
> >>
> >>
> >withou
> >
> >
> >>   t
> >>    EAL> having to include them in a library...
> >>    EAL>
> >>    EAL> The corresponding Instantiate Attribute  is also useful (e.g.
for
> >>
> >>
> >crea
> >
> >
> >>   ting
> >>    EAL> an instance of a new director that is under development).
> >>    EAL>
> >>    EAL> Any class in your classpath can be instantiated this way.
> >>    EAL>
> >>    EAL> BTW: One downside of creating a new, parallel menu structure in
> >>    EAL> Kepler is that Kepler will not automatically benefit from
> >>
> >>
> >capabilities
> >
> >
> >>    EAL> we add to Ptolemy II.  This consideration should be balanced
> >>
> >>
> >against
> >
> >
> >>    EAL> aesthetic considerations...  Also, we are more than happy to
> >>
> >>
> >rearrange
> >
> >
> >>    EAL> menus in Ptolemy II when reasonable suggestions are made...
> >>    EAL>
> >>    EAL> Edward
> >>    EAL>
> >>    EAL> At 06:46 PM 1/22/2006 -0800, Shawn Bowers wrote:
> >>    EAL>
> >>    >> Dan,
> >>    >>
> >>    >> Can you give a little more description of how the "Instantiate
> >>
> >>
> >Entity"
> >
> >
> >>    >> works?  Does this work by pointing Ptolemy at a MoML file (e.g.,
an
> >>
> >>
> >"Act
> >
> >
> >>   or
> >>    >> Class") or by pointing it at a java actor class (e.g.,
"org.kepler.
> >>
> >>
> >..."
> >
> >
> >>   ).
> >>    >>
> >>    >> Thanks,
> >>    >>
> >>    >> -shawn
> >>    >>
> >>    >>
> >>    >>
> >>    >> On Sun, 22 Jan 2006, Dan Higgins wrote:
> >>    >>
> >>    >> > Matthew,
> >>    >> >     Congratulations on getting the new Kepler menu layout
working
> >>
> >>
> >(and
> >
> >
> >>    >> > the ability to change the configuration)!
> >>    >> >
> >>    >> >     However, it looks likes we left out a couple of menu items
> >>
> >>
> >that I
> >
> >
> >>    >> > just recently learned to appreciate! --- namely 'Instantiate
> >>
> >>
> >Attribute
> >
> >
> >>   '
> >>    >> > and 'Instantiate Entity' under the 'Graph' menu.
> >>    >> >
> >>    >> > I must admit that I did not understand just what these menu
items
> >>
> >>
> >were
> >
> >
> >>    >> > used for until recently (and I might have suggested to Laura
that
> >>
> >>
> >we
> >
> >
> >>    >> > leave them out in Kepler).
> >>    >> >
> >>    >> > 'Instantiate Attribute' allows the user to add attributes to
the
> >>    >> > workflow by name. This allows one to add attributes that are
not
> >>
> >>
> >in th
> >
> >
> >>   e
> >>    >> > Kepler Actor Ontology tree to a workflow! (And we have not
> >>
> >>
> >included al
> >
> >
> >>   l
> >>    >> > the ones in Ptolemy.) Similarly, 'Instantiate Entity' allows
one
> >>
> >>
> >to ad
> >
> >
> >>   d
> >>    >> > actors; there are many Ptolemy actors/directories that we have
> >>
> >>
> >not
> >
> >
> >>    >> > included in our actor ontology and I have already been asked by
> >>
> >>
> >severa
> >
> >
> >>   l
> >>    >> > users how to add such actors to workflows without having to
> >>
> >>
> >recompile
> >
> >
> >>    >> > the whole Kepler system. It also turns out that whole new actor
> >>
> >>
> >classe
> >
> >
> >>   s
> >>    >> > can be added using this menu item (i.e. new classes).
> >>    >> >
> >>    >> > So I think these two menu items should be included in the new
> >>
> >>
> >menu
> >
> >
> >>    >> > layout, probably in the Workflow menu. Maybe Laura will want to
> >>
> >>
> >change
> >
> >
> >>    >> > the menu item names?
> >>    >> >
> >>    >> >
> >>    >> > Dan
> >>    >> >
> >>    >> > _______________________________________________
> >>    >> > Kepler-dev mailing list
> >>    >> > Kepler-dev at ecoinformatics.org
> >>    >> >
> >>
> >>
> >http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-d
> >
> >
> >>   ev
> >>    >> >
> >>    >> _______________________________________________
> >>    >> Kepler-dev mailing list
> >>    >> Kepler-dev at ecoinformatics.org
> >>    >>
> >>
> >>
> >http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >
> >
> >>    EAL>
> >>    EAL> ------------
> >>    EAL> Edward A. Lee
> >>    EAL> Professor, Chair of the EE Division, Associate Chair of EECS
> >>    EAL> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720
> >>    EAL> phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
> >>    EAL> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
> >>    EAL>
> >>    EAL> _______________________________________________
> >>    EAL> Kepler-dev mailing list
> >>    EAL> Kepler-dev at ecoinformatics.org
> >>    EAL>
> >>
> >>
> >http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-d
> >
> >
> >>   ev
> >>
> >>    _______________________________________________
> >>    Kepler-dev mailing list
> >>    Kepler-dev at ecoinformatics.org
> >>
> >>
> >>
> >http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >
> >
> >>--------
> >>_______________________________________________
> >>Kepler-dev mailing list
> >>Kepler-dev at ecoinformatics.org
> >>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >>
> >>
> >
> >
> >
>
>
>--
>*******************************************************************
>Dan Higgins                                  higgins at nceas.ucsb.edu
>http://www.nceas.ucsb.edu/   Ph: 805-893-5127
>National Center for Ecological Analysis and Synthesis (NCEAS) Marine 
>Science Building - Room 3405
>Santa Barbara, CA 93195
>*******************************************************************
>
>
>_______________________________________________
>Kepler-dev mailing list
>Kepler-dev at ecoinformatics.org
>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev

------------
Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal  




More information about the Kepler-dev mailing list