WikiGoogleMetaTrack DNS

सही मायने में विकेन्द्रीकृत इंटरनेट के निर्माण में मुख्य बाधाओं में से एक है वांछित (और मुझे भी) नेटवर्क पर साइटों और फाइलों को खोजने, वर्गीकृत करने, नामकरण और व्यवस्थित करने की समस्या है। सूचना के विकेंद्रीकृत प्रसंस्करण और भंडारण के लिए एक वातावरण बनाना पर्याप्त नहीं है;

अन्यथा, यह पता चला है - जिसके लिए वे लड़े, वे किसी चीज में भाग गए। सूचना बहुतायत के बजाय, एक कचरा डंप बाहर निकल जाएगा। नेटवर्क पर जानकारी की मात्रा ऐसी है कि आवश्यक डेटा को खोजने में असमर्थता उनकी पूर्ण अनुपस्थिति के बराबर है। सिग्नल शोर में डूब रहा है। और सब ठीक है, अगर यह शोर सफेद है, लेकिन इसका अक्सर एक स्पष्ट रंग होता है - राजनीतिक या वाणिज्यिक।

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

कैप्टन साक्ष्य से ऐतिहासिक यात्रा

उनमें से सबसे पुराना डीएनएस है। मैं अक्सर खुद को किसी साइट के "नाम" और "पते" की अवधारणाओं को भ्रमित करता हुआ पाता हूं। यद्यपि पता प्रश्न का उत्तर "कहाँ है?", और नाम इस प्रश्न का उत्तर देता है "क्या?"। आईपी ​​पता और डोमेन नाम। DNS नामकरण के लिए एक प्रणाली है, संबोधित नहीं, संसाधन।

आप DNS को इंटरनेट संसाधनों के विशाल, लेकिन बहुत संक्षिप्त कैटलॉग के रूप में देख सकते हैं। सब कुछ स्पष्ट रूप से पदानुक्रमित अलमारियों में व्यवस्थित किया गया है, प्रत्येक DNS रिकॉर्ड में साइट का नाम, नाम और पता (तथ्य यह है कि वास्तविक वाले) नहीं है और कुछ सेवा की जानकारी है जो साइट के नाम को उसके पते से जोड़ती है। शायद यह इंटरनेट के भोर में एक महान विचार था, जब कुछ साइटें थीं, और उनका उपयोग लगभग विशेष रूप से वैज्ञानिकों और प्रोग्रामर द्वारा किया गया था, जो कुछ भी हो, आईपी पते द्वारा उन्मुख कर सकते हैं। अब, जब साइटों का खाता दसियों और करोड़ों में चला जाता है, और औसत नेटवर्क उपयोगकर्ता न केवल पसंदीदा साइटों के आईपी पते को याद नहीं करता है, बल्कि यह नहीं जानता है कि आईपी पते क्या है, तो अभेद्य रूप से विशाल शक्ति DNS सर्वरों के हाथों में केंद्रित थी। लड़की! - और साइट बस मौजूद नहीं है। यदि साइट को होस्टिंग से दूर ले जाया जाता है, तो पर्याप्त रूप से प्रवेश की उच्च योग्यता के साथ, लगभग कोई भी कुछ भी नोटिस नहीं करेगा, अधिकतम डाउनटाइम के कई घंटे हैं। एक डोमेन का नुकसान बहुत बड़े पैमाने पर एक आपदा है।

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

पहली पीढ़ी के खोज इंजनों ने इसकी गुणवत्ता को कम करने की कीमत पर "इंटरनेट फ़ाइल अलमारियाँ" को स्केल करने की समस्या को हल किया है। आर्टिफिशियल वेबमास्टर्स ने साइट के पृष्ठों पर कीवर्ड में हेरफेर करके खोज इंजन को धोखा देने के तरीकों में तेजी से महारत हासिल की। और यहां पहला विकेन्द्रीकरण निगल पेज रैंक के रूप में दिखाई दिया। खोज परिणामों को रैंकिंग के लिए उपयोग करने का सरल विचार (और इतना ही नहीं) साइट की सामग्री को ही नहीं, बल्कि उपयोगकर्ता व्यवहार, जो तृतीय-पक्ष संसाधनों से साइट के लिंक के रूप में व्यक्त किया गया है, Google की शक्ति का आधार बन गया है।

ध्यान दें कि DNS के साथ ब्राउज़र का काम और Google के साथ उपयोगकर्ता का काम कैसे समान है। दोनों मामलों में, इनपुट में एक पंक्ति होती है जो प्रश्न "क्या?" का उत्तर देती है। यह लाइन DNS सर्वर या Google के डेटा केंद्रों में प्रसंस्करण के लिए दी गई है, और वे इस सवाल का जवाब देते हैं "कहां?" यह बहुत "क्या है?"

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

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

