[SDM-SPA] Re: [kepler-dev] moving edu.ncsu to org.sdm.spa
ludaesch at sdsc.edu
Thu Apr 8 09:01:28 PDT 2004
With the "views approach" I didn't mean something that was available
in CVS natively. Rather this would be implemented as a Ptolemy
extension into Kepler itself.
Ideally we should probably try to keep the following independent:
(a) the "dynamic repository view" mechanism
(b) the locality of the actor/workflow repository (local or remote/web
So (a) should work on top of (b) independent whether the actor library
is local or remote .. hm... but maybe a remote repository (b) could
support some of the view mechanism (a) itself.. hmm... I guess we need
to come up with requirements and design for that first.
But it's something that keeps coming up and would be of interest to
many I think..
>>>>> "TC" == Terence Critchlow <critchlow1 at llnl.gov> writes:
TC> Hi Bertram,
TC> This is interesting. I was not aware of the ability to do non-materialized
TC> views in CVS (or any other versioning system). If that is possible, that
TC> would be a way to do handle this so everyone sees the information laid out
TC> as they want / expect, and the actual format of the repository doesn't
TC> matter as much. If the underlying version control system doesn't support
TC> this, it would appear to take a lot of work to make it happen since the
TC> different views would need to be defined and referenced somewhere
TC> accessible from the repository and / or all versions of an actor would need
TC> to be updated automatically if any one instance changed.
TC> If you were thinking about it more from the perspective of the users
TC> finding the available actors (you mentioned actor repository, and I wasn't
TC> sure if this meant the same as the CVS development repository or not), then
TC> it becomes a lot simpler - possibly with dynamically generated web pages
TC> being able to identify the actors based on any of the properties.
TC> At 12:25 PM 4/7/2004 -0700, Bertram Ludaescher wrote:
>> Yes, things can get messy. That's why I had earlier suggested that we
>> have a dynamic classification of actors (and workflows which can be
>> seen as composite actors) based on a list of keywords (or "concepts").
>> Thus all actors would go into one or more actor repositories (there are
>> plans to include web-accessible remote actor libraries into a user's
>> environment, on demand), possible physically structured by function
>> (or domain or whatever else makes sense, including by project if it
>> works out), but *logically* structured by the properties we assign to
>> the actors. For example say that we have two actors with property
>> lists as follows
>> A1 has_prop [p1,p2,p3]
>> A2 has_prop [p1,p4,p5]
>> Wrt. property p1 both A1 and A2 would end up in the same bucket. If
>> for example, p2 isa p4 and p5 isa p3, then organization by properies
>> p2/4 and/or p3/5 gets more interesting.
>> Here we can apply classification and reasoning techniques to come up
>> with a dynamically created folder structure (or concept lattice) which
>> will allow the user to browser and search large actor and workflow
>> libraries by concepts and logical structure instead of physical
>> Obviously one property would be the project affiliation of the
>> contributing authors. Hence one will have a "project view". Another
>> one can be a "function view" (the way Ptolemy/Vergil organizes things
>> by default), yet another one would be by "domain" etc.
More information about the Kepler-dev