Catalogs - Obsidian October

Plugins ideas
1

While wishfully, I would have loved to make this plugin for Obsidian October, neither my programming skills or availability as a grad student are up to the task of making this happen, so I present it to the community in the hope that it inspires some productive discourse!

Catalogs

The Framework-Fluid Facsimile of Folders

Static folders aren’t conducive to organizing content and knowledge that spans multiple topics, nor do they foster interconnectivity. To remedy this, Zotero, GMail, XYPlorer, and Windows all got something right: adopting a system that can house objects in multiple “places” at the same time. While looking very similar to folders, these programs’ catalog systems allow for dynamic aggregation of resources across domains, and centralization of resources in multiple ways to provide different ways of viewing the same information.

  • Zotero: Collections
  • GMail: Labels
  • XYPlorer: Catalogs
  • Windows: Libraries

With this in mind, I propose a plugin that introduces Catalogs to the Obsidian ecosystem. These Catalogs act partially like folders, in that they can be navigated using their own tree-style navigation pane, however Notes and files (objects) can be located in any number of them. On the file-level, Catalogs are also simply automatically-updated MOCs which are registered by the plugin as Catalog Notes, which act as spaces of metacognition on the Catalog itself, and store the auto-updating block of Notes and Sub-Catalogs contained.

Acclimation Study

I realize the ideas here aren’t new to the Obsidian Ecosystem, so let me expound on where I think this fits in and what needs it addresses:

In brief, existing core features and plug-ins provide Note-level cataloging capabilities, which fit the desire for Markdown-central flexibility, but have some squeeze points (or friction):

  • MOC’s: Catalogs in Notes, but must be manually created
  • Zoottelkeeper: Automates MOC’s, but for one folder only
  • Tags: Content-level catatloging that suffers from growing pains
  • Dataview: Helps extend tags/remedy tag bloat w/ programmatic aggregation
  • Folder Note: Another useful tool, but on top of a folder structure

Therefore, while content-level (tags) and Note-level (MOC) cataloguing exists, there’s friction when either rapidly building connections between many things (manually editing many MOC’s), or recalling notes or content at a context-level (filtering through a long list of tags). In both cases, a Catalog would greatly help. In fact, I think Catalogs simply marry and extend the existing attempts for automated mapping and management (Zootelkeeper and Folder Note), raising them to the era of linking and fluidity.

Catalog vs MOCs

While for myself, Catalogs would take over much of the value MOCs currently have, they wouldn’t completely replace them. Catalogs aren’t perfectly fluid, as they reside in a static tree structure like folders, so MOCs would still be useful for creating one-off groups of objects, or jumping-off points outside the Catalog structure.

Note+ Example on Catalog Fluidity

The point of Catalogs is to overcome the problem of siloing that happens in Folders. Thus, beyond bringing the ability to link across folders, Catalogs (and the Catalog Note) are also exciting because they allow linking between Catalogs themselves. This addresses a critical failure of highly-structured systems: A/B vs B/A strucutral fragility (This, for example, is the sole reason I’ve failed to adapt the Johnny Decimal System for myself).

Example: Home Insurance

Since Catalogs are simply MOCs on the backend, if you’ve registered Catalog Home/Insurance to an MOC titled Home Insurance, and now think that MOC also belongs under the Catalog Insurance, you can either:

  • Deposit the Note Home Insurance into the Catalog Insurance
    • Cost: New cataloged object (same MOC, new line-item in cataloged object registry)
    • Result: Newly registered item visible under Insurance
  • Register Home Insurance as a Catalog under Insurance/Home
    • Cost: New linked-Catalog (same MOC, same cataloged objects, new line-item in Catalogs registry)
    • Result: Linked Catalog plus linked sub-items visible under Insurance
  • Create a new Catalog Insurance/Home and detail what belongs here versus in [[Home/Insurance]] (with a simple link) (e.g. contracts+invoices versus claims+home inventories respectively)
    • Cost: New Catalog (new MOC, new items, new Catalog)
    • Result: Separate Catalog that can relate to its own objects.

Catalogs vs Tags

Catalogs are like static, object-scope Tags that encourage atomicity. They are static (borrowing from the “extent” definition of static in coding) in that the group is saved and updated in your Vault as part of an MOC. Yes, users can search by tag, and with Dataview, even create static queries, but with the Catalog framework, users can build these groups without having to manually add any additional text (tags or Dataview::tags) to Notes. This also alleviates the lexical burden of tags (where unless you remember exactly what naming scheme you use for a tag, you can end up with duplicate categories intended for the same group), which gets especially frictional (viscous?) with many tags.

Secondly, Catalogs are “object-scope” in that they can be associated with Notes as a whole, and even non-Note files. While users can achieve a Catalog-like hierarchy with tags and sub-tags, this can bloat and confuse a tag system by mixing tags that might apply to a Note itself (Note-scope), or content in Notes (content-scope). This does not encourage atomicity, making it easy to end up adding many tags to a single Note, and hard to find good notes that pertain to the (likely few) tags used per atomic note. Finally, tags can’t be applied to files within a Vault, making it difficult to organize files in your fluid framework if your framework relies on tags.

Added Commands/UI

  • New Catalog Explorer tab (mirrors File Explorer)
  • Drag-and-Drop to add to Catalog
  • Delete from Catalog command (keyboard: Delete upon selection of a Catalog an object resides in)
  • File Deletion Hook: removes deleted file from any Catalogs it belonged to
  • Reveal in Catalogs: Expands Catalog tree and highlights all Catalogs a Note belongs to
  • Backlink Generator Setting/Command: Add/update links to Catalog/Sub-Catalogs a Note belongs to on the first line of content in the Note (setting with input line for customizing formatting)
1 Like
2

I like this idea and would personally find it really useful. I think having catalogs (or collections, if we’re thinking in a similar vein to Zotero) would actually complement MOCs.

I like to think of an MOC as the text version of my mindmaps. It’s a catalogue that has been consciously curated - by dividing items into categories, breaking down different aspects of a concept then linking notes etc. It’s a catalog but one that reflects your thinking process.

Having a ‘collection’ of notes in a given subject area / concept (either one that you plan to turn into an MOC, or one that spans several MOCs) would make it easier to make MOCs because you know where to look for notes and are less likely to have orphans. For example, knowing I need an MOC on ‘postcolonial state-building’ somewhere down the line, I could add notes to that collection. In another use case example, I might add notes to a collection ‘Feminist approaches to theory’ so I can pull notes from there when making an MOC on different approaches to theory in X discipline.

There’s probably a fair bit of overlap between this and feature requests for #multiple-word-tags or the various discussions on what to use tags for. That said, there are plenty of folks who use tags for action reminders/status indicators as well as concepts/ideas, so a collections feature would definitely help keep tag systems organised.

I also don’t know if this is at all possible, but being able to filter by collections as well as tags in Graph View would also be fantastic.

1 Like