Совместное использование кодов и наборов данных, связанных с исследованиями: разделить их или совместно использовать на одной платформе?

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

GitHub позволяет вам делиться своим кодом таким образом, чтобы поощрять совместную работу с помощью звездочек, задач, ответвлений, запросов на вытягивание и уведомлений. Так что обязательно поместите туда копию своего кода. Однако GitHub не предназначен для обеспечения постоянства размещенных репозиториев. Например, всегда можно полностью удалить репозиторий через интерфейс GitHub, а также удалить или изменить старый код принудительным нажатием Git. В долгосрочной перспективе мы не можем знать, что компания, контролирующая GitHub (раньше это был GitHub, а теперь Microsoft), продолжит управлять им так, как это служит науке. Подумайте, сколько корпоративных продуктов и услуг исчезло или изменило направление за последние двадцать лет, даже те, которые были созданы крупными компаниями, такими как Google (см. этот список) .) или Sun Microsystems после того, как она была приобретена Oracle (лицензирование Java и Solaris).

Следовательно, для лучшей гарантии постоянства вашей работы и доступности для будущих ученых вы также должны поместить свои данные и код в репозиторий научных данных, такой как Zenodo. Это свяжет DOI с вашими депонированными артефактами, которые будут постоянно связаны с соответствующей версией. (После того как вы загрузите что-то в Zenodo, почти невозможно отменить действие.) GitHub и Zenodo даже предлагают вам возможность заархивировать определенную версию GitHub в Zenodo .

Если объем данных велик или есть вероятность, что они будут часто использоваться сами по себе, то отделите их от кода и загрузите каждый в Zenodo как отдельный набор данных. Zenodo позволяет связать их (а также репозиторий GitHub) с метаданными «Связанные идентификаторы». Вы можете использовать идентификаторы Compilesи Compiled byдля связывания кода с данными и Supplement toидентификатор для связывания вашего репозитория GitHub.

В качестве примера разделения, связанного с большим набором данных, рассмотрим этот набор данных, касающийся времени жизни строк кода (3,7 ГБ), связанного программного обеспечения и репозитория программного обеспечения на GitHub . В качестве примера разделения, связанного с независимо используемым набором данных, рассмотрим этот список репозиториев, созданных предприятиями , и соответствующий пакет репликации .

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

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

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

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

Чувство постоянства также может быть фактором. Для репозитория я бы, вероятно, только отправил данные, ожидая, что ничего не будет обновлено. Если анализ все еще продолжается и коды будут активно обновляться и выпускаться, я бы рассмотрел что-то более динамичное, например GitHub.

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

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

Для данных, которые не являются «большими», я бы ранжировал ваши варианты следующим образом:

• Хорошо: поместите свои данные в любой репозиторий данных, даже если это общедоступный Google Диск.
• Лучше: синхронизируйте свои данные с кодом на GitHub.
• Лучшее: ваш код обрабатывает поиск данных, а также споры и анализ.

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

Если ваши данные «большие», вы, вероятно, захотите взглянуть на что-то вроде S3.