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

[Christoph F. <cf...@fo...>]

Hi Jens, hi harald

[Jens, I'm really happy to get comments from somenone with an academical
background on graphs. I appreciate your contribution very much.]



Am Mo, den 06.09.2004 schrieb harald kuhn um 9:36:
> Hi Jens,
>=20
> i just want to comment on some of your remarks and try to clearify some=20
> of the points you put question marks onto.
>=20
> Jens Kanschik wrote:
>=20
> >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 ;-)).
> >
Is this an offer? Could it be possible to extract the general API for
graphs from your Hypergraph Project and reuse it in panckoucke? It
sounds a bit like this. Please don't be upset, if I do not understand
you correctly.
=20
> > =20
> >
> 12. Plain access to nodes and arcs
>=20
> >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 ?
>=20
I agree. Lets add it to the model interface.

> >>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.
>=20
agreed.

> >>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.
I wonder to what other weights a weight is related to? If an arc has a
weight, does it refer to the graph as a whole, or is it just related to
the set of arcs that emerge from this node.
Is this a question, whether arcs/nodes or edges are weighted?
Do we need the notion of an edge?

Should a weight alwas run between 0 and 1 or is it common to store a
range somewhere?


> >
> >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.
I go with Harald.=20
Furthermore I would prefer to have not to much generic additions. We
already can attach any object to any part of the graph (via the
represented objects). I would vote to use signatures with clearly
assigned semantics whereever possible. My previous impression was, that
the "Gestalten" are doing their job overall satisfactorily. Is this a
false impression?=20

> 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).
>=20
> >>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
I remember that I ran into serious problems while I wrote the current
model code and tried to add support for mutablility to arcs and nodes.
Therefor I decided to leave it to the model. Actually i forget what the
problems were, but what jens wrote sounds a bit like, that changing a
graph through its members is rather uncommon.

> > =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.=20
I think this is pretty much what I meant.=20
If every node and arc is per se different, using a Set does not add
additional semantics to the model. But on the other hand the notion of
ordering gets lost. Therefor I would vote to use Lists.
=20
> Of course
> >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).
Harald explained it pretty well and I think, my original post lead into
a false direction.  We probably don't need representedObject for Models,
but the model should store all information that was provided at the time
when the model was generated.

>=20
> >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 ) .
> >
I agree with everything, expect the last half sentence. As said before,
I like signatures with clear semantics whereever possible. Therefor I
prefer adding enhancements by specialisation over adding enhancements by
providing generic mult-purpose properties.
=20

> >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.
> >
This is already implemented. There is an extension to the
Abstractor-Interface, called "InstantiableAbstractor" that have one
additional method: setModelFactory(ModelFactory).
All Abstractors that are currently part of panckoucke do implement
"InstantiableAbstractor"


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

> > =20
> >
> I can=B4t speak for christoph, but your comments at least were very usefu=
l=20
> to me.
>=20
> >Best Regards,
> >
> >Jens.
> >
> >
> > =20
> >
> Cheers,
> Harald
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dclick
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
--=20
Christoph Froehlich <cf...@fo...>