Tags: Multiple Systems or Expanding Area? (in Obsidian)

[ontologist]

Hi everyone,

I’m organizing my tags based on the Johnny Decimal system and considering two approaches. I use Obsidian for index keeping, with indices in a single folder (00.00) and the TagFolder plugin to display tags as a folder tree (as shown below).

Here are my two options:

1. Expand within JD: Use area 90-99 for tags, e.g., 9CS.ID. Here, C = category (Actionable, Contexts, Agents, etc.), and S = sub-category (Status, Sensitivity, Location, etc.).

2. Separate System: Create a second system, e.g., TAG.AC.ID, where 912.42 maps to TAG.12.42.

Would you recommend sticking to a single JD system (Option 1) or creating a separate tagging system (Option 2)?

Thanks for your advice!

[johnnydecimal (John Noble)]

This looks interesting.

I am right down the line on this one. 50/50, I’m really having a hard time making my mind up.

I don’t think it really matters. Having them as a separate system is really clean because they’re such a different thing. And then you’re not using up that area.

But two systems is two things to manage! I guess if they’re in the same Obsidian vault, the overhead is actually negligible?

Would love to know if anyone else has done anything similar. I’m going to add (in Obsidian) to the title of this post to try to woo the Obsidians.

[ontologist]

Hi Johnny Decimal,

Thank you for your response. Over the past few days, I’ve been exploring various ways to integrate tags seamlessly into the JD system. I’ve now developed a fully detailed approach, which I’ve outlined in the post below. I’d love to hear your thoughts on it, as well as feedback from others in the community.

[ontologist]

A Systematic Approach to Tag Integration in the JD System

Goal

Integrate tags into the Johnny Decimal (JD) system systematically. Each tag index file represents a tag and includes its definition, synonyms, and cross-links. This approach ensures centralized, consistent tag management across systems. It is designed for tools like Obsidian with Tag Wrangler and TagFolder plugins, however can be used with any system that supports nested tags.

---

The Problem

Johnny Noble’s insights inspired me to integrate tags into my JD system (Source 1, 2). Initially, I considered creating a separate system for tags but decided to expand the 90-99 area for this purpose. The challenge was how to structure tags into a JD-compliant hierarchy while ensuring flexibility and clarity.

Initial Attempt: 3-Level System

A 3-level system (9CS.ID) increased organizational depth but violated the JD format (AC.ID). It also encouraged an excessive number of tags (up to 10,000), contradicting the principle of intentional and minimal tagging.

---

The Solution

I restructured the system by splitting tags into two core components:

1. Fundamental Tags: Represent individual concepts or entities, each with its own tag index file. They are children of category-level tags but are not category tags themselves (e.g., 9103_Raindrop under category91_Contexts).
2. Meta Tags: Group and organize tag index files, enabling better management and more precise categorization.

Each Tag Index File is:

• Labeled with its fundamental tag (e.g., 9103_Raindrop).
• Tagged with at least one meta tag, which groups similar fundamental tags.

Tag Formatting

It’s important to note that tags do not include periods (e.g., 9103_Raindrop), while titles of tag index files follow the standard JD format with periods (e.g., 91.03_Raindrop). This distinction arises from Obsidian’s restriction on periods in tag names.

Meta Tags

Meta tags reside in the range 90.00-90.99. They organize and group tags in meaningful ways, with sub-ranges dedicated to specific categories:

• Category-Specific Meta Tags (90.10-90.19, 90.20-90.29, etc.): Group fundamental tags within their categories. For example:
  • 9010_Category-Contexts (general meta tag for fundamental tags of category 91_Contexts).
  • 9011_Locations (groups fundamental tags of 91_Contexts related to locations).
• General Meta Tags (90.00-90.09): Apply system-wide for maintenance or overarching purposes, such as:
  • 9001_Duplicates: Tracks duplicate or redundant tags.
  • 9902_Deprecated: Tracks tags that shouldn’t be used anymore.

The idea of introducing meta tags was originally inspired by the alternative layout to standard zeros (Source 3).

---

How It Works

Example Tag: 90-99_Tags/91_Contexts/9103_Raindrop

The tag index file named 91.03_Raindrop is tagged as follows:

1. Fundamental Tag: 90-99_Tags/91_Contexts/9103_Raindrop.
2. Meta Tag: 90-99_Tags/90_Meta/9011_Locations (groups similar tags under “Locations”).

The tag index file named 91.03_Raindrop:

• Contains definitions, synonyms, and cross-links.
• Is tagged with both 9103_Raindrop and 9011_Locations.

This ensures the tag is both functionally categorized and grouped meaningfully within its category.

Below you can see the tag index file 91.03_Raindrop among other files (In this case non-tag index files) tagged with 90-99_Tags/91_Contexts/9103_Raindrop in the tag folder tree.

