Что такое хорошая система для генерации эталонных ключей BibTeX?

При использовании диспетчера ссылок (или даже при отслеживании ссылок в рукописном черновике) обычно имеется ключ для каждой записи при обращении к элементам, которые компьютер (или вы в окончательной форме) позже заменяет правильно оформленной ссылкой. (в стиле журнала).

Например, в BibTeX, с которым я лучше всего знаком, запись \cite{Box2015a}может быть заменена на «[1]», или на «(Box, O. 2015)», или на «(Box, O. 2015, Формат значимого справочного ключа)» в зависимости от по стилю - ключ, о котором идет речь, является Box2015aчастью.

Наличие хорошего формата ключа кажется полезным, поскольку можно потратить много времени только на просмотр ключа, а не на полный справочник. Просто имя автора и дата, а письмо для разрешения конфликтов не кажется идеальным.

Работала ли Box2015aБокс над форматами осмысленных справочных ключей? Или это была его работа над зависимостью скорости велосипеда от погоды? Было бы неловко сделать это неправильно, а также случайный плагиат (поскольку не была дана ссылка на правильную статью).

Какой лучший формат для ссылочных ключей?

Я лично использую формат «АвторГод-ПервоеСловоНазвания», этого достаточно для разрешения конфликтов и напоминания о том, что это за статья.
@fjarri: Я полагаю, у вас есть запасной план для таких случаев, как Barbará2000-Using , Stonebraker1993-The , Roucairol1982-On , Wang2000-A , Shin1998-A , Jain1996-Similarity , Yu1998-Online , Han2000-Mining , Liu1987-Performance , Ю1994-Планирование и т.д., все из которых выявляют не менее 3-х публикаций ;)
@ORMapper: конечно, если заголовок начинается со статьи или предлога, я беру следующее слово. Не вижу проблемы ни в "майнинге", ни в "похожести", достаточно напомнить, какая из двух-трех работ.
@fjarri: я скорее имел в виду случай, когда вам нужно различать несколько публикаций, для которых один из ключей — например, Jain1996-Similarity — действителен.
Я использую ту же систему, что и @fjarri, но несколько слов из названия, что делает его уникальным и легко узнаваемым для меня. Ключи становятся немного длинными, но, поскольку я все равно использую RefTex (часть AUCTeX для emacs), это никак не влияет на мой рабочий процесс. Например, «Poincare1892:mech-celeste1» относится к первому тому знаменитого труда Пуанкаре «Les méthodes nouvelles de la mécanique céleste».

Ответы (6)

Вероятно, единственное общее правило, которому нужно следовать, состоит в том, что ключ должен быть чем-то, что хорошо характеризует документ . Что-либо более конкретное будет во многом зависеть от тем, о которых вы пишете, и варьироваться от ссылки к ссылке:

  • Является ли название очень уникальным или, скорее, общим? В первом случае в ключ может быть интегрирована сокращенная версия названия. (В качестве случайного примера: заголовок «Треугольный процессор и нормальный векторный шейдер: система VLSI для высокопроизводительной графики» можно было бы сократить до чего-то вроде TriangleProcHighPerf .)
  • Описывается ли в публикации продукт или технология, у которой есть название (которое вы также можете использовать в своем тексте)? Если это так, то это имя может стать частью ключа.
  • Связана ли публикация с узнаваемым именем автора , или вы редко встречаете одно и то же имя автора дважды в литературе, с которой работаете, особенно в отношении конкретных подходов? В последнем случае имена авторов могут быть просто произвольными строками, которые не помогут вам вспомнить что-либо конкретное, в то время как в первом случае вы можете подумать о включении в ключ имени автора, с которым произведение связано.
  • Является ли этот год каким-то особенным для работы? Например, является ли это исключительно ранним примером предположительно современного изобретения или это вариант, который стал известен как «версия 2011 года» определенного подхода? Если это так, год может быть обоснованно частью ключа, в противном случае он кажется излишним.
  • Можно ли классифицировать публикацию? Например, вы можете захотеть указать в ключе, является ли что-то черновиком концепции , пользовательским исследованием концепции, представленной в другом месте, обзором нескольких методов или обоснованием дизайна для данной концепции.
  • Существуют ли различные версии практически одного и того же произведения, опубликованные разными издательствами? Различные макеты и формы представления (монохромные и цветные, ...) могут иметь разные сильные стороны, поэтому вы можете в конечном итоге захотеть специально сослаться (wlog) на версию Springer и версию IEEE какой-либо работы, которая по какой-то причине была опубликована дважды . В этом случае включение имени издателя в ключ может быть разумным.

