As a result of a failed experiment, I have about 80 DevonThink items that I would like to import into a TBX. I’ve got a watched folder up and working. Unfortunately, it does not translate the internal links between items. The links import, but they point to the original DevonThink item, rather than the new Tinderbox item. Which is reasonable, but misses the point.
If I export the DevonThink items as a web site, internal links are appropriately translated and life is good. I can view the resulting folder in a browser and hop between notes as needed. Yay! But importing that folder into TBX gives the same result: links point back out to the original .html file.
This thread from back in 2017 looks promising:
Is that still the way to go, or is there a better way?
It turns out that Tinderbox was expanding each imported note’s ziplinks in turn. As a result, the first notes to be imported create new targets for their ziplinks because the other notes haven’t been imported yet.
I have a naive question for the forum that may touch on this tangentially. I’ve not used DevonThink but I have looked at online videos and descriptions of what it is good for.
Dragging and dropping “live” files and URLs into a rich text word-processor or database document and then having these containers live in folders (and then having agents) is one thing.
If that’s what it is, it is a smarter work environment for my mindmapping than a traditional desktop GUI (with task automator as a partial analogue to agents) can be.
And like Tinderbox a structured output can be webpages. But what I like about the desktop GUI is the ability to arrange files in groups spatially (with folders as a very limited third depth “dimension” and tags as a different kind of “dimension” of sorting), and what I like about TBX mindmaps is the ability to make spatial linkages and annotations be first order entities in their own right; it sounds to me like DevonThink users either don’t revolve around these, or don’t even have them to play with. The kind of container I am looking for is a Tinderbox file, with outline and spatial map views structured in all the mutually consistent ways Tinderbox can do, but where that power is applied to a GUI where I can file things like I normally would on my desktop in addition to adorned notes and web clippings and URLs.
I would like to understand, please, whether this is a big CPU step from how Tinderbox is set up to be used – or isn’t a big step at all. I see another post asking why long PDFs automatically get handled into searchable text in Tinderbox rather than just as a shortcut to their directory location. And I can sure imagine some of my multimedia files and PDFs becoming a memory liability if this is being lugged while they are tagged and drug back and forth in mindmaps with outliner link structure to many trailing annotations. But the point is to have directories in which my workflow can leave them and mark them up like they live there.
DevonThink is a full text database. Its fundamental purpose is to help organize large amounts of text, where “large” means millions of words. My smallest active database has about a quarter-million words. My main “working” database is about a million words, and my main “archive” weighs in at over seven million.
It supports links between items, and annotations and other forms of metadata. It has extremely powerful literal and “fuzzy” search functions. It supports groups and tags and outline-like views based on those, but it has nothing comparable to Tinderbox’s spatially-organized views. I can’t speak for the developers, but I think the working assumption is that if you’re using DevonThink at all, your dataset is too big to organize spatially.
For comparison, DevonThink is what I use when I’ve just downloaded the entire proceedings of a conference and need to sort the papers into my own topical groupings. Tinderbox is what I use when I’ve read 10 or 20 of those papers and need to organize my own notes.
There are several questions to unpack here. First off, consider that Tinderbox utilizes a single XML file for each Tinderbox document, whereas DEVONthink is a repository of hundreds or thousands of file, each stored individually. It’s possible to bloat up a Tinderbox document with a lot of imported data from watched or imported documents. The CPU impact is hard to project – depends on your machine, what else is going on, the OS level you’re at, available memory, etc. etc.
The rules of thumb I suggest are “Don’t import data into Tinderbox that you are not going to manipulate in Tinderbox. Don’t import data just to store it in Tinderbox. Instead – link to the source of the data, and take notes about it in Tinderbox.”
The practical effect is that dragging something from DEVONthink to Tinderbox causes Tinderbox to ingest the contents of the DEVONthink item into the XML file. XML is a flat text file – it has no native way to store PDF or image data. So that can lead to the case for a PDF “dragged” to Tinderbox that what you see in Tinderbox is not what you see in DEVONthink.
I would think of Tinderbox as more a companion to DEVONthink than a place to replicate data (document content) from DEVONthink. We cannot annotate PDFs in Tinderbox but we can take notes about PDFs, and link back to the file in DEVONthink. Or we can (as covered in many threads here) import the annotations from DEVONthink to Tinderbox and work in Tinderbox to further analyze them.
An analogy: you probably wouldn’t create a Word document (also XML) that summarizes the arguments in a corpus of PDFs, and copy into that document all the contents of all those PDFs. Same thing for Tinderbox.