Як зв’язати код з публікаціями

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

Ну, я думаю, у вас є кілька варіантів.

1. Якщо у вас є стабільна сторінка - наприклад, така, яку спонсорує університет чи інша неприбуткова установа, яка навряд чи зникне незабаром - ви можете опублікувати там.
2. Ви можете використовувати таку службу, як Github або Bitbucket або SourceForge для розповсюдження коду.
3. Якщо код має граничне загальне значення (це код аналізу для певного набору умов тощо), ви можете зробити код доступним як завантаження "додаткової інформації" разом із тим папером, в якому ви його використовуєте.
4. Ви можете використати комбінацію перерахованого вище.

Однак у будь-якому або всіх цих випадках слід чітко вказати джерело в статті та вказати, який саме тип ліцензування (GPL, Creative Commons тощо), щоб не виникало проблем, пов’язаних із ІР.

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

Доповнення до журналів на веб-сайтах університетів не є стійкими

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

На жаль, виявляється, що журнали не допомагають краще підтримувати свої додаткові матеріали (див. Anderson et al. 2006 ) і, можливо, не приймають необхідних форматів або взагалі приймають додаткові матеріали (див. Один помітний приклад ).

З цієї причини люди, які займаються тривалим архівуванням даних , одноголосно звертаються до того, щоб захищати використання виділених сховищ, а не веб-сайтів чи додаткових матеріалів, і багато журналів зараз зобов’язують цю практику . Справедливо справедливо, що код повинен дотримуватися цього стандарту.

Рішення багатьох примірників?

Github та пов'язані з ними сайти ще не довели довголіття протягом масштабів 100-х років, досягнутих університетськими бібліотеками та створеними видавцями. Шляхом сприяння широкому розповсюдженню, це може забезпечити рішення інших відгуків у коментарях, включаючи одного, хто не міг коментувати зміну stackexchange,

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

- Томас Джефферсон, 18 лютого 1791 року

Figshare та стандарт CLOCKSS

Єдиний архівний стандарт, про який я знаю, - це figshare , який може прийняти повні сховища коду (як "набори файлів" на даний момент, але, я вважаю, незабаром з'явиться можливість вказати як тип "код"). Ключовим елементом є не лише посилання на DOI з програмними метаданими, але резервна копія архівної служби CLOCKSS , яка зберігає копії всього її вмісту у 12 географічно та геополітично розподілених вузлах по всьому світу. Якщо фігура припинить свою діяльність або припинить своє існування, це призведе до того, що весь її вміст буде вільно доступний у CLOCKSS.

Отже, я б запропонував використовувати Github для розповсюдження коду, а також надати архівну копію для розміщення коду на момент публікації.

Ви можете використовувати деякі фантазійні методи pdf, щоб просто прикріпити код до pdf (тобто файли коду вбудовані у pdf та їх можна "завантажити", натиснувши на якусь кнопку в pdf). Це можна досягти, наприклад, з пакетом attachfile . Звичайно, це робота з препринтами (хоча я не знаю, чи це вже працює з arxiv), але у вас, ймовірно, виникають проблеми з журнальними файлами ...

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

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

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

Я взяв дві тактики, народжені через те, що я передбачу незабаром зміни закладів, тому моя університетська URL-адреса не є стабільною і в найменшій мірі.

Коли код порівняно короткий, я намагався включити його як додатковий додаток до самого журналу, припускаючи, що вони, ймовірно, зроблять гідну роботу, зберігаючи папір та код приблизно в одному місці. Це особливо корисно для коду, де не існує великої кількості загального інтересу - код, який дещо марний, без необхідної статті, щоб вказати контекст.

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

Погляньте на http://www.runmycode.org . Вони розміщують супутні сайти для коду, пов'язаного з науково-дослідними роботами. Якщо код R, Matlab або декілька інших, він фактично запустить код для вас. Я ще цього не пробував, але маю намір. Я думаю, що Девід Доного та його співробітники використовують це.

Університетські бібліотеки можуть бути місцем для цього або приймаючим центром університету.

Як читач, твердження в роботі про те, що код можна отримати, зв’язавшись безпосередньо з автором, було б ефективним. Як автор, це може допомогти сприяти співпраці та дати мені можливість нагадати людям цитувати мою статтю, якщо вони використовують код у своїй роботі.