Re: [Tm4j-developers] Graph presentation

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

This is probably drifting off topic, but as no one is complaining yet, my 
comments are below:

At 07:21 28/02/2002 -0800, Jack Park wrote:
>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.

Looking at the GXL DTD, I would venture as far as to say that a graph API 
need do no more than realize the data model of GXL. Adding the relation 
(<rel> in GXL or hyperedge in graph-land) could probably be used to enable 
an easier mapping of a more complex structure such as a constrained topic 
map (i.e a topic map with attendant schema) into the hypergraph structure. 
I think that a naive version of a GXL-based API would be relatively trivial 
to implement. There is already an implementation of a more complete graph 
database - GRAS 
(http://www-i3.informatik.rwth-aachen.de/research/projects/gras/index.html) 
- but this appears to be done in C, and so would either require 
reimplementing or wrapping with JNI.


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

I would see the architecture with a graph database as being something like 
this (fixed pitch font required for the next bit)

+------+---------+
| TM4J | RDF API |
+------+---------+
|   GRAPH API    |
+-------+--------+
| RDBMS | OODBMS |
+-------+--------+

I'm not sure where Nexist would necessarily fit in to this, would it be 
above the high-level bindings (TM4J, RDF API, CG API etc) or next to them ?

Cheers,

Kal