Purpose of Tags Vs Group?

New user trying to sort out the value of tagging vs groups.

Background:

I have primarily indexed my database in groups based on my existing folder/file structure that is on my computer. (FYI all my groups are represented by blue folder icons and cannot find the “exclude tags command”).

Here is my understanding of Groups:

Groups are broad subject headings where you place files under that subject. Accordingly you can further refine the structure by adding sub groups. For instance in my database I have the follow group structure:

Forestry>Fires>Fire 0123. Now I can file documents under each of these groups depending on how specific they are. Accordingly I can search them this way.

Here is my understanding of Tags:

I thought that Tags would act like key words that you can assign to specific documents for further refinement of a search. So in reference to my group structure above, I could file a document entitled “fire 0123 meeting notes” under Forestry>Fires>Fire 0123. But rather than simply search for all files related to group Fire 0123, I could Tag my document with the term “meeting notes” in order to filter out all other unrelated documents within group Fire 0123 in my search.

Is this the function of Tags?

PS. I did a forum search but I have found is the typical “Tags are the same of as a Groups” which if the case hardly seems to make sense.

1 Like

Like this smart group?

In File > Database Properties … > [name of database]

Or in the contextual menu for a given group

Note: blue-icon groups are groups that are excluded from tagging. What “excluded” means is that if you add a tag that has the name of an existing group, a replicant of the tagged document is not added to that group. See the Manual.

Thank you Korm, and so my understanding of Tags and their use was accurate then?

Thanks for the database properties tip, that was why I could not find this command in the context menu, which was what was in the help section I was reading.

Let’s say yes. The thing is, tags and group are both free-form taxonomies that mean whatever you want them to mean. There’s absolutely no “right” way. If your system works for you, go for it. 8)

Hi, Tobruk.

You aren’t going to like this answer but as far as I can tell, the difference between tags and groups is anything that you’d liike it to be. You can treat them as two classes of the same thing with any division between the two you’d like to make.

In my case this is a complex question having to do with what I consider to be a “group”. When you autoclassify something in DT, the program suggests groups. So “group” is defined (for me) as anything that you could reasonably expect DT to autoclassify based upon content. For instance, the program would likely suggest that a letter to “Greg Smith” would be classified into the “Greg Smith” group because it would pick up his name in the file.

In my world, a “tag” is anything that DT wouldn’t usually autoclassify. For instance, DT wouldn’t suggest that I put an email into a “Correspondence” group based upon the kind of file it is. So “Correspondence” is a tag (which also classifies things like Word files, scanned letters, etc…).

I have probably about 25 or so of these tags (the list is growing). Because I can never remember exactly what I named them, I need to be able to easily find them in the “Tags” group. So I use groups which are excluded from tagging to containg them and make them easier to hunt down.

Tom S.

LoL!

I find that just crazy but I can work with it :open_mouth:

I guess I’m just worried about creating an incomprehensible nightmare of a database that will cease to function in the manner that DevonThink proclaims.

This is a brilliant post (the whole post, not just this sentence). Thank you!

I have just returned to DT after an initially completely frustrating attempt to understand tags and groups (as well as other issues). I was driven to DT by the morass of research material that I have accumulated for a book. With no practical guidance from Devon and no cookbook available, and despite the wealth of information from Forum participants (which, sorry, seemed to me awfully hard to follow), I had to just dive in and try to make sense of tags and groups.

Here is what I’ve come up with so far in terms of organizing my information, and my initial understanding of groups and tags. I hope this helps, and I welcome comments about my thinking and implementation, and corrections to same, as I am still (like the OP) struggling to learn.

First, my goal: get my research “under control,” such that I have all my documents organized for retrieval; and also organized for complex relationships among them, and for discovery of not-obvious information contained in the documents.

Let’s say that my database is about car sales, and that I have a folder structure on my Mac that looks like this:

Cars

  • Manufacturers
    – Ford
    — [ documents ]
    –Toyota
    — [ documents ]
  • Markets
    – Domestic
    — [ documents ]
    – Foreign
    — [ documents ]
  • Tech
    – Electric
    — [ documents ]
    – Internal Combustion
    — [ documents ]

