إشعارات البيانات المرتبطة

إشعارات البيانات المرتبطة ( LDN ) ^{[ 3 ]} هي توصية من اتحاد شبكة الويب العالمية (W3C) تصف بروتوكول اتصالات قائم على HTTP و URI و RDF ، يوضح كيفية استقبال الخوادم ( المستقبلين ) للرسائل المرسلة إليها من التطبيقات ( المرسلين )، وكيفية استرجاع التطبيقات الأخرى ( المستهلكين ) لهذه الرسائل. يمكن لأي مورد ويب (مثل صفحة HTML ) الإعلان عن نقطة نهاية استقبال ( صندوق وارد ) لرسائل الإشعارات. تُعبَّر الرسائل باستخدام RDF، ويمكن أن تحتوي على بيانات متنوعة.

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

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

يتمثل أحد الدوافع الرئيسية لشبكة LDN في دعم الإشعارات بين تطبيقات الويب اللامركزية، ^{[ 4 ]} بما في ذلك متصفحات الويب التي - لعدم امتلاكها خادم HTTP خاص بها - لا تستطيع إنشاء رابط HTTP لرسائل الرد. وثمة دافع آخر يتمثل في هيكلة الإشعارات كعبارات RDF باستخدام أي مفردات مُتحكَّم بها ، بحيث يمكن لأي تطبيق مُستخدِم اختيار المعلومات التي يفهمها.

• يقوم المرسل أو المستلم بإجراء عملية إرسال أو استقبال إلى مورد HTTP موجود. يتم اكتشاف عنوان URI الخاص بصندوق الوارد من خلال أحد المصادر التالية:GETHEAD
  • علاقة Link:في رؤوس استجابة HTTP من النوعhttp://www.w3.org/ns/ldp#inbox
  • بيان RDF مضمن في نص HTTP باستخدام خاصية RDFhttp://www.w3.org/ns/ldp#inbox
• يقوم المرسل بإنشاء إشعار جديد (على سبيل المثال بتنسيق JSON-LD )، والذي يرسله POSTإلى عنوان URI الخاص بالصندوق الوارد .
  • يقوم المتلقي بإنشاء مورد HTTP جديد يحتوي على الإشعار المنشور ويستجيب باستخدام 201 Createdعنوان URI الذي تم إنشاؤه.
• يسترجع المستهلك بيانات RDF من عنوان URI الخاص بالبريد الوارد المكتشف باستخدام ، ثم: GET
  • يقوم المستهلك بتحليل نص الاستجابة للعثور على عبارات RDF التي تحتوي على الخاصية http://www.w3.org/ns/ldp#contains. يوفر كائن هذه العبارات معرّفات URI لإشعارات LDN المقبولة.
  • يقوم المستهلك باسترجاع أي من الإشعارات المرتبطة باستخدام GETRDF الخاص به ومعالجته بطريقة خاصة بالتطبيق.
  • تظل الإشعارات متاحة، وبالتالي يمكن ربطها ووصفها في موارد الويب الأخرى.

في كل مرحلة، يمكن للمرسل والمستهلك إجراء مفاوضات المحتوى للإرسال أو الاستقبال بأي تنسيق تسلسل RDF متفق عليه بشكل متبادل ، ولكن يجب أن يدعم جهاز استقبال LDN المتوافق على الأقل JSON-LD .

يكتشف المرسل أو المستهلك صندوق الوارد لعنوان URI معين، في هذا المثال باستخدام الطريقة التاليةHEAD :

HEAD https://example.org/article/5 HTTP / 1.1

HTTP / 1.1 200 OK الرابط : <https://example.org/inbox/7>; rel="http://www.w3.org/ns/ldp#inbox"

يقوم المرسل بإرسال إشعار إلى صندوق الوارد المكتشف، في هذا المثال باستخدام مفردات Schema.org :

POST https://example.org/inbox/7 HTTP / 1.1 Content-Type : application/ld+json{ "@context" : "http://schema.org" , "@type" : "ReviewAction" , "object" : { "@id" : "https://example.org/article/5" }, "agent" : { "@type" : "Person" , "name" : "Alice" }, "result" : { "@type" : "Review" , "reviewBody" : "هذه المقالة هي الأفضل التي رأيتها على الإطلاق!" } }

HTTP / 1.1 201 تم الإنشاء الموقع : http://example.org/inbox/f44f3f11

يقوم أحد المستخدمين بسرد محتويات صندوق الوارد الذي تم اكتشافه للعثور على 3 إشعارات:

طلب GET إلى https://example.org/inbox/7 HTTP / 1.1 Content-Type : application/ld+json

HTTP / 1.1 200 OK Content-Type : application/ld+json{ "@context" : "http://www.w3.org/ns/ldp" , "@id" : "https://example.org/inbox/7" , "contains" : [ "https://example.org/inbox/5c6ca040" , "https://cdn.example.org/inbox/92d72f00" , "https://example.org/inbox/f44f3f11" , ] }

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

في هذا المثال، يسترجع المستهلك الإشعار الجديد f44f3f11، مع التفاوض على المحتوى لتفضيل تنسيق Turtle RDF:

طلب GET إلى https://example.org/inbox/f44f3f11 HTTP / 1.1 Accept : application/ld+json;q=0.9, text/turtle;q=1.5

HTTP / 1.1 200 OK Content-Type : text/turtle@prefix schema: <http://schema.org/> . [ a schema : ReviewAction ; schema : agent [ a schema : Person ; schema : name "Alice" ]; schema : object <https://example.org/article/5> ; schema : result [ a schema : Review ; schema : reviewBody "This article is the best I've ever seen!" ] ] .

توجد العديد من تطبيقات LDN ، ^{[ 4 ] [ 5 ]} التي تغطي المرسلين والمستهلكين والمستقبلين، بما في ذلك:

• dokieli (المرسل، المستهلك)
• إيرول (المرسل)
• فيدورا كومنز (المستقبل)
• أباتشي مارموتا (مستقبل)
• كاربون إل دي بي (المستقبل)
• قواعد التعديل المرتبط (المرسل)
• صلب (مرسل، مستقبل، مستهلك)
• خادم Virtuoso العالمي (المستقبل، المستهلك)

أي تطبيقات لمنصة البيانات المرتبطة (LDP) هي أيضًا مستقبلات متوافقة لإشعارات البيانات المرتبطة لأن LDN هي مجموعة فرعية صارمة من LDP. ^{[ 4 ]}