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.
@ishgunacar I’m Dutch-Turkish, yes! 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.
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)
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?
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.
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.
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