JDex Location References

[ontologist]

JDex Location References: Naming and Tagging Strategy

I use JDex codes to identify any kind of relevant locations or objects like 13.17_Outlook or 13.21_Raindrop. This allows referencing e.g., “Look it up in 13.17”.

However, 13.17 can be ambiguous. It may refer to a local folder (with data about the location) instead of an external object or location. To clarify intent, I am considering prefixing such references with L, like L1317 or L-13.17, to clearly signal a external reference to a location.

In Obsidian, I use tags (from a controlled glossary) such as 13_17-Outlook or 13_21-Raindrop. I apply these tags to index notes to record the locations where the index has been applied.

I’m now considering simplifying these to just 13_17, 13_21 for brevity but I am unsure whether fully numerical tags are a good idea.

I appreciate your input if I am overcomplicating things, perhaps I am missing the forest for the trees. I look forward to your thoughts.

[hans]

@ontologist

I apply these tags to index notes to record the locations where the index has been applied.

@ontologist

To clarify intent, I am considering prefixing such references with L, like L1317 or L-13.17, to clearly signal a external reference to a location.

I’m not sure I understand this part of your question. How can Outlook, for example, be an external location? Or are you referring to the question of whether you’re referring to a note in your JDes versus some actual external resource?

[ontologist]

The red-highlighted tags in the JDex note indicate where I have used the index. In the case of 12.13, there is data in 13.11-01_Mac (the file system of the main account of my current working device) and in 13.17_Outlook (emails in my personal Outlook account).

Used on: L1311 indicates that the license was activated on 13.11_Mac (my current working device), and license.location: L1317 means the associated email holding the license key is stored in 13.17_Outlook (my personal Outlook account).

Using 13.11 or 13.17 on their own is potentially ambiguous, as the JDex might also directly refer to folders within Bitwarden.

[Rogfrich]

I’m thinking of those tags as being sort-of-like backlinks from outside Obsidian (which isn’t a thing, hence you having to do it manually with tags). Is that a decent mental model of what you’re doing?

[ontologist]

11.05 The index/JDex

Interesting thought! What I’m doing is following standard metadata practice, for example, recording the locations where the index was used, as suggested by JD. However, in my case, each location has their own JDex. This makes the location unambiguously identifiable, referenceable, and I can store information about them under their JDex folder.

[hans]

Thanks for the screenshots, I understand the context now!

If all the locations you’re referring to exist in the JDex, why not use hyperlinks? e.g.:

---
location: [[13.17 | Outlook ]], [13.11-01 | Macbook 2024]]
---

I don’t know if that’s the correct hyperlink syntax for Obsidian, but the idea is that it will display the human-readable name (Outlook or Macbook 2024) while linking to the URI.

The nature of this relationship is now encoded in the metadata name, location, eliminating the need to add that nature to the tag’s value with the L prefix.

To the question of whether to use just the number, I actually am trying to use just the names these days. I see the numbers’ function mainly in the design and layout of the system. They give you an address space to sort and order your things into, but once you have that, use the human-meaningful names in general day-to-day interaction.

So if you have a controlled vocabulary of tags anyways, the problem for which the numbering system was devised is no longer relevant, use the names of things in that controlled vocabular.

Analogy to street addresses: we don’t say we’re going to go buy ice cream at Main Street 112, we say we’re going to Jerry’s Gelato. We use numbers in the following case: “There’s a new ice cream place in town!” “Oh, what’s the address?”

Likewise in a library, once I’m familiar with the layout, I just walk to the aisle where books on a certain topic are and start looking for the book I want, rather than first looking up the exact URI in the catalog (depends on the size of the collection, of course, but even in large libraries I think I would do this at least 50% of the time).

those are my musings …

[ontologist]

Thank you so much for your highly appreciated suggestions. I immediately implemented two things into my system:

• Attributes including location imply 13.ID to be interpreted as location rather than local folder.

• I ditched tags for locations in favour of links. (The decision for tags was driven my automation concerns.) I also use aliases now.

[hans]

curious to hear how it goes. Ideas can seem perfect, but there are always tradeoffs. But glad to hear this helped you get clarity.

[ontologist]

Here are the cons:

• Less automation (currently)
• The location’s backlinks are mixed: notes linked via locations or due to other reasons are listed together. However, filtering of linked notes by location, e.g. ["locations"], is possible.

I currently think this is an acceptable trade-off tor the gained simplicity and clarity. Thanks again for the help. ^^