You have a point but I’ve really thought about this more since my post 2 days ago and I actually think that we don’t need any kind of #tag or @people pages. theres a way better way to implement what myself and alot of other people’s use cases need for this and its way simpler: make folders color codeable.

Imagine having a “tags” folder or a “people” folder that you put each tag page or people page into. This is the same work as typing the “#tag” in the page. You can fully use the page to work out of all you want, and best of all, since the name is ‘pure’ (doesn’t have any prefixes), all of your linked and unlinked mentions properly function.

Now, when you want to see a list of people you just Cmd+O for the quick switcher, type “People/” and a list of all the people in your vault populates. When you want to see a list of your tag pages (or anchor pages), type “Tags/”. I’ve already started doing this.

Finally, to give the visual distinction in graph view, if you make these folders color-codeable your set up is OP. No need for messy prefixes, no need for special tags or extra first class variables.

Got this idea from @Picard here: Graph View: Colored clusters

This is still a “folder-free” hierarchy, bc your notes don’t gain structure from the folders. The folders just group certain page types together; the hierarchy of the vault is still completely flat. I’ve also been able to get rid of most of my tags, which is awesome. Traditional folders and tags are imo just crutches until the notes can be properly linked to each other and to map pages

This is the feature request I’m talking about. Sorry if I’m side-tracking the convo, but I’m linking it here bc I really believe this would solve this use case.

5 Likes

I just wanted to mention that this would conflict directly with the citation syntax used by pandoc. From their docs:

