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

Feature requests
,
15

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?

16

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.

3 Likes
17

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

3 Likes
18

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!

5 Likes
19

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

2 Likes
20

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]

image
image1277×605 22.3 KB

2 Likes
21

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

22

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.

23

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/image or #image/findMe
24

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.

25

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
26

+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
27

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 then relevant-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:

  1. Always add a space when entering tags via the Property UI as it will not allow a # to begin a text value.
  2. If searching for a tag, I use the following method: #tagname OR tag:#tagname
  3. If wanting to autocomplete the tag name for other properties, I must enter it via modifying the file source.
  4. 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
28

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/WIP then I can easily rename all fields to #Status/WorkInProgress through the hashtag tools. I can also view and add restrictions in the topology graphs using the tags.
1 Like
29

You can do this with non-tag properties, too.

30

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.

31

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.

32

Yup - exactly the problem (I actually went down that route and abandoned it). Thanks for the feedback!

33

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?

34

+1, what more would be needed for this to be implemented ?