Ipfs: IPFS-LD - البيانات المرتبطة

مرحبًا jbenet ، عمل رائع مع IPFS ، مهتم جدًا بما تفعله لأننا نتطلع إلى استخدام DHTs (مثل Kademlia) + التوقيعات الرقمية + شبكة الاستعلام لاستبدال التسمية على الإنترنت (استبدل DNS في النهاية). العمل الأساسي الذي نقوم به قريب مما تفعله مع IPFS: https://manu.sporny.org/2014/identity-credentials/ . نحن نستخدم JSON-LD لهذه المبادرة ، هل أنت على علم ب Telehash؟ إذا لم يكن الأمر كذلك ، فيجب عليك إلقاء نظرة لأن بعض هذه المفاهيم قد تعزز IPFS.

في أي حال ، إذا كنت تريد أن تكون البيانات الوصفية على الشبكة قابلة للقراءة آليًا وقابلة للمعالجة ولكن بطريقة قابلة للتوسيع ، فيجب عليك استخدام JSON-LD. إذا كنت تستخدم JSON-LD ، فهناك فرصة جيدة لتكامل أعمال Web Payments وبيانات الاعتماد التي تحدث في W3C لأن مجموعتي العمل هاتين مبنيتان أيضًا على JSON-LD. تتمثل إحدى الفوائد الأساسية لـ JSON-LD في أنه يمكنك دمج البيانات من مصادر مختلفة. آخر هو أنه يمكنك تحديد تنسيق البيانات الأساسي والسماح للأشخاص بتوسيع البروتوكول بدون التنسيق معك (وهو أمر مهم إذا كنت تريد أن ينمو النظام بمعدل أسي).

فقط بعض الأفكار ، إذا كانت لديك أسئلة ، يرجى طرحها. إن طلب context في كل كائن JSON blob على الشبكة ليس مطلبًا ثقيلًا.

شكرا على الأفكار!

نحن نبحث في استخدام DHTs (مثل Kademlia) + التوقيعات الرقمية + شبكة الاستعلام لاستبدال التسمية على الإنترنت (استبدل DNS في النهاية).

ثم تأكد من رؤية قسم IPNS في الورقة: http://static.benet.ai/t/ipfs.pdf (3.7). :)

هل تعلم من Telehash؟

نعم ، أوافق بشدة على المفهوم العام + الدافع لبنائه ، لكنني لا أؤيد العديد من قرارات المشروع. مثال على ذلك ، سطر الوصف هو "JSON + UDP + DHT = Freedom" لكنني أعتقد أن هذه الأنواع من الأنظمة يجب (أ) ألا تفرض تنسيق بيانات ، (ب) لا تفرض بروتوكول نقل ، و (ج) لا تفرض نظام التوجيه. بالطبع ، هذه الخيارات الثلاثة هي خيارات رائعة اليوم ، ولكن يجب إنشاء هذه البروتوكولات لتلائم الطبقات وعبر الوقت. وبالتالي يتيح IPFS للمستخدمين استخدام أي تنسيق يرغبون فيه ، ويمكن لـ IPFS وضع طبقة فوق أي نقل ، وعلى الرغم من أن نظام التوجيه الأول سيكون DHT ، إلا أن هناك آخرين لاستكشافه.

يمكنك رؤية IPFS مثل Telehash + the (merkle) Web.

إذا كنت تريد أن تكون البيانات الوصفية على الشبكة قابلة للقراءة آليًا وقابلة للمعالجة ولكن بطريقة قابلة للتوسيع ، فيجب عليك استخدام JSON-LD.

أعتقد أنه يمكننا أخذ جزء -LD من عملك دون الحاجة إلى JSON كوسيلة نقل. أعتقد أن عملك (الرائع) قابل للتعميم على أي بنية بيانات شجرية ، وهو أفضل بكثير من تنسيقات الويب الدلالية الأخرى. (بساطة مذهلة + مرونة!) لذا فإن ما أشير إليه في هذه الملاحظات هو استخدام ما يعادل @context لكن في بنية بيانات ارتباط IPFS (وهي ليست JSON ، إنها تنسيق ثنائي معبأ للبحث السريع من خلال الكائنات - protobuf اليوم ، ولكن قد يكون أيضًا يصف نفسه في وقت لاحق - أنوي أن يكون IPFS سريعًا بما يكفي للعمل كقاعدة بيانات. ليس اليوم ، ولكن في المستقبل :)).

إن طلب @context في كل كائن JSON على الشبكة ليس مطلبًا ثقيلًا.

نعم ، لقد جادلت في نفس الشيء :)

