tm4j-developers

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

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

Hi

over the last weeks I had some conversations off-list concerning the
next version of panckoucke.
I collected the proposals and summarize them here. 

Every contribution - more proposals or comments on the existing ones -
is very appreciated.



Backward compatibility
-------------------------
Some of the proposals will have the effect, that the next version
wouldn't be backwards compatible with the current version 0.3
Is this is an important issue, taken the current spreading of panckoucke
into account? 



Proposals for the Abstractor-Interface
---------------------------------------------
1. Changes to the interface "Abstractor"
The signature of the two specified methods (generateModel(...) and
supportsAbstraction(...)) restricts the use of the Abstractors to
process *one* *TopicMapObject*. We would like to extend this to process
objects other than TopicMapObjects.
There are currently two proposals: 
a. Replacing the first parameter of type TopicMapObject with a parameter
of type Object. 
b. Changing the signature to generateModel(AbstractionTask).
AbstractionTask could be a new empty interface. Every Abstractor would
expect a distinct implementation of AbstractionTask. An implementation
will encapsulate all information necessary to perform the abstraction
process. A benefit of not-so-generic implementations of AbstractionTask
would be, that they clearly indicate the options suitable to this task.
This would be much more readable than the current practice where String
constants are passed via the hints-property of the AbstractionContext.


Proposals for the AbstractModel-API
---------------------------------------------
2. 
Using Lists instead of Sets
The collection of arcs, endnodes and represented objects should be
changed to use Lists rather than Sets.

Concerning the collections of arcs and endnodes, the matter is rather
clear, since the identity of a Node or an Arc in the AModel is not
defined. And apparently there was no need for it during the last two
years. Therefor using a Set does not add any meaning. Furthermore it
seems, that identity of nodes and arcs of a graph relies heavily on
their ordering position.
Concerning the collection of represented objects, it is not really
comprehensible why it should be illegal for an AMMember to represent a
collection of objects that contains duplicates.

While the significance of this proposal seems really clear, we have to
keep in mind, that it has the potential to break nearly every existing
panckoucke-client.


3. 
Weights
(This was already mentioned in some other threads on the list.)
The goal is to express some sort of 'scoring' for arcs and nodes.
It is not clear, if this feature should go to the core of the
abstraction model or would better be left to a specialisation of it
(WeightedModel extends AModel). Furthermore the details of its
implementation are unclear, but it is expectable that implementations of
weighted graph exists where we can learn about them.


4. 
Support for large topicmaps.
The next version of the abstract model should be implemented less naive
regarding the existance of larger topicmaps
Two issues:
a. Optimize the implementation in terms of memory usage (very important)
and speed (important, but less than memory)
b. Adding mechanics that restrict large lists (of nodes or arcs) to a
customisable number of items. The last (and eventually) the first item
of theese list would be an Arc or Node of special Gestalt. They would
hold a represented object that contains information about the current
and the next batch of items as well as information about the generation
of the model as a whole. 


5. 
Represented objects for models
The model itself should be able to represent objects.


6. 
Abstractor and Context in model.
The model may contain all information that were relevant to generate it.
This includes the Abstractor being used and all information that was
passed to generateModel(...)


7. 
Make the AMMember itself mutable.
Adding methods like addEndnode(AMNode) to AMNode/AMArc itself and
therefor get rid of the restriction that changing the graph is always
done through the model-interface. This would lead to much more readable
code.


8. 
Subgraphs.
Abstractors should be able to return several graphs. Therefor 
AModel could be enabled to hold several graphs, instead of only one.
Another approach would be to introduce a 'ModelGroup'. The ModelGroup
could be the return value of the generateModel(...) method??


9. 
Make the graph editable.
A use case: An application changes a given model, adds/removes/changes
Nodes and Arcs and pass the model back to some code (Harald calls this a
Concretizer) that is able to detect the changes and realizes them in the
source of the model, typically a topicmap. What additional properties
does a model need to support this idea? Something like a changeTracker,
that records additions, removals, updates? 


10. 
Make the model accessible through any of its member
A method getModel() in AMMember. Is this necessary? In consideration of
memory usage?


11. 
Add inheritance to the Gestalten.
This would enable us, as an example, to define a custom Gestalt
'Airport' as a specilisation of Gestalt 'Topic'. 
Code that processes the model and does know nothing about Airports could
therby fall back to rules for processing Topics.


12. 
Plain access to nodes and arcs
Add iterators to the model that let you iterate over all nodes and all
arcs contained in the model.
On the other hand this may also be done by an utility-method:
getNodeIterator(AModel)?? 



bye
c
-- 
Christoph Froehlich <cf...@fo...>

[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.

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

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...>

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

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

Hi,

Using hypergraph.graphapi in Panckoucke :
Since Hypergraph is open source, anyone is free to use the packages
hypergraph.graphapi (an api similar to TMAPI) and hypergraph.graph (the
actual implementation), so it can be used in Panckoucke as well. But that's
something you have to decide.

Bearing in mind that Panckoucke might get a more general visualisation
project, it might be a good idea to develop a generic graph api as a
subproject and an implementation that could be used by Panckoucke and
Hypergraph and maybe also other projects. This of course means that such an
api (resp. implementation) must be quite flexible, resource saving and fast.
One could than build abstractors that could abstract from a TM structure but
also from a database organisation (tables = nodes, relations = edges or so)
etc.

When I thought about hypergraph.graphapi, one of the most difficult issues
was to decide where to store information like color etc. I didn't want to
store it at the node itself, because for me the node really represented the
abstract notion of a node.. So I decided to create an AttributeManager
(probably similar to your "Gestalten"). This AttributeManger can attach any
object to any part of the graph, e.g. :

   public static final String NODE_FOREGROUND = "nodecolour";
   public static final String NODE_BACKROUND = "nodecolour_back";
...
  AttributeManager attrMgr =  graph.getAttributeManager();
  attrMgr.setAttribute(NODE_FOREGROUND, someNode, Color.green);
  attrMgr.setAttribute(NODE_BACKGROUND, someNode, Color.red);

This attaches the object "Color.green" to the node "someNode" and the first
parameter is the name of the attribute to allow more than one. Of course,
the third parameter could be anything, also a TMObject.

An interesting feature of the AttributeManager is that it uses a hierarchy
of three levels :
1. The whole graph:
    attrMgr.setAttribute(NODE_FOREGROUND, graph, Color.white); sets the
attribute NODE_FOREGROUND to white or all nodes and edges, unless it's
overwritten.
2. Groups of nodes or edges. Any element of a graph can belong to at most
one group (for example all edges that represent an instanceOf relationship).
One can attach an attribute to a group as a single default for all elements
belonging to a group.
3. Single nodes and edges.

So, you could set an attribute to a default value for the whole graph, but
also for groups. You are also not restricted to special objects, you could
use Color, Integer (for line width), float[] for the line stroke (dashed
etc) or also Double to attach a weight to an egde.

At the moment I don't know the Gestalt design in detail, so I'm not able to
compare both ways to add visualisation information to the graph, maybe I'll
do this in the next days.

By the way, I think information visualisation is a very interesting topic,
so I would like to work on the Panckoucke project. This project sounds good.

Regards,

Jens.