2011-11-02 24 views
21

मैं अभी एक परियोजना पर काम कर रहा हूं जहां मैं धीरे-धीरे विभिन्न स्रोतों के समूह से विभिन्न चरों का एक गुच्छा जमा कर रहा हूं। कुछ हद तक चालाक व्यक्ति होने के नाते, मैंने मुख्य "मूल_डेटा" निर्देशिका के तहत प्रत्येक के लिए एक अलग उप-निर्देशिका बनाई, और यूआरएल और अन्य वर्णनकर्ताओं के साथ एक .txt फ़ाइल शामिल की जहां से मुझे डेटा मिला। अपर्याप्त रूप से चालाक व्यक्ति होने के नाते, इन .txt फ़ाइलों में कोई संरचना नहीं है।डेटासेट का स्वचालित दस्तावेज

अब मुझे एक विधियों अनुभाग को संकलित करने के कार्य का सामना करना पड़ रहा है जो सभी अलग-अलग डेटा स्रोतों को दस्तावेज करता है। मैं डेटा के माध्यम से जाने और संरचना जोड़ने के लिए तैयार हूं, लेकिन फिर मुझे निर्देशिकाओं को स्कैन करने और जानकारी निकालने के लिए एक रिपोर्टिंग टूल ढूंढना या बनाना होगा।

ऐसा लगता है कि ProjectTemplate पहले से ही होगा, लेकिन मुझे वह कार्यक्षमता नहीं मिल रही है।

क्या ऐसा कोई उपकरण मौजूद है?

यदि ऐसा नहीं होता है, तो अधिकतम लचीलापन प्रदान करने के लिए क्या विचारों को ध्यान में रखा जाना चाहिए? कुछ प्रारंभिक विचार: (? YAML)

  1. एक मार्कअप भाषा इस्तेमाल किया जाना चाहिए
  2. सभी उप-निर्देशिका
  3. स्कैन किया जाना चाहिए सुविधाजनक बनाने के लिए (2), एक डाटासेट वर्णनकर्ता के लिए एक मानक विस्तार
  4. इस्तेमाल किया जाना चाहिए
  5. गंभीरता से, इसे सबसे उपयोगी बनाने के लिए वे वैरिएबल डिस्क्रिप्टरों को उस नाम से मिलान करने के लिए कुछ तरीका होने की आवश्यकता है जिसे वे अंततः लेते हैं। इसलिए या तो चर के सभी नामकरण को एक सफाई चरण (आदर्श से कम) की बजाय स्रोत फ़ाइलों में किया जाना चाहिए, कुछ कोड-पार्सिंग को दस्तावेज़ नाम द्वारा परिवर्तनीय नाम परिवर्तन (यूघ!), या कुछ ट्रैक करने के लिए किया जाना है सरल संकर जैसे मार्कअप फ़ाइल में परिवर्तनीय नामों को निर्दिष्ट करने की अनुमति दी जानी चाहिए।
  6. आदर्श रूप से रिपोर्ट को भी टेम्पलेट किया जाएगा (उदाहरण के लिए "हमने [var] चर [dset] डेटासेट से [दिनांक] पर खींच लिया।"), और संभवतः स्वीवे से जुड़ा हुआ है।
  7. उपकरण अत्यधिक लचीला होने के लिए पर्याप्त लचीला होना चाहिए। इसका मतलब है कि न्यूनतम दस्तावेज बस एक डेटासेट नाम होगा।
+1

कुछ विचार। एक, आपको डेटा-सेट दस्तावेज करने के लिए 'roxygen2' देखना चाहिए। दो, जो आप चाहते हैं उसे करने के लिए 'प्रोजेक्ट टेम्पलेट' को सामान्य बनाना बहुत आसान है, और मैं अवधारणा के सबूत पर काम कर रहा हूं, जिसे मैं जल्द ही 'गीथूब' पर पोस्ट करूंगा। – Ramnath

+0

@ रामनाथ धन्यवाद। सुनने में अच्छा है। मैं डेटासेट के लिए 'roxygen2' काम भूल गया था, इसलिए मैं इसे एक लुक दूंगा। क्या आपके पास कहीं भी लिखा गया एक प्रलेखन प्रारूप है, भले ही पार्सर नहीं किया गया हो, ताकि जब आप अवधारणा का सबूत निकल जाए तो मैं फिर से लिखने से बच सकता हूं? –

