As of 2023-10-15, tags still have a few remaining advantages. It has to do with quickly and simply pulling up results—and this is more pronounced with nested tags. So before the details, the advantages are:
clickable searches
ability to nest
Say, if I want to quickly search all “Prominent People”.
With tags, I just click on people/prominent. Done.
With properties, I can’t do that. I’d have to create a new note, and then spin up a dataview query, which takes time and brainpower.
So, at least for now, you can’t simply click on a property value like people: prominent—I can’t click on “prominent” there and have the search results populate in the sidebar like with tags.
Now a properties fanatic would say, turn “prominent” into a note, then all the linked mentions will be there. But I don’t want 100+ notes floating around with unclear titles like “prominent”—like, how is Future Me going to remember that a note called “prominent” is actually about people? And that’s just one of the 100+ I would need to remember.
My hopes?
Properties expands it’s functionality to allow “list” text to be clickable.
Obsidian’s work on “Databases” solves part of these limitations.
This would give properties the same editability that Tag Wrangler gives tags. While Tag Wrangler hasn’t been sherlocked yet (I’m actually surprised by this), it seems even more of a need to have a Properties Wrangler.
To finish, these are just patient hopes, not expectations, and I have trust in the devs to develop Properties over time in their 4D chess ways.
I’m going to start experimenting with bookmarking saved properties searches as a means of navigating notes. Currently, I use a lot of folders—it takes time to maintain them, it gets sloppy when I don’t maintain them and I dunno it just seems inelegant.
See my previous message about how tags could be used:
About the automatic link generation i.e. “clickable and easily searchable”. You can use Obsidian URI to perform searches by clicking links. Putting these links manually into properties can mess up property value based queries but you could maybe use css to display links so that property values would remain untouched.
I’m 100% sure that in future there will be a feature in Obsidian to easily generate links from searches. You could then put them to your properties as text properties or use css to indirectly have links in your properties. I’m not sure if search links for properties could be generated implicitly in general as a feature because we don’t know exactly what should happen when you click a property value (you could want to edit it, copy it etc). With tags you know what to expect when you click it. We could apply same logic to properties and introduce new property types that will create search links implicitly. These could be called super properties.
In your screenshot, you have links for the up and down properties but not for the domains and fields properties. I’m just wondering why this is the case? Not for any judgmental reason, just genuinely interested.
While Octavia Butler’s work can be classified under Art and Writing, I don’t want a note called “Art” to have every possible person who I’ve classified with Art to show up there.
It’s a preference to keep links meaningful. I’d rather have my notes linked to “Art” be about art. This is especially important early on in a new note’s lifecycle, where the entire tenor of a note is influenced by the notes already linking to it.
Instead, being able to run a looser tag-like search (where clicking on it would populate results in the sidebar) would be preferred. The functionality is mostly already there to pull it off:
Seems a bit convoluted, for me personally, since we already have a core feature that is linked (if not meant) to search. I like that tags are explicit with the syntax. CSS and backend shenanigans go a bit against the “plain text” philosophy imo (and I’m not even sure this is at all possible with CSS… but I’m no expert there).
From 2020-22, I had a weekly scheduled 1:1 meeting with my manager. Throughout the week, if I saw an item I wanted to discuss at that meeting, I tagged it with his name. Just before the meeting, I compiled the list into an agenda and was able to get through the meeting quickly and efficiently.
Thanks for sharing this! Tags are definitely useful regardless of properties. Your example shows that tags are not going anywhere. People know how to use them effectively.
To every reader: see my other comment if you want a general picture of how tags could be used.
I use tags pretty heavily. To begin with, this was honestly carryover from Evernote, but I find that they help me in a similar manner as MOCs (used in tandem with MOCs) to manage bottom-up organization structure without getting lost.
I tag my notes with all the major subject areas they fall under – essentially what would be, if I were using Dewey Decimal numbers, the equivalent of tagging a note as 600 and 640 and 647. Because they’re not in a hard structure, I can tag them for multiple categories if there’s overlap. And I can certainly use the note outside the obvious designation(s). But it means that if I’ve made a lot of small notes that have otherwise gotten somewhat “lost in the depths” of the vault, I can still find them – and I often will pull up a whole section that way in order to start a MOC and reorganize things.
I strongly agree, Nick. It will be great to have feature parity since I think properties are the future.
But for now, I continue to add data in two places: (1) frontmatter and (2) tags, so to get benefits from both metadata approaches. I would prefer, though eventually, to use Properties.
I’ll draw some attention to this post for more feedback.
