Ipfs: आईपीएफएस-एलडी - लिंक्ड डेटा

अरे @jbenet , बहुत अच्छा काम w/IPFS, आप जो कर रहे हैं उसमें बहुत दिलचस्पी है क्योंकि हम इंटरनेट पर नामकरण को बदलने के लिए DHTs (Kademlia-like) + डिजिटल हस्ताक्षर + क्वेरी नेटवर्क का उपयोग कर रहे हैं (अंततः DNS को बदलें)। हम जो बुनियादी काम कर रहे हैं, वह आपके आईपीएफएस के करीब है: https://manu.sporny.org/2014/identity-credentials/ । हम उस पहल के लिए JSON-LD का उपयोग कर रहे हैं, क्या आप Telehash के बारे में जानते हैं? यदि नहीं, तो आपको एक नज़र डालनी चाहिए क्योंकि उनमें से कुछ अवधारणाएँ IPFS को मजबूत कर सकती हैं।

किसी भी स्थिति में, यदि आप चाहते हैं कि नेटवर्क पर मेटाडेटा मशीन-पठनीय और संसाधित हो, लेकिन एक एक्स्टेंसिबल तरीके से हो, तो आपको JSON-LD का उपयोग करना चाहिए। यदि आप JSON-LD का उपयोग करते हैं, तो एक अच्छा मौका है कि आप W3C पर हो रहे वेब भुगतान और क्रेडेंशियल कार्य को एकीकृत कर सकते हैं क्योंकि ये दोनों कार्य भी JSON-LD के शीर्ष पर बनाए गए हैं। JSON-LD के प्राथमिक लाभों में से एक यह है कि आप अलग-अलग स्रोतों से डेटा मर्ज कर सकते हैं। दूसरा यह है कि आप मूल डेटा प्रारूप निर्दिष्ट कर सकते हैं और लोगों को आपके साथ समन्वय करते हुए प्रोटोकॉल का विस्तार करने की अनुमति दे सकते हैं (जो महत्वपूर्ण है यदि आप सिस्टम को एक घातीय दर से विकसित करना चाहते हैं)।

बस कुछ विचार, यदि आपके कोई प्रश्न हैं, तो कृपया पूछें। नेटवर्क पर प्रत्येक JSON ब्लॉब में @context की आवश्यकता एक भारी आवश्यकता नहीं है।

विचारों के लिए धन्यवाद!

हम इंटरनेट पर नामकरण को बदलने के लिए डीएचटी (कैडेलिया-जैसे) + डिजिटल हस्ताक्षर + क्वेरी नेटवर्क का उपयोग करने पर विचार कर रहे हैं (अंततः डीएनएस को बदलें)।

फिर पेपर में आईपीएनएस अनुभाग देखना सुनिश्चित करें: http://static.benet.ai/t/ipfs.pdf (3.7)। :)

क्या आप टेलीहैश के बारे में जानते हैं?

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

आप IPFS को Telehash + the (merkle) Web के रूप में देख सकते हैं।

यदि आप चाहते हैं कि नेटवर्क पर मेटाडेटा मशीन-पठनीय और संसाधित हो लेकिन एक्स्टेंसिबल तरीके से हो, तो आपको JSON-LD का उपयोग करना चाहिए।

मुझे लगता है कि हम परिवहन के रूप में JSON की आवश्यकता के बिना आपके काम का -LD भाग ले सकते हैं। यानी मुझे लगता है कि आपका (भयानक) काम किसी भी पेड़ डेटा संरचना के लिए सामान्यीकृत है, और अन्य अर्थपूर्ण वेब प्रारूपों से कहीं बेहतर है। (अद्भुत सादगी + लचीलापन!) तो मैं इन नोटों में जो इंगित कर रहा हूं वह @context के बराबर का उपयोग करता है लेकिन आईपीएफएस लिंक डेटास्ट्रक्चर में (जो जेएसओएन नहीं है, यह वस्तुओं के माध्यम से त्वरित खोज के लिए एक बाइनरी पैक प्रारूप है -- प्रोटोबफ आज, लेकिन बाद में स्व-वर्णन भी हो सकता है -- मेरा इरादा आईपीएफएस को डेटाबेस के रूप में काम करने के लिए पर्याप्त तेज़ होना है। आज नहीं, बल्कि भविष्य में :))।

नेटवर्क पर प्रत्येक JSON ब्लॉब में @context की आवश्यकता एक भारी आवश्यकता नहीं है।

हाँ, मैंने वही तर्क दिया है :)

@jbenet re: https://github.com/dataprotocols/dataprotocols/issues/110#issuecomment -43430309 - हाँ, मुझे लगा कि आपके तर्क बहुत अच्छे और अच्छी तरह से सूचित थे।

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

किसी भी मामले में, मुझे आपके द्वारा बनाई गई चीज़ों में जाने दें और फिर आपके पास वापस आएं। यदि आप सप्ताह के भीतर मुझसे नहीं सुनते हैं, तो कृपया मुझे फिर से पिंग करें।

अरे @jbenet , मुझे सप्ताहांत में श्वेतपत्र को और अधिक विस्तार से देखने के साथ-साथ आपकी प्रस्तुति देखने का मौका मिला। आइए इस आने वाले सप्ताह में बात करने के लिए एक समय निर्धारित करें। मैं पूर्वी तट पर हूँ, यू.एस. मंगल/बुध को छोड़कर अधिकांश दिनों में सुबह 10 बजे से दोपहर 2 बजे तक उपलब्ध। मेरा ईमेल: [email protected] , स्काइप: msporny, एसआईपी: सिप: [email protected] अपनी सुविधानुसार मुझसे संपर्क करें।