Citations go inside square brackets and are separated by semicolons. Each citation must have a key, composed of ‘@’ + the citation identifier from the database, and may optionally have a prefix, a locator, and a suffix. The citation key must begin with a letter, digit, or _, and may contain alphanumerics, _, and internal punctuation characters (:.#$%&-+?<>~/). Here are some examples:

Blah blah [see @doe99, pp. 33-35; also @smith04, chap. 1].

Blah blah [@doe99, pp. 33-35, 38-39 and *passim*].

Blah blah [@smith04; @doe99].
2 Likes

This is a good point! I definitely do not want to lose pandoc citations. I have completely forgot about this, even though I use those on a daily basis…

1 Like

@argentum, I’m not sure I find this a compelling argument against an optional plugin, since that proves my point of its utility more than it causes conflict with it.

Pandoc’s @-syntax references a database ID key, either a person or a work (often the work by a person, referenced as the person). Since Obsidian doesn’t use a database system behind it, you’re talking about a use case of using Obsidian’s output in a completely different system and context, which I would consider very much second-class use rather than first-class use (Obsidian itself).

Additionally, the pandoc and @-person cases won’t conflict unless you happen to have a person with the exact same name as a database ID key, but if so, that’s easily resolveable—give the person in the Obsidian vault a slightly different name, since it’s self-contained by design, whereas use of pandoc is not (it may be locally used, but again: database, not Obsidian, so not fully self-contained).

Lastly, if someone is a heavy pandoc user and find that all their database keys match the names of people they want to reference by the same shorthand (for some reason), they could just not enable this plugin, or not create the Person pages. Really solves this edge case problem entirely.

4 Likes

@ishgunacar: What is the “messy prefix” you keep mentioning?

Several billion people use @person and #hashtags, far fewer use the imo much messier [[wiki]] syntax. Use of both @ and # long predate wikis, and are far more entrenched and accessible concepts.

Your proposed workaround is decent, and we can already use notes in folders that way yes. However, it does require ‘hacking’ the way Obsidian works and doesn’t solve the name variations or updates problem. You’re still relying on the less-accessible [[wiki]]-style syntax and it doesn’t transfer to any other platforms the way #hashtags and @people do.

I wrote up a more example-y version of my proposal in Obsidian itself to demonstrate my points:

3 Likes

The problem with any kind of prefix is that in order to harness the full backlink power of obsidian you would have to always use that prefix when referring to any thing of that type, even when they’re not important yet, which seems silly and not to mention unnatural and requires intention. One of the biggest advantages of using a digital tool is the ability to spontaneously rediscover notes. This (or any type of prefix) effectively kills that.

Here’s what I mean:
Let’s say I’m super interested in Socrates and have been researching his works a lot lately. I make a @Socrates page as a hub, and reference @Socrates in my notes. This is great.

But it turns out, I actually had a mini Socrates binge last year. And on top of that I used to research Plato’s works a lot, and a lot of my notes on Plato reference Socrates. BUT at that point, he was just a supporting character, and I didn’t really care about him much. All of my references in those notes are along the lines of “@Plato and Socrates loved to go fishing.” Socrates wasn’t cool enough for a prefix yet.

When I make my new @Socrates page, my new @ page does not pick up on any of those notes, since my unlinked mentions are searching for instances of ‘@Socrates’, not ‘Socrates’. The same thing goes if politics suddenly piques my interest and I create a MOC_Politics; I don’t automatically see any of my old notes from, for example, 2 years ago where I my research in economics intersected with politics a bit.

However, with my system, you do. If I create a Socrates.md file next year and put it in my People folder (I think of them not as folders but more as bags, as they’re not heirarchical, but purely unorganized bags of things that are like in essence), my unlinked mentions will automatically suggest the times last year where my Plato notes mentioned Socrates. When I create a Economics.md file, my unlinked mentions automatically pull up that random economics book that piqued my interest last year and any notes that intersected economics. No searching, no digging.

The same thing goes with tags. I’ve almost completely done away with tags except for deliberate and actionable ones (#important, #unfinished, #readlater). Any topic worth “tagging” has its own map page. And–when I create a new map page (that I would have made a tag for in the past) that piques my interest, I suddenly have all of the unlinked mentions of where my old notes intersected this ‘tag’. I want to focus on taking notes, not organize them. After all, we’re all here to take as many notes as possible, while losing as few as possible, with as little manual sorting as possible.

Again: the power in tools like obsidian is not just that they let you link things deliberately, its that they help you link things you never even thought of. Using prefixes kills that.

Edit:
I realized that I didn’t answer your point about aliasing. I think doing it this way, and then still putting YAML data for aliases (so that references don’t create duplicate non-canons like you mentioned) would be truly OP.

Also just realized you might be Turkish. Merhaba bende turkum:)

1 Like

Very Well defended, I couldn’t have justified this ‘plugin’ request like you.

I was thinking that @mention will work same as [[mention]], just instead of applying square brackets I will prefix a symbol @ …

And therefore it will create those files like mention.md under-the-hood.

1 Like

I have no strong opinions on this, I don’t need the @ tags for people myself. My only point is that the @ symbol is already used in conjunction with markdown for citations.
There might be people who want tags for people AND citations, so using this notation would create conflicts for them.

I’ll just point out that this are second class for you, but you can check the Zotero integrations thread and see how many people consider citations a first-class use, and also the requests for pandoc. My only point is: the use of @ would cause conflicts for the use cases other people want too, might be a good thing to consider. Dependencies and conflicts between plugins might get messy otherwise.

3 Likes

@ishgunacar I’m Dutch-Turkish, yes! :slight_smile: Except ben turkçe bilmiyorum, as I grew up in The Netherlands, so ik spreek voornamelijk Nederlands (besides English).

Anyway, thank you for the thorough reply! Some thoughts:

Well… sort of. This whole system of yours only works with exact matches, or people who only have a single name. I don’t write about Cher or Madonna or Sting all that much, definitely more likely to write about Socrates and Plato, but the bulk of people tend to have more than one name, and if I write Faruk somewhere but my name (and file) is Faruk Ateş, then your system won’t find any of those unlinked references. Same holds true for literally every other person who you reference in writing by only one name (first, last, whatever nickname), which tends to be a lot more people by a factor of near-infinity.

Additionally, your system doesn’t work when people have names that are also words. I have a friend named Can Sar, it’s (coincidentally) a Turkish name. I don’t want every single instance of the word “can” to show up as my means of finding references to him, that would be tedious as f–. Furthermore, I write science fiction & cyberpunk, and while you may think fiction is not a compelling use case, the reality is that we are heading towards a world where more and more people have names that are also just common words. Apple West is a great example of a person whose first and last names would render your system useless, but could work perfectly with my proposed plugin.

Not sure what you mean with OP here. Overpowered? Overproduced? Overprogrammed?

In any case, 99.9~nearinfinity % of people go by more than one name. Your suggestion only supports a single name, or requires creating multiple files per person to solve the problem, which I think is really hacky and ugly. I may be new to personal knowledge base systems, but to me that does not seem like a good practice at all?

Or do you mean using your system in combination with my YAML frontmatter aliases system? Because if so, I don’t see how that could possibly work with any name that is also a word — how could Obsidian possibly know whether this sentence is referring to a person or to a concept:

“Damn straight! Code is awesome.”

YAML-style aliases in your system wouldn’t catch that, as Code, in this case, is not referring to programming code, but a person named Code. Without seriously sophisticated AI and ML, I can’t see how Obsidian could possibly understand whether to treat it as an unlinked reference to a person, or a word that needs to be ignored.

I don’t see why this would create conflicts. It’s the same as when you use [[wiki links]] with the exact same name to point to two different notes. But maybe I don’t understand the pandoc citation system?

My understanding is that in pandoc citations, @ is a pointer / reference to another data object. You would use unique pointers for each unique data object—whether person or paper. This plugin would really just do the same, and just like in pandoc, you couldn’t use the same identifier for two different data objects, you’d simply pick one over the other.

From the example above:

Blah blah [see @doe99, pp. 33-35; also @smith04, chap. 1].

If I manually create a @Person with the name “doe99” then yes, I would have two possible endpoints it could reference. That’s not a conflict, though. I can make two notes in Obsidian with the exact same name—just put one in a folder—and it already handles the distinction beautifully (using [[…]]), so I don’t see why it would suddenly break anything for this. See screenshot below; I have two files named People Plugin in my vault.

Again, maybe I don’t know enough about how pandoc citations work, so please enlighten me if there is a glaring gap in my knowledge. :slight_smile:

Screen Shot 2020-10-08 at 9.02.55 AM

I think you got the gist right! @doe99 would indeed be matched with a key in a file (CSL or Bib files). I don’t worry so much about the collisions which could still happen, because as you righly point out, they could be avoided (with some extra effort to avoid conflicts) by following a naming convention, e.g. citations always include the last name and publication year @doe2020 or something else, while people are only defined with their first name @john or a bit more confusing @doe.

The “problem” comes from the semantics of the symbol now. Every time I look at @someone I’ll have to think a little about whether that’s a reference to a paper or a tag for a person and hope I was meticulously keeping things in check. If I have a reference that doesn’t follow the convention, maybe because of the rules I can set in the software I use to manage references, e.g. so it doesn’t have a year for some reason, (examples from my library: podcasts @dubner or @cortex), at first glance, how do I differentiate between the person and the citation? I’d now have to check in the bib file or in obsidian which is which. Also, I now have to spend a lot of extra effort meddling with a reference manager so it doesn’t collide with the people tag plugin in obsidian.

Let’s say now that I want to use the citations to output some work! pandoc is great and widely used, and I have a note where I have both references and people… unless we patch pandoc, I probably won’t be able to use that. Also worth thinking about: IF the PDF export in Obsidian relies on pandoc, the people tags using @ might cause issues if you are using citations too unless there’s a smart way to mutually exclude bibliography for only those notes that have it, but then again… how do let the software know which @s are people and which ones are citations? I could try to render only those references that are in my bib file, but that also means we might have to patch pandoc or existing citation libraries to handle it if they don’t already.

Edit: Here’s the output of pandoc, when a citation doesn’t exist: (???), and the citation it did find (grakn labs)
image

If there is a deeper integration where typing @ brings up the citations from the bib file, conflicts between people and citation autocompletion could also be an issue.

What format are you using under “Core>File>New link format”? I’m using “Shortest path when possible” and this wouldn’t work there. What does your final link look like? And when you click on each, does it take you to the right note?

By OP I meant overpowered. Like awesome:)

