Trying to create a continuous log file that will have structured data, ideally in YAML. Why? Right now I use a table in google sheets, with several columns, but as individual cells are lengthly, it is difficult to read it on my mobile. I thought I could try setting up a yaml file and use obsidian to write and read it.
Things I have tried
I tried searching, but most results refer to using YAML for metadata. Starting with ‘—’ in the file body results in a horizontal line. I am looking for an example of how I could use this. E.g., should I use ‘—’ to separate each log entry? What I am thinking of is:
---
id: 1
date: 2024-02-23
tags:
- a
- b
short_description: text
long_description: text
long_description_2: text
---
id: 2
...
Is it doable in obsidian? What would be best practice - one continuous document starting with ‘—’ or having multiple yaml documents in a single file, separated by ‘—’, where each document represents a row in a table?
Edit: I suspect I’m trying to find a way to edit a YAML file in Obsidian… should I use .yml instead of .md ?
Multiple YAML blocks in a single document is not supported in Obsidian. In your case you can very easily use unique note creator to create new notes for your YAML blocks. You need to do two things:
set a template for Unique note creator
set a hotkey for “Unique note creator: Create new unique note”
You can later use Dynamic views to query YAML fields into one table. Dynamic views and Unique note creator should support your use case really well.
Like you’ve already experienced you can’t just put frontmatter/yaml blocks one after another. That’s not functioning, and I’ve not heard of any plugin working to that extent either.
So what options could we do to repeat multiple fields of information in a consistent way?
In the frontmatter
In the frontmatter, you could to some extent use something like:
---
entries:
- id: 1
date: 2024-01-01
tags:
- a
short_description: text 01
long_description: The first text, that is number 1, the start...
long_description_2: text
- id: 2
date: 2024-02-02
tags:
- a
- b
short_description: text 02
long_description: The second text, that is number 2, not the start...
long_description_2: text
---
But, it’ll display as the following in reading mode:
And you’ll need to go to source mode to change it (or use some external script/query to update it).
Other than that, it seems like recent version of Obsidian wont mangle up the entry of it too much. The version above is actually how Obsidian rewrote a very similar markup of mine.
A query to look at frontmatter variant
One variant to list a few of the columns, just from the current file in the example, would be to something like:
```dataview
TABLE WITHOUT ID item.id as Id, item.date as Date, item.tags as Tags, item.short_description as Short, item.long_description as Long
WHERE file = this.file
FLATTEN entries as item
```
Another alternative is to use inline fields in the body of the note, and here are two examples:
First suggestion on alternative markups
- [id:: 30] [date:: 2023-03-30] [tags:: #c, #d] [short_description:: text 03] [long_description:: This is the long text example]
Or possibly like the following:
- [id:: 31] [date:: 2023-04-31] [tags:: #d, #e]
- short_description:: text 04
- long_description:: This is the long text example
- long_description_2:: This is also long
Note how that in the second example we’ve moved the longer text into a sub-level, thusly allowing for better word breaking on longer texts.
Accompanying queries
#### Query inline variant 1
```dataview
TABLE WITHOUT ID item.id as Id, item.date as Date, item.tags as Tags, item.short_description as Short, item.long_description as Long
WHERE file = this.file
AND file.lists.id
FLATTEN file.lists as item
WHERE item.id
WHERE item.id = 30
```
#### Query inline variant 2
```dataview
TABLE WITHOUT ID item.id as Id, item.date as Date, item.tags as Tags, Short, Long_1 as Long
WHERE file = this.file
AND file.lists.id
FLATTEN file.lists as item
FLATTEN nonnull(filter(item.children, (c) => c.short_description))[0].short_description as Short
FLATTEN nonnull(filter(item.children, (c) => c.long_description))[0].long_description as Long_1
WHERE item.id = 31
```
Some advantages of these latest queries, are that you could more easily incorporate links and tags, and have them function as normal. And most likely will they be easier to edit on mobile, since they’re more normal text in lists.
Parts of the query looks kind of ugly, especially in the last variant, but then again, you’ll only need to do it once, and then keep repeating that center part with those kind of magic FLATTEN statements to extract the fields from the children lists. After that you can do your more normal WHERE clauses, and filter stuff according to your likings. It’s just like a normal query where you just have to add a few lines in the middle of the query to sort out part of the fields.
Also note that you could style the inline fields quite intensively if you like to show/hide/enhance some of the fields in your entries.
I think these two variants of either in the frontmatter or in the body text using inline fields are your best options, before you consider to split it up into separate files.
Another alternative altogether would be to either use some of the more database related plugins, or even possibly metadata-menu and file classes to try to adhere your structure into that. If that’s a better option for you in the long run is up to you to decide, but that’s eventually for another thread another time.
