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

[harald k. <sc...@ma...>]

Hi Jens,

i just want to comment on some of your remarks and try to clearify some=20
of the points you put question marks onto.

Jens Kanschik wrote:

>Hi Christoph,
>
>I would like to make some comments on the rather graph related issues yo=
u
>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 beh=
ind
>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 th=
e
>same time as flexible as possible. Most of the comments below have been
>implemented there as well (more or less successful ;-)).
>
> =20
>
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 wr=
ote
>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.
>
> =20
>
I also think that we need something like this. Hw do you handle this=20
technically in hypergraph ? Do you have a NodeIterator (ArcIterator)
or do you have something like getAllArcs which returns some collection ?

>>8. Subgraphs.
>>   =20
>>
>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 hand=
le
>such a situation properly, but this should (and probably will) change. F=
or
>an example you might want to look at the HyperGraph example for the map
>"Kings and Queens" (http://hypergraph.sourceforge.net/examples_tm_kaq.ht=
ml).
>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 n=
eed
>to have a ModelGroup. For this it's vital to have issue 12 implemented t=
o
>have access to all nodes and not only those that are connected to a star=
ting
>node.
>
> =20
>
That is a very good point. I think that this is something we really need=20
in panckoucke as topicmaps are not always connected.

>>10. Make the model accessible through any of its member
>>   =20
>>
>If each AMMember had a reference to AModel, it would be "only" a two byt=
e
>reference (or whatever java uses), but based on my (small) experience, m=
ost
>classes or algorithms that would work with members need a reference to t=
he
>whole graph (or model) anyway, so a reference from AMMember to AModel wo=
uld
>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.
> =20
>
While working with the Concretizer stuff, a Model Referecnce would have=20
made live much easier. However implementing Point 12 would have been=20
even more helpfull, so IMHO 12 and 10 are two possible solutions to the=20
same problem: How to process a Model effectivly, but 12 is Probably=20
better in 90 per cent of the use cases i see.
However i do not think that it is possible to use one AMember in two=20
different Graphs / Models as AMNode=B4s hold refernces to "their" AMArcs=20
and vice versa.

> =20
>
>>3.Weights
>>   =20
>>
>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 a=
ny
>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 a=
nd
>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 g=
roup
>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. Th=
en
>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 f=
or
>any kind of additional information about visualisation, let it be color
>(class Color), line thickness (class Integer), labels (class String) etc=
.
>
> =20
>
We always tried to seperate the Graphical costumisation from the=20
Conceptual Part of a Graph, so i think color and thickness should not be=20
part of a graph.
However we have something called a Representation (which i would like to=20
rename to VisualRepresentaion to make it even more clear what they are=20
for) which is a kind of Gestalt dependant rendering hint. I used this=20
for the SVG and VRML Renderer Prototypes of the TopicMapViewer. The=20
Renderer looks up representations accoding to the gestalt of the Node /=20
Arc to render. The Representation then contains Icons / Color /=20
Thickness, whatever may be specified for a given Renderer (so the=20
Representation Implementations are somewhat Renderer dependant).

>>7. Make the AMMember itself mutable.
>>   =20
>>
>I would be careful to change the graph structure only via the model itse=
lf.
>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 defi=
ned.
>It might be easier and more convenient to have mutable arcs, but this
>creates potential problems with the consistency.
> =20
>
Which brings us back to a Reference to the Model. If a Node knows its=20
model, one can either use the AModel methods to manipulate the graph or=20
/ and the AMMembers could use the Graph Methods as well.

> =20
>
>>2.Using Lists instead of Sets
>>   =20
>>
>I'm not quite sure if I got the point or not. From a graph theoretic poi=
nt
>of view, a graph consists of a set (!) of nodes, i.e. two nodes are real=
ly
>different, no matter of they represent the same thing/idea/topic. Of cou=
rse
>it might happen that one topic in a graph occurs in two different positi=
ons,
>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.
>
> =20
>
>>5. Represented objects for models
>>The model itself should be able to represent objects.
>>   =20
>>
>?? I thought a model should represent a graph. Or do you mean that a nod=
e
>should not be restricted to visualising a topic, but instead a general
>object ?
> =20
>
As far as i am concerned (and i think niko and christoph understood this=20
the same) the Model is the Graph and the Representet Object would be the=20
Orginal Data Model or Data Source. This is also something which becomes=20
really important with adding a "way back", a method to synchronize=20
changes in the graph back to the original data structure (as long as the=20
data structure supports this).

>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 o=
f 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 nu=
mber
>3b ) .
>
>One strategy that might be useful in this context is the factory strateg=
y:
>AModel works with implementations of very simple and rudimentary interfa=
ces
>AMArc/AMNode and provides two method "createNode()" and "createArc(Node =
1,
>Node 2)". This methods would return a simple straight forward implementa=
tion
>(without weights and Gestalten) and if in some more advanced context it'=
s
>necessary to have this information, these two methods would be overwritt=
en
>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.
>
> =20
>
I can=B4t speak for christoph, but your comments at least were very usefu=
l=20
to me.

>Best Regards,
>
>Jens.
>
>
> =20
>
Cheers,
Harald