I agree with you.
Your argument is reasonable, and yes a plugin would be suitable. But look we are used to @mentions like how we use #tags, so it can’t be justified as a divergent to practice.
3 Likes
It’s a divergence from markdown. Obsidian is attempting to follow markdown standards as much as possible.
1 Like
I get what you’re saying (and I agree), but I don’t understand how this functionality interferes with that goal.
Where are you getting that “interoperability” is a goal of obsidian? I dont think that’s necessarily true. I mean you rightfully point out [[wikilinks]] are not markdown. Obsidian is based on a universal format so that it can be stored by you and easily accessed anywhere for ever, but this doesnt mean that even all of the markdown functionality will be there in your new app. They guarantee the content.
The goal of obsidian if I understand correctly is to be future proof. And by interoperability they are referring to you being able to open and access your notes easily wherever you want, bc they’re yours forever in plaintext. Anything not standard to markdown (and obviously obsidian is much more than a markdown editor), including wikilinks, back links, graph view, may or may not be supported in your new app choice. This isn’t them failing their promise.
1 Like
Treating @ (people) as first-class citizens the same way that Obsidian treats links as first-class citizens seems like an obvious gain to me, but to expand on that:
- using tags per your suggested solution is a hack and a workaround that doesn’t solve most of the utility needs
- my initial arguments’ cases are not solved with a tag-hack solution
- tags are for taxonomies; people are not taxonomies
(More use cases below.)
A great thing about Markdown is that it keeps working fine when the syntax is extended. Each of your three examples are extensions that don’t break anything, and two of them are unrelated to Markdown in the first place. Calling markdown a “rickety construction” and a “house of cards” is a rather harsh and inaccurate description for one of the more robust formats ever made.
More pertinently, the @-syntax does not break interoperability, and in fact it may even improve it. Twitter, Facebook, Messenger, Github, Reddit, Discourse (hey @Dor!) and so many other platforms use Markdown or “Markdown lite”—basic syntax without rich links or advanced features—and also support @-syntax for people.
A first class implementation of @ could conceivably offer the utility of flexible identity within Obsidian much like what Solid technology enables for internet identity at large: controlled identity representation. Example:
Input: → output:
-------------------------------
@KuraFire:twitter → @KuraFire
@KuraFire:firstname → Faruk
@KuraFire:nickname → Supernova
(Imagine that the output of @KuraFire:twitter is @KuraFire.)
This would be a variation on the wiki link + heading combo, except generating output that doesn’t include the input, and doesn’t require the output to be provided in the input.
Example: using [[note#heading]] will include whatever key you use in the output. Similarly, using a pipe + custom label technique like [[person|nickname]] requires you to manually enter the output in your input, rather defeating the purpose of it -and- relying on intelligent auto-replace by the system any time you change the name.
6 Likes
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 - #13 by Picard
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.
2 Likes
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! 
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.
1 Like
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?
1 Like
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.
1 Like