Best Tag Naming format: Embedded Hierarchy or Separate Tags?

DEVONthink Tips
1

Hi there,

I am a new user of DT 2 and now DT 3 Beta, although I’ve been a “lurker” for a while, learning about it off and on for years until recently taking the plunge.

I have a question for you all about tags. Specifically, the best practice way to create and name Tags. I am torn between creating long tags with embedded hierarchy and using multiple tags. When I was using Microsoft Outlook’s categories in Windows, in combination with a third party add-on called SimplyTag, I used the embedded hierarchy option. It worked well with the way Microsoft Exchange categories were represented in Outlook. Now, using Apple Mail, MailTags, and DT, I’m not certain which option is the best.

Here is a concrete example: let’s say that I’m working on a product called “Great App”. Great App has a feature called, “Save Profile”. Here is how the options would look:

  • Embedded Hierarchy Option: “Prod - Great App - Feature - Save Profile”
  • Separate Tags: “Product”, “Great App”, “Feature”, “Save Profile”

I would like to use these tags in concert with MailTags in Apple Mail, connected to a corporate Google Gmail account, to import them automatically for archived email. In Gmail, folders are merely labels (tags) that are nested within one another. However, MailTags imports a nested folder of many tags as “Product/Great App/Feature/Save Profile”; one tag with slashes between the different folder levels. As such, they will get sucked into DT as a flat structure, with no respect to any hierarchy of tags in DT that’s already set up.

Based on all of this, do any of you have any opinions on which way to go for my tag naming convention?

Thank you all very much for your time and assistance!

Best Regards,
Eric

2

There is no definite answer on this and there are plenty of opinions on the matter. Check out some of our thoughts in the built-in Help > Documentation > Getting Started > Tagging, especially note after the Nested Tags subsection.

3

Interesting…I read it and I think I like the flat hierarchy. However, I still cannot decide between “simple tags” and “complex tags”.

Example of a simple tag list:

  • Product
  • Great App
  • Original App
  • Feature
  • Save Profile
  • iCloud Synch

Example of a “complex tag” list:

  • Product
  • Prod - Great App
  • Prod - Original App
  • Feature
  • Feature - Save Profile
  • Feature - iCloud Synch
  • Prod - Great App - Feature - Save Profile
  • Prod - Great App - Feature - iCloud Synch
  • Prod - Original App - Feature - Save Profile
  • Prod - Original App - Feature - iCloud Synch

Simple Tag List
In this case, I would need to use filters and searching to look for specific intersections of topics (e.g. all items that relate to both the concept of Saving Profiles in general would be tagged with “Feature” and “Save Profile”, whereas those items relating to the saving of profiles in Great App would be tagged with “Product”, “Great App”, “Feature”, “Save Profile”). As such, in the latter case, I would need to search for four tags simultaneously. I would imagine that finding things in this scenario would require more complex searching with both “AND”, “NOT”, and “OR” clauses in the search.

Complex Tag List
In this case, I am using more descriptive tags, where I could, theoretically just search for a single tag to get the same effect, however, I would also need to tag data objects with multiple tags to accommodate that a document could be about not just Saving Profiles in Great App, but also tangentially related to the generic concept of saving profiles. For example, all items related to the general concept of a product that saves profiles would be tagged with “Product”, “Feature”, and “Feature - Save Profile”. Conversely, anything that deals with the specific subset of Saving Profiles for Great App would be tagged with, “Product”, “Prod - Great App”, “Feature - Save Profile”, and “Prod - Great App - Feature - Save Profile”. That way, when I do searching for the specific feature items for Great App Saving of Profiles, I would merely search for “Prod - Great App - Feature - Save Profile”, but if I wanted to search for things that were both about Great App Saving of Profiles and also relating to Saving of Profiles in General, I would look for “Prod - Great App - Feature - Save Profile” and “Feature - Save Profile”.

Which is easier / more manageable over the long term? Which makes it easier to find things?

I know that, without nested tags, using descriptive, complex tags allows for me to more easily find related tags in a tag list sorted alphabetically. However, I’m also looking at how I can not just effectively manage the tags themselves, but use them effectively.

Thoughts? :slight_smile:

Thank you again for your help!

Best Regards,
Eric

4