अर्ध-तैयार उत्पाद खोजें

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

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

बॉक्सिंग की तरह, जब एक ही मूल नियमों और तकनीकों के साथ प्रतियोगिताओं के कई संस्करण और प्रारूप हैं - ये सभी WBA, WBO और WBC, तो एक विकेंद्रीकृत इंटरनेट पर आप कुछ बुनियादी मेटाडेटा प्रारूप प्रदान कर सकते हैं जिसके आधार पर विभिन्न खोज एल्गोरिदम एक-दूसरे के साथ प्रतिस्पर्धा करेंगे, रैंकिंग और फ़िल्टरिंग। और, जिस तरह विभिन्न संस्करणों के चैंपियंस के एकीकरण झगड़े मुक्केबाजी में आयोजित किए जा सकते हैं, उपयोगकर्ता को यह चुनने के लिए सक्षम करना आवश्यक है कि सार्वजनिक रूप से उपलब्ध बुनियादी मेटाडेटा के प्रसंस्करण के लिए कौन सा एल्गोरिदम का उपयोग करें। फिर तुम तुरंत देखोगे कि कौन है। एल्गोरिदम के बीच स्वस्थ प्रतिस्पर्धा होगी। सभी एल्गोरिदम खुले होंगे, क्योंकि यदि कोड को ग्राहकों की मशीनों पर वितरित किया जाता है, तो इसे बनाना और छिपाना एक Sisyphean काम है। इसका मतलब यह है कि इस संदेह के लिए कोई आधार नहीं होगा कि कोई बेईमान या अनुचित मानता है। अभी भी संदेह में है? सेटिंग्स पर जाएं, दूसरे एल्गोरिदम पर जाएं और जांचें।

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

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

एक सार्वभौमिक मेटाडेटा प्रारूप कैसा दिख सकता है?

फ़ाइलों, लोगों, समुदायों और साइटों को एक संरचना में कैसे संयोजित करें? जाहिर है, आपको अमूर्तता के उच्च स्तर पर चढ़ने की आवश्यकता है। इन सभी संस्थाओं में क्या समानता है? कम से कम, ये ऐसे संसाधन हैं जो इंटरनेट पर हैं। ठीक है, या कम से कम वे इंटरनेट पर प्रस्तुत किए जाते हैं। क्या कुछ भी समान नहीं है? उदाहरण के लिए, REST मॉडल में संसाधन और उनके अभ्यावेदन? फिल्म "द डेल्टा फोर्स" चक नॉरिस और नाक एक-आवाज़ अनुवाद के साथ, उदाहरण के लिए, फ़ाइल-साझाकरण नेटवर्क में निहित है। वास्तव में, किसी भी REST संसाधन की तरह, फिल्म एक अमूर्त अवधारणा है, यह केवल इसके अभ्यावेदन के रूप में मौजूद है। उदाहरण के लिए, सामान्य, निर्देशक और सेंसर वाला संस्करण। या मूल, डबिंग और विभिन्न भाषाओं में अनुवाद। या विभिन्न प्रस्तावों और बिट दर वाली फाइलें। ये सभी एक ही संसाधन के निरूपण हैं। संसाधन प्रश्न का उत्तर "क्या?", इसकी प्रस्तुति - प्रश्न "क्या?"

