For your commonly used searches, you can always create a smart group where the criteria is:
All the following are true
Kind is any document
Tag is Games
Tag is Kids
Tag is Adults
...
Alternatively, you can go into the Tags view of the database and command-click on the tags to get all the documents that contain all the tags that you have clicked on in the list. Note this only works in the Tags view. Command-clicking on multiple tags in other views will give you a list of documents that have tagA OR tagB OR tagC OR…
Ultimately what I’m looking for is as I clip/add items into DevonThink, I will use the appropropriate tags upon first import and rather than use a tag view, I would like Devon to either move them into the right folder (maybe a script) or it does it on import. Let me try again with better examples.
Each clip/item will have main tag such as Cars, Things, People and then a secondary tag. I would like each secondary tag to be a group of likely tagged items under the primary. EG
Cars -
…Ferrari
…Porsche
…GM
Things
…Brooms
…Pliers
…Chairs
People
…Famous
…Infamous
…Funny
So when I clip a website/item that is a Thing/Pliers it goes into that folder automatically so when I open Devon and click in that folder, it’s there.
This is already possible but not without its caveats…
These are hierarchical Tag Groups (or nested Tags, if you’d prefer). If you clipped a webpage and added the Tag “Horses”, the file would appear in the “Horses” Tag Group and also inherit the “Hobbies” Tag from its parent.
However… note the redundant Tags I’ve highlighted. If you Tagged the file “Adult”, it would go to the most recently made Tag Group named “Adult" - and no, you cannot get around this, even by typing a parent Tag first. So, consider this before comitting to such a hierarchy.
I wonder if it would just be easier to create multiple smart groups? I was thinking that this would be an intesnive process?
EG. Smart group for Cars
Then another smart group for CARS + Ferrari
Then another smart group for CARS + Porsche
should yield a view like
Cars -
…Ferrari
…Porsche
…GM
I should not assume inheritance because what happens if an item is named “chairs” and it could be a car chair or a chair of another “Primary” group and thus will go to the newest created one (Bluefrog, I think this is what you were pointing out, if i’m correct)
Per your example, you could define a “car chair” Tag as well as an “electric chair” Tag.
Though some want hierarchical Tags due to the inheritance benefit, the implementation requires precise controls (or more user intervention) to determine the context when redundand Tags are used.
A flat system can be just as effective since context is created through successively selected Tags - in both application and searching.
(Sheesh! I sometimes almost sound like I know what I’m talking about. )
Currently it’s not possible to make a Smart Smart Group - one that references the contents of another Smart Group.
Note: A Smart Group doesn’t actually contain anything, which is why you can’t put anything - group or file - into one. It just shows items that match its criteria.
So it would seem that I cannot do what I wanted except maybe to retag my items into using a concatenated tag. Or accept that I will not have any nesting for projects.
Or ensure you don’t have redundant simple Tags (which you should never have, according to some school’s of thought on the subject).
Or use a flat system and allow the context to be derived from the applied Tags instead of a hierarchy (which is considered by many, the proper way to do it).
Can you give me an example using the descriptors above what you meant by
“Or use a flat system and allow the context to be derived from the applied Tags instead of a hierarchy”
Did you mean
Cars - Ferrari
Cars - Porsche
Cars - GM
as opposed to 2 separate tags?
I think the latter is far superior. Atleast this way the same information can be in two places without redundanct links/copies.
Nope, I meant two separate Tags. (The other method can be useful in a way, but changes to the underlying dataTypes would need to be made to make it truly useful. But that’s another tale…)
This is a fancy way of saying: As you select Tags, the context of the file / search appears.
If I have a flat system with a Tag of “apple” (noting that some systems, including OpenMeta, are case insensitive), it has many possible contexts.
If I put it in a hierarchy of…
Technology
Computers
Hardware
apple
Hobbies
cooking
Baking
Pies
apple
… we run into the redundancy problem.
But if I have a flat system of…
apple
Baking
Computers
cooking
Hardware
Hobbies
Pies
Technology
… and Tag a file with “apple” and “pies”, the context is being defined without requiring a hierarchy while avoiding the problem of inheritance misapplying “Hardware”, etc.
In my experience with Tagging metadata and its issues, Inheritance always sounds good, until it does something unexpected. And yes, the reason most people want to use it is so things are “automatic”, not because they believe a hierarchy is a better system.
On a side note: It’s not that it’s technologically impossible to create a hierarchy that works better than the current methods, but it’s also not a trivial task either. And again, some say it’s a problem that shouldn’t be solved.
I wanted a nested view because having all the sub-categories as a smart group on my main view is not appealing and clutters the space. That’s the main reason I wanted to sort and group.
I may just end up with a smart-group to look for tags, then use that to manually move to the normal groups that can be nested so when i want to find apple, be it a computer or a pie, I go exactly there. Helps with a diet too
)
And yes, the reason most people want to use it is so things are “automatic”, not because they believe a hierarchy is a better system. 