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

Terence Critchlow critchlow1 at llnl.gov
Thu Apr 8 09:30:01 PDT 2004

Hi Bertram,

This is interesting. I was not aware of the ability to do non-materialized 
views in CVS (or any other versioning system). If that is possible, that 
would be a way to do handle this so everyone sees the information laid out 
as they want / expect, and the actual format of the repository doesn't 
matter as much. If the underlying version control system doesn't support 
this, it would appear to take a lot of work to make it happen since the 
different views would need to be defined and referenced somewhere 
accessible from the repository and / or all versions of an actor would need 
to be updated automatically if any one instance changed.

If you were thinking about it more from the perspective of the users 
finding the available actors (you mentioned actor repository, and I wasn't 
sure if this meant the same as the CVS development repository or not), then 
it becomes a lot simpler - possibly with dynamically generated web pages 
being able to identify the actors based on any of the properties.


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 mailing list