यह योजना ऐसे बुनियादी तकनीकी मेटाडेटा से कुछ फाइलों के डाउनलोड की संख्या के रूप में प्राप्त करने की अनुमति देती है, संसाधन की समग्र रूप से लोकप्रियता - यह संसाधन के सभी अभ्यावेदन के लिए काउंटरों को जोड़ने के लिए पर्याप्त है। यह आपको संसाधनों का लचीले ढंग से मूल्यांकन करने की अनुमति देता है - उदाहरण के लिए, मैंने +1 को एक संसाधन में रखा है और इसके एक प्रतिनिधित्व ("महान फिल्म!") और -1 को एक और प्रतिनिधित्व ("निर्देशक का संस्करण बहुत लंबा है")। या, एक अन्य उदाहरण: एक संसाधन के लिए +1 ("दिलचस्प लेख") और -1 एक प्रतिनिधित्व ("vyrviglaznaya लेआउट)" के लिए।

जब नेटवर्क पर एक नई वस्तु दिखाई देती है - निश्चितता के लिए, भले ही वह एक फिल्म हो, प्रस्तुति के बारे में जानकारी वाली मेटाडेटा फ़ाइल स्वचालित रूप से बनाई जाती है। यदि दृश्य एकल प्रतिलिपि में मौजूद है (हमने नेटवर्क पर कुछ बिल्कुल अनोखा पोस्ट किया है), तो एक दूसरा संसाधन स्तर मेटाफ़ाइल बनाया जाता है। यदि इस संसाधन के अन्य प्रतिनिधित्व पहले से ही नेटवर्क पर मौजूद हैं, तो नए प्रतिनिधित्व के बारे में जानकारी संबंधित संसाधन मेटाफ़ाइल में दर्ज की जाती है।

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

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

संसाधन स्तर पर, रेटिंग, सामान्य आँकड़े, और अंतर्निहित मेटाफ़ाइल्स के लिंक के अलावा, लगभग शुद्ध शब्दार्थ है: सभी अभ्यावेदन के लिए टैग और रेटिंग, और फ़ाइल प्रकार पर अत्यधिक निर्भर क्षेत्र: नाम, शीर्षक, लिंग, आयु, लेखक, शैली और आदि ... संसाधन स्तर शब्दार्थ वेब के बीच एक पुल है, जिसमें ऑन्कोलॉजी और तार्किक अनुमान और अधिक तकनीकी और तात्विक चीजें हैं, जैसे कि रेटिंग, लिंक और हिट काउंटर। इस पुल पर यातायात दो तरफा है। हैश को जानने के बाद, आप चैन को सिमेंटिक लेवल पर जाकर फाइल के बारे में सारी जानकारी प्राप्त कर सकते हैं। केवल सबसे सामान्य खोज क्वेरी होने के बाद, आप एक विशिष्ट फ़ाइल दृश्य पर जा सकते हैं।



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

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

यदि मेटाफ़ाइल्स का प्रारूप कठोरता से परिभाषित नहीं किया गया है, और एक्सेस वाला कोई भी उनमें जानकारी दर्ज कर सकता है, तो उन्हें प्राकृतिक या दुर्भावनापूर्ण क्लॉगिंग से कैसे बचाया जाए? यदि हम मौजूदा क्षेत्रों को संशोधित करने के बारे में बात कर रहे हैं, तो सूचना की शुद्धता कई नेटवर्क नोड्स की आम सहमति से गारंटी देती है जो एक-दूसरे को डबल-चेक करेंगे।

और अगर कोई खोज या रैंकिंग एल्गोरिथ्म के साथ आया था, जिसके लिए आपको संसाधन की पूरी तरह से नई विशेषताओं पर विचार करने की आवश्यकता है? आप निश्चित रूप से, एक निश्चित प्राधिकरण को पेश कर सकते हैं जो प्रत्येक प्रकार के संसाधन के लिए मानक मेटाडेटा सेट को मंजूरी देगा। लेकिन हम सिर्फ ऐसी योजनाओं से दूर होना चाहते हैं, है ना? फिर, यह निर्धारित करने के लिए कि मेटाफ़ाइल में कौन से रिकॉर्ड उपयोगी और माँग में हैं, और जो पुराने हैं या जिनकी कभी आवश्यकता नहीं है?

हम इस स्थिति का अनुकरण करेंगे। मान लें कि हम निम्नलिखित जानकारी को संगीत संसाधनों के मेटाफ़ाइल्स में संग्रहीत करते हैं:

• ट्रैक का शीर्षक, एल्बम, कलाकार, रिलीज़ की तारीख, आदि।
• विनिर्देशों - प्रारूप, बिट दर, समय
• आंकड़े डाउनलोड करें
• संसाधन उपलब्धता (उदाहरण के लिए, सक्रिय बीजों की संख्या, यदि आप बिटटोरेंट शब्दावली का उपयोग करते हैं)
• टैग मेघ

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

उसी तरह, आप अनावश्यक मेटाडेटा को हटा सकते हैं। यदि किसी ने बहुत लंबे समय तक उनसे अनुरोध नहीं किया है, तो आप मेटाफ़ाइल्स की सफाई शुरू कर सकते हैं।

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

फाइलों से लेकर साइट्स और लोगों तक

प्रत्येक साइट एक मिश्रित संसाधन है जिसमें एम्बेडेड संसाधनों का संग्रह होता है। इसकी रेटिंग या प्रतिष्ठा अधीनस्थ संसाधनों के संकेतकों की समग्रता पर निर्भर होनी चाहिए। एक साइट की बहुत अवधारणा इस तरह की योजना में बहुत मिट गई है - विकेंद्रीकरण समान है!

लेकिन अभी के लिए, साइटें इंटरनेट की संरचना का मुख्य तरीका हैं। और निकट भविष्य में, थोड़ा बदल जाएगा। और साइट के लिए नाम का सवाल बहुत तीव्र है। यदि नेटवर्क पर कहीं फ़ाइल का नाम किसी के लिए कम चिंता का विषय है, तो साइट का नाम याद रखने के लिए एक सरल और आसान बहुत महत्वपूर्ण है। मौजूदा डोमेन नाम प्रणाली किसी तरह काम करती है। बदले में क्या पेश किया जा सकता है?

संसाधन स्तर मेटाफ़ाइल में साइट नाम के साथ प्रविष्टि? यह अच्छी तरह से हो सकता है।आखिर डीएनएस सिस्टम की मुख्य समस्या क्या है? तथ्य यह है कि नाम सर्वर रिकॉर्ड लगभग कोई उपयोगी जानकारी नहीं रखता है। साइट के नाम से यह पता लगाना पूरी तरह से असंभव है कि क्या नाम सामग्री से मेल खाता है, साइट कितनी लोकप्रिय है, किससे संबंधित है। हमारे मेटाफ़ाइल्स में, यह सब है। और इसलिए, किसी को भी अपनी साइट पर "microsoft.com" नाम असाइन करके गुमराह करना संभव नहीं होगा। कोई भी क्लोन प्रतिष्ठा के स्तर के करीब पहुंचने में सक्षम नहीं होगा जो मूल है। और अगर वह कर सकता है, तो इसका मतलब है कि मूल में समस्याएं हैं जिन्हें सरल तरीकों से इलाज नहीं किया जा सकता है।

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

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

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

और हां, किसी भी तरह से एक अच्छी तरह से विकसित नाम के लिए किसी अन्य साइट का चयन करना, ब्लॉक करना या स्थानांतरित करना असंभव है। विकिलिक्स के वंशज प्रसन्न होंगे।

सामान्य तौर पर, साइट नामों के साथ स्थिति लोगों के नामों के साथ बहुत समान है। कोई भी आपको अपना पासपोर्ट बदलने और चक नॉरिस बनने के लिए मना नहीं करेगा। लेकिन आपने यह नहीं सीखा कि कैसे यू-टर्न से किक करें। सबसे अधिक संभावना है, असली चक नॉरिस पासपोर्ट कार्यालय में कागज के टुकड़ों के साथ अपने उपद्रव के बारे में भी नहीं जानता होगा।

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

अर्थ वेब?

मेटाफ़ाइल्स के प्रारूप को तैयार करने और वर्णन करने में, मैं इस भावना से छुटकारा नहीं पा सकता था कि मैं शब्दार्थ वेब को फिर से शुरू कर रहा हूं । खुद को (और एक ही समय में) आप को समझाने के लिए, मैं समानता और अंतर पर विचार करूंगा।

वहाँ और यहाँ दोनों मेटाडेटा मौजूद है। लेकिन सिमेंटिक वेब में, किसी को मैन्युअल रूप से इस डेटा को चलाना होगा। ऐसा लगता है, क्या समस्या है? वहाँ, पूरा विकिपीडिया हाथ से, मुफ्त में और गुमनाम रूप से लिखा गया था! और नहीं!एक विश्वकोश लेख लिखना या संपादित करना एक जटिल और रचनात्मक कार्य है, जिसका अर्थ है कि प्रक्रिया स्वयं मजेदार है और लेखक को पुरस्कृत करती है। मेटाडेटा के साथ काम करना - अनिवार्य रूप से एक फॉर्म भरना - एक थकाऊ और गूंगा गतिविधि है। यह वेब 3.0 के अविकसित होने के कारणों में से एक है।

, . , , , , — , — , ( , !) — . , . “+1” “-1” , , . कुछ इस तरह:



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

वेब अब मेटाडेटा की विशाल मात्रा को संग्रहीत करता है। लेकिन वे ऊंचे पहाड़ों और गहरी खाई के साथ जीवन के लिए बहुत आरामदायक नहीं एक परिदृश्य बनाते हैं। आधुनिक इंटरनेट की सबसे ऊंची चोटियाँ केवल निर्विवाद रूप से अस्थिर पर्वत चोटियों से मिलती जुलती हैं। वे बेहद लचीले और सौम्य हैं, स्थानीय कानूनों के साथ टकराव से बचने और बाजारों को खोने से। और जो लोग सरकारों और प्रतिस्पर्धियों द्वारा रौंदे जाने वाले लचीले जोखिम नहीं चाहते हैं। और हम अचानक पाते हैं कि कल आसानी से उपलब्ध होने वाली जानकारी कहीं गायब हो गई थी।

सूत्रों और रुचियों की सूची

सामूहिक बुद्धिमत्ता,

वितरित

नेटवर्क बनाने के लिए दृष्टिकोणों में से एक पायराइन नेटवर्क में मेटाडेटा को संग्रहीत करने का प्रयास करता है:
चुंबक लिंक , शारेज़ा
संग्रह ,
मेटलिंक ,
चुंबक-प्रकट (मैग्मा) ।

वितरित खोज इंजन:
राजसी -12 ,
Vseisk ,
Grub ।