jabref: Entry preview not rendering the citation properly

I think I can say that, even though biblatex is more powerful than bibtex, the big publishers in science still rely on bibtex. Therefor JabRef won’t deprecate bibtex support.

Perfect. Since JabRef will not deprecate BibTex support, my understanding is that, when the user chooses to use this format, the entries should rely only on fields that exist in the BibTex format, and not on fields that are BibLaTex specific (e.g. the “issue” field). Otherwise, you cannot really say that the standard is being followed.

Woo-hoo! The number is back in APA! 😃 Thank you, @ThiloteE, @koppor, @michel-kraemer, @Siedlerchr, @mlep, @AEgit, and @calixtus for your dedication to solving this bug! You guys are awesome! I am looking forward to the release of JabRef 5.8.

This is a short digression, but since this suggestion was made, I wanted to comment on it.

An alternative would be to remove the option for BibTex and make it clear that JabRef is focusing solely on biblatex.

This suggestion has been made before years ago - it was rejected, and the reasoning for that remains the same. Biblatex might be more prevalent (?) within computer science, maths, physics and related subjects, but in other disciplines it is nearly non-existent (e.g., biology). Making JabRef biblatex only therefore would exclude a major part of the user base.

As for how to deal with article numbers (from a user’s perspective) when using bibtex: That is pretty straightforward - you do not have the “numbers” field that biblatex provides, but you generally also do not need that field. Instead, you enter the article number in the “pages” field that bibtex provides (since page numbers are usually not relevant for articles with articles numbers and/or are not even provided for such articles). I have done this for years and I think some web-based bibtex extraction tools do this even automatically (though, could be wrong about the latter). This way also journals issues volumes and issues are preserved in a bibtex setting: they go into the “Volume” and “Number” fields. I have yet to see an article with article number + meaningful page numbers. The only thing I have come across is something like this 104982-12, where 104982 represents the article number and 12 represents the total number of pages. But this is rare and you can actually still use it in a bibtex context.

