Re: Towards a Graph API was Re: [ba-ohs-talk] New backlink metadata; mhpurple v0.2 released
From the tm4j-dev list,
http://www.geocrawler.com/archives/3/12569/2002/2/0/7967813/ (01)
Kal Ahmed had these snippets to say: (02)
"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. " (03)
and (04)
"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 |
+-------+--------+
"
<note>I hope that shows correctly: its a table with database engines at the
bottom, a graph api in the middle, and wrappers such as for XTM (tm4j),
rdf, cg, DAML, and so forth at the top</note> (05)
That table is just how I originally envisioned it as well. Now, bundle
into that picture the various apis needed for, say, node-level permissions
and so forth and you've got a pretty powerful engine to satisfy just about
any DKR. As we learn more about this, Grove-like behaviors can evolve into
the core code to add the additional features necessary to open this engine
up to heterogeneous information resources. (06)
Jack (07)
At 08:04 PM 3/4/2002 -0800, you wrote:
>On Mon, 4 Mar 2002, Jack Park 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
>
>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.
>
> > 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.
>
>Now we're talking!
>
> > 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.
>
>Now we're getting somewhere.
>
>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:
>
>* Lucid Fried Eggs
>
>* Nexist
>
>* dialog mapping tools (QuestMap; Mifflin; perlIBIS)
>
>* Augment clones (OpenAugment, a2h)
>
>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).
>
>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.
>
>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.
>
>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.
>
>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.
>
>Thoughts? Who's in?
>
>-Eugene
>
>--
>+=== 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 ===========+ (08)