+0

मैं एक नए दस्तावेज़ प्रारूप पर काम नहीं कर रहा हूं। अधिकांश दस्तावेज आवश्यकताओं के लिए 'roxygen2' पर्याप्त है। जिस विचार पर मैं काम कर रहा हूं वह है कि 'roxygen' को मनमानी निर्देशिकाओं पर चलाने की अनुमति दें, ताकि इसका उपयोग' प्रोजेक्ट 'के साथ किया जा सके जो' आर' पैकेज नहीं है। – Ramnath

उत्तर

17

यह एक बहुत अच्छा सवाल है: लोगों को डेटा संग्रह, एकत्रीकरण, परिवर्तन इत्यादि के सभी अनुक्रमों के बारे में बहुत चिंतित होना चाहिए, जो सांख्यिकीय परिणामों के लिए आधार बनते हैं। दुर्भाग्य से, यह व्यापक रूप से अभ्यास नहीं किया जाता है।

अपने प्रश्नों को संबोधित करने से पहले, मैं इस बात पर जोर देना चाहता हूं कि यह डेटा उद्भव के प्रबंधन के सामान्य उद्देश्य से काफी प्रतीत होता है। मैं आपको और पढ़ने के लिए Google link भी दे सकता हूं। :) संसाधनों का एक समूह है जो आपको मिलेगा, जैसे सर्वेक्षण, सॉफ़्टवेयर टूल (उदा। कुछ विकिपीडिया प्रविष्टि में सूचीबद्ध), विभिन्न शोध परियोजनाओं (उदा। Provenance Challenge), आदि।

एक वैचारिक शुरू है यही कारण है, अब पता करने के लिए व्यावहारिक मुद्दों:

मैं एक परियोजना पर काम कर रहा हूँ अभी मैं कहाँ है धीरे-धीरे विभिन्न स्रोतों के एक झुंड से अलग चर का एक गुच्छा जमा कर दिया गया। कुछ हद तक चालाक व्यक्ति होने के नाते, मैंने मुख्य "मूल_डेटा" निर्देशिका के तहत प्रत्येक के लिए एक अलग उप-निर्देशिका बनाई, और यूआरएल और अन्य वर्णनकर्ताओं के साथ एक .txt फ़ाइल शामिल की जहां से मुझे डेटा मिला। अपर्याप्त रूप से चालाक व्यक्ति होने के नाते, इन .txt फ़ाइलों में कोई संरचना नहीं है।

हर किसी के दुःस्वप्न में आपका स्वागत है। :)

अब मुझे एक विधियों अनुभाग को संकलित करने के कार्य का सामना करना पड़ रहा है जो सभी अलग-अलग डेटा स्रोतों को दस्तावेज करता है। मैं डेटा के माध्यम से जाने और संरचना जोड़ने के लिए तैयार हूं, लेकिन फिर मुझे निर्देशिकाओं को स्कैन करने और जानकारी निकालने के लिए एक रिपोर्टिंग टूल ढूंढना या बनाना होगा।

कोई समस्या नहीं। list.files(...,recursive = TRUE) एक अच्छा दोस्त बन सकता है; R.utils में listDirectory() भी देखें।

यह ध्यान देने योग्य है कि डेटा स्रोतों पर एक विधि अनुभाग भरना डेटा उद्भव के भीतर एक संकीर्ण अनुप्रयोग है। वास्तव में, यह दुर्भाग्यपूर्ण है कि CRAN Task View on Reproducible Research केवल दस्तावेज़ीकरण पर केंद्रित है। डेटा उद्भव का उद्देश्य, मेरे अनुभव में, पुनरुत्पादित अनुसंधान का एक सबसेट है, और डेटा मैनिपुलेशन और परिणामों के दस्तावेज़ीकरण डेटा उद्भव का एक सबसेट है। इस प्रकार, यह कार्य दृश्य अभी भी पुनरुत्पादित अनुसंधान के संबंध में अपने बचपन में है। यह आपके लक्ष्यों के लिए उपयोगी हो सकता है, लेकिन आप अंततः इसे आगे बढ़ा देंगे। :)

क्या ऐसा कोई उपकरण मौजूद है?

