tm4j-developers — Forum for issues related to development of TM4J.

[Tm4j-developers] [ tm4j-Bugs-1027733 ] unable to open topic maps in LTM format

[SourceForge.net <no...@so...>]

Bugs item #1027733, was opened at 2004-09-14 09:17
Message generated for change (Comment added) made by c_froehlich
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1027733&group_id=27895

Category: Import/Export
Group: TMNav 0.2.8_1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Vidar Gundersen (vidarg)
Assigned to: Christoph Fröhlich (c_froehlich)
Summary: unable to open topic maps in LTM format

Initial Comment:
I have been unable to open .ltm files with tmnav.
Error and log messages are:

    Corrupt [path+basename].ltm:
    "Cannot activate TopicMapReference, because its in
    state StoreState (corrupted)"

One of the topic maps i have tried to open was the example
from an Ontopia user manual, "Jill's first topic map":
http://www.ontopia.net/omnigator/docs/navigator/userguide.html#d0e1764


----------------------------------------------------------------------

>Comment By: Christoph Fröhlich (c_froehlich)
Date: 2004-09-14 16:37

Message:
Logged In: YES 
user_id=503220

It seems to me that tm4j currently does not support the 
# (line) comments:

The first three lines of the offending map:
@"utf-8"
#TOPICMAP jills-tm
#INCLUDE "dc.ltmm"

Changing the line comments to range comments resolved the
problem:

@"utf-8"
/*TOPICMAP jills-tm */
/*INCLUDE "dc.ltmm"*/

bye
c




----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-09-14 14:33

Message:
Logged In: YES 
user_id=176992

Passed over to Cristoph :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1027733&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-973979 ] Exception when creating two topics with the same base name

[SourceForge.net <no...@so...>]

Bugs item #973979, was opened at 2004-06-16 17:08
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=973979&group_id=27895

Category: Hibernate Impl
Group: TM4J 0.9.6
Status: Open
>Resolution: Accepted
Priority: 7
Submitted By: Andy Peel (atpeel)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Exception when creating two topics with the same base name

Initial Comment:
If I create two topics with the same base name, I get
this exception:

Message:
testUpdateTopic_SameBaseName(test.client.TestTopicDelegate):
Source exception thrown:
org.tm4j.topicmap.TopicMapRuntimeException: 
Cause: java.sql.SQLException: ERROR:  syntax error at
or near "topic_types" at character 15
Cause:ERROR:  syntax error at or near "topic_types" at
character 15

The problem seems to be inside
org.tm4j.topicmap.hibernate.TopicImpl.replaceTopicReference()
where the SQL query generated includes the fragment
"update ignore". The ignore keyword only seems to work
on BDB/MySQl, whereas I'm using PostgreSQL.

----------------------------------------------------------------------

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-09-14 13:37

Message:
Logged In: YES 
user_id=176992

