Automating "MOC" Management with Embedded Queries

[lynma01]

Hello, Hello-

Use case or problem

I think there should be an option for embedded queries in organizing-notes (like MOCs or TOCs) to reactively update to changes in the greater Vault. So one would have a template-able means of creating MOCs/TOCs that automatically update, expand, contract, and organize themselves.

The difference between this and the Expander Plug-in, is that once the tag parameters are set, the note updates itself without having to manually re-execute the command in the palette. So one wouldn’t have to re-run the search command for the “Newly Added Book” file to pop up in the query results as it did in the Expander Plug-in’s demonstration gif. Very similar to the Continuous chronological feed of daily notes, but implementable for all types of notes.

While this may seem a trivial problem, which is also mitigated by one’s knowledge management system of choice, having to run a command to update every MOC becomes laborious.

Proposed solution

The Expander Plug-in seems, to me at least, 90% of the solution to the problem. The ability to embed queries underneath Markdown headings with:

    {{tag:#tag}}

also allows a note to have multiple headings with multiple embedded query results. The 10% of functionality that isn’t there is a timer or something similar to the Automatic Git Backup Plugin.

Why should this be a core-feature as opposed to a plug-in? (I’m guessing that) Because of the popularity of automation threads, especially ones for creating TOC’s, and date-breadcrumb trails- this kind of feature seems to be pretty central to the way many users take notes(?).

Current workaround

The current work around is pretty easy but very manual:

“select the files in the sidebar, and drag them into a new note. It will make links for them, and then I can edit/sort/process the links in that new note.”

Related feature requests

This is a significant expansion of this feature request. I very much agreed with it and I believed there were enough citations/references that just a comment/reply seem inappropriate. But, then again, this is my first time posting anything outside of instagram- so hello, lovely to be here.

Obligatory first-post thank you:

Huge thank you to the Devs: this app changed my life. As a uni-student, it made me completely reconsider the way I think about learning.

[atiz]

Currently I just embed a query for the filename itself. E.g., in every literature note I have, I list all the pages that mention that note.

```query
[[filename]]
```

I do the same with certain tags to create MOCs.

(The expander plugin is also good for this kind of thing, but as you mentioned, it does not refresh on its own, so it’s better for more static things. Embedded queries do refresh though.)

Would this be most of what you would like?

[lynma01]

Yeap! I would say that you have 90% of the solution. The last bit is just the refreshing part. This would be most of what I’d like.

What do you mean when you say embedded queries refresh? Like the list of results the query returns expands and contracts automatically? Or that number of query results stays the same but reflect filename changes?

[Thecookiemomma]

The one drawback I’m seeing to this is that the query does contain the self-reference, that is, the first line is always, “Oh, you typed [[title]] for the query, so there’s one link…” Is there a way to avoid that?

[atiz]

By “refresh” I just mean that if you create a new note with a link [[filename]], then the embedded query list in ‘filename’ will refresh to include that new note as well. So in that sense, it expands and contracts. And yes, it also reflect filename changes.

As for @Thecookiemomma, I think I have seen somewhere on this forum some syntax to avoid self-reference (somehow by excluding the current file from the search). I wish I remembered how to do it, I just have not been bothered enough by it to try it out.

[lynma01]

Oh, I didn’t know that. Good call.

So I gave it a shot and functionally, you’re spot on. But one thing that I’m concerned about is that the note retains its MOC structure/functionality “hard-coded” links.

While the query embed does expand and contract as you’re describing, the actual text-list in the note does not. So I’m guessing that the amount of links to and from the MOC don’t reach the files themselves.

At this point I’m torn, because functionally your reply does 95% of what I’m asking, but the only difference is how the vault looks in the graph view with note links.

At this point, the work around looks like this:

Heading 1

``` query
[[filename]]

Link List

1.[[filename_1]]
…
n.[[filename_n]]

[atiz]

Yeah, I know it’s not 100% ideal, and I wish too that there was a better way. It’s just the best work-around I know.

FWIW, I use the Expander plug-in for more “constant” MOC’s (i.e., those that I’m not working on at the moment, and that I expect not to develop too much further), and the built-in query for the more “developing” ones. There are some things about the queries that bother me too; the display format is pretty ugly (although I have just seen a way to customize it, will try); you don’t see much context, there is the highlighting for the term that’s unnecessary, etc. And structurally, hard-coded links would indeed be nicer.

Anyway, if your described feature gets developed, I’ll be happy too :).

[lynma01]

Cheers man,

I’m going to update the original post to incorporate your points and work-around. As well, using the stuff you brought up in my own work-flows so thank you.