मैं ipns और इस wrt पर चर्चा करना चाहता हूँ। वेब, क्रेडेंशियल और वेब भुगतान पर लॉगिन करें: https://manu.sporny.org/2014/identity-credentials/

@msporny बढ़िया! करूंगा। आधार को छूने के लिए अभी एक ईमेल भेजा है। हो सकता है कि आप इस समस्या से अपने संपर्क विवरण निकालना चाहें (क्योंकि यह सार्वजनिक है, आदि)।

हम आज आईआरसी पर "यह किस तरह की वस्तु है" सवालों के जवाब देने के तरीके के बारे में सोच रहे थे। @jbenet ने LSON-LD शैली @type या @context लिंक का उल्लेख किया है, लेकिन मुझे यकीन नहीं है कि आप उस श्रृंखला से कैसे बाहर निकलते हैं । क्या यह @context सभी तरह से नीचे लिंक है? @ tv42 ने फ़ाइलनामों के साथ टकराव के बारे में भी चिंता जताई , क्योंकि निर्देशिका नोड्स चाइल्ड सेगमेंट नामों को अपनी चाबियों के रूप में उपयोग करते हैं। आप खंड नामों से पहले या अन्यथा बचकर इसके आसपास काम कर सकते हैं, लेकिन यह प्रकार विवरण के लिए हैश आईडी रखने के लिए केवल एक स्पष्ट प्रकार फ़ील्ड जोड़ने से अधिक काम की तरह लगता है। अगर हम इस तरह की और चीजों की अपेक्षा करते हैं, तो शायद यह लिंक को आंतरिक और बाहरी सेटों में विभाजित करने के लिए कहता है। आप किसी भी @context फ़ाइल प्रविष्टियों से @context प्रकार प्रविष्टि को अलग करने के लिए 'आंतरिक' बूलियन जोड़कर @jbenet के प्रस्तावित लिंक प्रोटोबफ एक्सटेंशन दृष्टिकोण (यदि वह एक चीज़ बन जाती है) के साथ ऐसा कर सकते हैं ( उदाहरण के लिए)।

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

एक ipfs ऑब्जेक्ट जेसन या कुछ और जैसा पेड़ है। इसका मतलब है कि JSON (JSON-LD, JSON-schema, इत्यादि सहित) के लिए उपलब्ध सभी समाधान IPFS के लिए उपलब्ध हैं। इसके अलावा, आरडीएफ ट्रिपल को आईपीएफ ऑब्जेक्ट्स के रूप में प्रस्तुत करना तुच्छ है। इसलिए, आप कुछ भी और सब कुछ कर सकते हैं।

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

अब, _preferred_ तरीका -- जिस तरह से हम लोगों को काम करने का सुझाव देंगे -- संभवतः JSON-LD से @context / @type होगा।

लेकिन मुझे यकीन नहीं है कि आप उस श्रृंखला से कैसे टूटते हैं

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

@ tv42 ने फ़ाइल नामों के साथ टकराव के बारे में भी चिंता जताई, क्योंकि निर्देशिका नोड्स चाइल्ड सेगमेंट नामों को अपनी कुंजी के रूप में उपयोग करते हैं।

यदि एक डीआईआर डेटास्ट्रक्चर में पहले से ही @context है तो यह किसी अन्य फ़ाइल के निर्माण की अनुमति नहीं देगा-- (या सबसे खराब, (स्थिर सॉर्ट) के बाद लिंक संलग्न करें)। यह एक ही नाम से दो फाइलें बनाने की कोशिश करने जैसा ही है।

शुक्र, 01 मई, 2015 को 03:51:22 पूर्वाह्न -0700 पर, जुआन बतिज़-बेनेट ने लिखा:

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

लिंक एक्सटेंशन ठीक काम करना चाहिए। और लिंक कुंजियों को उपसर्ग कर रहा है
नामस्थान उन्हें इतना बुरा नहीं है। प्रकार की जानकारी भरना
डेटा में भी काम करता है (इस तरह फाइलें और निर्देशिका अब काम करती हैं
[1,2,3,4,5])। गणना प्रकार एक स्थायी दृष्टिकोण नहीं है, लेकिन
इनमें से कोई भी स्थान एक प्रकार के हैश को स्टोर करने के स्थान के रूप में काम करेगा।

अब, _पसंदीदा_ तरीका -- जिस तरह से हम लोगों को काम करने का सुझाव देंगे
-- से @context / @type होने की संभावना है
(आश्चर्यजनक रूप से शक्तिशाली और सरल) JSON-LD।

JSON-LD ठीक है, लेकिन इसके आसपास के पारिस्थितिकी तंत्र को समझना होगा
कि @-उपसर्ग विशेष है। मैं पसंद करूंगा कि स्पेशल-नेस को स्टोर किया जाए
अतिरिक्त डेटा के साथ लिंक प्रविष्टियों को स्पष्ट रूप से विस्तारित करके (उदाहरण के लिए a
आंतरिक/बाहरी ध्वज) इसलिए हमारे पास @ संदर्भ . के बीच अस्पष्टता नहीं है
फ़ाइल और एक @context प्रकार का लिंक। लेकिन अगर सभी फाइल/उपदिर लिंक कुंजीबद्ध हैं
बच्चे के साथ/', तो आपके पास प्रकार के लिए 'संदर्भ' हो सकता है
फ़ाइल (या जो कुछ भी) के लिए लिंक और 'बच्चा/संदर्भ'। यह अभी भी चल रहा है
एक बाहरी रूप से परिभाषित सम्मेलन होना चाहिए जो जनरेटर को ऑब्जेक्ट करता है
और उपभोक्ताओं को एक गैर-स्व-वर्णन चैनल के माध्यम से सहमत होने की आवश्यकता है।