jbenet re: https://github.com/dataprotocols/dataprotocols/issues/110#issuecomment -43430309 - نعم ، اعتقدت أن حججك كانت جيدة جدًا ومستنيرة.

أنا مهتم حقًا بما تفعله ، لقد قمت بقشط الورق وبدأت في مشاهدة الفيديو الخاص بك. لسوء الحظ ، لدي مواعيد نهائية أحتاج إلى تجاوزها اليوم ، لكن لديّ قراءة ورقتكم ومشاهدة الفيديو بأكمله في قائمة المهام الخاصة بي. لا أعرف ما إذا كنت تعرف هذا ، لكني أعمل على بناء معايير للويب عبر W3C. لدينا الآن مجموعة من المشاكل التي تحتاج إلى حل مشابه للحل الذي تحدده. أريد أن أرى ما إذا كان بإمكاننا دمج بعض أعمالك في الجيل التالي من حل تسجيل الدخول القياسي W3C الذي نعمل عليه للويب (المنشور الذي أشرت إليه أعلاه). نحن نستخدم Telehash حاليًا ، ولكن لدينا بعض المخاوف المتعلقة بها ويبدو أنك قد حللت المشكلة بطريقة قد تناسب حالات الاستخدام لدينا بشكل أفضل.

على أي حال ، دعني أتطرق إلى ما قمت بإنشائه ثم أعود إليك. إذا لم تسمع أي رد خلال الأسبوع ، يرجى الاتصال بي مرة أخرى.

مرحبًا jbenet ، أتيحت لي الفرصة لإلقاء نظرة على الورقة البيضاء بمزيد من التفاصيل خلال عطلة نهاية الأسبوع بالإضافة إلى مشاهدة العرض التقديمي. دعونا نحدد وقتًا للتحدث هذا الأسبوع القادم. أنا على الساحل الشرقي للولايات المتحدة. متاح من 10 صباحًا حتى 2 مساءً معظم الأيام ما عدا الثلاثاء / الأربعاء. بريدي الإلكتروني: [email protected] ، Skype: msporny ، SIP: sip: [email protected] تواصل معي في أقرب وقت يناسبك.

أود مناقشة ipns وهذا الكتاب. تسجيل الدخول على الويب وبيانات الاعتماد والمدفوعات عبر الويب: https://manu.sporny.org/2014/identity-credentials/

تضمين التغريدة سوف تفعل. أرسل بريدًا إلكترونيًا الآن للمس القاعدة. قد ترغب في إزالة تفاصيل الاتصال الخاصة بك من هذه المشكلة (لأنها عامة ، وما إلى ذلك).

كنا نتحرك حول كيفية الإجابة على أسئلة "ما نوع هذا الكائن" على IRC اليوم. ذكرت jbenet نمط LSON-LD @type أو @context روابط ، لكنني لست متأكدًا من كيفية الخروج من هذه السلسلة . هل هي روابط @context على طول الطريق؟ أثار @ tv42 أيضًا مخاوف بشأن الاصطدامات مع أسماء الملفات ، نظرًا لأن عقد الدليل تستخدم أسماء الأجزاء الفرعية كمفاتيح لها. يمكنك حل هذه المشكلة عن طريق إدخال البادئة أو الهروب بطريقة أخرى من أسماء المقاطع ، ولكن يبدو أن هذا عمل أكثر من مجرد إضافة حقل نوع صريح للاحتفاظ بمعرف التجزئة لوصف النوع . إذا كنا نتوقع المزيد من هذا النوع من الأشياء ، فربما يتطلب فقط تقسيم الروابط إلى مجموعات داخلية وخارجية. يمكنك القيام بذلك باستخدام نهج امتداد Link protobuf المقترح من jbenet (إذا أصبح ذلك شيئًا) عن طريق إضافة قيمة منطقية "داخلية" لفصل إدخال النوع @context عن أي ملف @context إدخالات ( علي سبيل المثال).

آسف ، التنسيق (على الأرجح) لا يتغير في هذه المرحلة. لقد أمضيت شهورًا في غليانه حتى هذا الحد ولن أفتح بوابات الفيضان على ذلك مرة أخرى. الأسئلة المتبقية (مثل امتدادات الروابط) معروفة لبعض الوقت ومجرد إيجاد الطريقة الصحيحة للقيام بذلك.

كائن ipfs هو شجرة مثل json أو أي شيء آخر. هذا يعني أن جميع الحلول المتاحة لـ JSON (بما في ذلك JSON-LD و JSON-schema وما إلى ذلك) متاحة لـ IPFS. علاوة على ذلك ، من التافه تمثيل ثلاثيات RDF ككائنات ipfs. وبالتالي ، يمكنك فعل أي شيء وكل شيء.

