Enhanced eta-template to export multiple Zotero items for pasting into Logseq including title, url, creators, tags, select link, abstractNote, multiple notes, multiple relations and the rights. Code completely rewritten after support by Emiliano Heyns and his update of the code of his Zotero AddOn BetterBibTeX

Zotero-BetterBibTeX-QuickCopy-eta-template.eta

<%- for (const item of it.items) {
  const [ , kind, lib, key ] = item.uri.match(/^https?:\/\/zotero\.org\/(users|groups)\/((?:local\/)?[^/]+)\/items\/(.+)/)
  const select = (kind === 'users') ? `zotero://select/library/items/${key}` : `zotero://select/groups/${lib}/items/${key}`

  const relations = []
  if (item.relations) {
    for (const [kind, rels] of Object.entries(item.relations)) {
      for (const rel of rels) {
        relations.push(rel)
      }
    }
  }
-%>
- ### <%= item.title %>
<%- if (item.creators.length) { -%>
<%= "\n" %>creators:: <% item.creators.forEach((creator, i) => { %><%= creator.creatorType %>: <%= creator.name || `${creator.firstName || ''} ${creator.lastName || ''}`.trim() %><% if (i < item.creators.length - 1) { %>, <% } %><% }) %>
<%- } -%>

<%- if (item.url) { -%>
<%= "\n" %>url:: <%= item.url %>
<%- } -%>

<%- if (item.tags.length) { -%>
<%= "\n" %>tags:: <% item.tags.forEach((tag, i) => { %>#[[<%= tag.tag %>]]<% if (i < item.tags.length - 1){%>, <%}%><% }) %>
<%- } -%>

<%- if (item.citationKey) { -%>
<%= "\n" %>zotero:: [@<%= item.citationKey %>](<%= select %>)
<%- } -%>
<%= "\n" %>

<%- if (item.abstractNote) { -%>
<%= "\r" %>  - #### abstractNote
<%="\r"%><%=item.abstractNote%>
<%- } -%>

<%- if (item.notes.length) { -%>
<%= "\r" %>  - #### Notes
<%- for (const note of item.notes) { -%>
<%= "\r" %>    - ##### Note [<%= note.key %>](<%= note.uri %> "URI Link")
<%~ note.note %>
<%- } -%>
<%- } -%>

<%- if (relations.length) { -%>
<%= "\r" %>  - #### Relations
<%="\r"%>   collapsed:: true
<%- for (const rel of relations) { -%>
<%= "\r" %>    - <%= rel %>
<%- } -%>
<%- } -%>

<%- if (item.rights) { -%>
<%= "\r" %>  - #### Rights
<%= "\r" %>    - <%= item.rights %>
<%- } -%>

<% } %>

TypeError: item.abstractNote is undefined if the abstractNote is empty.

Replace it with item.abstractNote. The .length is only relevant for array type fields, not text fields. edit: also item.citationKey, although that will in practice always be filled.

As I see now an empty abstractNote creates an TypeError: item.abstractNote is undefined if the abstractNote is empty. Need to investigate the different approach @retorquere used for the if clauses to check if the value is present.

For reference: item.X tests whether item.X is "truthy". Objects and arrays are always "truthy", regardless of their content, so for those you need a further check whether they have any data. Strings are "truthy" unless it is the empty string, numbers are "truthy" unless the number is 0.

So for a string, you can test either item.X (tests whether the string is empty) or item.X.length (which tests whether its length is non-0). The full check for a string is item.X != ''.

Since arrays are always "truthy" themselves, you need to check for contents, for which the full check is item.X.length > 0, but since lengths cannot be negative, it suffices to check for item.X.length != 0, but since 0 is "falsy" and all other number values aren't, you can shortcut that to item.X.length.

<%= "\n" %>creators::

this is the same as

creators::

Is \r special to Obsidian in some way? Line endings are usually either \r\n (windows) or \n (all the rest).

@retorquere First: thanks for your general help with the validation of the field content before writing out stuff in the template. I will update my code and test this.

-> Validation Fixed -> DONE! in Rev 7 20240213_212748-acsr

on Zotero Select Links

Links in notes and relations are still pointing at http://zotero.org/ (no https) due to relying on the current JSON output by BetterBibTeX

@retorquere wrote:

This is due to Zotero storing it this way, it is not due to BetterBibTeX doing or not doing anything. The "current JSON output by BBT" is just BBT outputting what is in your library, unaltered; BBT is the conduit of this data, it is not the originator.

Got it. Sure. I am aware that there is no responsibility for BetterBibTeX if you just dump the raw Zotero content.

Roadmap to fix Zotero select links (for me)

I am not sure if it is a proper approach to write a transformation function in eta to convert the link formats and put it into the eta-template in BetterBibTex. It is just a workaround.

On the other hand I need to investigate Zotero 7 first if there is already a solution coming up. Integrating this into the main Zotero API would be much better and then call it from BetterBibTeX or a different solution (see below).

Other Approaches

Is the serialized JSON Exportv already a part of Zoteros API or a product by BetterBibTeX?
For me there is the need for more variations for export translators.

This may go beyond the purpose of BetterBibTeX. Then I have to investigate other ways…

Zutilo Plugin

It can be added to Zutilo, but there is only one eta-template from BetterBibTeX usable at a time.
You can add hotkeys for multiple alternative QuickCopy export translators, but only one using the one eta-template if selected in BetterBibTeX. see: https://github.com/wshanks/Zutilo/blob/master/docs/COMMANDS.md#item-menu-functions -> QuickCopy items:

Python

writing a Jupyter Notebook for developing this in Python using pyzotero. I have some expertise in using Python and Jinja2 templates.

Javascript

My javascript skills are current not sufficient to write stuff from scratch. The eta-template stuff seems OK for me.

@retorquere wrote

Is \r special to Obsidian in some way? Line endings are usually either \r\n (windows) or \n (all the rest).

My Challenge

I am using Logseq not Obsidian! They use similar Markdown in data on rest (in a file) – but, there is (maybe) a difference how the insertion via clipboard can be handled, because there is some postprocessing of the code from the clipboard trying to interpret tables, lists, links etc. and hiccup syntax as well (a clojurescript dialect to represent html) and so on. I also use a plugin that tries to interpret more clipboard flavors. But this can be deactivated if necessary.

Purpose: adding properties in Logseq Style

Logseq uses ASCII char 10 for regular newlines issued by the Return key.
Every Return usually creates a new block = paragraph.
To add properties line by line inside the same paragraph (similar to the
in html you enter an initial Shift-Return key (ASCII char 13). Inside the paragraph the return key is interpreted different, when the line already contains a property. Then a regular Return is sufficient.

The challenge is that Logseq behaves different if Markdown is typed by hand or pasted from the clipboard.

If you do not provide the proper order and finalize the properties with a regular return, the last property is interpreted different by Logseq. It simply does not catch the clue (or different as expected).

On quoted placeholders

Note: The original purpose of the quoted \r \n \t placeholders (like in regex) ist NOT to mimick the OS flavor of default text file line endings! Is an abstraction to avoid it.
I am not sure if Javascript has a OS abstraction like the Python os module. But this is actually the reason to use seperate placeholders \r and \n for different purposes: \r for the end of a paragraph and \n for a newline inside a paragraph.

Background: Whitespace can hurt!

There is a natural difference between a Line Feed and a Carriage Return since the ages of typewriters.
Why the hell the different Operating Systems have different approaches is another thing.

This is also one of the reasons not every Markdown dialect is offering newlines inside a table cell. some accept a raw <br > some not. Its just to difficult to explain how different OS and keyboards enter ASCII Decimal 10 or ASCII Decimal 13 characters.

A nice wrapup of the topic can be found here: https://blog.codinghorror.com/the-great-newline-schism/

On the select links for Zotero

I was involved in the translation of the manual for the Zutilo Plugin and proposing some enhancements. I heavily use the Zutilo Plugin to catch Zotero select item links and those to link to collections in Zotero groups. It is not trivial to manage the lifecycle of links spanning more than 20 years.

There was an issue with the select links in your report customizer plugin because of differences in links for groups or the main library. You fixed it soon. I am missing it currently a lot. It has provided those links as well going beyond standard Zotero.

When pasting those links without any dynamic updates, there is also a challenge when the target is gone or moved, changed context or ID and you have no clue left where it belongs to. Using full UUIDs for references like in Logseq does not protect against link loss just against ambigous IDs. Keeping a full history of changes and previous parents or origin UUID bloats the data up, but there is no workaround.

Content Lifecycle Management

I use Zotero since 2009 and try to keep my data alive over long lifecycles. I use my data archives and migrate them to be readable since the 1980ties. It is not trivial and challenging.

The transformation of links and keeping the history is a challenge you also have to tackle with your citations. Reorganizing items can lead to lots of broken relations. They are human readable. But editing useless titles can break everything.

We also have this challenge in Logseq with links across knowledge graphs. Using both Logseq and Zotero is crucial for me today. The referenced data and metadata is stored in Zotero first, the the contents abstractions and notes are exposed into Logseq and complex relations, tags and queries with backlinks and crossreferences can be created there. So the postprocessing of the cited stuff is going beyond Zotero. And it should be kept seperated. Then publishing workflows start and the nightmare continues.

Saving comments over the lifecycle of documents and sharing with different users

When it comes to commenting website content there were nice features in the early Zotero versions. Today we have commenting / Annotations back for PDF. But the workflwos are challenging, when you have to maintain research over decades. On paper ist was more reliable but not so efficient. But to be effective you need to create content that is reliable over time. Or we may loose serious results of the current scientific research.

Revison 8 fixes the missing separator between multiple selected Zotero items in the created markdown.
There is maybe another issue with relations, I need to test in a second step. See retorquere/zotero-better-bibtex#2791 (comment) and followup for more details

Revision 10 fixes an obsolete added leading space char in abstract notes (Rev 9 contained a remaining space too)

Revision 11 adds a property collapsed:: true after the Revisions list to collapse long lists by default. The actually broken link issue transformation remains unchanged but can be solved later.

Footgun: After pasting the markdown, Logseq does not take the collapsed property until a reindex of the page. (This can only be forced on per page basis by a workaround editing page the md file in a text editor (for new files: leave the page and come back. Then the page can be edited by the menu Open Page in default editor once it is openend in a text editor add a minor one character edit, save, reverse the edit and save again. (Just touching is not enouch). Other tricks to reindex just this page are welcome.

This gist was experimentally cloned and I moved the revision states until and including revision 11 of this gist to a new public full fledged repo at https://github.com/acsr/Zotero-BetterBibTeX-QuickCopy-eta-template .

I am trying to preserve the comments in the new repo by migrating the comments from this gist to a discussion in the new repo. I successfully exported all the former comments as JSOn via the Github API and using Github CLI

Why? I want to allow to manage the further development and even migration to another approach by an dedicated Issue Tracking workflow in this repo. Also the Wiki allows to add some illustrated examples and explain the use cases and limitation of this tool for others.