Just updated to the 2.0 release. (I miss the beta stripes at the top )
My concept of tags don’t seem to coincide with Devon’s, as I’ve suspected from using the beta (and judging by many other posts in this forum). One area that has been very much into tags, a lot longer than the Open MetaData work, is photography software. If you look into Lightroom or Aperture, tagging (and hierarchical tagging) has been built-in for a number of years. I’m a mathematician and computer scientist who’s been interested in taxonomy and the storage and retrieval of information, and all my experience with tags (especially in photography) rests on the concept of set theory.
A group of nodes with the common tag of “foo” should be retrievable using that one tag. For example, if I have nested tags:
History
Paris
Photos
Paris
then anything tagged with Paris should be in one set. In the photography apps, tagging an image with the first “Paris” will add the tags “History” and “Paris”. If a second image is tagged with the other “Paris”, it also has the tag “Photos”. If I extract the set “Paris”, then I get both images.
In DTPO, if I bring up the tag view, then I’ll have two “Paris” icons. This isn’t, in my opinion, proper. There is only one set “Paris” and a single icon should be displayed resulting in a list of all items tagged with “Paris”.
Of course, I understand that DTPO’s use of tags is based on Devon’s concepts of tags. (I also find their mantra of “tags are groups” unusual, as tags are based on sets, which are not hierarchical in the group/folder sense.)
At this point, I must part with DTPO as it does not support my view of tags (and that of many other applications).
I agree with you that multiple tags of the name should be combined for display. I mentioned that a few weeks back to the DevonThink support team, and was told that this request might be addressed in a future release.
Given that this is the first official release to contain tags, I am confident that things will improve with upcoming versions.
I would agree with you about combining the items tagged ‘Paris’ in your example organizational structure. In displaying ‘group tags’ DEVONthink separately lists each group named ‘Paris’.
But it’s not that simple. Many users have organizational structures in which there may be many groups with the same name, but containing quite different content. For example, a teacher might have a database with groups defined by topics, such as History, Geography, etc. — and within each topical group subgroups such as ‘Overview’, ‘Goals for the Semester’, ‘Course Outline’ and ‘References’. That organizational structure makes sense to the teacher, and it causes no problems for DEVONthink’s Classify feature in suggesting appropriate locations as new content is added.
But in the Tags view, each such group is repeated multiple times in the list. Yes, that’s confusing. But simply to ‘meld’ those subgroup tags by listing only one and combining all the contents of groups with the same names doesn’t appear very useful, especially for a group tag such as ‘References’, where the context of the enclosing group is important.
Perhaps another approach to simplifying the list of group tags might be to display only a single group tag for multiple instances, but to ‘split it up’ if that tag is clicked, in such a way that context could be retained.
Of course, there’s a second kind of tag — user-created and imported OpenMeta tags — where one should avoid using the same name multiple times. This is the kind of tag that I think you have in mind. In the final release of DEVONthink 2.0 one can choose, in Database Properties, to exclude ‘group tags’ from view for that database. Here, a tag such as ‘Paris’ can be applied to any item you choose, perhaps in conjunction with one or more other tags. If you are studying the sewers of major cities, for example, items about the famous sewers of Paris could have the tags ‘Paris’ and ‘sewer’ attached. This would be totally independent of the locations of items in the database’s organizational structure.
But I don’t understand the point of the Tag view showing, say, six tags called “References” if that context is completely lost in that view. Is there currently some way to view the hierarchy of those multiple tags?
I had a similar issue with the concept of groups and tags being so intertwined and made a request that the grey groups be turned off should be possible on a per database basis, so that only my blue tags would show up.
It’s in DevonThink final 2.0!!
Thank you and many thanks for the incredibly hard work and long road to 2.0, company requisition goes through on Monday, sold!
Another vote for changing how regular group (gray) tags are handled in View as Tags. It is just plain wrong now.
Selecting several duplicate tags in the sidebar should display a combined total of records with that tag. Not no records as occurs now in View as Tags, but a combined total as occurs when using a Smart Group selecting for the tag.
The point of tags is to not search on one and expect to get just what you want (unless the search is very focused). If someone is doing a search on the tag “References”, then they would also include other tags to perform a narrower search. That’s generally how tags are used. If I do a search on “Goals for the semester” and I’m disappointed that I get all kinds of goals (for that computer organization class, for my research, for student learning goals in my software design course), then it’s my fault for not including other tags in the search.
The way you describe the hierarchical tags and the fact that users want several tags of the same name to perform a search makes the tag structure no different than a folder hierarchy. Why bother? I still contend that the use of tags by Devon is a departure from the general meaning and use of tags. Tags define sets. Multiple tag searches perform an intersection. If you do that with folders in different subtrees, the result is empty. With tags, there is no tree structure, and the result is exactly what you would expect it to be.
To most of us tags are not hierarchical. If we want hierarchy we get it by selecting multiple tags.
But View as Tags now displays same-name “different” tags based on their hierarchy. Listing these same-name tags separately may be necessary for the tags as groups DT philosophy and for the preferences of some users.
However, for most of us who think that tags are not hierarchical, we still at least expect to see a combined total of records when several of the same-name or different-name tags are selected in the sidebar. Not a blank “No Selection”.
As DEVONthink works now, is there not a view that gives each camp the results that they are looking for in tag selection? Selecting multiple tag groups in the Three Panes view gives the combined total of records (TagA OR TagB OR Tag…). Selecting multiple tag groups in the Tags view filters the list to the records that contain all selected tags (TagA AND TagB AND Tag…). I don’t know what most of us think about the expectations are of how tags should work, but there appears to be an option for everyone as is now.
One thing that does puzzle me about the discussion is this-if there is an expectation that tags should not be hierarchical, then why create a hierarchy? Can you not get precisely the structure that you are looking for by turning off tagging (‘File>Database Properties>Exclude Groups From Tagging’) and create all tags in the Tags group? Or use a blended approach, where (using the example above) ‘History’ and ‘Photos’ are groups with tagging enabled and all ‘Paris’ groups have tagging disabled, and for this example there are two documents in each of the 'Paris sub-groups. Create a Tag in the Tags Group named ‘Paris’ and then assign that Tag to each of the ‘Paris’ sub-groups.
Then the Three Pane view will look like this:
Tags (with the tag icon)
Paris (6) (with the tag icon)
Paris (2) (with the blue, non-tag icon)
Paris (2) (with the blue, non-tag icon)
History (x number) (with the blue, non-tag icon)
Paris (2) (with the blue, non-tag icon)
Photos (x number) (with the blue, non-tag icon)
Paris (2) (with the blue, non-tag icon)
The Tag view will look like this:
History (x number)
Paris (4)
Photos (x number)
The Paris tag in the Tags view will give all the items that have been tagged as ‘Paris’, either explicitly by assigning tags or implicitly, by inheriting the tags. Try it-I believe this is the results that you are looking for.
Perhaps I didn’t follow Greg’s last example, it certainly is one way to overcome the problem although in a kludgy way. This approach fast becomes tedious if not downright unworkable when the hierarchy gets very deep with countless repeated tags. Realistically, for very fine-grained tag taxonomies, I’m not convinced this type of mixed hierarchy works.
@Greg_Jones: Am I missing something? How are you selecting multiple tag groups in the Three Panes view?
Regular group (gray) tags are a handy feature. A quick way to tag. A blended approach to tagging seems to add complexity, especially when imported OpenMeta and exported tags are thrown in.
Searches and Smart Groups are practical. They do work as expected for your example of a combined total of records (TagA OR TagB OR Tag…). Also for the AND example.
It is that illogical “as Tags” view.
Is that the place to deal with the subtleties of hierarchical tags? Especially for a new or casual DTPO user. There is no hierarchy displayed in that view and tag selections should reflect the same.
ISo when is the 2.1 slated for with a proper tagging feature ? Hope DT decides to make tags searchable globally using spotlight or 3rd party software with no need to export groups and tags first…which is another restriction that undermines the OpenMeta standard !
@cturner: I spend most of my time in the Three Panes view with Tags showing (at the bottom). And, talking about regular group (gray) tags, what is Shift or Command clicked(!) to view those OR’ed records?
Then “See related tags”? I may be a little dense or have something turned off in my preferences, but I just don’t follow your suggestions.
@cturner: Thanks for the time getting those screen shots and your help. A picture is worth a 1000 words.
I was aware of the ORed selection of ordinary (blue) tags appearing in the Tags Group of the Three Panes view, but my question had been about regular group (gray) tags – those tags that also appear along the bottom with Tags showing and in the sidebar of the Tags view.
Over 80% of my tags originate from Groups or match Group names and are my main concern. The way ordinary (blue) tags work is not a concern and seems fine except for the ANDed philosophy of the Tags view sidebar.
Related tags may be useful but right now is a little dangerous for group (gray) tags. It quickly creates a new replicate entry in the Group representing the tag. “Related Tags” does not mean adding tags or replicating entries to me.
)