البيانات الحقيقية شديدة الفوضى. لم ينجح أحد في العالم في إجبار الناس على اعتماد نظام معين لكتابة البيانات - ولن أضيع الوقت في تلك الحجج. الحل الوحيد الذي أعتقد أنه قابل للتطبيق على المدى الطويل هو جعل النظام مرنًا بدرجة كافية بحيث يتمكن الأشخاص من فعل ما يريدون ، ويكون صارمًا بدرجة كافية بحيث يرتبط كل شيء ببعضه البعض.

الآن ، الطريقة _المفضلة_ - الطريقة التي نقترح بها على الأشخاص القيام بالأشياء - من المحتمل أن تكون @context / @type من JSON-LD (القوية والبسيطة بشكل مثير للدهشة).

لكني لست متأكدًا من كيفية خروجك من هذه السلسلة

انا لا افهم السؤال. لا توجد سلسلة ، يمكنك حل السياق مرة واحدة وهذا كل شيء. هذا هو ملف سياق الكائن. إذا لم يكن سياق صالح - هناك مواصفات - فإنك تتجاهلها. يجب ألا تعتمد التطبيقات على صحة هذه الأنواع ، بل يجب أن تستفيد منها عندما تكون كذلك.

أثار @ tv42 أيضًا مخاوف بشأن الاصطدامات مع أسماء الملفات ، نظرًا لأن عقد الدليل تستخدم أسماء الأجزاء الفرعية كمفاتيح لها.

إذا كان هيكل بيانات dir يحتوي بالفعل على @context فلن يسمح بإنشاء ملف آخر - (أو في أسوأ الأحوال ، قم بإلحاق الرابط بعد (فرز مستقر)). إنها نفس محاولة إنشاء ملفين بنفس الاسم.

في الجمعة ، 01 مايو 2015 الساعة 03:51:22 صباحًا -0700 صباحًا ، كتب خوان باتيز بينيت:

عذرًا ، التنسيق (على الأرجح) لا يتغير في هذه المرحلة. أنا
أمضى شهورًا في غليانه حتى هذا الحد ولن يفتح الطوفان
بوابات على ذلك مرة أخرى. الأسئلة المتبقية (مثل ملحقات الارتباط)
معروفين لبعض الوقت ويبحثون عن الطريقة الصحيحة للقيام بذلك
هو - هي.

يجب أن تعمل ملحقات الارتباط بشكل جيد. وربط مفاتيح الربط بـ
مساحة لهم ليست بهذا السوء أيضًا. حشو معلومات النوع
يعمل في البيانات أيضًا (هذه هي الطريقة التي تعمل بها الملفات والأدلة الآن
[1،2،3،4،5]). تعداد الأنواع ليس نهجًا مستدامًا ، ولكن
سيعمل أي من هذه الأماكن كمكان لتخزين تجزئة نوع.

الآن ، الطريقة _المفضلة _ الطريقة التي نقترح بها على الأشخاص القيام بالأشياء
- من المحتمل أن يكون @context / @type من
(قوي بشكل مذهل وبسيط) JSON-LD.

JSON-LD جيد ، لكن النظام البيئي المحيط به سيحتاج إلى فهم
أن @ -prefix خاص. أنا أفضل أن يتم تخزين ذلك الخاص
صراحةً من خلال توسيع إدخالات الارتباط ببيانات إضافية (على سبيل المثال
علامة داخلية / خارجية) لذلك لا يوجد غموض بينcontext
ملف ورابط نوع context . ولكن إذا كانت جميع روابط الملفات / الملفات الفرعية محددة
مع طفل/، إذًا يمكن أن يكون لديك "سياق" للنوع
رابط و "تابع / سياق" للملف (أو أيا كان). ما زالت مستمرة
يجب أن يكون اصطلاحًا محددًا خارجيًا لمولدات الكائنات
ويحتاج المستهلكون إلى الاتفاق من خلال قناة لا تصف نفسها بنفسها.

لكني لست متأكدًا من كيفية خروجك من هذه السلسلة

انا لا افهم السؤال. لا توجد سلسلة ، أنت عازم
السياق مرة واحدة وهذا كل شيء. هذا هو ملف السياق لـ
هدف. إذا لم يكن سياق صالح - هناك مواصفات - أنت
تجاهله.

هذا يناسبني. كنت أتساءل كيف تنتهي من وصف الذات
سلسلة:

ما هو نوع A؟ دعنا فقط نتبع A / context إلى B. ما هو نوع B؟
دعنا فقط نتبع B / context إلى C ...

