2011-11-02 15 views
21

Pracuję nad projektem w tej chwili, w którym powoli gromadziłem kilka różnych zmiennych z wielu różnych źródeł. Będąc nieco sprytnym człowiekiem, stworzyłem inny podkatalog dla każdego pod głównym katalogiem "original_data" i zawarłem plik .txt z adresem URL i innymi deskryptorami skąd mam dane. Będąc niewystarczająco sprytną osobą, te pliki .txt nie mają żadnej struktury.Automatyczna dokumentacja zbiorów danych

Teraz mam do czynienia z zadaniem opracowania sekcji metod, która dokumentuje wszystkie różne źródła danych. Jestem gotów przejść i dodać strukturę danych, ale wtedy potrzebowałbym znaleźć lub zbudować narzędzie do raportowania, aby przejrzeć katalogi i wydobyć informacje.

To wydaje się być czymś, co już miałoby ProjectTemplate, ale nie mogę znaleźć tam tej funkcji.

Czy takie narzędzie istnieje?

Jeśli nie, jakie względy należy wziąć pod uwagę, aby zapewnić maksymalną elastyczność? Niektóre wstępne myśli: (? YAML)

  1. Język znaczników należy stosować
  2. wszystkie podkatalogi powinny być skanowane
  3. Dla ułatwienia (2), standardowe rozszerzenie dla deskryptora zestawu danych należy stosować
  4. Krytycznie, aby było to najbardziej użyteczne, musi istnieć jakiś sposób dopasowania deskryptorów zmiennych do nazwy, którą ostatecznie przyjmują. Dlatego też wszystkie zmiany nazw zmiennych muszą być wykonywane w plikach źródłowych, a nie w etapie czyszczenia (mniej niż idealne), niektóre operacje na kodach muszą być wykonywane przez mechanizm dokumentacji, aby śledzić zmiany nazw zmiennych (ugh!), Lub niektóre należy zastosować prostszą hybrydę, taką jak zezwolenie na podanie nazw zmiennych w pliku znaczników.
  5. Idealnie raport byłby również szablonem (np. "Pobraliśmy zmienną [var] z zestawu danych [dset] w dniu [data].") I prawdopodobnie powiązaliśmy z Sweave.
  6. Narzędzie powinno być wystarczająco elastyczne, aby nie było nadmiernie uciążliwe. Oznacza to, że minimalna dokumentacja byłaby po prostu nazwą zestawu danych.
+1

kilka myśli. jeden, powinieneś spojrzeć na 'roxygen2' dla dokumentacji zbiorów danych. dwa, całkiem łatwo jest uogólnić 'ProjectTemplate', by zrobić to, czego szukasz, i pracuję nad sprawdzeniem koncepcji, którą wkrótce opublikuję na githubie. – Ramnath

+0

@Ramnath Dzięki. Brzmi świetnie. Zapomniałem, że 'roxygen2' działa dla zbiorów danych, więc postaram się to rzucić. Czy masz gdzieś zapisany format dokumentacji, nawet jeśli parser nie jest zrobiony, abym mógł uniknąć przepisywania, gdy pojawi się dowód twojej koncepcji? –

+0

Nie pracuję nad nowym formatem dokumentacji. 'roxygen2' jest wystarczający dla większości wymagań dotyczących dokumentacji. Pomysł, nad którym pracuję, polega na zezwoleniu na uruchamianie 'roxygen' na dowolnych katalogach, aby mógł być użyty z' projektem', który nie jest pakietem 'R'. – Ramnath

Odpowiedz

17

To jest bardzo dobre pytanie: ludzie powinni być bardzo zainteresowani wszystkimi sekwencjami gromadzenia danych, agregacji, transformacji itp., Które stanowią podstawę dla wyników statystycznych. Niestety nie jest to powszechnie praktykowane.

Zanim odpowiem na twoje pytania, chcę podkreślić, że wydaje się to dość związane z ogólnym celem zarządzania danymi pochodzenia. Równie dobrze mogę ci dać Google link, aby przeczytać więcej. :) Istnieje wiele zasobów, które można znaleźć, takie jak ankiety, narzędzia programowe (np. Niektóre wymienione w wpisie w Wikipedii), różne projekty badawcze (np. Provenance Challenge) i inne.

