The graph model support that I added is the part of Connectors that 
I'm least happy with. It turns out that the way I did it (even if 
copying weren't broken) gets in the way of sharing graph model items 
between graphs, and also imposes a particular set of decisions as to 
hierarchical graph structuring and policy.

In particular, there is the problem of allowing a particular domain 
model object to have different connectivity in different contexts. 
And there is also the distinction between a Morph and its domain 
model: original Morphic thought would have them be the same thing in 
many cases, but a lot of the time you want to look at Morphs as views 
(hence my separation of graph model items from Morphs).

However, this means that things work differently in Worlds with and 
without graph contexts; in the ones _with_ graph contexts, there is a 
separate structure that represents the "real" graph. Unless this 
(possibly invisible) structure is maintained in a way that coincides 
with the user's needs, it will get in the way. An example of this is 
my desire to have a generic graph iterator morph for Etoys. I'd like 
such a thing to work in a world where the entire graph model is 
implicit in the morphs themselves (i.e. what you see is all you get). 
But I'd also like to be able to use EToys as an extension language 
for certain kinds of operations on Connectors drawings that have a 
deeper model.

I am in the middle of reading Giorgio Busatto's 2002 PhD thesis 
paper, entitled "An Abstract Model of Hierarchical Graphs and 
Hierarchical Graph Transformation" 
(http://theoretica.informatik.uni-oldenburg. 
de/~giorgio/papers/thesis.ps.gz , 672Kb ).

It is quite interesting and probably should be required reading for 
anyone interested in hierarchical graphs of any kind. It is also 
quite readable for someone like me who doesn't have a math or 
computer science degree (though some familiarity with the concepts 
and notation of set theory is helpful), and appears to be obviously 
useful, neither of which I can say about all the graph theory papers 
that I've read.

He argues (convincingly, I think) that because one might want to do a 
number of graph transformations and/or apply various policies to how 
hierarchical graphs are constructed, it is a bad idea to make 
excessively clever graph elements (nodes and edges). In fact, his 
model views the connection relationship between graph elements as an 
attribute of the graph itself, going so far as to move the knowledge 
of connectivity from the edges themselves into the graphs (more 
specifically, into the graph skeleton and its packages).

I think this view would work better in the general case, as it avoids 
having a dual structure that must be maintained separately in the 
case of the Connectors themselves. Changes to the connectivity of a 
Connector are the user's assertions and desires about changes to the 
visible part of the graph itself. However, the morphs in the current 
world or other container may themselves only be a reflection of part 
of a larger graph.

By making the graph package (Busatto's term for a particular subset 
of the nodes and edges of the entire graph, itself part of the 
"hierarchy graph") separate and responsible for reflection on 
connectivity, a number of the problems are eliminated. So questions 
about connectivity are always delegated to a graph package (what I 
called a "graph context"). This lets us have the same graph element 
(nodes or edges) shared, with some elements visible in some contexts 
and not others.

Among the things that need to be made possible to make this end-user 
friendly are:

- specify graph types and policy without having to be a programmer
- create graphical shapes representing specific graph elements (that 
  is, how best to present a focused view of the available graph 
  elements for assocation with the current package)
- use pluggable transformers and iterators to define operations and 
  policy
- see the distinction between the view(s) of the graph and the 
  internal model of the graph (that is, how to make the distinction 
  between (say) deleting the last view of an edge and deleting the 
  edge itself). I'm interested in ideas for how this could be made 
  useful and powerful from a programmer as well as an end-user point 
  of view. Thanks,

-- Ned Konz