#1

Support in-content JSON?

I guess YALM is a kind of JSON, except that it doesn’t fully support links (you can use the format key: "[[link]]", but I heard that there is a case that you cannot put links in there. Unfortunately I don’t fully remember the details). In my understanding JSON has more flexibility than YAML? So I just wonder why can’t we use JSON in the middle of the content, like LaTeX or mermaid?

Case 1: list of links

text text:: value
subcategory: {[
  [[link 1]],
  [[link 2]] 
]}

  • I don’t want to put this in the frontmatter, because it’s more natural to have read this list at the bottom. Plus that links aren’t fully supported in there

  • If I use the Dataview inline, i.e. subcategory:: [[link 1]] [[link 2]], then it will be cluttered if there are many items and the links are long (alias won’t help)

  • If I use tasks instead, i.e.

    - [ ] [[link 1]]
- [ ] [[link 2]]

    then I can only query them with file.tasks, not with the actual key I want. The checkbox also gives me false impression.

  • If I separate the list in multiple lines, i.e.

    subcategory:: [[link 1]]
subcategory:: [[link 2]]

    then the connotation that link 1 and link 2 are relevant will be lost. They are two arrays of one element, not one array of two elements.

Case 2: declare metadata for non-existing files

[[link 1]] : {
  key 1: "value 1",
  key 2: "value 2" 
}

While link 1 hasn’t created yet. This is extremely useful if you are working with graph database. See the Link Types - Juggl

#2

Hi. What you mean by “doesn’t support links”?

#3

To follow up @mnvwvnm, how do you intend to use JSON? At one level, JSON is just a text file, and you can certainly write JSON structure within a markdown text file – it’s more a question of what you’re trying to do with it

1 Like
#4

It will help plugins like Dataview get info better. With a proper object you can nest lists and objects as values. You can also write each item in a separate line, which is easier to read. You can guarantee that links as values can always be read properly (currently the YALM doesn’t fully support it). You can even put metadata to the links as well. I see that there are many potentials

#5

Hi Ooker, thanks for your note. Can you give me an example of what a JSON block would look like in your model? I don’t have any objection to adding JSON support, but I’m struggling to think of a concrete example where JSON provides functionality YAML doesn’t.

1 Like
#6

for example:

text text:: value
subcategory: {[
  [[link 1]],
  [[link 2]] 
]}

  • I don’t want to put this in the frontmatter, because it’s more natural to have read this list at the bottom. Plus that links aren’t fully supported in there

  • If I use the Dataview inline, i.e. subcategory:: [[link 1]] [[link 2]], then it will be cluttered if there are many items and the links are long (alias won’t help)

  • If I use tasks instead, i.e.

    - [ ] [[link 1]]
- [ ] [[link 2]]

    then I can only query them with file.tasks, not with the actual key I want. The checkbox also gives me false impression.

  • If I separate the list in multiple lines, i.e.

    subcategory:: [[link 1]]
subcategory:: [[link 2]]

    then it will be acceptable in this case if I ignore the repetition. So you can say this can be the solution for this case. But from here I just want to generalize the question

#7

OK, that’s a helpful example, thanks. I don’t usually use YAML front-matter for Dataview fields either, because I like having them visible in the page when rendered.

When need multiple values for a field, I usually use multiple definitions like in your example above:

Field:: value1
Field:: value2

#8

Another example would be to declare metadata for non-existing files. For example I may have

[[link 1]] : {
  key 1: "value 1",
  key 2: "value 2" 
}

While link 1 hasn’t created yet. This is extremely useful if you are working with graph database. See the Link Types - Juggl

#9

YAML is quite commonly interpreted by markdown editors, JSON isn’t.

I don’t think anything stops a plugin designer using json.

1 Like