[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


 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)