لكن إذا كنت تقوم بتوزيع المواصفات B (C في المثال الخاص بي) ، فلا يوجد
بحاجة إلى ارتباط B / context . ولكن إذا كان لديك قناة
بتوزيع مواصفات النوع (C) ، فلماذا لا تستخدمها أيضًا لتوزيع ملف
اكتب المخططات نفسها (ب)؟ يبدو أنه من الأفضل أن يكون لديك ملف
مكان تقليدي في الكائنات التي تحتوي على متعدد الهاش يصف لها
اكتب (رابط context الخاص بك ، أو أيا كان). ثم ابتعد عن الطريق و
اترك الأمر لمجتمعات المنتجين / المستهلكين لتقرير ما إذا كان هذا
إشارة إلى تعريف نوع (ربما بموجب المواصفات C أو Cv2 أو
CCv1.3 ، أو ...) أو إذا كانوا يريدون فقط استخدام multhash كـ
معرّف غير شفاف. ثم لا يزال بإمكانك القيام بأشياء مثل:

التبديل pbn.GetType () {
حالة قدم الدليل:
root.val = NewDirectory (PointsTo.String () ، mnode ، الجذر ، fs)

كل ما في الأمر أن GetType هو الذي سيحصل على تجزئةcontext Link (أو
أينما) ، وسيكون دليل TD متعدد الهاش
(QmWellKnownDirectoryType).

يجب ألا تعتمد التطبيقات على هذه الأنواع ، ولكن
بالأحرى الاستفادة منهم عندما يكونون كذلك.

هذا يبدو وكأنه معرّف معتم. ربما نقول نفس الشيء
شيء ؛).

كما أثار @ tv42 مخاوف بشأن التصادم مع أسماء الملفات ، منذ ذلك الحين
تستخدم عقد الدليل أسماء الأجزاء الفرعية كمفاتيح لها.

إذا كان هيكل بيانات dir يحتوي بالفعل على @context فلن يسمح بذلك
إنشاء ملف آخر-- (أو في أسوأ الأحوال ، قم بإلحاق الرابط بعده
(نوع مستقر)). إنها نفس محاولة إنشاء ملفين بامتداد
نفس الاسم.

إنه إذا كنت تريد جعل ملفات context غير قانونية ؛). أذا أردت
السماح للأشخاص بإنشاء ملفات context ، فستحتاج إلى طريقة ما
توضيح بين "نقاط الارتباط عند نوع" و "هذا الارتباط
يشير إلى ملف / دليل فرعي / ... ". لكن هناك عدد من الطرق
حول هذه المشكلة ، طالما أننا نختار واحدًا منهم ، فسأكون سعيدًا
؛).

أجريت محادثة مع cryptix منذ عدة أيام وتحدثنا بإيجاز عن استخدام JSON-LD. أود فقط أن أشير إلى أن مواصفات json-ld تسمح باستخدام "ارتباط" لوصف التعيينات من json إلى json-ld. أنا شخصياً أفضل هذا النهج لأنه يسمح للبيانات الوصفية بأن تكون متوافقة مع json-ld دون إعادة هيكلتها لأي نكهة لـ RDF هي "hip" حاليًا.

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

في الجمعة ، 01 مايو 2015 الساعة 09:24:27 مساءً -0700 ، كتب دبليو تريفور كينج:

يجب أن تعمل ملحقات الارتباط بشكل جيد. وربط مفاتيح الربط بـ
مساحة لهم ليست بهذا السوء أيضًا. حشو معلومات النوع
يعمل في البيانات أيضًا (هذه هي الطريقة التي تعمل بها الملفات والأدلة الآن
[1،2،3،4،5]). تعداد الأنواع ليس نهجًا مستدامًا ، ولكن
سيعمل أي من هذه الأماكن كمكان لتخزين تجزئة نوع.

في ملاحظة ذات صلة (توزيع معرفات النوع المجزأ مع ملحق
payload) ، لفتت @ tv42 انتباهي إلى Ethos ETypes [1،2،3]. وبالتالي
أعتقد أن وجود نوع من الفتحة الصريحة لهذه الأشياء سيكون
رائعة.

لم أرَ ETypes ، شكرًا على الظهور. سوف تقرأ خلال اليومين المقبلين. شيء ذو صلة هو عمل Kathleen Fisher's PADS + ذي الصلة. يبدو أن صفحة مشروع PADS قد تم تغييرها مؤخرًا (إذا كان هناك فقط بعض المحتوى غير القابل للتغيير على الويب ...). (لكن أرشيف الإنترنت أنقذنا مرة أخرى \ o /: http://web.archive.org/web/20130125041549/http://www.padsproj.org/)

