Properties: Recognize tags in text property when formatted as "#tags"

[argentum]

Use case or problem

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.

Proposed solution

Recognize text properties as tags when formatted as such, similar to how wikilinks are treated:

new_tag_property: 
- "#tag"
links:
- "[[wikilinks]]"

Current workaround (optional)

N/A, currently I duplicate information under tags and their individual properties where applicable

Related feature requests (optional)

Add a property type for tags / multiple tag-based properties

Use case or problem I would like to be able to use tags as data for a given property that is not the default “tags” property. For instance, tags could be the property type for a “Company” property so that when I search for #CocaCola, the results will include both uses of the tag and files where the “Company” property is #Cocacola. Proposed solution “Tags” would be a property type in addition to “Text,” “List,” “Date,” etc.

[WhiteNoise]

Currently, the text type in properties recognizes both simple text and [[wikilinks]] (not mixed). It would be desirable for it to recognize/handle tags like "#atag" as well.

[ryadaj]

Would this allow the following? (Just attempting to understand)

---
type: "#type-of-note"
---

instead of

---
tags: type-of-note
---

[WhiteNoise]

yes, that is what is being asked here.

[blue_emperor]

I’m just curious and try to understand your problem. Can you give concrete examples of what you mean by “duplicate information”.

I’m not sure how to view tags of a note without plugins but at least you can use symbols mode in QuickSwitcher++. Does that solve your problem?

[argentum]

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:

Moving them to the tags key is not wrong, but the proposed FR makes it more flexible. Concretely, if this doesn’t get implemented, I might have end up with something like:

---
aliases: 
- 
tags: 
- project/paper
- in-progress # This is repeated
publish: false
status: in-progress
date created: 2022-08-22 18:57:26 +02:00
date modified: 2022-08-24 21:54:54 +02:00

I don’t think QuickSwitcher++ addresses any of this, since this is about the new Properties Editor, but if you have some pointers, I’ll look into it.

[blue_emperor]

Thanks for your answer. I see that you want to use tags and nested tags, like

project/status/in-progress

Then for some reason you also want to add custom metadata that encodes

status: in-progress

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.

[argentum]

@blue_emperor

I see that you want to use tags and nested tags, like

project/status/in-progress

Then for some reason you also want to add custom metadata that encodes

status: in-progress

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.

[blue_emperor]

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?

[argentum]

@blue_emperor

Is quering using status/in-progress different from in-progress?

No, functionally it is the same.

@blue_emperor

Or your problem is to avoid typing the name of a tag query when you add it to front matter.

Autocompletion is nice, but I can live without it.

@blue_emperor

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. I want my metadata to contain all my metadata, and I want to be able to interact with it, e.g. click on the tag to open the search.
2. I want to be able to exploit the features for what they do best, a #tag is searchable, a [[link]] is clickable.
3. I don’t want to have to add semantic information to my tags, e.g. having to add project/status/ to my in-progress tag, to do 1.
4. And yes, I don’t want to have duplicated information to be able to do 1.

[blue_emperor]

Ok now I understand but it wasn’t easy. I think it’s not obvious to do things like you would do, but your approach will improve how one should use tags and nested tags. Thanks for clarifying it!

[argentum]

Glad that made it clearer!

[efemkay]

±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

[nhanjkl]

I just read this comment here by @anon63144152 that # in YAML is interpreted as comment. Does this FR make YAML in Obsidian not follow the standard regarding hashtag in YAML?

[anon63144152]

This feature request escapes hashtags by using speech marks. Try the sample headers below in a local file. This one validates as YAML in reading mode:

---
key: "#sample"
---

This one doesn’t:

---
key: #sample
---

It also wants users to be able to use the # sign in values for keys that aren’t tags.

[CawlinTeffid]

To slightly expand on what eightning said: in YAML quoted text is a string, so a # there doesn’t start a comment.

[dbarenholz]

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!

[ms047]

+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).

[TomYeoman]

Here’s my use-case I can no longer support using properties instead of metadata.

I often have multiple properties where tags seem like a better match than page links?

There’s a few reasons I want a tag instead of a page here;

• I don’t really need a specific page for every tag (I.E for #gym), I just want to explore the topic
• A page would end up living in the wrong place (topics could be linked from any folder, such as /Atom /Molecule or /Source)

I see 2 workarounds;

• No longer use tags, and instead use [[Topics/topic]], but the old way just worked much better for me, I don’t need a dedicated folder for this.
• Just use property type “List” and add all my topics this way, but I can no longer click to explore, I must use the “Search” tool with ["topics":phil]