Block reference

[Sellaro]

@minhthanh3145

To make an atomic note we have to give it a name, to give it a name is to add a proxy layer. A proxy layer simplifies the process of re-use, but it adds extra efforts to retrieve the content (opening the note in a new panel, eye-switching, mentally constructing the actual line of reasoning from names of the notes, etc). The efforts, when compounded, have significant effects, especially when you’re trying to develop complex, intertwined lines of reasonings.

On top of that, even the so-called atomic notes are likely to bear some level of meta information - as opposed to only the note/idea content itself. So an atomic note is usually not really atomic.

One can than argue: you can always put the note/idea in a specific header and refer the header instead with ![[note#header]]. Yes, that is possible, but not practical. If, for example, you change the header name for any reason, all the references to this header become invalid. There is no “header update” feature that visits the whole vault and updates references accordingly.

[Lachlan]

The header update would be a good start for moving to some sort of block reference system. Obsidian can already update links when a filename changes, headers shouldn’t be impossible. (edit: already planned )

I’d like to see transcluded header title visibility toggling added as well. e.g:

note.md >
# Header
Some text

should be able to be displayed as

some text

when transcluded rather than

# Header
Some text

as it is now.

A switch in settings to control it should be enough.

[Klaas]

@Sellaro: further to my previous, less unenthusiastic comment, I have now hit a situation where, instead of linking to the whole note, I’d like to be able to link to a specific line another note. A block reference is called for.

I have added my like to your OP. I hope you don’t mind this change of heart.

[Sellaro]

@Klaas

I hope you don’t mind this change of heart.

Not at all. This is an evolving conversation The more feedback we get - including from changes of heart - the better.

[Nadia]

+1 to this request.

In addition to the uses mentioned above (FWIW, my use case is remixing individual ideas/notes — e.g., from article/book notes — in a granular way as I write about a given topic), I think there’s an additional/secondary argument for block references: their existence enables more frictionless note-taking. Without them, more thought needs to be put into how you structure each note as you write it (e.g., deciding whether or not to create a new note or headline for a given idea to make it easier to transclude).

That isn’t necessarily a bad thing — there have been some compelling comments here arguing that block references may deliver efficiency at the expense of “better thinking” — but I’m not sure, for me personally, that the added friction is a net positive.

[deftdeg]

Again, a fascinating topic that really stimulates my own thoughts, and I’d like to contribute.

It appears the debate on block referencing has quite a bit of focus on the mechanics of how it could be achieved, with perhaps more than some comparisons to Roam and some probing as to why you would, or wouldn’t want to do it.

Apologies for Stating the Obvious
If we consider the essence of the use-case where we want to achieve a graph of linked thoughts, each thought in Roam is, at it’s most atomic, a single bullet. This is conveniently lazy (not meant to be pejorative) in that we could ‘brain dump’ in our daily note page with all kinds of links and the subsequent nodes of the thought graph would all reflect the thoughts we had - because bullet node links to bullet node.

In Obsidian, each thought (node) is either an .md file or a header within that file. Thus the same brain dump in our daily notes file would yield connections that all backlink to the daily file - which has a certain utility, like when you want to recall when you had a particular brain-wave, but isn’t a real robust knowledge graph.

In Roam I’ve noticed most all of the thought ‘pages’ I’ve seen in examples - confession: I’m not a Roam user - are empty save for all the backlinks, which i where the magic happens.

In Obsidian this cannot be - well it could, but it wouldn’t be terribly useful. Pages link to pages or headers in pages.

@Silver and @Licat are showing us we need to be more deliberate in expressing our thoughts - which is hard, at least for me, which is why I keep reading everyone’s posts for inspiration .

I’m Making This up as I Go
Since pages are file names, we are constrained by OS rules as to legal characters and length. This is where header referencing and multi-page panes are our friends.
If we want to brain-dump in our daily files, we could briefly pause to consider the topic or context of our thought, quickly link to that [[topic or context]], immediately open it in a new pane and dump our thought in there, which may contain further links - in which case, rinse-and-repeat.

We can then if we want to further contextualize our thought, place it under a header. We can add the header to our original link [[topic or context#further context]]. At that point we can be as wordy as we want since the header isn’t constrained by OS file-naming rules.

We preserve the initial link to when we had the thought, but we are also creating a knowledge graph, from the thought itself, by populating the thought page with the substance of the thought and links to further thoughts.

A Feature to be Requested
I’ve noticed though that if we preempt the header before it’s created - [[topic or context#further context not-yet-created]] and click to the page to create it, the header is not created.

Further, as @Lachlan points out, while file name changes are reflected in all links, header changes are not. And while what I have outlined is deliberate/intentional thought mapping - I’m going to have to try it myself today - I would think having to manually change header links, after we have carefully revised our thought-map, would just get in the way and cause a break in our focus - counterproductive.

[Klaas]

@deftdeg

while file name changes are reflected in all links, header changes are not. And while what I have outlined is deliberate/intentional thought mapping - I’m going to have to try it myself today - I would think having to manually change header links, after we have carefully revised our thought-map, would just get in the way and cause a break in our focus - counterproductive.

@WhiteNoise said here it is a planned feature.

[grt]

I would also like to support the request for being able to use blocks. I understand that there are technical difficulties and/or issues related to the core idea of Obsidian (after reading this thread), but it would make it a much more productive tool for many.

I am a social science researcher and have previously used quite a mix of note taking software (especially Evernote) and hardware (paper highlighting, post-its etc).

When testing the software in the last two days I did not really understand how to use it on the first day for the very reason that block references did not work. I thought this was a bug and I looked for problem solving ideas here on this very forum.

I understand the underlying principle and the (for me, more conceptual) benefit of having individual markdown files with associated title-based filenames. I realise that block-level backlinking would make this difficult. Yet, for my personal research style many of the theoretical benefits of Obsidian do not materialise without it. Having more than one “file” for my notes and quotes on an article or book (chapter) makes it impractical - even if this goes against the ‘atomicity’ of Zettelkasten proponents. Yet, then not being able to relate bullet points or paragraphs (without very extensive use of headings) to others takes away the key benefit I believe Obsidian is proposing.

I cannot help with the technical realisation of the issue but wanted to provide another rudimentary use case scenario and, perhaps more importantly, my personal expectation on how to use Obsidian as a layman of this kind of note-taking tools.

[ryanjamurphy]

Thanks for this (and same to others).

It’s clear that there’s an important design issue to resolve here.

I still think there’s technical limitations that mean that the only solution to “real” block referencing also means abandoning the core interoperability principle of Obsidian. This is why I’d bet we won’t see an answer to this until the plugin API is launched and a third-party developer makes such a solution as an add-on.

In the meantime, if you desire block referencing because of familiarity with related app-paradigms (i.e., Roam), your best bet is to forget about the filesystem and to use the quasi-solution I detailed in the thread below. That solution only works if your “blocks” are valid filenames, so it has some obvious limitations.

How to do block referencing in Obsidian

Edit: Since block referencing and embedding was implemented in 0.9.5, this workaround is no longer needed. TL;DR: Can Obsidian do block linking? Yes, but it behaves differently from other PKM apps. Create a block reference by wrapping the target block—or sentence, or phrase, even—in [[square brackets]]. Then, create a new note with this link. There! Now you can reference that “block” elsewhere. You may add content to the new note, but you don’t need to. A best practice might be to include a …

[Privid]

One way to execute this might be via search. The transclusion command, {{transclude:note_title§paragraphstart}} or whatever, would search in note_title for a paragraph beginning with paragraphstart and insert the relevant paragraph. This kind of syntax would keep the text readable and interoperable, and wouldn’t demand anything extra of users such as adding IDs.

[Sailesh]

Great example. The next simple step would be break/split [[Matthew 28]] into sub-files so the first reference (if clicked == you care enough) to [[Matthew28 #18]] results in separate #18 file.md just for the block and it get included into [[Matthew 28]] with the ![[Mathew 28 #18]]. Use preview to see the whole thing or drill-in to edit. [[Matthew 28 #18]] obviously starts with a # or ## etc depending on the level.

[grt]

Thank you. I read your post at the beginning of my search journey and lacked the understanding of what your suggestions meant. It makes much more sense to me now and this would be, at least in some scenarios, an option until a final decision on this is made by the developers.

[Dor]

I think that many of the issues mentioned in this thread are down to old habits and Obsidian not being fully developed yet. And it’s important to bear in mind the advantages and disadvantages of database versus document based models.

Some of the issues are about display - showing lots of documents on screen in card form, makes an overview easier; should be possible and I assume someone will write a plugin sometime. If you look at Scrivener, it’s quite easy to write a long document in small chunks and see chunks separately or the document as a whole. I don’t think that’s quite possible in Obsidian because I don’t think it has the concept of child notes, thoughit does have the file explorer sequence. Traditionally in outliners each new point is a ‘child’ or ‘sibling’ of the previous point and that relationship is retained unless deliberately changed.

I’m not convinced of the need for block references like Roam. Seems to me that there are many ways to tackle this perceived need, some of which are well suited to a document based system.

[ATobsidian]

@Sellaro

This feature is like the stage 3 of transclusion

Thinking… ,

[Sellaro]

There are two problems with this approach. The first one is that it assumes a pure, 100%, contents-only atomic note. The second one is that it creates a couple of extra steps . Expanding on the two problems below.

Atomic notes are not atomic: As mentioned here. Take this very example. Let’s say I have an atomic note that says “Atomic notes are not really atomic, for they have some kind of meta data added to it in a Markdown-based systems like Obsidian”. I would like to add at least two elements to this note: where it came from and other related notes. If I add these bits of information, my so-called atomic note is no longer atomic. It bears not only the content itself, but other information. If I reference this note (by transclusion, for example), I’d also be including its meta data and the links to related notes, which I may not want to do if my interest is only on the core of the note itself.

Extra steps: We are interested in doing exactly the opposite of creating extra steps. Adding extra steps is taxing on ones cognitive system, which degrades understanding and learning. This seems a too expensive side effect. Taking the extra steps argument to the limit, Obsidian itself is not needed. For one can always implement atomic notes in an analog index card system and achieve great results. Luhmann’s intellectual production is a demonstration of that.

In summary, although it is possible to create (cognitive taxing) workarounds and in spite of the technical challenges of developing a block reference system on top of a plain Markdown file structure, it is possible and useful to develop some kind of block reference in Obsidian.

[Dor]

If you like the Roam approach so much, why not simply use Roam when it’s clearly not straightforward to add this feature to Obsidian.

I’d also disagree about the cognitive tax. It’s taxing if it requires a habit change because you are coming from another system, but otherwise it’s minor.

As a separate point there is a recurrent tension between users wanting a more reflective Luhmann type approach, and those pursuing a high number of outputs as in GTD etc. Your comments suggest that you’re more in the second camp?

[minhthanh3145]

I don’t think it’s a Roam-specific feature, per se, although Roam popularizes it. Before Roam, I already was doing citations to specific paragraphs in my notes written in other note-taking tools. Particularly when I am writing a long train of thoughts that incorporate points made in paragraphs from other notes, the switching between notes exhausts me.

The reason I switched to Obsidian from Roam is because the cost of Roam doesn’t make sense for me. I like Obsidian the way it is, but I don’t think people advocating for block references are doing so due to their habits formed when using Roam, but rather from a position where they the benefits of such a feature.

If you would like to argue that, the habit change which is equivalent to forsaking the pursuit of block references, would actually benefit the users in the long-run, as opposed to increasing cognitive load as discussed above, I’d be interested in hearing that.

[ja_rule]

What would be wrong with a very simple system of markers to mark the block, that either include or exclude the ##header that identifies it? So you could have, for example:

{{ ### My awesome quote
My block text
}}

or

### My awesome quote {{
My block text
}}

In either case, you would include this elsewhere as

![[my_file#My awesome quote]]

Obsidian already supports this form of header-level referencing, I believe. The first form would include the header/block name in the transcluded text, and in the second case would skip it. I understand that the goal is to stay as close the standard markdown as much as possible, but [[ ]] is already non-standard. This seems to fit the philosophy of link as first class citizen even if it introduces a small deviation. And it looks not entirely unlike a bit of LaTeX or json code with the use of delimiters to mark out a region for special treatment, which is probably familiar to this community.

I’m not a fan of all the hidden line IDs or other mechanisms, which seem complicated. Better to mark and name the block, which will still work if you add, remove, or shuffle other things in the file, or change the contents of the block itself. Would also be obvious in non-Obsidian markdown editors that this block was marked and named for a reason, and wouldn’t be too visually offensive.

[Dor]

afaics Roam keeps all your notes as a single dataset. The block is a key concept in design and optimisation of its database. This makes it fast and flexible working with blocks.
Obsidian is a database working with notes held in separate document files. Links to Documents and Headings are straightforward because they are native features of those documents.
I don’t see how it can ever process blocks as effectively as Roam.

The downside for Roam is that it’s stuck with blocks, just as Obsidian is stuck with documents. There are many ways of thinking about working with sections of text. I think it would be most useful to consider the detail of various needs rather than talking about blocks.
For instance, doing textual analysis there may be a use for analysing portions of text, where the portions may overlap. Neither Roam nor Obsidian have an elegant solution to that right now- multiple links to the same word require a different solution to [[ in the original file. I think Ryan is right in his approach, though the program would need to heavily tweaked to make it fully effective. Micro plaintext files are managed very effectively in all OSs. A selection that created a new linked file could work with any and all portions of text - but there would need to be an effective way of displaying them in the original document.

[obsessed]

@greasemonkey I try to not look at this as a difference in opinion because that can shut us off from finding something of value in what the other is saying - like 99% of internet talk I suppose

This discussion allows some people to already find a partial solution that can work for them right now, which is great on its own.

Then others can share why exactly it won’t work for them and this is extremely valuable because let’s face it: there’s a lot of smart people here and those tend to have difficulties dumbing things down, as in their minds the problem is THAT obvious, it’s hard for them coming up with words to fully describe it.

There’s some great insights shared so far by both yourself and everyone else who posted.

For example based on your multiple uses of the words “friction” and “pulling” blocks, I now wonder how people would feel if the problem on how to STORE blocks got solved but we would then always need to type in order to RETRIEVE a block when including it in another page.

Would such a solution still carry the same amount of friction? In other words, when you refer to “pulling blocks”, is it the act of dragging and dropping blocks between documents which contributes to the feeling of efficiency?

---

Then back to the other side of the coin on how to actually store the blocks in the first place:

I’m sure eventually people will develop multiple flavors of plugin solutions as some want bullets, others want paragraphs, others just lines, etc… and those plugins will be a good fit covering those specific needs.

The risk is with other people not fully understanding some of the intricacies these plugins will bring along when they require storing foreign block indicators inside markdown files.

Everybody can of course accept that risk when using such plugins but nobody wants to see theirs or someone else’s life work get mangled due to the inner workings of a plugin conflicting with another app and/or human error update.

That’s why a fully portable and truly robust solution which can be safely distributed to a wider general audience will most likely need to stay closer to the Obsidian foundation using plain markdown documents.

I’m not a developer and don’t care much for markdown - so don’t know this suggestion is of any use at all, but maybe we need to look closer at using plain markdown without requiring extra foreign indicators in the file?

For instance by using a simple numbered list.
A plugin could validate numbered lists ensuring they are sequential and unique within the document(header). Then couldn’t that regular number be used as the block ID?

Something along those lines would feel more robust to me, easier to comprehend for the average user as well, be portable, and if something does get mangled wouldn’t require the SpaceX team to come in to fix your files.