I’m looking to migrate to Obsidian from Logseq and am having trouble replicating Logseq’s ability to store properties on blocks (in Logseq, one block = one line of markdown, basically). I use this to have a single long page containing a giant list of records, which looks something like this:
- entry:: 235
kind:: B
person:: Bob
country:: USA
- entry:: 234
kind:: A
description:: my description here
time:: 8:02
person:: John
The idea is that different records are mostly the same but can have some different fields, so a single table wouldn’t necessarily be appropriate. In Logseq, this format gives me a bunch of records I can query using its querying system.
In Obsidian, it doesn’t seem like it’s possible to query or attach data at a level more granular than entire pages. So what would be the best way to achieve this collection of records?
Things I have tried
Although it should work in theory, I do not really want to have a giant folder of records with one page per record — that seems like overkill and would be very annoying to manage.
The idea of Dataview and Dataviewjs is to process your notes. You can process them all to RAM and then run your code to extract stuff. Obviously that requires knowledge of programming.
Man I wish I could delete someone else’s comments right now. I know how to program. My question is not how to process data I already have, it is WHERE AND HOW DO I STORE THE DATA I WANT TO PROCESS. YOU DO NOT NEED TO KNOW HOW TO PROGRAM TO ANSWER THIS QUESTION. IT IS A QUESTION ABOUT OBSIDIAN.
- [entry:: 235]
[kind:: B]
[person:: Bob]
[country:: USA]
- entry:: 234
kind:: A
description:: my description here
time:: 8:02
person:: John
- (entry:: 236)
- kind:: C
- description:: my subitems here
- time:: 8:08
- person:: Johnny
`$= dv.span(dv.current().file.lists) `
```dataview
TABLE item.entry, item.kind, kind, item.children.time, nonnull(item.children.time), item
FLATTEN file.lists as item
WHERE file = this.file
WHERE item.entry
```
If you go to reading view you’ll see what dataview sees when using the various notations.
Your original format (the second one in my example) collapses all the text into one entry item, and there I don’t think you can access the bits and pieces of it.
In the last example I use subitems to create different contexts separating the various fields, but it’s not really easy to access them here either.
So my preferred method would be the first variant where you enclose each field in either square brackets (where the key value is shown), or normal parentheses (where the key value is hidden). The various fields are then easily accessible through simple dot notation after you split the lists in a file using FLATTEN.
Note that you will get much better performance if you put where file = this.file first. Putting it right after table lets Dataview filter by file first (quick, easy), then flatten the lists in the current page. If you put the where file = this.fileafter the flatten, then Dataview must flatten every list in your workspace before filtering on file, which is expensive (and slow!).
