On 3.1.2010 0:38, Daniel Lohmann wrote:
On 30.12.2009, at 01:57, Pavel Sanda wrote:
Petr Šimon wrote:
Currently the citation key can be made out of 'author', 'year',
'title' and
optionally from separators like '_'. I will add another keyword,
'zotero'
that will create the cite key from unique identifier in zotero db.
yep, this was the main complaint in bug #6300. i expect two usecases -
* users who dont care a about citekeys and just want to externally push
citations and need to keep bitex keys stable. for these zotero ID is
the way.
* users who care about keys and need the stable bibtex keys too. for
those
the "customizable" citekey is the way. in this case is expecting
users to
be intelligent about the keys certainly in order.
Hey Petr,
Thanks for all the hard work on LyZ. I haven't checked out Zotero for
a while; liked it a lot, but the integration with LyX was odd and it
tended to corrupt my bibtex databases. However, with LyZ I will give
it another try.
I just want to put emphasize the importance of customizable citation
keys! Many of us work in collaborative environments with shared bibtex
databases and specific "home grown" requirements on how the keys are
made up. For instance, in our group this is:
<author>:<two-digit-year>:<venue> (with <venue> being an abbreviation
for the conference or journal the paper appeared.)
In fact, in my group this it has always been the number one argument
against bibtex frontend XYZ that it does not get the keys right.
Having said that, I would appreciate an even better configurability of
the key generation. What I would really like is the option to enter an
advanced formatting string to generate the keys, including besides the
variables for author, year, etc. various formatting specifiers and
conditionals, such as:
- number of digits (e.g., use only the two last digits of the year)
- upper case/lower vase (very important, unfortunately very few tools
support this)
- conditionals (e.g., @book entries do not have a <venue>; URLs do not
have a year and the <venue> is 'site')
- ...
Another important point in which most, if not all, bibtex frontends
fail miserably is the requirement to be "minimally invasive" on the
bibtex database. Some collaborators still prefer editing the database
with a text editor. What I expect from a good frontend is that it
leaves all entries alone in the file that have not been modified in
the current session, including formatting, LaTeX comment lines
beginning with %, and so on. Basically, if I use your tool to add or
edit an entry 'foobar' and update the bibtex file underneath, the the
diff to the previous version of the bibtex file should contain only
lines that are related to the 'foobar' entry.
Just my 2 items on the long-term wish list :-)
Daniel
Hi Daniel,
I'm glad you said a 'long-term wish list' :)
Bibtex keys are now independent of unique identifiers. I will think
about more advanced customization soon.
As for the bibtex file update and the 'invasiveness of frontends': I
have been exporting from Zotero to bibtex for a while now and rarely did
I have any problems, except for couple of weird characters that were
easily corrected in Zotero. I would rather patch Zotero's bibtex export.
In what cases would manual editing of the bibtex file be necessary?
Important point is that when you are collaborating with others and using
this plugin, only people citing from Zotero should be allowed to update
the file, because I am using the true identifiers in bibtex comments
(actually anywhere oustide of @ and } ) and I don't care about the
bibtex entries at all, except that I replace the bibtex key when necessary.
Best
Petr
