Using nested tags as dataview-field


I found some use cases for assigning strings to tags, for example for building a health diary with dataview from my daily notes.
While writing my daily notes I would e.g. write #on/health/spine:: went to doctor today, he told me xyz.

Using $= dv.span( dv.current() ) in that daily note, showed me, that the note has the tag #on/health/spine and the dataview-fields

  • on/health/spine and
  • onhealthspine (I learned, that this is the normalised dataview field version of the the field on/health/spine


Table onhealthspine
From #on/health/spine

shows me all my entries in my daily note about spine problems/comments.

Here are two problems with that approach:

  1. the slashes in the nested tags don’t work in the dataview-query, so I have to use the normalised dataview-field in the DQL
  2. updating my tags with the tag wrangler plugin, doesn’t update the a) tags in dataview-queries in general and b) especially not the normalised dataview-fields…

So my request is:

  • Would it be possible to use nested tags in dataview-queries?
  • Would it be possible to combine the tag-wrangler plugin with dataview, so that updates in the tag-names, automatically updates the dataview-queries?

I don’t use dataview, but this strikes me as an unusual thing that is unlikely to be supported. I don’t know what the benefit of this technique is, but hopefully there’s another way.

  1. You can use just tags, scoping them to a list view item to associate just the text you want.
- went to the doctor today, he told me xyz. #on/health/spine
  1. You can also do the same thing with inline datafields, with various ways:
- went to the doctor today, he told me xyz. [topic:: health] [topic:: spine]
- went to the doctor today, he told me xyz. [topic:: health-spine]
- went to the doctor today, he told me xyz. [topic:: health] [subtopic:: spine]
  1. Or a mix of tags and inline metadata (where “mix” means individual separate tags and data items, not chimeric constructs of the two :wink: :laughing: ) :
- went to the doctor today, he told me xyz. #on/health  [topic:: spine] [doctor:: who] 

Of these, I think I might go with - went to the doctor today, he told me xyz. [topic:: health] [topic:: spine] as being the simplest and maybe most useful. I know, it doesn’t capture the hierarchy that you want. But it opens up the possibility for nicely co-querying your concept notes for “spine” topics, etc.


You can also use row["on/health/spine"] (or row["#on/health/spline"] see caveat towards the end) , if you prefer the version with slashes. So you don’t have to use the normalised version.

This is a lot harder, as in general most plugins don’t touch what’s inside other code blocks.

It can in some cases be countered by using intermediate fields to keep the tags outside of the query, and then use that field inside your query. This can become messy, though.

So something like the following would work:

[#on/health/spline:: My value]

searchTag:: #on/health/spline 

LIST row[this.searchTag]
WHERE econtains(file.etags, this.searchTag)

Whether this is recommended, or usable is another issue. But it does allow for the tags to be changed by Tag Wrangler, and at the same time excludes the use of the tags inside the query. Similar trickery can be used to define links outside of the query, thusly allowing them to be renamed by Obsidian.

One caveat that follows with this trick is you can’t do FROM this.searchTag, you do need to rewrite that into WHERE econtains(file.etags, this.searchTag) or variants like that. (Occasionally you might have a little race condition on updating the searchTag vs the cached queries, but these can be solved by reopening the file)

Another caveat is that defining fields like this is sensitive to the syntax as well. Consider the following example:

#a/nested/tag:: nested value
[#another/nested/tag:: another value]

If looking at the fields defined, we get this output:


So if unbracketed, it’s just the non-hashtagged tag which is used, and if bracketed, it’s the full tag which is used… The normalised version stays the same.