Надеюсь, это поможет понять идею — я не вижу здесь причин для единого формата ключа; вместо этого этот формат для конкретного случая подчеркивает особенности каждой работы, на которую ссылаются, и поэтому, кажется, лучше всего помогает запомнить, какая ссылка указывает на какую работу в моем опыте.

Лично для меня вышеприведенная система обычно приводит к ключам, которые никогда не включают имя автора или год публикации, и почти всегда имя концепции, в противном случае некоторые фрагменты названия статьи. В зависимости от ваших тем, у вас могут быть разные предпочтения.

У меня никогда не было проблем с конфликтами клавиш при использовании этого подхода; во всяком случае (не то, чтобы это действительно вызвало какие-либо проблемы), я мог получить несколько разных ключей в тех случаях, когда я создавал записи библиографии для одной и той же публикации несколько раз, а не копировал первый в более поздние работы.

Обобщить:

  • Преимущество этой системы в том, что вам не нужно запоминать какую-либо информацию, которая не является описательной для содержания статьи (год публикации, имя автора, место публикации, ...), чтобы понять ссылку.
  • Недостатком может быть то, что ключ не может быть сгенерирован автоматически, хотя я использую один файл .bib для каждого проекта , и мой рабочий процесс обычно решает добавить ссылку -> искать ссылку в JabRef, чтобы проверить, есть ли она там -> добавить, если это не так . exists -> + для получения готовой к вставке команды в буфер обмена , где автоматическая генерация ключей не является проблемой.CtrlK\cite

Я использую справочные ключи (BibTeX), которые состоят из трех частей:

  • фамилия первого автора
  • две последние цифры года издания
  • первое осмысленное слово из названия

Понятие «значимые слова», конечно, немного расплывчато. Обычно это первое прилагательное, глагол (кроме «to be») или существительное в названии. Например, я бы использовал box15meaningfulдля ссылки на документ под названием «О значимых форматах справочных ключей», но box15bicycleдля ссылки на «Зависит ли скорость велосипеда от погоды?».

(Кажется, есть термин "первое осмысленное слово из названия", так как это понятие используется или использовалось в каталогах библиотек, но я забыл этот термин).

С моей точки зрения, основными преимуществами этой системы являются:

  1. Учитывая полную ссылку, я могу предсказать ключ цитирования. Например, когда я смотрю на печатную статью и хочу процитировать ее, я знаю ключ цитирования, не просматривая его в файле BibTeX и не используя какой-либо программный инструмент для его поиска.

  2. Учитывая ключ цитирования, у меня есть некоторое представление о том, что это за статья, потому что ключ включает значимое слово из заголовка.

  3. Клавиши достаточно короткие и не слишком загромождают мой текст.

  4. Ключи цитирования могут использоваться как часть имен файлов, поэтому я также могу называть PDF-файлы подобным образом, если у меня есть статья, доступная в формате pdf на моем жестком диске. Например, у меня было бы box15meaningful.pdfи box15bicycle.pdf.

  5. Ключи цитирования можно использовать как часть URL-адресов, поэтому я могу называть веб-сайты, посвященные моим собственным статьям. Например, если бы я был Боксом, у меня мог бы быть веб-сайт, на http://my-university.edu/~box/publications/box15bicycle/котором вы могли бы загрузить необработанные данные, используемые для моего исследования скорости велосипеда.

  6. Имея два файла BibTeX, которые используют эту схему, я могу объединить их, объединив записи с одним и тем же ключом, потому что одна и та же статья всегда будет иметь один и тот же ссылочный ключ.

Это почти не ответ. Причина в том, что я использую формат, аналогичный тому, который вы считаете неадекватным: "FirstAuthorLastName:Year". В моей области мы используем ссылки в стиле Гарварда, так что это почти то, что появляется в тексте. Двоеточие не является ключевым элементом, просто я использую форму «tab:xxx», «fig:xxx» и «eq:xxx», где «xxx» — это уникальное имя, которое я хочу для объекта, для маркировки поплавки и уравнения. Я хочу сказать, что для меня краткость является необходимостью, поскольку я не хочу, чтобы вокруг документа висели излишне длинные ключи BibTeX или метки. Некоторое время я пытался добавить количество авторов, например "Smith+4:2005", чтобы отличить его от "Smith:2005" с одним автором, но это оказалось слишком утомительно для настройки. Я также сократил несколько авторов до "Smith+:2005". " некоторое время.