Below you can see the tag index file 91.03_Raindrop among other tag index files tagged with meta tag 90-99_Tags/90_Meta/9011_Locations in the tag folder tree. 90-99_Tags/90_Meta/9011_Locations groups similar tags of the 91_Contexts category together.

---

Meta Tag Index Files

Just as every fundamental tag has its own tag index file, you can extend this concept to meta tags as well. A meta tag index file provides additional context or relationships for a meta tag.

To maintain consistency, tag the meta tag index file with its corresponding meta tag. For example, the meta tag index file 90.11_Locations should be tagged with 90-99_Tags/90_Meta/9011_Locations.

Additionally, to create an easy overview of all meta tags, tag every meta tag index file with 9000_Meta-Tags. This practice ensures you can quickly locate and manage all groups of fundamental tags.

---

Key Benefits

1. Centralized Tag Management: Tags are linked to a central index file, ensuring consistent usage and definitions across systems.
2. Flexible Organization: Meta tags allow grouping tags within categories without adding hierarchical complexity.
3. JD Alignment: Maintains JD compliance with a clear AC.ID structure while leveraging meta tags for extended grouping.

---

Conclusion

This system integrates tags into the JD framework using fundamental tags and meta tags. Meta tags organize and group tag index files, while each tag index file is tagged with its own tag and a relevant meta tag. This ensures clarity, scalability, and consistency across systems. While still being tested, this approach provides a robust solution for systematic tag management. I am looking forward to your feedback.

---

Sources

1. Thoughts on Tags
2. Use JD to Organise Your Tags
3. The Standard Zeros

[torbengb (Ben)]

Just seeing how much you have written about this makes my immediate thought appear stronger: less is more.

I use only a single structure for everything and I don’t use tags except for the occasional #todo because it’s already a bit of a chore to adhere to one system - I would hate to have to keep track of two systems!

I’d like to pose this question: Do you really need two systems for your things?

[johnnydecimal (John Noble)]

While I think this is amazing, and 100% think that if this works for you then go for it, I tend to side with @torbengb in that this is too complex for my tastes.

Just yesterday I created my first real tag-as-JD-ID. I’m just playing with this, so don’t take this as a recommendation. Here’s what I did, and even this confused my tiny mind a little bit.

Objective

Create a tag that I can apply to Bear notes that indicates that this note/JDex entry is also a page on the website.

This is the JDex for the website itself, i.e. 01.02 Licence and so on. But then there are some additional entries that aren’t pages. So I wanted to be able to flag that somehow.

‘Solution’

Create a Bear tag. But that tag has to live somewhere, otherwise it’d just clutter my neat sidebar there. So it sits in the JD hierarchy.

Tags feel like they live in 00 Index. So I created a header for them, and a new tag at 00.51.

And now any individual page gets two tags: one that places it in the structure, and this one.

A slight complication

When you select a tag in Bear, by default it shows you all notes that also contain child tags. In this situation I don’t want that for reasons that aren’t really interesting.

So this tag ‘should’ live at

• #D01 Johnny.Decimal website/00-09 Site administration/00 Index/00.51 Entry is a web page#
• but it doesn’t, it lives at
• #D01 Johnny.Decimal website/00-09 Site administration/00.51 Entry is a web page#

which is fine by me. That’s why it isn’t nested in that first screenshot.

But you do you!

@ontologist, I’m not saying I don’t think you should use the system you’ve built. If it works for you, terrific.

But I’d caution others against going down a similarly complex route.

[ontologist]

Comparison of Approaches for Tag Integration in JD

Thank you @johnnydecimal and @torbengb for your input. I agree that simplicity is key, but some complexity may be necessary to meet specific goals. Here’s a concise comparison of different approaches to integrating tags into the Johnny Decimal (JD) system.

Strategic Goal

Integrate tags into the JD system, acknowledging their advantages while leaving implementation open to individual needs.

Operational Goal

Find a concrete method for integrating tags that aligns with personal goals. The table below reflects my own perspective on how I think different systems work, based on Johnny Decimal’s approach and my own.

Criteria	Johnny Decimal’s approach	My approach
Number of tags	Fewer than 100 tags for the whole system.	A few hundred tags.
Organising tags	A simple, flat list of tags.	Tags are categorized and grouped.
Tag index files	No need for tag index files.	Use tag index files to manage additional information.
Synonyms/Keywords	Not necessary.	Use tag index files to track synonyms and establish a primary tag name.
Tags on tags, meta tags	Not necessary.	Each tag is linked to a unique tag index file. These index files can list other tags as metadata, establishing relationships between tags (e.g., grouping similar tags, or noting dependencies).
Scope	Tags are primarily used in one location.	Tags span multiple locations, with index files tracking their usage.

Conclusion

Choosing how to integrate tags into JD depends on your personal needs and complexity tolerance. Simpler systems may work for most, while a minority might benefit from advanced methods. Sharing best practices in this forum could eventually lead to official guidelines on tag integration.

Looking forward to more ideas and discussions!