[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.
Terence
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.
More information about the Kepler-dev
mailing list