I’m playing around with how I might use tags in my databases, but do not understand why I have duplicate tags.
In a database the same sub-group name repeats in different groups. This results in separate tags named the same as that repeated sub-group.
For example, Group 1 has Sub-Group “Example” and Group 2 has Sub-Group “Example”. Then in the Tags view I have two separate tags named “Example”.
Although those tags derived from your database groups have the same name, they are not actually duplicates. In the Tags view, click on one of those tags in the right-side list of tags, and then on the other. Do you see the same documents listed as members of the two tags named ‘Example’?
Note that if you select a document that has been ‘tagged’ by the ‘Example’ tag, you will see in the Tags bar the containing group names, which will be different for each of your two ‘Example’ tags.
You have two groups named ‘Example’ although they are at different locations in your organizational structure and hold different content. Likewise, this creates two instances of tags named ‘Example’, which have different document members.
If the multiple tags are not useful for you, it is possible to use the Info panel to exclude those groups from tagging. Doing that, those group tags will not appear in Tags view.
Bill, that’s exactly what I do see. And, now I no longer see much value to tags over groups and sub-groups, except for import and export. Especially in my case when I see 6 or 8 separate tags all named the same in tag view.
Also, if I Command+click those tags in tag view I get no entries displayed and not a combination of them.
I just had expected tags to eliminate a bunch of replicates where similar categories of content repeat in different groups. Kinda like “tagged” by assigning searchable and viewable keywords for those categories.
And, excluding from tagging doesn’t help.
Just click on a tag displayed in the right column of Tag view, to see its members (not Command-Click).
Personally, I’ve never bothered to tag items as they are added to the database, as I’ve never seen any tagging system that justifies to me the time and effort required. Sometimes I use tags (usually by marking items of special interest, e.g., with Label colors) when I’m working on a project, and usually remove those marks when I’m finished.
But I will make more use of tags with the new Tags system. I’ll probably eventually remove most of my groups from Tag display, and develop new tags for special purposes.
Thanks again Bill. I’m leaning toward your approach of using tags for particular purposes. And like you I have currently marked items of special interest by using colors and specific keywords in Comments. We’ll see how tags evolve.
I should have been clearer about Command+clicking. Blank listings occur when Command+clicking on multiple tags in tag view. Tagging Help states all items carrying all selected tags should appear. They don’t.
This does, or it least it should, work as described in the Help file. I’ve used this feature extensively since the Tags view first became available. If you cannot get this to work with any combination of tags, you might want to file a support request.
Command+clicking multiple tags in the Tags view displays nothing – “No Selection”. However, that same Command+clicking does export all the files from all the selected multiple tags.
I suggest that tags named the same and applied to files duplicated in different groups still be considered as the same tag and only displayed once in the Tags view sidebar.
That approach is logical and consistent with what happens when these same files are exported and their OpenMeta tags are viewed. Tags of the same name are all the same even if they originate from different DT groups.
I believe the PB8 help file explanation of tags view is imprecise. The help file says in the “Views” topic
This means that a multiple selection (cmd-click) is a boolean AND – tag1 AND tag2 AND tag3. The documents displayed with this selection are those for whom the boolean selection is true – documents that have all three tags.
The “all” in the help file is ambiguous in plain English, and could imply a boolean OR, which I think is what dfuller is expecting (reasonably so). But, tags-view multiple selects are ANDs. To get an OR, one needs to do a multiple selection of groups in 3-pane view (for example). Unfortunately the help file is silent about the multiple-selection OR feature in 3-pane view.
I can’t reproduce the problem of cmd-clicking tags causing all the files to be exported.
That would be a nice feature. It has to be squared with the use scenario for many DT users who have a practice of including subgroups with the same name throughout their databases as a data management technique. The “single display” proposal wouldn’t work for those folks.
I don’t agree that “group tags” with the same name should then have the same content, even if that’s what happens when the OpenMeta tags are assigned in Spotlight Comments when the content is exported.
The important point is that such duplicative “group tags” had meaning to the user when the organizational structure was created, the content assignments to those groups did result in differences in content between groups of the same name, and those differences are recognized by the user when doing manual classification of new content and also by the Classify artificial intelligence feature of DEVONthink.
So information would be lost if DEVONthink’s Tags system were to subsume all groups with duplicative names into a single “group tag”. The fact that such information is in fact lost when the files are exported and OpenMeta tags are assigned doesn’t justify throwing that information away within DEVONthink. It seems to me better to leave the user the choice between accepting ambiguity in group names, or renaming groups to remove ambiguity. Within DEVONthink, the organization structure distinctions between groups with identical names can be revealed by selecting a content item and inspecting the Tags bar.
Emphatically agree. DevonThink should NEVER simply discard information assigned by the user. In fact, I would say that any database that handles ambiguity in that way is seriously broken.
On the other hand, I see this potential for ambiguity as a serious problem with the current tags=groups metaphor. I see having a tag structure independent of the group hierarchy as one of the biggest reasons to bother with tagging in the first place. For example, I might want to assign tags relevant to a particular project, while leaving the overall data repository structure alone.
Katherine
My sentiments exactly.
I agree. I’ve never bothered with tagging new content as it is added (e.g., by keywords), as I’ve never thought it worth the time and effort to do it, and I’ve never trusted myself (or anyone else) to define and consistently apply keywords that would make every document in a database more useful to me.
I do tagging at the project level, when it makes sense to me and the effort will probably be repaid. I suspect that I’ll end up excluding all or most of my groups from tagging most of the time, although I’ve already found the group tags useful a couple of time.
It would be nice to be able to toggle group tags on or off easily, so that when I wish, only new “tag-tags” are visible when I’m working on one of my projects.
If I exclude groups from tagging then same-name tags from different groups are shown separately in the tags view sidebar. That just doesn’t make sense.
Exactly! And consistent with OpenMeta tagging.
AND/OR?? Command+clicking in tags view successfully exports those tags (combined) but inconsistently does not display them.
Good idea maybe to check in on the meaning of boolean logic esp. as used in DT - e.g., the manual.
Cmd-click over here selects multiple items in any group or list or tag view (as it does in Finder). It doesn’t export. There must be some other keystroke over there.
Thanks korm for the suggestion. This isn’t a logic issue but more one of UI consistency. Select multiple tags in the Tags View sidebar and go to File > Export > Files and Folders. You get all the tagged files exported but they are not displayed in the Tags View.
And, not to totally disagree with my esteemed commenters here, but this duplicate/multiple tag thing is simple.
I suggest that most users expect tags to not be hierarchal. That’s what folders (groups) are for and is a view consistent with the rest of the Mac universe. If DT keeps tags internally as hierarchal (tags=groups), then combine duplicate tags and display a single tag to the user in Tags View. Also export them as a single tag.
That approach will break existing (pre-tag) databases, and make structuring new ones more difficult. If I have groups called photovoltaics/business and integrated circuits/business, the two “business” groups are NOT related, and the two “business” tags should NOT be combined.
As I’ve previously posted, any implementation of tags MUST honor the user’s prior decisions about database structure. Data corruption – which is effectively what you’re advocating – is the most serious error a database can commit, and will cause users to abandon it in droves.
I’m not worried, because I assume the DevonTech folks know that. But I’m somewhat amused to see people screaming to high heaven about relatively trivial cosmetic tweaks, while blithely waving away issues that go straight to the heart of DTP’s core functionality.
Katherine
I think there is only one people. The rest of us agree with Kathrine. With the last post about File > Export maybe there is a bug that DT could look into. The rest is what it is, and you wrote “finished” to that story. Thanks.
There’s nothing logically wrong with thinking about tags hierarchically, or as tagged items belonging to one or more larger sets which are themselves tags, or indeed as being sets capable of having members that can in turn be discretely tagged. In fact, that’s the most likely view most people have in mind when they ‘stick’ a tag onto something.
Your suggestion that ‘group tags’ that have the same name should be converted to a single tag that subsumes all the members of the duplicative groups might fit the way you organize content.
But I think it would be strongly resisted by other users of DEVONthink. Example: I know a user who creates topical groups holding the content within a database. Within each top-level group he has tightly organized some of the content by characteristics reflecting the content and his interests. But each such top-level group also contains a subgroup named ‘Other’, which holds content that has not – at least for the time being – been further classified into groups based on content/interest, but is topically relevant to its container group.
I don’t think his approach can be criticized as ‘wrong’. I would consider him a power user of DT Pro databases. And in fact, when I examine my own databases I find that I sometimes behave in much the same way, although I haven’t been as systematic in naming my partially classified groups. I use names such as ‘General’ or ‘Miscellaneous’ and so on.
It’s true that if that user switches to the Tags view there will be a long list of tag groups named ‘Other’.
But I’m quite certain that user would not wish to have all his ‘Other’ group tags collected into a single tag, either within his database or as OpenMeta tags of exported content. That just wouldn’t make any sense. The tag would lack meaning or coherence.
Let’s leave it up to the user. He has three general choices:
Leave the Tags view as is, however messy the result. Note that if his files are Exported, the OpenMeta tags saved into Spotlight Contents will be correct, as the hierarchy of the group tags will be correct and in that way will distinguish the files that have the ‘Other’ tag in a meaningful way.
Rename the ‘Other’ groups, e.g., by prefixing the name of the container group. That eliminates duplicative group tags in the Tags view.
Exempt some or all of the groups named ‘Other’ from tagging. Note that the items contained in tag-exempted ‘Other’ groups will still retain the group tag(s) of the enclosing group(s). So the individual items in all the tag-exempted ‘Other’ groups will still have meaningful group tags.
Bill and Katherine, thanks for the clarifications and examples. I DO understand your perspectives, but still DO NOT get the philosophical difference between hierarchal tags (tags=groups) and the groups were already have. What is being done with these tags that cannot be done with sub-groups and replicates?
My organization is similar to Katherine’s. I also don’t want the “business” groups combined, but (continuing her example) I do tag entries with the names of manufacturers. Also similar entries in many, many other groups.
At some point I want to be able to find all entries by manufacturer. (I do this now inside DT using keywords in the comments field.) I may then “reveal” entries to locate them in a group, sub-group, etc. Or, if exported, check other tags to find the pertinent DT group data. “business” might not be a significant tag, but “photovoltaics” might be.
With the current setup for tags, I care little about tags on groups except for exporting. I do care about seeing 40 or 50 separate tags all with the same manufacturer’s name in a Tags View. Is this an unacceptable philosophy of tagging in DT?
I agree completely. My admittedly off-the-cuff suggestion was only for display in Tags View to alleviate difficulties from what seems to be different philosophies of tagging. Possibly as a user-determined option. Technically DT is committed to hierarchal tags (tags=groups) and that structure is valuable as is a user’s existing organizational structure. No argument from me about altering what already exists.
Also, I just do not have a concern over “group tags”, Misc., Business, Other, etc., which have been vigorously defended here. But how about a compromise like Bill’s plus in some way dealing with same-name tags?