On 9 Jul 2008, at 2:52 PM, Stephan Kurz wrote:
> Dear all,
>
> I have been using BibDesk for quite a while now (AFAIR since release
> 0.73), creating a lot of .bib files that cover pieces of my academic
> work (one .bib file per article).
That's longer than I've used it.
> These files are also spread across 3
> computers (and an SVN repository).
>
> To avoid duplicate bib entries, I would now like to create one large
> master file (my estimate is that this will sum up to around 3000
> entries). Summertime is probably the time to keep up with some things
> and get my computer environment properly running before doing some
> writing tasks…
>
> Before doing this (by means of merging in external file groups as
> suggested on this list), I have some questions that I hope somebody
> can
> provide answers or actual usage experience for:
>
> - Will BD deal smoothly with 3000+ entries? I am mainly using an 2007
> iMac and a G4 PowerBook 1,67 (both with 2gb of RAM).
>
That shouldn't be a problem.
> - Citekeys issue:
> Some were generated manually in the old days when either I did not
> understand how to autogenerate them or the feature was not yet
> implemented. Others, I have autogenerated (using several different
> custom formats, stupid me).
> As I have used the keys in my .tex sources, these should not change
> (obviously). I just tried it, and BibDesk’s "Select duplicate"
> mechanism
> does find duplicate publications that have different citekeys.
> Great! I
> still have to clean those up manually anyway, and achieving a
> consistent
> scheme of cite keys would require reediting old .tex sources. Are
> there
> ways to do that automagically? If not, I’ll probably leave
> everything as
> is since it is rather a problem of cosmetics.
Not everything, I couldn't even imagine how that may work. For example
BibDesk has no idea which .tex files you have and how referecnes are
used there, so you should not expect BibDesk to be able to fix
citations in those. Generating cite keys in BD is easy enough, as you
probably know. But synchronizing those with .tex files can be a pain,
and not something BD can do.
The only thing I can think of is to write an AppleScript. It should
scan your .tex files for cite keys (in \cite and \bibitem), generate
new cite keys for those keys (which can also be called in
AppleScript), and replace them in the .tex files and in BD.
>
> - Autofile issues:
> Some of my bibs have papers filed (via Autofile, and some are also
> still
> stored somewhere on the file system of my PowerBook with links in the
> deprecated local-url field, but that is the minority of the files).
> Unfortunately, to different fixed locations on different computers.
> What
> is the best way to bring these together?
I think the easiest way is to fix the .bib files at the local level
before merging and then moving the file together with the PDFs to your
joined location. In more detail:
1. On your PB make sure you save using a recent BD version including
the new linked files (you may leave the old-style Local-Url fields if
you want, it would be a backup solution, you could remove them later
if you want).
2. You may want to move the files first (move, not copy) so they are
placed near the .bib file (into a common folder), make sure you save
the .bib file after doing this.
3. Archive the .bib file and the linked files together (it is
important that the relative locations remain intact).
4. On your new location unarchive it. When you open the
unarchived .bib file the linked files should work. Make sure you save
the .bib file on the new system to update the alias links to the files.
5. Now you can copy the items (copy/paste, drag/drop, or merging from
external groups) to your master .bib file. The (new style) links
should work in the copied items.
>
> My ideal scenario would be to have a central repository on my
> university
> server that would sync with my workstations to provide offline
> access as
> well. That won’t work, so probably I’ll stick to mounting the
> university
> server (which is no problem from my work computer, but I need a VPN
> connection from home).
> What will happen if I change the "fixed location" to, say,
> "/Volumes/myserver/Papers/" -- can I, say, batch replace the location?
There is a problem with moving papers to a different volume. BibDesk
can automatically follow linked files that are moved outside of
BibDesk. But when you "move" them to a different volume the files are
actually copied rather than moved, so BibDesk will not be able to find
the files in the new location. On the other hand if you use BibDesk
(in particular the manual auto-file feature) to move the files to the
new location, this should work. Just set the papers folder in the
prefs to "/Volumes/myserver/Papers/" and choose an appropriate
filename format, select the items or files you want to move there, and
choose an Auto-File menu item.
>
> Another Autofile thing is that I once had the idea to divide my bibs
> and
> Autofiled papers between primary and secondary sources by assigning a
> document info key and using this in the Autofile local file format
> (%i{key}/somegeneratedname). Can I safely remove the "%i{key}/"
> fragment
> without losing the connection between .bib and the actual files?
The format is not used to find linked files, only to generate new
locations. So any change to the format only has an effect when you
move papers using the auto-file format (either manually or
automatically). So there can be no problem.
>
> Probably the "match files" thing is the way to go, but actually I did
> never try this.
It's meant to match unlinked files with files in your database. If you
have the files already linked somewhere it may not be what you want.
> Am I right that the old menu item "consolidate linked
> files" has been renamed and reworked to the "Autofile Linked Files"
> menu
> item?
>
That's right, it's just a bit more consistent naming as we were using
the term "consolidate" and "auto file" as synonyms in the help.
> - Duplicates and identification:
> For being able to see from which context each publication is coming
> from, I would like to assign keywords to all publications in a given
> .bib file (using the Add Keyword applescript by Derrick Fay). This
> does
> not prevent otherwise identical entries to be recognised by the
> "select
> duplicates" mechanism,, but are there any other downsides to this
> approach?
Can't think of any, makes perfect sense.
> Thanks for an amazing app, and for all your comments!
> Stephan
You're welcome,
Christiaan
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bibdesk-users mailing list
Bibdesk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-users
