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:
-
Create a Group named “Design”
-
Find all of the documents tagged with “Design,” either by using the Tags Group, or the “as Tags” View
-
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.
-
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.