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

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

I forgot to mention:
http://www.pastiche.org/wiki/RewritingWiki    (01)

is a nifty, very lightweight Java (BSD license) Wiki engine.  Check it out. 
My take is that it will not be all that hard to wire it to a database.    (02)

Jack    (03)

At 08:01 PM 3/4/2002 -0800, you wrote:
>Murray Altheim is making a compelling argument in favor of Graph Exchange 
>Language GXL which I just made reference to at graphs.memes.net: 
>GXL is at http://www.gupro.de/GXL/
>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.
>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
>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.
>My 0.02 EUROs for the day.
>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
>>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.    (04)