Simpler is better over the long run. All that your “complex tags” accomplish is embedding the results of a specific search predicate into the tags. It’s better, IMO, to stick to one-term tags to the extent possible. Use the search syntax to look for conjunctions, rather than trying to anticipate conjunctions and embedding them into the tagging scheme, which limits your options.

5

It’s apparent each complex Tag here isn’t truly unique. They are just intersections of simpler tags. Also, the complex tags are just mimicking a tag hierarchy. However, nested tags would be a bad idea in your example as there would be duplicate tags.

I would agree with @korm here. Just use simple tags and the meaning of each is decided by the context of other tags used on specific files.

6

Interesting. If I go with “simple” tags, in practice, that would mean that each tag, by itself, is effectively meaningless. Only when combined in a search or filter with multiple other tags would it make sense. For example, let’s say I have this:

  • Product
  • Release Planning
  • Great App
  • Old App
  • Version 1.1
  • Marketing

If I clicked on the Version 1.1 tag by itself, it would show my the hundreds of documents that corresponded to version 1.1 in both Great App and Old App, both related to release planning and related to marketing. To show the release planning documents related to the 1.1 release of Great App, I would need to create a filter view that would have multiple tags: “Release Planning”, “Version 1.1”, and “Great App”. If I was OK with hundreds of saved filters and views, then I could use those to find the specific documents that I’m looking for - I could even pre-build the filters.

However, if I didn’t want to create a view/filter each time I was looking for something specific, it would take longer to find those specific documents than it would in a hierarchical structure with complex tags, where I would just merely click into the tag and instantly the documents would be there.

Here’s how it would look in the hierarchical, complex tag structure:

  • Product
    – Prod - Great App
    -> Prod - Great App - v1.0
    -> -> Prod - Great App - v1.0 - Release Planning
    -> -> Prod - Great App - v1.0 - Marketing
    -> Prod - Great App - v1.1
    -> -> Prod - Great App - v1.1 - Release Planning
    – Prod - Old App
    -> Prod - Old App - v1.0
    -> -> Prod - Old App - v1.0 - Release Planning
    -> -> Prod - Old App - v1.0 - Marketing
  • Release Planning
  • Marketing
    … etc

By using complex tags, I eliminate the possibility of duplicate tags. By using hierarchical tags, it allows me to find the tags themselves easier through clicking and scrolling. With the above model, I also have a means to signify those items that apply to Release Planning or Marketing across all releases, but are not version-specific.

This method front-loads the work of finding data into the act of tag creation, whereas the “simple” tags method requires a heavier back-end investment in filter creation.

Given all of that, one might think I’m too invested in the complex model to consider another method. Truly though, I am not; I’m just trying to avoid the work of creating what I can envision as a ton of filters and enabling easy selection of documents meeting specific criteria through scrolling and clicking only - no filter creation: the lazy way of searching. :wink:

Can you all think of any other way to:

  1. Limit the number of filters that are needed for specific document types
  2. Allow for the finding of these documents through easy mouse movement, scrolling, clicking, etc.

Thank you all very much for your continued advice and assistance!

Best Regards,
Eric

7

that would mean that each tag, by itself, is effectively meaningless.

I would strongly disagree with this assessment. Tags always have their own meaning but also gain more specificity of meaning in context.

Imagine a tag of bright. That is a tag that clearly has meaning, as any attribute does.
Now imagine these two contexts:
Lighting > bright
Student > Sally > bright.

image
image2168×1534 349 KB

The contextual difference do not negate the meaning of the singular tag. It is just that the tag gains meaning relative to the other applied tags.
Also, searching for bright suffers no great productivity loss as subsequent tags searched for can quickly exclude unrelated tags.

And this is also a good example where bright would not be a good idea as a hierarchical tag.

8

An easy way for ur migration is to adopt the same structure as you described in the first post? Use groups or tagging group (tagging group is a group but also will be shown as a grey-colour tag) to mimic ur Outlook’s categories, and use tags in DT3 to mimic you hierarchy in SimplyTag. Unless you plan to re-organise ur way of classification.

9

I’m getting a little lost here – the problem statement seems to be rather very fluid. What does filtering document types have to do with tag taxonomy? Or with moving the mouse?

You might want to look at a helper app called Ammonite.

10

