Re: [Tm4j-developers] Graph presentation

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

At 09:22 27/02/2002 -0800, Jack Park wrote:
>It may be that this group is familiar with 
>http://touchgraph.sourceforge.net. (Apache)

I have had a brief discussion with Alex Shapiro (developer of Touchgraph) 
about using it as a visualisation for a topic map in TM4J. Since that 
discussion I kind of got bogged down in 0.6.0 release stuff. But now that 
the TMNav application is back on the cards I will resume experimenting with it.

>Another one I just discovered (though others may be familiar with it) is 
>http://jgraph.sourceforge.net (LGPL)

>An interesting point about jGraph is that it exports to GXL (Graph 
>Exchange Language) http://www.gupro.de/GXL/

I hadn't realised that...interesting!

>Which brings to mind an interesting set of issues.
>
>For instance: the world seems to be awash in ontology expression 
>languages, like DAML+OIL, OWL (just getting started), CG, RDF, XTM, and so 
>forth (assuming you'll allow me to group XTM into that cluster).
>
>One wonders if the persistence layer of any knowledge product ought not to 
>consist of something a bit more "universal" (whatever that means) than 
>XTM.  GXL comes to mind, and Murray Altheim seems to be heading in that 
>direction. It may be that the GooseWorks package is going in that 
>direction as well, but I'm not sure yet.
>
>This would imply that the next generation of TM4J could be a 
>wrapper/mapper for a GXL backside.  From the same backside, we could 
>wrap/map to Conceptual Graphs, DAML+OIL, OWL, and who knows what else.

That sounds like an interesting approach - in a way it is somewhat similar 
to what the DOM backend is intending to do - take some standard 
representation form with a standard API (in this case XTM in the DOM) and 
add the necessary processing layer to expose that as a topic map with TM4J 
APIs to it. I have toyed with the idea of a generic node-arc back-end for 
TM4J, but have decided recently to focus more on building up the front-end 
(with client apps, web-app frameworks, higher-level utilities, query 
languages and so on).

>Your thoughts on the notion of going in the direction of a universal, 
>graph-theoretic backside with wrapper/mappers?

I think that there shouldn't be anything in the current TM4J back-end 
architecture that should prevent this from happening and I also think that 
it could be a very interesting thing to do. If it turns out that something 
in the way TM4J's backend architecture works prevents this from being 
possible then we should change that. To be honest, right now my focus is 
not on creating new backends, but I would certainly support anyone who 
wants to give it a go!

Cheers,

Kal