| [Date Prev] [Date Next] [Thread Prev] [Thread Next] | Indexes: Main | Date | Thread | Author |
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)