I have successfully replicated this problem with the early
commit. Even when unecessary session.flush() calls are
removed, a commit still occurs before any query. If you
write code like:
Topic t = tm.createTopic("topic1);
BaseName bn = tm.createName("bn1");

The row for the Topic gets committed just before the system
checks the id "bn1" is not a duplicate ID. It looks like the
Hibernate code needs to be reviewed for transaction isolation.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-09-13 16:13

Message:
Logged In: YES 
user_id=1064816

Time passes...

OK, having reopened this at our end to try and get to the
bottom of it, it seems that the test I wrote to test Kal's
fix had a bug in it...
The bug in the test has now been fixed and we can reproduce
the problem that I got before. The exception I sent Kal in a
private email was as follows:


Message:
testUpdateTopicSameBaseName(test.client.TestTopicDelegate):
Source exception thrown:
org.tm4j.topicmap.TopicMapRuntimeException: 
Cause: java.sql.SQLException: ERROR:  update or delete on
"tmobjects" violates foreign key constraint
"fkce45afe9c6f0e22b" on "topic_sips"
Cause:ERROR:  update or delete on "tmobjects" violates
foreign key constraint "fkce45afe9c6f0e22b" on "topic_sips"


We have tried running the code *without* our custom
transaction manager code, and calling
provider.openTransaction() instead. Our test then passes
fine and I can create two topics with the same base name
that are then merged inside TM4J. Our custom transaction
provider mechanism basically subclasses Hibernate's
SessionFactory and Session classes with spoof versions that
are wired into a simple transaction manager that forces the
use of a single transaction per thread (analagous to
Hibernate's Session-In-View pattern).

This is different to the way the transaction opened by
calling provider.openTransaction() works. By putting some
breakpoints into our test we found that every time we create
a topic and set its base name, the transaction's commit
method is called 4 times - you can actually see the data
being inserted into the tmobjects table as you step through
the code. This really needs to be done atomically, in a
single transaction.

Of course if you don't use a custom transaction provider and
you don't call provider.openTransaction() then TM4J creates
and commits a transaction for each operation is performs
internally.

So it looks like it's the fact that the TM4J-managed
transaction is being committed too early is preventing the
topic_sips foreign key violation from happening.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-06-22 16:59

Message:
Logged In: YES 
user_id=1064816

This works fine when I test it with stand-alone code,
although I still have problems when I run within my code base. 

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-06-18 18:28

Message:
Logged In: YES 
user_id=176992

Fixed error in the static merging code that caused this
exception. Waiting on confirmation that the fix actually
works on PostgreSQL...

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-06-17 20:13

Message:
Logged In: YES 
user_id=176992

Sorry, I misunderstood the problem. I need to take a closer
look at that SQL update. I used SQL directly for this
operation for perfomance, but my simple update statement can
violate key constraints (especially when merging on names or
subject indicators I think). I *think* that there must be a
way to do what I want without temporarily violating key
constraints.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-06-17 10:11

Message:
Logged In: YES 
user_id=1064816

Hi Kal,

I'm pretty sure that won't make a difference - the SQL query
in TopicImpl includes the IGNORE keyword, and as far as I
can make out, that only works with BDB/MySQL. I even tried
the query directly using psql, but to no avail.


Andy.

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-06-16 19:10

Message:
Logged In: YES 
user_id=176992

I wonder if this is a Hibernate problem. There was a new
Hibernate release on June 1st (2.1.4) - perhaps it is worth
giving that a spin to see if the Postgres problem got fixed ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=973979&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-955921 ] Tables aren't fully emptied after TopicMap removal

[SourceForge.net <no...@so...>]

Bugs item #955921, was opened at 2004-05-18 14:38
Message generated for change (Settings changed) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=955921&group_id=27895

Category: Hibernate Impl
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Lischke (lischke2)
>Assigned to: Kal Ahmed (kal_ahmed)
Summary: Tables aren't fully emptied after TopicMap removal

Initial Comment:
Hi,

when calling TMAPI TopicMap.remove() not all tables are
emptied in the relational Backend.

The tables "srclocs", "locators" and
"SubjectIdentityPoint" are not cleaned. Maybe that can
cause a data growth when often deleting topicmaps.

i dunno if it is only TMAPI related.

Stefan 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=955921&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-1015061 ] Wrong example for ozone provider config

[SourceForge.net <no...@so...>]

Bugs item #1015061, was opened at 2004-08-24 09:04
Message generated for change (Settings changed) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1015061&group_id=27895

Category: Documentation
Group: TM4J 0.9.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Kal Ahmed (kal_ahmed)
Summary: Wrong example for ozone provider config

Initial Comment:
kal,

in docs/devguide/ch03s05.html#config.ozone you write in
example 3.4 that the config property should be

dburl=ozone:remote://localhost:3333

according to what you write above and my experiences
here, this should be changed to 

ozonedb:remote://localhost:3333

note the "ozone_db_", or things go havoc. could be that
further down, the same applies to
dburl=ozone:local:/data/ozone/topicmaps ?

this prob showed up with the current tmnav, no other
experiences available (yet).

greets, tobi... :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1015061&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-1027733 ] unable to open topic maps in LTM format

[SourceForge.net <no...@so...>]

Bugs item #1027733, was opened at 2004-09-14 08:17
Message generated for change (Comment added) made by kal_ahmed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1027733&group_id=27895

Category: Import/Export
>Group: TMNav 0.2.8_1
Status: Open
Resolution: None
Priority: 5
Submitted By: Vidar Gundersen (vidarg)
>Assigned to: Christoph Fröhlich (c_froehlich)
Summary: unable to open topic maps in LTM format

Initial Comment:
I have been unable to open .ltm files with tmnav.
Error and log messages are:

    Corrupt [path+basename].ltm:
    "Cannot activate TopicMapReference, because its in
    state StoreState (corrupted)"

One of the topic maps i have tried to open was the example
from an Ontopia user manual, "Jill's first topic map":
http://www.ontopia.net/omnigator/docs/navigator/userguide.html#d0e1764


----------------------------------------------------------------------

>Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-09-14 13:33

Message:
Logged In: YES 
user_id=176992

Passed over to Cristoph :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1027733&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-1027733 ] unable to open topic maps in LTM format

[SourceForge.net <no...@so...>]

Bugs item #1027733, was opened at 2004-09-14 09:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1027733&group_id=27895

Category: Import/Export
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Vidar Gundersen (vidarg)
Assigned to: Nobody/Anonymous (nobody)
Summary: unable to open topic maps in LTM format