लेकिन मुझे यकीन नहीं है कि आप उस श्रृंखला से कैसे टूटते हैं

मैं सवाल नहीं समझता। कोई जंजीर नहीं है, आप संकल्प करें
संदर्भ एक बार और बस इतना ही। यह संदर्भ फ़ाइल के लिए है
वस्तु। यदि यह एक मान्य संदर्भ नहीं है -- एक युक्ति है -- you
इसे नजरअंदाज करो।

ये मेरे लिए सही है। मैं सोच रहा था कि आप आत्म-वर्णन कैसे समाप्त करते हैं
जंजीर:

ए किस प्रकार का है? आइए बस A/ @context से B का अनुसरण करें। B किस प्रकार का है?
आइए बस B/ @context से C का अनुसरण करें…

लेकिन अगर आप बी स्पेक (मेरे उदाहरण में सी) वितरित कर रहे हैं, तो नहीं
B/ @context लिंक की आवश्यकता है। लेकिन अगर आपके पास के लिए एक चैनल है
टाइप स्पेक (सी) वितरित करना, इसे वितरित करने के लिए इसका उपयोग क्यों न करें
स्कीमा स्वयं टाइप करें (बी)? ऐसा लगता है कि बस एक होना ही बेहतर है
वस्तुओं में पारंपरिक स्थान जिसमें उनका वर्णन करने वाला एक मल्टीहैश होता है
टाइप करें (आपका @context लिंक, या जो भी हो)। फिर रास्ते से हट जाओ और
यह तय करने के लिए निर्माता/उपभोक्ता समुदायों पर छोड़ दें कि क्या यह है
एक प्रकार की परिभाषा के संदर्भ में (शायद कल्पना सी, या सीवी 2 के तहत, या
वैकल्पिक CCv1.3, या…) या यदि वे केवल मल्टीहैश का उपयोग करना चाहते हैं
एक अपारदर्शी पहचानकर्ता। तब आप अभी भी चीजें कर सकते हैं जैसे:

स्विच पीबीएन.गेट टाइप () {
मामला ft.Tनिर्देशिका:
root.val = NewDirectory (pointsTo.String (), mnode, root, fs)

यह सिर्फ इतना है कि GetType @context लिंक हैश (या .) को पकड़ लेगा
जहाँ भी), और TDirectory एक मल्टीहैश होगा
(QmWellKnownDirectoryType)।

अनुप्रयोगों को इन प्रकारों के सही होने पर _निर्भर_ नहीं होना चाहिए, लेकिन
बल्कि जब वे हों तो उनका लाभ उठाएं।

यह एक अपारदर्शी पहचानकर्ता की तरह लगता है। शायद हम भी यही कह रहे हैं
चीज़ ;)।

@tv42 ने फ़ाइल नामों के साथ टकराव के बारे में भी चिंता जताई, क्योंकि
निर्देशिका नोड चाइल्ड सेगमेंट नामों को अपनी कुंजियों के रूप में उपयोग करते हैं।

अगर एक डीआईआर डेटास्ट्रक्चर में पहले से ही @context है तो यह अनुमति नहीं देगा
दूसरी फ़ाइल का निर्माण-- (या कम से कम, बाद में लिंक संलग्न करें
(स्थिर प्रकार))। यह दो फाइलों को बनाने की कोशिश करने जैसा ही है
एक ही नाम।

यह है अगर आप @context फ़ाइलों को अवैध बनाना चाहते हैं;)। यदि आप चाहते हैं
लोगों को @context फ़ाइलें बनाने की अनुमति दें, आपको किसी तरह की आवश्यकता होगी
"यह लिंक एक प्रकार पर इंगित करता है" और "यह लिंक" के बीच स्पष्ट करें
एक फ़ाइल/उपनिर्देशिका/…” पर इंगित करता है। लेकिन कई तरीके हैं
उस समस्या के आसपास, इसलिए जब तक हम उनमें से किसी एक को चुनते हैं, मुझे खुशी होगी
;).

मैंने कई दिनों पहले @cryptix के साथ बातचीत की थी और हमने संक्षेप में JSON-LD का उपयोग करने के बारे में बात की थी। मैं केवल यह बताना चाहूंगा कि json-ld के लिए कल्पना एक "लिंक" के उपयोग की अनुमति देता है जो कि json से json-ld में मैपिंग का वर्णन करता है। मैं व्यक्तिगत रूप से इस दृष्टिकोण को पसंद करता हूं क्योंकि यह मेटाडेटा को बिना पुनर्गठन के json-ld के अनुरूप होने की अनुमति देता है, जो कि RDF का जो भी स्वाद वर्तमान में "हिप" है।

http://www.w3.org/TR/json-ld/#interpreting -json-as-json-ld

शुक्र, 01 मई, 2015 को 09:24:27 अपराह्न -0700 पर, डब्ल्यू ट्रेवर किंग ने लिखा:

