I’m trying to create a property that is of the type “tag.” But it looks like there is a fixed “tag” property and you cannot make any custom property of the tag type. Is there any plan to change this? I would like to migrate my meta-data over but in my meta data I have certain things I use tags for and I’d like it to have more context than simply being added to “tags.”
5 Likes
I assume since there were no replies that there is no plan to allow properties of the type “tag”? We can only have one “tag” type of property?
According to the help docs, there are a few property types predefined for Obsidian:
Yes I understand that. My point is that when you create a new property you can give it a “type.” And every “type” is an option except “tag” although “tag” is shown as a type on the default “tags” property. My question is why can’t we create a property that does not replace the default “tags” property but it of the tag type. It seems pretty natural that user defined properties should could be any property type that Obsidian understands and “tag” is a property type but for some reason cannot be applied to any other property than the default “tags.” That is what I am questioning. It does not seem difficult to let us define other properties that could also use tags.
1 Like
If you don’t get any responses here, I’d suggest checking out the Feature Requests category, and posting there if you don’t find anything on this already.
To use tag as a key / keyword for something other than tags?
That’s been deprecated since 1.4.
As of 1.4.0, we’re deprecating the “tag”, “alias”, and “cssClass” frontmatter keys. The new property editor will automatically migrate to
tags,aliases, andcssclassesand the values will automatically be converted to lists.The old keys will still be identified correctly in the app, but the property editor will always prefer
tagsandaliases.
Apologies if I have misunderstood.
What’s your purpose for this? Are you filtering by these additional fields? As posts above mentioned, they don’t allow for additional tag fields in the frontmatter.
Two workarounds may help:
Obsidian allows for subtags with #index, #index/subtag1, #index/subtag2, etc.
OR you can commit like I did and have dedicated YAML fields that behave like tags. I reference these through Dataview with
WHERE contains(frontmatterName, "frontmatterValue")
Here’s a screenshot of the “zettelkasten tag” that I adopted.
FYI - there is a feature request for this submitted by another user: Add a property type for tags / multiple tag-based properties
1 Like
Edit the file .obsidian/types.json, change the type to tags then restart Obsidian.
2 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.