Initial Comment:
I have been unable to open .ltm files with tmnav.
Error and log messages are:

    Corrupt [path+basename].ltm:
    "Cannot activate TopicMapReference, because its in
    state StoreState (corrupted)"

One of the topic maps i have tried to open was the example
from an Ontopia user manual, "Jill's first topic map":
http://www.ontopia.net/omnigator/docs/navigator/userguide.html#d0e1764


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=1027733&group_id=27895

[Tm4j-developers] [ tm4j-Bugs-973979 ] Exception when creating two topics with the same base name

[SourceForge.net <no...@so...>]

Bugs item #973979, was opened at 2004-06-16 16:08
Message generated for change (Comment added) made by atpeel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=973979&group_id=27895

Category: Hibernate Impl
>Group: TM4J 0.9.6
>Status: Open
Resolution: Fixed
Priority: 7
Submitted By: Andy Peel (atpeel)
Assigned to: Kal Ahmed (kal_ahmed)
Summary: Exception when creating two topics with the same base name

Initial Comment:
If I create two topics with the same base name, I get
this exception:

Message:
testUpdateTopic_SameBaseName(test.client.TestTopicDelegate):
Source exception thrown:
org.tm4j.topicmap.TopicMapRuntimeException: 
Cause: java.sql.SQLException: ERROR:  syntax error at
or near "topic_types" at character 15
Cause:ERROR:  syntax error at or near "topic_types" at
character 15

The problem seems to be inside
org.tm4j.topicmap.hibernate.TopicImpl.replaceTopicReference()
where the SQL query generated includes the fragment
"update ignore". The ignore keyword only seems to work
on BDB/MySQl, whereas I'm using PostgreSQL.

----------------------------------------------------------------------

>Comment By: Andy Peel (atpeel)
Date: 2004-09-13 15:13

Message:
Logged In: YES 
user_id=1064816

Time passes...

OK, having reopened this at our end to try and get to the
bottom of it, it seems that the test I wrote to test Kal's
fix had a bug in it...
The bug in the test has now been fixed and we can reproduce
the problem that I got before. The exception I sent Kal in a
private email was as follows:


Message:
testUpdateTopicSameBaseName(test.client.TestTopicDelegate):
Source exception thrown:
org.tm4j.topicmap.TopicMapRuntimeException: 
Cause: java.sql.SQLException: ERROR:  update or delete on
"tmobjects" violates foreign key constraint
"fkce45afe9c6f0e22b" on "topic_sips"
Cause:ERROR:  update or delete on "tmobjects" violates
foreign key constraint "fkce45afe9c6f0e22b" on "topic_sips"


