Support of different type of BibTeX files

[koppor]

We need two types of BibTeX files: One for collecting (BC) and one for working in tex files (BW).

BC: This file is UTF-8 without encoded umlauts, without additional braces.

BW: This file should have all characters encoded using LaTeX directives and containing only the fields required by the publisher. E.g., no review field, series only in the short form, abbreviated journal name, no DOI, ... (to be defined for each publisher)

Background: The .bst file of the publisher allows more fields than typically used in publications. One always cleans up the file by hand. That effort should be reduced by JabRef.

[ThomasA]

I think JabRef should keep working with the maximally informative format (BC) to retain as much information as possible for storage. Ideally I think it is the responsibility of the style file to get rid of any unwanted fields. UTF is not necessarily a problem either, if using bibtex8 or Biblatex. I know one sometimes has to manually remove certain fields that should not be included in a paper, but for those cases I think it would be better if the BW format you propose were a sort of export filter.

[bluebirch]

👍

[tobiasdiez]

I second the comment of @ThomasA!

With Biblatex it is really easy to use the (BC) format and then delete/modify fields accordingly directly in latex. So in this case, no (BW) file is necessary at all. For the bibtex users, I would suggest the following workflow (which needs some additional features in JabRef):

1. Run latex on your document.
2. Create a new (BW) file based on (BC) and the aux-file. (Not implemented in JabRef I think)
3. Run a cleanup on the new (BW) file. (Here it would be convenient if there were different presets possible.)

So in my opinion, the cleanup facilities should be improved instead of supporting two types of files.

[ThomasA]

Last time I checked, step 2 was possible in JabRef.

[tobiasdiez]

I think this issue can be closed. The cleanup operations have been improved in the meanwhile so that it is relatively easy to convert a BC file to a BW one. Moreover, the consensus above was that JabRef should focus on supporting the BC format.

[koppor]

I'd rather like to put it "on-hold", as sometimes one wants to have complete entries with volume and series, which one doesn't want in the final bib file. One can achieve that with hide/unhide (refs #759), but one then needs version control...

This feature is more for users who stick with the publisher's template (such as LNCS's splncs03.bst instead of https://github.com/neapel/biblatex-lncs).

I also the feature to be useful to have a large clean bibliography database and one bib for each publication. Maybe, this feature should be renamed to "synchronized bibtex files", which transformation operations going on between the large and the publication file.

[koppor]

tex stackexchange question: https://tex.stackexchange.com/q/6393/9075

[koppor]

Another workflow could be a merge-back from the .bib file of the paper. see https://github.com/koppor/jabref/issues/295.

The issue itself adresses the case when working with a group of authors of a paper - and each paper author has its own personal.bib, where entries are copied to the .bib of the paper.

Maybe, the save actions of JabRef are one solution. Maybe, we can create profiles for each publisher (LNCS, IEEE, ...).

[claell]

Adding my workflow: I have a large library with everything in it and then I have separate libraries for each publication. Then I merge them manually to the central library again (and assign them the group of the publication in there as well). As this is manual work, I don't keep up with that task. So some better support for it (as suggested in https://github.com/koppor/jabref/issues/295) would be helpful, indeed :)

[koppor]

I unfreezed, because I have weekly discussions about that feature. These discussions also include different BST styles used by IEEE and ACM causing (unnecessary) load on researchers.

[vvk0107]

@koppor can you please elaborate the issue JabRef#160 more

[koppor]

@vvk0107 This task is not only a programming task, but a software engineering task. One has to think about the users of JabRef and what they want. Did you come across the concept of "user stories", requirements specifications and other tools to make requirements explicit? I think, this issue needs at least 10 hours to come up with details requirements. Users with research experience may have the knowledge to come up with this list. One needs to know the concept of bibtex, bst files and meta data for papers (e.g., full BibTeX data). You can build up that knowledge by yourself by trying out to typeset a paper maybe using the IEEE template. Include an @article there and add pages to the BibTeX entry. See that it is typeset in the paper. But due to space limitations, it might be that one removes it. Thus, one has a variant of a BibTeX entry: one with pages and one without. If one now puts another entry to paper.bib (maybe a colleagure does). How to get this BibEntry back to the original main.bib?

If someone wants to work on this, we can collaboratevily refine this issue. Seeing more than 400 other open issues, I would only do it if there is real interest. A first step to get into the topic is to come of with test cases for the entry duplictation. See #8885 for the issue and add additional tests to https://github.com/JabRef/jabref/blob/main/src/test/java/org/jabref/logic/database/DuplicateCheckTest.java (and possibly fixes to the DuplicateCheck class).

Side note: CrossTeX had another approach for that. But the meta data is not BibTeX, but a variant of it. There is a GUI for it CrossRefX, but not maintained. -- Thus, this information is only interesting for historical reasons and understanding the decision drivers.