From: tsd@tsdye.com (Thomas S. Dye)
To: Richard Lawrence <richard.lawrence@berkeley.edu>
Cc: emacs-orgmode@gnu.org
Subject: Re: Citation syntax: Underscore MUST(?) be allowed in cite keys?
Date: Mon, 09 Mar 2015 06:37:02 -1000 [thread overview]
Message-ID: <m2y4n6ktzl.fsf@tsdye.com> (raw)
In-Reply-To: <87k2yqyx55.fsf@berkeley.edu> (Richard Lawrence's message of "Mon, 09 Mar 2015 09:05:10 -0700")
Richard Lawrence <richard.lawrence@berkeley.edu> writes:
> Hi Tom and all,
>
> "Thomas S. Dye" <tsd@tsdye.com> writes:
>
>> Richard Lawrence <richard.lawrence@berkeley.edu> writes:
>>
>>> But my opinion probably shouldn't count for much on this
>>> point, because I don't use a citation manager myself (I use org-bibtex),
>>> and I write my own keys.
>>
>> Oh my. This is a lot to keep in your head as a bibliographic database
>> grows. The one I've created with my colleagues over the last two
>> decades has more than 5,000 entries.
>
> Yes, I realize this method probably isn't going to scale well in the
> long run, but it's working for me for now. The vast majority of my keys
> are just the author's last name plus the year. I just write a key like
> that when I add something to my reading list, and fix the rare duplicate
> cases as necessary.
>
> (Just to explain why it makes sense to me to do it this way: I used to
> work in a psychology lab, where I had to write a lot of little programs
> to do data analysis. The worst part of that job was always dealing with
> malformed, missing, and otherwise-corrupt data captured by someone else.
> Since then, my attitude has always been that it's much easier to correct
> that data at the point where it's captured than figure out what to do
> with it somewhere further down the processing pipeline, after the reason
> *why* it is malformed has been lost. In the context of this discussion,
> that translates to: a work doesn't get a key in my reading list unless I
> have complete citation information for it. Sometimes I put items on my
> reading list that I don't have citation data for yet, but I don't do
> org-bibtex-create-in-current-entry on that item until I have the
> citation data and can assign it a key.)
>
We've had a couple dozen contributors to our bibliography over the
years. Initially, we assigned keys by hand but we found this led to
very many duplicate entries. Generating keys has helped a lot in this
situation because most duplicates are caught when we merge the
project-specific database, which has already been edited, with the
central one.
>>> I don't disagree, but I think there is an empirical question that needs
>>> to be answered here: within the keys people actually use, how many do
>>> not conform to the syntax? Of those that don't, do they represent
>>> `normal' cases or not?
>>
>> A good friend of mine is a military historian who writes books
>> describing how the Army habitually plans to fight the last war over
>> again, then has to adapt hurriedly when the next war turns out to be
>> different. It strikes me that basing core features of the citation
>> syntax on the software users happen to be using today is a bit like
>> this--at some point the design of the system will prove unprepared for
>> new developments.
>>
>> I think Vaidheeswaran C's example of a citation scraped off the internet
>> with Zotero should carry a lot of weight. This kind of thing is bound
>> to happen more and more as authors increasingly harvest citation
>> information on-line (my generation typically looks on this with horror,
>> but we'll be swept aside).
>
> That's a fair point.
>
>> I kind of like Rasmus' idea to make the citation insertion routines
>> aware of punctuation and use a full citation where a shortcut would
>> introduce ambiguities.
>
> That would work for me. Like Rasmus, I don't particularly like the idea
> of letting the syntax of keys vary in the shortcut case and the full
> citation case, but if the only difference is whether or not they can end
> in clause-ending punctuation, maybe this is the least-bad option.
>
> Another option would be to allow clause-ending punctuation in all keys,
> but introduce some kind of optional syntax to express `this key ends
> here'. This could be used to disambiguate the key from any following
> punctuation in those cases where this is needed. Perhaps something like
> '{}', since even LaTeX won't allow '}' at the end of a key, or maybe
> just '\'. Thus, in these examples:
>
> This is an in-text citation, as was shown by @Doe99{}. The next sentence.
> This is an in-text citation, as was shown by @Doe99\. The next sentence.
>
> the key would be parsed as `Doe99', but in this example:
>
> This is an in-text citation, where @Doe???? is mentioned mid-sentence.
>
> the key would be parsed as `Doe????'.
>
> What do you think?
The {} terminator is used elsewhere in Org mode, so it might be the
least bad option in this instance.
All the best,
Tom
--
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com
next prev parent reply other threads:[~2015-03-09 16:37 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-04 18:21 Citation syntax: Underscore MUST(?) be allowed in cite keys? Vaidheeswaran C
2015-03-04 18:30 ` Rasmus
2015-03-04 18:42 ` Vaidheeswaran C
2015-03-04 19:01 ` Rasmus
2015-03-04 19:18 ` Vaidheeswaran C
2015-03-04 21:38 ` Christian Moe
2015-03-05 5:00 ` Richard Lawrence
2015-03-06 10:49 ` Nicolas Goaziou
2015-03-06 11:55 ` Rasmus
2015-03-06 17:34 ` Nicolas Goaziou
2015-03-06 17:55 ` Rasmus
2015-03-06 21:01 ` Eric S Fraga
2015-03-06 12:41 ` Vaidheeswaran C
2015-03-06 18:09 ` Richard Lawrence
2015-03-07 6:28 ` Vaidheeswaran C
2015-03-07 17:09 ` Richard Lawrence
2015-03-07 18:20 ` Vaidheeswaran C
2015-03-08 8:19 ` Stefan Nobis
2015-03-07 17:50 ` Thomas S. Dye
2015-03-08 0:18 ` Nicolas Goaziou
2015-03-08 2:12 ` Rasmus
2015-03-08 4:19 ` Thomas S. Dye
2015-03-08 12:34 ` Rasmus
2015-03-08 17:07 ` Thomas S. Dye
2015-03-08 17:49 ` Rasmus
2015-03-09 1:56 ` Richard Lawrence
2015-03-09 2:29 ` Thomas S. Dye
2015-03-09 8:57 ` Stefan Nobis
2015-03-09 9:19 ` Vaidheeswaran C
2015-03-09 9:49 ` Stefan Nobis
2015-03-09 10:46 ` Vaidheeswaran C
2015-03-09 11:02 ` Rasmus
2015-03-09 11:27 ` Stefan Nobis
2015-03-09 16:05 ` Richard Lawrence
2015-03-09 16:37 ` Thomas S. Dye [this message]
2015-03-09 16:49 ` Eric S Fraga
2015-03-09 17:49 ` Thomas S. Dye
2015-03-09 18:00 ` Eric S Fraga
2015-03-09 18:44 ` Thomas S. Dye
2015-03-09 19:26 ` Eric S Fraga
2015-03-09 18:50 ` Richard Lawrence
2015-03-09 21:07 ` Rasmus
2015-03-09 22:33 ` Richard Lawrence
2015-03-10 0:37 ` Rasmus
2015-03-10 15:35 ` Richard Lawrence
2015-03-10 0:36 ` Richard Lawrence
2015-03-10 7:06 ` Eric S Fraga
2015-03-10 8:15 ` Nicolas Goaziou
2015-03-10 8:50 ` Rasmus
2015-03-10 10:18 ` Eric S Fraga
2015-03-10 14:35 ` Matt Price
2015-03-10 15:32 ` Richard Lawrence
-- strict thread matches above, loose matches on Subject: below --
2015-03-04 18:21 Vaidheeswaran C
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2y4n6ktzl.fsf@tsdye.com \
--to=tsd@tsdye.com \
--cc=emacs-orgmode@gnu.org \
--cc=richard.lawrence@berkeley.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).