JDex deep-dive: data and storage options

[johnnydecimal (Johnny Noble)]

Another one big enough for its own thread here.

22.00.0182 JDex deep-dive: data and storage options

[njmatch3]

This was useful and helped me understand why descriptions/discussions of nesting and storage in the JD system documentation and this forum are occasionallya little puzzling to me. I use obsidian for my work system, but my JDex and text data is stored in iCloud, whereas all my other work files are stored in my workplace OneDrive and SharePoint sites. This is because I use Obsidian on my iPad as often as on my MacBook and iCloud provides reliable syncing (without paying for Obsidian sync).

Based on this deep-dive I am now increasingly confident that this means I use Obsidian the way JD uses Bear. This is sometimes a little wonky as I have pretty extensive data (“below the line”) in Obsidian/icloud as well as files in my OneDrive so there are sort of two places to look for data/files. But having trained myself to always start with Obsidian, I can very quickly discover whether whatever I might be looking for is my Obsidian vault (stored in iCloud) or my OneDrive. Even more rarely something might be stored in another app (e.g. goodnotes) and my Obsidian JDex alerts me to that too (with locations as an above the line metadata property).

One thing I do is always take the time to create a OneDrive folder any time I make a new ID (or category) in my iCloud JDex. A lot of these are folders empty in my One-Drive. But that means if I for some reason go straight to my OneDrive files and find an empty folder, I know there must be stuff “below the line” in Obsidian that is what I was looking for.

[johnnydecimal (Johnny Noble)]

@njmatch3

Even more rarely something might be stored in another app (e.g. goodnotes) and my Obsidian JDex alerts me to that too (with locations as an above the line metadata property).

Nice. Sometimes I feel a bit silly typing something above-the-line (ATL) essentially like ‘you also have files’. But it helps! It really does.

@njmatch3

One thing I do is always take the time to create a OneDrive folder any time I make a new ID (or category) in my iCloud JDex. A lot of these are folders empty in my One-Drive. But that means if I for some reason go straight to my OneDrive files and find an empty folder, I know there must be stuff “below the line” in Obsidian that is what I was looking for.

Interesting. I’d never thought about it like that. Great idea.

[torbengb (Ben)]

Great article!

I like the ‘partially nested’ approach best, and I realize that my 00.xx is actually my Workflowy structure, with lots of stuff ‘below the line’.

It works incredibly well because Workflowy is made to be so easily searchable. And I use the filesystem for data that does not fit well in Workflowy.

[Tjoenk (Thorbjørn)]

I really like the structured-data approach to defining locations.

My current, home-grown solution has mainly been to use tags—for example #locations/OneDrive—combined with a direct folder link such as

[12.26 Husdrift](file:///[file path]/Husdrift)

(I typically insert these by Ctrl-dragging the folder into the note).

I’ve also chosen to make every ID a folder, because I want to maintain separate notes for each ID inside Obsidian. To support that, I’m using the Folder Notes plugin, where I store the metadata for each ID directly in the folder note.

One question I’m still experimenting with is how to represent the location value itself:

Option 1: Use “OneDrive” as the value

• Simple and stable

• My folder structure doesn’t change often

• Easier to query and build overview tables of locations

Option 2: Use the clickable link as the value

• Immediate one-click navigation to the actual folder

I suspect I may end up using both—keeping “OneDrive” as the structured location value, and then including a direct link to the folder below it for quick access.

[johnnydecimal (Johnny Noble)]

Ooh that’s interesting. I might be tempted to use Location: OneDrive and maybe put the full URL at URL: …?

I’d be interested to know how this shakes out for you.

[shefi1280]

A timely reminder that I need to work on my JDex.

I use Obsidian for both my JDex and my digital content - where stuff is actually stored. The JDex and the JD content folders are both in the same vault, but in separate folders. I spend most of my time in my content folders and so far THEY have been my “index”

So, I started updating my JDex and soon discovered a flaw in my organisation: going back and forth from my JD content folders and my JDex, I soon lost track of where I am in the LH Obsidian side-bar because of course all the JDex notes (I use 1 note per ID) have the same names as the JD content folders. Am I looking at my JDex 10-19 Life Admin or my JD content 10-19 Life Admin? Would appreciate any suggestions as this is creating too much friction and tires me out sooner rather than later in my organising process.

Not using my JDex the way it was designed, not looking at it or updating it when I add notes to my content folders, for instance, I don’t have a workflow. I need a workflow, which I can turn into a routine so that I don’t neglect my JDex.

My priority is to update my JDex so that there is a note in there for each file and folder in my JD content folder. This is going to be a daunting task. Where to start? I’m starting by making sure each NEW note in Obsidian gets indexed. I haven’t started on the backlog. Well, I did start, but soon got bored and fell asleep.

[icy_fox]

As someone finally making a start with using the Life Admin System for real after initially purchasing the course last year, I’d like to understand:

1. Why doesn’t the Above the Line metadata section include one or two fields (key-value pairs) as a standard within every .md file in the JDEX? Such as the below which if unused, they simply don’t get populated:
   Location:
Keywords:

2. Is there a list of recommended optional key-value pairs to include based on lived experience, not listed in this article? Appreciate some of this would depend on category / ID involved. But when it comes to structured data, I’d like to keep to some sort of standard.

Before transferring items and getting stuck into indexing, I want to ensure a solid understanding of the fundamental concepts and any “Best-Practice” where applicable.

[johnnydecimal (Johnny Noble)]

@icy_fox

Why doesn’t the Above the Line metadata section include one or two fields (key-value pairs) as a standard within every .md file in the JDEX?

Ease-of-use for beginners: it’s just one more thing to explain and understand. I’ll be building this sort of thing in as an option in the next iteration of JDHQ.

@icy_fox

Is there a list of recommended optional key-value pairs to include based on lived experience, not listed in this article?

Here’s my internal working document.

---

21.13 Notes theory

Standard properties

• You’re allowed a single > immediately after the title as a one-line description. Freeform.
• Data:
  • Either a link to, or just a note that other data exists.
  • This data might be a file in your filesystem or anything else.
• Location:
  • A location in digital, physical, or any other space.
  • DRAFT standard category 01?
• Note[s]:
  • Just notes.
• URL:
  • A link to a thing online.
• Projects:
  • The 50-59 projects/work packages that this ID contains.
  • Per [[#Linking notes together]] we link from parent to child.
• Related:
  • Links anything to anything else.
• Tags:
  • A ~tag or @tag or what? Still working on this one.

[DavidK]

When I started out I had 2 JDS file systems. I thought one for the desktop computer and one for my Obsidian stuff. But I got rid of the desktop system and just put everything into Obsidian JDS. It was to easy to get confused. Also there would be files on the desktop that I would need on my phone because I would get confused and put the wrong link in Obsidian. I think I’m getting confused now just remembering how it worked.

I would say to get your Index figured out before you start on the backlog.

Just my two cents worth.