Block reference

OK but we can already do all that using ![[topic]] no?

Though I can understand if another tool has gotten you into the habit of making bullets per topic instead of notes per topic, that it can feel like a mental burden having to change the existing habit.

Anyways don’t want to make it sound like I’m pushing back on the feature, which I’m not…

![[note]] already does that. Or do you mean something else? Agree that fold would be very nice though.

2 Likes

OK but we can already do all that using ![[topic]] no?

No
[[topic]] restricts you to the note name! Sorry but that is absurd as a solution. The point is to reduce friction not add enormous friction. The point is the ability to write on a topic then include a piece of that writing as a part of multiple other topics.

The beauty of obsidian is in the clean simple writing tool with great linking capability. It completely defeats the purpose to think you are going to break out every single paragraph as a note title. And no displaying the entire md file is not the solution either. This is about efficiency in connecting your ideas and in your workflow.

4 Likes

Not [[topic]] but ![[topic]] with the exclamation mark, which embeds the entire note content and not just the note name, therefore from my perspective solving the example issue described here.

===

The specific mention of a piece of that writing is a good example of what I meant with:

I can see how people are struggling with that. But I turned into a proponent of atomic notes and like I mentioned before believe this habit of listing down bullets which other tools have instilled on people might actually be a trojan horse when it comes to knowledge management, though I could be wrong on that last part and it doesn’t matter for me neither does it help resolve the immediate problem some people are having.

But I don’t think I’m wrong in it having instilled a habit on people (again, leaving in the middle if this is a good or bad habit) which they now have trouble letting go of, or else I’d not be writing this comment and you probably wouldn’t have written this either:

Not saying that all this enthusiasm about block references is wrong, not at all, but I’m just sharing a different perspective from someone who has not been influenced by alternative tools and who won’t be affected by what other people eventually end up doing.
Hopefully it can help at least a couple of you get past your existing habit of writing in bullet lists and switch to atomic notes, or if not you can still try find a middle ground by using Ryan’s solution, or maybe one of the solutions that smart more technical people have proposed will turn out to be a good fit for anyone who won’t be able to let go of their existing habits then.

4 Likes

Thanks so much for pointing this feature out - I had missed it, and it works well for my use case :slight_smile:

4 Likes

Ah - I had missed the ! - but doesn’t change my point that embedding an entire note does not provide the same workflow efficiency as being able to embed blocks. Our difference of opinion is not about atomic notes (I’m a big fan of the concept although from long before I ever heard the term “atomic notes”). The difference of opinion (on my part anyway) is about efficiency in building new formulations of old information.

I’d point out though that there are quite a few, long established apps that simply allow you to create an atomic note and have it linked in various ways. A good starting point on those is the zettlekasten.de site. Not sure why the world needs another version of The Archive, Zetlr, nvUltra etc. The value I see in Obsidian is combining notes with long form writing - as summaries or header pages (sorry MOC seems the hot term on this forum) in various ways. The reason people mention Roam so much is not that they want to make Obsidian a Roam clone but that Roam showed the way to some amazingly efficient workflows using backlinks and transclusion that generated a lot of excitement.

Atomic notes are great in some use cases. What I want is to be able to pull notes on an article, book, reference into one page where I summarize that information at some level of detail and then be able to very quickly pull individual elements into another page or into a piece of writing (an example of the power of the flow can be seen in the video I posted early in this thread). Yes I could accomplish the first part using the type of notes you are describing (with lots of friction) but the second part would be extremely cumbersome in Obsidian as it stands now. Making those connections is still pretty kludgy in my humble opinion.

4 Likes

I like to develop each line of reasonings in a single note, which makes it long, as opposed to atomic notes.

If you represent a line of reasoning by a chain of connected statements (for example R1: A -> B -> C -> D -> … -> Z), then block references would provide the ability to re-use a part of it (C -> D) in other lines of reasonings at other notes (for example R2: !A -> !B -> C -> D -> … !Z) without adding cognitive loads.

You can argue that if C -> D appears in different contexts then it can be extracted to an atomic note and referred in the reasonings by its name. However, just because it can be doesn’t mean we should do it. And cognitive load is a reason I don’t do it.

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.

Block references would resolve that problem in a natural way. It’s not that I am familiar with Roam so I want Obsidian to have what Roam has, but I think it’s a feature that would empower the way that I develop arguments, which is through writing long notes.

I understand this isn’t trivial, being a software engineer myself, especially when it’s not included in the initial design decisions, but I hope I offer a reasonable point of view.

13 Likes

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.

6 Likes

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.

8 Likes

@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.

7 Likes

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

5 Likes

+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.

8 Likes

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 :wink:.

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 :wink: - 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.

7 Likes

@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 :wink: - 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.

4 Likes

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.

1 Like

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.

3 Likes

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.

3 Likes

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.

1 Like

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.

1 Like

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.

Thinking… , :star: :star: :star: :star: :star: