The reason I love and use DEVONthink Pro Office for my own research and data management is that it frees me from the necessity of a lot of grunt work such as highly hierarchical, detailed organization into groups and/or tagging for reliable and comprehensive identification of the information content of documents.
Before computers became available, it was necessary to file documents in a consistent way in order to retrieve them. In the early days of computerized databases, before full-text searches of content became available, it was necessary to use keywords (tags) to retrieve them.
But there are two fundamental weaknesses in retrieving documents by their organization or by keyword/tag. The first is completeness of identification of important information relevance, as the same document may be useful in multiple contexts. It would take a lot of time and effort to do that for many documents in my database. The second is consistency, as different persons (and certainly the same person at different times) will be likely to organize or keyword/tag the same documents differently, and I found that no amount of training could solve that problem. (From 1969-72 I developed and ran a university computer information center that disseminated the results of federal R&D that were relevant to environmental issues. Searches were by keyword/tag, and the weaknesses of this approach were highly evident, both up-front at federal agencies in applying the identifiers and when devising search strategies to meet information requests by my staff. Those weaknesses are often noted in the literature of computer science and document management.)
I discovered DEVONthink in its first year of release, and it revolutionized my management of my digital documents. For the first time I could truly integrate the information content of documents that were of different filetypes. And DEVONthink included artificial intelligence assistants to help me file new content appropriately (including the use of replicants when multiple filing locations might be appropriate), and to look for documents that might be contextually similar to one that I was viewing.
DEVONthink has continued to evolve over time to the point that I consider it the best research assistant I’ve ever had. It has AI assistants and powerful searches that also enable creation of smart groups on the fly. From the beginning it enabled ‘marking’ by keywords (in the Info panel of a document) and later brought tags into its arsenal. DEVONthink Pro and Pro Office have large AppleScript dictionaries, enabling automation or extension of procedures via scripting. And (perhaps because of my training in the old days before lab equipment to tackle bleeding edge research wasn’t available off the shelf but had to be cobbled together from what was already in the lab or available at a hardware store or Radio Shack), I found that I could often create kludges to accomplish tasks for which no built-in tools were available, such as replicating search results into a new group in order to perform subsequent procedures on those items.
Some of the tools of DEVONthink such as searches, tags and See Also work well in a database that has no group organization, such that all documents are held at the root level of the database. Some users operate in that mode, at least for some databases. Of course, the Classify assistant becomes useless in that case.
Christian Grunenberg, the architect of DEVONthink, notes that See Also is somewhat improved in a database that holds groups. But See Also still can ‘find’ contextually similar documents in different groups or at the root level.
Personally, I do create groups, but for my own edification and convenience rather than DEVONthink’s. I rarely create multilevel hierarchies of groups, as that takes more time and effort, although I sometimes find it useful. Most of the groups I create in my research databases contain contextually related (topical) content, so that the Classify routine works well in suggesting locations for filing new content. But in some databases such as my Financial database, I do use a highly structured hierarchical group organization and don’t use Classify for filing chores. I know precisely where to file a new invoice or receipt in that structure, e.g., by Year, category and Vendor. (And I don’t need to do a search in the Financial database to find a receipt in that database, as I already know where it will be found.)
As for keywords or tags, I almost never apply them as new content is added to the database. Why? Because, as may be evident from my previous remarks, I don’t consider the time to do a good job of tagging would be an economical use of my time – it doesn’t pay off well enough.
Most of my tagging is done at the project level, for example when I’m identifying references or notes useful for that project and ranking their information content for specific purposes. When I finish that project I will usually delete those tags, as they would likely have little or no utility (and might be counterproductive) for the next project I undertake. But in my Financial database I might create permanent tags identifying cost items for a project.
So my advice in approaching the level of effort in group organization or tagging is to tune it to your needs and workflows in that database, so that you accomplish what you wish to do with the minimum level of effort that gives a good payoff for the effort put into it. In a database like my Financial one, I gave a good deal of prior thought to group design, and that paid off. In my research databases, sometimes I start with one-level topical groups, and may find it useful to reorganize some of them into a hierarchical structure later.
Tips: When devising hierarchical structures for groups or tags, give sub-groups unique names so that when Classify suggests that group, it won’t have a common name used in other groups or tags also, such as Miscellaneous or Physics – which would be confusing. And when filing documents or assigning tags in hierarchical structures, always do so at the lowest appropriate level of the structure – otherwise, the hierarchy won’t make logical sense. Never file or assign at the top level of a hierarchy; if that has occurred, move items down into the lowest level of appropriate sub-groups or sub-tags.
Final tip: Don’t get obsessive about organization or tagging, as you won’t have time to get any real work done with your database.