Это очень хороший вопрос: люди должны быть очень обеспокоены всеми последовательностями сбора, агрегации, преобразования и т. Д., Которые составляют основу для статистических результатов. К сожалению, это широко не практикуется.
Прежде чем ответить на ваши вопросы, я хочу подчеркнуть, что это, по-видимому, связано с общей целью управления происхождением данных . Я мог бы также дать вам ссылку Google , чтобы узнать больше. :) Существует множество ресурсов, которые вы найдете, такие как опросы, программные инструменты (например, некоторые из них перечислены в записи в Википедии), различные исследовательские проекты (например, Provenance Challenge ) и другие.
Это концептуальное начало, теперь для решения практических вопросов:
Я сейчас работаю над проектом, в котором я медленно накапливаю кучу разных переменных из кучки разных источников. Будучи несколько умным человеком, я создал отдельный подкаталог для каждого в главном каталоге «original_data» и включил файл .txt с URL-адресом и другими дескрипторами, из которых я получил данные. Будучи недостаточно умным человеком, эти .txt файлы не имеют структуры.
Добро пожаловать в кошмар каждого. :)
Теперь передо мной стоит задача составить раздел методов, который документирует все различные источники данных. Я готов пройтись и добавить структуру к данным, но тогда мне нужно будет найти или создать инструмент отчетности для сканирования каталогов и извлечения информации.
Нет проблем. list.files(...,recursive = TRUE) может стать хорошим другом; см. также listDirectory() в R.utils.
Стоит отметить, что заполнение раздела методов по источникам данных является узким приложением в области происхождения данных. На самом деле весьма прискорбно, что CRAN Task View по воспроизводимым исследованиям сосредоточен только на документации. По моему опыту, цели происхождения данных представляют собой подмножество воспроизводимых исследований, а документация по манипулированию данными, а результаты - это часть происхождения данных. Таким образом, этот вид задачи все еще находится в зачаточном состоянии в отношении воспроизводимых исследований. Это может быть полезно для ваших целей, но в конечном итоге вы перерастете это. :) 1030 * *
Существует ли такой инструмент?
Да. Что это за инструменты? Mon dieu ... это очень ориентированный на приложения в целом. В R, я думаю, что этим инструментам не уделяется много внимания (см. Ниже). Это довольно прискорбно - либо я что-то упускаю, либо сообщество R пропускает то, что мы должны использовать.
Для базового процесса, который вы описали, я обычно использую JSON (см. этот ответ и этот ответ для комментариев о том, что я собираюсь сделать). Для большей части моей работы я представляю это как «модель потока данных» (кстати, этот термин может быть неоднозначным, особенно в контексте вычислений, но я имею в виду это с точки зрения статистического анализа). Во многих случаях этот поток описывается с помощью JSON, поэтому нетрудно извлечь последовательность из JSON, чтобы выяснить, как возникли конкретные результаты.
Для более сложных или регулируемых проектов JSON недостаточно, и я использую базы данных, чтобы определить, как данные собирались, преобразовывались и т. Д. Для регулируемых проектов в базе данных может быть много аутентификации, регистрации и многого другого, чтобы убедитесь, что данные о происхождении хорошо документированы. Я подозреваю, что такого рода БД не в ваших интересах, так что давайте двигаться дальше ...
1. Следует использовать язык разметки (YAML?)
Честно говоря, все, что вам нужно для описания вашего потока данных, будет адекватным. Большую часть времени я считаю достаточным иметь хороший JSON, хорошие макеты каталогов данных и хорошую последовательность сценариев.
2. Все подкаталоги должны быть отсканированы
Готово: listDirectory()
3. Для облегчения (2) следует использовать стандартное расширение для дескриптора набора данных
Тривиально: ".json".;-) Или ".SecretSauce" тоже работает.
4. Критически важно, чтобы сделать это наиболее полезным, должен быть какой-то способ сопоставления дескрипторов переменных с именем, которое они в конечном итоге принимают.Следовательно, либо все переименование переменных должно выполняться в исходных файлах, чем на этапе очистки (что не идеально), анализ документации должен выполняться механизмом документации для отслеживания изменений имен переменных (тьфу!), Или некоторыеСледует использовать более простой гибрид, такой как разрешение переименования переменных в файле разметки.
Как уже говорилось, это не совсем имеет смысла.Предположим, что я беру var1 и var2 и создаю var3 и var4.Возможно, var4 - это просто отображение var2 в его квантилях, а var3 - наблюдательный максимум var1 и var2;или я мог бы создать var4 из var2 путем усечения экстремальных значений.Если я сделаю это, сохраню ли я имя var2?С другой стороны, если вы имеете в виду просто сопоставление «длинных имен» с «простыми именами» (т. Е. Текстовые дескрипторы с переменными R), то это то, что вы можете сделать только вы.Если у вас очень структурированные данные, нетрудно создать список текстовых имен, соответствующих именам переменных;В качестве альтернативы вы можете создать токены, на которых можно выполнить подстановку строк.Я не думаю, что сложно создать CSV (или, что еще лучше, JSON ;-)), который сопоставляет имя переменной с дескриптором.Просто продолжайте проверять, что все переменные имеют совпадающие строки дескриптора, и остановитесь, как только это будет сделано.
5. В идеале отчет также должен быть шаблонным (например, «Мы извлекли переменную [var] из [dset»).] набор данных в [date]. ") и, возможно, связан с Sweave.
Вот где могут применяться рекомендации других roxygen и roxygen2.
6. Инструмент должен быть достаточно гибким, чтобы не быть чрезмерно обременительным.Это означает, что минимальная документация будет просто именем набора данных.
Хмм, я в тупике.:)
(*) Кстати, если вам нужен один проект FOSS, связанный с этим, посмотрите Taverna .Он был интегрирован с R , как описано в нескольких местах.Это может быть излишним для ваших нужд в настоящее время, но это стоит исследовать в качестве примера достаточно зрелой системы рабочего процесса.
Примечание 1. Поскольку я часто использую bigmemory для больших наборов данных, ядолжны назвать столбцы каждой матрицы.Они хранятся в файле дескриптора для каждого двоичного файла.Этот процесс поощряет создание дескрипторов, сопоставляющих имена переменных (и матрицы) с дескрипторами.Если вы храните свои данные в базе данных или других внешних файлах, поддерживающих произвольный доступ и множественный доступ для чтения / записи (например, файлы с отображением в памяти, файлы HDF5, что угодно, кроме файлов .rdat), вы, вероятно, обнаружите, что добавление дескрипторов становится второй натурой.