[kepler-dev] planned kepler-1.0.0alpha5 release
Matt Jones
jones at nceas.ucsb.edu
Tue Feb 22 23:15:28 PST 2005
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
>
>
More information about the Kepler-dev
mailing list