• PADS: لغة خاصة بالمجال لمعالجة البيانات المخصصة
• مشروع PADS: نظرة عامة
• PADS / T: لغة لوصف وتحويل البيانات المخصصة
• PADS / ML: لغة وصف البيانات الوظيفية
• LearnPADS: إنشاء أداة تلقائية من بيانات مخصصة
• المزيد من الأوراق: http://web.archive.org/web/20120205185831/http : // www.padsproj.org/doc.html#papers

على أي حال ، لدى PADS الفكرة الصحيحة إلى حد كبير. ولكن حتى الآن لم نشهد تطبيقًا واسعًا ، وأنا على علم به. ربما هناك شيء ما في أسلوب JSON-LD يمكنه إصلاح ذلك هنا.

لا يقتصر JSON-LD على إضافة رابط context فقط. على وجه الخصوص ، يجب أن يقع كل اسم ارتباط (مفتاح في JSON) في إحدى الفئات التالية:

• context : رابط سياق أو عقدة مضمنة تصف البيانات
• id : عنوان URL الخاص بالعقدة الحالية
• المخطط: // full-uri : يتم التعرف عليه كارتباط المسند هو URI
• البادئة: الاسم : يتم التعرف عليه كارتباط يكون المسند هو سلسلة البادئة URI (المحددة في السياق) والاسم
• الاسم: يتم التعرف عليه كارتباط فقط إذا تم تعريفه في السياق

على وجه الخصوص ، لا يبدو أن JSON-LD يدعم خرائط المفاتيح / القيم العشوائية. إذا كان من الممكن تفسير المفتاح على أنه URI ، فسيتم اعتباره مسندًا باستخدام URI هذا. بالنسبة إلى eample ، ما يلي غير صالح:

{
  "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>"
    }
  ]
}

في IPFS-LD سيكون لدينا عقدة للدليل ، مرتبطة بسياق وبعقدة لكل إدخال. سيكون لكل إدخال بعد ذلك روابط إلى سياقه الخاص ، وعقدة تحتوي على اسمه وعقدة بمحتوى الملف.

يضيف هذا مستويات متعددة من المراوغة ، والتي تكون مقبولة لمستندات JSON (لأن كل شيء معبأ في ملف واحد) ولكن قد لا يكون مقبولًا لـ IPFS حيث تحتوي كل عقدة على تجزئة مختلفة ويجب تتبعها بشكل منفصل.

ربما ، ما نريده هو عدم استخدام JSON-LD كما هو ، ولكن تحديد تنسيق السياق الخاص بنا والمستوحى من JSON-LD. سيكون هذا أفضل لأن تنسيقنا ليس JSON ، وهو محدد للغاية: نحن نرغب في وصف خرائط المفاتيح التعسفية (لـ unixfs) ونريد أيضًا استخدام قسم البيانات في كائنات IPFS الخاصة بنا (JSON ليس لديها ذلك ).

نظرًا لأن قسم الارتباط الخاص بكائنات IPFS مقيد للغاية ، فإن الروابط لها اسم وتشير إلى كائن آخر. لا يمكن أن تحتوي على قيم حرفية. ما نحتاج إلى تحديده في السياق هو الاسم المؤهل بالكامل للرابط في نموذج URI. نظرًا لأن لدينا أيضًا قسمًا للبيانات ، نحتاج إلى تحديد ما يحتويه.

بالنسبة لـ unixfs ، أتخيل الأشياء التالية:

• directory :
  
  
  
  • ربط @context يشير إلى سياق الدليل
  
  
  • ربط entry:README.md للإشارة إلى الكائن README.md
  
  
  • لايوجد بيانات
  
  
• README.md :
  
  
  
  • ربط @context يشير إلى سياق الملف
  
  
  • قسم البيانات مع محتوى README.md
  
  
• سياق الدليل:

