Подтвердить что ты не робот

Автоматическая документация наборов данных

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

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

Это похоже на то, что ProjectTemplate уже было бы, но я не могу найти там эту функциональность.

Существует ли такой инструмент?

Если это не так, какие соображения следует принимать во внимание, чтобы обеспечить максимальную гибкость? Некоторые предварительные мысли:

  • Следует использовать язык разметки (YAML?)
  • Все подкаталоги должны сканироваться
  • Чтобы облегчить (2), следует использовать стандартное расширение для дескриптора набора данных
  • Критически, чтобы сделать это наиболее полезным, должен быть какой-то способ сопоставления дескрипторов переменных с именем, которое они в конечном итоге принимают. Поэтому любое переименование переменных должно выполняться в исходных файлах, а не на этапе очистки (меньше, чем идеальном), некоторый анализ кода должен выполняться механизмом документации для отслеживания изменений имен переменных (ugh!) Или некоторых следует использовать более простой гибрид, например, позволяющий указывать переменные переименования в файле разметки.
  • В идеале также будет шаблонный шаблон (например, "Мы вытащили переменную [var] из набора данных [dset] в [date]." ) и, возможно, связаны с Sweave.
  • Инструмент должен быть достаточно гибким, чтобы не быть чрезмерно обременительным. Это означает, что минимальная документация просто будет именем набора данных.
4b9b3361

Ответ 1

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

Прежде чем обращаться к вашим вопросам, я хочу подчеркнуть, что это, по-видимому, связано с общей целью управления доказательством данных. Я мог бы также дать вам ссылку Google, чтобы узнать больше.:) Есть куча ресурсов, которые вы найдете, например опросы, программные средства (например, некоторые из них перечислены в записи в Википедии), различные исследовательские проекты (например, Provenance Challenge) и многое другое.

Это концептуальное начало, теперь для решения практических вопросов:

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

Добро пожаловать в каждый кошмар.:)

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

Нет проблем. list.files(...,recursive = TRUE) может стать хорошим другом; см. также listDirectory() в R.utils.

Стоит отметить, что заполнение раздела методов по источникам данных является узким приложением в области происхождения данных. На самом деле, довольно печально, что CRAN Task View on Reproducible Research фокусируется только на документации. По моему опыту, цели происхождения данных - подмножество воспроизводимых исследований, а документация по манипулированию данными и результатам - это подмножество происхождения данных. Таким образом, эта задача все еще находится в зачаточном состоянии относительно воспроизводимых исследований. Это может быть полезно для ваших целей, но вы в конечном итоге перерастите это.:)

Существует ли такой инструмент?

Да. Что такое такие инструменты? Mon dieu... он очень прикладной в целом. Внутри R я считаю, что этим инструментам не уделяется много внимания (см. Ниже). Это довольно неудачно - либо я что-то упустил, либо сообщество R потеряло то, что мы должны использовать.

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

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

1. Следует использовать язык разметки (YAML?)

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

2. Все подкаталоги должны быть отсканированы

Готово: listDirectory()

3. Чтобы облегчить (2), следует использовать стандартное расширение для дескриптора набора данных

Тривиальный: ".json".;-) Также работает ".SecretSauce".

4. Критически, чтобы сделать это наиболее полезным, должен быть какой-то способ сопоставления дескрипторов переменных с именем, которое они в конечном итоге принимают. Поэтому любое переименование переменных должно выполняться в исходных файлах, а не на этапе очистки (меньше, чем идеальном), некоторый анализ кода должен выполняться механизмом документации для отслеживания изменений имен переменных (ugh!) Или некоторых следует использовать более простой гибрид, такой как разрешение переменных переименований в файл разметки.

Как уже было сказано, это не совсем понятно. Предположим, что я беру 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 для больших наборов данных, я должен указывать столбцы каждой матрицы. Они хранятся в файле дескриптора для каждого двоичного файла. Этот процесс поощряет создание дескрипторов, сопоставляющих имена переменных (и матрицы) с дескрипторами. Если вы храните свои данные в базе данных или других внешних файлах, поддерживающих произвольный доступ и несколько R/W-доступа (например, файлы с отображением памяти, файлы HDF5, все, кроме файлов .rdat), вы, скорее всего, обнаружите, что добавление дескрипторов становится второй натурой.