Hi there
I have written a document with many citations in LibreOffice using the ooplugin to handle the citations. I would like to pass it to a colleague so that they can work on it too. Currently the file is linked to my big enormous personal Jabref database, but I would like to have a smaller .bib file containing only the papers I have cited in this document.
Is there a way to quickly obtain a subset of my Jabref database that I can share with my colleague?
Cheers
JP
Hi!
Is there a way to quickly obtain a subset of my Jabref database that I can share with my colleague?
I suppose you are looking for an automated way to do this? I think that this is not possible, but maybe @oscar.gustafsson knows a possibility?
No, not at the moment. Should be quite easy to fix though.
Easy to fix as in 42 minutes. If everything works well there should be a version to test at http://builds.jabref.org/extractoobibdatabase in five minutes or so. crossref field is supported, but I do not think string constants will work currently.
Hey Oscar! Thanks so much, I tried this out and it works great!
There is only one little problem, which is that the big āGenerate new BIB databaseā button. That big button means I canāt make the LO toolbar as small as I like to on my laptop screen. The LO toolbar needs to take up 290 px, which is too much for my 1366-wide laptop. Can I suggest you change the name to āExport citedā or something shorted like that? Also, when I make this sidebar narrower than the buttons permit, the tool ācloseā button is obscured. If the buttons were āself-abbreviatingā or if they converted to icons or something like that, it would be a nicer look.
A follow up question, I guess: how hard would it be to embed the cited database subset and associated style file automatically in the document as a hidden field, document metadata, or whatever? That would be quite handy for collaborative document editing, but would probably be quite a bit of work.
(PS not sure what is meant by āstring constantsā and ācrossref fieldā. I saw that my file references and URLs were copied across in the new DB, which was nice. Donāt know about the other fields you are mentioning).
Hi John!
Glad that it worked! I wasnāt too happy with the length of the button name either, but it was the shortest I could come up with in 42 minutes. 
āExport citedā makes sense and Iāll try to incorporate that.
Regarding storing the bib-file in the document, I must say that it is a really clever idea. However, the problem is that I have very limited knowledge of how the OO/LO and the OO/LO connection actually works (slightly better how JabRef implements it). A quick googling says that it is possible to store metadata (I think that is actually what the reference markers are, if you hover it says JR_something_bibkey), so it may simply be possible to form some sort of special name reference marker and store the whole bib-file there.
For future reference I store the link I found here: https://wiki.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/RDF_metadata
Regarding string constants, you can define strings and give them simpler names (for example, months are typically written as #jan# in JabRef, which means that the entry is stored as month = jan rather than month = {jan}. Now jan is a string name and it is replaced by BibTeX to say Jan. or January depending on the bib-style. These strings can also be defined in a bib-file (BibTeX -> Edit strings), there you could define e.g. jdpipe to always evaluate to your own name and then in the author field your write #jdpipe# and Some Bloke and BibTeX will replace #jdpipe# with your name. Which is convenient as you will then always write your name exactly the same (and, hence, maybe more useful for journal titlesā¦). In this context, Iām not sure that these string definitions will end up in the new bib-file, which is of course a bit of a problem as there will be missing information.
Similarly, the crossref field can be used to link to another entry. Say that you have a book and a book chapter from that book. Instead of copying all information for the book chapter reference, you just enter the BibTeX key of the book in the crossref field and BibTeX will fill in any missing information in the book chapter entry from the bookās entry. I think the linked entry is copied now, so probably that works (unless the linked entry has a crossref in it, then the linked entry of the linked entry is not copiedā¦).
PS. Thanks for the donation. It really made my weekend to see that you appreciated the work that much!
I had to play around and it seems like it is indeed possible to store arbitrary long bookmark markers. There are some limitations to which characters that can be used though and of the obviously relevant ones #,@\/ seems prohibited. Not a major problem though, but will take more than 42 minutes (and I wonāt start on it for a while).
Hi Oscar
Another way would be to store in the document metadata. Apparently OpenDocument specification says that you can put whatever you want there:
http://www.forensicswiki.org/wiki/Open_Document_Format#Metadata
Earlier versions appear to have a limited number of fields, but LO 5.1.4.2 lets me specify the name of the field and it definitely was able to store quite a long chunk of text (I tried it with ~6 bibitems including abstract). I donāt know what the string length limit is, if any. LO seems to strip out the CR/LF characters so some string escaping/unescaping/encoding/compression would be in order.
This relates to the earlier versions:
http://books.evc-cit.info/odbook/ch02.html#meta-xml-section
The other thing you can do is Insertā>Fieldā>User and choose type āTextā and select the āInvisibleā checkbox. I checked, I could definitely paste in 6-7 bibtex items, and they were still there when I loaded the document again. The problem with storing the bibliography as a document field in plain view is that the user could easily accidentally delete it. That might be OK, but unless it can be made obvious to them what they are actually doing, it seems risky, and Iām not sure how that could be done.
Itās interesting to imagine how this would work ā if I email a file with embedded .bib in it, how does Jabref detect and respond? If my colleague returns the file to me with added/modified bibliography entries, how does Jabref deal with thatā¦?
And note that the .jstyle file would need to be embedded too, not just the .bib. And potentially certain user config settings (like strings etc, potentially ā I donāt use those features except for #jan# etc)
Cheers
JP
I agree that metadata would make more sense. Iām not really sure if I fully understand how to access it though, but that is a later issue. Iām wondering if this is the same thing as custom properties https://help.libreoffice.org/Common/Custom_Properties ? I managed to paste a 131k bib-file there if nothing elseā¦
Yes, the interaction part is indeed quite interesting. I imagine that the easiest way might be to do this manually, extract a bib-file and store a bib-file upon request. (The same with jstyle.) I guess introducing some sort of magic is really too much effort at the moment (as in, quite likely that there are lots of strange cases that are bound to go wrong).
A natural approach might be to use the XML features of JabRef. However, Iām not very knowledgeable when it comes to XML, so somehow it seems easier (to me) to just squeeze in the bib-entries.
Regarding strings, Iām working on a better way to copy a subset of a database, including the relevant strings (ideally from other bib-files as well, as I personally prefer to have a separate file with all relevant journal and conference names, shared with my research group). The main problem I face is what to do with the preamble, detect if it should be copied as well and if there are any strings used there. The latter issue should be relatively straightforward by simply parsing it, but then it is quite boring to write parsersā¦
I think that this would be really powerful if there were no explicit export step required; to automatically write the database to the file, so you or your colleague never ends up stranded without the required .bib data to continue editing/working on the document. When āconnectingā to the document, Jabref could offer to import/merge/open the embedded database for you. More magic would be possible, but that would be quite a useful start, I think.