""
{
//type: نوع كائن 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 # ملف "

// <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

يا mildred - تحليل رائع. من المضحك أنني توصلت إلى نفس الاستنتاجات في محادثة مع dlongley في irc: //irc.frennode.org#json -ld (يمكنني إرسال السجلات إليك إذا كنت مهتمًا)

لقد كنت أجرب قليلاً مع نوع 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>"}
• يمكن للمستخدمين تحديد سياقات لهياكل البيانات الخاصة بهم
• can _nest_ الروابط ، باستخدام تدوين المسار للعبور ، على سبيل المثال https://github.com/ipfs/go-ipld/blob/master/ipld.go#L122 -L141

أعتقد أنك وأنا على الطريق الصحيح. أعتقد أيضًا أنه يمكننا على الأرجح القيام بالكثير من هذا دون الانحراف كثيرًا عن JSON-LD. مجرد إسقاط بعض القيود

mildred سجلات هنا

يجب أن يقول أيضًا أنه - من حديثي مع dlongley - يجب أن يكون من الممكن القيام بما نريد دون الانحراف تقنيًا عن معيار JSON-LD ، فإن مجرد استدعاء التحويلات (الضغط / التوسيع) _ من شأنه إزالة كل "غير -مفاتيح معرّفة بالسياق ". (يجب ألا نحيد)

أعتقد أنك ستزيل الكثير من الالتباس من خلال التفكير في JSON-LD من حيث الثلاثيات التي تم إنشاؤها ، بدلاً من ما يفعله المحلل اللغوي json-ld.js في تحويل JSON. خطوة تحويل JSON خاصة بهذا المحلل اللغوي ويمكنك أن تتخيل تحويلها بسهولة بطريقة أخرى دون مشاكل.

الآن ، إذا فهمت جيدًا ما تفعله باستخدام go-ipld ، فقد يحل محل قسم الارتباط في كائنات IPFS الحالية ، أليس كذلك؟ هذا الشيء: merkledag.proto

أرى مشكلة هناك. حيث كان لدينا سابقًا بنية بسيطة تسمح بمعالجة فعالة (اسم الرابط ، المرتبط مباشرة بالمسار ، وتجزئة الارتباط) ، أصبح لدينا الآن بنية أكثر تعقيدًا. للوصول إلى التجزئة المرتبطة ، يجب عليك حل السلسلة "mlink" في جدول التجزئة. هل ذلك ضروري؟

إذا كنت تريد بيانات مرتبطة / RDF ، فلماذا لا تحدد تنسيق الأسلاك الخاص بك ببساطة (يعد protobuf رائعًا بقدر ما أشعر بالقلق) والطريقة التي يمكن بها ترجمتها إلى JSON. ثم استخدم سياق JSON-LD فوق ذلك.

الآن ، حول بنية البيانات المختلفة التي كنت تفكر فيها ، أعتقد أنها رائعة ، باستثناء وحدات unixfs: لا يمكننا الحصول على أسماء ملفات مثل مفاتيح 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"
    }
  ]
}

مرة أخرى ، يجب ألا يكون الإصدار الثنائي / المتسلسل مثل هذا. طريقة تمثيل هذا الترميز الأخير على أنه رحلات RDF ستكون:

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"

أنا على IRC ، لا تتردد في الاتصال بي هناك.

بالنسبة لأولئك الذين ليسوا على دراية بـ RDF في هذا الموضوع ، إليك شرح بسيط:

RDF هي طريقة لتنظيم بياناتك. إنه نموذج البيانات وراء JSON-LD. في RDF ، يجب تشفير جميع البيانات في ثلاثيات:

<subject> <predicate> <object>

• الموضوع عبارة عن عقدة يتم تحديدها بواسطة URI
• المسند هو URI مثل <http://www.w3.org/1999/02/22-rdf-syntax-ns#name> . يعرّف URI العلاقة بشكل فريد ، ويفضل أن يتم تعريفه جيدًا في المواصفات أو المخطط.
• الكائن هو هدف الارتباط / المسند. يمكن أن تكون قيمة حرفية (سلسلة ، يمكن كتابتها اختياريًا ، على سبيل المثال كعدد صحيح أو تاريخ ، مشتق بشكل عام من مخطط xsd) أو يمكن أن تكون عقدة أخرى ، محددة بواسطة URI الخاص بها

يفترض التدوين الثلاثي أن كل موضوع وعقدة كائن لها عنوان URI يعرّفها بشكل فريد. يحدد هيكل البيانات الكامل من خلال سرد كل الثلاثيات التي تحتوي على واحد في كل سطر.

مفاتيح JSON في JSON-LD هي المسندات التي تربط الموضوع (الكائن الذي يوجد فيه المفتاح) والكائن: قيمة مفتاح JSON-LD. في هذه الحالة ، لا يتم استخدام URI للإشارة إلى الموضوع والكائن. إذا كنت تريد تحديد URI لكائن يمكن استخدامه للإشارة إليه ، فهناك خاصية id .

هل هناك كتابة في أي مكان تشرح كيفية عمل البيانات المرتبطة عبر IPFS مقارنة بكيفية عملها عبر HTTP؟ (ما هي URIs؟ ما هي أفضل الممارسات للناشرين والمستهلكين للبيانات المرتبطة عبر IPFS؟)

يرى:

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

يمنحك IPLD نموذج بيانات json. يمكنك طبقة أي JSON-LD فوق IPLD.

(لم تهبط بعد)

jbenet مجرد قراءة من خلال هذا الموضوع ، واستخدام البيانات المرتبطة هو مبادرة عظيمة IMHO

