[kepler-dev] planned kepler-1.0.0alpha5 release
Chad Berkley
berkley at nceas.ucsb.edu
Wed Feb 23 09:12:02 PST 2005
I'm trying to re-add that functionality now....
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
>>
>>
>
>
More information about the Kepler-dev
mailing list