I have managed to find a tool that illustrates this concept quite well, though it is only compatible with TiddlyWiki files so can’t be integrated with DEVONthink. However, the below screenshot demonstrates what the node graph looks like at “2 step distance” and how this provides a useful way of understanding the local context of one’s notes and where gaps or potential interconnections may exist, as well as facilitating non-hierarchical document navigation.
Live demo available at: http://tiddlymap.org/ - note: this is far more advanced than it needs to be. A simple node graph with arrows would suffice, but the “neighbourhood scope” setting is what is key to make this useful.
This fascinating discussion (which raises the necessity to have some “visual frontend” for devonthink, brought me to this Organising literature in Curio – Jumping from trees – Personal webpage of Kyle Eggleton
This blog has a perfect summary of what we have been discussing thus far: “And despite the amazing ability of DEVONthink Pro to find similar text and documents there is a missing element, at least for me. That missing element is the ability to link similar records in a graphical fashion that suits the way in which I think visually.”
Node graph integration is my #1 wish for q future DT releases–by far. I’m intently watching this thread and very much appreciate all the fascinating contributions. I’ve learned a great deal from everyone–incl. other platforms I hadn’t heard about previously.
@jooz - thanks for sharing the blog post. The quote you pulled from it, is spot on.
I use DT primarily for historical research and genealogy. (To the latter; the need for node graphs functionality regularly discussed) elsewhere.
For me, and I trust I’m not alone here, a node diagram to see present linkages between a document or a group spark an “ah HA!” moment in my head, which can then in-turn present a case for generating repliants of a certain document–i.e. a newspaper clipping from 1695–into other groups in my database. It’s a way to jog my memory in a way that AI will never be able to do.
Jooz; the use-scenarios you present in one your post just above this one, are the ones I’ve been thinking about. Cheers!
taking up the valuable drift of @Jun_GL input: I am also sharing the sentiment that it would be helpful to come to something like a typology / matrix of solutions for graph representation in the context of note-taking/knowledge management tools.
I think the issue of ‘whole graph representation’ is a red herring.
as is mentioned here there are already several conceptual (as well as coded) solutions on how to meaningfully augment a (hierarchical) database with visualizing note context(s), and on skinning this cat (this is also why I also pointed to some existing software in this regard).
so, I think what would be helpful is to use that as basis for a kind of typology of existing solutions / options for helpful – interactive – map/graph-visualizations in the context of knowledge management tools.
– on that basis it would also be easier to coalesce around shared visions (possibly; and if wanted).
for me – coming from a (‘handicapped’) non-coder perspective – I see five general types / approaches to structuring such graphs in a helpful ways.
hierarchies + x-th generation approach
lateral links (i.e. using explicitly linked notes as basis instead of the hierarchy)
collateral links (i.e. showing related notes on the basis of shared parents/ancestors)
content relation (this is of course one of the real potential strengths of DT; and brings in the whole AI road…)
metadata related (tags, frequencies, weights, usage, length etc etc.)
often these principles are mixed in a certain flavor (see TheBrain combining lateral, colateral and hierarchical structuring in a very unique / signature way). I think also noteworthy is the decision of Trilium for example to leave hierarchical representation to the classic folder-tree representation, and concentrate for the graph on explicit (‘wiki’-)links btw. notes. it is not my preferred way of approaching but illustrates different systematic decisions that can be taken here.
but all of these five ‘principles’ to me seem helpful in potentially informing the decisions for a certain kind of visualization (in the context of ‘Zettelkasten’-like tools)
… just some quick rough idea, as I was thinking in that direction rather implicitly with my last post; but then Jun_GLs input made me think out loud on this.
Actually, just by coincidence, but it seems that Devonthink Team actually had this on their minds long before this thread was started:
I am literally copying from the public webpage:
Where in the text of that page do you interpret that it indicates that DEVONthink does/will support a graph view of documents? Please don’t create a narrative for something that does not exist.
It says “automate your tasks with DEVONthink” – that’s a gear, not a graph.
I’ve become partly convinced there is a kernel of something useful in this thread, but I’d like to see someone outline a realistic use case and how it would work. I don’t have a single database with fewer than several thousand documents, and that makes for a nightmarish graph. Nor do I want to rely on AI to suggest relations. But the visual aspect is possibly interesting.
@korm there are many situations where the link graphs can be useful, and provide insight that would be hard to get in a non-visual way - such as:
quickly show unnoticed clusters of linked items, which you might not have otherwise seen. These ‘unnoticed clusters’ can mean, for example that we need to create ‘central’ or ‘top level’ summary notes that explain the cluster (helping us discover and understand previously unseen relationships).
easily pinpoint outlier items - that is, items that have little or no link to anything else in your knowledgebase. This is extremely helpful in visually finding items that need further research, or that should be just dropped out completely.
helping focus new research by looking at areas of the graph that have none or very few links
This is considering that the only available graph view would be one that plots the entire database all at once. If we could have a view that showed only the connections to the selected item(s), then there would be even more uses.
You can find many examples of databases that have such graphs, and why they’re useful - regardless of the size of your dataset. Tinderbox is a personal database tool which offers many different kinds of graphs, and in their documentation they had an example of such a database with hundreds of thousands of items in it. Currently, the modern Zettelkasten apps that are surfacing seem to be offering it, too - and the users definitely want it, and find it useful (have a look at Roam Research, Obsidian, Stroll, TiddlyRoam, and others). IMHO, for use-cases involving knowledge-management and research applications, a network graph of links definitely adds great value to the app.
The main problem here is that in apps that implement such a graph, the links in an item/note have to be treated as a ‘first-class citizen’: the system has to keep a constantly-updated table of internal links for all items, and it then derives the graph from that table. This is not an easy programming task - specially if we are allowing users to add links in the body of markdown notes, rich text notes, html documents and arbitrary metadata fields of any item. That’s a lot of programming work - although it would be awesome to see it put in the official list of ‘planned features’…
I understand the general theory, but I am looking for some specific, granular, explanations of how graph views would work in DEVONthink as it is. Some real-world building-block-level explanations: I have A in DEVONthink, I do B in DEVONthink, I get C, sort of thing.
I am not sure about how to answer this as well. and also think @benoit.pointet made some quite specific use-cases relating to his actual DT-use, thus in a way answering this already.
but on another level I think @korm´s scrutinizing is helpful. at least when I thought through possible answers to the question, I realized that what the question does is point to the need to specify an actual implementation / version of the link-graph logic (and visualization).
that is because different implementations lend themselves to different kind of solutions and thus use-cases. depending on the way the graph actually works there would be different benefits for DT use scenarios.
for example: the logic of allowing for different graphs that very specifically rely on explicit (wiki-like) links – as in Trilium – allows for something as visualizing a / multiple topic networks (Benoits case #1 and #3). a logic that combines the simultaneous visualization parent-child (group-container) relations with lateral (explicit link) and collateral (node that are indirect siblings) relations allow for discovery of yet unrealized patterns of proximity (I guess this is Benoits case #4). etc. pp.
what would be helpful in a DT scenario (based on case #3) is an implementation that would allow users (in case #3 of Benoit) to search for those topic maps/graphs in a global search via their included ‘concepts’/‘constructs’ (notes) – and thus find all the topics (graphs) one note belongs to, and be able to browse them visually very quickly to get new systematic ideas.
all to say: the relational logic of the graph (+ its visual representation / implementation) will / must mirror to some extent the functions (and actual ‘surplus uses’) decided for. which is of course quite an architectural task – even more if you start factoring in different preferences / practices of a set of users…
(1) It is only a very personal experience: Node/graphical UI always look appealing until it gets messy. I stop using all similar apps (any kinds of mind map, the brain) and switch to flow chart/outline once my tasks of any nature are getting complex. It seems to me that nodes or GUI are very bad in dealing with large numbers (I am simplifying the case here). Perhaps having a pre-filter - as simple as a DT search - before the nodes is crucial.
(2) I think more discussions on specific problems and how GUI would help to solve the problem (like what @benoit.pointetdid would be more meaningful than discussing the architecture of nodes. If a DT developer understands what is the essence of common problems faced by many users when they are dealing with notes, documents, tasks, etc they will be thinking about a DT-style solution in the long run - with or without the means of GUI or nodes.
Building your slip-box is simple. We add notes, one at a time. It’s quite possible that you’ve already added a few during or since our last exercise.
While I appreciate Dini’s offer of a excerpt of substance, rather than an introduction (or worse, a installation procedure), what does he mean by “Slipbox”?
“Zettel kasten” == “note box” or “slip box”. (The title of the original work by Luhmann on this technique is sometimes translated as “taking notes with a slip box”. Luhmann used physical notes on cards or slips of paper and kept them in a filing box.)