We have tried running the code *without* our custom
transaction manager code, and calling
provider.openTransaction() instead. Our test then passes
fine and I can create two topics with the same base name
that are then merged inside TM4J. Our custom transaction
provider mechanism basically subclasses Hibernate's
SessionFactory and Session classes with spoof versions that
are wired into a simple transaction manager that forces the
use of a single transaction per thread (analagous to
Hibernate's Session-In-View pattern).

This is different to the way the transaction opened by
calling provider.openTransaction() works. By putting some
breakpoints into our test we found that every time we create
a topic and set its base name, the transaction's commit
method is called 4 times - you can actually see the data
being inserted into the tmobjects table as you step through
the code. This really needs to be done atomically, in a
single transaction.

Of course if you don't use a custom transaction provider and
you don't call provider.openTransaction() then TM4J creates
and commits a transaction for each operation is performs
internally.

So it looks like it's the fact that the TM4J-managed
transaction is being committed too early is preventing the
topic_sips foreign key violation from happening.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-06-22 15:59

Message:
Logged In: YES 
user_id=1064816

This works fine when I test it with stand-alone code,
although I still have problems when I run within my code base. 

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-06-18 17:28

Message:
Logged In: YES 
user_id=176992

Fixed error in the static merging code that caused this
exception. Waiting on confirmation that the fix actually
works on PostgreSQL...

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-06-17 19:13

Message:
Logged In: YES 
user_id=176992

Sorry, I misunderstood the problem. I need to take a closer
look at that SQL update. I used SQL directly for this
operation for perfomance, but my simple update statement can
violate key constraints (especially when merging on names or
subject indicators I think). I *think* that there must be a
way to do what I want without temporarily violating key
constraints.

----------------------------------------------------------------------

Comment By: Andy Peel (atpeel)
Date: 2004-06-17 09:11

Message:
Logged In: YES 
user_id=1064816

Hi Kal,

I'm pretty sure that won't make a difference - the SQL query
in TopicImpl includes the IGNORE keyword, and as far as I
can make out, that only works with BDB/MySQL. I even tried
the query directly using psql, but to no avail.


Andy.

----------------------------------------------------------------------

Comment By: Kal Ahmed (kal_ahmed)
Date: 2004-06-16 18:10

Message:
Logged In: YES 
user_id=176992

I wonder if this is a Hibernate problem. There was a new
Hibernate release on June 1st (2.1.4) - perhaps it is worth
giving that a spin to see if the Postgres problem got fixed ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=391879&aid=973979&group_id=27895

[Tm4j-developers] RE: [TM4J-users] slow tm export

[Kal A. <ka...@te...>]

Hi Conal,

I'm going to have to take a look at this in more detail - it may be that
it will be possible to create a lower-level exporter specifically for
the Hibernate backend that doesn't have this performance problem.

In the meantime, I can only suggest that you take a look through
Hibernate's documentation and that of your database to see if there are
any runtime configuration options that might help improve performance.

Cheers,

Kal

On Sun, 2004-09-12 at 23:54, Conal Tuohy wrote:
> Thanks Kal!
> 
> I opened a transaction before walking my topic map, but sadly it hasn't speeded it up at all :-(
> 
> Here's the code I used:
> 
> 	/* get the topic map from the topic map manager */
> 	var TopicMapManager = cocoon.getComponent("org.tm4j.tm4web.cocoon.TopicMapManagerComponent");
> 	var map = TopicMapManager.getTopicMap("nzetc");
> 	cocoon.releaseComponent(TopicMapManager);
> 
> 	/* write the topic map to a file */
> 	var walker = new Packages.org.tm4j.topicmap.utils.TopicMapWalker();
> 	var writer = new Packages.org.tm4j.topicmap.utils.XTMWriter();
> 	var file = new java.io.File(export_filename);
> 	var os = new java.io.FileOutputStream(file);
> 	var of = new Packages.org.apache.xml.serialize.OutputFormat();
> 	of.setEncoding("UTF-8");
> 	of.setIndenting(true);
> 	of.setIndent(2);
> 	var serializer = new Packages.org.apache.xml.serialize.XMLSerializer(os, of);
> 	walker.setHandler(writer);
> 	writer.setContentHandler(serializer);
> 	
> 	var txn = map.getProvider().openTransaction();
> 	try {
> 	  walker.walk(map);
> 	} finally {
> 	  txn.abort();
> 	}
> 	
> 	/* walker.walk(map); */
> 	cocoon.sendPage("export/nzetc.xtm");
> 
> Cheers
> 
> Con
> 
> > My guess is that the walk is just doing to many transactions. If you
> > don't have an "outer" transaction wrapping that walk, then 
> > each call to
> > the API will result in a separate transaction against the database -
> > which amounts to quite a lot of transactions to walk the whole map.
> > 
> > What I would recommend you try is creating a transaction to 
> > wrap around
> > the walk. If a transaction is already in progress, then the TM4J
> > Hibernate code will use that txn instead of creating one.
> > 
> > The code would be something like this:
> > 
> > ProviderTransaction txn = provider.getTransaction();
> > try {
> >   walker.walk();
> > } finally {
> >   txn.abort();
> > }
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM. 
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Tm4j-users mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-users
-- 
Kal Ahmed <ka...@te...>
techquila

Re: [Tm4j-developers] Tm4j-cvs-checkout fails to compile

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

Ah. My problem. I just reported what eclipse shows me, without running
ant.

Thanks 
c


Am Mo, den 13.09.2004 schrieb Kal Ahmed um 0:02:
> The lexer and parser are generated by ANTLR - check to see if I
> commented out the command to generate those files in build.xml
> 
> Cheers
> 
> Kal
> 
> On Sat, 2004-09-11 at 20:01, Christoph Froehlich wrote:
> > Hi kal
> > 
> > I did a cvs-checkout of tm4j. I fails to compile, because
> > 
> >    org.tm4j.tologx.memory.QueryEvaluatorImpl 
> >   (and two or three other classes)
> > 
> > tries to import the following missing classes:
> > 
> >   org.tm4j.tologx.parser.TologLexer;
> >   org.tm4j.tologx.parser.TologParser;
> > 
> > 
> > Is it possible that you forgot to check them in?
> > 
> > Bye
> > c
-- 
Christoph Froehlich <cf...@fo...>

Re: [Tm4j-developers] Tm4j-cvs-checkout fails to compile

[Kal A. <ka...@te...>]

The lexer and parser are generated by ANTLR - check to see if I
commented out the command to generate those files in build.xml

Cheers

Kal

On Sat, 2004-09-11 at 20:01, Christoph Froehlich wrote:
> Hi kal
> 
> I did a cvs-checkout of tm4j. I fails to compile, because
> 
>    org.tm4j.tologx.memory.QueryEvaluatorImpl 
>   (and two or three other classes)
> 
> tries to import the following missing classes:
> 
>   org.tm4j.tologx.parser.TologLexer;
>   org.tm4j.tologx.parser.TologParser;
> 
> 
> Is it possible that you forgot to check them in?
> 
> Bye
> c
-- 
Kal Ahmed <ka...@te...>
techquila

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

Re: [Tm4j-developers] Website update (well, sort of)

[Kal A. <ka...@te...>]

Hi Cristoph

On Sat, 2004-09-11 at 19:57, Christoph Froehlich wrote:
> Hi kal,
> 
> this is really promising, especially the integration of the two very
> different sources, api-docs and prose-documentation. Congratulations.
> 
Thanks!

> I looked in tm4j-cvs to find resources about how you are creating the
> topicmap (topicmaps?) that the tm4j-site is built from, but the only
> thing I found was tm4j/resources/topicmaps/sitemap/ where you seem to
> store the 'ontologies'.

I still need to check some things into CVS. The docbook source was
transformed by an XSLT stylesheet which I *think* is checked in to CVS -
look in resources and under the docbook directory there should be an xtm
subdirectory - that has the stylesheet in it.

The API documentation is, of course, generated with the TopicMapDoclet
that is part of TM4J.

The other "structural" stuff that describes the main site navigation and
the release versions of the different packages are all contained in the
CVS module named website.

The site is then generated using TM4Web/Velocity - the templates are all
part of the website module too.

I'll tidy up what I've been using and check stuff into CVS tomorrow or
the day after - I'll post another message when I think I have got
everything checked in.

Cheers,

Kal

-- 
Kal Ahmed <ka...@te...>
techquila

[Tm4j-developers] Tm4j-cvs-checkout fails to compile

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

Hi kal

I did a cvs-checkout of tm4j. I fails to compile, because

   org.tm4j.tologx.memory.QueryEvaluatorImpl 
  (and two or three other classes)

tries to import the following missing classes:

  org.tm4j.tologx.parser.TologLexer;
  org.tm4j.tologx.parser.TologParser;


Is it possible that you forgot to check them in?

Bye
c



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

Re: [Tm4j-developers] Website update (well, sort of)

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

Hi kal,

this is really promising, especially the integration of the two very
different sources, api-docs and prose-documentation. Congratulations.

I looked in tm4j-cvs to find resources about how you are creating the
topicmap (topicmaps?) that the tm4j-site is built from, but the only
thing I found was tm4j/resources/topicmaps/sitemap/ where you seem to
store the 'ontologies'.
 
Are your scripts (I assume there are some scripts) that create the
topicmaps available anywhere on tm4j-cvs? I'm asking because I would
like to add some info concerning tmnav and panckoucke and I'm looking
for a good point to start.

Bye
c




 
Am Fr, den 10.09.2004 schrieb Kal Ahmed um 22:28:
> Hi all,
> 
> I've been updating the TopicMapDoclet code a bit to try and get a useful
> approximation of the standard Javadoc out of it. What I have so far I
> have integrated into the website build and uploaded. If you go to
> http://www.tm4j.org/tm4j-engine.html or
> http://www.tm4j.org/x1k1pbb6tr-0.html (hmmm, that needs to be changed
> really... :), you will see that the topics for those pages are now
> associated with topics for the packages that the application provides
> (listed under the header "Contains" in the right-hand bar). Clicking on
> one of those takes you into the Javadoc-alike topic map stuff. 
> 
> What makes this quite fun is that there is tight integration with the
> documentation (see http://www.tm4j.org/dg-N1050D.html - scroll down or
> use the left-hand menu to see the related resources) thanks to the topic
> map generated from the Developer's Guide docbook source. Also because
> the topic maps from the separate projects get merged together, where a
> method in Panckoucke uses a class from TM4J, the Javadoc-alike pages are
> actually linked together (unlike when you have the standard javadoc
> documentation that can only link together all the classes processed in a
> single run).
> 
> There is still a bit of work to be done in tidying up and I think that
> some features of standard Javadoc are still missing, but any thoughts
> and comments or suggestions for the layout would be appreciated.
> 
> I also want to get a whole bunch of FAQs together and topic map them to
> integrate them with the site and class documentation. So any suggestions
> for questions (and answers) would also be welcome.
> 
> I'll be checking in the changes and the TM4Web/Velocity templates that
> made all this happen over the weekend. But right now I need some more
> coffee ;-)
> 
> Cheers,
> 
> Kal 
-- 
Christoph Froehlich <cf...@fo...>