हां। ऐसे उपकरण क्या हैं? सोम मरू ... यह सामान्य रूप से बहुत ही अनुप्रयोग केंद्रित है। आर के भीतर, मुझे लगता है कि इन उपकरणों को ज्यादा ध्यान नहीं दिया जाता है (* नीचे देखें)। यह दुर्भाग्यपूर्ण है - या तो मुझे कुछ याद आ रहा है, अन्यथा आर समुदाय में कुछ ऐसा गुम है जो हमें उपयोग करना चाहिए।

आपके द्वारा वर्णित मूल प्रक्रिया के लिए, मैं आमतौर पर JSON का उपयोग करता हूं (this answer और this answer देखें कि मैं क्या कर रहा हूं) पर टिप्पणियों के लिए। मेरे अधिकांश कामों के लिए, मैं इसे "डेटा प्रवाह मॉडल" के रूप में प्रस्तुत करता हूं (यह शब्द संदिग्ध हो सकता है, विशेष रूप से कंप्यूटिंग के संदर्भ में, लेकिन मेरा मतलब है कि यह सांख्यिकीय विश्लेषण परिप्रेक्ष्य से है)। कई मामलों में, यह प्रवाह जेएसओएन के माध्यम से वर्णित है, इसलिए जेएसओएन से अनुक्रम निकालना मुश्किल नहीं है ताकि यह पता चल सके कि विशेष परिणाम कैसे सामने आए।

अधिक जटिल या विनियमित परियोजनाओं के लिए, जेएसओएन पर्याप्त नहीं है, और मैं डेटा को एकत्रित करने, बदलने, इत्यादि को परिभाषित करने के लिए डेटाबेस का उपयोग करता हूं। विनियमित परियोजनाओं के लिए, डेटाबेस में प्रमाणीकरण, लॉगिंग और बहुत कुछ हो सकता है, यह सुनिश्चित करने के लिए कि डेटा उद्भव अच्छी तरह से प्रलेखित है। मुझे लगता है कि डीबी उस तरह का अच्छी तरह से आपकी दिलचस्पी से परे है, तो चलो पर चलते हैं ...

1. एक मार्कअप भाषा इस्तेमाल किया जाना चाहिए (YAML?)

सच कहूं, आप जो भी वर्णन करने के लिए की जरूरत है आपका डेटा प्रवाह पर्याप्त होगा। अधिकांश समय, मुझे अच्छा JSON, अच्छी डेटा निर्देशिका लेआउट, और स्क्रिप्ट की अच्छी अनुक्रमित करने के लिए पर्याप्त लगता है।

2. सभी उप-निर्देशिका स्कैन किया जाना चाहिए

डन: listDirectory()

3. सुविधाजनक बनाने के लिए (2), एक डाटासेट वर्णनकर्ता के लिए एक मानक विस्तार किया जाना चाहिए

ट्रिविअल: ".json"। ;-) या ".ScrecretSauce" भी काम करता है।

4. गंभीरता से, यह सबसे उपयोगी बनाने के लिए वे वैरिएबल डिस्क्रिप्टरों को उस नाम से मिलान करने के लिए कुछ तरीका होने की आवश्यकता है जो वे अंत में लेते हैं। इसलिए या तो चर के सभी नामकरण को एक सफाई चरण (आदर्श से कम) की बजाय स्रोत फ़ाइलों में किया जाना चाहिए, कुछ कोड-पार्सिंग को दस्तावेज़ नाम द्वारा परिवर्तनीय नाम परिवर्तन (यूघ!), या कुछ ट्रैक करने के लिए किया जाना है सरल संकर जैसे मार्कअप फ़ाइल में परिवर्तनीय नामों को निर्दिष्ट करने की अनुमति दी जानी चाहिए।

जैसा कि कहा गया है, यह काफी समझ में नहीं आता है। मान लीजिए कि मैं var1 और var2 लेता हूं, और var3 और var4 बना देता हूं। शायद var4 इसकी मात्रा में var2 का मैपिंग है और var3 अवलोकन-वार अधिकतम var1 और var2 है; या मैं var2 से चरम मूल्यों को कम करके बना सकता हूं। अगर मैं ऐसा करता हूं, तो क्या मैं var2 का नाम बरकरार रखता हूं? दूसरी तरफ, यदि आप "सरल नाम" के साथ "लंबे नाम" से मिलान करने का जिक्र कर रहे हैं (यानी आर चर के लिए पाठ वर्णनकर्ता), तो यह केवल कुछ है जो आप कर सकते हैं। यदि आपके पास बहुत संरचित डेटा है, तो परिवर्तनीय नामों से मेल खाने वाले टेक्स्ट नामों की सूची बनाना मुश्किल नहीं है; वैकल्पिक रूप से, आप टोकन बना सकते हैं जिस पर स्ट्रिंग प्रतिस्थापन किया जा सकता है। मुझे नहीं लगता कि एक CSV (या, बेहतर अभी तक, JSON ;-)) बनाना मुश्किल है जो वैरिएबल नाम से वर्णक से मेल खाता है। बस यह जांचते रहें कि सभी चरों में मिलान करने वाले स्ट्रिंग्स हैं, और एक बार ऐसा करने से रोकें।

