محدد موقع الموارد الموحد الدائم

مُحدد موقع الموارد الموحد الدائم ( PURL ) هو مُحدد موقع موارد موحد (URL، أي مُعرف موارد موحد ، أو URI، يعتمد على الموقع) يُستخدم لإعادة التوجيه إلى موقع مورد الويب المطلوب . تُعيد عناوين PURL توجيه عملاء HTTP باستخدام رموز حالة HTTP .

في الأصل، كانت عناوين PURL تُعرف باستضافتها على purl.org أو أسماء مضيفين أخرى تحتوي على purl. في البداية، استخدمت العديد من هذه المضيفات الأخرى برامج مشتقة من برنامج نظام OCLC PURL الأصلي. مع ذلك، أصبح مفهوم PURL عامًا في نهاية المطاف، واستُخدم للإشارة إلى أي خدمة إعادة توجيه (تُسمى مُحلِّل PURL ) تقوم بما يلي: ^{[ 1 ]}

• يحتوي على "عنوان URL جذري" كمرجع للمحلل (على سبيل المثال http://myPurlResolver.example)؛
• يوفر وسائل لمجتمع المستخدمين الخاص به لإدراج أسماء جديدة في عنوان URL الرئيسي (على سبيل المثال http://myPurlResolver.example/name22)؛
• يوفر وسائل لربط كل اسم بعنوان URL الخاص به (لإعادة التوجيه)، ولتحديث عنوان URL لإعادة التوجيه هذا؛
• ضمان استمرارية (على سبيل المثال عن طريق العقد) عنوان URL الجذر وخدمات محلل PURL .

تُستخدم عناوين PURL لتنظيم عملية تحليل عناوين URL، وبالتالي حل مشكلة عناوين URI المؤقتة في أنظمة URI القائمة على الموقع مثل HTTP. من الناحية التقنية، يُشبه تحليل السلاسل النصية في PURL تحليل عناوين URL المُحسّنة لمحركات البحث (SEF ). يتناول الجزء المتبقي من هذه المقالة نظام PURL الخاص بمركز OCLC ، والذي اقترحه ونفذه المركز.

طُوِّر مفهوم PURL بواسطة ستيوارت ويبل وإريك جول في OCLC عام 1995. ^{[ 2 ]} تم تطبيق نظام PURL باستخدام نسخة معدلة من خادم Apache HTTP Server قبل الإصدار 1.0 . تم تحديث البرنامج وتوسيعه عام 2007 بواسطة شركة Zepheira بموجب عقد مع OCLC، ونُقل الموقع الإلكتروني الرسمي إلى purlz.org(جاء الحرف "Z" من اسم Zepheira، واستُخدم لتمييز موقع برنامج PURL مفتوح المصدر عن مُحلِّل PURL الذي تُشغِّله OCLC).

قد تُعتبر أرقام إصدارات PURL مُربكة. أصدرت OCLC الإصدارين 1 و2 من شجرة المصدر القائمة على رخصة أباتشي، بدايةً في عام 1999 بموجب رخصة OCLC Research Public License 1.0، ثم لاحقًا بموجب رخصة OCLC Research Public License 2.0. ^{[ 3 ]} أصدرت Zepheira الإصدار PURLz 1.0 في عام 2007 بموجب رخصة أباتشي ، الإصدار 2.0. ^{[ 4 ]} تم إصدار PURLz 2.0 في مرحلة الاختبار التجريبي في عام 2010، لكن الإصدار لم يُعتمد نهائيًا. قام مشروع Callimachus بتطبيق PURLs بدءًا من إصداره 1.0 في عام 2012.

تم تشغيل أقدم محلل PURL HTTP بواسطة OCLC من عام 1995 إلى سبتمبر 2016 وتم الوصول إليه على النحو التالي purl.oclc.orgبالإضافة إلى purl.org، purl.netو و purl.com.

ومن بين الجهات الأخرى البارزة التي تقوم بتحليل عناوين PURL مكتب الطباعة الحكومي الأمريكي ( purl.fdlp.gov)، الذي يتم تشغيله لصالح برنامج مكتبة الإيداع الفيدرالية ويعمل منذ عام 1997.

يُستخدم مفهوم PURL في w3id.org، والذي قد يحل محل خدمات PURL القديمة وتقنيات PURL.

في 27 سبتمبر 2016، أعلنت OCLC عن تعاونها مع أرشيف الإنترنت ، ما أدى إلى نقل خدمة تحليل أسماء النطاقات وواجهة إدارتها إلى أرشيف الإنترنت. ^{[ 5 ]} وتُدعم الخدمة ببرمجيات جديدة كليًا، منفصلة عن جميع التطبيقات السابقة. وقد أتاح هذا النقل إمكانية إدارة تعريفات عناوين PURL التي كانت معطلة في الخدمة المستضافة على OCLC لعدة أشهر. وتدعم الخدمة المستضافة على خوادم أرشيف الإنترنت الوصول عبر عناوين IP التالية purl.org: purl.netو purl.infoو و purl.com. وتقوم OCLC الآن بإعادة توجيه طلبات DNS الخاصة بعنوان IP purl.oclc.orgإلى عنوان IP الخاص بها purl.org.

يُتيح مفهوم PURL إمكانية تنظيم عناوين URL العامة لبروتوكول HTTP URI على شبكة الإنترنت العالمية . كما يُتيح PURL تحكم جهات خارجية في كلٍ من تحليل عناوين URL وتوفير بيانات تعريف الموارد.

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

يعمل طلب PURL البسيط عن طريق الاستجابة لطلب HTTP GET بإرجاع استجابة من النوع 302 (وهو ما يعادل رمز حالة HTTP 302، ويعني " تم العثور على "). تحتوي الاستجابة على ترويسة HTTP Location ، وقيمتها عبارة عن عنوان URL يجب على العميل استرداده لاحقًا عبر طلب HTTP GET جديد.

تُطبّق عناوين URL الدائمة (PURLs) أحد أشكال المعرّفات الدائمة للموارد الافتراضية. وتشمل أنظمة المعرّفات الدائمة الأخرى معرّفات الكائنات الرقمية (DOIs) ومعرّفات علوم الحياة (LSIDs) ومعرّفات الموارد الموحدة للمعلومات (INFO URIs ). توفر جميع أنظمة التعريف الدائمة معرّفات فريدة للموارد الافتراضية (التي قد تتغير)، ولكن لا توفر جميعها فرصًا للتنظيم. وقد عُرّف تنظيم الموارد الافتراضية بأنه "المشاركة الفعّالة لمتخصصي المعلومات في إدارة البيانات الرقمية ، بما في ذلك حفظها، لاستخدامها في المستقبل". ^{[ 6 ]}

تعرضت عناوين PURL لانتقادات بسبب حاجتها إلى تحليل عنوان URL، مما يربط عنوان PURL بموقع على الشبكة. وتعاني مواقع الشبكة من عدة ثغرات أمنية، مثل تسجيلات نظام أسماء النطاقات (DNS) والتبعيات المضيفة. وقد يؤدي فشل تحليل عنوان PURL إلى حالة غامضة: إذ لن يكون واضحًا ما إذا كان سبب فشل تحليل عنوان PURL هو عطل في الشبكة أم أنه غير موجود. ^{[ 7 ]}

عناوين PURLs هي عناوين URL صالحة بحد ذاتها، لذا يجب أن تتوافق مكوناتها مع مواصفات عنوان URL. يُحدد جزء "البروتوكول" لبرنامج حاسوبي ، مثل متصفح ويب، البروتوكول الذي سيستخدمه عند تحليل العنوان. عادةً ما يكون البروتوكول المستخدم في عناوين PURLs هو HTTP. يُحدد جزء "المضيف" خادم PURL الذي سيتم الاتصال به. أما الجزء التالي، وهو "نطاق PURL"، فيُشابه مسار الموارد في عنوان URL. النطاق عبارة عن مساحة معلومات هرمية تفصل عناوين PURLs وتسمح بوجود جهات صيانة مختلفة لكل منها. قد تُدار كل نطاق PURL بواسطة جهة صيانة واحدة أو أكثر. وأخيرًا، اسم PURL هو اسم عنوان PURL نفسه. يُشكل النطاق والاسم معًا مُعرّف PURL .

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

معظم عناوين PURL هي عناوين بسيطة ، تُستخدم لإعادة التوجيه إلى المورد المطلوب. رمز حالة HTTP لهذا النوع من عناوين PURL هو 302. الغرض من عنوان PURL ذي الرمز 302 هو إعلام متصفح الويب والمستخدم النهائي بضرورة استخدام هذا العنوان للوصول إلى المورد المطلوب، وليس عنوان URI النهائي. يتيح ذلك إمكانية الوصول المستمر إلى المورد في حال تغير عنوان PURL. يفضل بعض المشغلين استخدام عناوين PURL من النوع 301 (مما يشير إلى ضرورة استخدام عنوان URI النهائي في الطلبات اللاحقة).

يسمح عنوان PURL من نوع " سلسلة" بإعادة توجيه عنوان PURL إلى عنوان PURL آخر بنفس طريقة إعادة التوجيه 301 أو 302، مع اختلاف أن خادم PURL سيتولى عملية إعادة التوجيه داخليًا لزيادة الكفاءة. هذه الكفاءة مفيدة عند وجود العديد من عمليات إعادة التوجيه الممكنة؛ حيث تتوقف بعض متصفحات الويب عن متابعة عمليات إعادة التوجيه بمجرد الوصول إلى حد معين (في محاولة لتجنب الحلقات).

يُعدّ PURL من النوع 200 رابط PURL نشطًا ، حيث يشارك هذا الرابط بفعالية في إنشاء أو تجميع البيانات الوصفية المُسترجعة. يتضمن رابط PURL النشط بعض العمليات الحسابية لإنتاج مخرجاته. تمّ تطبيق روابط PURL النشطة في PURLz 2.0 ومشروع Callimachus . يُمكن استخدامها لجمع تقارير حالة وقت التشغيل، أو تنفيذ استعلامات موزعة، أو أي نوع آخر من جمع البيانات حيث يُراد مُعرّف ثابت. تعمل روابط PURL النشطة بشكل مشابه للإجراءات المخزنة في قواعد البيانات العلائقية. ^{[ 8 ]}

يُستخدم عنوان URL من النوع 303 لتوجيه عميل الويب إلى مورد يُقدّم معلومات إضافية حول المورد المطلوب، دون إعادة المورد نفسه. هذه الميزة مفيدة عندما يُستخدم عنوان URI لبروتوكول HTTP كمعرّف لكائن مادي أو مفاهيمي لا يمكن تمثيله كمورد معلومات. تُستخدم عناوين URL من النوع 303 غالبًا لإعادة التوجيه إلى البيانات الوصفية بتنسيق تسلسل إطار وصف الموارد (RDF)، ولها أهمية في الويب الدلالي ومحتوى البيانات المرتبطة . يتوافق استخدام رمز حالة HTTP 303 هذا مع توصية http-range-14 الصادرة عن مجموعة الهندسة المعمارية التقنية التابعة لاتحاد شبكة الويب العالمية . ^{[ 9 ]}

يُعلم عنوان URL من النوع 307 المستخدم بأن المورد موجود مؤقتًا على عنوان URL مختلف عن المعتاد. أما عناوين URL من النوعين 404 و410 فتشير إلى عدم العثور على المورد المطلوب، وتقدم بعض المعلومات لتوضيح سبب ذلك. ولإتمام الصورة، تم توفير دعم لرموز الاستجابة HTTP 307 (إعادة توجيه مؤقتة)، و404 (غير موجود)، و410 (غير موجود).

يتم توفير عناوين PURLs من النوعين 404 و410 لمساعدة المسؤولين في تحديد عناوين PURLs التي تتطلب إصلاحًا. تتيح عناوين PURLs من هذين النوعين مؤشرات أكثر فعالية لفشل تحديد الموارد عندما يتم نقل الموارد المستهدفة ولا يتم تحديد بديل مناسب لها.

تُستخدم عناوين PURL من النوع clone فقط أثناء إدارة PURL كطريقة ملائمة لنسخ سجل PURL موجود إلى PURL جديد.

تتضمن خدمة PURL مفهومًا يُعرف باسم إعادة التوجيه الجزئي. إذا لم يتطابق طلب ما مع عنوان PURL تمامًا، يتم فحص عنوان URL المطلوب لتحديد ما إذا كان جزء متصل من سلسلة PURL يطابق عنوان PURL مسجلًا. إذا كان الأمر كذلك، تتم إعادة التوجيه مع إضافة الجزء المتبقي من عنوان URL المطلوب إلى عنوان URL المستهدف. على سبيل المثال، لنفترض وجود PURL بعنوان URL http://purl.org/some/path/وعنوان URL مستهدف . ستؤدي http://example.com/another/path/محاولة إجراء عملية HTTP GET على عنوان URL إلى إعادة توجيه جزئي إلى . يتيح مفهوم إعادة التوجيه الجزئي الوصول إلى تسلسلات هرمية من موارد الويب عبر عناوين PURL دون الحاجة إلى عنوان PURL خاص بكل مورد. يكفي وجود PURL واحد ليكون بمثابة عقدة رئيسية لتسلسل هرمي على خادم مستهدف واحد. تستخدم خدمة PURL الجديدة النوع " partial" للدلالة على PURL الذي يُجري إعادة توجيه جزئية.http://purl.org/some/path/and/some/more/datahttp://example.com/another/path/and/some/more/data

لا تُخالف عمليات إعادة التوجيه الجزئية على مستوى مسار عنوان URL التفسيرات الشائعة لمواصفات HTTP 1.1. مع ذلك، لم يتم توحيد طريقة التعامل مع أجزاء عناوين URL عبر عمليات إعادة التوجيه، ولم يتم التوصل إلى إجماع بشأنها بعد. تُشير مُعرّفات الأجزاء إلى مؤشر لمعلومات أكثر تحديدًا داخل مورد، ويتم تحديدها بعد #فاصل في عناوين URI. ^{[ 10 ]}

يُعدّ التوجيه الجزئي في وجود مُعرّف جزء إشكاليًا نظرًا لاحتمالية وجود تفسيرين متضاربين. ^{[ 11 ]} إذا كان جزء مُرفقًا بعنوان URL من نوع "جزئي" ، فمن غير الواضح ما إذا كان ينبغي لخدمة PURL افتراض أن الجزء له معنى على عنوان URL المستهدف، أو تجاهله بافتراض أن موردًا ما قد يكون قد غيّر محتواه أيضًا، مما يُبطل الأجزاء المُعرّفة سابقًا. اقترح بوس الاحتفاظ بالأجزاء وتمريرها إلى عناوين URL المستهدفة أثناء عمليات إعادة توجيه HTTP التي تُنتج استجابات 300 (اختيار من متعدد)، أو 301 (نُقل بشكل دائم)، أو 302 (تم العثور عليه)، أو 303 (انظر أخرى)، ما لم يكن عنوان URL المستهدف المُحدد يتضمن مُعرّف جزء بالفعل. إذا كان مُعرّف الجزء موجودًا بالفعل في عنوان URL المستهدف، فيجب التخلي عن أي جزء في عنوان URL الأصلي. لم ينجح اقتراح بوس في التوافق مع معايير IETF، وانتهت صلاحيته دون مزيد من العمل. (دوبوست وآخرون). أعاد إحياء اقتراحات بوس في مذكرة صادرة عن اتحاد شبكة الويب العالمية (ليست معيارًا، بل توجيهًا في غياب معيار). ^{[ 12 ]} وقد فشل مصنّعو برامج تصفح الإنترنت "عمومًا" ^{[ 12 ]} في اتباع توجيهات بوس.

ابتداءً من سلسلة PURLz 1.0، تقوم خدمة PURL بتنفيذ عمليات إعادة التوجيه الجزئية التي تشمل معرفات الأجزاء عن طريق كتابة الأجزاء على عناوين URL المستهدفة في محاولة للامتثال لـ ^{[ 12 ]} وتجنب السلوك الإشكالي وغير المتسق من قبل موردي المتصفحات.

• أمثلة على التنفيذ:
  • مفتاح الموارد الأرشيفية (ARK)
  • معرّف الكائن الرقمي (DOI)
  • معالجة مُعرّفات النظام
• تعطل الرابط
• فهرس الوصول العام عبر الإنترنت (OPAC)
• رابط دائم
• إعادة توجيه عنوان URL
• اختصار عنوان URL
• اسم المورد الموحد (URN)
• آلة أرشيف الإنترنت

• الموقع الرسمي لـ PURLz
• الموقع الرسمي لمشروع كاليماخوس
• محلل روابط PURL التابع لأرشيف الإنترنت
• محلل عناوين PURL التابع لمكتب الطباعة الحكومي الأمريكي
• persistent-identifier.de
• موقع معلومات DPE/PURL ومحلل الروابط