Looking for comment and critique of this unusual approach To DEVONthink.
I use NO TAGS. No even one.
Essentially NO GROUPS, either. (Just one tiny group of 17 documents.)
Why so?
Saves much time and aggravation.
I never think about tags or groups.
Everything dumped into one database, and DT does all the work of figuring out what is relevant to each search.
Search functions in DT are so powerful and so fast, that, so far, no problems.
It is the “so far” that worries me.
This approach of no tags and no groups is so far from the standard practice that I worry about in future hitting a big problem.
Search functions in DT are so powerful and so fast, that, so far, no problems.
Yes, a very powerful search function makes different approaches possible.
The question here is: Does your method make sense to you and are you effective in searching and using the materials in your database?
And do not be so in love with your idea that you feel you can’t explore other options. Perhaps you’d want to add some basic groups at some point. Perhaps you’d like to add a Tag to two in the future.
Obviously Classification will not be functional with no groups to point to, but See Also should still suggest files that may be related.
BLUEFROG, post:2, topic:51093…
The question here is: Does your method make sense to you and are you effective in searching and using the materials in your database?
Well, no, that’s not my question. It already makes sense or I would not have posted about it.
.
And do not be so in love with your idea that you feel you can’t explore other options.
I always appreciate advice, but my response should also be obvious. This post is exploring.
.
See Also should still suggest files that may be related.
Yes, indeed.
I never think about tags or categories. Is anyone else working along these lines? If so, has this strategy caused any problems?
This is just a case, where you don’t use much “collect & analyze” functions in your DT-related workflows. Human brain is a “Difference Engine” and first logical operations people usually do to organize arriving information are: difference operations, part vs whole, completing a whole and so on. So, you will need grouping and tagging functions of DT when you try to incorporate such activity into your workflows.
An aspect to using DEVONthink (or even Finder, for that matter) is that you can do “incremental formalism” starting from any point you wish. So, if today a single-big-bucket approach works for you because of the search features, then fine. As time progresses maybe you find that some of your saved searches need to be shored up with some fixed groups for this or that topic. And, as more time passes, maybe those groups need to be modified and be broken down into subgroups. Then, more time passes, and you find that having the groups is a drag and you can get rid of them and put their documents back into the big bucket.
So, I don’t think it’s likely you’ll run into a “big problem”. If a “big problem” means you lose track of your data. You can, after all, use smart groups to start down the tagging path, or the setting-up-groups path, etc.
Couldn’t agree more. I naturally tend to using groups for most stuff. Like, I know my heating bills are going to be my heating bills, so no sweat to have a Household Cost > Heating hierarchy in place. I don’t need to search for “heating”.
On the other hand, I avoid tags like the plague. When tagging became popular I spent untold wasted hours on them and have never once benefitted from all that work. More power to you!!
I think in order to give advice we would need to know a bit more about the nature your database(s). What type of information are you storing; what are some typical queries when you retrieve the information.
… need to know a bit more about the nature your database(s). What type of information are you storing; what are some typical queries when you retrieve the information.
Thank you,@rkaplan. That’s the most useful response so far.
The information topic is health and medical. 99% clippings from the web, a few OCR scans. 99% text, but a few tables and a few images, very few.
Some clippings stored in DT as web archives, some rich text, some plain text. A few PDFs. So, a bit of everything text-wise, but no sound or videos.
A typical inquiry might be, "Vitamin C" AND (coronary OR CHD)
I’m not trying to sell this approach or persuade anyone else to use it. I am wondering if there is some hidden danger ahead that I can’t see from here. So far the “one big bucket” approach is working perfectly well. (And the reason it is working well is the powerful search capabilities of DT.)
For about one year now I have been using the “one big bucket” approach in the Finder – not every file, but many. That approach is working very well there, too, using a Finder search program, “EasyFind”.
If anyone can think of some problems ahead, I hope you will point them out.
I think for that application your approach is fine.
Groups and/or tags seem more critical when there are potential mission-critical items to retrieve, such as a database of business or legal records. Groups and/or tags also seem more critical if your documents are your own work product or that of your company/colleagues and they may need to be retrieved as part of a pertinent business transaction or report.
It seems that your application is for DT3 to be a library or repository of publicly available information on a topic and you are using DT3 to curate/organize the information to help you know what to read. In other words, you are creating a superior alternative to a web search engine for the specific topic(s) about which you are collecting material.
In your case, I think your approach is just fine. In fact, trying to organize by groups or tags might result in your losing some important responses to your searches.
@rkaplan -
I appreciate your reply. You’ve described the essential factor where a “one big bucket” approach might NOT work well.
Groups and/or tags seem more critical when there are potential mission-critical items to retrieve, such as a database of business or legal records.
…
you are using DT3 to curate/organize the information to help you know what to read. In other words, you are creating a superior alternative to a web search engine
Yes, exactly. And I like the concept, “curate”. DT is the best tool I’ve found for that.
Thank you for taking your time to think and to write as you did.
As for what I was trying to say. If “final result” in DT workflow for you is to find the right material to use, then your approach might be just fine.
But you will need “networking”, grouping and tagging for making something “new” out of DT contents, or better to say, if this part of your work will lie inside DT.
I have found, counter-intuitively, that tags seem to work better for grouping material that I think is related, but that DT might not see as related. If I have a few documents that relate to a given project, then I can tag them with the project name, and they maintain the tag no matter where they live in the database. But if I put them in a group, and then move one somewhere else, then the relationship between them is gone.
@padillac
… they maintain the tag no matter where they live in the database. But if I put them in a group, and then move one somewhere else, then the relationship between them is gone.
That is exactly the kind of situation I wondered about. Thank you, @padillac, for your post.
You’ve confirmed, once again, why I’m not using groups and probably never will.
I won’t use tags, either. Tags require thinking and maintenance. I want DT to do the thinking, not me. So…
When I enter any document into DT I glance to see if the appropriate keywords are somewhere in the document. If so, I do nothing !
If I don’t see essential keywords, then I enter them into the document or meta data or anywhere. DT will find it. But that is only a small proportion of documents. Most contain some keywords, if not all. (If keywords are repeating and frequent, I use a Keyboard Maestro pallet and just click to enter instead of typing.)
With keywords inbeded in each document they are never lost, never confused.
And I never move documents either – everything in one big bucket.
Well, I’m satisfied that this approach will not create unexpected oblems in the future. It has been valuable to read and think about the comments above. Thank you.
I suspect there is one major exception to that rule.
If your use case for DT3 remains solely to curate and read content, then this approach will probably serve you well.
However if at some point you choose to also use DT3 to create new content of your own, such as a blog or scholarly article based on information in your DT3 database, then you will probably find that creating your own Groups (or Smart Groups based on your tags) is essential.