Так почему же я работаю с более короткой формой? Во-первых, я знаю, на какой материал ссылаюсь. Я также знаю материал в этой области. Позже я также дважды проверяю ссылки, поскольку они появляются в списке литературы, конечно же, перед отправкой рукописи. Таким образом, ключевым моментом здесь является компромисс между добавлением большого количества информации на этикетку с меньшей степенью «неправильных ссылок» и короткими формами с потенциальным риском большего количества промахов. В конце концов вы используете то, что вам подходит, но со временем вы, вероятно, упростите.

Написав как статьи, так и очень длинные отчеты/книги, я никогда не считал это большой проблемой. Я могу понять, что это становится проблемой, если вы по какой-то причине используете много ссылок, с которыми вы не знакомы. Так что «лучше» — это то, что вы считаете лучшим. Если я правильно понимаю из вашего профиля, что вы стремитесь получить степень доктора философии, и я уверен, что ваша база данных будет расти в определенном направлении во время докторской степени, вы станете близко знакомы с этим набором литературы и, возможно, вы измените способ, которым вы BibTeX ключевые метки ваши ссылки.

Так что лучше то, что лучше всего работает для вас в данный момент. В долгосрочной перспективе, по моему опыту, чем проще, тем лучше.

Отображение «полной информации о цитировании» в «ключ цитирования» во многом является хеш-функцией , и обычно по своей конструкции легко применяется, но трудно инвертируется. Мы делаем это, потому что не хотим набирать от 50 до 100 символов каждый раз, когда цитируем статью.

Часто самый простой способ восстановить данные из хэш-ключа — найти их в словаре/таблице. Если ваша библиографическая база данных достаточно велика, она больше подходит для программного обеспечения, чем для вашего мозга.

Итак, мой рабочий процесс делает следующее:

  • Я использую JabRef в качестве основного менеджера библиографических данных, а также для отслеживания моей растущей коллекции PDF-файлов.
  • Формат ключа цитирования: ABCDEF1234?Первые шесть символов образованы именами авторов (по некоторому правилу), за ними следует год из четырех цифр и суффикс устранения неоднозначности.
  • Я использую Vim в качестве редактора по своему выбору.
  • Я экспортирую свою базу данных цитирования из JabRef, используя специально написанный фильтр экспорта, чтобы он стал Vim Completefunc , который я загружаю .vimrcкаждый раз, когда редактирую файл TeX. Это позволяет мне использовать его двумя способами:
    • Я могу ввести начало ключа цитирования, скажем Won, а затем <ctlr>-X <ctrl>-U, и он покажет мне всплывающий список всех записей с ключом, начинающимся с «Выиграл», который включает, в моем случае, все мои первые авторские статьи не более чем с двумя авторами. . Выделение выбранных записей в списке покажет «экран предварительного просмотра», показывающий библиографическую информацию об этой записи. Я настраиваю свой так, чтобы отображалось только полное название статьи, но достаточно легко включить также информацию об издателе и т. д.
    • Увидев существующий ключ цитирования в документе, подведя курсор к концу ключа и снова нажав комбинацию, <ctrl>-X <ctrl>-Uсписок теперь состоит только из одного элемента, но окно предварительного просмотра все еще появляется, показывая мне библиографическую информацию.
  • Если мне нужно вставить цитату в статью, полный список авторов которой я не могу восстановить в своей голове (и, следовательно, не могу знать даже начало ключа цитирования), я могу либо просмотреть полный список, предоставленный функцией завершения в Vim, или просто ищите в JabRef.

Для иллюстраций:

Перед вызовом средства предварительного просмотра: Обратите внимание на \cite{...}строку в середине окна.

введите описание изображения здесь

Наведение курсора Alinac1999вызывает всплывающее меню (оказывается, Серж Алинхак как минимум три статьи в 1999 году) и панель предварительного просмотра вверху.

введите описание изображения здесь

