Я пишу статью, описывающую некоторые исследования, которые я сделал. В рамках своей работы я разработал библиотеку с открытым исходным кодом и сделал ее доступной на Github.
Как мне связать его?
Нужно ли указывать его в библиографии или делать сноску со ссылкой на программу?
На такие ресурсы, особенно если они являются дополнением к статье, т. е. в каком-то смысле ее частью, следует ссылаться в сноске, а не в библиографии.
Включите не только URL-адрес, но и краткое описание; и постарайтесь сохранить этот URL-адрес действительным - как только вы опубликуете эту ссылку, она будет заморожена навсегда.
Это также помогает включить противоположную цитату. В файле readme этой библиотеки включите полную информацию о цитировании вашей статьи. Это позволит другим получить дополнительную информацию о методах, а также даст вам ссылки, если/когда другие будут опираться на вашу работу.
Некоторые издатели также поддерживают двоичные вложения для дополнительной информации. Если да, то вам следует использовать его — подготовьте пакет текущей стабильной версии и залейте его туда. Это обеспечивает воспроизводимость, поскольку упоминается конкретная версия, относящаяся к фактическому документу, а не некоторые улучшения, сделанные в 2020 году, которые все меняют; и он также прикрепляет всю соответствующую информацию вместе с документом на сайте издателя, который останется в силе, даже если этот репозиторий github по какой-либо причине исчезнет.
В предыдущих статьях я использовал что-то вроде (исходный код доступен на github.com/fomite/brilliantwork) при описании используемых программных методов.
Однако Figshare теперь позволяет вам напрямую импортировать репозиторий из GitHub, что даст вам DOI, на который вы можете ссылаться в качестве цитаты. Это также дает преимущество наличия «моментального снимка» репозитория на момент публикации для репозиториев, над которыми будет продолжаться работа. Это, а также возможность для меня и других людей цитировать репозиторий напрямую (и, таким образом, иметь возможность получить некоторые традиционные показатели цитирования, чтобы показать влияние программного обеспечения), — это то, чем я буду заниматься в будущем.
gitпредоставляет хэши, соответствующие конкретным коммитам/версиям: это то, что я бы включил в цитату (не используя Figshare).Цитата – это ссылка на объект исследования. До DOI эта ссылка содержала информацию, которая требовалась кому-то для физического определения местонахождения объекта исследования, будь то книга, журнальная статья или диссертация. Хотя до сих пор не принято решение о том, как предоставлять общие ссылки на объекты цифровых исследований, репозиторий Git содержит каноническую ссылку — хэш SHA1 коммита.
Если вы хотите ссылаться на свой репозиторий Git таким образом, чтобы его было легко найти в будущем, вы должны предоставить не только URL-адрес, где он находится сейчас, но также короткое имя репозитория, ведущий автор[ы ] и хэш SHA1 коммита, с помощью которого вы получили свои результаты.
Вот пример URL-адреса из GitHub, который содержит коммит: https://github.com/hashdist/hashstack/commit/4c72950a0f6eb9cc1cf63cd640f3e6b82c9ce9c0 .
Я не рекомендую загружать ваш код на Figshare, пока они не исправят свою способность принимать лицензии на код.
Обновление от 14 мая 2014 г.
GitHub и ZENODO объединились для загрузки кода для DOI под гибкой лицензией. Чтобы получить DOI для вашего кода, достаточно следовать инструкциям GitHub Guide to Making Your Code Citable . Вот обзор инструкций:
Это действительно так просто. В настоящее время нет причин не использовать этот подход по умолчанию для цитирования вашего программного обеспечения.
Специфика зависит от вашей области, и я думаю, что в большинстве областей есть очень расплывчатые рекомендации относительно того, что делать в таких ситуациях. Единственное жесткое правило заключается в том, что вы должны пройти через своих рецензентов и редакторов, которые скажут вам, если стиль неуместен. Помимо этого, самое главное, что вы сами довольны тем, что цитирование делает ваш репозиторий GitHub максимально заметным. Наконец, вы должны рассматривать свою статью с точки зрения читателей, которые могут захотеть использовать и цитировать ваш код, и которые, естественно, будут искать в вашем тексте, как это сделать.
В общем, я бы рекомендовал цитировать код в библиографии, как еще одну ссылку. Преимущество этого заключается в том, что ссылки на вашу статью будут перечислены и проиндексированы отдельно, и (если повезет) это будет зарегистрировано как ссылки, указывающие на ваш репозиторий, что станет большим преимуществом, если на него будет ссылаться больше людей. Такая цитата должна быть
Пример цитаты
GA Worth, MH Beck, A. Jackle и H.-D. Мейер. Пакет MCTDH, версия 8.2 (2000 г.), Гейдельбергский университет, Гейдельберг, Германия. Х.-Д. Мейер, Версия 8.3 (2002 г.), Версия 8.4 (2007 г.). См. http://mctdh.uni-hd.de
Вы также должны описать код в тексте, когда вы впервые цитируете код, и предоставить достаточно полное описание в документе, чтобы читателям не нужно было читать какую-либо дополнительную информацию, чтобы продолжить чтение вашей статьи, потому что она должна читаться как единое целое. , целостная работа.
Как вариант, вы можете процитировать его в сноске, указав название кода и его местонахождение. Это было бы хорошим местом для включения описания, если оно краткое. Другой вариант — сделать это в благодарностях, как указывает Джордано . Однако я думаю, что это делает ваш код менее доступным как для людей, так и для поисковых систем.
Как я упоминал ранее, вы должны формировать свое цитирование кода так, как вы хотели бы, чтобы его цитировали другие. Также желательно, чтобы вы включили на страницах, описывающих код в Интернете, описание того, как вы хотите, чтобы люди цитировали код. Некоторыми примерами являются GAMESS UK , MCTDH и MOLCAS или упомянутые в этом вопросе . Наличие такого описания укрепит вашу позицию, если рецензентам или редакторам не понравится ваш предпочтительный стиль. Вы устанавливаете условия, на которых ваш код будет цитироваться!
Наконец, как уже упоминалось, вы должны убедиться, что URL-адрес, на который вы указываете, стабилен, поскольку вы не сможете изменить ссылку в опубликованной статье после ее выхода. Это вообще отдельный вопрос, и сделать это можно несколькими способами — включая дополнительную информацию к самой статье, отдельные репозитории для академического кода и, конечно же, сам GitHub — и вы должны стремиться к максимально стабильному решению. Вероятно ли, что репозиторий когда-нибудь закроют или перенесут? Если это так, вы должны рассмотреть альтернативы.
В дополнение к ссылке на репозиторий в документе вы также должны убедиться, что ссылка между документом и репозиторием является частью метаданных документа. В частности, если вы размещаете статью на arXiv , вы можете использовать новейшую функцию , которая интегрируется с Papers with Code, чтобы зафиксировать связь между вашей статьей и ее реализацией.
Джордано
ЭП