5. आदर्श रूप में रिपोर्ट के रूप में अच्छी तरह से टेम्प्लेट किया जाएगा (जैसे "हम डाटासेट से [dset] [वर] चर। [तिथि] पर खींच लिया"), और संभवतः Sweave से जुड़ा हुआ।

यही वह जगह है जहां roxygen और roxygen2 के अन्य सुझाव लागू हो सकते हैं।

6. उपकरण अत्यधिक लचीला होने के लिए पर्याप्त लचीला होना चाहिए। इसका मतलब है कि न्यूनतम दस्तावेज बस एक डेटासेट नाम होगा।

हम्म, मैं यहां स्टंप हूं। :)

(*) वैसे, अगर आप इससे संबंधित एक एफओएसएस परियोजना चाहते हैं, तो Taverna देखें। यह कई स्थानों पर दस्तावेज के रूप में integrated with R रहा है। यह इस समय आपकी आवश्यकताओं के लिए अधिक हो सकता है, लेकिन यह एक स्थायी परिपक्व वर्कफ़्लो सिस्टम के उदाहरण के रूप में जांच के लायक है।


नोट 1: क्योंकि मैं अक्सर बड़े डेटा सेट के bigmemory उपयोग करते हैं, मैं एक मैट्रिक्स के कॉलम नाम के लिए है। ये प्रत्येक बाइनरी फ़ाइल के लिए एक वर्णक फ़ाइल में संग्रहीत हैं। यह प्रक्रिया वर्णनकर्ताओं को परिवर्तनीय नाम (और matrices) से मेल खाने वाले वर्णकों के निर्माण को प्रोत्साहित करती है। यदि आप अपने डेटा को डेटाबेस या अन्य बाहरी फाइलों में यादृच्छिक पहुंच और एकाधिक आर/डब्ल्यू एक्सेस (उदा। मेमोरी मैप की गई फाइलें, एचडीएफ 5 फाइलें, लेकिन .dat फ़ाइलों के अलावा कुछ भी) में स्टोर करते हैं, तो आप पाएंगे कि डिस्क्रिप्टर जोड़ना दूसरी प्रकृति बन जाता है।

+0

+1 अच्छा जवाब। मैं सीखने के लिए चीजों की सूची में जेएसओएन जोड़ूंगा। – Andrie

+0

@Andrie क्या बहुत रोमांचक है कि आपके पास सीखने के लिए बहुत कुछ नहीं है! आप पहले से ही आर की सूचियों को जानते हैं, जो मुझे विश्वास है, जेएसओएन क्षमताओं का एक सुपरसेट प्रदान करते हैं (कोई तर्क दे सकता है कि वे आइसोमोर्फिक हो सकते हैं, मुझे यकीन नहीं है)। [इस उत्तर] में मेरा छोटा डेमो देखें (http://stackoverflow.com/questions/6437213/strategies-for-repeating-large-chunk-of-analysis/6550914#6550914)। 'सेजसन' और 'toJSON'' को आज़माकर आपको जो कुछ जानने की आवश्यकता है, उसे जानने के लिए लगभग 3-5 मिनट लगेंगे, क्योंकि आप पहले से ही सूचियों और सूचियों को सूचीबद्ध करते हैं। सब कुछ एक सूची में परिवर्तित हो जाता है। – Iterator

+0

(जारी) 'सेजसन 'के विकल्पों को देखते हुए उपयोगी है क्योंकि आप नामित वैक्टर, ला ला सी (टॉम =" बिल्ली ", जेरी =" माउस ") बनाने के तरीके सीख सकते हैं। केवल गॉचा यह है कि 'TRUE' और' FALSE' JSON में उनके लोअरकेस रूपों में संग्रहीत हैं। – Iterator