[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

Towards a Graph API was Re: [ba-ohs-talk] New backlink metadata; mhpurple v0.2 released


Murray Altheim is making a compelling argument in favor of Graph Exchange 
Language GXL which I just made reference to at graphs.memes.net: 
http://graphs.memes.net/index.php3?request=displaypage&NodeID=17    (01)

GXL is at http://www.gupro.de/GXL/    (02)

The LGPL graph editor JGraph http://jgraph.sourceforge.net exports to 
GXL.  JGraph apparently uses a "spring" arranger much like TouchGraph -- 
perhaps rooted in the same original Sun demo code. Talking with Murray and 
Kal Ahmed, the creator of TM4J -- the XTM XML topic maps engine 
http://tm4j.sourceforge.net, we begin to imagine a common backside database 
system that spoke GXL, working with relational databases, Xindice, Ozone, 
etc, and a family of mappers that will then talk to any formalism you can 
imagine, including DAML, OIL, RDF, XTM, CG, KnownSpace, and so forth.    (03)

At the same time, I think Murray is already part way along with a mapper 
from XTM to TouchGraph.  I modified TouchGraph's node editor so that it can 
do IBIS discussions.  There's no end of great stuff we might be able to 
pull off.  Be sure to take the time to look at Chris Dent's Warp as well 
http://www.burningchrome.com/~cdent/index.cgi    (04)

For purposes of this thread -- assuming it takes roots, perhaps we should 
consider the kinds of use cases we expect, then see how GXL might serve as 
a common API.    (05)

My 0.02 EUROs for the day.
Jack    (06)

At 06:50 PM 3/4/2002 -0800, you wrote:
>I'm game. How do we start to assemble a common API for all the graph-based
>editors? I was hoping that one of the graph editors would emerge as "the
>best". Therefore such integration wouldn't have been necessary.
>
>Let's say we build an import/export standard. How do we make a tree (XML)
>represent a graph?
>How do we prune a graph for exporting subsets, branches or aggregates?
>
>What common baseline features are required in each graph editor for the API
>to be useful: purple numbers, versioning, typed edges?
>
>...Steve Danic
>Lucid Fried Eggs
>www.memes.net
>
>PS. If I had to guess which graph editor was emerging as "the best", my
>money's on Touchgraph. Let's hope Alex builds peer/peer or client/server
>features into it so we can use it collaboratively. I still prefer typed
>edges though.
>
> > * Integration and interoperability with all other applications using the
> >   same APIs.  There's no reason I shouldn't be able to transclude a Wiki
> >   node in an e-mail, or for that matter, into Lucid Fried Eggs, which is
> >   really a Wiki with typed links.
> >
> > Incidentally, you can reframe a number of apps as essentially graph
> > editors.  XML editors?  A tree editor, which of course is a type of graph.
> > Threaded discussion forums and blogs are another examples of tree-based
> > discussions.  Lucid Fried Eggs, QuestMap/Mifflin, Topic Maps and RDF
> > editors -- all graphs.
> >
> > If all of these tools shared a common API, and if there were tools that
> > implemented these APIs, then all of these tools would be interoperable.
> > The universe of those interoperable apps makes up the OHS, and the APIs
> > are what enables all of this.    (07)