Single note/file per quote

[themikejr]

For PKM workflows that prefer atomic style notes, it would be preferable to have one note or file for each quote. Then users can assemble these atomic notes in various ways. Has there been any discussion around this idea? I can imagine a setting in the plugin where someone could elect to use a single file/note per quote instead of the current default where quotes live in bulleted lists in a note that represents the entire book/article.

If there is a way to do this that I have missed, please let me know!

[Irshaadv]

Hello.

I actually came here to comment on the same thing! Basically looking for a way for each highlight to live in it's own note (file name/ title can be the "date-time-title").

Would open up a number of options in terms of work flows.

Hope someone has an answer for us :)

[Irshaadv]

Coming back to check on this - would be happy to pay a dev to do this if possible. Any takers?

[writtenfool]

There a number of plugins, both core (note composer) and community (Extract Highlights), that do this sort of shredding. Both work well and given the QuickAdd and Templater community plugins could be automated.

Also, doing this sort of loading at volume puts a strain on both Readwise and our Obsidian vaults.

And, I have to ask myself this question all the time ... do we really have to adhere to total atomicity? Given the Obsidian search and the various internal link types (especially section and blocks), is it really necessary?

[quinn-p-mchugh]

@writtenfool It sounds like you think this request is unreasonable?

Personally, I would love a feature like this. It would allow me to view my highlights as individuals nodes in the graph view, which could yield some interesting cross-source connections.

Using Note Composer, Templater, and other plugins to achieve this kind of functionality seems like it would require a lot of manual work. I'd love to be wrong about this, however.

[writtenfool]

Disclaimer - I no longer use Readwise or Reader.

If somebody has the discipline to maintain an atomic pkm, it certainly is reasonable. I do not.

I have an issue with tainting a source, and for books and articles, they have context in their original setting. Granted, we have all kinds of ways of linking back to or, via yaml, providing a path from highlight to source.

And I have a fear of using an externally assigned unique id; this is why I left readwise.

For me, I can find or fish for the good stuff in my non atomic vault with nothing more than core search. With properties now, it's even easier.

The new local llama plugins allow us to model our vaults; this is going to be a cool function; none of the AI LLM's require or need atomic sources.

Do you know about https://kindle-formatter.com/ ? You could use this to feed your proposed project, for free. You can download the source and incorporate it into your solution.

I'd go back to readwsie in a heartbeat if somebody would do something with this interface. With reader, despite my love for it, I got tired of maintaining meta data in two places.

Cheers!

[quinn-p-mchugh]

@writtenfool Thanks for elaborating! I wasn't previously aware of Kindle Formatter - it seems like a useful tool. :)

For me, I can find or fish for the good stuff in my non atomic vault with nothing more than core search. With properties now, it's even easier.

I think this is where our perspectives differ. For my use case, I rely heavily on Obsidian's graph view instead of search. I use it to identify patterns in the kinds of content I engage with and the various learning artifacts (e.g. concepts, facts, etc) I've written about, which can help indicate gaps in my knowledge or provide new insight or inspiration for problems I'm trying to solve in my work or life. Standard search and LLM-powered vaults can help in this regard, but taking a pluralistic view of knowledge, I find the most value in being able to see and play around with the connections myself and see what disparate sources have to say about a particular topic. I suspect being able to see Readwise highlights as individuals nodes will help with this, especially given that a not insignificant portion of the content I digest is podcasts, which can often jump around to dissimilar topics.

[tyler-dot-earth]

Heya, friends. I'm a contributor to the Obsidian Readwise plugin and figured I'd add my own perspective here.

First, definitely acknowledge that people want this. In a recent Reddit thread about the plugin, note-per-highlight was actually one of the more popular requests.

My own perspective is that this request is well-intentioned but unnecessary and difficult to imagine how it would actually work. Hear me out 🙂

If what you're after is the ability to reference highlights, you can configure the highlights to generate stable block ids and then embed those references in any other note very easily:

![[readwise/exports/Article^rwhi123456]]

:point_up: I think this fits inline with the idea that you should treat readwise exports as read-only.

