I swear I have searched this topic here, and there are tens, if not hundreds of users experiencing confusion over the implementation of tags in DT. From all I read, it is clear that the current implementation, although intuitive to some, is inconsistent at best and does not make much logical sense (to some, it violates the mathematical principles of set theory). Essentially we are condemned to either (1) a non-hierarchical tag view or (2) a hierarchical tag-as-folder view. I am not sure how much time and effort it takes for Devon to create a toggle button that allows us to switch to our preferred view (tag groups show items belonging to sub-tags, vs. not), but clearly that goes against some hidden ideological design dogma we are not allowed to contemplate.
Actual question:
Now, while I am waiting forever to get my decent dose of real tags in DT, I have made a workaround: I have created smart groups in my higher level tags that show all the content tagged with that specific tag. The problem is that all the counts are wrong (see in the picture).
Here I have a database with only 9 documents. Yet, when I search for all the documents tagged with “Packages”, the count is 12 (they are 8, actually)! This doesn’t look correct, even with DT’s strange tag implementation. Any explanation?
I’m guessing that your only criterion for the smart group is Tag=Packages. If that is the case, then the smart group count is correct. There are 8 documents tagged with Packages as well as four tags (tidyr, sparklyr, etc.) for 12 items total tagged with Packages. The view is displaying documents only, so you see only the 8 documents. Switch to a different view e.g. as Columns and you will see all 12 items in the column.
If you want only documents in the smart group count, add the criterion, Kind>is>Any document.
I didn’t get how it is about tags at all. The ‘Rant’ part appears to me to be about how documents in sub-groups are not displayed in the Three Pane view when a (document or tag) group is selected. Perhaps I am missing something that makes this tag specific?
Having said that, if @mszargar is only looking to have tag groups show items belonging to sub-tags, then the Tags view does this nicely.
Yes I agree and I expressed this opinion when Devon first introduced tags.
Mathematically, tags (back in the old days, for example tags in photo DAM apps) were merely subsets of a universal set. When hierarchies were defined, the set paradigm was maintained in the sense that if Paris was a child of Cities and Paris was a child of Daughter. The tag, Paris, would reference cities as well as daughters. And Cities and Daughters were also tags. As an aside, I once worked on a project where parents in the hierarchy could be either tags or categories (used to categorize tags). I even had my students write a program using these concepts. So, For your daughter, Paris, you would need to include the tag Daughter. If searching all references of Paris, regardless of context, all you need is the one tag, Paris.
Thank you Greg_Jones and korm. That solved the issue! I hadn’t noticed that tag hierarchies are actually saved as tags on tags (that actually makes a lot of sense).
What, then, doesn’t make sense is that if I drag a document item from one tag to another, it simply receives the new tag and keeps the old tag. While if I drag a tag from one tag to another, it moves to the new tag!
And dear BLUEFROG:
Real tags are sets of labels that we stick on objects:
This is regardless of the physical positioning of the objects. You shouldn’t be able to save an item in a tag group. In DT you can. That smart group above is saved in “Coding > Tags > R > Packages”. That doesn’t make any sense. Removing a tag from an item must not make it orphan, as it should always be saved somewhere in a folder structure.
By the same token, moving an item from under a tag to a folder (group) must not remove it from the tag, but must rather just move it from its folder of origin to the new folder (and ask for confirmation on the way). A tag hierarchy must remain just a “view”, a special way of filtering. Here as well, DT goes against the logic of the tags, by making tags behave like folders. The only way to remove an item from under a tag must be eliminating the tag from the item. You can’t “move” an item out of a tag, or even if you can, that must not be the default behavior of the user interface when you drag an item.
Wether in a hierarchy or not, a tag filter must show all the items under it, or at least give the option to display all the items “tagged” with that tag. Again, think of labels. If you are looking up a label you want to see all the objects with that label, not only the ones that are not hidden within another object with that label! DT violates this logic as well. The hierarchical tag view hides the files with a specific tab, when the tag is not a low-level tag. That is also creates a user interface inconsistency that many have complained about before me. When we click on a high-level tag, you actively “hide” the document items from the pane that normally displays them, if they happen to be tagged with a lower-level tag as well. You could at least give us the choice there. Don’t refer me to the other tag view please (View as tags). That’s completely useless, as it doesn’t show the tag hierarchy.
Tags are different from hard links - the possibility to have multiple pointers to one item in different folder structures. Tags came about after the hard links, as a less restrictive solution to organizing items. All modern file systems support soft and hard links, but they also support tags in xattrs. That’s because they are supposed to be different. What you have reinvented is actually a folder structure with hard links. It is fine, but it doesn’t go all the way to “tagness”.
I appreciate that there are tags and tag structures in DT, but the behavior remains inconsistent with the mere concept of a tag, in the language and in the computers. DT tags look like an alternative folder structure with perks. I understand all this comes from the desire to give tags structure by allowing a tag hierarchy, and I also do appreciate the effort. But the implementation is weird and inconsistent at best. The way I see it, tags, themselves, may have hierarchies. But the documents tagged using hierarchical tags must not obey tag hierarchies. They are simply tagged. You may facilitate tagging by allowing us to drop a document in a tag hierarchy, that’s great. But that doesn’t mean the document has been positioned at that level of hierarchy, despite the fact that it has taken all the higher order tags as well… A tag filter must still show the tagged items, no matter what level of abstraction we are at in the tag hierarchy.
Anyway… I definitely don’t have the time to write my own document organization software while I am on the tenure track, so I am glad I have DT. But DT could get much closer to a more helpful / useful implementation of tags with much less redundancy with the folder structure. It doesn’t even require breaking backward compatibility. Only a few additional UI options would give us much more flexibility using our tags.
And there is a large and vocal camp that believe Tagging should NEVER be hierarchical, but should only be a flat space. Our approach attempts to give both options.
I personally believe the ideal model uses both approaches but it needs to be more well thought out than most people put the effort into.
(PS: Apologies, if needed. It’s not a defense. Just a discussion. )
That’s all that is wrong with DT. Tags are not groups, and it is wrong to treat them as groups: it is feature redundancy / lack of clarity. Tags are tags – labels, and they have to be treated as such. You just explained what is a major inconsistency when dealing with two different types of objects/elements/items in tag hierarchy. If a hierarchy of tags consists of tagged tags, then tag elements should be replicated, just like any other item in the tag hierarchy, when they are dragged around. It makes absolutely no sense that they are moved as if they are groups. If tags are groups, then why do we need tags at all?
I have no problem with you guys keeping posting here and justifying the incoherencies in the user interface and congratulating yourself on the superiority of the approach you are defending. And I don’t want to take your toy away from your – I am asking for minor accommodations that make the software adaptable to other workflows unlike yours. But I also explained in detail why from my perspective DT has got it partially wrong (hard links, ability to save in tag groups that is yet another inconsistency).
That’s not only me, just do a little search and you will see how many have complained about this. That’s because to many it doesn’t make sense. But this is software, not religion, so there are many ways to do one thing. I am just saying some minor tweaks would make this piece of software much more useful for us as well, while maintaining the features you benefit from.
Tags are the elements of semantic organization. They are, by nature, hierarchical. But one may argue that their hierarchy must not be embedded within the tags - the hierarchy might be contextual, shifting with the context of use. You may want to use one hierarchy for tagging, but another hierarchy for search and retrieval operations, and yet another hierarchy for browsing based on topic. I personally find the hierarchy of tags very useful, and if DT bends a little bit on a few points I will probably get rid of all folders completely for my reference docs, keeping them only for my projects (live docs). Many filesystems initiatives are also pushing that way.
I can’t agree more. We would benefit from a better executed tag system almost everywhere. Although I am against making tags a completely free-form enterprise, and I like the fact that DT puts limits to that, I think a few flexibility like those I counted above would help many make more out of them. That doesn’t need to undermine the current model, but would rather allow for options.
Haha, no hard feelings. I know it is a discussion. No need for apology either. I am just trying to get the point across, that how frustrating the current tag function can be for someone who is not a big fan of the current implementation - mostly because a few UI options would introduce enough flexibility to solve all of these issues. For instance having just a toggle button somewhere, saying “Treat tag groups as sets vs. tag groups as regular groups”.
As I said, I personally dislike tagging. But it is important to any discussion to know the facts, and so I spent time explaining how this DEVONthink tagging works.
I am not defending a damn thing.
And I am offended by your tone and personal attacks, which have no place in this or any forum.
I apologize if I said anything out of frustration. I do understand your explanation and I learned from that. Thanks for your help once more.
I think ultimately I will try to make a script to create smart groups in all higher order tag groups, instead of pulling my hair out.
This is the most useful content-management piece of software I own, and yet it has some unnerving limitations (e.g. What’s the deal with that sync window from 1990s, and how can I get rid of it when it jumps up in the middle of my writing?!)… Or take this one: Yesterday I touched the minus button by mistake (instead of i for info) when I was on the sync window. No confirmation, nothing, DT just deleted my main sync location!!!
)