[kepler-dev] planned kepler-1.0.0alpha5 release

Bertram Ludaescher ludaesch at ucdavis.edu
Wed Feb 23 09:27:10 PST 2005


Chad Berkley writes:
 > I'm trying to re-add that functionality now....

very good!

 > 
 > Dan Higgins wrote:
 > > 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
 > >>  
 > >>
 > > 
 > > 
 > _______________________________________________
 > 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