I get where you’re coming from. Tags can get more specific in context of other tags. However, in this example, the word “bright” in the context of the other tag, “lighting” implies that the level of ambient brightness in the photo is high. However, in the context of the other two tags, “student”, and “Joe” or “Sally”, it implies a level of intelligence.

In this case, if I may be frank, bright is a poor example of the concept as it has multiple, different, and opposing meanings depending on the context. If we wanted this to be an effective example in my usage, I would not use the tag of “bright”.

I would rather use two separate tags to convey the unique meanings of bright. For example, instead of bright as it relates to lighting, I would use one tag, e.g. “high luminosity”, or perhaps merely, “bright lighting”. In the context of a person, I would say, “high intelligence” instead of “bright”. Thus a document that has something to do with Sally the student’s level of intelligence would have three tags still, “Sally”, “Student”, “High Intelligence”. If it was a photo of Sally the student that was about her high intelligence and had a high luminosity level in the photo itself, I would use, “Sally”, “Student”, “High Intelligence”, “High Luminosity”, and perhaps another tag, “Photo”.

11

It’s understandable I think to get into a muddle over this. I use tags extensively. But until i read this i wasn’t aware of hierarchical or nested tags. Apparently i use flat tags. As for permutations, why not use numbers and abbreviate? Unless others using your database, I should’ve thought you can remember what abbreviations you are using.

For example, 4 tags could be abbreviated as tag P4. And so on. As an aide memoire you could create a rtf file and note the meanings of the abbreviated tags foe example:

  • Product = P
  • Prod - Great App = PGA
  • Prod - Original App = POA
  • Feature = F
  • Feature - Save Profile = FSP
  • Feature - iCloud Synch = FIS
  • Prod - Great App - Feature - Save Profile - = P4
  • Prod - Great App - Feature - iCloud Synch = P3
  • Prod - Original App - Feature - Save Profile = P2
  • Prod - Original App - Feature - iCloud Synch = P1
12

Hi Korm,

They are related in that if you have a smaller, simple set of tags, you’ll need to pair that with a large number of highly complex filters to get the effect of having a larger set of complex tags.

Simple Tags
Per my previous example, let’s say I had a tag set that looked like this:

  • Product
  • Release Planning
  • Great App
  • Old App
  • Version 1.1
  • Marketing

To find all of the documents specifically related to the marketing efforts for the release of version 1.1 of Great App, I would need to create a search filter either manually or ahead of time that used these tags: “Marketing” AND “Great App” AND “Version 1.1”. Then, if I needed to find the documents related to release planning of version 1.1 of Great App, I would need these tags in yet another filter set: “Release Planning” AND “Great App” AND “Version 1.1”.

Complex Tags
However, let’s say I had a tag set that looked like this:

  • Product
    – Prod - Great App
    -> Prod - Great App - v1.0
    -> -> Prod - Great App - v1.0 - Release Planning
    -> -> Prod - Great App - v1.0 - Marketing
    -> Prod - Great App - v1.1
    -> -> Prod - Great App - v1.1 - Release Planning
    – Prod - Old App
    -> Prod - Old App - v1.0
    -> -> Prod - Old App - v1.0 - Release Planning
    -> -> Prod - Old App - v1.0 - Marketing
  • Release Planning
  • Marketing

In this case, I wouldn’t need to create a filter set for any one of those, I would merely scroll down in the tag list until I saw the hierarchy of Product->Great App->1.1, and then click on the tag “Prod - Great App - v1.1 - Release Planning”. Three clicks and done, vs. creating a filter for that request and/or having to browse through hundreds of filters that were already pre-created.

13

The point isn’t the efficacy of the tag I suggested and its alternatives. The point is to show that tags aren’t "meaningless " (your words) because they’re simple terms. It was to show the context can clarify their meaning.

Also, why don’t you just use a structure and work with it? You’ll find out soon enough if it actually works for you, i.e., your method is your method, not necessarily anyone else’s.

14

I think you are trying to merge different information architectural concepts into one structure. Why would you need to recreate the complete hierarchy with tags? This only would make sense if you were restricted to use a flat unstructured database. Why not just use groups/folders for the hierarchy and tags for the semantics?

PS: You might want to have a look at LATCH (https://parsonsdesign4.wordpress.com/resources/latch-methods-of-organization/) in order to clarify the concepts by which you are organising your data.

1 Like