[kepler-dev] planned kepler-1.0.0alpha5 release

Dan Higgins higgins at nceas.ucsb.edu
Wed Feb 23 09:06:28 PST 2005


Bertram,
    FYI, Ptolemy has a User folder where personal actors and workflows 
can be stored (in a .ptolemy file in /home, I think) that survives 
reinstallation. We somehow lost this capability in adding new features. :-)

Dan

Bertram Ludaescher wrote:

>Hi Matt:
>
>Re. the config. file: this sounds like a very good plan! 
>Re. the complexity of the files -- I guess some of the complexity
>might come from the different kinds of config files one wants to have:
>- simple attribute/values kinds of settings (a la .Xdefaults for
>those who remember ;-)
>- more powerful "code files", e.g., a la .Xinitrc, .bashrc, .emacs, etc
>This kind of thing seems like good Ptolemy/Kepler discussion
>topic. 
>
>Re. use of a Sparrow-like language for annotations: There are probably
>different parts to consider. I guess I need to look at the part for
>which Chad is working on the design of a GUI. But there is also a part
>that can clearly benefit from a Sparrow syntax entry/editing mechanism
>-- even and in particular for ecologists: Think of an actor parameter
>or the name and type of actor port: We don't really need a "GUI" for
>that. An actor parameter can be as simple as a number or in more fancy
>cases an expression from the Ptolemy expression language. Clearly, the
>former is bested entered via the keyboard. And even for the latter,
>this (PT expressions) it is a reasonable choice to have a text entry
>form. It is in this sense (settings of actor parameters, port types
>etc) that I think a semantic annotation should first be tried (until
>proven otherwise) via a simple textbased window. For example we might
>say sth like this: 
>    [Name:] SRB.Sput
>    [Actor category:] df.Grid, df.SRB, SRB.DataMovement
>    [foo Port:] df.InputPort, SRB.ConnectionToken
>    [bar Port:] df.OutputPort, SRB.GridHandle
>Here each line would be a separate entry "form", with the stuff in
>brackets given by the system. The "df." and "SRB." are namespace
>prefixes. The stuff afterwards are controlled terms from the
>respective vocabulary. The "," corresponds to a logical conjunction
>For some reason, above the foo port (whose Ptolemy IO type is probably
>"input") has been also semantically annotated using the concept
>"InputPort" (from the default ontology).
>
>Clearly the above needs some more thought, but the basic idea is this:
>we can specify things like port names, port types, parameter values
>etc already in text-form. We should try to keep this for certain
>semantic type annotations too. At least until proven impossible. That
>is not to say that a GUI to select a value from a (large) controlled
>vocabulary isn't useful. But we should first get the basic SMS type
>system going which includes figuring out how the ("sparrow"-like)
>abstract syntax works. 
>
>Does that make sense?
>
>Bertram
>
>Matt Jones writes:
> > Hi Bertram,
> > 
> > I was suggesting to Shawn exactly the kind of configuration mechanism 
> > that you described.  The idea would be that user prefs would override 
> > defaults and survive kepler upgrades, and that user-prefs would be 
> > bootstrapped by copying the defaults into the users .kepler directory.  
> > So far we have a couple of configuration files in kepler, one of which 
> > is in the traditional ptolemy "configuration", and one of which is 
> > kepler-specific.  The ptolemy configuration file is quite a bit more 
> > complicated to extend because it itself is a MOML file and is parsed 
> > using the MOML parser, which requires a dynamically loadable class for 
> > every configuration property.  So, for some of the simpler configuration 
> > properties that we've simply wanted to record we have created a separate 
> > config file (config.xml).  Its against this backdrop that we'd like to 
> > create user-customizable configuation preferences, and allow users to 
> > store their own ontologies.  A comprehensive solution needs to be 
> > carefully designed to make it easier for us to extend and maintain the 
> > kepler configuration and not complicate the already complex 
> > configuration mechanisms we have in place.
> > 
> > Regarding the ontologies, I think user-customizable ontologies would be 
> > great, and Chad is working on a design for a GUI that allows the simpler 
> > classification ontologies to be modified as part of the Kepler tree.  
> > More complex ontology editing I think is a difficult topic.  The sorts 
> > of annotations that Shawn has proposed for data and actors are clearly 
> > needed but are going to be difficult to compose even with an amazingly 
> > well-conceived user interface (witness the difficulties with 
> > comprehending simple ontologies with Growl).  I personally don't believe 
> > the Sparrow language is suitable for exposure through the Kepler 
> > interface for the ecological scientists and other scientists at whom we 
> > are targeting the UI.   Do you have a user-clientele in mind that you 
> > think would embrace Sparrow?  I don't think the ecologists will, but 
> > maybe there's another group of users you have in mind.
> > 
> > About the actors that were hidden: they were simply not classified in 
> > the actor annotation file because they were deemed not-useful for the 
> > types of workflows we have been targeting. I think this needs to be 
> > reviewed. We can either add them into the ontology in the categories 
> > they belong, or create one or more new categories to contain these 
> > 'advance features' that should be less emphasized in the 
> > categorization.  We should really get Laura involved in getting specific 
> > user feedback from our ecological science testers about whether all 
> > actors should be included and if not, which to exclude.  I think its 
> > valuable to simplify the list of choices to include only those that are 
> > useful to a particular domain.  Because we intend to support multiple 
> > ontologies that can change from domain to domain, the list of actors 
> > that are relevant can also be customized depending on the domain.  The 
> > actors still exist in Kepler, so workflows that use them will still work 
> > fine -- they just don't show up in the tree if they are not in the actor 
> > annotation file.  Shawn and Chad can probably clarify the situation and 
> > correct any mistakes I might have made in describing it.
> > 
> > Matt
> > 
> > Bertram Ludaescher wrote:
> > 
> > >Shawn Bowers writes:
> > > > Bertram Ludaescher wrote:
> > > > 
> > > > >  > On another note, we talked a bit on IRC a few days ago about some of the 
> > > > >  > needed infrastructure within kepler to handle these changes.  One 
> > > > >  > problem is that the only way to make an annotation, ontology change, or 
> > > > >  > any other configuration in Kepler "last" is by checking in the changes 
> > > > >  > to cvs.  
> > > > > 
> > > > > I'm not sure I understand. Why can't there be a start-up sequence in
> > > > > which the system looks for user-specific init/config files, after
> > > > > loading the version specific ones? For example, XEmacs does something
> > > > > like that on start-up: first load the "default configs" (corresponding
> > > > > what would be found in the release/cvs) then look for the "user
> > > > > configs", e.g., at the the place defined by an environment
> > > > > variable (if it is defined), or if such isn't defined, then at a
> > > > > "user location" such as ~/.keplerrc 
> > > > 
> > > > Yeah ... I don't think conceptually any of this is probably that 
> > > > difficult; it's just that someone needs to implement it!
> > > > 
> > > > > 
> > > > > I'm not sure what Ptolemy II does at start-up, but I wouldn't be
> > > > > suprised if they'd let you do sth like that (and if they don't,
> > > > > probably Kepler should do sth like that).
> > > > 
> > > > It's all just java code, so if we can change the base code, we're golden.
> > >
> > >Or (as just discussed ;-) maybe we can use some existing "start-up
> > >hooks" of Ptolemy ... 
> > >
> > > > 
> > > > shawn
> > > > 
> > > > > 
> > > > > The big advantage of course would be that all user preferences,
> > > > > configs, workflows, actors etc would "survive" an new Kepler install,
> > > > > even if done "in-place".
> > > > > 
> > > > >  > This somewhat limits customization ... and is a larger issue 
> > > > >  > that needs to be addressed.  Matt suggested using their approach in 
> > > > >  > Morpho which involves copying files at startup, etc., which may be one 
> > > > >  > way to do it.
> > > > > 
> > > > > I don't think copying is needed (see above)
> > > > > 
> > > > > Bertram
> > > > > 
> > > > >  > 
> > > > >  > Shawn
> > > > >  > 
> > > > >  > 
> > > > >  > 
> > > > >  > Bertram Ludaescher wrote:
> > > > >  > > Hi Matt:
> > > > >  > > 
> > > > >  > > A related question: I remember that at some point some Ptolemy actors
> > > > >  > > were hidden (or otherwise disappeared from the Kepler actor tab). I
> > > > >  > > assume they are still part of the Kepler distribution though, right?
> > > > >  > > 
> > > > >  > > Also: What are the plans for being able to edit actor annotations?
> > > > >  > > (currently they seem to be "pseudo-hardwired", i.e., via some OWL-ishe
> > > > >  > > files). As simple text-based form (just like the one for configuring
> > > > >  > > ports or in fact one that links into that one) might do.
> > > > >  > > 
> > > > >  > > The ontology itself should be just a config file that can be changed
> > > > >  > > via "Preferences" / "Options"..
> > > > >  > > 
> > > > >  > > Any comments?
> > > > >  > > 
> > > > >  > > Bertram
> > > > >  > > 
> > > > >  > > Matt Jones writes:
> > > > >  > >  > Hi,
> > > > >  > >  > 
> > > > >  > >  > On our roadmap that we developed at the last Kepler meeting we said we 
> > > > >  > >  > would try for an alpha 5 release by Feb 21 (see 
> > > > >  > >  > http://kepler-project.org/Wiki.jsp?page=KeplerReleaseRoadmap&version=1). 
> > > > >  > >  >   That hasn't happened but is probably still useful.  I talked with Dan 
> > > > >  > >  > today, and we thought it would be good to go ahead with a release to try 
> > > > >  > >  > to get some of the bug fixes and improvements that we've completed now 
> > > > >  > >  > out there in a more accessible format.  So Dan is planning on pulling 
> > > > >  > >  > the CVS HEAD on Friday Feb 25 and creating the alpha5 installers then. 
> > > > >  > >  > If you have anything you want included in this release, please check it 
> > > > >  > >  > into CVS by Thursday the 24th, and please try not to check in any 
> > > > >  > >  > experimental code that is likely to break the trunk (use a branch instead).
> > > > >  > >  > 
> > > > >  > >  > A revised roadmap is here:
> > > > >  > >  > 
> > > > >  > >  > http://kepler-project.org/Wiki.jsp?page=KeplerReleaseRoadmap
> > > > >  > >  > 
> > > > >  > >  > The main differences from the previous roadmap version are that: 1) the 
> > > > >  > >  > documentation framework isn't complete so has been moved to alpha6, and 
> > > > >  > >  > 2) the R improvements are ongoing and so have been extended to alpha6. I 
> > > > >  > >  > also added links to the bug lists for each milestone.  The alpha 6 
> > > > >  > >  > release is slated for April 15th, 2005 (just prior to the SEEK and GEON 
> > > > >  > >  > meetings and the Ptolemy/Kepler miniconference), and I think we should 
> > > > >  > >  > try hard to make that deadline.
> > > > >  > >  > 
> > > > >  > >  > Cheers,
> > > > >  > >  > Matt
> > > > >  > >  > 
> > > > >  > >  > -- 
> > > > >  > >  > -------------------------------------------------------------------
> > > > >  > >  > Matt Jones                                     jones at nceas.ucsb.edu
> > > > >  > >  > http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
> > > > >  > >  > National Center for Ecological Analysis and Synthesis (NCEAS)
> > > > >  > >  > University of California Santa Barbara
> > > > >  > >  > Interested in ecological informatics? http://www.ecoinformatics.org
> > > > >  > >  > -------------------------------------------------------------------
> > > > >  > >  > _______________________________________________
> > > > >  > >  > 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
> > >  
> > >
>
>_______________________________________________
>kepler-dev mailing list
>kepler-dev at ecoinformatics.org
>http://www.ecoinformatics.org/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
*******************************************************************




More information about the Kepler-dev mailing list