[Tm4j-developers] Future of Panckoucke

[Harald K. <har...@we...>]

Hi All,

As panckoucke evolves, I see that it could be interesting not only for TopicMapVisualisation but also for the Visualistation of other Data. I think that this is something nobody objects against.

However, as a generic Visualisation Project would not fit within the scope of the TM4J Project, I suggest moving panckoucke into its own Project on SF.net. I would like to suggest splitting the panckoucke development into two branches. The first one will clean the existing code and add certain functionality (like basic support for editing and basic support for generic data abstraction) without breaking compatibility with panckouck 0.3.1 (at least not in a major way) This will be called panckoucke 0.4 (PK 0.4) 

In Parallel inside a new founded panckoucke Project on sf.net, development for the new panckoucke will start. This (well the first release) will be called 
panckoucke 0.5 (PK 0.5), Its goals are to create a new Model API, make panckoucke a generic Data Visualisation Framework (without loosing the strong connection to TopicMap Visualisation) and in the end, port the PK 0.4 stuff into PK 0.5. 

TMNav as the Reference implementation should definitly stay inside the TM4J Project.

As this means a lot of work which can be made parallel, I would also like to suggest that two different persons take resposibility for the different branches. I would personally volunteer to take over
resposibilty (and probably most of the work) for PK 0.4. I also think that Christoph should be responsible for PK 0.5. Other people like Niko, George and his team as well as Jens and Stefan or anybody else interested would be more than welcome to contribute.