For biblatex, issue is more a season (like “Summer issue”). And number is the “The number of a journal or the volume/number of a book in a series”, so quite close to BibTeX definition . See the biblatex and documentations for more details (http://mirrors.ctan.org/macros/latex/contrib/biblatex/doc/biblatex.pdf and http://mirrors.ctan.org/biblio/bibtex/base/btxdoc.pdf). So the conversion of number to number. seems right (even if trivial).

You are right.

1. My proposal to

   Would it be possible to map issue to number, but then delete it,
   
    if issue is an integer, but not delete it, if issue is a non-integer
    if both fields are similar?
   
   

   in https://github.com/JabRef/jabref/issues/8372#issuecomment-1003565049 is flawed. Please don’t do it.

2. Before i was thinking that it would be best, if issue and number should be merged into one field (and hence my above proposal), but after reading up on it a little bit more, i think this may not necessarily be good. It is ok if both fields hold both integer and non-integer. Rather than merging issue and number, documentation should become more clear. Yes, indeed, there can be at least three different types of numbers: One for volume-number, one for issue-number and one for the article-number, therefore it is fine if both fields show, as they denote inherently different things. If i understand it correctly, the relationship between number and issue is this:

• Relationship

• Example 1

• Example 2

• Example 3; Here, the journal does not provide any issues, but publishes the articles directly:

  • The original Bibtex format only knows the number field. There is no ‘issue’ field. Edit: It is defined in the Bibtex docs page 10: https://ftp.gwdg.de/pub/ctan/biblio/bibtex/base/btxdoc.pdf number: The number of a journal, magazine, technical report, or of a work in a series. An issue of a journal or magazine is usually identified by its volume and number; the organization that issues a technical report usually gives it a number; and sometimes books are given numbers in a named series.

    Also, according to https://en.wikipedia.org/wiki/BibTeX, Number denotes: The "(issue) number" of a journal, magazine, or tech-report, if applicable. Note that this is not the "article number" assigned by some journals..

    So original bibtex somehow is a merger of both issue and number. Edit: So my interpretation would be that the number field in Bibtex is the same as the issue field in Biblatex and (article-) number is missing.

  • Biblatex knows both issue and (article-)numbers.

  • CSL knows both issue and (article-)number.

  So, depending on the style, number or issue could be omitted or included.

  The APA Style dictates to change the format in the following way:

  

To conclude, it is fine if both fields show, as to my new understanding, issue and number are two different things.

I would say that the current behavior:

builder.number(entries.get(FIELD_NUMBER));
builder.issue(entries.get(FIELD_ISSUE));

is better indeed and i very much would prefer now for citation-styles to adapt to this (unless we go back to merging the fields).

I checked with Zotero and they probably opted not to correct the various citation-styles (so much work!), but rather to correct it within Zotero or within some conversion tool. They map issue to number, but then call the number field issue… Confusing? Yes, but they basically follow the definition of bibtex, not biblatex. There is no number field in Zotero. At least, i have not found it.

• Option A: If Jabref and Citeproc want to keep short term conformity with Zotero and bibtex and provide a workaround, i would say that the mapping you proposed in https://github.com/JabRef/jabref/issues/8372#issuecomment-1003526977 is better than we have right now, but it also might lead to unintended problems with other styles that purely follow biblatex or that incorrectly miss one of the two. I am not too sure about the conformity with CSL, maybe somebody else knows better. This would be a centralised approach.

• Option B: If you keep what we have currently without any changes (which is better for Biblatex conformity (and probably CSL?)), in the long term, people will adapt all the citation-styles to differentiate between issue and number. It will all depend on the citationstyle. This would be a decentralied approach and responsibility lies with the citation-styles.

Not sure what is better. Create work for authors of citation-styles, or have proper differentiation.

Things i read:

• https://apastyle.apa.org/Blog/issue-numbers
• https://apastyle.apa.org/style-grammar-guidelines/references/elements-list-entry
• http://www.differencebetween.net/language/difference-between-volume-and-issue/
• https://www.differencebetween.com/difference-between-edition-and-vs-issue/
• https://github.com/plk/biblatex/issues/726
• https://github.com/retorquere/zotero-better-bibtex/issues/925
• https://ftp.gwdg.de/pub/ctan/biblio/bibtex/base/btxdoc.pdf

Interesting.

• When changing number = {3}, to issue = {3}, it is depicted correctly in the entry editor>preview.
• When BOTH number = {3}, AND issue = {3}, are present, then it is depicted correctly.
• When only number field is present, then it is depicted wrongly.

I will create an issue at citeproc. I think the code that was changed for #8279 at https://github.com/michel-kraemer/citeproc-java/commit/ad20fc45cae262bc5044bea4d1f6edfcc6be8d19 could be the culprit, but Michel will know better.

Yes. But #8607 will definitely be merged before next release. Can’t wait forever for something that “might” happen. @adrianocorrea You already can try out the pull-request 😃 It is downloadable from here: https://builds.jabref.org/pull/8607/merge/

As for me, I will monitor https://github.com/citation-style-language/styles/issues/5827 and CSL apa-style with regard to issue/number/eid/page behaviour and if necessary will do a follow up pull-request.

Fun fact:

    <term name="issue" form="short">
      <single>no.</single>
      <multiple>nos.</multiple>
    </term>

Source: https://github.com/citation-style-language/locales/blob/c6e38e6963a9792332c63ea3c3c385176f76f7ea/locales-en-US.xml#L374

Almost.

moewew clarified for Biblatex: “Moving the issue number to issue and article number to number would not be my preference, because the issue number is traditionally number and the article number is eid in biblatex”

The long answer: plk/biblatex#726 (comment)

Ok hold your beer.

Option A (https://github.com/JabRef/jabref/issues/8372#issuecomment-1003526977) by @michel-kraemer is totally viable.

It is the best.

I learned so much about Java “If Else if” statements today xD. Let’s use this code for a test-run:

if (type == CSLType.ARTICLE_JOURNAL) {
    if (entries.containsKey(FIELD_NUMBER) && entries.containsKey(FIELD_ISSUE)) {
        builder.number(entries.get(FIELD_NUMBER));
        builder.issue(entries.get(FIELD_ISSUE));
    } else if (entries.containsKey(FIELD_NUMBER) {
        // map number to issue!
        builder.issue(entries.get(FIELD_NUMBER));
    } else if (entries.containsKey(FIELD_ISSUE)) {
        builder.issue(entries.get(FIELD_ISSUE));
    }
} else {
    builder.number(entries.get(FIELD_NUMBER));
    builder.issue(entries.get(FIELD_ISSUE));
}

If we get a lot of complaints about the rendering in the development version, we always can reverse it for the stable one. @adrianocorrea will definitely be happy 😄

It is very much viable, because I made a mistake. I forgot about:

• The original Bibtex format only knows number. It does not know ‘issue’. According to https://en.wikipedia.org/wiki/BibTeX, Number denotes: The "(issue) number" of a journal, magazine, or tech-report, if applicable. Note that this is not the "article number" assigned by some journals.

Number therefore is issue in Bibtex. Bibtex does not know article-number.

I cross-checked at Taylor & Francis: The number in the number-field that is exported there is the same as the issue-number. Not the article number. Article number is missing.

I cross-checked with these entries: - https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0193972 - https://www.tandfonline.com/doi/citedby/10.1080/13642987.2017.1313237?scroll=top&needAccess=true

THEREFORE:

1. [Bibtex compliancy] Option A (https://github.com/JabRef/jabref/issues/8372#issuecomment-1003526977) by @michel-kraemer is totally viable, since we DO have the issue field available in our data. It is just called number, not issue…

2. [Biblatex compliancy] @Siedlerchr, Jabref does not fetch the article number. I would advise to implement additional fetchers for Biblatex library mode to somehow get the article number.

   Edit: In hindsight, the following statements were wrong: field according to Biblatex standard. Jabref currently fetches the number field following Bibtex standard. In Bibtex number is issue number, while in Biblatex, number is the article-number. I would advise to implement additional fetchers for Biblatex library mode to somehow get the article number, but if we do so, then mapping number to issue in citeproc-java (As done in Option A) will create problems.

@michel-kraemer In light of the [Biblatex compliancy] problem: For long-term stability, couldn’t we just put some labels (one for bibtex and one for biblatex) into Citeproc-java and therefore give Jabref the option to choose when to use one or the other type of rendering, depending on the library mode in Jabref? 🤔 Or the other way round, trigger different rendering by citeproc, if it finds a certain label within Jabref?

As a general reminder about the difference between number and issue, the biblatex documentation (https://ctan.kako-dev.de/macros/latex/contrib/biblatex/doc/biblatex.pdf) on page 22 shows this:

issue field (literal)
The issue of a journal. This field is intended for journals whose individual issues
are identified by a designation such as ‘Spring’ or ‘Summer’ rather than the month
or a number. The placement of issue is similar to month and number. Integer
ranges and short designators are better written to the number field. See also month,
number and §§ 2.3.10 and 2.3.11.

and on page 23:

number field (literal)
The number of a journal or the volume/number of a book in a series. See also
issue as well as §§ 2.3.7, 2.3.10, 2.3.11. With @patent entries, this is the number or
record token of a patent or patent request. Normally this field will be an integer or an
integer range, but it may also be a short designator that is not entirely numeric such
as “S1”, “Suppl. 2”, “3es”. In these cases the output should be scrutinised carefully.
Since number is—maybe counterintuitively given its name—a literal field, sorting
templates will not treat its contents as integers, but as literal strings, which means
that “11” may sort between “1” and “2”. If integer sorting is desired, the field can be
declared an integer field in a custom data model (see § 4.5.4). But then the sorting of
non-integer values is not well defined.

I tested the pullrequest #8370 and the issue persists

JabRef 5.5-PullRequest8370.22–2021-12-29–707c014 Windows 10 10.0 amd64 Java 16.0.2 JavaFX 17.0.1+1

The interesting thing is that the number is depicted correctly under options>preferences>entry preview, but wrongly at entry editor>preview, so i was hoping your pull-request was making a difference 😄