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.

24 Likes

As an alternative, it could be possible to recognize text properties if formatted as a tag, e.g.

Company: "#CocaCola"

I opened a separate, slightly different, request for this: Recognize tags in text property when formatted as "#tags"

3 Likes

I would like this too. Either way.

Another potential solution/workaround would be to use nested tags. For example #company/cocaCola

I believe Tag Wrangler will also organize the nested tags as “folders”

I use tag wrangler already for somewhat similar applications. Probably the best workaround.

Yes - please add the option to create a specific property and give it a “tag type.” I don’t understand why only the default “tags” property can be “tag type.”

3 Likes

I just started using properties and was surprised that I couldn’t do this! It would be lovely to organise “types” of tags without having to make everything nested. I was going to use it to differentiate my “category” (ie daily-note, personal, research) tags and my “topic/subject” (ie knitting, math, etc) tags.

1 Like

I believe Tag Wrangler will also organize the nested tags as “folders”

You may be thinking of the TagFolder plugin

No, I’m thinking of Tag Wrangler. The ReadMe says it supports child tags.

+1 for this, I use a template and DB Folder for keeping track of meetings and properties broke my system.

For example, the front matter used to look like:

---
Meeting_Type: internal (type = tag)
tags:  (type = tag)
- company_name
- OneonOne
Meeting_Date:  (type = text)
---

I can come up with an alternative system, but its a pain to go back and update a bunch of files. Plus now the “Type:” column in DB Folder has the original “internal” tag AND “[,Internal]” since the update changed my property type to text.

bumping… enabling multiple tag properties is exactly what i’m interested in, also!

for overall vault organization, it is helpful for me to have tags manipulated in the tag wrangler and to be used to tag more meta-level note info (e.g. #status/to-read, #status/done or #note/personal/meeting, #note/personal/etc) – i never really used tags for “keywords” to avoid cluttering the tag pane and just kind of blindly typed into the search and prayed whenever i actually looked stuff up. (i wasn’t interested in grouping my keywords by [[wikilinks]] either – didn’t really produce the results i intended on in the graph view.)

with the properties update, i’m now using a system like this to track keywords so i can make my searching easier. the autocompletion is really helpful!

ultimately, would be ideal if i could somehow handle these keywords them as tags the way obsidian currently handles them… i dont mind if i have to do something like #keyword/xxx to reduce tag pane clutter, but i’d at least like to keep keyword tags property field separate from my categorization tags property field.

1 Like

+1 for this feature!

Properties in Obsidian has been a wonderful addition to how Obsidian works. But the current restriction in Properties that only allows tags that function like tags to be used in the “tags” field feels unnecessarily restrictive and counter to the natural use of Properties.

+1 to this. My use case is similar to others - I want to use specifically named properties but be able to use tags as the values, so I can categorise (including nesting substates) to search/filter/group much more easily in things like Dataview. Examples to make this clearer:

  • media property using tags of #book, #article, #video/youtube, #video/vimeo
  • status property using tags of #inprogress, #review/first, #review/second, published

Workaround at the moment is using a root tag to group things up, and putting all of them into the tags property eg. #media/video, #media/book, etc. However, I find that it’s easy to forget things, it’s messy and not very scannable when looking at a note, and I can’t structure specific concepts in templates against specific types of notes (for example a source note has a media property but an evergreen note doesn’t, and I’d like to represent that in the template for the new notes of that type. Being able to create a property as a top-level bucket that can hold the tags would remove all these issues.

An addition to this, I’ve been experimenting just using properties and values. But two main issues have come up with this approach for me:

  • this doesn’t give me nodes in the graph ie. A node for type: note and a node for type: resource
  • filtering via properties is possible (either in the search or the graph) but it gets really fiddly to work with the text, especially when they’re nested or there is duplicated bits of text

I note that both of these issues are fixed if we can just set a tags type on the property.

+1 for this. It’s wild that obsidian is so restrictive in this feature…

You can just change types.json to have multiple fields of type ‘tags’ - they all autosuggest all tags, but it works fine. I’ve written an Implicit Tags plugin for personal use which always automatically adds relevant tags associated with a specific tag. Under water it adds those tags also to the cachedMetadata.tags field so they all are searchable as tags. Works great.

Interesting, I gave that a go and it didn’t work - field was still treated as a plain text field, no autosuggest behaviour or anything unusual. I’ll have to try again…

It’s working! Don’t know what I was doing differently/wrong beforehand, but I’ve got it working now. Thank you for prompting me to give this another go! Solves so many things that I wasn’t quite happy with in managing my vault :tada:

1 Like

Oh wow. This is potentially a game changer for me. I’m just a bit cautious/curious before I implement this. How does this file work? Why do I see a bunch of properties there but many of my properties are not listed there? What if I create a property in types.json and it matches the key of another property not listed in the file?

Doesn’t quite work right for me. I can add the property and it behaves like a tag property ostensibly. But in the tag pane I dont see the tag counter go up when I use a tag in that property. And when I search by that tag I dont see the note in search results.

If I invent a new tag in that new property, the new tag doesn’t appear in the tag pane.

Do you experience the same? And does this issue not negate the usefulness of this for you?