Would this allow the following? (Just attempting to understand)
---
type: "#type-of-note"
---
instead of
---
tags: type-of-note
---
Would this allow the following? (Just attempting to understand)
---
type: "#type-of-note"
---
instead of
---
tags: type-of-note
---
yes, that is what is being asked here.
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?
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.
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.
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.
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?
No, functionally it is the same.
Autocompletion is nice, but I can live without it.
#tag
is searchable, a [[link]]
is clickable.project/status/
to my in-progress tag, to do 1.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!
Glad that made it clearer!
12 posts were split to a new topic: Property entry for “tags” should be semantically equivalent to body text hashtags
±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
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?
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.
To slightly expand on what eightning said: in YAML quoted text is a string, so a #
there doesn’t start a comment.
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!
+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).
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 see 2 workarounds;
["topics":phil]
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.