Goal #1: Initial organization for retrieval of documents

Like you, I had an existing folder structure. I created this structure in a DT database, with a Group for each folder. In File-Database Properties, I made sure that “Exclude Groups from Tagging” was turned off, because I wanted to enable auto-tagging of documents, as a way of automatically classifying documents as I add them into the hierarchy.

As I added documents and Groups, I saw that some documents could belong to more than one Group, for example:

  • “2011 U. S. Automobile Market Segmentation Analysis” – discusses “Manufacturer-Ford,” and “Manufacturer-Toyota” (because Toyotas are sold in the U. S.), and “Market-Domestic”

So, I put the document into a relevant Group, and replicated it, so that it appears in the Groups: “Manufacturer-Ford,” “Manufacturer-Toyota,” and “Market-Domestic.”

Because I had enabled auto-tagging, these replicated documents inherited the new tags of the replicants. This document appears in all of these very relevant Groups, and in these Tags in the “as Tags” view. And, as I move documents around from Group to Group, their tags are automatically updated.

Result:

This organized my research for retrieval:

  • Documents are assigned into as many Groups as makes sense.
  • I can browse the Group hierarchy (and do DT full-text searches).

Observations:

In my database’s sidebar (in “Three Panes” View), there is a “Tags” Group, which shows 0 tags. I’ll get back to this in the section “Goal #2,” below.

If I select “as Tags” from the View menu, the hierarchy disappears, and is replaced by a flat, alphabetized list of all of the tags in use. At this point, this is just an alternative view of the Groups.

At this point, “Groups” and “Tags” represent the same thing: the Group hierarchy.


Goal #2: Organize documents for complex relationships among them, and discovery of not-obvious information

Let’s say that the “2011 U. S. Automobile Market Segmentation Analysis” also discusses how designs of cars change over time. This has nothing directly to do with Manufacturers, Markets, or Tech, at least so far, given the information in the database. (This determination is based upon context, and purpose, of the database and its hierarchies.)

But, all Manufacturers must be attentive to design, and design affects Markets, and influences, and is influenced by, Tech. How can I represent this cross-category, complex relationship?

I could create a new Group named “Design,” place the document into this Group, and replicate the document into each additional relevant Group. A lot of work to create and maintain these relationships, and not much better than messing about with files, folders, and aliases in Finder. This approach attempts to use hierarchically-oriented tools to manage an cross-hierarchy relationship.

Instead, I will use what I will term a “stand-alone” Tag. I place the document into any one relevant Group, and create a new “stand-alone” Tag named “Design,” and assign it to the document, by using the Tag Bar.

As I accumulate more research, I may find more documents that concern Design, from a specific perspective, such as:

  • a press release titled “Ford Announces 2012 Designs” – deals with “Manufacturers-Ford” and “Tech" – and “Design”

  • “Design Trends In American Autos 1950 - 2000” – deals with “Market-Domestic” and “Manufacturers-Ford” – and “Design”

  • “Vehicle Psychology 101: How Luxury Design Drives The Asian Vehicle Market” – deals with “Markets-Foreign” and “Manufacturers-Toyota”-- and “Design”

  • “Are SUV-based Vehicle Designs A World-wide Fad?” – deals with every category so far defined – and “Design”

So, rather than creating a separate Group named “Design,” I will instead file these documents in a Group that I believe best represents their primary theme (and perhaps create Replicants in other Groups) and use the “stand-alone” Tag named “Design” to keep track of Design-related information across the database.

Result:

In Step #1, I created a Group hierarchy for information that can be organized in this way.

In step #2, I have created a “stand-alone” Tag to relate documents by a theme that cuts across the hierarchy.

By examining DT’s “Classify” and “See Also” suggestions, I can consider not-obvious relationships between documents. (At least, in theory: I doubt much would be revealed in such a small database.)


Managing the database

If I look at the database’s “Tags” category while in the “Three Panes” View, I see there is one tag: “Design.” This tag appears here because I am looking at a hierarchy. There is no Group that I have created for this tag, so the Tag appears in the Tag Group.

If I now switch to the “as Tags” View, the “Design” tag appears in the flattened alphabetized list, because these are all tags.