लिंक एक्सटेंशन ठीक काम करना चाहिए। और लिंक कुंजियों को उपसर्ग कर रहा है
नामस्थान उन्हें इतना बुरा नहीं है। प्रकार की जानकारी भरना
डेटा में भी काम करता है (इस तरह फाइलें और निर्देशिका अब काम करती हैं
[1,2,3,4,5])। गणना प्रकार एक स्थायी दृष्टिकोण नहीं है, लेकिन
इनमें से कोई भी स्थान एक प्रकार के हैश को स्टोर करने के स्थान के रूप में काम करेगा।

संबंधित नोट पर (हैशेड टाइप आईडी के साथ-साथ वितरित करना
पेलोड), @ tv42 ने अभी मेरा ध्यान एथोस ईटाइप्स [1,2,3] की ओर दिलाया। इसलिए
मुझे लगता है कि इन चीजों के लिए किसी प्रकार का स्पष्ट स्लॉट होना होगा
महान।

ETypes नहीं देखा है, सरफेसिंग के लिए धन्यवाद। अगले दो दिनों में पढ़ेंगे। कुछ प्रासंगिक है कैथलीन फिशर का PADS कार्य + संबंधित। ऐसा लगता है कि PADS प्रोजेक्ट पेज हाल ही में बदल दिया गया है (यदि केवल वेब की कुछ सामग्री-संबोधित अपरिवर्तनीय स्टोर थी ...) (लेकिन इंटरनेट संग्रह ने हमें फिर से \o/: http://web.archive.org/web/20130125041549/http://www.padsproj.org/ बचा लिया है)

• PADS: तदर्थ डेटा को संसाधित करने के लिए एक डोमेन-विशिष्ट भाषा
• पैड परियोजना: एक सिंहावलोकन
• PADS/T: तदर्थ डेटा का वर्णन करने और बदलने के लिए एक भाषा
• पैड/एमएल: एक कार्यात्मक डेटा विवरण भाषा
• LearnPADS: तदर्थ डेटा से स्वचालित उपकरण निर्माण
• अधिक पेपर: http://web.archive.org/web/20120205185831/http :// www.padsproj.org/doc.html#papers

वैसे भी, पैड के पास बहुत सही विचार है। लेकिन अभी तक व्यापक कार्यान्वयन नहीं देखा है, जिसके बारे में मुझे पता है। शायद JSON-LD की शैली में कुछ ऐसा है जो इसे यहां ठीक कर सकता है।

JSON-LD केवल @context लिंक जोड़ने के बारे में नहीं है। विशेष रूप से, प्रत्येक लिंक नाम (JSON में कुंजी) इन श्रेणियों में से एक में आना चाहिए:

• @context : डेटा का वर्णन करने वाला संदर्भ लिंक या इनलाइन नोड
• @id : वर्तमान नोड का यूआरआई
• योजना: // पूर्ण-उरी : एक लिंक के रूप में पहचाना जाता है जिसका विधेय यूआरआई है
• उपसर्ग: नाम : एक लिंक के रूप में पहचाना जाता है जिसका विधेय उपसर्ग यूआरआई (संदर्भ में परिभाषित) और नाम का संयोजन है
• नाम: संदर्भ में परिभाषित होने पर ही लिंक के रूप में पहचाना जाता है

विशेष रूप से, JSON-LD मनमाने ढंग से कुंजी/मान मानचित्रों का समर्थन नहीं करता है। यदि कुंजी को यूआरआई के रूप में व्याख्या किया जा सकता है, तो इसे इस यूआरआई का उपयोग करके एक विधेय माना जाएगा। उदाहरण के लिए, निम्नलिखित अमान्य है:

{
  "http://xmlns.com/foaf/0.1/name": "<!DOCTYPE html><html><body><p>Hello World</p></body></html>"
}

जैसा कि http://xmlns.com/foaf/0.1/name हमेशा एक FOAF नाम को संदर्भित करेगा, न कि किसी वेब पेज का कैश्ड संस्करण।

यह आवश्यक रूप से एक समस्या नहीं है, लेकिन यदि हम ऑब्जेक्ट स्वरूपों को डिज़ाइन करते समय लिंक को लिंक किए गए डेटा के रूप में व्याख्या करने का निर्णय लेते हैं, तो इस पर विचार किया जाना चाहिए। उदाहरण के लिए, JSON-LD का उपयोग करके एक निर्देशिका को इस तरह दर्शाया जा सकता है:

{
  "@context": {
    "entry": {
      "@id": "http://schema/unixfs#entry",
      "name": "http://schema/unixfs#filename",
      "content": {
        "@id": "http://schema/unixfs#filename",
        "@type": "@id"
      }
    }
  },
  "entry": [
    {
      "name": "README.md"
      "content": "/ipfs/<hash-of-README.md>"
    }
  ]
}

आईपीएफएस-एलडी में हमारे पास निर्देशिका के लिए एक नोड होगा, जो एक संदर्भ से जुड़ा होगा और प्रत्येक प्रविष्टि के लिए एक नोड होगा। तब प्रत्येक प्रविष्टि में उनके स्वयं के संदर्भ के लिंक होंगे, एक नोड जिसमें उनका नाम होगा और फ़ाइल सामग्री वाला एक नोड होगा।

यह संकेत के कई स्तरों को जोड़ता है, जो JSON दस्तावेज़ों के लिए स्वीकार्य हैं (क्योंकि सब कुछ एक फ़ाइल में पैक किया गया है) लेकिन IPFS के लिए स्वीकार्य नहीं हो सकता है जहाँ प्रत्येक नोड का एक अलग हैश होता है और इसे अलग से ट्रैक किया जाना चाहिए।

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

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

यूनिक्स के लिए, मैं निम्नलिखित वस्तुओं की कल्पना करूंगा:

• directory :
  
  
  
  • लिंक @context निर्देशिका-संदर्भ की ओर इशारा करते हुए
  
  
  • लिंक entry:README.md README.md ऑब्जेक्ट की ओर इशारा करते हुए
  
  
  • कोई डेटा नहीं
  
  
• README.md :
  
  
  
  • लिंक @context फ़ाइल-संदर्भ की ओर इशारा करते हुए
  
  
  • README.md . की सामग्री के साथ डेटा अनुभाग
  
  
• निर्देशिका-संदर्भ:

```
{
// @ प्रकार: IPFS ऑब्जेक्ट का प्रकार
"@type": " http://schema/unixfs#Directory "

// entry: declares the links starting with "entry:"
//   <strong i="38">@id</strong>: the relationship with the pointed object
//   <strong i="39">@key</strong>: the relationship with the link name suffix (after ':')
"entry": {
  "@id": "http://schema/unixfs#containsEntry",
  "@key": "http://schema/unixfs#hasFilename"
}

}
```

• फ़ाइल-संदर्भ:

```
{
"@type": " http://schema/unixfs#File "

// <strong i="50">@data</strong>: the relationship with the data section of the object
"@data": "http://schema/unixfs#content"

}
```

यदि हम इसे त्रिक में प्रस्तुत करना चाहते हैं, तो हमारे पास होगा:

# Contained in directory object:
<hash of directory>        <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema/unixfs#Directory>
<hash of directory>        <http://schema/unixfs#containsEntry>              <hash of README.md object>
<hash of README.md object> <http://schema/unixfs#hasFilename>                "README.md"

# Contained in README.md object:
<hash of README.md object> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema/unixfs#File>
<hash of README.md object> <http://schema/unixfs#content>                    DATA SECTION of README.md

अरे @ मिल्ड्रेड - महान विश्लेषण। मजे की बात है कि मैं irc://irc.frennode.org#json -ld में dlongley के साथ बातचीत में उसी निष्कर्ष पर पहुंचा (यदि रुचि हो तो आप लॉग भेज सकते हैं)

मैं यहाँ एक अधिक अनुमेय IPLD प्रकार की चीज़ के साथ थोड़ा प्रयोग कर रहा हूँ - विशेष रूप से उदाहरण देखें। ये अंतिम नहीं हैं (या सही?), लेकिन दिशा की भावना देते हैं

• https://github.com/ipfs/go-ipld
• https://github.com/ipfs/go-ipld/issues/1
• https://github.com/ipfs/go-ipld/blob/master/ipld.go#L57 -L89
• https://github.com/ipfs/go-ipld/blob/master/examples/commit/commit.go#L10 -L15 ( @value के उपयोग पर ध्यान न दें, यह गलत है)
• https://github.com/ipfs/go-ipld/blob/master/examples/sig/sig.go#L14 -L16
• https://github.com/ipfs/go-ipld/blob/master/examples/unixfs/unixfs.go#L16 -L18

महत्वपूर्ण लेख:

• अन्य मूल्यों को शामिल करने के लिए _allow_ के लिए आरामदेह लिंक (बहुत अनुरोध किया गया), हम केवल {"@type": "mlink", "hash": "<multihash>"} . आरक्षित करते हैं
• उपयोगकर्ता अपने डेटा संरचनाओं के लिए संदर्भों को परिभाषित कर सकते हैं
• _nest_ लिंक कर सकते हैं, ट्रैवर्स के लिए पथ संकेतन का उपयोग कर सकते हैं जैसे https://github.com/ipfs/go-ipld/blob/master/ipld.go#L122 -L141

मुझे लगता है कि आप और मैं बहुत सही रास्ते पर हैं। मुझे यह भी लगता है कि हम शायद JSON-LD से ज्यादा विचलित हुए बिना इसमें से बहुत कुछ कर सकते हैं। केवल कुछ प्रतिबंधों को छोड़ना

@माइल्ड्रेड यहाँ लॉग करता है

यह भी कहना चाहिए कि - dlongley के साथ मेरी बातचीत से - JSON-LD मानक से तकनीकी रूप से विचलित हुए बिना हम जो चाहते हैं वह करना संभव होना चाहिए, बस _रूपांतरण (संघनन/विस्तार)_ को कॉल करने से सभी "गैर -संदर्भ-परिभाषित" कुंजी। (हमें प्रयास करना चाहिए कि हम विचलित न हों)

मुझे लगता है कि आप JSON-LD के बारे में सोचकर बहुत भ्रम को दूर करेंगे, बजाय इसके कि JSON को बदलने में json-ld.js पार्सर क्या करता है। JSON परिवर्तन चरण उस पार्सर के लिए विशिष्ट है और आप बिना किसी समस्या के इसे आसानी से दूसरे तरीके से बदलने की कल्पना कर सकते हैं।

अब, अगर मैं अच्छी तरह से समझता हूं कि आप go-ipld के साथ क्या कर रहे हैं, तो यह वर्तमान IPFS ऑब्जेक्ट में लिंक अनुभाग को बदल सकता है, है ना? यह बात: merkledag.proto

मुझे वहां एक समस्या दिखाई दे रही है। जहां पहले हमारे पास एक सरल संरचना थी जो कुशल प्रसंस्करण (लिंक नाम, सीधे पथ से संबंधित, और लिंक हैश) की अनुमति देती थी, अब हमारे पास थोड़ी अधिक जटिल संरचना है। लिंक किए गए हैश पर जाने के लिए, आपको हैश तालिका में स्ट्रिंग "mlink" को हल करना होगा। क्या यह सचमुच आवश्यक है?

यदि आप लिंक किए गए डेटा / आरडीएफ चाहते हैं, तो क्यों न केवल अपने स्वयं के वायर प्रारूप को परिभाषित करें (जहां तक ​​​​मेरा संबंध है, प्रोटोबफ बहुत अच्छा है) और जिस तरह से इसका JSON में अनुवाद किया जा सकता है। फिर उसके ऊपर JSON-LD संदर्भ का उपयोग करें।

अब, आप जिस अलग डेटा संरचना के बारे में सोच रहे थे, मुझे लगता है कि वे महान हैं, यूनिक्स के अपवाद के साथ: हमारे पास JSON-LD कुंजी के रूप में फ़ाइल नाम नहीं हो सकते हैं क्योंकि JSON-LD कुंजियों को सभी परिस्थितियों में RDF विधेय को संदर्भित करना चाहिए। एक फ़ाइल नाम एक शाब्दिक मूल्य है।

के बजाय:

{
  "@context": "/ipfs/Qmf1ec6n9f8kW8JTLjqaZceJVpDpZD4L3aPoJFvssBE7Eb/merkleweb",
  "foo": {
    "@type": "mlink",
    "@value": <multihash>,
    "unixType": "dir",
    "unixMode": "0755",
  },
  "bar.jpeg": {
    "@type": "mlink",
    "@value": <multihash>,
    "unixType": "file",
    "unixMode": "0644",
  }
}

मैं इसे इस प्रकार मॉडल करूंगा:

{
  <strong i="16">@context</strong>: {
    "ipfs":   "tag:ipfs.io,2015:ipfs:"
    "unixfs": "tag:ipfs.io,2015:unixfs:"
  }
  <strong i="17">@type</strong>: "unixfs:directory"
  "unixfs:contains": [
    {
      "@id":   "ipfs://<IPFS Hash>"
      "@type": ["unixfs:directory"]
      "unixfs:name": "foo"
      "unixfs:mode": "0755"
    },
    {
      "@id":   "ipfs://<IPFS Hash>"
      "@type": ["unixfs:file"]
      "unixfs:name": "bar.jpeg"
      "unixfs:mode": "0644"
    }
  ]
}

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

DIRECTORY              <tag:ipfs.io,2015:unixfs:contains> <ipfs://Hash:foo>
DIRECTORY              <tag:ipfs.io,2015:unixfs:contains> <ipfs://Hash:bar.jpeg>
<ipfs://Hash:foo>      <strong i="21">@type</strong>                              <tag:ipfs.io,2015:unixfs:directory>
<ipfs://Hash:foo>      <tag:ipfs.io,2015:unixfs:name>     "foo"
<ipfs://Hash:foo>      <tag:ipfs.io,2015:unixfs:mode>     "0755"
<ipfs://Hash:bar.jpeg> <strong i="22">@type</strong>                              <tag:ipfs.io,2015:unixfs:file>
<ipfs://Hash:bar.jpeg> <tag:ipfs.io,2015:unixfs:name>     "bar.jpeg"
<ipfs://Hash:bar.jpeg> <tag:ipfs.io,2015:unixfs:mode>     "0644"

मैं आईआरसी पर हूं, मुझे वहां पिंग करने में संकोच न करें।

इस धागे पर RDF से अपरिचित लोगों के लिए, यहाँ एक छोटी सी व्याख्या है:

RDF आपके डेटा की संरचना करने का एक तरीका है। यह JSON-LD के पीछे डेटा मॉडल है। RDF में, सभी डेटा को ट्रिपल में एन्कोड किया जाना चाहिए:

<subject> <predicate> <object>

• विषय एक नोड है जिसे यूआरआई द्वारा पहचाना जाता है
• विधेय एक यूआरआई है जैसे <http://www.w3.org/1999/02/22-rdf-syntax-ns#name> । यूआरआई विशिष्ट रूप से रिश्ते को परिभाषित करता है, और अधिमानतः एक कल्पना या स्कीमा में अच्छी तरह से परिभाषित किया जाना चाहिए।
• वस्तु लिंक/विधेय का लक्ष्य है। यह एक शाब्दिक मान हो सकता है (एक स्ट्रिंग, जिसे वैकल्पिक रूप से टाइप किया जा सकता है, उदाहरण के लिए एक पूर्णांक या दिनांक के रूप में, आमतौर पर xsd स्कीमा से प्राप्त) या यह एक अन्य नोड हो सकता है, जिसे इसके यूआरआई द्वारा पहचाना जाता है

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

JSON-LD में JSON कुंजियाँ विधेय हैं जो विषय (वस्तु जिसमें कुंजी मौजूद है) और वस्तु को जोड़ती है: JSON-LD कुंजी का मान। इस मामले में, विषय और वस्तु को संदर्भित करने के लिए यूआरआई का उपयोग नहीं किया जाता है। यदि आप किसी ऑब्जेक्ट का यूआरआई निर्दिष्ट करना चाहते हैं जिसका उपयोग इसे संदर्भित करने के लिए किया जा सकता है, तो @id प्रॉपर्टी है।

क्या आईपीएफएस पर लिंक किया गया डेटा HTTP पर काम करने की तुलना में कैसे काम करता है, यह बताते हुए कहीं भी लिखा गया है? (यूआरआई क्या हैं? आईपीएफएस पर लिंक्ड डेटा के प्रकाशकों और उपभोक्ताओं के लिए सर्वोत्तम अभ्यास क्या होने चाहिए?)

देखो:

• https://github.com/ipfs/specs/pull/37
• https://github.com/ipfs/specs/blob/ipld-spec/merkledag/ipld.md

IPLD आपको json डेटा मॉडल देता है। आप IPLD के ऊपर किसी भी JSON-LD को लेयर कर सकते हैं।

(अभी तक नहीं उतरा)

@jbenet बस इस धागे के माध्यम से पढ़ें, लिंक किए गए डेटा का उपयोग करना एक महान पहल है IMHO

आप सही हैं कि लिंक्ड डेटा किसी एक क्रमांकन को अनिवार्य नहीं करता है। JSON-LD, RDF/XML, RDFa, टर्टल या अन्य प्रारूपों के समूह का उपयोग करना संभव है

लिंक्ड डेटा की क्या आवश्यकता है कि JSON में कुंजियाँ URI हैं। यह उन्हें urn:string:<key> के साथ उपसर्ग करने जितना आसान हो सकता है, जिसके लिए, यदि JSON-LD का उपयोग संदर्भ में एक लाइनर के रूप में किया जा सकता है, या स्पष्ट रूप से लिखा जा सकता है।

एक अन्य (आम तौर पर पसंदीदा) तरीका यह होगा कि वे कुंजी के लिए शब्दों को http(s) या ipfs: दस्तावेज़ में रखें जिसमें प्रत्येक शब्द के लिए मानव पठनीय विवरण हों।

मुझे लगता है कि लिंक्ड डेटा में लिखे गए आईपीएफएस हैश के लिए मेटा डेटा भी दिलचस्प है। मैंने आज कछुए में इसका एक त्वरित प्रयास किया, RFC6920 में उल्लिखित पैटर्न का पुन: उपयोग किया:

<ni:///multihash;QmZvTvRQ2voimuYwBtKsyMqMqirDt5Xrq4sdow2RM5ynKj> 
    <https://schema.org/sameAs> 
        <https://gateway.ipfs.io/ipfs/QmZvTvRQ2voimuYwBtKsyMqMqirDt5Xrq4sdow2RM5ynKj> ,
        <http://ia801506.us.archive.org/3/items/NodeUp114/NodeUp%20114.mp3> ,
        <ipfs:/ipfs/QmZvTvRQ2voimuYwBtKsyMqMqirDt5Xrq4sdow2RM5ynKj> ;
    <https://schema.org/contentType>
        "audio/mpeg" ;
    <https://schema.org/title>
        "NodeUp: A Node.js Podcast - Episode 114 - Internationalization Deep Dive" .

https://namedinstance.com/.well-known/ni/multihash/QmZvTvRQ2voimuYwBtKsyMqMqirDt5Xrq4sdow2RM5ynKj

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

(एक rdfhead के रूप में, मैं कछुए को एक प्रारूप के रूप में पसंद करता हूं क्योंकि मुझे यह सरल और शक्तिशाली लगता है लेकिन आप निश्चित रूप से JSONLD का उपयोग कर सकते हैं)

/मैं http://static.benet.ai/t/ipfs.pdf पढ़ने के लिए static.benet.ai से कनेक्ट नहीं हो सकता

@timbl आप यहाँ IPFS पेपर का अधिक अप-टू-डेट संस्करण पा सकते हैं: https://github.com/ipfs/papers/blob/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf या सार्वजनिक आईपीएफएस गेटवे के माध्यम से एक ही पेपर: https://ipfs.io/ipfs/QmV9tSDx9UiPeWEExXEeH6aoDvmihvx6jD5eLb4jbTaKGps

उदाहरण के लिए, आप दावा कर सकते हैं कि एक स्थान में कुछ वैसा ही है जैसा कि दूसरे में है।

हां! ये सभी समान हैं:

• dweb:/ipfs/somehash
• ipfs: //somehash
• https://dweb.link/ipfs/somehash

इसके बारे में क्षमा करें, dweb: URI योजना और https://dweb.link वास्तव में अभी तक काम नहीं करते हैं।

अभी के लिए यह URI के लिए fs:/ipfs/somehash है (IPFS गेटवे रीडायरेक्ट एडऑन में) और HTTP के लिए https://ipfs.io/ipfs/somehash :

• ipfs: //somehash
• fs:/ipfs/somehash
• https://ipfs.io/ipfs/somehash

अगर इस धागे पर लोगों ने इसे याद किया, तो ऐसा हुआ!

https://ipld.io/

आइए https://github.com/ipld/ipld . पर बातचीत जारी रखें

ज़रूर। लिंक किए गए डेटा के पहलुओं पर चर्चा करने के लिए बेझिझक यहां जाएं:

https://gitter.im/linkeddata/chat

@nicola मुझे यकीन है कि उस चैनल के लिए कोई अजनबी नहीं है

हम वास्तव में आज अपने सिस्टम में ipfs: URI जोड़ने पर चर्चा कर रहे थे। आईपीएल के साथ शुभकामनाएँ!

किसी ऐसी चीज़ के लिए जो स्पष्ट रूप से LD नहीं है, अच्छी तरह से परिभाषित शब्द "लिंक्ड डेटा" का उपयोग क्यों करें?
https://www.w3.org/standards/semanticweb/data

इसलिए, मुझे पता है कि यह एक पुराना धागा है, लेकिन मैं खुद को भावी पीढ़ी के लिए मिला रहा हूं।

मैं सत्यापन योग्य क्रेडेंशियल डेटा मॉडल (https://w3c.github.io/vc-data-model/) पर काम कर रहा हूं और JSON-LD बनाम IPLD में दर्शाए गए @context को समेटने में कुछ समस्याएं आई हैं। (देखें: https://github.com/w3c/vc-data-model/pull/261)। मैं पहचान सकता हूं कि JSON-LD पूरी तरह से IPLD के साथ संगत है, लेकिन IPLD JSON-LD के साथ पूरी तरह से पीछे की ओर संगत नहीं है, जो मौजूदा विनिर्देशों के साथ इंटरऑपरेबिलिटी के लिए आवश्यक होगा। जैसा कि मैंने इसे देखा, समाधान आईईटीएफ में एक वैध योजना के रूप में ipld: जोड़ना होगा (देखें: https://github.com/ipld/specs/issues/98 ) फिर { <attr> : ipld:<cid> } के लिए अनुमति दें { "/" : <cid> } IPLD में हासिल करता है (देखें: https://github.com/ipld/specs/issues/99)। प्रोटोकॉल को परिभाषित करने वाले प्रकार को घोषित करने के लिए application/ipld के MIME सामग्री-प्रकार को भी पंजीकृत करें। यह भ्रम को कम करने के लिए application/json+ipld बनाम application/cbor+ipld की अनुमति देने के लिए मिश्रित होगा। ( @mildred मुझे ipfs पसंद नहीं है: // इसके लिए हमें प्राकृतिक लिंकिंग और `{"@context" : "/ipfs/" }' एक मान्य यूआरआई है )

सिमेंटिक इंटरऑपरेबिलिटी के लिए, मैं आईपीएलडी के शीर्ष पर जेएसओएन-एलडी संदर्भ ले रहा हूं। हालांकि, यह एक मूल समस्या हो जाती है, आसानी से JSON-LD में मान्य मानों के रूप में URI को एम्बेड करने के साथ हल हो जाती है।

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

(एक rdfhead के रूप में, मैं कछुए को एक प्रारूप के रूप में पसंद करता हूं क्योंकि मुझे यह सरल और शक्तिशाली लगता है लेकिन आप निश्चित रूप से JSONLD का उपयोग कर सकते हैं)

इसका एक आदर्श उदाहरण https://w3id.org/did/v1 पर सत्यापन योग्य क्रेडेंशियल के लिए @context में डेटाटाइम की हैंडलिंग है जो xsd:datetime से लिंक करता है जो http://www.w3.org/ को संदर्भित करता है। html में है।

इस एक्सएमएल में मेरा पसंदीदा एनोटेशन है:

पहले बिल्ट-इन आदिम डेटाटाइप। ये परिभाषाएँ केवल जानकारी के लिए हैं, वास्तविक अंतर्निहित परिभाषाएँ जादू हैं।

मैं इस जादू के साथ काम कर सकता हूं, जब तक हम स्वीकार करते हैं कि स्टैक के निचले भाग में: कछुआ:>: कछुआ:>: कछुआ: हम मानते हैं कि यह @timbl है और फिर हम JSON-LD के साथ पीछे की संगतता का उपयोग कर सकते हैं उपरोक्त ipld: के साथ।

@jonnycrunch मैं आपके विचारों का समर्थन करता हूँ। कछुआ सबसे लोकप्रिय नहीं है, क्योंकि JSON वेब पर काफी अच्छी तरह से स्थापित है, विशेष रूप से JSON ब्राउज़र के मूल निवासी है, और इसमें सीखने की अवस्था उथली है।

एक व्यापक देव समुदाय से अपील करने और एक ऐसी प्रणाली होने के बीच संतुलन होना चाहिए जो इंटरऑपरेबल हो (कुछ ऐसा नहीं जो काला और सफेद हो) और समृद्ध हो।

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

अंततः भ्रम पैदा होता है कि यूआरआई दोनों नाम (यूयूआईडी) और लोकेटर (प्रोटोकॉल) हैं और मस्तिष्क आसानी से दोनों के बारे में एक साथ नहीं सोचता है। यदि हम उस बिंदु तक पहुँच सकते हैं जहाँ हम अपने JSON की कुंजियों में URI या URI के लिए शॉर्टहैंड का उपयोग कर रहे हैं, तो इनमें से कई समस्याएं दूर हो जाती हैं। वास्तव में नामकरण के रूप में ipfs: और http: एक सहकारी नेटवर्क का हिस्सा बनना चाहिए, जिसमें लिंक किए गए डेटा एक प्रकार के गोंद के रूप में होते हैं।

मैंने सिंटैक्स का उपयोग करने के लिए अपनी टिप्पणी को अपडेट किया ipld:<cid> यह महसूस करते हुए कि यह गैर-आधिकारिक है और इस प्रकार ipld:// डबल स्लैश // के योग्य नहीं है। चूंकि पेलोड स्व-वर्णन कर रहा है, यह उसका अपना अधिकार है और उसे अपने दम पर खड़ा होना चाहिए। लेकिन यह विशेषज्ञों के लिए एक तर्क है।

@jonnycrunch ने लिखा:

समाधान यह होगा कि आई.पी.डी. को जोड़ा जाए: आईईटीएफ में एक वैध योजना के रूप में

मैं इस दृष्टिकोण का बहुत समर्थन करता हूं और सोचता हूं कि यह (अधिक पारंपरिक) लिंक्ड डेटा समुदाय और आईपीएफएस/आईपीएलडी समुदाय के बीच एक महान इंटरऑप कहानी को जन्म देगा।