I'd also welcome biblatex support. I can't say what the original reporter was hoping for, but I'd suggest a 'switch' in terms of field and entry type support. biblatex has a wider range of entry types, and also uses fields in a different way. For example, it uses 'location' in place of 'address', 'journaltitle' in place of 'journal', etc.
At a more ambitious level, the biblatex project in conjunction with biber is moving toward an XML format for data, rather than the .bib format. This may well be beyond the range of JabRef, but import/export to this format might be useful.
Last edit: Anonymous 2017-03-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Preliminary support has been added in V2.7 Beta 1 (though it doesn't mention it on the change history page). Can this feature request therefore be reviewed in terms of priority, assigned status, etc. please? Is this considered a reasonable priority by the developers, or was this a bit of an 'off the trunk' one-off addition??
To expand on Joseph's comment, I'd suggest that the main essential sub-features of interest are as below:
1) Some sort of global toggle to switch between BiBTeX and biblatex modes
[bibtex files are valid biblatex files; a file that had new biblatex entry types (or biblatex-only attributes for existing types) should ideally bring up a dialog to say that the database appears to be a biblatex one and do you want to switch mode]
[All following referring to biblatex mode]
2) Support for all the biblatex entry types and attributes as user-enterable fields
3) Support for all the entry type and attribute aliases (which allows an existing bibtex file to be a valid biblatex one).
The biblatex standard requires that only an attribute *or* its alias are in the file, not both.
It would seem best just to show the non-aliased fields for editing, but include any alias attribute values in the value box. If the user changes the value, the attribute name would change to the non-aliased one 'under the covers'. (This is preferred to, say, a one-off alias 'correction' when a database is opened in biblatex mode, but see 5.)
4) The formatted reference shown for each entry should recognise all the biblatex entry types accordingly.
5) In biblatex mode, there would be an option to import a bibtex file, which would convert all fields to (non-alias) biblatex ones. (Not very important functionality, but handy.)
6) Similarly, an option to export to bibtex format. This is more complicated, since new biblatex entry types would have to be condensed to bibtex ones (probably mostly to @misc), but is pretty crucial when, say, a journal requires bibtex files and your master JabRef database is now in biblatex format.
All as gleaned from very brief use of biblatex and its manual (http://mirror.ctan.org/macros/latex/contrib/biblatex/doc/biblatex.pdf); I don't claim to be an expert.
The rationale for the functionality is that biblatex seems to be gaining momentum as the successor to bibtex, and is a much more natural 'universal' basis for references since it reflects modern types much better and allows things like newspaper/magazine articles (with a specific date) to be referenced via @article, and Web sites via @online (rather than some non-standard @electronic type which JabRef doesn't support).
Effectively my points 1 and 2 are supported, but not the others. (And the toggle is in advanced options, where longer term it would seem to better as a 'front of house' main window toggle icon or similar.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I too would be keen on biblatex support. I have had a preliminary play with the 2.7b1 release, and will do some more extensive tests with 2.7b1. Thanks to Thomas Arildsen for his hard work.
One issue that I immediately had was that due to the inherent flexibility of biblatex, it has been extended further to accurately meet other style guides. In my case, I want to use the biblatex-chicago package, which extends the biblatex standard to specifically meet the Chicago Manual of Style (CMS). The flexibility of both biblatex and CMS make it the perfect combination for citing obscure and unpublished historical documents such as birth/death/marriages records, personal correspondence, land and tax records etc., as well as online collections, databases and images.
The biblatex-chicago package adds even more Entry Types than biblatex itself has (http://mirrors.ctan.org/macros/latex/contrib/biblatex-contrib/biblatex-chicago/doc/biblatex-chicago.pdf). I know I should be able to create my own entry types and associated optional entry fields in the Jabref UI (and for now, that's acceptable), but in the long-term each biblatex-extension is going to define its own Entry Types and Entry Fields. Therefore I think we need to hook up the Entry Types and Entry Fields to the plugin system so that we can, for example, create a biblatex-chicago plugin that creates the missing entry and field types for us as per the standard. Uninstalling this plugin would revert back to the standard biblatex entry types.
If we don't do this, then Jabref will be almost too cumbersome to set up for a given project, and switching between biblatex extensions will be a lot of work.
I am willing to help in a testing and documentation capacity. Unfortunately, I am not Java'd-up enough to contribute to the codebase.
Cheers
Ken
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We really would like to improve the support for BibLaTeX and also welcome documentation for it. Possibly, we could have a winter task force to improve BibLaTeX support until Easter 2013.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure what is planned for the editor interface, but that is the main shortcoming regarding biblatex support as it stands today. Since biblatex in many cases use several fields to represent data that are simply one field in BibTeX, editing is awkard, to say the least.
An example: In biblatex, titles are made up by the title and subtitle fields (and corresponding journaltitle and journalsubtitle fields, and so on). Since the subtitle field is, by definition, optional, it can be found under one of the optional tabs in the editor. This, in turn, means that you have to switch between different screens in the editor just to enter simple things like title and subtitle (which, in standard BibTeX, would consist of only one field, title and subtitle delimited by a colon or something similar).
Another example is the eprint, eprintclass and eprinttype which is used to specify links to electronic documents at Google Books, JSTOR and other repositories (specified by the eprinttype field).
Proper editing would take this into account and supply optional fields as "expandables" or something similar in the edit dialog. For example, when entering title, there could be a small "more" button next to the title input field that expands a subtitle field, titleaddon field, and so on.
How the fields relate to each other and which fields goes with which entry types is clearly stated in the biblatex documentation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A first step would be for the submitter to describe what supporting biblatex actually means in terms of JabRef functionality.
View and moderate all "feature-requests Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Feature Requests"
I'd also welcome biblatex support. I can't say what the original reporter was hoping for, but I'd suggest a 'switch' in terms of field and entry type support. biblatex has a wider range of entry types, and also uses fields in a different way. For example, it uses 'location' in place of 'address', 'journaltitle' in place of 'journal', etc.
At a more ambitious level, the biblatex project in conjunction with biber is moving toward an XML format for data, rather than the .bib format. This may well be beyond the range of JabRef, but import/export to this format might be useful.
Last edit: Anonymous 2017-03-16
Preliminary support has been added in V2.7 Beta 1 (though it doesn't mention it on the change history page). Can this feature request therefore be reviewed in terms of priority, assigned status, etc. please? Is this considered a reasonable priority by the developers, or was this a bit of an 'off the trunk' one-off addition??
To expand on Joseph's comment, I'd suggest that the main essential sub-features of interest are as below:
1) Some sort of global toggle to switch between BiBTeX and biblatex modes
[bibtex files are valid biblatex files; a file that had new biblatex entry types (or biblatex-only attributes for existing types) should ideally bring up a dialog to say that the database appears to be a biblatex one and do you want to switch mode]
[All following referring to biblatex mode]
2) Support for all the biblatex entry types and attributes as user-enterable fields
3) Support for all the entry type and attribute aliases (which allows an existing bibtex file to be a valid biblatex one).
The biblatex standard requires that only an attribute *or* its alias are in the file, not both.
It would seem best just to show the non-aliased fields for editing, but include any alias attribute values in the value box. If the user changes the value, the attribute name would change to the non-aliased one 'under the covers'. (This is preferred to, say, a one-off alias 'correction' when a database is opened in biblatex mode, but see 5.)
4) The formatted reference shown for each entry should recognise all the biblatex entry types accordingly.
5) In biblatex mode, there would be an option to import a bibtex file, which would convert all fields to (non-alias) biblatex ones. (Not very important functionality, but handy.)
6) Similarly, an option to export to bibtex format. This is more complicated, since new biblatex entry types would have to be condensed to bibtex ones (probably mostly to @misc), but is pretty crucial when, say, a journal requires bibtex files and your master JabRef database is now in biblatex format.
All as gleaned from very brief use of biblatex and its manual (http://mirror.ctan.org/macros/latex/contrib/biblatex/doc/biblatex.pdf); I don't claim to be an expert.
The rationale for the functionality is that biblatex seems to be gaining momentum as the successor to bibtex, and is a much more natural 'universal' basis for references since it reflects modern types much better and allows things like newspaper/magazine articles (with a specific date) to be referenced via @article, and Web sites via @online (rather than some non-standard @electronic type which JabRef doesn't support).
For completeness, I did a quick review of the changes as in V2.7 Beta 1 on the jabref-users mailing list:
http://sourceforge.net/mailarchive/forum.php?thread_name=BANLkTim%3D%3Dmroq-EyooBjQKDjizd5KuV5Bg%40mail.gmail.com&forum_name=jabref-users
Effectively my points 1 and 2 are supported, but not the others. (And the toggle is in advanced options, where longer term it would seem to better as a 'front of house' main window toggle icon or similar.)
I too would be keen on biblatex support. I have had a preliminary play with the 2.7b1 release, and will do some more extensive tests with 2.7b1. Thanks to Thomas Arildsen for his hard work.
One issue that I immediately had was that due to the inherent flexibility of biblatex, it has been extended further to accurately meet other style guides. In my case, I want to use the biblatex-chicago package, which extends the biblatex standard to specifically meet the Chicago Manual of Style (CMS). The flexibility of both biblatex and CMS make it the perfect combination for citing obscure and unpublished historical documents such as birth/death/marriages records, personal correspondence, land and tax records etc., as well as online collections, databases and images.
The biblatex-chicago package adds even more Entry Types than biblatex itself has (http://mirrors.ctan.org/macros/latex/contrib/biblatex-contrib/biblatex-chicago/doc/biblatex-chicago.pdf). I know I should be able to create my own entry types and associated optional entry fields in the Jabref UI (and for now, that's acceptable), but in the long-term each biblatex-extension is going to define its own Entry Types and Entry Fields. Therefore I think we need to hook up the Entry Types and Entry Fields to the plugin system so that we can, for example, create a biblatex-chicago plugin that creates the missing entry and field types for us as per the standard. Uninstalling this plugin would revert back to the standard biblatex entry types.
If we don't do this, then Jabref will be almost too cumbersome to set up for a given project, and switching between biblatex extensions will be a lot of work.
I am willing to help in a testing and documentation capacity. Unfortunately, I am not Java'd-up enough to contribute to the codebase.
Cheers
Ken
We really would like to improve the support for BibLaTeX and also welcome documentation for it. Possibly, we could have a winter task force to improve BibLaTeX support until Easter 2013.
I'm not sure what is planned for the editor interface, but that is the main shortcoming regarding biblatex support as it stands today. Since biblatex in many cases use several fields to represent data that are simply one field in BibTeX, editing is awkard, to say the least.
An example: In biblatex, titles are made up by the
titleandsubtitlefields (and correspondingjournaltitleandjournalsubtitlefields, and so on). Since thesubtitlefield is, by definition, optional, it can be found under one of the optional tabs in the editor. This, in turn, means that you have to switch between different screens in the editor just to enter simple things like title and subtitle (which, in standard BibTeX, would consist of only one field, title and subtitle delimited by a colon or something similar).Another example is the
eprint,eprintclassandeprinttypewhich is used to specify links to electronic documents at Google Books, JSTOR and other repositories (specified by theeprinttypefield).Proper editing would take this into account and supply optional fields as "expandables" or something similar in the edit dialog. For example, when entering title, there could be a small "more" button next to the
titleinput field that expands asubtitlefield,titleaddonfield, and so on.How the fields relate to each other and which fields goes with which entry types is clearly stated in the biblatex documentation.