أنت محق في أن البيانات المرتبطة لا تتطلب أي تسلسل واحد. من الممكن استخدام JSON-LD أو RDF / XML أو RDFa أو Turtle أو مجموعة من التنسيقات الأخرى

ما تتطلبه البيانات المرتبطة هو أن المفاتيح في JSON هي URIs. يمكن أن يكون هذا بسيطًا مثل تسبقها بـ urn:string:<key> لذلك ، إذا كان استخدام JSON-LD يمكن أن يتم كبطانة واحدة في السياق ، أو كتابتها بشكل صريح.

هناك طريقة أخرى (مفضلة بشكل عام) وهي وضع مصطلحات للمفاتيح في http (s) أو ipfs: مستند يحتوي على أوصاف يمكن قراءتها بواسطة الإنسان لكل مصطلح.

أعتقد أيضًا أنه من المثير للاهتمام البيانات الوصفية لتجزئة IPFS المكتوبة في البيانات المرتبطة. لقد أجريت محاولة سريعة لهذا اليوم في Turtle ، مع إعادة استخدام النمط الموضح في 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://ignedinstance.com/.well-known/ni/multihash/QmZvTvRQ2voimuYwBtKsyMqMqirDt5Xrq4sdow2RM5ynKj

فكرة البيانات المرتبطة هي أن المعرفات التي تقدمها للأشياء ، إذا بحثت عنها ، فامنحها بيانات مفيدة ، بما في ذلك البيانات التي ترتبط بالأشياء ذات الصلة. لذا ، يمنحك الدليل قائمة بـ URIs للأشياء التي يحتوي عليها ، ويمنحك الحدث الوقت والبيانات والروابط إلى الأشخاص المدعوين ، ويمنحك الأشخاص روابط لمجموعات وأشخاص آخرين ، وما إلى ذلك. القيام بكل هذا عبر ipfs: بدلاً من http: بالطبع يعمل بشكل جيد ، ويمكنك ربط الفراغين. يمكنك على سبيل المثال التأكيد على أن شيئًا ما في مكان ما هو نفسه شيء في مكان آخر. هل يمكن لأصدقائك توثيقهم في http: space وتوثيق منشوراتك في ipfs: space أو أي شيء تريده.

(بصفتي rdfhead ، أفضّل Turtle كتنسيق حيث أجده بسيطًا وقويًا ولكن يمكنك استخدام JSONLD بالتأكيد)

/ لا يمكنني الاتصال بـ static.benet.ai لقراءة http://static.benet.ai/t/ipfs.pdf

timbl ، يمكنك العثور على إصدار أحدث من ورقة IPFS هنا: https://github.com/ipfs/papers/blob/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf أو نفس الورقة عبر بوابات IPFS العامة: https://ipfs.io/ipfs/QmV9tSDx9UiPeWExXEeH6aoDvmihvx6jD5eLb4jbTaKGps

يمكنك على سبيل المثال التأكيد على أن شيئًا ما في مكان ما هو نفسه شيء في مكان آخر.

نعم! هذه كلها متشابهة:

• dweb: / ipfs / بعضهاش
• ipfs: // somehash
• https://dweb.link/ipfs/somehash

نأسف لذلك ، فإن مخطط dweb: URI و https://dweb.link لا يعملان بالفعل بعد.

الآن هو fs:/ipfs/somehash لـ URIs (في الملحق IPFS Gateway Redirect) و https://ipfs.io/ipfs/somehash لـ HTTP:

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

في حال غاب الناس في هذا الموضوع ، حدث ذلك!

https://ipld.io/

دعنا نواصل الحديث على https://github.com/ipld/ipld

بالتأكيد. لا تتردد في الحضور لمناقشة جوانب البيانات المرتبطة على:

https://gitter.im/linkeddata/chat

nicola Im متأكد من أنه ليس غريبًا على تلك القناة

كنا في الواقع نناقش إضافة ipfs: URIs إلى نظامنا اليوم. حظا سعيدا مع ipld!

لماذا نستخدم المصطلح المحدد جيدًا "البيانات المرتبطة" لشيء من الواضح أنه ليس صعوبة التعلم؟
https://www.w3.org/standards/semanticweb/data

لذلك ، أعلم أن هذا خيط قديم ولكني أضيف نفسي لأختلط للأجيال القادمة.

