On Thursday 23 December 2004 10:51 am, Michael Latta wrote:

> Looking through the connectors GraphModel classes I have several
> questions:
>
> 1) Are these classes meant to hold application data, or are they
> "models" for the connectors morphs?

Sigh...

My intention was to give an easy way for end-users or programmers to attach 
models to the connectors and to other morphs used as nodes in graphs using 
connectors.

Previously, there was no easy or standard way to associate a model item with a 
connector, so you couldn't have a particular model item viewed by multiple 
connectors. And you couldn't separate the model from the views.

So I figured that what I needed was to have a separate concept of graph 
models. I wrote a set of graph model and context classes that were extensible 
using a property dictionary. And I made several pluggable or subclassable 
kinds of iterator with different iteration policies. You can look at this 
work at my MC repository mirror at 
http://bike-nomad.com/squeak/monticello/Connectors (ConnectorsGraphModel, 
ConnectorsGraphIterators).

But then what got me was the hierarchical graphs. I realized that if I had 
more than one idea of how to use hierarchical graphs, probably other people 
did as well.

The problem comes with the relationship between the different sub-graphs of a 
hierarchical graph, and between differing views of the same entities in 
different graphs.

For instance, in some cases (like, say, making a visual language that allows 
you to expand nodes into other graphs) you want to summarize connections into 
a single connector in the top-level graph. Sometimes you don't.

Similarly for (say) pins in such a language: they would be viewed in two 
different contexts: the graph in which the symbol was used (where they'd be 
connected to from outside) and the graph in which the symbol was defined 
(where they'd connect to the guts of the symbol).

In other cases, you might want to summarize or otherwise fold nodes or edges 
or some combination into other nodes or edges; in some cases you'd want to 
hide them, etc.

If you look at how different software handles hierarchical graph you'll see 
many different ideas. I wrote this to the list earlier:

--
Short answer: I am in the midst of re-thinking the graph model stuff. I would 
recommend that you postpone using it for a bit, as I will probably rip it out 
soon and replace it with something quite different.

A longer answer (and one that might bear some reflection on the list):

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.

--

> 2) Can you elaborate on the serialization functions in Connectors?  I
> see a hook for when an NCGraphElementModel is loaded from disk into a
> project (named class missing).

These use the standard Squeak serialization support. What I did in Connectors 
1.9 was to serialize all the graph elements as a single array. Again, I ran 
into problems with multiple graphs and since I was trying to support 
Squeakland first, the menu items for serialization (and hence the support for 
it) were left out.

> 3) I do not see evidence of a read/write method.  Are they inherited,
> missing, a work in progress, or a planned future feature?

As I said, the read/write is handled by the usual Squeak means 
(SmartRefStream).

Thanks for your interest,
-- 
Ned Konz
http://bike-nomad.com/squeak/