[kepler-dev] breaking off a kepler-docs repository
Bertram Ludaescher
ludaesch at ucdavis.edu
Fri Aug 5 11:26:25 PDT 2005
Dan:
Good points! But here is where I thought the new KAR system (aka KSW)
and/or object manager would help: One could download and install an
(almost) empty Kepler release with as few actors as one likes. Actors
could then be dynamically loaded from the Kepler Actor Repository
(oops .. just overloaded KAR again ;-).
On a related note: I thought we were going in the direction where
directories don't matter much (a single directory a la CP/M will do ;-)
Instead we would have a single repository (call it directory if you
like) but we can have multiple views (aka indexes) on it. Those
views/indexes are based on the actor annotations (e.g. what project
it's from, what scientific domain it might apply to, and most
importantly what overall function it performs.. we can get some
guidance from OWL-S here..)
Bertram
Dan Higgins writes:
> Let me throw in some related comments (not on the KSW system, but on
> different project groups).
>
> I recently went through the entire current actor tree and built a
> simple text file showing ALL the actors currently in the tree. (see
> kepler/docs/dev/actorLibraryDesign/ActorTree.txt; also see
> kepler/docs/dev/actorLibraryDesign/actorOntology.gif). There are now
> approximately 340 actors! Unfortunately, I am not sure anyone
> understands just what all these actor do (especially ones from different
> groups). As an example, I noticed that we have 4 'Constant' actors
> that all do almost the same thing (see attachment) and I think we really
> need to consider whether we need all the actors that are currently in
> the actor tree. (Also, many seem to be in the wrong place in the
> ontology; e.g. 'Interpolator', 'Quantizer', and 'Interpolate' are the
> only actors under "Statistics' and none of them should be (in my
> opinion)). At some point, I think we need to review all the efforts and
> determine just what actors are really of universal use and make that the
> Kepler 'base-set'. Showing all the project specific actors is getting
> too confusing as the numbers continue to increase.
>
> Dan
>
> ----
>
> Chad Berkley wrote:
>
> >I don't think the KSW/ObjectManager system will really have an impact on
> >custom builds, unless you're talking about custom releases (which I
> >think are different). The objman should allow you to create your own
> >ontology for the system and just load the actors (from KSW files) that
> >are specific to that ontology. So you could have a GEON ontology and
> >just have a GEON specific release with relevant components. As far as
> >building and daily development goes, I don't see the objman affecting it
> >very much.
> >
> >chad
> >
> >Bertram Ludaescher wrote:
> >
> >
> >>Indeed, the project-oriented splitting had been discussed before (and
> >>project boundaries are not always clear, e.g., if someone from SEEK
> >>helps someone from SPA (or Geostreams ;-) to jointly write an
> >>actor. Where does it go??
> >>
> >>Chad, could you briefly summarize (or point us to the respective docu)
> >>how the new KSW (KAR ;-) and/or object manager approach might help the
> >>problem of project-specific/custom builds? It seems that under the new
> >>approach, one could just have a "minimal" Kepler build and then
> >>dynamically discover components (actors, workflows, datasets)..
> >>
> >>Bertram
> >>
> >>Chad Berkley writes: > Hi Carlos,
> >> >
> >> > The problem I see with this is that it divides kepler into project
> >> > specific lines where what we're trying to do is create a cross project
> >> > modeling platform. Our src directly was already divided similarly to
> >> > this and it caused numerous problems with organization so we've been
> >> > trying to move stuff to the org.kepler tree. Also, reorganizing stuff
> >> > on that level at this point would be a nightmare.
> >> >
> >> > chad
> >> >
> >> > Carlos A. Rueda wrote:
> >> > > Dear kepler-ers,
> >> > > I think having the two modules kepler/pubs and kepler/dev is a very
> >> > > good idea. In fact (knowing that the current KSW efforts might
> >> > > supersede the following suggestion somehow), I would suggest even go
> >> > > further and split up the /dev module into submodules corresponding to
> >> > > projects, something like:
> >> > > kepler/dev/core
> >> > > kepler/dev/projA
> >> > > kepler/dev/projB
> >> > > ...
> >> > >
> >> > > with each component (submodule) coming with its own build files
> >> > > (build.xml, properties, etc.) and dependencies only on those other
> >> > > required modules.
> >> > >
> >> > > Developer-users would be able to check out only the desired
> >> > > components. This way one can avoid dealing always with the "heavy"
> >> > > kepler and instead work with the minimum set of components required to
> >> > > try and test new developments.
> >> > >
> >> > > carlos
> >> > >
> >> > > Bertram Ludaescher wrote:
> >> > >
> >> > >>Chad Berkley writes:
> >> > >>...
> >> > >>
> >> > >> > a slightly different way. Say kepler/dev and kepler/pubs. That way if
> >> > >> > you only want the code part you could do 'cvs co kepler/dev' If you
> >> > >> > want it all, you would do 'cvs co kepler'. Just a thought.
> >> > >>
> >> > >>Looks like that easiest fix to me. Any objections to this suggestion?
> >> > >>(Would take care of both Chad's problem and the concern that Laura raised)
> >> > >>
> >> > >>BTW, I also think that a document management might be too much effort
> >> > >>right now. An interesting project though for someone who is interested
> >> > >>in that topic ..
> >> > >>
> >> > >>Bertram
> >> > >>
> >> > >> >
> >> > >> > chad
> >> > >> >
> >> > >> > Laura L. Downey wrote:
> >> > >> > > I thought the point was having everything in one place -- which is important
> >> > >> > > with a distributed project. At least that is the impression I've gotten
> >> > >> > > from Matt.
> >> > >> > >
> >> > >> > > It would seem that people are "checking out" instead of "updating" with CVS
> >> > >> > > because update is much quicker. But I think I remember Dan telling me the
> >> > >> > > other day that it is "safer" to check out than to update.
> >> > >> > >
> >> > >> > > I'm fine with whatever is decided, keeping things together or splitting them
> >> > >> > > apart. My only comment is that the more repositories we have and the more
> >> > >> > > places we have to go to get and put data (docs, code etc), the more upkeep
> >> > >> > > that is for everyone.
> >> > >> > >
> >> > >> > > Laura L. Downey
> >> > >> > > Senior Usability Engineer
> >> > >> > > LTER Network Office
> >> > >> > > Department of Biology, MSC03 2020
> >> > >> > > 1 University of New Mexico
> >> > >> > > Albuquerque, NM 87131-0001
> >> > >> > > 505.277.3157 phone
> >> > >> > > 505.277-2541 fax
> >> > >> > > ldowney at lternet.edu
> >> > >> > >
> >> > >> > >
> >> > >> > > -----Original Message-----
> >> > >> > > From: kepler-dev-bounces at ecoinformatics.org
> >> > >> > > [mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Shawn Bowers
> >> > >> > > Sent: Thursday, August 04, 2005 12:02 PM
> >> > >> > > To: Chad Berkley
> >> > >> > > Cc: Kepler-Dev
> >> > >> > > Subject: Re: [kepler-dev] breaking off a kepler-docs repository
> >> > >> > >
> >> > >> > >
> >> > >> > > I think it is a good idea to *not* include the various publications and
> >> > >> > > presentations concerning Kepler in the code repository (cvs).
> >> > >> > >
> >> > >> > > I wonder, however, if having a separate cvs for documents is the way to
> >> > >> > > go. Instead, maybe we should consider using a more traditional approach
> >> > >> > > like a document management system? I'm sure there are a number of
> >> > >> > > open-source/free ones out there (e.g., zope and plone are popular ones,
> >> > >> > > the stanford publication server is an older one). Perhaps there are
> >> > >> > > also extensions of the wiki for this?
> >> > >> > >
> >> > >> > >
> >> > >> > > -shawn
> >> > >> > >
> >> > >> > >
> >> > >> > >
> >> > >> > >
> >> > >> > > Chad Berkley wrote:
> >> > >> > >
> >> > >> > >>Hi all,
> >> > >> > >>
> >> > >> > >>As I sit here checking out kepler (again), waiting forever for the docs
> >> > >> > >>directory to finish, it occured to me that it might be ok to have a
> >> > >> > >>different cvs repository for kepler docs. there's no reason why a
> >> > >> > >>developer should have to checkout out a myriad of .doc and .ppt files
> >> > >> > >>everytime you need a new version of kepler. It seems to me that docs
> >> > >> > >>that actually go with the kepler software should stay in the kepler
> >> > >> > >>repository, but publications, reports and the like could be stashed
> >> > >> > >>somewhere else. Anyone have any reasons why this would be a bad idea?
> >> > >> > >>
> >> > >> > >>thanks,
> >> > >> > >>chad
> >> > >> > >>_______________________________________________
> >> > >> > >>Kepler-dev mailing list
> >> > >> > >>Kepler-dev at ecoinformatics.org
> >> > >> > >>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >> > >> > >
> >> > >> > >
> >> > >> > > _______________________________________________
> >> > >> > > Kepler-dev mailing list
> >> > >> > > Kepler-dev at ecoinformatics.org
> >> > >> > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >> > >> > >
> >> > >> > > _______________________________________________
> >> > >> > > Kepler-dev mailing list
> >> > >> > > Kepler-dev at ecoinformatics.org
> >> > >> > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >> > >> > _______________________________________________
> >> > >> > Kepler-dev mailing list
> >> > >> > Kepler-dev at ecoinformatics.org
> >> > >> > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >> > >>
> >> > >>_______________________________________________
> >> > >>Kepler-dev mailing list
> >> > >>Kepler-dev at ecoinformatics.org
> >> > >>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >> > >>
> >> > >
> >> > > _______________________________________________
> >> > > Kepler-dev mailing list
> >> > > Kepler-dev at ecoinformatics.org
> >> > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >> > _______________________________________________
> >> > Kepler-dev mailing list
> >> > Kepler-dev at ecoinformatics.org
> >> > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >>
> >>
> >>
> >_______________________________________________
> >Kepler-dev mailing list
> >Kepler-dev at ecoinformatics.org
> >http://mercury.nceas.ucsb.edu/ecoinformatics/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
> *******************************************************************
>
> If you look under the Constants folder in the Kepler actors tree, you will see a rich assortment of 'Constant' actors - namely 'Constant', 'StringConstant', 'Single Fire Constant', and 'Permanent String Constant'. The first of these ('Constant') is supplied by Ptolemy. The other three have been added by the sdm/spa, geon, and resurgence groups. Do we really need all these versions of an actor to supply a constant?
>
> Well, is there a difference between them? The original Ptolemy 'Constant' actor supplies a constant every time the actor is fired. That constant can be a number, a string, or any type of value that can be specified by a Ptolemy expression. If the value of the constant is meant to be a string, it must be enclosed in double quotes. If it is not a valid expression, an error is signal when the value is entered.
>
> The 'Single Fire Constant' simply extends 'Constant' with one change - the postfire method returns false. This means that the 'Single Fire Constant' will only supply its value the first time it is fired. As I understand it, this change was just to insure that PN workflows will stop! (Otherwise, the actor keeps sending tokens and a PN workfow will continue to run until there are no more tokens.) The same effect can be obtained by using the Ptolemy SampleDelay actor.
>
> The 'Permanent String Constant' is another variation of 'Constant' that is specialized for strings. There is no need to inclose a string in quotes, but only strings can be input as values. Actually, there is one additional change - the value is defined as a FileParameter meaning that a 'Browse' button appears in the editor so that file names can be selected from a file chooser, but the file name is just sent to the output as a string.
>
> The 'StringConstant' actor combines the changes previously discussed. You can set string values without needing enclosing quotes and it fires only once.
>
> These small differences are subtle and will be confusing to new Kepler users. It seems to me that we really need only the original 'Constant' actor, and that the convenience of note typing quotes is rather limited. In any case, the names should be changed to better reflect what the actors do. If we keep 'Single Fire Constant', then the current 'StringConstant' should be called ' Single Fire String Constant', and 'Permanent String Constant' should be just 'StringConstant'.
>
>
> Other similar actors:
>
> FiringCountLimitPort Ramp vs Ramp
>
> Token Duplicator vs Repeat
>
> TokenCounter vs Counter
>
> FileReaders?
More information about the Kepler-dev
mailing list