Surely a property entry for “tags” for (say) self should be semantically equivalent to body text of #self. But using the Core Search plugin, a search for
tag:self is not equivilent to #self
---
tags:
- self
---
is not equivilent to
body text #self
Is this an intentional distinction?
Oh, I deeply agree here.
I’m not sure how Obsidian has been handling multi-term tags with the hashtag, but that has been really helpful. But, when searching across all my files I can search with the “#” and know I’m getting everything with that tag, no matter if I’m in Obsidian or not.
I use tags lightly and mostly in front matter and occasional inline at the end of a block or paragraph to pull that section in with a search. Tags are like hooks to pull things together. In the mid-2000s onward I was one of “the” tagging people going to academic, standards, and developer conferences walking people through the use, particularly for personal vocabulary expression (but, far beyond that as well).
The great thing about markdown is you can have a #tag, but also in tools like Obsidian an other services in the last 5 years you have a backlink to use a bridge to a related resource, which functions very differently from a tag. The two methods should never be combined into one. Their use and purposes are do not align and shouldn’t be treated in the same way because of that.
The query tag:self searches the tag index, so it picks up all tags. Searching #self does a plain text search for that exact string, which doesn’t appear in your example.
Yeah that’s exactly the problem. Surely a metadata tag in YAML should be treated the same? Isn’t #self a tag of “self”? The Tags core plugin thinks that #self is. I’m confused.
No, because a search for #self isn’t a tag search. It’s a search for that literal text string, like a search for se#lf or self#. If you have a url like https://example.com/realms#self it will match that; tag:self won’t because it’s not a tag. If you want any kind of special search that does something other than searching for literal text, you need to use a search operator.
Not only does the tag plug-in think it is wrong, but so does every other markdown app that also uses these files.
The great advantage of Obsidian is it has lived wonderfully in an ecosystem of other markdown apps and services that can have extended capabilities with things they can do with markdown.
Changing to a non-standard method of tagging breaks the reason many like and love Obsidian, which is it has been a really good member of an ecosystem that extends capabilities of markdown notes in a folder without breaking anything for any other app or service.
+1 for being able to use tags as data for a given property that is not the default “tags” property
-1. Disagee 100%. A search for #tag has been a tag search in Obsidian up until this point. Ask your users what they expect & I bet 99% of people would agree. And even your own Tags plugin agrees.
I really hope that the Obsidian dev team changes their mind because its either an oversight or the first big misstep the team has taken.
Searching for #tag in the search pane has never been a tag search, it searches notes that contain that exact text, which won’t return a note that uses the tags: field in the frontmatter.
Regardless, I have to confess I’m a bit at a loss as to how this relates to this FR? I’m afraid that it’s getting a bit off-topic.
I think differentiating between #atag and tag:atag is a really bad call & is going to upset & confuse a lot of your users.
And “Searching for #tag in the search pane has never been a tag search” is not how tag search works in “my” Obsidian (1.4.1)
(tag:#self and tag:self produce the same results)
Or how the tag plugin works
Those both contain the literal text #self.
we’ll agree to disagree. I can’t think of a single example in an app where the hashtag has ever been differentiated from a “tag”. Also the tags core plugin has always worked with (at least) hashtags. Regardless of these results, I think differentiating between #atag and tag:atag is a really bad design call & is going to upset & confuse a lot of your users. I hope the product team changes its mind.
I’ve split this discussion out from Properties: Recognize tags in text property when formatted as "#tags".
Hashtags aren’t differentiated from tags. They and YAML tags are both added to the tag index, which you search by using the tag: operator (or by viewing the tags tab). Their plain text forms differ because Obsidian is using 2 common conventions (hashtags and YAML) that weren’t designed to go together. The inconsistency is awkward and causes some misunderstandings, but so far the confusion levels seem manageable.
(Also I assume you mean “your users” rhetorically, but to be clear, they’re not mine — I’m just a volunteer).
I haven’t even been aware that there was a distinction between tags and hashtags until now. I think that the addition of the really great Properties feature in 1.4 will make this distinction obvious to most users for the first time in a way that causes unnecessary confusion.
Yeah, the main source of confusion will probably shift. Until now I think the worst, commonest tag confusion has been people putting hashtags in the frontmatter field, not realizing that they don’t work. “Why aren’t my tags appearing in search?” Some people didn’t notice it didn’t work for a long time because they always searched #tag instead of tag:. 
If you like you can file a feature request for #tag to be a tag search instead of a plain text search (tho there’d need to be a way to do a plain text search version). Or actually search the forum first in case it’s been requested already. I wouldn’t pin hopes on it being implemented, but who knows? There are arguments for it.
Related issue: with the new ‘properties’ feature in obsidian 1.4 (which if I understand correctly is simply a shiny user interface to edit YAML fields - which I think is great), given that the ‘text’ and ‘list’ property types now handle internal and external links, shouldn’t they also handle the # syntax for tags? I find it confusing that 1) “tags” are a property NAME and not a property TYPE 2) it is impossible to add a bunch of tags in a text property.
For that reason, it is sadly impossible for me to drop the “::” dataview syntac and fully switch to properties:
So that it is possible to have clickable tags in dataview fields:
The current system allows to distinguish between frontmatter and inline tags in search, which is supremely useful. For example, I may want to find all instances of inline ‘#ToDo’ in my vault (and exclude from search notes w/ ‘#ToDo’ in frontmatter) or vice versa. If “#example” was treated the same as “tag:example” in search, this wouldn’t be possible.
I tested this and ["tags":xxx] make exact queries to frontmatter meaning #ToDo and ToDo are slightly different. Then tag:xxx queries both inline and frontmatter results and it doesn’t matter if you use hashtag in the frontmatter or not. Then finally searching #ToDo will include frontmatter and inline tags if hashtag is used in the frontmatter. If you want to exclude frontmatter results, you can use -["tags":ToDo] tag:ToDo or -["tags":ToDo] #ToDo. I think the current behaviour of hashtag vs no hashtag in the frontmatter is confusing, because you can use these three queries to select the correct option:
["tags":xxx] (only frontmatter)-["tags":xxx] tag:xxx (only inline tags)tag:xxx (both frontmatter and inline tags)In these queries property search is used to indicate if frontmatter results are included and one doesn’t have to decide whether to use hashtags in the frontmatter or not. I think searching #xxx works fine because one should know about tag:, [tags:xxx] and -[tags:xxx].