My frontmatter and note content currently has a lot of duplicated info depending on whether I want to use certain functionality that wasn’t available in the frontmatter before, i.e. links and clickable tags. The new properties pane recognizes links if they are formatted as wikilinks and in quotes in a text property: “[[link]]”. Tags are only currently recognized inside the tags key.
Recognize text properties as tags when formatted as such, similar to how wikilinks are treated:
Sure, here two simple examples from my vault (which I already refactored, so I’ve removed some duplicate information already).
First, a meeting note. The blurred text is a link to my project note. The question I was facing was whether I should have a new tag project/meetings/type/workshop instead of the meeting_type: "#meeting/workshop":
Next, a project note for one of my papers. Status could be status: "#in-progress" instead of what I would use if I moved that piece of metadata under the tags key, which would be something like project/status/in-progress:
Thanks for your answer. I see that you want to use tags and nested tags, like
Then for some reason you also want to add custom metadata that encodes
Again I’m not sure what your problem is, but it seems very special case to be able use Dataview and tags simultaneously to query a note. But I think you will be using more complex Dataview queries compared to search by tags, hence you want to use both. Or maybe your problem is very different.
That is the point, I don’t want to do that. I want to only have status: "#in-progress" which is not recognized by the property editor at the moment, as the status key can’t have tags.
I don’t use dataview, so tags are really useful for searching in my case.
Is quering using status/in-progress different from in-progress? Or your problem is to avoid typing the name of a tag query when you add it to front matter. So in essence you want three things: use frontmatter to access and make tag queries, get guidance what the tag query is about, avoid typing the guidance repeatedly?
±1 for this. I have the exact workflow as argentum. I would use tag project status as #Project/InProgress, #Project/Concluded, etc.
Good thing about using tags is that I can do quick search by clicking the label. Also when I use with dataviewjs grouping, it gives a nice separator because tags can be formatted like a pill shape. If I were to group with typical text based value, I don’t think I can format that
I would like to explicitly express a “+1” to this by means of this comment. I’m already typing tags on various properties (e.g. state: "#state/todo" ) and having obsidian recognise this would be amazing!
+1 for this feature request - this is +++ necessary for anybody who uses tags as ‘values’ of inline key/value pairs (so that they can be fetched by dataview - whichever_key :: #value_as_tag) and wishes to transition to using properties.
I confirm that the feature request is the following: treating YAML key : "#value" entries as tags rather than dead text (indeed the # character is escaped because it is in quotes), akin to the way key : "[[value]]" entries are treated as internal links (which is what the new property type ‘text’ maps to under the hood).