The reasons for doing this parallel work are:
- both branches could be developed independantly, so the clean up and refactoring could be done without having to wait for the new Model API
- i also think, that this would speed up development, as the features and changes introduced in PK 0.4 could be tested and applied in tmnav without the need for the new model api to be in place
- i think that the major argument against moving the whole codebase at once is that, if we move panckoucke into a new Project, then why "pollute" the new CVS with packages that will be changed soon anyway (new model api, possibly new package structure)

Cheers,
Harald

_________________________________________________________
Mit WEB.DE FreePhone? mit hochster Qualitat ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201

[Tm4j-developers] Website update (well, sort of)

[Kal A. <ka...@te...>]

Hi all,

I've been updating the TopicMapDoclet code a bit to try and get a useful
approximation of the standard Javadoc out of it. What I have so far I
have integrated into the website build and uploaded. If you go to
http://www.tm4j.org/tm4j-engine.html or
http://www.tm4j.org/x1k1pbb6tr-0.html (hmmm, that needs to be changed
really... :), you will see that the topics for those pages are now
associated with topics for the packages that the application provides
(listed under the header "Contains" in the right-hand bar). Clicking on
one of those takes you into the Javadoc-alike topic map stuff. 

What makes this quite fun is that there is tight integration with the
documentation (see http://www.tm4j.org/dg-N1050D.html - scroll down or
use the left-hand menu to see the related resources) thanks to the topic
map generated from the Developer's Guide docbook source. Also because
the topic maps from the separate projects get merged together, where a
method in Panckoucke uses a class from TM4J, the Javadoc-alike pages are
actually linked together (unlike when you have the standard javadoc
documentation that can only link together all the classes processed in a
single run).

There is still a bit of work to be done in tidying up and I think that
some features of standard Javadoc are still missing, but any thoughts
and comments or suggestions for the layout would be appreciated.

I also want to get a whole bunch of FAQs together and topic map them to
integrate them with the site and class documentation. So any suggestions
for questions (and answers) would also be welcome.

I'll be checking in the changes and the TM4Web/Velocity templates that
made all this happen over the weekend. But right now I need some more
coffee ;-)

Cheers,

Kal 
-- 
Kal Ahmed <ka...@te...>
techquila

Re: [Tm4j-developers] ID Generators

[Kal A. <ka...@te...>]

Hi Pete,

Thanks for the pointers. If you can send me your patch I'll apply it,
but I'll also look through the source later on and see if there are some
places where unecessary calls to newIDGenerator() can be removed.

Cheers,

