As i outlined in my other post, we can mimic roamresearch tags by using [[tag]] instead of #tag to tag a page, and using backlinks instead.
I really wish this was part of the default design philosophy.
Currently tags are special case and must be opened in a new window.
Instead, obsidian can treat a #tag as just a regular link to a page - and maybe clicking on it would automatically bring up backlinks.
This removes a mental burden of thinking about tags as something special
If you want to implement tags with pages, you can do so. As you have discovered, it works the exact same way as it does in Roam.
Other people prefer to have a sharp separation between pages and tags. Where concepts are mapped with pages and statuses are mapped with tags (read, todo, someday, athome).
In graphview, which is supposed to be a network of concepts. Does it make sense to see pages that are actually just tags/statuses.
I am sure some people say yes, most say no.
Interested in the discussion. What would be the fundamental difference in usage that matches Obsidian’s UI with tags. In other words, there are only a couple differences between tags and [[pages]] in Obsidian from what I can tell (other than the visual difference).
Tags:
Tags don’t show up in the graph view
They look different in the document
(though if used outside of obsidian, tags are nearly universal, where bracket links are not)
Pages:
When click on page links highlights the line instance in the document.
They are a part of the graph view.
So my question is, what functionality in Obsidian do you get by using a tag instead of a page? (I mean this without reference to outside software that recognize them as quite different)
PS. I assume tags will become a huge part of filtering/searching in the future?!
You can make a page link #likethis automatically act as a tag.
You can also hide the #pagelinks like that in the graph view.
The benefit of having it as a page is that you can document a tag. That’s pretty much the only advantage. That, and having two concepts become one - which I think reduces the number of different elements (but that’s not that important).
Yeah, all of this can automatically be achieved based on a convention.
If a page link is #likethis, then treat it as a tag i.e. a page that you don’t show in the graph view.
If the page link is [[likethis]] then treat it as you do now.
No, features are meant for most users. It happens that features may be useable for a small group only, but on the whole they should be, and generally are useable for the majority. Otherwise we end up with an app of which only a small part is useable for each user.
And here we’ll have to disagree A user may of course use his/her own usecase as a base. Then we’ll see if the idea gets traction or not. Neither you nor I know how many users may benefit from an idea.
In the end, we have the developers to work on this!
Let’s try not to derail this thread in to off-topic land and leave it at that you and I disagree about this.
I have no intention of derailing this thread after the previous altercation.
You asked me a question, presumably to get my opinion. I proffered it, you disagree. That’s your privilege.
You seem to agree though that an idea, i.e. a feature, needs traction, i.e. become popular, i.e. become used by a majority of users, to be useful. Maybe I misread you.
I have not come across the idea of replacing tags by pages, and I have not seen people in this forum jumping on the idea as being fantastic. But who knows, time will tell, if the devs decide to implement.
True but my question above is in what ways do people differentiate the use of tags vs pages IN obsidian. In either case, not all software recognizes them - hence my comment above. I wanted to focus on their use in this software in particular.
I use links as direct links between one note and another. With an option to describe the nature of the link if i choose.
Tags usually being indirect.
A small number being categorical. Others being very loose associations. Two notes sharing a tag doesn’t necessarily imply that they are linked in any meaningful way.
I see current Obsidian treatment of both as fairly irrelevant because I know that search, queries, graphs etc are all in line for substantial development. And I’ll consider future treatment when we reach the future.
And I can’t ignore how other programs work with these features because I actively use other programs to work with Obsidian files.
Hadn’t thought of the second example you made there. Interesting. I don’t know the function will remain in the future considering they are working on search at the moment. But we will see.
A user may of course use his/her own usecase as a base. Then we’ll see if the idea gets traction or not. Neither you nor I know how many users may benefit from an idea.