If what you're after is findability without scrolling through a notes file that has all the highlights for that Readwise document, some questions:

• Are Obsidian's global + file search not sufficient? Or maybe something like the Omnisearch plugin?

• If the highlights vary in topic for a specific document, have you considered writing a note that consolidates the highlights (using ![[embeds]]) into a single thesis?

...

But, all this aside, let's just consider note-per-highlight.

• What would the name of the note be? Remember: a highlight a lengthy paragraph, multiple paragraphs, just an image, etc.

• what advantage is there of note-per-highlight that my suggestions haven't solved? It seems like the 2 main reasons that people want it are findability and referencability, both of which I have provided suggestions for.

...

Finally — i'll just note that making this feature isn't trivial with how the whole system works right now. Combine that it seeming unnecessary, and it's difficult to rationalize working on this.

I hope this helps. Let me know your thoughts, especially if I'm not considering something important.

[writtenfool]

The note name may be trivial, as long as the child highlight is aware (properties) of the parent note (book or article). You have a book parent and a unique id for each highlight - the child highlight name could be bookname-highlightID.

The reason for the mass frustration is the concept of "atomic notes" in zettelkasten methodology; there is merit to this and therefore important.

[tyler-dot-earth]

@writtenfool

The note name may be trivial, as long as the child highlight is aware (properties) of the parent note (book or article). You have a book parent and a unique id for each highlight - the child highlight name could be bookname-highlightID.

That's a solution, though I'd find a name like that not-very-useful. This plugin also doesn't determine the file structure (the files get downloaded from the backend), nor would it be able to augment the export template settings page on the web - so the note-per-highlight filename would either have to be fixed or do templating in the plugin (which seems unfortunate given all the other settings are on the web).

The reason for the mass frustration is the concept of "atomic notes" in zettelkasten methodology; there is merit to this and therefore important.

I understand this desire to some degree... Though, and this is just my opinion, but it seems like this views atomicity too rigidly/dogmatically — if there's no underlying benefit of atomicity given you can reference it regardless, there's no point in scattering the files other than personal preference.

Totally valid that we have different preferences, but in this case your preference is technically difficult to achieve, would add complexity to the codebase, and has (to me) unknown benefits.

All of these factors make it difficult for me to justify working on this as a contributor. Even if I did the work, I don't know that Readwise (the company) would want the added complexity without very solid reasoning. :confused:

Unfortunately, your best bet here might be to fork the component and implement the feature yourself, or make a stronger case to convince others to help.

Good luck :+1:

[writtenfool]

Another bigger issue is the amount of meta data in Reader is not available to Obsidian; it's why I left Readwise as a subscriber.

I totally agree about the atomic thing, I do not have the discipline to do that ... but a staggering number of Obsidian users do. I use the core search in obsidian and it works for me just fine.

Totally hear you about the time investment and appreciate your time. It has puzzled me that Readwise has not updated this plugin or even acknowledge the issues. There are influential obsidian users on the readwise team.

[quinn-p-mchugh]

@tyler-dot-earth Hi Tyler, thanks for taking the time to share your thoughts here. It helps to have a contributor perspective. Some responses to the questions you posed above:

What would the name of the note be? Remember: a highlight a lengthy paragraph, multiple paragraphs, just an image, etc.

I would give the same answer as @writtenfool - "BookName - HighlightID". Using the highlight content as part of the title doesn't make a lot of sense to me, unless it was truncated to, say, 50 characters (while still including the highlight ID to ensure uniqueness)

what advantage is there of note-per-highlight that my suggestions haven't solved? It seems like the 2 main reasons that people want it are findability and referencability, both of which I have provided suggestions for.

Per my previous comment, exporting note-per-highlight would increase the "explorability" of highlights using Obsidian's graph view. If the Readwise template is configured such that Readwise tags are exported as Obsidian links, having a note per highlight would include highlights as nodes in Obsidian's graph view, allowing me to visually explore my highlights (and their connections via the Readwise tags they share). This particular use case seems valid and useful.

As you indicated, referencability can already be addressed using block references and findability is not an issue with plugins like Omnisearch.