Hello all,
Thank you for Obsidian.
TL;DR;
Here’s a simple suggestion for the problem of links in YAML:
- Treat all -almost- YAML scalars as potential labeled links (implicit, without any special link syntax)
- This would include those scalars that are deeply buried within nested YAML structures
This may sound awkward or even stupid at first, but please bare with me…
In a freeform mostly unstructured context (like markdown), we obviously do need a special syntax for links and the like.
In a structured context (like YAML), however, information is already entered and than parsed in small chunks.
Quite often, those chunks refer to other entities (whether they aready exist as an note entry or not).
Most of the time, even things that seem as pure attributes (like dates, e.g.: “2021-03-16”) have the potential to become first class notes (entries) some day: if the user so desires.
This kind of approach (or something equivalent) would allow Obsidian to bring together the best of both worlds (structured and unstructured approaches mentioned by @Whitenoise) for managing a knowledge base on any topic.
Any entry may start out as an unstructured freeform markdown note…
With time, as the need arises, structure could emerge… naturally and gradually… all within the same “entry” (file).
EXAMPLE
Below is an example that illustrates both a use case and the workings of above solution.
The demonstrated example happens to be for a hobby knowledge-base for plants, but the suggested solution is entirely generic so it could be applied to any use case involving semi-structured granular knowledge-base on any topic (movies, books, articles, …, anything).
YAML Front matter (and then some)
---
title: Spinach
author: John Smith
tags: [“gardening”, “plant/vegetable/leafy”]
source:
- {name: Wikipedia, link: "https://en.wikipedia.org/wiki/Spinach", primary: true }
- {name: Wikimedia, link: "https://upload.wikimedia.org/wikipedia/commons/c/cd/Spinach.jpg" }
---
type: species
name: Spinach
species: Spinacia oleracea
lifecycle: annual
taxonomy:
genus: Spinacia
family: Amaranthaceae
clade: Tracheophytes/Angiosperms/Eudicots/Caryophyllales
kingdom: Plantae
…
Followed by the BODY (markdown)
Spinach (Spinacia oleracea) is a leafy green flowering plant native to central and western Asia. It is of the order Caryophyllales, family Amaranthaceae, subfamily Chenopodioideae. Its leaves are a common edible vegetable consumed either fresh, or after storage using preservation techniques by canning, freezing, or dehydration. It may be eaten cooked or raw, and the taste differs considerably; the high oxalate content may be reduced by steaming.
bla bla bla...
Optionally followed by REFERENCE LINKS
[spinach:primary]: https://en.wikipedia.org/wiki/File:Spinacia_oleracea_Spinazie_bloeiend.jpg
[spinach in the fields]: https://upload.wikimedia.org/wikipedia/commons/c/cd/Spinach.jpg
What are the links in the above example ?
All the scalars found within the YAML frontmatter(s) above can be treated as potential -labeled- links:
- Spinach
- John Smith
- gardening
- plant/vegetable/leafy
- Wikipedia
https://en.wikipedia.org/wiki/Spinach
- …
- Amaranthaceae
- …
It gets better… Those are already labeled links, ready to be represented on a directed labeled graph (or go into a graph database :-), or just generate semantic triples…
For example :
link |
label(s) |
Spinach |
doc.title , name
|
John Smith |
doc.author |
Wikipedia |
doc.source[0].name , doc.source.name
|
Spinacia oleracea |
species |
annual |
lifespan |
Spinacia |
taxonomy.genus |
… |
… |
The above mapping convention probably needs some discussion and improvements. But it should give the general idea.
How does this approach compare to other solutions ?
PROS:
-
Brings together the best of both worlds of managing data (structured and unstructured), allowing structure to emerge naturally and gradually.
-
Generic solution for all kinds of data and metadata, without the need to reinvent the wheel for each and every problem domain (authors, articles, plants, movies, recipes, …)
-
Totally compatible with existing -and future- YAML syntax, without the need of any custom convention.
-
YAML data stays clean, void of extra syntactic noise (which might have otherwise been problematic for automated processing of YAML by other scripts that could choke on any special link syntax).
-
Gives us an easy and natural way of entering labeled “semantic” links (using dot notation or similar)
-
Probably quite easy to implement without breaking the existing Obsidian code (this is just a guess; I don’t have sufficient knowledge of the code base)
CAVEATS:
-
Could lead to “link noise”, listing too many things as links or backlinks.
This risk could easily be mitigated by some furher implementation choices:
- Ideally, such links could internally be marked as “implicit” and the user could be given the choice of displaying those (or not)
Also, auto-creation of unwanted entries should be avoided.
-
Could lead to structrure frenzy… prompting some users to over-structure their data, unnecessarily or just too early.
Well, when something is so easy (to do)… it takes some discipline to learn not to over-do…
OPEN QUESTIONS :
- What impact on performance ?
FUTURE POSSIBILITIES (for later on)
As the careful readers have probably noticed, this concept could be extended in may ways differnt later on… enabling many other goodies…
Here are just a few :
-
Basic text templating within the markdown body (something like jinja2 syntax or similar)
This would help avoid repeating oneself and also minimize errors.
-
Detect URLs and possibly treat them differently
-
More knowledge-base/graph capabilities (or exporting triples into graph databases) thanks to implicit labels that come from YAML
-
Ability to specify labeled links within the markdown body itself, in a way that is interoprable with the described approach (in YAML).
The last two items resemble the #juggl add-in being developed by @Emile (the current version is called Neo4j Graph View
)
Needless to say, care would be needed to avoid feature-creep and software bloat.
Obsidian was intended as an easy to use note taking app, in which it excels. So, it should not evolve into some complicated bloatware.
IMHO, with a few carefully chosen features, it has the potential to fill a huge gap… and still remain simple.
As Larry Wall once coined it: “Simple things should be easy, and complicated things should be possible [to accomplish] :-)”
Thank you for reading this far
Tabulo[n]