Я думаю, вы упустили точку зрения ОП. Они говорят, что автор-год — это плохой формат, потому что нельзя сразу устранить неоднозначность между статьями с одинаковыми кодами года автора при чтении статьи. Я предполагаю, что наличие какого-то автоматизированного инструмента для поиска и вставки ключей bibtex для них уже само собой разумеющееся. (Однако для многих исследователей, особенно старшего поколения, это не так).
@FedericoPoloni Я думаю, что ты тот, кто упустил суть. (a) Они спрашивают о ключе BibTeX, а не о его представлении в окончательном PDF-файле. (b) ОП спрашивает о хорошем формате ключа BibTeX при редактировании рукописи; моя точка зрения заключается именно в том, что это неправильный вопрос. Чего следует просить, так это хорошего инструмента, который полностью решает эту проблему. Инструмент редактирования, который позволяет вам после выбора ключа BibTeX, который находится в бегущем тексте, который вы редактируете, немедленно показать вам, что соответствующая библиографическая информация настолько недвусмысленна, насколько это возможно.
@FedericoPoloni: в частности, я описываю больше, чем просто поиск и вставку. Но также и обратный поиск на месте через всплывающее меню. Позвольте мне включить изображение того, как это выглядит.
Думаю, я понял, о чем вы пишите. В Sublime Text 3 есть нечто подобное . Однако ключевое предложение в вопросе: « Хороший формат ключа кажется полезным, поскольку можно потратить много времени только на просмотр ключа, а не на полную ссылку». (Под «чтением статьи» я имел в виду «чтение исходного кода LaTeX».)

Моя система выбора состоит в том, чтобы позволить моему диспетчеру ссылок или какой-либо внешней базе данных обрабатывать генерацию ключа. Каждый раз, когда мне нужно вставить цитату, я обращаюсь к внешнему инструменту или базе данных, ищу ссылку (таким образом избегая большей части риска использования неправильного ключа) и копирую ключ цитаты в свой документ. Это звучит непрактично, но на самом деле я обнаружил, что процесс довольно гладкий и не такой уж неудобный. Несколько ключей, которые я использую чаще всего в той или иной газете, я все равно запоминаю.

Я использую Mendeley в качестве менеджера ссылок, который представляет метаданные рядом с представлением документа в формате PDF. Поэтому, когда я ищу какую-либо информацию в статье, легко скопировать ключ цитирования прямо из Mendeley в мой документ. Я полагаю, что есть много других менеджеров ссылок, у которых есть такая же функция.

В основном я использую Jabref и LyX. Следовательно, необходимости кодировать каждый бит значимой информации в ключе не возникает.

Следовательно, у меня есть простой механизм именования клавиш, который<FirstAuthorLastName>:<Year>:<JournalAbbreviation>

Если это книга, то я заменяю последнюю часть на Book. Я настроил Jabref, чтобы он автоматически создавал первые две части при импорте. Поскольку аббревиатуры журналов не являются стандартными (пока), это не автоматизировано.

Поскольку LyX используется для написания документа и вставки записей, я могу выполнить поиск, чтобы узнать, какие статьи нужно цитировать, и ключ не имеет большого значения ...

Добро пожаловать на сайт! Возможно, стоит включить в ваш ответ что-то, указывающее на то, что JabRef имеет интеграцию LyX, поэтому вы можете выполнить поиск в конце JabRef. (Я полагаю, это то, что вы имеете в виду? Или у LyX также есть поиск? Я сам отправил поисковый Jabref, нажмите, чтобы вставить в метод LyX. Прошло некоторое время с тех пор, как я использовал менеджер LyX)
Спасибо @Oxinabox. Хотя у Jabref есть интеграция с LyX, я ею не пользуюсь. Я использую Джабрефа в первую очередь как прославленного менеджера цитирования. Раньше использовал Zotero - это здорово, но сгорело sqlite db вместо обычного текста. Что я делаю, так это использую функцию «Вставить цитату» LyX, которая вызывает меню, в котором вы также можете выполнять поиск, вставлять, а также выбирать, как будет выглядеть цитата.
Достаточно справедливо, я предлагаю (для вашей же пользы) изучить интеграцию, это здорово. Инструкции по его настройке находятся по адресу: tex.stackexchange.com/questions/148287/lyx-and-jabref-problem/…