I agree about the names, but I believe the more elegant solution to that would be to just allow all documents to have aliases which I really really would love to see. I think that should be a feature in the program, and I obviously don’t have any qualms with plugin ideas for more specific use cases like this. The reason I commented was bc at first I thought it this would fix my use case that was similar to your initial post but I was able to hack up a better fit for me that that I just wanted to share above in case it resonates with anyone else:)

As far as the search/finding words like Apple West: you’re absolutely right, but thats just the limitations of non-AI search. The same ‘problem’ occurs when you use vault search for those kinds of names. Search is pretty dumb. It only finds all and only exact matches or fuzzy matches. The benefit in what I’m doing is basically that all of my purposefully linked things show up in linked mentions, and anything that I didn’t purposefully link, including false positives like apple, would show up (basically like an automatic vault search query) in unlinked mentions for me to quickly skim through and build on if needed.

To me, i’d much rather write naturally, with as little sorting as possible, and then be able to have suggestions to dig through than to write intentionally/with decision points (imo causes friction) and possibly miss out on non intentional connections from the past. The ability to see good unlinked mentions are super important to me.

Ah! So, my point was just that if you use [[wiki links]] to point to two different notes, that obviously wouldn’t work. Same with Pandoc and using @ to point to two different references, i.e. if you have two endpoints and you give them both the same name, you’ll have a conflict of your own making.
——

