Often one wants to assign a value to a tag. For example #delegate(John) or #due(2021-06-18). The tag in these cases is delegate or due, each holding values of type string or date. The utility is that one can then run queries against the presence of a tag AND the value assigned to that tag.
Plug-ins such as Tasks could use this in a powerful way to find and display select items across notes, as described here.
The idea is not new of course: Taskpaper employs this clever use of tags.
That’s a clever approach, @Craig. I think it handles nicely values that are strings. However, other values (dates, number, duration) might require the approach I mentioned in original post. For example, #due(2021-06-18) or #priority(2) would enable operators such as < > <=.
At the level of Notes, we have YAML attribute-value pairs of course. But, I’m imagining tag-value pairs being used in bullet or todo lists so that one could query for specific lines of text within a note. For example:
- [ ] do this #defer(2021-06-18) #due(2021-07-01) #priority(3) #duration(45m)
Ah, that’s a good point. Numeric values wouldn’t sort or compare well using my approach.
I like your idea of annotating individual tasks. The lack of a good way to manage start or due dates on tasks has me pushing time-sensitive tasks back to my calendar.
Hey. New Obsidian user, I registered to the forum exactly for that! associating a value to a tag would open a lot of possibilities. @Craig thanks for the tip about subtags, that might do the trick for me!
OK, trying this out on my smallish dataset raises two problems:
tag spamming. Every time a tag with a new value is inserted, a new tag is created, making it difficult to show tags in the graph display.
search sort. Say I have tags #date/YYYY-MM-DD scattered all around my vault, and I want to display all occurences sorted by subtag - is there a way to do that?
Since my original post, I shifted to using Dataview plugin for value-based “tagging”. Basically, use [field:: value] to assign values and then use a wide range of Dataview queries to present results based on value of field.
Thanks, that’s interesting, I’ll definitely look into it.
I was thinking about this right now, and it looks like a lot of feature requests here boils down to generalizing three concepts into one: link, tag and key-value pairs from the frontmatter. Basically, a tag is a link to a virtual page, and a key-value pair is a tag with some arbitrary data associated to it.
So a #foo is stored as tag: foo, [[some page]] is stored as link: some page, syntax such as dataview’s [key:: value] adds arbitrary entries to metadata, and so is the YAML frontmatter. This also opens up the possibility to specify the nature of a link to another page, which is cool.
But I guess I’m not the first one to make this observation - given the popularity of the dataview plugin!