To be able to use Logseq effectively for academic work there needs to be a good Zotero plugin like the one for Roam Research. I suspect that many of the ideas and concepts can easily be transferred.
2 Likes
Thanks for posting, this has been discussed many times on the forums but I guess no one actually put it here to vote on! Any interested devs should search the Discord forum for resources I’ve posted there about similar plug-ins for other programs as a place to start.
1 Like
Would be useful to list some of the best Zotero plugins for Roam and Obsidian here for reference. I haven’t used them so I’ll leave that for someone else…
2 Likes
So I had some time to look into this and here is what I found for Zotero support in Obsidian:
- Zotero -> zotfile -> mdnotes -> obsidian -> dataview Workflow - Share & showcase - Obsidian Forum
- GitHub - hans/obsidian-citation-plugin
And here is what I found for Roam Research (though these seem like they could work with Logseq as well?)
1 Like
Looking further, it seems that mdnotes is highly configurable. Here are instructions on how to edit the default templates.
UPDATE: Currently there are too many limitations to how it can be configured for me to get things how I would like… But hopefully it will get better, it is still early in development.
UPDATE 2: So, after an afternoon of testing, I came up with this temporary solution, until something better comes along.
3 Likes
Since there are a bunch of advanced users here with different workflows, we probably should start differentiating particular use cases and functions in our discussions. e.g. there is
- search for a source from within Logseq and find the citekey
- automatically create a Logseq page (file) for a source
- automatically import Zotero metadata to an existing source page in Logseq
- automatically creating web links on the Logseq page to search for the paper in online services like Google Scholar, CrossRef, ConnectedPapers, etc.
- importing pdf annotations made in Zotero beta, pdf readers, or (potentially) an integrated pdf reader in Logseq, and turning those annotations into plain-text that can be edited in Logseq
- using citekeys in Logseq as part of longer-form writing that can be exported to Word or other formats—not just word processing formats, but potentially pdfs, markdown, Pandoc-markdown, or LaTeX
There are probably other ways to use these tools but it makes sense to be more specific than just talking about “using” Zotero and Logseq together.
EDIT: want to add more functions currently in the Roam-Zotero plugin.
On a Logseq page for a source, list the works cited by the source that:
7. …you currently have Logseq pages for
8. …you have in your current Zotero database (thus ready for import to Logseq)
9. …you don’t have in your Logseq graph or Zotero database, with a link to the cited work’s DOI page
- link to open item in local or web Zotero
- link to open item’s attached pdf in local or web Zotero
2 Likes
Which of these would be hard to implement using just an offline bibtex file? Because if all of them can be implemented without using online zotero library then it would be usable for everybody.
1 Like
It’s sort of a strange question. The bibtex file is not needed for any of these (although perhaps it could play a role in 6). The bibtex file is intended to be used for Pandoc or Latex to lookup source information for the purpose of properly formatting citations in manuscripts for final output and submission to a publisher. If you use zotero to create and maintain the bibtex file, and then try to rely on the bibtex file to do these other things, then you will basically be needlessly inserting a middleman for no reason other than having the Zotero info in a local file. I understand that you prefer an entirely offline solution, but is there any other reason than privacy concerns? I am very privacy-concerned also, but Zotero accounts can be totally anonymous. And for actions that fall under 4), which I find very useful in my current work, obviously online is necessary.
Ok. I am very new to Zotero and research and still learning so I wanted to know clearly the benefits of zotero web library integration over an offline integration. Thank you for clarifying.
I actually like the bibtex file solution because it works for people (like me) who use other bibliographic managers. Paperpile can generate a bibtex file that works seamlessly with the Citation plugin in Obsidian. This file is constantly updated and kept in sync with my Paperpile library.
I understand your position, but because the Citation plugin in Obsidian uses bibtex rather than the API, it is more limited than the Zotero-Roam plugin that uses the API.
I suppose we should decide whether interoperability with other note-taking apps is a priority over increased functionality for a Zotero-Logseq plugin. There is value to both.
But also, it does seem strange to want to do the Zotero-Logseq plugin in a more limited way so that you can more easily use a different reference manager with a different notetaking app! I know we all love our individual workflows, but how would you respond to someone who said, “We should design the Zotero-Logseq plugin in a certain way so that I can more easily use Mendeley to cite references in WordPerfect.”? 
1 Like
I suppose we should decide whether interoperability with other note-taking apps is a priority over increased functionality for a Zotero-Logseq plugin. There is value to both.
I agree. I’m generally for open standards myself. One reason I like Logseq is that it supports both markdown and OPML. Bibtex seems like a natural extension of that, and would also lend itself to the plans (on the roadmap) to have a more optimized experience for long form writing. Obviously, the very existence of plugins means that there could be multiple solutions - but I do think that interoperability makes more sense for a plugin that might be included as a default…
1 Like
Of course open standards are good. But we are talking about a Zotero plug-in and integration, not a bibtex plug-in. And Zotero is open source and has a public API so it it an open standard. Bibtex is another, different, open standard. And so is Latex, and pandoc, etc.
These issues are always trade-offs between openness and functionality. Pure plain-text is highly open and has low functionality. A pure database solution is more functional, but less “open”. (Truthfully, the very concept of “open standards” is very ambiguous and things can be open or closed in many ways. I think it is generally used to refer to any data standard that is public and non-proprietary.)
I am also hesitant to make long-term calls about the value of interoperability between two apps with the same basic functionality (Obsidian and Logseq). That’s not the same issue as interoperability between e.g. Zotero and Word, which are decades-old programs that have separate functions and userbases. About a month ago I was really enthusiastic about using both Obsidian and Logseq together. But now I think this is just because neither platform is mature enough to do everything I want, and in a year, the inherent difficulty of using two platforms on the exact same files will become increasingly annoying and I’ll end up using just one.
It’s also hard because some of us are students, some are teachers, some are writers, etc. And we are all discussing our intuitions about these things with totally different backgrounds and work contexts.
1 Like
Just had another thought: people who use Logseq online, on multiple devices, or on work computers with limited file access would do much better with a Zotero API solution than a local bibtex solution. e.g. an API solution could potentially work even on mobile devices.
1 Like
Posting a message from @AlixLahuec (with permission) re: API vs file-based Zotero integration. They are the one responsible for Roam’s fantastic Zotero plug-in.
—-
Hmm - off the top of my head, I would say the API has more data available & allows more operations as well. But then it requires making calls frequently whereas using a local file is more straightforward.
Some of the differences I see :
- the API can return formats that are easier to work with (JSON, XHTML) than BibTeX, a local JSON would be nice though I don’t know what it would include
- the API lets you update & write data
- the API gives access to metadata, extra information (date added, collections,…), attachments, notes, etc. If I recall correctly a BibTeX file would have a lot less (metadata only?). JSON format might have more but I wouldn’t be 100% sure
- syncing of course is a question too, though it’s possible to keep a synced BibTeX file in local storage so if the app had access to that it could work (don’t know if synced JSON is possible)
Now for within-Roam features specifically :
-pulling citations is done through the Scite.ai API, which returns a (partial) list of citing papers
- this generates the “citations available” list, and then that list gets filtered by DOI against items in the library to create the “citations in library”
- I don’t think using an external API is avoidable here, because pulling citation data (in this direction) is not an integral feature of reference management software for some reason. So in this case it doesn’t really matter whether you use the Zotero API or a local BibTeX file, as long as the DOI information is accessible & can be parsed from the file
So depending on what features they’re going after, either could be a good choice. For full, synced access to data, the API is great (even lets you generate formatted citations/bib entries) ; for a more Zettlr-like functioning, local file can be sufficient though it will be limiting future dev I think.
E.g, if the only goal was to convert citekeys into citations & to generate a bibliography, a local file would be just fine. To have the additional functionality of in-library/available citations, with the Scite API it would also be enough, if it contains the DOIs.
But the limitations afaik would be on operations like getting PDF attachments/notes, writing data, making citations… Not necessarily a big deal but PDF links for example I don’t know if that could be done through a local file
2 Likes
It is totally possible to sync a bibtex file to your assets folder in Logseq (as I do), but I appreciate the way you are exploring this topic and looking at it from all angles.
1 Like
Wanted to put a link to this project in the thread: GitHub - aljedaxi/logseq-zotero: zotering in logseq
Obviously not a substitute for a full integration but could be interesting for some.
1 Like
4 posts were split to a new topic: Zotero - Modify Template