[SDM-SPA] Re: [kepler-dev] moving edu.ncsu to org.sdm.spa

[Bertram Ludaescher]

Hi Terence:

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 
accessed)

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..

Bertram



>>>>> "TC" == Terence Critchlow <critchlow1 at llnl.gov> writes:
TC> 
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> 
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> 
TC> Terence
TC> 
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
>> structure.
>> 
>> 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.