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.
Especially using tag wrangler to make “Tag Pages” by adding tags as aliases to a note, so they then appear as unlinked mentions. Pretty cool!
Well said. I agree and wait for devs to make their next steps.
Ah yes…
One of the many reasons why I won’t be upgrading to properties any time soon. There is a fluidity to my current system and properties would throw all that into turmoil/
Not a rebuttal, just some thoughts in reply to keep the convo going.
I feel this. There are subtle and not-so-subtle ways in which Obsidian encourages us to work in files vs. blocks:
And to this I must agree, and because of other sentimental reasons, like devs both being University of Waterloo alums, which is true of me. I also respect they are new parents probably feeling how I feel right now lol.
But it is true that (as with the majority of other tools these days), changes are incremental and IP has to be protected by not revealing too much. I understand this even if I don’t like it. But there are folks in this community who design their lives around use of this tool, so some I sympathize with the desire for more information since I myself, as a professional researcher, feel overwhelmed by the evolving capacity of Obsidian and the resulting changes I have to make to my flow.
edit 2023-10-23 1545-50 - I am also seeing the writing on the wall with regards to files vs. blocks. The coming “Database” feature means files, not blocks. I’m not complaining. I think a Database feature would make Properties more meaningful and useful. Dataview is powerful, Datacore will be more powerful, and core Databases will be wonderful for my mental bandwidth if I use it (and hopefully Datacore and core Databases prove to be the same thing, with “Datacore” being a hint that Dataview is being sherlocked).
I will make an additional and final comment. A nested tag is equal to a Property. E.g., #genre/science-fiction is equal to
---
Genre: Science Fiction
---
However, what is lost by using a property instead of a tag is what @ton mentions:
We also lose “clickable search” (one of @nickmilo’s original points in this topic) and finally, bulk editing and renaming via Tag Wrangler (can use Visual Studio Code “Replace in File” instead, but this is not user friendly or as convenient when attempting to conduct oneself entirely in Obsidian).
But what is gained by using a property instead is de-cluttering the content of a note and individual blocks of text, as well as reducing the overall number of tags in the vault which is nice for sanity.
One should also ask how to work with individual text blocks. Should they be separate notes which can then be organized be properties? In theory we could have very fluid workflow to transfer text blocks to new notes with a backlink. This doesn’t mean tags are completely useless, but their usefulness is more and more unobvious. At least tags could be used to add metadata to tasks, but none of us know in which direction task management in Obsidian is going. Maybe we can associate tasks to notes in some day. Why do care about inline metadata because we could have a separate note entry for such thing?
I can only say that using Obsidian and by trying to maximize the utility of blocks and search results, I have become very good at writing paragraphs.
But to your point, how to work with text blocks indeed. In-line links attempts to render blocks as less necessary than tags (I would argue), so that is one suggestion, and then of course, as you say, these links lead to pages with properties that somehow add value to the blocks in which the links to these files may be found.
I don’t use tasks in Obsidian so I won’t make any comments there, but regarding in-line metadata, it (for me) helps me to stay “in the content” rather than “in the file” so that instead of thinking about properties, I’m thinking about what I’m writing.
In short, links (pages/files) require or in some way encourage me to think more about file management, but tags seem to help me simplify.
Distilled - tags are nothing more than keywords with benefits.
That being said, tags can become “links” in similar fashion to proper links if added as an alias to a file, e.g.,
# Topic
---
alias: "#topic"
---
Tag Wrangler championed this, I believe. If one were to implement this practice, that would make the line between tags and links even thinner.
That being said, a link is equal to a file, and for a tag to be “linked” to a file, it must be done so in this way; as such it is not equivalent to a link. This matters because we can’t assign properties to tags, but we can to links (via the files they are links of). This is the direction Obsidian is taking, so I would argue the advantage of tag is simply convenience and cross-compatibility.
The convenience part is definitely one thing to consider here. Easy keywords with auto completion and then automatic link generation. They have already realized the importance of auto completion and it was adopted by properties. Maybe we see other realizations as well in the future.
The story of inline metadata is still in the hands of tags. In some way tags are logical way to indicate inline metadata because you only need one special character and then keyword. Key-value-pairs are too complex for inline metadata but they definitely have place in file properties. Sometimes you want to query one specific line exactly. Usually this is not needed but for example in language learning it’s very common task. How do you indicate inline metadata with some key-value pairs? You want a link to the source material and the actual phrase/word.
One very elegant solution would be to capture your word as a separate note. You don’t get the benefit of adding key-value-pairs directly here because the backlink destination doesn’t directly contain information about your exact thoughts when you made the backlink. There are several ways to deal with this situation but how about making yet another note for your inline capture? You could then capture the exact moment when you made the inline capture and then link that forward to your actual resource. I think this workflow is really powerful because you can re-use other links when making your capture. I’m not sure how to deal with that three-level linking when working with dataview queries but at least for now you have captured everything and they are properly connected.
The point here is that you want to indicate inline metadata somehow. With some equal effort compared to tags, you could do much more powerful stuff with links. You can make your note alias as #topic to emphasize a concept that you want to link. I really like this idea but it’s hard to market it to wider audience. I think it’s quite obvious that you have concepts that are linked frequently and then you have other notes that are not frequently mentioned. There is clearly a distinction but how a computer would do that distinction for you? And do we want to think this as black and white question? Maybe we want to specify more details about different concepts and then single yes/no information is not very useful. In that case we would want to use floating search similar to Slash commands.
Very interesting! Somehow, I hadn’t ever considered that possibility. But perhaps, like people have commented above, if they are separate things, Databases will be much more note based. And, Datacore is apparently going to be note, heading, and block based.
Clearly I haven’t kept up with the information as much as most. So, for others like myself, here’s a quote from the Datacore readme:
Today I made a related but slightly different feature request:
I do believe we are asking for the same thing, but where you are looking for a clickable property values within notes, I am looking for clickable property values in the search menu. If our requests end up being merged, I think that would be a meaningful improvement to properties.
Ha, so true!
Hi Mitch,
Could you please describe that workflow and the corresponding dataview?
Thank you! 
Let’s say my manager’s name was Joe. (It wasn’t, but let’s say that for this example.)
Our weekly 1:1 meeting was Tuesdays 10 am. There was never a specific agenda–just time for me to catch him up on what I had been working on over the past week, and anything else I needed to bring to his attention. Likewise, it was a time for him to bring up anything he needed to bring to my attention. (We also talked during the week as needed, for timely matters.)
During the week, if I thought of something to bring up on the 1:1, I either added it to the note for whatever project it was relevant to, or I’d just add it to the daily note. Either way, I’d tag the paragraph or section #Joe.
Just prior to our meeting, I’d click the tag, which called up search, review all the tagged items, and manually compile a list of things to discuss with my manager. The first time I did this I just read from the search box in Obsidian while meeting with my manager, but that was too disorganized, so instead I created a fresh list, and wrote out notes manually.
I did not use dataview for this process. Indeed, I do not use dataview at all. I find it a little challenging to configure and I just haven’t found a need for it.
Hi Mitch,
thanks for describing your workflow.
tags are pagewise metadata, so I was interested how you attach them to sections or paragraphs. Your solution, to use the search for your workflow is lean and therefore beautiful
If your interested to try a more sophisticated solution, you could try using the hashtag as a inline field and attach your information to it, for example like this:
in daily note:
#joe:: reminder to tell joe about XYZ
in project note:
#joe:: the following question is still open: blabla
then you could have a dataview, to query for the #joe-fields like this:
```dataview
Table row["joe"] AS "Topics to discuss with Joe"
From #joe
Sort file.name DESC
```
Thank you. In what way is that an improvement on clicking the tag?