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:
>http://graphs.memes.net/index.php3?request=displaypage&NodeID=17
>
>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.
>Jack
>
>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. (04)