[Tm4j-developers] Re: Panckoucke - Next Version [long]

[Jens K. <jen...@fr...>]

Hi Christoph,

I would like to make some comments on the rather graph related issues you
mentioned in your mail. I think the abstractor process should give the
possibility to convert a given topicmap (or part of it) into a general (!)
graph with certain properties (labels, colors, weights etc); the graph
itself can be handled completely separately from the actual topicmap behind
it. As part of HyperGraph (http://hypergraph.sourceforge.net), I try to
provide a general API for graphs that is as simple as possible and at the
same time as flexible as possible. Most of the comments below have been
implemented there as well (more or less successful ;-)).

> 12. Plain access to nodes and arcs
I would give the model the responsibility to provide access to nodes and
arcs via iterators of lists (as mentioned in a separate mail). If you wrote
a utility method in another class, this method would need to have access to
the set/list of nodes and arcs of the model in some way. The only way to
provide this information for the utility method would be a corresponding
method for the model anyway.

> 8. Subgraphs.
There is a danger to mix subgraphs with connected components of a graph. A
general graph can exist of many different connected components ("islands"),
but it still is one graph. At the moment, the AModel is not able to handle
such a situation properly, but this should (and probably will) change. For
an example you might want to look at the HyperGraph example for the map
"Kings and Queens" (http://hypergraph.sourceforge.net/examples_tm_kaq.html).
There is only one graph that consists of two connected components, one
having three topics (Man/Woman/Person) and another one with the actual
information.
I think that if AModel would be able to handle this, there would be no need
to have a ModelGroup. For this it's vital to have issue 12 implemented to
have access to all nodes and not only those that are connected to a starting
node.

> 10. Make the model accessible through any of its member
If each AMMember had a reference to AModel, it would be "only" a two byte
reference (or whatever java uses), but based on my (small) experience, most
classes or algorithms that would work with members need a reference to the
whole graph (or model) anyway, so a reference from AMMember to AModel would
be redundant in most cases.
Moreover, one could use one AMember in more than one model (can't think of
an actual situation, e.g. two or more models would share the same member) if
there isn't an explicit reference to the AModel.

> 3.Weights
I could think of two different approaches :
a) Add a property "weight" with double values to an arc, i.e. getWeight() /
setWeight(..) at class AMArc.
b) Provide a possibility to attach general properties or attributes to any
element of a graph, which would be a Double object attached to an edge. For
HyperGraph, I used this to add colors, background, icons etc. to nodes and
arcs. I have a three level hierarchy :
- any property attached to an arc or node is only valid for this object.
- there is a notion of groups, grouping different nodes or edges. Each group
can get an own property so that you can establish a group for "instance of"
arcs etc. and each group has different properties. For example you would
have one group "InstanceOf" that is alway a yellow arc with weight 3. Then
these properties would be attached to the group and each arc can belong to
this group.

In HyperGraph, one is able to attach any Object to any part of the graph.
This could be useful for example for the "Gestalten" or more generally for
any kind of additional information about visualisation, let it be color
(class Color), line thickness (class Integer), labels (class String) etc.

> 7. Make the AMMember itself mutable.
I would be careful to change the graph structure only via the model itself.
Say you add some method like "addEndNode(AMNode)" to the arc, then this arc
must make sure that the AMNode is really a member of the graph, because at
any time the graph structure must be consistent, i.e. each arc has to be
known to the model and each node that is start/endpoint of an arc has to be
part of the graph, otherwise the structure of the graph is not well defined.
It might be easier and more convenient to have mutable arcs, but this
creates potential problems with the consistency.

> 2.Using Lists instead of Sets
I'm not quite sure if I got the point or not. From a graph theoretic point
of view, a graph consists of a set (!) of nodes, i.e. two nodes are really
different, no matter of they represent the same thing/idea/topic. Of course
it might happen that one topic in a graph occurs in two different positions,
but then there are two different nodes that represent one topic, not one
node in the graph that occurs twice. Of course this means that there has to
be an identifier of the nodes that is different from the identifiers of the
topics (topic ID) to handle this one to many relationship.

> 5. Represented objects for models
> The model itself should be able to represent objects.
?? I thought a model should represent a graph. Or do you mean that a node
should not be restricted to visualising a topic, but instead a general
object ?


Summarizing the comments I would try to keep the model as general as
possible, rather as a general representation of a graph than of a part of a
topicmap. I would implement the features and properties that are really the
properties of a graph while providing a simple way to enhance it (see number
3b ) .

One strategy that might be useful in this context is the factory strategy:
AModel works with implementations of very simple and rudimentary interfaces
AMArc/AMNode and provides two method "createNode()" and "createArc(Node 1,
Node 2)". This methods would return a simple straight forward implementation
(without weights and Gestalten) and if in some more advanced context it's
necessary to have this information, these two methods would be overwritten
to return more advanced objects that store also weights or Gestalten or
whatever there might come in future.

So much for the moment, I hope the comments were useful.

Best Regards,

Jens.