To koncepcyjne start, teraz na adres istotne zagadnienia:

Pracuję nad projektem teraz gdzie zostały powoli gromadząc kilka różnych zmiennych z gronem różnych źródeł. Będąc nieco sprytnym człowiekiem, stworzyłem inny podkatalog dla każdego pod głównym katalogiem "original_data" i zawarłem plik .txt z adresem URL i innymi deskryptorami skąd mam dane. Będąc niewystarczająco sprytną osobą, te pliki .txt nie mają żadnej struktury.

Witaj w koszmarach wszystkich. :)

Teraz mam do czynienia z zadaniem opracowania sekcji metod, która dokumentuje wszystkie różne źródła danych. Jestem gotów przejść i dodać strukturę danych, ale wtedy potrzebowałbym znaleźć lub zbudować narzędzie do raportowania, aby przejrzeć katalogi i wydobyć informacje.

Nie ma problemu. list.files(...,recursive = TRUE) może stać się dobrym przyjacielem; zobacz także listDirectory() w R.utils.

Warto zauważyć, że wypełnienie sekcji metod dotyczącej źródeł danych jest wąską aplikacją w obrębie pochodzenia danych. W rzeczywistości niefortunne jest to, że CRAN Task View on Reproducible Research skupia się tylko na dokumentacji. Cele pochodzenia danych stanowią, moim zdaniem, podzbiór powtarzalnych badań, a dokumentacja manipulacji danymi i wyniki stanowią podzbiór pochodzenia danych. Tak więc ten pogląd na zadania jest wciąż w powijakach w odniesieniu do powtarzalnych badań. Może to być przydatne dla twoich celów, ale w końcu go przerosniesz. :)

Czy takie narzędzie istnieje?

Tak. Czym są takie narzędzia? Mon dieu ... jest bardzo zorientowany na aplikacje. W R, myślę, że te narzędzia nie są poświęcone zbyt dużej uwagi (* patrz poniżej). To raczej niefortunne - albo coś mi brakuje, albo w społeczności R brakuje czegoś, czego powinniśmy używać.

Podstawowy proces, który opisałem, zazwyczaj używam JSON (zob. this answer i this answer w celu uzyskania komentarzy na temat tego, co robię). W przypadku większości moich prac reprezentuję to jako "model przepływu danych" (termin ten może być niejednoznaczny, nawiasem mówiąc, zwłaszcza w kontekście informatyki, ale mam na myśli to z perspektywy analizy statystycznej). W wielu przypadkach ten przepływ jest opisany za pomocą JSON, więc nie jest trudno wyodrębnić sekwencję z JSON, aby rozwiązać problem powstawania poszczególnych wyników.

W przypadku bardziej złożonych lub regulowanych projektów JSON nie wystarcza, a ja korzystam z baz danych, aby zdefiniować sposób gromadzenia, przekształcania itp. W przypadku projektów regulowanych baza danych może zawierać wiele uwierzytelnień, rejestrowania i innych elementów, aby zapewnić, że pochodzenie danych jest dobrze udokumentowane. Podejrzewam, że tego rodzaju DB jest dobrze poza zainteresowanie, więc przejdźmy dalej ...

1. Język znaczników należy stosować (YAML?)

Szczerze mówiąc, co trzeba, aby opisać twój przepływ danych będzie odpowiedni. Przez większość czasu uważam za stosowne mieć dobry JSON, dobre układy katalogów danych i dobre sekwencjonowanie skryptów.

2. wszystkie podkatalogi powinny być skanowane

Sporządzono: listDirectory()

3. Aby ułatwić (2), standardowe rozszerzenie dla deskryptora zestawu danych należy stosować

Trivial: ".json". ;-) Lub ".SecretSauce" działa również.

4. Krytycznie, aby to najbardziej przydatny tam musi być jakiś sposób, aby dopasować zmienne deskryptory z nazwą, że ostatecznie podjąć dalej. Dlatego też wszystkie zmiany nazw zmiennych muszą być wykonywane w plikach źródłowych, a nie w etapie czyszczenia (mniej niż idealne), niektóre operacje na kodach muszą być wykonywane przez mechanizm dokumentacji, aby śledzić zmiany nazw zmiennych (ugh!), Lub niektóre należy zastosować prostszą hybrydę, taką jak zezwolenie na podanie nazw zmiennych w pliku znaczników.