That aside, @argentum it sounds like the proposed @-people plugin wouldn’t inherently cause conflicts, i.e. if you enabled that plugin AND used Pandoc, nothing would necessarily break—am I correct so far?

Then, if so, my thought is this: wouldn’t it be great if we made the @ a general-purpose pointer that works appropriately in Pandoc use cases (CSL or Bib files), but was architected in such a way that Obsidian users could also use local CSL, Bib, or .md files with YAML frontmatter? Basically, it just becomes @ == reference pointer to <structured data file entity>, and there are either formatting and/or templating options for how it should output all the references?

CSL? → use standard Pandoc output
Bib file? → use standard Pandoc output
.md YAML? → use this formatting syntax or template, which could create the same output as Pandoc, or something else.

Basically, make this plugin proposal something that caters to your needs as well as mine with a single solution.

Except it doesn’t, and it does break pandoc’s export. I did do a little test and having a @people in a document I want to export using pandoc does mess up the output, see the (???) in the post above, which are not something I want in the output document. Keep in mind that I will get one set of (???) for each @people reference not found in my bib file. To use pandoc you’d have to have a @people-free document to use the export or patch the citation libraries.

I still do not agree that @ for both people and citations is good for all the reasons I mentioned before: Cognitive overload, plugin conflicts when typing @, incompatibility with citation libraries. I think if you are really strict about using @, most likely (at least in my opinion) this would have to be mutually exclusive with citations.

Okay, as a product designer I don’t call that a break, I call that a configuration: what to do with unknown inputs.

A “break” is the conversion process—pandoc export, in this case—simply not working anymore, i.e. it fails entirely. An unwanted (???) can be removed (via error handling configuration); an empty output is a clear case of something breaking.

Again, though, you’re talking about a hypothetical situation in which you consciously and willingly insert @people references in a document together with pandoc references. Like I said above: that’s a comparable situation as using [[wiki links]] to try and point to two different entities, in that you have control over the input and output in both cases. The difference is that Obsidian already has proper error handling for non-entities: a [[wiki link]] pointing to a non-entity fails silently. Pandoc not failing silently is a choice, and it can be a configuration in an Obsidian plugin for it.

Furthermore, if there have to be two separate plugins, you could just not enable the @people plugin if you’re a pandoc user, and vice-versa, if you don’t want to deal with potential unknown reference output.

Fair enough, I’m looking at this from the point of view of a developer. As far as I know, this is not one of the things you can configure in pandoc, hence my use of “break” and mentioning that the citation libraries would need to be patched. The output being a PDF means that unless we patch pandoc, those (???) are not removable.

We agree there! These are indeed all hypotheticals since we’re just discussing the idea, I just thought I’d point out that this could cause conflicts in case you wanted to consider other symbols. Mutually exclusive might be the way to go if @people is a must.

2 Likes

Well, the output seems to be many possible things, PDF being just one of them.

I read through the pandoc documentation and there is a lot of possibility in configuration but I agree that I couldn’t quite tell whether or not you could tweak the citation processing this way. The templating stuff allows for almost Jekyll-like control and freedom, though, so I would be surprised if not.

Moreover, reading it made me discover that pandoc supports a YAML frontmatter bibliography, so literally the only thing Obsidian would have to support is not limiting itself to a highly specific and fixed set of CSL YAML structure and allow a more general-purpose YAML structure, and that would cover perhaps 80-90% of my desired use case. :slight_smile:

1 Like

Not knowing the first thing about how pandoc parses, so possibly a noob idea, but would using @@person to reference “people in obsidian” pages still break pandoc? That keeps the convention of @ being people in the text, but disambiguates from pandoc’s use of it

@KuraFire I’m beginning to noodle on a plugin to do this. I have the exact same desire as you, at least based on what I’m seeing here. I’ll update the thread when I have something.

7 Likes

Sorry to bump an old thread, but I searched for this topic rather than creating a new thread.

Here’s my use case: I keep notes on members of my team and leadership. Often it’s just reminders to me of things I want to discuss with them the next time we talk. I could use tags: #MK, #KJ, #TT, etc, but they would show up along with all my other tags in the Tags pane, but I wouldn’t want them to show up there (wouldn’t want others to see them and wonder about them).

I could use nested tags (- people/MK) but it’s not as simple to input as @MK.

So my ideal would be to use @mentions exactly like #tags except that the Tags pane would show tags and a separate People pane would show a list of all @mentions. Clicking on @MK would bring up a list of all items using the @MK mention, or a single @MK page with an index of all items.

@sheeley Any progress on a plugin?

3 Likes