لقد كنت أعمل على نموذج بيانات الاعتماد القابلة للتحقق (https://w3c.github.io/vc-data-model/) ووجدت بعض المشكلات في التوفيق بين @context الممثل في JSON-LD مقابل IPLD. (انظر: https://github.com/w3c/vc-data-model/pull/261). أستطيع أن أدرك أن JSON-LD متوافق تمامًا مع IPLD ، لكن IPLD ليس متوافقًا تمامًا مع JSON-LD ، والذي سيكون ضروريًا للتشغيل البيني مع المواصفات الحالية. كما أراه ، سيكون الحل هو إضافة ipld: كمخطط صالح في ietf (انظر: https://github.com/ipld/specs/issues/98) ثم السماح بـ { <attr> : ipld:<cid> } يكون { "/" : <cid> } في IPLD (انظر: https://github.com/ipld/specs/issues/99). أيضًا / بالإضافة إلى ذلك ، قم بتسجيل نوع محتوى MIME application/ipld للإعلان عن النوع الذي يحدد البروتوكول. قد يتراكم هذا للسماح application/json+ipld مقابل application/cbor+ipld لتخفيف الارتباك. ( mildred لا أحب ipfs: // لهذا لأننا نحتاج إلى ربط طبيعي و "{"context ":" / ipfs /"}" هو URI صالح)

بالنسبة لقابلية التشغيل البيني الدلالي ، فقد قمت بوضع سياق JSON-LD فوق IPLD. ومع ذلك ، فإن هذا يصل إلى مشكلة تأصيل ، ويتم حلها بسهولة من خلال تضمين URIs كقيم صالحة في JSON-LD.

في النهاية ، إنها السلاحف على طول الطريق : سلحفاة:>: سلحفاة:>: سلحفاة: حتى تصل إلى القاع حيث تجد timbl ، ولهذا أعتقد أنه يفضل السلاحف كتنسيق: مبتسم : .

(بصفتي rdfhead ، أفضّل Turtle كتنسيق حيث أجده بسيطًا وقويًا ولكن يمكنك استخدام JSONLD بالتأكيد)

وخير مثال على ذلك هو التعامل مع التاريخ والوقت في @context لأوراق الاعتماد التي يمكن التحقق منها على https://w3id.org/did/v1 والتي ترتبط بـ xsd: datetime الذي يشير إلى http://www.w3.org/ 2001 / XMLSchema # ، حيث يكون التفسير كمصدر توثيق بلغة html .

تعليقي المفضل في ملف xml هذا هو:

أولاً ، أنواع البيانات الأولية المضمنة. هذه التعريفات هي للعلم فقط ، والتعريفات الحقيقية المضمنة هي سحرية.

يمكنني العمل مع هذا السحر ، طالما أننا نقبل ذلك في الجزء السفلي من كومة: turtle:>: turtle:>: turtle: نتفق أنها timbl ومن ثم يمكننا التوفيق بين التوافق العكسي مع JSON-LD باستخدام أعلاه مع ipld: .

jonnycrunch أنا أؤيد أفكارك. Turtle ليس الأكثر شيوعًا ، لأن JSON راسخ تمامًا على الويب ، خاصة وأن JSON أصلي للمتصفحات ، وله منحنى تعليمي ضحل.

هناك توازن يجب تحقيقه بين جذب مجتمع مطور واسع وامتلاك نظام قابل للتشغيل البيني (ليس شيئًا بالأبيض والأسود) وميزات غنية.

تختفي مشكلة context إذا قمت بكتابة عنوان url كاملاً. على الرغم من وجود عدد أكبر من الشخصيات ، إلا أنني أظن أنها ممارسة أفضل ، إن لم تكن أفضل ، نظرًا لأنها تتجنب رحلة الذهاب والإياب ولا تحتاج إلى التحقق من سلامة الملف البعيد.

في نهاية المطاف ، ينشأ الالتباس في أن URIs هي أسماء (uuids) ومحددات (بروتوكول) ولا يفكر الدماغ بسهولة في كليهما مرة واحدة. إذا تمكنا من الوصول إلى النقطة التي نستخدم فيها URIs أو الاختزال لـ URIs في مفاتيح JSON ، فإن العديد من هذه المشكلات تختفي. في الواقع ، كتسمية ipfs: و http: يجب أن تصبح جزءًا من شبكة تعاونية ، مع البيانات المرتبطة كنوع من الغراء.

لقد قمت بتحديث تعليقي لاستخدام الصيغة ipld:<cid> وأدركت أنها غير موثوقة وبالتالي لا تستحق استخدام الشرطة المائلة المزدوجة ipld:// // . نظرًا لأن الحمولة تصف نفسها ، فهي سلطتها الخاصة ويجب أن تقف بمفردها. لكن هذه حجة للخبراء.

jonnycrunch كتب:

سيكون الحل هو إضافة ipld: كمخطط صالح في IETF

أنا أؤيد هذا النهج بشدة وأعتقد أنه سيؤدي إلى قصة تفاعل رائعة بين مجتمع البيانات المرتبطة (الأكثر تقليدية) ومجتمع IPFS / IPLD.