I actually find this solution elegant because it’s more clear what you are trying to do. With tags it’s more vague because you could use tags to categorize tasks for example. Tags could be used many different ways other than just specifying document topics. You could use obsidian advanced uri to open search bookmarks. It requires some tweaking to generate these links automatically when you add topics property, but this could be a new feature request or plugin idea (regarding any text or list property).
Yeah I do see your point here, the chance of tag collision against irrelevant pages is high, versus more using a more specific property!
I still find it a little hard to understand when we should use “tags” in this new world, seems like it’s no longer a universal tool.
Some thoughts about how to use tags:
Beyond using tags when creating tasks they could be used to mark parts of your note that needs some future action. Even if you use only one tag for this like #findMe, it gives your consistency how you will mark content for later processing. The global search is very powerful because it shows context. There is Floating Search plugin that brings that feature to file-based search.
Other ways to utilize tags:
- mark concrete elements in notes such as lists, images, tables, comments, formulas and then use search to quickly navigate between images etc (the symbols mode of QuickSwitcher++ partially implements this)
- mark more abstract structure in your notes such as references or content based on references
- categorize images, tables etc using nested tags like
#image/low-quality - target specific elements that need future action using nested tags like
#findMe/imageor#image/findMe
But that is the entire point of this FR. Tags can be used however a user sees fit, not just for tasks or actions.
In this case, if you’ve used the #philosophy tag elsewhere, e.g. to categorize a single line in a note, when you click on the #philosphy tag on that note, this example won’t show up unless you duplicate things like I’ve mentioned before. The workaround with advanced URI on top of being more complicated doesn’t solve this.
If this is implemented, I think it would be ideal to be able to convert existing text properties into tag properties across the vault. I.e., if I have the following:
status: doing
I want to be able to right click “status” and then assign it the “tag” property type, while maintaining the same label, so that the values wherever they appear in the vault, are converted to tags so that:
status: "#doing"
Related to this may be my feature request: Properties Wrangler: Add a way to “Insert”, “Rename” and “Remove” properties and values in all files
2023-10-08 edit: This would mean that list items which are more than one word, e.g., firstname lastname would need to be converted to tag-friendly format on version from a text or list property to a tag property, i.e., replacing the space with a dash, so firtsname-lastname
1 Like
+1 for this feature request. I don’t see why this isn’t a standard feature of properties. In order to properly assign metadata to a file you need multiple tag-based properties. Otherwise you would need to use one property and place all of your tag metadata into one long line. Properties where it usually makes more sense to use a tag instead of a page are status, type, tag and maybe something like rating.
Is there any updates or news, if or when this request will be implemented?
4 Likes
I’d love to add in that there are many use cases in which it would be useful for #hashtags to be recognized in other properties. For instance:
-
What if I want to categories my tags into groupings, e.g. “
subjects: #philosophy, #science”, and thenrelevant-authors: #Kant, #Hume -
I’d love to have some properties be filled out with hashtag values, like “
status: #status/incomplete”. This allows me to use the same tags that I might use inside the note to tag a paragraph as incomplete. -
There are some tags that are in orthogonal spaces to the typical tags. Again for these, it would be good to group them into their own properties. For instance, I store “mental models” as tags. For each note I have a list of mental models used in the YAML code:
Mental-Models-Used: #MentalModels/Munger/Scaling #MentalModels/Physics/GravityWells
Previously I used YAML Anchoring (a pretty advanced feature) to feed everything into the Tags field, but anchoring is not officially supported in 1.4.
To work around, I must:
- Always add a space when entering tags via the Property UI as it will not allow a # to begin a text value.
- If searching for a tag, I use the following method:
#tagname OR tag:#tagname - If wanting to autocomplete the tag name for other properties, I must enter it via modifying the file source.
- And lastly, I must give up on the tags used in properties in being displayed on connectivity graphs or tag lists.
I add this to the discussion because the original request for the feature was in a very specific use case, but I’d like to highlight that the request is far more reaching. Thanks!
2 Likes
And two more use cases:
- I have some metadata fields (aka properties) that I want to restrict the answer to a known set of answers. With version 1.4, having the UI present a list of known entries helps, but it is an emergent approach. By allowing for #hashtags to be entered instead, then my vault can have a dedicated system page that lays out the possible hashtags (and thus populating the auto-complete database) for any field. I use this all of the time.
- By allowing hashtags for other properties, it allows for Obsidian’s hashtag capabilities to be used on them. For instance, say I have a property called “status”. If I could store the property as a hashtag, e.g.
status: #Status/WIPthen I can easily rename all fields to#Status/WorkInProgressthrough the hashtag tools. I can also view and add restrictions in the topology graphs using the tags.
1 Like
You can do this with non-tag properties, too.
Thanks for chiming in, @CawlinTeffid
Agreed that the ability to have it auto-complete non tags is a feature (thank you devs!). But there are times when I want to pre-define what the possible values are for a property. Say you want to store the current development status of a note in a property (active, finished, blocked). If properties allowed for tags, I could create a system document page that spelled out the official tags allowed for that property (#Status/Active, #Status/Finished, etc.). Then, when a user fills out the property for that tag, these are all prefilled and there is no ambiguity. If you use the non-tagged solution, you will have to look it up at least the first time for each possible answer to check the phrasing and spelling.
And by the way, one more use case for allowing tags in properties. For even the basic need to record relevant #hashtags in the tags: property, I often need to add some contextual text around the #hashtags (e.g. "#Status/Blocked - Need to get feedback from Jim). The tags: property however only allows pure tags and no context. That’s ok, but I’m hoping we can still add other properties that will allow embedded #hashtags in them, and for those to still be recognized.
You can predefine the values of any property by making a guide note that contains the property filled with the appropriate values. Altho now that I think of it, if the property type isn’t a list you’d have to make a note for each value, which would be bad.
Yup - exactly the problem (I actually went down that route and abandoned it). Thanks for the feedback!
BIG +1 for this feature request.
It’s been a while since it was originally posted. Does anyone know if there’s been any feedback or movement on this?
+1, what more would be needed for this to be implemented ?
Also I don’t think it was mentionned here before, but a work-around is to use inline properties:
Some text
property:: #tag
1 Like
That assumes you are using a community plugin that supports that, which is not a core implementation. (Clarifying for people that might not know that).
2 Likes