Kal
On Thu, 2004-09-09 at 13:55, Pete Lewin-Harris wrote:
> Kal,
> 
>  I haven't gone into any detail about where all the calls are, but a grep
> for newIDGenerator returns 21 matches across the codebase.
> 
> The most nefarious of these is in the instantiation of the
> org.tm4j.topicmap.hibernate.TopicMapFactoryImpl class, which is called every
> time the topic map is retrieved via the tmapi getTopicMap() method. This is
> the one that is causing most problems for me, but I'm sure there are
> others...
> 
> If you like, I can mail you the updated IDGeneratorFactory and
> IDGeneratorImpl classes which can just be plugged in and seem to work fine.
> 
> cheers, Pete
> 
> ----- Original Message ----- 
> From: "Kal Ahmed" <ka...@te...>
> To: "Pete Lewin-Harris" <pe...@il...>
> Cc: <tm4...@li...>
> Sent: Thursday, September 09, 2004 1:03 PM
> Subject: Re: [Tm4j-developers] ID Generators
> 
> 
> > Hi Pete,
> >
> > The newIDGenerator() method should not be getting called that often. In
> > fact, it should really only get called once per application session (so
> > your proposal of storing a single IDGenerator instance makes a lot of
> > sense).
> >
> > I guess I can just grep the code for where newIDGenerator() is getting
> > invoked - but if you have any pointers to the offending callers, that
> > would be handy!
> >
> > Cheers,
> >
> > Kal
> >
> > On Thu, 2004-09-09 at 10:15, Pete Lewin-Harris wrote:
> > > Hi,
> > >
> > > I have discovered a bit of weird behaviour in the id generator factory
> and
> > > was wondering what the reasoning behind may be. Whenever the
> > > IDGeneratorFactory.newIDGenerator() method is called, a completely new
> > > IDGeneratorImpl object is constructed, which involes a Thread.sleep(100)
> > > call being made.In my performance tests, this means that approximately
> 50%
> > > of the time spend in TM4J is spent sleeping which really can't be good!
> > >
> > > I have rewritten the IDGeneratorFactory and IDGeneratorImpl classes so
> the
> > > Factory stores a singleton IDGenerator object and the Generator returns
> a
> > > random 32 character string (and the getID() method is synchronized).
> This
> > > results in a massive performance benefit and seems to have no impact on
> > > anything else.
> > >
> > > Anyone got any  reasons why this is a bad idea? I haven't run the junit
> > > tests so I may have missed something vital...
> > >
> > > cheers, Pete
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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_id=5047&alloc_id=10808&op=click
> > > _______________________________________________
> > > Tm4j-developers mailing list
> > > Tm4...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tm4j-developers
> > -- 
> > Kal Ahmed <ka...@te...>
> > techquila
> >
> >
> >
> > -------------------------------------------------------
> > 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_id=5047&alloc_id=10808&op=click
> > _______________________________________________
> > Tm4j-developers mailing list
> > Tm4...@li...
> > https://lists.sourceforge.net/lists/listinfo/tm4j-developers
> >
> >
-- 
Kal Ahmed <ka...@te...>
techquila

Re: [Tm4j-developers] ID Generators

[Pete Lewin-H. <pe...@il...>]

Kal,

 I haven't gone into any detail about where all the calls are, but a grep
for newIDGenerator returns 21 matches across the codebase.

The most nefarious of these is in the instantiation of the
org.tm4j.topicmap.hibernate.TopicMapFactoryImpl class, which is called every
time the topic map is retrieved via the tmapi getTopicMap() method. This is
the one that is causing most problems for me, but I'm sure there are
others...

If you like, I can mail you the updated IDGeneratorFactory and
IDGeneratorImpl classes which can just be plugged in and seem to work fine.

cheers, Pete

----- Original Message ----- 
From: "Kal Ahmed" <ka...@te...>
To: "Pete Lewin-Harris" <pe...@il...>
Cc: <tm4...@li...>
Sent: Thursday, September 09, 2004 1:03 PM
Subject: Re: [Tm4j-developers] ID Generators


> Hi Pete,
>
> The newIDGenerator() method should not be getting called that often. In
> fact, it should really only get called once per application session (so
> your proposal of storing a single IDGenerator instance makes a lot of
> sense).
>
> I guess I can just grep the code for where newIDGenerator() is getting
> invoked - but if you have any pointers to the offending callers, that
> would be handy!
>
> Cheers,
>
> Kal
>
> On Thu, 2004-09-09 at 10:15, Pete Lewin-Harris wrote:
> > Hi,
> >
> > I have discovered a bit of weird behaviour in the id generator factory
and
> > was wondering what the reasoning behind may be. Whenever the
> > IDGeneratorFactory.newIDGenerator() method is called, a completely new
> > IDGeneratorImpl object is constructed, which involes a Thread.sleep(100)
> > call being made.In my performance tests, this means that approximately
50%
> > of the time spend in TM4J is spent sleeping which really can't be good!
> >
> > I have rewritten the IDGeneratorFactory and IDGeneratorImpl classes so
the
> > Factory stores a singleton IDGenerator object and the Generator returns
a
> > random 32 character string (and the getID() method is synchronized).
This
> > results in a massive performance benefit and seems to have no impact on
> > anything else.
> >
> > Anyone got any  reasons why this is a bad idea? I haven't run the junit
> > tests so I may have missed something vital...
> >
> > cheers, Pete
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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_id=5047&alloc_id=10808&op=click
> > _______________________________________________
> > Tm4j-developers mailing list
> > Tm4...@li...
> > https://lists.sourceforge.net/lists/listinfo/tm4j-developers
> -- 
> Kal Ahmed <ka...@te...>
> techquila
>
>
>
> -------------------------------------------------------
> 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_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
>
>

