I’m building a new template for notes I take while reading. In the YAML, I have an author property.
In the content itself, a mix of highlights and my own thoughts, I want to single out the most important parts. The idea is to be able to filter for all important quotes and thoughts from author X.
I’ve found at least two options for this: Either using inline fields and query using Dataview (with (highlight:: ) and (thought:: ) as possible field names), or by just adding a #h or #t tag at the end. Using tags, I can search for (line:#q) to retrieve them.
What would be pros/cons with each option? Any other way this can be done?
If you’ve read some posts in this forum you wont be surprised that I’m advocating the inline fields. I’ll try to argue why.
With tags you don’t get your specific thoughts or question when searching, you get the entire paragraph.
If you want you can search for inline fields, but you’ll have to use dataviewjs and read the entire file to get the paragraph with the tags.
You can style your addition/sentence in the inline fields using CSS, but yet again using tags you would then need to style the entire paragraph.
I know some are a little reluctant using inline fields since they aren’t a part of the markdown standard, and that possibly both Datacore and dynamic view, if or when they come will have a different syntax. I’ll say that the syntax is so transparent that if another syntax come along, it’s easy to do a search and replace to whatever the new syntax will be.
I’m thinking that to avoid marking your thoughts and question in a succinct and precise way today using inline fields, is way better than not noting it and needing to remember all these thoughts and question when the new tools are available. Yes, you might need to rework it, but it’s there in plain sight instead of only in your brains.
In other words, using inline fields you have a clear markup (readily replaceable if need be) which can be accessed through searching and querying. With tags, it’s cumbersome to query and your information is easily intermixed with the other content in the paragraph.
I don’t know of other methods which are better than either of these two. You could possibly device some scheme using inline footnotes, but is it better? Not in my book.
Could you use some tool to have annotation/reference in another place? Surely, but I prefer to have it right there (and if need be you could hide it using CSS too).
Currently Obsidian doesn’t offer any native way to mark inline content for later retrieval. Hence we cannot give any proper answer to your question. In the future Obsidian may feature dynamic views (see Obsidian Roadmap) to query inline items including inline fields.
The idea of inline fields is not restricted to Obsidian specifically. In Pandoc’s Markdown you can use fenced divs:
::::: {#special .sidebar}
Here is a paragraph.
And another.
:::::
In above special is used as element identifier and sidebar as element class. Inside the curly braces {⋯} you can also write key–value attributes with name=”value” syntax. Pandoc then offers Lua Filters to retrieve document elements with given attributes. Pandoc has been around nearly 20 years.
Edit:
Similar syntax for span elements that can be used as inline elements:
Totally agree with @holroy here - I have moved from using straight links, to callouts (bad idea) to using tags to now using inline fields (with a side journey trying footnotes that I ended up keeping for other uses).
If you’re happy using dataview, inline fields are the way to go
Inline fields will be opt-in instead of on by default, so performance sensitive vaults can opt for inline YAML blocks or frontmatter instead, which are faster to parse.
I won’t use Dataview or Datacore if the core Dynamic views plugin works well enough for my needs. Adding this note in case it is important for the OP or anyone else dealing with this question to know about the performance overhead of inline fields.
Personally, I am moving all my existing inline fields to frontmatter (1) to use syntax that is native to Obsidian, and (2) to make the vault as easy to parse as possible.
Does anyone know if inline fields in Datacore use the same double-colon syntax that Dataview uses? Can’t find an answer in the Datacore documentation.
You are of course free to do whatever you like while we wait for the next version of either Datacore or dynamic view, but this is just one of the cases where I feel many choose a slightly worse alternative while we’re waiting.
Instead of keeping the inline fields just at the point where you have your thought, comment or question you opt to move it into the frontmatter and lose that locality aspect. For me that would mean I either need to expand the comment since I need to refer which part of the note it’s related to, or risk not being able to reconnect to the correct part.
Either option is for me worse related to keeping the inline fields until a better alternative is actually released and out in the open.
I considered this approach, but those thoughts are part of the content for me, not part of the meta of the note - they belong in the flow, and I want them present in exports/publish. I also have 10, 20 or more of them in my longer form notes, and trying to somehow manage that in the properties would be difficult for me. Not saying you’re doing anything wrong with that approach, just highlighting my reasons for not doing it, so other people can recognize what would work for them.
Performance-wise, I think Datacore has got it right. Opt-in for the people that want/need the feature and want to make any tradeoff there, but no impact for the majority that don’t. But, a lot of people do use a lot of inline fields all the time with the Tasks plugin (me included) if they’re using Dataview as well. I have two vaults, one for my notes/thinking and one for all.mynwork tracking/daily notes and all my tasks/projects. Both are sizeable, both use inline properties extensively, and as yet anyway (touch wood) I haven’t struck any performance issues (YMMV of course ).
I (think I) understand the points you are making. Added my thoughts above as part of a discussion, knowing that different solutions work for different people and their diverse needs. I initially used inline fields when I first used Obsidian but started to realign my thoughts when (1) Properties was launched, which I personally find very useful for data sanitization, and (2) I started to have performance issues with Dataview, probably caused by my poorly written queries and the unfettered pleasure I got from adding multiple queries to every page—the sheer excitement of manipulating data.
My thought process now is that I will keep to the ‘safe’ syntax supported by Obsidian’s core plugins: if Dataview is no longer maintained and Datacore doesn’t launch or it uses a different format for inline fields, I don’t want to have to wrestle with reformatting syntax again in the future. I just want to keep the maintenance of the vault as simple as possible, ergo Properties (for me). I’m a regular user of Obsidian, and unfortunately I don’t have your coding skills to feel I can sort out possible problems simply in the future. I have wasted too much time in the past wrangling with plugins and CSS—that’s down to my incompetence and poor discipline. So rationalization is therapy for me.
Completely agree. Being a simpleton when it comes to tech, I didn’t realize that different types of fields have different overheads in terms of performance.
My notes are generally very concise, so I don’t usually have separate thoughts in the flow. If I do, I tag them or, occasionally, mark them as tasks. When it comes to long-form writing, the notes are reference points, and I don’t need those thoughts / comments / questions to be in the final work.
Really want to be clear that I wasn’t criticizing anyone else’s working practices: one of the great things about Obsidian is that it can be tailored to each user’s needs. I was just sharing my thoughts and experiences. And because I intend to use Dynmaic Views in the future rather than Dataview or Datacore, I need to get on with the almost-Sisyphean task of moving the old inline fields to the YAML headers—just over 122,000 inline fields to move at the moment. I chose inline fields originally largely for aesthetic reasons and because I didn’t really get a handle on metadata and YAML headers. Properties changed everything for me.
Thanks for all the insights! At first I was also considering putting highlights and thoughts in frontmatter properties, but since I want to keep a majority of them in context that left we with either inline field or tags. And the fact that tags are applied to the whole paragraph make inline fields my choice.
To possibility to use standard markdown was something I hadn’t considered, but since I’ll sometime add a number (1-3) to my inline field as a way to tell the value of a highlight (by using h2:: for instance) that isn’t a solution for me.
I’ll be curious to see how “annotations” will manifest in Obsidian. Current work is about making them functional with PDF documents, but I can’t help but wonder if they could be a new “thing” for notes as well.
I like the manner in which a plugin “Enhanced Annotations” provides a sidebar and can distinguish between markdown comments and highlights.