[kepler-dev] planned kepler-1.0.0alpha5 release
Arcot Rajasekar
sekar at sdsc.edu
Wed Feb 23 08:30:02 PST 2005
Hi Bertram
Look at the concept of pf files that are used in Antelope
software. They have a whole bunch of different types of parametr files
which can include data structures such as lists, arrays, etc in them....
They use the pf files for everything including executing cron jobs.
I am ccc;ing Kent who might give more info on this....
2c
raja
On Wed, 23 Feb 2005, 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
>
More information about the Kepler-dev
mailing list