Menu

#787 Support of biblatex/biber crossrefs, related entries

open
nobody
None
3
2014-07-11
2012-12-20
No

The combo of biblatex and biber supports a variety of ways to link entries; there is more advanced crossref mechanism, there is the xref field and there is the possibility to link entries with the 'related' field. Currently the only work halfway in BibDesk. For example these two entries from biblate'x biblatex-examples.bib.

@article{doody,
title = {Hemingway's Style and Jake's Narration},
author = {Doody, Terrence},
related = {matuz:doody},
relatedstring = {\autocap{e}xcerpt in},
journal = {The Journal of Narrative Technique},
volume = {4},
number = {3},
pages = {212--225},
year = {1974}}

@collection{matuz:doody,
title = {Contemporary Literary Criticism},
editor = {Matuz, Roger},
volume = {61},
location = {Detroit},
publisher = {Gale},
pages = {204--208},
year = {1990}}

In LaTeX you would simply \cite{doody} and run biber only once since it knows that it has to look for matuz:doody. BibDesk OTOH doesn't know about this. The effect is that there is no proper preview if I only select matuz:doody since the data of the related entry is not available. If I select both entries, the preview is correct.

Discussion

  • Christiaan Hofman

    I don't ee how we can reasonably support this. It is too complex and conditional.

    Really, biblatex IMHO has gone much too far in complexity and flexibility, which greatly diminishes its use for many people. And really for no real good reason. IMHO even crossrefs were mostly unnecessary complexity, and being lazy can be done in so much better ways these days.

     
  • Christiaan Hofman

    • priority: 5 --> 3
     
  • Simon Spiegel

    Simon Spiegel - 2012-12-20

    "Really, biblatex IMHO has gone much too far in complexity and flexibility,
    which greatly diminishes its use for many people."

    I couldn't disagree more, but I guess that's beside the point.

    But on a technical level: Where is the actual complexity? After all what preview does is just running LaTeX and BibTeX. I don't know why it fails at the moment with the given example, but taking care of the crossrefs is not something BibDesk has to do. It just has to make sure that biblatex and biber can run normally. Biber itself is looking for the linked entries, but obviously it fails at the moment.

     
  • Adam Maxwell

    Adam Maxwell - 2012-12-20

    BibDesk creates a subset of your .bib file for previewing, which includes only the target reference(s) and crossref parent(s) as needed. BibDesk maintains its own crossref lookup table, and recomputing crossrefs and tracking changes/inheritance is extremely complex, fragile, and computationally expensive.

    Adding more "crossref" fields to BibDesk would be madness, so you'll have to live with partially working previews if you're not using BibTeX anymore. Basically, the further biblatex/biber go from BibTeX, the more features in BibDesk are going to break for you. Now that I've said that, Christiaan will probably go implement it to prove me wrong, but I hope his better judgment prevails :).

    Anyway, adding more crossref fields in biblatex was stupid, IMNSHO, and the original crossref is no longer that useful. We have autocomplete and duplication features that are easier to use than mucking about with crossref, and it was basically added for compatibility with long-time BibTeX users who had hundreds of crossref entries and wanted search/display to work. Frankly, I'm pretty annoyed that biblatex/biber keep abusing the .bib format with half-assed backwards compatibility. They should just create their own proprietary file format and be done with it.

     
  • Simon Spiegel

    Simon Spiegel - 2012-12-20

    I can't speak for the developers of course, but one reason why they chose to extend the original .bib format seems quite obvious to me: It allows the user to use existing tools like BibDesk. Even without support for biblatex-specific features, BibDesk still proves extremely useful me. Without excellent apps like BibDesk to manage the database, biblatex would be much less useful. I think it's a pity that you don't take a more friendly approach towards biblatex but I'm glad that I still can use many of BibDesk's feature.

    Now as for the current problem: Why not just dump the complete content of the current database into the preview .bib file and then call \cite with the selected keys? At least for biblatex/biber this would work since it would like for the connected entries itself. Would this mean a big speed hit or are there other reasons for this?

     
  • Simon Spiegel

    Simon Spiegel - 2012-12-20

    I of course meant "it would *look" for the connected entries itself".

     
  • Adam Maxwell

    Adam Maxwell - 2012-12-20

    Extending file formats is one thing, but biblatex has extended BibTeX in a backwards-incompatible way by changing the semantic meaning of some fields, thus subtly or sometimes obviously breaking existing tools. If I needed software that supported biblatex/biber, I'd write it from the ground up, as too many of BibDesk's features are conceptually tied to BibTeX's data model. I have other issues with what they're doing, but that's the most relevant objection.

    Anyway, what you're suggesting would work, but the speed hit from doing it would be identical to that of saving your entire database. If you have 10 entries, no problem. If you have a few thousand, you could beachball every time the preview updates (i.e., on selection changes in the main table). There are ways to work around that (caching, hard links, incremental saves), but they're gruesome and fragile, and you'd still have to ensure entries were sorted correctly for BibTeX crossrefs.

     

Log in to post a comment.

MongoDB Logo MongoDB