However, the “Design” tag is colored differently than tags that are the result of Group assignment, so that I understand that it is not associated with a Group.

Now, let’s say that for some reason, I want to convert all of the documents that have been tagged with “Design” into an actual Group. This is easily done:

  1. Create a Group named “Design”

  2. Find all of the documents tagged with “Design,” either by using the Tags Group, or the “as Tags” View

  3. Replicate these documents into the “Design” Group. Since we enabled auto-tagging, these documents will be tagged with the Group’s name: “Design,” colored a darker blue that the “stand-alone” Tag of the same name.

  4. In “Three Panes” View, delete the light blue “Design” tag. The only things deleted are the stand-alone Tag, and the Replicants of documents that are assigned the stand-alone Tag. The documents have effectively been moved form a stand-alone Tag into an auto-tagged Group.


This is how I’ve come to think of the question of Groups and Tags. I hope my example is clear, and that it helps to illustrate one use of Groups and “stand-alone” Tags as distinct entities. There are doubtless many other ways to use (and consider, understand, and implement) Groups and Tags.

But I believe that the claim of Tags and Groups as “being the same” is a facile notion. There is much subtlety in the topic.

2 Likes

Beautifully put. Many thanks!

Thank you Shoolie, this is very helpful :smiley:

Very nice use case, Shoolie – very interesting reading, too. :stuck_out_tongue:

I believe that the “tags are groups” statements you’ll find frequently in the forum refer merely to the mechanics of implementing tags in DEVONthink, not to their use from a taxonomic, logical, or classification basis. As your write up (and Tobruk’s and others, above) demonstrates well, the mechanics are not what matters – it is what you do with the feature that matters.

Thanks Shoolie for the effort you put into your post. I believe that it really captures the diversity and potential role(s) that tags can play.

Your example is the clearest explanation that I have read and the concept of the “stand alone” tag is what I intuitively understood tags to be: an intermediary classification that provides a bridge between groups designations and the file itself…if that makes sense.

Thank you for your kind compliments.

Yes, that does make sense. I too have discovered this use of tags as (if I understand your point correctly) a way of temporarily classifying items, or a way to provide some other dimension to Group classification (if that makes sense!). But, my discovery was through trial and error, and hardly intuitive.

Which again brings me to the notion of tags and groups as “the same” as, if not incorrect, then greatly oversimplified.

I’m not sure that I understand, korm: the actual steps to assign groups and tags to items can be different, and it is possible for items to have:

  • group assignments, but no tags, or
  • group assignments, and tags, or
  • no group assignments and tags.

And, here, the similarity of groups and tags is, if not destroyed, then at least confused. When would I use one and not the other, or use both? What are the consequences (upon classification, importing items, exporting items, …) of these different uses of groups and tags?

Groups and tags are metadata, of course. But, items also have other metadata that is accessible from the Tools-Show Properties command. How does this metadata intersect with groups and tags? What should I consider when using groups, tags, and document metadata? How does DT’s artificial intelligence consider all of this metadata? What are the pros and cons of using each kind? Is some metadata used only for search and retrieval, and not for classification? What is retained, or converted, if I index documents, or import documents, or export documents? How can I convert one kind of metadata to another? When does it make sense to do so? Why is there no unified view of all of an item’s metadata?

I can’t make any sense of the different kinds of metadata, and I can’t find a concise explanation of why to use each kind. I do know that groups and tags can be manipulated with AppleScript, but document-level metadata cannot. What other limitations exist among these different sets of metadata, and why do limitations exist?

Perhaps more information is somewhere in the DT manuals, but this topic deserves a thorough explanation, rather than piecemeal mention of features each set of metadata might or might not provide.

And, statements such as “DEVONthink Pro Office treats groups as tags and tags as groups” in the DTPO manual do not help me unravel what all this metadata does, and how each kind is regarded by DT. As far as I can determine, there is only one scenario where groups and tags are “the same”: when there are only Groups used in a database, and no “stand-alone” tags are in use, DT presents Groups as Tags, and Tags as Groups. But, this case is contradictory: how can two things be the same when only one exists?

OTOH if some explanation does exist, please point me to it! (And, thanks in advance!)

I very much appreciate all input (especially from the developers of DT).

