search

koppor / jabref

Collection of simple for JabRef issues. Please submit PRs to https://github.com/jabRef/jabref/.
https://github.com/jabRef/jabref/
MIT License
8 stars 13 forks source link

Request: Add capability of cross-referencing entries within the same database #79

Open teertinker opened 8 years ago

teertinker commented 8 years ago

I don't know whether it is time for a feature request, but since there has been much development recently I thought, I could at least try.

The group function is great to assign different papers to certain topics. However, in some cases I want to connect two or three papers somehow, because they have a very close relationship. E.g. there is a follow up study. For those cases keywords or groups do not work efficiently.

That's why I would really love a Crossreference function. Up till now, I just use the "crossref" field of an entry manually and put the bibtexkey of the entry I want to refer to in there. This, however, has two limitations:

  1. I have to add bibtexkeys in the crossref field to both papers, to link them in both directions
  2. It is rather complicated to jump from one entry to the one in the crossref field.

It would be great if there was a possibility to add some kind of link from one entry to another that works in both directions. For example there could be a new field in the entry editor "Crossreference". And after putting a bibtexkey of another paper from my database into it, the bibtexkey of the first paper is being put into the paper refered to. Than may be the preview window can somehow be used, to create hyperlinks from these crossreferenced bibtexkeys to other papers in the same database. In that case I could jump from one entry to another by using the preview window.

Thanks Felix

oscargus commented 8 years ago

I'm thinking about implementing something like this, see #14

One thing that is not really clear to me is if this "crossreference" should be uni- or bidirectional. Assume that you have entries 1, 2, and 3. You put 1 in 2 as a crossreference, should that automatically lead to that 2 is put in 1? In that case, if you put 3 in 2, should 3 also be put in 1 (and 1 and 2 in 3)? Any opinion?

Also, even though it do require much more effort, I've been thinking of make this configurable, such that the user can define different relations between papers "builds on", "generalization of", "outperforms" etc. The first step may be "cites" (an indirect cited by which is not shown in the bibtex file, but in JabRef) and some sort of crossreference.

tobiasdiez commented 8 years ago

Be careful using the crossref field for these kind of functionality. Biblatex has special build-in functions for this field (like deriving bib-data from the parent). So maybe a JabRef specific field might be a better idea to implement this linking.

teertinker commented 8 years ago

Thats great to hear! I would love this feature.

I was talking about a bidirectional relationship. I think in most cases if one wants to mark a paper e.g. as "builds on", it has some meaning for the other paper as well. I think a bidirectional implementation could however cause problems for the different categories you have in mind. Because one paper that marks another as "builds on", could mean for the other paper, that the first one is e.g. a "generalization" of the other one.

There was an extension to jabref on sourceforge, but I cant find it anymore. It was building relational graphs out out each literature reference of a paper. For me, this was too much information and to many relationships, I have professional databases for these purposses (e.g. sciencedirect). Thats why I never used it. In my case I'd like to cross reference a paper may be in one of 10 cases, to mark a special connection between few papers, that goes beyong grouping and keywords.

Tobias is right, that crossref shouldn't be used for this in general. Since I don't write papers in Latex but in LibeOffice, I never had any problems.

oscargus commented 8 years ago

It may be this one: http://sourceforge.net/projects/jabrefprrvp/ (see #95)

Correct, the crossref field should be avoided.

I've drafted some more details in #14 just now and I think those follows your ideas. I've realized that it is probably better to get a "simple" working version out rather than having a highly configurable monster that takes years to develop and configure. ;-)