Re: [Tm4j-developers] ID Generators

[Kal A. <ka...@te...>]

Hi Pete,

The newIDGenerator() method should not be getting called that often. In
fact, it should really only get called once per application session (so
your proposal of storing a single IDGenerator instance makes a lot of
sense).

I guess I can just grep the code for where newIDGenerator() is getting
invoked - but if you have any pointers to the offending callers, that
would be handy!

Cheers,

Kal

On Thu, 2004-09-09 at 10:15, Pete Lewin-Harris wrote:
> Hi,
> 
> I have discovered a bit of weird behaviour in the id generator factory and
> was wondering what the reasoning behind may be. Whenever the
> IDGeneratorFactory.newIDGenerator() method is called, a completely new
> IDGeneratorImpl object is constructed, which involes a Thread.sleep(100)
> call being made.In my performance tests, this means that approximately 50%
> of the time spend in TM4J is spent sleeping which really can't be good!
> 
> I have rewritten the IDGeneratorFactory and IDGeneratorImpl classes so the
> Factory stores a singleton IDGenerator object and the Generator returns a
> random 32 character string (and the getID() method is synchronized). This
> results in a massive performance benefit and seems to have no impact on
> anything else.
> 
> Anyone got any  reasons why this is a bad idea? I haven't run the junit
> tests so I may have missed something vital...
> 
> cheers, Pete
> 
> 
> 
> 
> -------------------------------------------------------
> 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_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
-- 
Kal Ahmed <ka...@te...>
techquila

[Tm4j-developers] ID Generators

[Pete Lewin-H. <pe...@il...>]

Hi,

I have discovered a bit of weird behaviour in the id generator factory and
was wondering what the reasoning behind may be. Whenever the
IDGeneratorFactory.newIDGenerator() method is called, a completely new
IDGeneratorImpl object is constructed, which involes a Thread.sleep(100)
call being made.In my performance tests, this means that approximately 50%
of the time spend in TM4J is spent sleeping which really can't be good!

I have rewritten the IDGeneratorFactory and IDGeneratorImpl classes so the
Factory stores a singleton IDGenerator object and the Generator returns a
random 32 character string (and the getID() method is synchronized). This
results in a massive performance benefit and seems to have no impact on
anything else.

Anyone got any  reasons why this is a bad idea? I haven't run the junit
tests so I may have missed something vital...

cheers, Pete

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

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

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

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

Re: [Tm4j-developers] database deadlocks

[Pete Lewin-H. <pe...@il...>]

Kal,

I made the changes to the schema generated by Hibernate so I do agree with
you that the way forward isn't clear.

The problem is fundamentally to do with postgres and the way it locks for
update all foreign keys. However in our base product we (seem to?) have
solved this problem by always creating the foreign keys in the same order
with in the database creation script and by avoiding as much as possible
tables that have foreign keys back onto themselves.

In the same way I have taken the tm4j generated hibernate schema and changed
the order in which the constraints are defined as well as removing the
foreign key from the topicMap column on tmobjects. This has stopped the any
deadlocks appearing. I realise that removing foreign keys  indiscriminately
is not the answer but for the moment I can't come up with anything better.

To be honest this is really more of an FYI post than an explicit issue.
Maybe something to keep in mind if you are bored on a wet Wednesday
afternoon and decide to re-acrchitect the entire schema ;-)

cheers, Pete


----- Original Message ----- 
From: "Kal Ahmed" <ka...@te...>
To: "Pete Lewin-Harris" <pe...@il...>
Cc: <tm4...@li...>
Sent: Wednesday, August 18, 2004 9:28 AM
Subject: Re: [Tm4j-developers] database deadlocks


> Hi Pete,
>
> Did you make these changes to the schema generated by Hibernate or did
> you change the Hibernate mapping files ? If you did the latter, would it
> be possible to get a copy of your changes ? If you had to hack the
> schema generated by Hibernate then I'm a little less clear on the best
> way to proceed - on the one hand this is an issue we should try to
> address, but on the other hand I don't want to have to create and
> maintain a set of schemas for different databases (that was one of the
> reasons for using Hibernate in the first place!) - perhaps it could be
> reported as an issue to the Hibernate folks though ?
>
> Cheers,
>
> Kal

>