[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

On Mon, 4 Mar 2002, Jack Park wrote:    (01)

> 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    (02)

I looked at GXL, and think it would make a great interchange language for
our repository.  I'm going to add a GXL export function to perlIBIS one of
these days.  It's also worth studying for clues on how to structure a
graph-based repository.    (03)

> 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.    (04)

Now we're talking!    (05)

> 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.    (06)

Now we're getting somewhere.    (07)

My proposal would be to create a graph-based repository (lets call it
"Node Soup" for now, a term Nicholas Carroll coined) for the following
projects:    (08)

* Lucid Fried Eggs    (09)

* Nexist    (010)

* dialog mapping tools (QuestMap; Mifflin; perlIBIS)    (011)

* Augment clones (OpenAugment, a2h)    (012)

Here's the short term impetus.  All of these projects are open source.
All of them have a graph-like model for their data structures.  All of
them have their own interfaces to some database back-end, and implement
their own security model, access control, and version control (if they
implement any of these at all).    (013)

Let's a design a distributed repository that all of these tools could
easily plug into.  This repository could store any data with a graph-like
data model, but would focus on the tools above (to constrain the problem).
The repository would handle issues like access control, version control,
etc.    (014)

What would be the win?  All of these tools would inherit all of the
repository's features.  All of these tools would be capable of
interoperating with each other.  You could, for example, create a topic
map using Nexist that pointed to nodes in a dialog map or Lucid Fried Eggs
as occurrences.  OpenAugment could transclude content from Lucid Fried
Eggs or Nexist.  Etc.    (015)

Here's the long term impetus.  Any tool that uses a graph-like data model
could plug into this repository and interoperate with all the other tools
(e.g. Wiki, e-mail repositories, web-based forums, blogs, etc.).
Additionally, it would be easier to write common tools for visualization
(perhaps TouchGraph-based) that would work with all of these different
applications.    (016)

Here's the longer term impetus.  My suspicion is that the API for this
repository will end up looking very similar to the one for NODAL and
Groves.  While our short-term focus is primarily on graph-based discussion
forums, our longer-term goal should be representing all types of data,
including structured documents.    (017)

Thoughts?  Who's in?    (018)

-Eugene    (019)

+=== Eugene Eric Kim ===== eekim@eekim.com ===== http://www.eekim.com/ ===+
|       "Writer's block is a fancy term made up by whiners so they        |
+=====  can have an excuse to drink alcohol."  --Steve Martin  ===========+    (020)