Re: [Tm4j-developers] Graph presentation

[Jack P. <jac...@th...>]

Comments below...
Cheers,
Jack
At 09:00 AM 2/28/2002 +0000, 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.
>
>>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).

Very smart!  Very important thing to be doing.


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

What's really interesting about this offer is that the other forum you are 
running, Tmapi-discuss, is that what is suggested would be a forum called, 
say, graphapi-discuss, in which the api for a generic graph backend is 
constructed.  What falls out of that are front sides for xtm, daml/oil, 
owl, cg, and who knows what else.  My thinking has been going along the 
lines of a generic nodes and arcs layout.  Then, the Xindice and Ozone 
designs resolve to two simple classes (I think), and the rdbms schema is 
two tables.  Doing the mapping, however, does not seem trivial.

If that becomes a reality, then it makes sense to me to map Nexist over to 
TM4J sooner rather than later.

>Cheers,
>
>Kal