Comprehensive Zotero Plugin

I recently wrote up my workflow. It might be useful for those making plugins.

4 Likes

I made some notes about what I think an ideal workflow should look like and also added some comments about where it breaks down currently.

2 Likes

Wow! Nice to hear that, I could definitely use these features. When I want to insert a page from zotero, the search bar is soooo slow.

maybe this is a little beyond the scope of this proposal of extension, but I want to say the pdf reading experience is not so good in current logseq.

It lacks multi tab feature, this makes reading supplementary materials and the main article at the same time an awful job to do.
And the pdf reader lacks the ability to jump back to last position. For example, I get interested about a reference mentioned in the main text, I clicked the reference linked to the end of the article, and then I get lost where I have been reading just now. Zotero, as well as many (if not all) other pdf reader have this important feature, you just press alt + left/right arrow and you can navigate through jumped positions.

The most urgent need is that use the relative path in file-path and file fields in the pdf annotation file (e.g., hls .md file) to implement pdf annotation across multiple devices, such as Mac and Windows.

1 Like

I should better have posted this Zotero: tag imported items as imported in Zotero database here perhaps.

It would be great if LogSeq could add tags to an imported Zotero item within Zotero upon import of the item in LogSeq.

My use case was to tag items in Zotero has having been imported to LogSeq. Perhaps others would have other use of such tags.

1 Like

Thanks for that !
With new version of Zotero… il would be great to import highlights and notes into Logseq :wink:

1 Like

Thanks for the initiative! Zotero enhancement as suggested here would also be very useful: Zotero enhancement by including citations, references and related papers

While I see your point from an engineering perspective, I beg to differ.

There’s two main reasons: workflow and attracting users.

As awesome as it is that logseq has a builtin PDF annotator, I prefer to annotate in Zotero.
To me, the layout of Zotero works better when working through a PDF.

Also, Zotero has been around for a long time now, and will likely persist.
In contrast, the note-taking/PKM scene is constantly shifting.
I myself have tried a bunch: Tiddly, Roam, Anytype, Athens, …
If the PDF annotations are locked into logseq, it’s harder to convince people to try it, as they have to fear losing them in the future. (I’m looking at you Polar …)
If, instead, one could annotate in Zotero and then just pull annotations into logseq, one has nothing to lose and everything to gain by trying logseq.

To me, that’s the ideal workflow: pull PDF into Zotero, annotate there, then pull the notes into logseq where I can use the annotations in writing by referencing the blocks, but still being able to look up where the blocks come from in the PDF via the imported highlights.

1 Like

Valid points. You’re thinking however from a consumer perspective. My thoughts are based from a logseq perspective. If fear of losing annotations is what keeps people at bay, logseq should work towards guaranteeing that this will not happen and being the PKM that masters PDF annotation.

Zotero’s annotator is perfectly fine, but you must keep in mind that it’s a different software with a team behind that is not thinking about other PKMs. The engineering perspective is the one that matters when two independent softwares must be linked to each other. It is here where you should fear losing your annotations.

Finally, outsourcing PDF annotation basically ruins the purpose of a built-in annotator in your PKM. Having a built-in annotator is there to simultaneously integrate your annotation with your existing notes, not add an additional step in your workflow.

Yes, exactly, we’re looking at that from different perspectives.
And while the engineering perspective is certainly important, it’s crucial to remember the end-user experience as well. I think that’s something a lot of open-source projects struggle with.

A few comments.

I think you’re misunderstanding my point about losing annotations.
I didn’t mean that logseq would screw up and literally lose the annotations.
Instead, what if, god forbid, some day logseq is not developed further?
Or a user wishes to switch his PKM tool for some other reason?
As a developer, you’re focused on improving the app, sure. But a single end-user has little influence on logseq’s survival or direction of development. So he has to plan for the case that logseq won’t be around for ever.

An anecdote: Polar reader was an awesome, open source PDF annotation tool.
Some day, the devs announced that they would switch to a client-server model, because syncing was a much-requested feature and this was the easiest way for them to implement it.
A little later they also decided to try and monetize their product and people now had to pay for the cloud-storage, which was also mandatory because of the new server-client model.
People were upset and there’s radio silence from the devs. The project is essentially dead now.
Moral of the story: a lot of users, including me, got burned and lost years worth of annotations.

Not to say that the same thing will happen to logseq, but there’s many ways in which a project can die.
And it’s much easier to sell users on an app where they do not have to fear losing their data.
To me, that’s one of the central promises of being ‘local first’.

With the notes being in Markdown, there’s little damage to fear there.
PDF annotations are trickier, because everyone uses a different format.
So it’s safest to follow a bigger project, like Zotero, which is likely to be around for longer.

If there’s reason to assume that Zotero’s structure for annotations will change in the near future, I think it’s reasonable to wait for the new format and built on that.
But, are there any specific reason why Zotero’s annotation format should not work for logseq?
Zotero, too, highlights and finds the annotations in the PDF, and extracts the highlighted area or text for display in the sidebar. What else does logseq need?

Regarding ‘ruin[ing] the purpose of a built-in annotator’, I disagree as well.
First, if there’s a two-way sync, the annotator is useful as it would still allow to quickly edit and make new notes in logseq without having to switch apps.
I just put emphasis on the Zotero-logseq direction, as to me this is more important.
Second, refusing to implement an awesome feature because it might make a good feature obsolete, sound like sunk-cost fallacy to me.

1 Like

Hi all,

Just to point here this Zotero plugin

3 Likes

i have zotero installed and all files locally, the ability to use the current zotero integration offline would be really useful.

The last update to this discussion was in January. Bumping it because I would really like to see some progress on this!

2 Likes

Same here, would be so useful to have.

1 Like

Hi, all where do we stand on this plugin? Any roadmap to share? Many thanks!

This plugin seems to work locally, without zotero account or internet connection:

It is not on the marketplace though, but the installation is rather easy.

I would like to mention the plugin I am developing. It runs locally, dynamically and fast. It speaks directly to the zotero client on your computer. So you have to keep zotero running to import things from zotero. To use the function, a zotero plugin has to be installed in zotero. For details of intallation and more features please check this.

There’re already quite many plugins using .bib to work with Zotero. However, this plugin, by interacting with a plugin on Zotero’s side, directly searches in your Zotero database.

This is actually a quite powerful way to integrate Zotero into Logseq since now one can fetch in principle everything from Zotero. Notes, PDF annotations, citekeys, folder structures and linked refereces, you name it. Unfortuenately, these features are just in plan since I have very limited experience and time to do it all myself. I am not a professional frontend developer. I welcome anyone interested to make PRs (or to develop their own plugins) to make these possibilities a reality. For any question related to the plugin (usage, development…) please start a discussion here.

1 Like