[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