Jak stwierdzono, nie ma to sensu. Załóżmy, że biorę var1 i var2 i tworzę var3 i var4. Być może var4 jest po prostu mapowaniem var2 na jego kwantyle, a var3 jest maksymalnym celem obserwacji var1 i var2; lub mogę utworzyć var4 z var2 przez obcięcie ekstremalnych wartości. Jeśli to zrobię, czy zachowam nazwę var2? Z drugiej strony, jeśli chodzi o po prostu dopasowanie "długich nazw" z "prostymi nazwami" (tj. Deskryptorami tekstu do zmiennych R), to jest to coś, co tylko Ty możesz zrobić. Jeśli masz bardzo uporządkowane dane, nietrudno stworzyć listę nazw tekstów pasujących do nazw zmiennych; alternatywnie można utworzyć tokeny, po których można przeprowadzić podstawianie ciągów znaków. Nie sądzę, że trudno jest stworzyć plik CSV (lub, jeszcze lepiej, JSON ;-)), który dopasowuje nazwę zmiennej do deskryptora. Po prostu sprawdzaj, czy wszystkie zmienne mają pasujące ciągi deskryptorów, i zatrzymaj się, gdy już to zrobisz.

5. Idealnie raport będzie na matrycy, jak również (na przykład „Jesteśmy wyciągnął [var] zmienną z [DUstaw] zbiorze dniu [data].”), A być może związany z Sweave.

W tym miejscu mogą znaleźć zastosowanie sugestie innych osób: roxygen i roxygen2.

6. Narzędzie powinno być wystarczająco elastyczne, aby nie być zbyt uciążliwe. Oznacza to, że minimalna dokumentacja byłaby po prostu nazwą zestawu danych.

Hmm, jestem tu zaskoczony. :)

(*) Nawiasem mówiąc, jeśli chcesz jeden projekt FOSS, który się do tego odnosi, sprawdź Taverna. Zostało to integrated with R udokumentowane w kilku miejscach. W tej chwili może to być przesadą dla twoich potrzeb, ale warto zastanowić się nad przykładem przyzwoicie dojrzałego systemu workflow.


Uwaga 1: Bo często wykorzystują bigmemory dla dużych zbiorów danych, muszę wymienić kolumny każdej matrycy. Są one przechowywane w pliku deskryptora dla każdego pliku binarnego. Proces ten zachęca do tworzenia deskryptorów dopasowujących nazwy zmiennych (i matryce) do deskryptorów. Jeśli przechowujesz swoje dane w bazie danych lub innych zewnętrznych plikach obsługujących dostęp losowy i wielokrotny dostęp R/W (np. Pliki mapowane w pamięci, pliki HDF5, pliki inne niż .rdat), najprawdopodobniej okaże się, że dodawanie deskryptorów staje się drugą naturą.

+0

+1 Dobra odpowiedź. Dodam JSON na mojej liście rzeczy, żeby się o tym dowiedzieć. – Andrie

+0

@Andrie Co jest bardzo ekscytujące, to że nie masz wiele do nauczenia się! Znasz już listy R, które, jak sądzę, oferują nadzbiór nad możliwościami JSON (jeden może argumentować, że mogą być izomorficzne, nie jestem pewien). Sprawdź moje małe demo w [tej odpowiedzi] (http://stackoverflow.com/questions/6437213/strategies-for-repeating-large-chunk-of-analysis/6550914#6550914). Potrwa to około 3-5 minut, aby nauczyć się wszystkiego, co musisz wiedzieć, wypróbowując 'fromJSON' i' toJSON', która jest częścią I/O, ponieważ znasz już listy i zagnieżdżanie list. Wszystko zostanie przekształcone w listę. – Iterator

+0

(Kontynuacja) Przeglądanie opcji 'fromJSON' jest przydatne, ponieważ możesz nauczyć się tworzenia nazwanych wektorów, a la' c (Tom = "cat", Jerry = "mouse") '. Jedynym problemem jest to, że 'TRUE' i' FALSE' są przechowywane w JSON w swoich małych literach. – Iterator

Powiązane problemy