Как связать код с публикациями

40

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

Дэвид Кетчесон
источник
2
Совместное использование кода - отличная идея, и ее следует делать больше. Я знаю, что мог бы лучше предоставить соответствующий код для бумаги. Репозиторий Github кажется хорошим решением. Конечно, гораздо лучше, чем включать исходный код в приложение, что я видел для меньших усилий по написанию кода.
Бэррон
4
Это связанный вопрос МО.
JM
@JM Спасибо, ответы на МО очень хорошие!
Дэвид Кетчесон
обратите внимание, что вы можете публиковать записные книжки ipython на github, и они отображаются, за исключением интерактивных частей
denfromufa
1
@denfromufa К сожалению, Github отключает Mathjax, поэтому математика также не отображается. Это делает его довольно бесполезным для большинства соответствующих областей. Но всегда есть nbviewer.
Дэвид Кетчон

Ответы:

17

Ну, я думаю, у вас есть несколько вариантов.

  1. Если у вас есть стабильная страница - например, спонсируемая университетом или другим некоммерческим учреждением, которое вряд ли исчезнет в ближайшее время - вы можете опубликовать там.
  2. Вы можете использовать сервис, такой как Github, Bitbucket или SourceForge, для распространения кода.
  3. Если код имеет предельную общую ценность (это код анализа для определенного набора условий и т. Д.), Вы можете сделать его доступным для загрузки в качестве «дополнительной информации» вместе со статьей, в которой вы его используете.
  4. Вы можете использовать некоторую комбинацию из вышеперечисленного.

Однако в любом или во всех этих случаях вы должны четко указать источник в статье и указать, какое это лицензирование (GPL, Creative Commons и т. Д.), Чтобы не было проблем, связанных с IP.

aeismail
источник
6
Я думаю, что человек должен поместить свой код в наиболее вероятное место, чтобы выжить, и в нескольких местах, если это возможно. Например, университетские страницы выживают реже, чем хостинговые услуги. Имеет смысл сделать журнал доступным для моментального снимка. К сожалению, ни один из известных мне журналов не занимается хостингом репо.
Фахим Митха
1
Студент, вероятно, не должен размещать программное обеспечение на личной домашней странице; тем не менее, я бы сказал, что для типичного исследовательского кода его распространение на странице, связанной с исследовательской группой, вероятно, принесет больше пользы, чем на внешней странице, где атрибуция может быть потеряна. Что касается журналов, это правда, что они не делают хостинг хранилища. Однако способность иметь «дополнительную информацию» в виде исследовательского кода, я думаю, удовлетворяет большинству требований ответственной научной разработки программного обеспечения. (При необходимости.)
Aeismail
Мне кажется, что университетские страницы могут потеряться больше, чем обычные хостинговые сайты. Конечно, большинство популярных на сегодняшний день хостинговых сайтов (Bitbucket, Github, Google Code) существует не так давно. С другой стороны, Sourceforge, например, существует уже некоторое время.
Фахим Митха
Есть и другие проблемы, о которых нужно знать; Проблемы, связанные с ИС, а также нормативные акты университетов или правительств могут также контролировать выбор хранилищ. Но контраргумент состоит в том, что есть ряд кодов ( NAMD является одним из главных примеров), которые были успешно распространены на сайтах, принадлежащих университетам. В общем, «значимость» кода будет определять, насколько он виден. Я сомневаюсь, что код, который развивает значительную базу пользователей, когда-либо полностью исчезнет.
Aeismail
1
Правда, но если код неясен, это не значит, что все в порядке, если он исчезнет. И можно надеяться, что большая часть научного кода будет находиться под свободной лицензией и без необоснованных ограничений. Я полагаю, что NIH, например, теперь обязывает это для работы, разработанной на деньги NIH (налогоплательщиков). Я думаю, что это должно иметь место для всех проектов, финансируемых налогоплательщиками.
Фахим Митха
8

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

Приложения к университетским веб-сайтам не являются постоянными

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

К сожалению, похоже, что журналы не намного лучше поддерживают свои дополнительные материалы (см. Anderson et al. 2006 ), и могут не принимать необходимые форматы или вообще не принимать дополнительные материалы (см. Один известный пример). ).

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

Решение многих копий?

Github и связанные сайты еще не доказали долговечность в течение столетия, достигнутого университетскими библиотеками и признанными издателями. Способствуя широкому распространению, это может обеспечить решение, которое другие поддержали в комментариях, включая одного человека, который не смог прокомментировать stackexchange,

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

- Томас Джефферсон, 18 февраля 1791 г.

Figshare & стандарт CLOCKSS

Единственный известный мне архивный стандарт - это figshare , который может принимать полные репозитории кода (на данный момент «наборы файлов», но я полагаю, что в скором времени появится возможность указывать их как «code»). Ключевым элементом figshare является не только цитируемый DOI с программными метаданными, но и поддержка архивного сервиса CLOCKSS , который хранит копии всего своего контента на 12 географически и геополитически распределенных узлах по всему миру. Если figshare обанкротится или прекратит свое существование, это приведет к тому, что весь его контент будет свободно доступен из CLOCKSS.

Следовательно, я бы предложил использовать Github для распространения кода, а также предоставить архивную копию для figshare во время публикации.

