[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