Re: [ba-ohs-talk] Towards a Graph API
> > Let's say we build an import/export standard. How do we make a tree
> > represent a graph?
> > How do we prune a graph for exporting subsets, branches or aggregates?
> GXL is a good starting point for an import/export standard. Of course,
> it's only a starting point; still have to develop the appropriate GXL
> schemas for different types of data.
> As for pruning a graph, what would be the Lucid Fried Eggs use cases for
> such a feature? (01)
Pruning would be used for sharing bits of data and synchronizing bits of
data. I currently keep all my notes in instances of Lucid Fried Eggs.
Sometimes I would like to send a subset of nodes to someone else for
inclusion in their database (sharing). I would also like to synchronize a
subset of nodes with Thoughtstream ( www.thoughtstream.org ) on a handheld
It's not essential. With email I can send people the text of one node at a
time, but it might be preferable to send them a little self-contained
touchgraph ( www.touchgraph.com ) file. (03)
Imagine keeping lots of interrelational digraphs or ibis discussions in a
single repository, then exporting a single discussion and emailing it to
someone else. (04)
Graph repositories become highly intertwingular, so it's difficult to pluck
a "branch" and export it like you can with tree structures. We need
mechanisms to select "aggregates of thoughts" ( www.ms.lt ) for export. I
suggest that algorithms for determining relatedness and selecting aggregates
should be included in the API. The algorithms themselves could be simple or
complex. A simple one is: all the nodes within x hops. A more complex
algorithm might weight relatedness based on how many edges each connected
node has. Another algorithm might mine the textual content of the nodes to
determine relatedness. (05)
I've made another node at
http://graphs.memes.net/index.php3?request=displaypage&NodeID=18 for an API