I guess I could automatically resolve the file paths into an absolute path. WOn’t work cross platform though. Else, you should post this bug onto githhub, seems pretty serious.
Hi Aryan, I don’t think there is anything wrong with your plugin. A relative path is clearly the better solution, otherwise the whole library will break if one uses a different path.
It looks like a bug in Logseq to me.
Actually. I think relative path is wrong. If your zotero folder was stored in the same location as the assets folder or the pages folder then it would be correct. But in this case it’s wrong as …/ in logseq will check for files in your db folder.
it’s
I just checked the paths in my .bib file. It has file paths relative to the folder of the bib file. This might be as I set a custom storage location in Zotero, maybe that is why andupaz has absolute paths.
That folder was at the same level as the top level logseq folder, so the paths would be correct as seen from this folder.
As an experiment, I exported into the assets folder, which gives relative paths starting with ../../. Logseq ignores these relative path and puts everything under assets, so it looks for logseq/assets/zotero/storage. This looks like a bug. Once this works, I think it would make sense to accept relative paths in the .bib file, but as this file might not reside in the assets folder, the paths need to be replaced by a relative path with respect to the Logseq folders.
The relative path issue is indeed a known bug, here is an older feature request: Relative path for Zotero data directory
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 
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!