منبع یاب یکنواخت مداوم

یک منبع یاب یکنواخت دائمی ( PURL ) یک منبع یاب یکنواخت (URL) است (یعنی شناسه منبع یکنواخت مبتنی بر مکان یا URI) که برای تغییر مسیر به محل منبع وب درخواستی استفاده می شود . PURL ها مشتریان HTTP را با استفاده از کدهای وضعیت HTTP هدایت می کنند .

در اصل، PURL ها به دلیل میزبانی در purl.org یا سایر نام های میزبان حاوی purl. در اوایل بسیاری از میزبان های دیگر از نوادگان نرم افزار سیستم اصلی OCLC PURL استفاده می کردند. با این حال، در نهایت، مفهوم PURL عمومی شد و برای تعیین هر سرویس تغییر مسیر (به نام حل‌کننده PURL ) مورد استفاده قرار گرفت که: [1]

  • دارای یک "نشانی اینترنتی ریشه" به عنوان مرجع حل کننده (مثلا http://myPurlResolver.example);
  • ابزاری را برای جامعه کاربر خود فراهم می کند تا نام های جدید را در URL ریشه قرار دهد (به عنوان مثال http://myPurlResolver.example/name22).
  • ابزاری برای مرتبط کردن هر نام با URL آن (برای تغییر مسیر) و به روز رسانی این آدرس-URL فراهم می کند.
  • از ماندگاری URL ریشه و سرویس های حل کننده PURL اطمینان حاصل کنید (مثلاً با قرارداد) .

PURL ها برای مدیریت فرآیند حل URL استفاده می شوند، بنابراین مشکل URI های گذرا در طرح های URI مبتنی بر مکان مانند HTTP حل می شود. از نظر فنی وضوح رشته در PURL مانند وضوح URL SEF است . بقیه این مقاله در مورد سیستم PURL OCLC است که توسط OCLC (مرکز کتابخانه کامپیوتر آنلاین) پیشنهاد و پیاده سازی شده است.

تاریخ

مفهوم PURL توسط استوارت وایبل و اریک جول در OCLC در سال 1995 توسعه داده شد . این نرم افزار در سال 2007 توسط Zepheira تحت قرارداد با OCLC مدرن و توسعه یافت و وب سایت رسمی به http://purlz.org منتقل شد («Z» از نام Zepheira گرفته شد و برای متمایز کردن سایت نرم افزار منبع باز PURL از آن استفاده شد. حل کننده PURL که توسط OCLC کار می کند).

ممکن است شماره نسخه PURL گیج کننده در نظر گرفته شود. OCLC نسخه های 1 و 2 درخت منبع مبتنی بر آپاچی را در ابتدا در سال 1999 تحت مجوز OCLC Research Public License 1.0 و بعداً تحت مجوز OCLC Research Public License 2.0 (http://opensource.org/licenses/oclc2) منتشر کرد. Zepheira PURLz 1.0 را در سال 2007 تحت مجوز آپاچی، نسخه 2.0 منتشر کرد. PURLz 2.0 در آزمایش بتا در سال 2010 منتشر شد اما انتشار هرگز نهایی نشد. پروژه Callimachus از زمان انتشار 1.0 در سال 2012، PURL ها را اجرا کرد.

قدیمی‌ترین حل‌کننده PURL HTTP توسط OCLC از سال 1995 تا سپتامبر 2016 مورد استفاده قرار گرفت و purl.oclc.orgبه‌عنوان purl.org, purl.netو و purl.com.

دیگر حل‌کننده‌های قابل‌توجه PURL عبارتند از دفتر چاپ دولت ایالات متحده (http://purl.fdlp.gov)، که برای برنامه کتابخانه سپرده گذاری فدرال اداره می‌شود و از سال 1997 فعال بوده است.

مفهوم PURL در w3id.org استفاده می‌شود که ممکن است جایگزین سرویس‌های قدیمی PURL و فناوری‌های PURL شود.

در 27 سپتامبر 2016 OCLC همکاری خود را با Internet Archive اعلام کرد که منجر به انتقال سرویس Resolver و رابط مدیریت آن به Internet Archive شد. [3] این سرویس بر روی نرم افزارهای جدید ایجاد شده، جدا از همه پیاده سازی های قبلی پشتیبانی می شود. این انتقال توانایی مدیریت تعاریف PURL را که برای چندین ماه در سرویس میزبانی شده OCLC غیرفعال شده بودند، دوباره فعال کرد. سرویس میزبانی شده در سرورهای Internet Archive از دسترسی از طریق purl.org, purl.net, purl.info, و purl.com. OCLC اکنون درخواست های DNS را برای purl.oclc.orgبه purl.org.

اصول عملیات

مفهوم PURL اجازه می دهد تا URL های عمومی URI های HTTP را در شبکه جهانی وب انتخاب کنید . PURL ها امکان کنترل شخص ثالث را هم بر وضوح URL و هم بر ارائه ابرداده منبع فراهم می کنند.

URL به سادگی آدرس یک منبع در شبکه جهانی وب است. URL ثابت آدرسی در شبکه جهانی وب است که باعث هدایت مجدد به یک منبع وب دیگر می شود. اگر یک منبع وب مکان (و بنابراین URL) را تغییر دهد، یک PURL که به آن اشاره می کند می تواند به روز شود. یک کاربر یک PURL همیشه از یک آدرس وب استفاده می کند، حتی اگر منبع مورد نظر جابه جا شده باشد. PURL ها ممکن است توسط ناشران برای مدیریت فضای اطلاعاتی خود یا توسط کاربران وب برای مدیریت فضای خود استفاده شوند. یک سرویس PURL مستقل از ناشر اطلاعات است. بنابراین خدمات PURL امکان مدیریت یکپارچگی هایپرلینک را فراهم می کند. یکپارچگی هایپرلینک یک مبادله طراحی وب جهانی است، اما ممکن است تا حدی با اجازه دادن به کاربران منبع یا اشخاص ثالث برای تأثیرگذاری بر مکان و نحوه حل یک URL بازیابی شود.

یک PURL ساده با پاسخ دادن به یک درخواست HTTP GET با برگرداندن پاسخی از نوع 302 (معادل کد وضعیت HTTP 302، به معنی "یافت شده") کار می کند. پاسخ حاوی یک عنوان HTTP "Location" است که مقدار آن یک URL است که مشتری باید متعاقباً از طریق یک درخواست HTTP GET جدید بازیابی کند.

PURL ها یک شکل از شناسه پایدار را برای منابع مجازی پیاده سازی می کنند. دیگر طرح‌های شناسایی پایدار شامل شناسه‌های دیجیتال شی (DOI)، شناسه‌های علوم زیستی (LSID) و URI‌های اطلاعاتی هستند . همه طرح‌های شناسایی مداوم، شناسه‌های منحصربه‌فردی را برای منابع مجازی (احتمالاً در حال تغییر) ارائه می‌کنند، اما همه طرح‌ها فرصت‌هایی را فراهم نمی‌کنند. مدیریت منابع مجازی به این صورت تعریف شده است: "درگیری فعال متخصصان اطلاعات در مدیریت، از جمله حفظ، داده های دیجیتال برای استفاده در آینده." [4]

PURL ها به دلیل نیاز به حل یک URL مورد انتقاد قرار گرفته اند، بنابراین یک PURL را به یک مکان شبکه گره می زنند. مکان های شبکه دارای چندین آسیب پذیری هستند، مانند ثبت نام دامنه و وابستگی هاست. شکست در حل یک PURL می تواند منجر به یک حالت مبهم شود: مشخص نیست که آیا PURL حل نشد زیرا یک خرابی شبکه مانع از آن شده است یا به دلیل وجود نداشتن آن. [5]

PURL ها خود URL های معتبری هستند، بنابراین اجزای آنها باید با مشخصات URL نقشه برداری کنند. بخش طرح به یک برنامه کامپیوتری مانند یک مرورگر وب می گوید که از کدام پروتکل هنگام حل آدرس استفاده کند. طرح مورد استفاده برای PURL ها به طور کلی HTTP است. قسمت میزبان می گوید که به کدام سرور PURL متصل شود. بخش بعدی، دامنه PURL، مشابه مسیر منبع در URL است. دامنه یک فضای اطلاعاتی سلسله مراتبی است که PURL ها را از هم جدا می کند و به PURL ها اجازه می دهد نگهدارنده های مختلفی داشته باشند. یک یا چند نگهدارنده تعیین شده ممکن است هر دامنه PURL را مدیریت کنند. در نهایت، نام PURL نام خود PURL است. دامنه و نام با هم "id" PURL را تشکیل می دهند.

مقایسه با پیوند ثابت

هم پیوند ثابت و هم PURL به عنوان URL دائمی/دائمی استفاده می شوند و به محل منبع وب درخواستی هدایت می شوند . به طور کلی، آنها یکسان هستند. تفاوت آنها در مورد نام دامنه و مقیاس زمانی است :

  • یک پیوند دائمی معمولاً دامنه URL را تغییر نمی دهد و به گونه ای طراحی شده است که در طول سال ها باقی بماند .
  • یک نام دامنه PURL به طور مستقل قابل تغییر است و به گونه ای طراحی شده است که در طول دهه ها باقی بماند .

انواع

متداول ترین انواع PURL ها به گونه ای نام گذاری می شوند که با کد پاسخ HTTP که برمی گردانند منطبق باشد. همه کدهای پاسخ HTTP دارای انواع PURL معادل نیستند و همه سرورهای PURL همه انواع PURL را اجرا نمی کنند. برخی از کدهای پاسخ HTTP (به عنوان مثال 401، غیر مجاز) معانی واضحی در زمینه یک مکالمه HTTP دارند، اما در فرآیند هدایت مجدد HTTP کاربرد ندارند. به سه نوع دیگر از PURL ها ("زنجیره"، "جزئی" و "کلون") نام های یادگاری مربوط به عملکرد آنها داده شده است.

انواع PURL
تایپ کنید معنی PURL معنی HTTP
200 محتوای ایجاد شده یا جمع آوری شده است خوب
301 به طور دائم به یک URL هدف منتقل شد به طور دائم منتقل شد
302 تغییر مسیر ساده به یک URL هدف پیدا شد
زنجیر به PURL دیگری در همان سرور هدایت شوید پیدا شد
جزئي به یک URL هدف با اطلاعات مسیر انتهایی ضمیمه شده است پیدا شد
303 آدرس دیگر را ببینید دیگر را ببینید
307 تغییر مسیر موقت به یک URL هدف تغییر مسیر موقت
404 موقتا رفته پیدا نشد
410 برای همیشه رفته رفته
شبیه ویژگی های یک PURL موجود را کپی کنید N/A

اکثر PURL ها به اصطلاح "PURL های ساده" هستند که یک هدایت مجدد به منبع مورد نظر ارائه می دهند. کد وضعیت HTTP، و از این رو از نوع PURL، یک PURL ساده 302 است. هدف از PURL 302 این است که به مشتری وب و کاربر نهایی اطلاع دهد که PURL همیشه باید برای آدرس دادن به منبع درخواستی استفاده شود، نه منبع نهایی. URI حل شد. این برای اجازه دادن به وضوح ادامه منبع در صورت تغییر PURL است. برخی از اپراتورها ترجیح می دهند از PURL های نوع 301 استفاده کنند (که نشان می دهد URI نهایی باید در درخواست های بعدی آدرس دهی شود).

یک PURL از نوع "زنجیره" به یک PURL اجازه می دهد تا به PURL دیگری به روشی مشابه با تغییر مسیر 301 یا 302 تغییر مسیر دهد، با این تفاوت که یک سرور PURL تغییر مسیر را به صورت داخلی برای کارایی بیشتر انجام می دهد. این کارایی زمانی مفید است که تغییر مسیرهای زیادی امکان پذیر باشد. از آنجایی که برخی از مرورگرهای وب پس از مواجه شدن با محدودیت تعیین شده (در تلاش برای جلوگیری از حلقه ها) تغییر مسیرها را دنبال نمی کنند.

یک PURL از نوع "200" یک "PURL فعال" است که در آن PURL فعالانه در ایجاد یا تجمیع ابرداده های بازگشتی شرکت می کند. یک PURL فعال شامل مقداری محاسبات دلخواه برای تولید خروجی آن است. PURL های فعال در PURLz 2.0 و پروژه Callimachus پیاده سازی شده اند. آنها ممکن است برای جمع آوری گزارش های وضعیت زمان اجرا، انجام پرس و جوهای توزیع شده یا هر نوع دیگر از جمع آوری داده ها که در آن یک شناسه پایدار مورد نظر است استفاده شود. PURL های فعال مشابه یک رویه ذخیره شده در پایگاه های داده رابطه ای عمل می کنند. [6]

یک PURL از نوع "303" برای هدایت یک سرویس گیرنده وب به منبعی استفاده می شود که اطلاعات اضافی را در مورد منبع درخواستی آنها بدون برگرداندن خود منبع ارائه می دهد. این ظرافت زمانی مفید است که HTTP URI درخواست شده به عنوان شناسه یک شی فیزیکی یا مفهومی که نمی تواند به عنوان یک منبع اطلاعاتی نمایش داده شود، استفاده می شود. PURLهای نوع 303 اغلب برای تغییر مسیر به ابرداده در قالب سریالی چارچوب شرح منابع (RDF) استفاده می شوند و برای محتوای وب معنایی و داده های پیوندی مرتبط هستند. این استفاده از کد وضعیت 303 HTTP با یافته http-range-14 گروه فنی معماری کنسرسیوم وب جهانی مطابقت دارد .

یک PURL از نوع "307" به کاربر اطلاع می دهد که منبع به طور موقت در یک URL متفاوت از معمول قرار دارد. PURL های انواع 404 و 410 توجه داشته باشند که منبع درخواستی یافت نشد و اطلاعاتی را برای دلیل این کار پیشنهاد می کند. پشتیبانی از کدهای پاسخ HTTP 307 (تغییر مسیر موقت)، 404 (یافت نشد) و 410 (رفته) برای کامل بودن ارائه شده است.

PURL هایی از انواع "404" و "410" برای کمک به مدیران در علامت گذاری PURL هایی که نیاز به تعمیر دارند ارائه می شوند. PURL ها از این نوع، زمانی که منابع هدف جابجا شده اند و جایگزین مناسبی شناسایی نشده اند، نشانه های کارآمدتری از شکست شناسایی منبع را امکان پذیر می کنند.

PURL های نوع "کلون" صرفاً در طول مدیریت PURL به عنوان روشی مناسب برای کپی کردن یک رکورد PURL موجود در یک PURL جدید استفاده می شود.

تغییر مسیر قطعات URL

سرویس PURL شامل مفهومی است که به عنوان تغییر مسیر جزئی شناخته می شود. اگر درخواستی دقیقاً با PURL مطابقت نداشته باشد، URL درخواستی بررسی می شود تا مشخص شود که آیا بخشی از قسمت جلویی به هم پیوسته رشته PURL با PURL ثبت شده مطابقت دارد یا خیر. در این صورت، با اضافه شدن باقیمانده URL درخواستی به URL مورد نظر، تغییر مسیر رخ می دهد. به عنوان مثال، یک PURL با URL http//purl.org/some/path/ با یک URL هدف http://example.com/another/path/ در نظر بگیرید. تلاش برای انجام عملیات HTTP GET در نشانی اینترنتی http//purl.org/some/path/and/some/more/data منجر به هدایت بخشی به http://example.com/another/path/and/ می‌شود. برخی / بیشتر / داده ها مفهوم تغییر مسیر جزئی به سلسله مراتب منابع مبتنی بر وب اجازه می دهد تا از طریق PURL ها بدون اینکه هر منبع به PURL خود نیاز داشته باشد، پرداخته شود. یک PURL برای خدمت به عنوان یک گره سطح بالا برای یک سلسله مراتب در یک سرور هدف کافی است. سرویس جدید PURL از نوع "جزئی" برای نشان دادن PURL استفاده می کند که تغییر مسیر جزئی را انجام می دهد.

تغییر مسیرهای جزئی در سطح مسیر URL، تفسیرهای رایج از مشخصات HTTP 1.1 را نقض نمی کند. با این حال، مدیریت قطعات URL در سراسر تغییر مسیرها استاندارد نشده است و هنوز توافقی به وجود نیامده است. شناسه های قطعه یک اشاره گر به اطلاعات خاص تر در یک منبع را نشان می دهد و به دنبال یک جداکننده # در URI ها تعیین می شوند. [7]

تغییر مسیر جزئی در حضور یک شناسه قطعه مشکل ساز است زیرا دو تفسیر متضاد امکان پذیر است. [8]اگر یک قطعه به یک PURL از نوع "جزئی" متصل شود، آیا سرویس PURL باید فرض کند که قطعه در URL هدف معنی دارد یا باید آن را با این فرض که منبعی با مکان تغییر یافته ممکن است محتوا را نیز تغییر داده باشد، کنار بگذارد. باطل کردن قطعات تعریف شده قبلی؟ Bos پیشنهاد کرد که قطعات باید حفظ شوند و در طول تغییر مسیرهای HTTP به URL های هدف منتقل شوند که منجر به 300 پاسخ (چند انتخاب)، 301 (به طور دائم جابجا شده)، 302 (پیدا شده) یا 303 (به سایرین مراجعه کنید) شود، مگر اینکه یک URL هدف تعیین شده قبلاً شامل یک قطعه باشد. مشخص کننده. اگر یک شناسه قطعه از قبل در یک URL هدف وجود داشته باشد، هر قطعه در URL اصلی باید رها شود. متأسفانه، پیشنهاد Bos نتوانست مسیر استانداردهای IETF را طی کند و بدون کار بیشتر منقضی شد. دوبوست و همکارانپیشنهادات Bos را در یادداشت W3C احیا کرد (نه یک استاندارد، بلکه راهنمایی در غیاب استاندارد). [9] سازندگان سرویس گیرنده های وب مانند مرورگرها "به طور کلی" [9] از راهنمایی Bos پیروی نکرده اند.

با شروع سری PURLz 1.0، سرویس PURL تغییر مسیرهای جزئی شامل شناسه های قطعه را با نوشتن قطعات بر روی URL های هدف در تلاش برای مطابقت با [9] و جلوگیری از رفتار مشکل ساز و ناسازگار توسط فروشندگان مرورگر پیاده سازی می کند.

همچنین ببینید

منابع

  1. ^ خدماتی مانند URN LEX ، ELI و DOI ، پیوند ثابت و دیگران، آنها به طور مستقیم یا غیرمستقیم از مفهوم PURL استفاده می کنند.
  2. ^ ویبل، استوارت؛ جول، اریک (1995). "PURL برای بهبود دسترسی به اینترنت". خبرنامه OCLC (نوامبر/دسامبر): 19 . بازبینی شده در 17 دسامبر 2021 .
  3. «OCLC و Internet Archive با هم کار می کنند تا پایداری URL های پایدار در آینده را تضمین کنند» (نسخه مطبوعاتی). دوبلین، اوهایو: OCLC. 27 سپتامبر 2016. بایگانی شده از نسخه اصلی در 2 فوریه 2023 . بازبینی شده در 10 آوریل 2023 . OCLC و Internet Archive امروز نتایج یک تلاش مشترک یک ساله را برای اطمینان از پایداری آینده purl.org اعلام کردند. این سازمان‌ها برای ایجاد یک سرویس پایدار جدید که توسط Internet Archive میزبانی می‌شود، همکاری کرده‌اند که URL‌های دائمی و تغییر مسیرهای زیر دامنه را برای purl.org، purl.com، purl.info و purl.net مدیریت می‌کند.
  4. ^ یاکل، ای. (2007). "کیوریشن دیجیتال". سیستم ها و خدمات OCLC . 23 (4): 335-340. doi :10.1108/10650750710831466. S2CID  33219560.
  5. مارتین، شان (2006-06-30). "یادداشت های LSID URN/URI". کنسرسیوم وب جهانی ESW Wiki . بازیابی شده در 2011-01-05 .
  6. هایلند وود، دیوید (01-07-2008). "مبانی فراداده برای مدیریت چرخه حیات سیستم های نرم افزاری". دانشکده فناوری اطلاعات و مهندسی برق، دانشگاه کوئینزلند . بازیابی شده در 2011-01-05 . {{cite journal}}: مجله استناد نیاز دارد |journal=( کمک )
  7. ^ برنرز لی، تی. فیلدینگ، آر. Masinter, L. (ژانويه 2005). "شناسه منبع یکسان (URI): Generic Syntax، RFC 3986 (STD 66)". کارگروه شبکه IETF . doi :10.17487/RFC3986 . بازیابی شده در 01-03-2008 . {{cite journal}}: مجله استناد نیاز دارد |journal=( کمک )
  8. «Handling of Fragment Identifiers in Redirected URLs, Internet Minded Draft». کارگروه شبکه IETF . 30-06-1999 . بازیابی شده در 01-03-2008 .
  9. ^ abc "مشکلات مشترک عامل کاربر، یادداشت W3C". کنسرسیوم وب جهانی 06-02-2001 . بازیابی شده در 01-03-2008 .

لینک های خارجی

  • وب سایت رسمی برای PURLz
  • وب سایت رسمی پروژه Callimachus
  • حل‌کننده PURL بایگانی اینترنت
  • حل‌کننده PURL اداره چاپ دولت ایالات متحده
  • persistent-identifier.de
  • اطلاعات DPE/PURL و سایت Resolver