cboettig
источник
1
figshare - это большой шаг вперед, хотя лицензия CC-BY не является лицензией на программное обеспечение, и я не знаю, сколько ученых готовы выпустить свой код в рамках CC0, поэтому эту проблему нужно решить. Я ценю, что они используют DOI и CLOCKSS, но это здорово.
Арон Ахмадиа
Да, замечательно, что лицензии все еще остаются проблематичными, особенно для более полно разработанного программного обеспечения. Для сценариев, чтобы повторить анализ, я мог бы видеть, что CC0 является более подходящим.
cboettig
Код Google мог бы быть немного лучше для более широкой аудитории, поскольку у вас может быть более приятная веб-страница с краткой информацией, изображениями, ссылкой DOI, более высокой видимостью в поиске и т. Д. Вы должны обязательно указать tgz в разделе «Загрузка» и указать ссылку на первой странице. Помните, что большинство не разработчиков даже не знакомы с управлением версиями, не говоря уже о git / hg. Subversion - это то, что я хотел бы сделать для более широкой аудитории.
Стали
1
@stali напомним, что github также поддерживает пользовательские веб-страницы для репозиториев через gh-страницы и загружаемые тарболы из загрузок. Но ни Google, ни Github не предоставляют отдельного DOI для кода, а также не решают проблему долговечности архивов за пределами жизни компании afaik.
cboettig
4

Вы можете использовать некоторые причудливые pdf-методики, чтобы просто прикрепить код к pdf (то есть кодовые файлы встроены в pdf и могут быть «загружены» нажатием какой-либо кнопки в pdf). Это может быть выполнено, например, с помощью пакета attachfile . Конечно, это работает с препринтами (хотя я не знаю, работает ли он уже с arxiv), но у вас, вероятно, проблемы с журнальными файлами ...

кортик
источник
Очень круто! Я не знал, что LaTeX мог сделать это.
Qubyte
4

Для небольших сценариев, относящихся к конкретному исследовательскому проекту, лучшим местом для публикации является веб-сайт журнала в качестве «дополнительной информации» к статье. Вот где легче всего найти того, кто читает статью.

Более содержательные пакеты, представляющие интерес и для других проектов, лучше опубликовать отдельно. К сожалению, в настоящее время нет действительно хорошего решения. В идеале, публикация кода должна быть постоянно доступна через DOI, как бумага, но я не знаю ни одного хостинг-сайта, который раздает DOI и гарантирует их постоянство. Публичные репозитории, такие как Github или Bitbucket, возможно, являются лучшим выбором на данный момент.

Лучшим решением было бы опубликовать документ, упакованный с кодом, и данные, которые сопровождают его, но это пока технически невозможно. Я работаю над исследовательским прототипом, исследующим эту идею, подробности смотрите на этом сайте .

khinsen
источник
1
+1 для ActivePapers. Я не думаю, что это отвечает моим потребностям сейчас, но я рад видеть кого-то, кто работает над решением!
Дэвид Кетчесон
figshare предоставляет DOI: см. figshare.com/blog/…
Джероми Энглим
3

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

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

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

фомиты
источник
2

Взгляните на http://www.runmycode.org . Они размещают сопутствующие сайты для кода, связанного с исследовательскими работами. Если код R, Matlab или несколько других, он фактически запустит код для вас. Я еще не пробовал, но собираюсь. Я думаю, что Дэвид Донохо и его сотрудники используют это.

Пол Г. Константин
источник
Ах. Вы уже использовали это. runmycode.org/CompanionSite/site.do?siteId=158
Пол Г. Константин
@David Ketcheson и я также провели эксперимент в декабре, используя стек wakari.io и записные книжки IPython для одного из наших кодов на основе Python. Вы можете ознакомиться с записными книжками по воспроизводимости PyClaw здесь .
Арон Ахмадиа
0

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

vanCompute
источник
-2

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

JXB
источник
4
Это интересная точка зрения, и мне любопытно посмотреть, насколько это распространено. Лично это то, от чего я пытаюсь уйти. Я чувствую, что это похоже на публикацию неполной статьи и требование, чтобы читатели просили полную информацию. См. Sciencecodemanifesto.org .
Дэвид Кетчесон
2
Имея контактный адрес в одной из моих самых заметных статей, которая, по сути, мертва - и не уверена в некоторых других - я, как правило, против этого как решения. «Связаться со мной» не обязательно самая легкая вещь в мире, особенно десятилетие спустя.
Fomite
2
Подход «свяжитесь со мной» также не гарантирует воспроизводимость. Когда вы связываетесь со мной, спрашивая какой-то код, я, вероятно, вышлю вам самую последнюю версию, а не ту, которую я использовал в оригинальной статье. Хотя бы потому, что у меня больше не будет оригинальной версии.
Хинсен
3
Эмпирические исследования, на самом деле связывающиеся с автором и запрашивающие данные, даже когда автор подписал лицензионное соглашение на предоставление их по запросу, показали, что на удивление немногие авторы соблюдают. Например, см. Dx.doi.org/10.1371/journal.pone.0007078 и цитаты в нем. Если это не работает для данных, я подозреваю, что это не очень хорошее решение для кода.
cboettig