Many thanks.

1 Like

Whoa Shoolie you are in deep!

Many good questions, some of which I fear are going over my head but I am anxious to hear if there are answers, particularly the relationship between tags, groups and metadata.

Excellent Questions and I’m sorry to see that they haven’t been addressed in the months since Shoolie’s post.
Most of all I would have liked to see an answer for

More specifically: are tags and groups treated differently by the AI mechanism that suggests groups for filing? And if so, how?

See below

Tags are, by default, excluded from classification (filing) while all groups have, by default, classification enabled. Tags, as well as Groups, that have ‘Exclude from…>Classification’ checked will not appear in the AI mechanism that suggests groups for filing.

** Edited to add-my experience when testing is that Tags will never appear in the Classify list, even if a Tag has ‘Exclude from…>Classification’ unchecked.

Greg’s response is correct.

Remember that the Classify and Auto Classify AI assistants operate by attempting to find commonalities among the contextual relationships of the content (only) of documents contained in each group that contains documents, and compares such commonalities to the contextual relationships in the content (only) of a document being viewed.

It must be emphasized that these assistants look only at document content, whether as characteristics of a group or in the specific document being viewed. Other information about documents, such as Name, Size, Kind, dates (Added, Creation, Modified), Document Properties metadata, etc. are NOT evaluated.

With respect to the text content of documents, DEVONthink “looks” at terms used, and their relative frequencies of use. That’s what “contextual relationships” are.

Suppose I have a database that holds scientific papers about two topics, astronomy and ecology, and have created two groups that hold papers about each topic. Classify will quickly “learn” the differences of the terms used in each discipline and their relative frequencies, so that when I add a new paper about one of those topics to my collection and ask advice from Classify, the probability that it will suggest the appropriate group into which that new paper should be filed will be high.

But suppose I have another database that’s not organized by topic, but, for example, holds groups for each of my clients. Each client’s group may hold a variety of documents about various things, such as items purchased, invoices and receipts, letters about various topics, etc. In this case, DEVONthink will be much less likely to “see” distinctions of the contextual relationships among these groups that would enable it to correctly recommend the group into which a complaint from John Doe should be filed. And in this case, especially if I wish to keep track of all the complaints received, I might decide to create a new Tag for Complaints, and apply that tag to this item. Alternatively, I might have created a separate group for Complaints. But because my customers may express themselves so differently in writing complaints, Classify might have difficulty in recommending replication to both the client’s group and the Complaints group when a complaint is received; manual filing by client name plus applying the Tag will work better.

Thanks for the replies, and excuse me but what perhaps seems obvious to veterans is still pretty opaque to some of us.
We keep reading that tags and groups are essentially the same, but if I understand you rightly, the A.I. will either assign or suggest a group based on contents, but it will not do the same for tags. If that’s the case it’s a huge functional difference that could cause - for me at least - no small confusion.

I might, for instance, have reasonably believed that it makes sense to

  1. use Groups for functional purposes - for separate projects, document types, or different time frames (current, longTerm, archives etc.) and
  2. use Tags for topics (e.g. rhetoric, theatre, Artificial_Intelligence).
    But if the AI assigns by lexical content to groups but not tags - then the exact opposite strategy would make more sense i.e. using groups for topics and tags for function.

Maybe I’m dim but I’ve had DT for years - though my usage has certainly been sporadic - and I still don’t grok whether this difference between tags and groups is real or illusory. And if they are basically the same - as everyone says - why don’t tags show up in the “classify” sidebar?

And while I’m at it - does anyone know why the same database would display differently on 2 different computers. For some reason on my Imac the dtbase in question - which is stored and synced in Dropbox - shows groups that are included in classification as blue folders with a tag symbol next to them while on my MBAir, the same groups show up as yellow folders without the tag symbol while excluded groups show up as blue folders. I’ve searched high and low for some pref that might dictate folder appearance but I can’t find it.

Thanks again to all.

Just responding to the DropBox comment… We strongly advise against storing your DEVONthink database in a DropBox folder. DropBox is not built to sync our databases and can lead to data loss and database damage. The forthcoming Sync plugin will allow for proper syncing through DropBox.