Role for MOCs in JD?

On a long-term slog to get all my files into the JD system. I am starting to sense the need for another level of cross-referencing amongst IDs. For example (I am an academic), I might have students (each with their own ID in a category containing students) working on topic A and producing papers (in a category containing papers, each with its own ID) and being funded on sponsored research (in its own category). And perhaps along the way, I will teach a course with material on that topic. This, to me, calls for an MOC (map of content) linking all the relevant IDs (I am using Obsidian for my JD-dex). For the moment, I’ve started a MOC with major headings and links with JD ID 00.02 (reserving 00.01 for my area/category list).

I wonder if others see this approach as valuable - especially in a non-academic context.

I use Logseq, and I’ve had the same thought.

Either to use

#tags

or

Index entry Logseq
property:: property

to reveal connections to other IDs.

This is not relevant for ALL my index, but some parts.

Here’s an example of what it would look like - just to get a feel for it:

Tags
JD-tags-on-IDs

Block-property

Using jdnote:: to add notes to certain ID’s - and then run a query to find all:

JD-block-properties-to-IDs

I’m leaning towards the last one, using the jdnote as block property. Feels cleaner.

After playing around a bit more, I decided to take fuller advantage of the automation capabilities of Obsidian and wikilinks. So when I want to call out a particular topic, I embed the wikilink, e.g., [[SubjectA]] into my ID entry, then click on it and Obsidian will set up the page. And on that entry page for SubjectA, if I show backlinks, it will link to each of the entries using that (and of course also populate the graph view). I also moved the topical link pages to the top of my hierarchy using the folder _CollectedLinks

So no need for manual MOCs!!!

1 Like

I do a mix (in Obsidian) of both automated MOCs (really just a DataView summary of inbound links to an ID) and hand-crafted MOCs for IDs that will benefit from it. This is usually IDs that have a lot of notes associated with them, perhaps with some value in sub-organizing them. The MOCs live in the note corresponding to the ID itself.