Re: [Tm4j-developers] Graph presentation

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

At 10:20 28/02/2002 +0000, Murray Altheim wrote:
>Kal Ahmed wrote:
>
>>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.
>
>
>I have a preliminary XTM-to-TouchGraph converter working, though it is
>missing a good deal of the topic map (such as occurrences and any sort
>of interactive features). As a display tool for topics, associations,
>and *some* of the scopes it works passably. But for now I won't be
>spending so much time on it as my Ph.D duties are calling louder. But
>perhaps working together on a Java API for XTM-in-TG I'd be happy to
>lend a hand.

That sounds cool. I think that there are two independent things which we 
could collaborate on here - one is a common visualisation for XTM in TG 
(e.g. what should be displayed as TG nodes and what should be TG arcs, 
conventions on the use of colour, shapes and labels) such that two 
different apps displaying XTM in TG could do so in a consistent manner. The 
second would be a generic topic map viewer using TG (possibly built on top 
of TMAPI). The third thing might be if I can just pick your brains if I get 
stuck on the TG coding... ;-)


>>>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).
>
>
>I had a minor competition with Peter Becker last fall in developing an
>XML serialization of CGs, but have somewhat abandoned that after John
>Sowa took all of the development efforts back into the ANSI committee.

That is a shame - it would be good to have some XML vocabulary for a well 
researched formalism such as CG.

>I instead decided to look at how GXL could be used for this purpose,
>and that's when the light bulb went off -- it was an obvious choice for
>a common syntax. I've also written a TG-to-GXL converter in the process,
>then realized I wanted a more generalized approach.

An XML graph vocabulary is the obvious lowest-common-denominator 
representation for TMs, CGs, RDF et al. I haven't (yet) looked deeply into 
GXL - I have skimmed over some of the pages from Jacks's reference. My 
feeling is that GXL as a vocabulary is interesting though as you point out 
somewhat limiting for use by humans because of its verbosity. In using it 
as a lingua-franca for different represntational forms, you will 
undoubtedly run into semantic problems. However, having said all that, the 
nice simple graph model that GXL encodes would be an interesting basis for 
a "node engine" that handles multiple higher-level representations of which 
TM4J could be one.


>>>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!
>
>
>A little healthy competition is a good thing I think, especially
>among friends. I'm hoping over the next few months to hitch up my
>TG toolkit to my Xindice DB so that Very Large Graphs (>100K nodes)
>can be displayed via locality (ie., n nodes from a selected node).

V. Cool !

>I once for an experiment tried opening one of my ITIS topic maps
>and it took my machine down. Well, not completely, but you get the
>picture.

I do - I tried to create a VLTM from the RPMFind RDF dump and had a similar 
experience with TM4J :-( at some point I need to free up enough disk space 
to regenerate the TM and retest with the Ozone backend.

Cheers,

Kal