Handle System

Handle System (Хендл Систем, Система Дескрипторів) — це власний реєстр ^[en], який призначає ^[en], або дескриптори, інформаційним ресурсам, а також робить можливим ідентифікацію за допомогою «цих дескрипторів інформації, необхідної для пошуку, доступу та іншого використання ресурсів».

Подібно до дескрипторів, що використовуються в інших обчисленнях, дескриптори Handle System непрозорі й не кодують інформацію про основний ресурс, прив'язуючись лише до метаданих про ресурс. Отже, дескриптори не стають недійсними через зміни метаданих.

Система була розроблена (Бобом Каном) у Корпорації національних дослідницьких ініціатив (англ. CNRI). Початкова робота була профінансована Агентством передових оборонних дослідницьких проектів (англ. DARPA) між 1992 і 1996 роками як частина ширшої структури для розподілених цифрових об'єктних сервісів і, таким чином, збіглася у часі з раннім розгортанням Всесвітньої павутини, яка мала схожі цілі.

Handle System була вперше запроваджена восени 1994 року, і нею керувала корпорація CNRI до грудня 2015 року, коли було введено новий режим роботи «мульти-основний адміністратор» (MPA). На даний момент фундація DONA адмініструє систему глобального реєстру дескрипторів та акредитує MPA, включаючи CNRI та Міжнародний фонд DOI. Наразі система забезпечує базову інфраструктуру для таких систем на основі дескрипторів, як Digital Object Identifiers і DSpace, які в основному використовуються для надання доступу до наукових, професійних і державних документів та інших інформаційних ресурсів.

CNRI надає специфікації та вихідний код для еталонних реалізацій для серверів і протоколів, які використовуються в системі, згідно з безоплатною «Публічною ліцензією», яка схожа на ліцензію з відкритим вихідним кодом.

Зараз працюють тисячі служб обробки. Понад 1000 із них знаходяться в університетах і бібліотеках, але вони також діють у національних лабораторіях, дослідницьких групах, державних установах і комерційних підприємствах, щомісяця отримуючи понад 200 мільйонів запитів на обробку дескрипторів^[].

Технічні характеристики

Handle System визначена в інформаційних RFC 3650, 3651 і 3652 Інженерно-технічної групи Інтернету (IETF); визначення включає відкритий набір протоколів, простір імен і еталонну реалізацію протоколів. Документація, програмне забезпечення та відповідна інформація надаються CNRI на спеціальному веб-сайті.

Дескриптори складаються з префікса, який ідентифікує «орган іменування», і суфікса, який дає «локальне ім'я» ресурсу. Подібно до доменних імен, префікси надаються органам іменування одним із «мульти-основних адміністраторів» системи після сплати комісії, яку потрібно щорічно поновлювати. Орган іменування може створити будь-яку кількість дескрипторів з унікальними «локальними іменами» в межах призначених їм префіксів. Приклад дескриптора:

• 20.1000/100
• 2381/12345

Перший приклад — це дескриптор для ліцензії на програмне забезпечення HANDLE.NET, 20.1000 — це префікс, призначений органу іменування (у цьому випадку — самому Handle.net), а 100 — це локальне ім'я в цьому просторі імен. Локальна назва може складатися з будь-яких символів із набору символів Unicode UCS-2. Префікс також складається з будь-яких символів UCS-2, крім «/». Префікси складаються з одного або кількох сегментів органів іменування, розділених крапками, що представляють ієрархію органів іменування. Таким чином, у прикладі 20 є префіксом органу іменування для CNRI, тоді як 1000 позначає підлеглий орган іменування в межах префікса 20. Інші приклади префіксів верхнього рівня для федеративних органів іменування фундації DONA: 10 для дескрипторів DOI; 11 для дескрипторів, призначених ITU; 21 для дескрипторів, виданих німецьким Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG), науковим обчислювальним центром Геттінгенського університету; і 86 для китайської коаліції Handle Services. Старіші «застарілі» префікси, видані CNRI до того, як було запроваджено структуру «мульти-основного адміністратора» (MPA), як правило, складаються з чотирьох із п'яти цифр, як у другому прикладі вище — дескрипторі, яким керує ^[en]. Усі префікси мають бути зареєстровані в Глобальному Реєстрі Дескрипторів через реєстратора, схваленого фундацією DONA, як правило, за окрему плату.

Як і в інших випадках використання дескрипторів в обчислювальній техніці, дескриптор непрозорий (англ. opaque), тобто він не кодує інформацію про основний ресурс і надає лише засоби для отримання метаданих про ресурс.

Цей підхід відрізняється від уніфікованого локатора ресурсу (URL), який може кодувати в ідентифікаторі такі атрибути ресурсу, як протокол, який буде використовуватися для доступу до сервера, що містить ресурс, ім'я хоста сервера та номер порту та, можливо, навіть такі особливості розташування, як ім'я файлу у файловій системі сервера, що містить ресурс. У підході, застосованому в Handle System, ці особливості не закодовані в дескрипторі, а містяться в метаданих, до яких прив'язаний дескриптор.

Метадані можуть включати багато атрибутів інформаційного ресурсу, наприклад його розташування, форми, в яких він доступний, типи доступу (наприклад, «безкоштовний» чи «платний»), і перелік тих, хто може отримати доступ до ресурсу. Обробка метаданих для визначення того, як і де можна отримати доступ до ресурсу, а також надання ресурсу користувачеві виконуються на окремому етапі, який називається «вирішення» (англ. resolution), за допомогою «Резолвера» (англ. Resolver) — сервера, який може відрізнятися від серверів, що беруть участь в обміні дескрипторами, які посилаються на метадані. На відміну від URL-адрес, які можуть стати недійсними, якщо метадані, вбудовані в них, стають недійсними, дескриптори не стають недійсними, і їх не потрібно змінювати, коли змінюються розташування або інші атрибути метаданих. Це допомагає запобігти вимиранню посилань, оскільки зміни інформаційного ресурсу (наприклад, місцеположення) мають відображатися лише в змінах метаданих, і не призводять до змін у посиланні на ресурс.

Кожен дескриптор може мати власного адміністратора, і адміністрування дескрипторів може здійснюватися в розподіленому середовищі, подібному до доменних імен DNS. Дані асоціації «ім'я-значення» також можуть бути захищені підписами для перевірки даних або за допомогою процедури виклик-відповідь для перевірки передачі даних, що дозволяє використовувати дескриптори в додатках для управління довірою.

Один і той самий основний інформаційний ресурс може бути пов'язаним з кількома дескрипторами, наприклад, коли дві університетські бібліотеки генерують дескриптори (і, отже, можливо, різні набори метаданих) для однієї книги.

Handle System сумісна з системою доменних імен (DNS), але не потребує її, на відміну від постійних ідентифікаторів, таких як ^[en] або ^[en], які подібні до дескрипторів, але використовують доменні імена. Проте, на відміну від підходів на основі доменних імен, дескриптори вимагають окремого процесу реєстрації префікса та серверів дескрипторів, окремих від серверів доменних імен.

Дескриптори можна записувати у власній формі запису або виражати як уніфіковані ідентифікатори ресурсів (URI) через простір імен у ^[en]; наприклад, 20.1000/100 можна записати як URI, info:hdl/20.1000/100 . Деякі простори імен Handle System, такі як ідентифікатори цифрових об'єктів, самі по собі є просторами імен URI "info: "; наприклад, info:doi/10.1000/182 — це інший спосіб запису дескриптора для поточної версії DOI Handbook як URI.

Деякі простори імен Handle System визначають спеціальні правила представлення. Наприклад, цифрові ідентифікатори об'єктів, які представляють значний відсоток наявних дескрипторів, зазвичай представлені префіксом "doi: ": doi:10.1000/182.

Будь-який дескриптор може бути виражений як уніфікований локатор ресурсів (URL) через використання загального проксі-сервера HTTP:

• https://hdl.handle.net/20.1000/100

Деякі системи на основі дескрипторів пропонують HTTP проксі-сервер, призначений для використання з їхньою власною системою, наприклад:

• https://doi.org/10.1000/182 .

Реалізація

Реалізація Handle System складається з локальних служб дескрипторів, кожна з яких складається з одного або кількох сайтів, які надають сервери, які зберігають певні дескриптори. Глобальний реєстр дескрипторів — це унікальна служба локальних дескрипторів, яка зберігає інформацію про префікси (також відомі як органи іменування) в Handle System; ця служба відповідає на запити про місцезнаходження певних дескрипторів в інших службах локальних дескрипторів у цій розподіленій системі.

Веб-сайт Handle System надає ряд інструментів реалізації, зокрема програмне забезпечення HANDLE.NET і клієнтські бібліотеки HANDLE.NET. Клієнти Handle можуть бути вбудовані в програмне забезпечення кінцевого користувача (наприклад, веб-браузер) або в серверне програмне забезпечення (наприклад, веб-сервер), розширення вже доступні для Adobe Acrobat і Firefox.

Бібліотеки клієнтського програмного забезпечення Handle доступні як для C, так і для Java. Для деяких програмних пакетів були створені спеціальні інструменти доповнення, наприклад, для системи DOI.

Відкрита для взаємодії мережа розподілених серверів розпізнавання дескрипторів (також відома як система проксі-серверів) пов'язана через глобальний резолвер (який є єдиною логічною сутністю, але фізично децентралізованою та дубльованою). Користувачі технології Handle System отримують префікс дескриптора, створений у глобальному реєстрі дескрипторів. Глобальний реєстр дескрипторів підтримує та розпізнає префікси локально підтримуваних служб дескрипторів. Таким чином, будь-яка локальна служба дескрипторів може розпізнати будь-який дескриптор через глобальний резолвер.

Дескриптори (ідентифікатори) передаються клієнтом у вигляді запиту про орган іменування/префікс до глобального реєстру дескрипторів (ГРД) Handle System. ГРД відповідає, надсилаючи клієнту інформацію про місцезнаходження відповідної локальної служби обробки (яка може складатися з кількох серверів, розташованих в різних місцях); потім запит надсилається на відповідний сервер у службі локальної обробки. Служба локальної обробки повертає інформацію, необхідну для отримання ресурсу, наприклад, URL-адресу, яку потім можна перетворити на перенаправлення HTTP. (Примітка: якщо клієнт уже має інформацію про відповідний ГРД для запиту, початковий запит до ГРД пропускається).

Хоча початкова модель, з якої походить Handle System, стосувалася керування цифровими об'єктами, Handle System не вимагає жодної конкретної моделі зв'язків між ідентифікованими об'єктами, а також не обмежується ідентифікацією лише цифрових об'єктів: в системі можуть бути представлені нецифрові об'єкти як відповідний цифровий об'єкт для управління цим цифровим об'єктом. Потрібна певна обережність у визначенні таких об'єктів і їхнього відношення до нецифрових об'єктів; існують усталені моделі, які можуть допомогти у таких визначеннях, наприклад, ^[en], (CIDOC CRM) та ^[en]. Деякі програми використовують цю структуру в комбінації з програмним забезпеченням дескриптора: наприклад, ініціатива Advanced Distributed Learning (ADL) об'єднує Handle System з існуючими стандартами для розподіленого навчального контенту, використовуючи еталонну модель об'єкта спільного використання (англ. Shareable Content Object Reference Model (SCORM)); реалізація системи ідентифікатора цифрових об'єктів (DOI) Handle System прийняла її разом із структурою ^[en] для роботи з ^[en].

Handle System також чітко вказує на важливість організаційного дотримання схеми постійного ідентифікатора, але не вимагає єдиної моделі для забезпечення такого дотримання. Окремі програми можуть застосовувати власні набори правил і соціальної інфраструктури для забезпечення постійності (наприклад, при використанні в додатках DSpace і DOI).

Принципи проектування

Handle System розроблена відповідно до наступних вимог, щоб сприяти постійності

Строка ідентифікатора:

• не базується на будь-яких змінних атрибутах сутності (місцезнаходження, приналежність або будь-який інший атрибут, який може змінюватися без зміни ідентифікатора референта);
• не містить значущих внутрішніх елементів (бажано «англ. dumb number»: добре відомий шаблон може призводити до припущень, які можуть вводити в оману, а значуща семантика може не перекладатися різними мовами та може спричинити конфлікт торгових марок);
• є унікальною у системі (щоб уникнути колізій і референційної невизначеності);
• має необов'язкові, але корисні функції, які слід підтримувати (читабельна для людини, легка для копіюваня та вставки, може бути вбудована; сумісна зі звичайними системами, наприклад, специфікацією URI).

Механізм розпізнавання ідентифікатора:

• є надійним (використовує резервування, відсутність окремих точок відмови та достатньо швидкий, щоб не виглядати пошкодженим);
• є масштабованим (більші навантаження просто обробляються більшою кількістю комп'ютерів);
• є гнучким (може адаптуватися до мінливих обчислювальних середовищ; може бути корисним для нових програм):
• є надійним (і розпізнавання, і адміністрування мають технічні методи довіри; експлуатуюча організація зобов'язана діяти довгостроково);
• побудовано на відкритій архітектурі (заохочення зусиль спільноти для створення додатків на інфраструктурі);
• є прозорим (користувачам не потрібно знати подробиці інфраструктури).

Застосування

Серед об'єктів, які наразі ідентифікуються дескрипторами, є журнальні статті, технічні звіти, книги, тези та дисертації, державні документи, метадані, розподілений навчальний контент і набори даних. Дескриптори використовуються в додатках цифрових водяних знаків, ^[en], репозиторіях тощо. Хоча окремі користувачі можуть завантажувати та використовувати програмне забезпечення HANDLE.NET незалежно, багато користувачів визнали корисним співпрацювати в розробці додатків у федерації, використовуючи спільну політику або додаткові технології для надання спільних послуг. Як одна з перших постійних схем ідентифікації, Handle System була широко прийнята державними та приватними установами та перевірена протягом кількох років (див. парадигма, постійні ідентифікатори).

Додатки, побудовані на основі Handle System, можуть використовувати дескриптори як прості постійні ідентифікатори (найчастіше використання — визначення поточної URL-адреси об'єкта), або можуть використовувати інші властивості. Підтримка одночасного повернення кількох фрагментів поточної інформації, пов'язаної з об'єктом, у визначених структурах даних, дає змогу встановлювати пріоритети для порядку, у якому визначаються кілька дескрипторів. Таким чином, дескриптори можуть бути визначені для різних цифрових версій того самого вмісту, для дзеркальних версій сайтів або для різних бізнес-моделей (платних або безкоштовних, захищених або відкритих, публічних або приватних). Вони також можуть створювати різні цифрові версії різного вмісту, наприклад поєднання об'єктів, необхідних для курсу дистанційного навчання.

Сьогодні існують тисячі тисячі сервісів обробки, розташованих у 71 країні на 6 континентах; понад 1000 з них працюють в університетах і бібліотеках. Послуги з обробки надають федерації користувачів, національні лабораторії, університети, обчислювальні центри, бібліотеки (національні та місцеві), урядові установи, підрядники, корпорації та дослідницькі групи. Основні видавці використовують Handle System для постійної ідентифікації комерційного вмісту та вмісту з відкритим доступом за допомогою системи цифрового ідентифікатора об'єктів.

Кількість префіксів, які дозволяють користувачам призначати дескриптори, зростає і станом на початок 2014 року становить понад 12 000. Існує шість серверів Global Handle Registry верхнього рівня, які отримують (в середньому) 68 мільйонів запитів на обробку на місяць. Проксі-сервери, які відомі CNRI, що передають запити до системи в Інтернеті, отримують (в середньому) 200 мільйонів запитів на обробку на місяць (статистика отримана з Handle Quick Facts).

У 2010 році CNRI та Міжнародна спілка електрозв'язку уклали угоду про співпрацю щодо використання Handle System (і архітектури цифрових об'єктів загалом) і працюють над конкретними деталями цієї співпраці; у квітні 2009 року Міжнародна спілка електрозв'язку назвала Handle System «новою тенденцією».

Ліцензії та політика використання

Handle System, HANDLE.NET і Global Handle Registry є товарними знаками ^[en] (CNRI), некомерційної дослідницької корпорації в США. Handle System є предметом патентів CNRI, яка ліцензує свою технологію Handle System згідно з публічною ліцензією, подібною до ліцензії з відкритим вихідним кодом, щоб забезпечити ширше використання технології. Інфраструктура Handle System підтримується реєстрацією префікса та платою за обслуговування, причому більшість платежів надходить від власників одного префікса. Найбільше внесків на даний момент надходить від Міжнародного фонду DOI. Публічна ліцензія дозволяє комерційне та некомерційне використання за невисоку вартість як запатентованої технології, так і еталонної реалізації програмного забезпечення, а також дозволяє вільно вбудовувати програмне забезпечення в інші системи та продукти. Угода про надання послуг також доступна для користувачів, які мають намір надавати послуги ідентифікації та/або обробки дескрипторів за допомогою технології Handle System згідно з публічною ліцензією Handle System.

Супутні технології

Handle System представляє кілька компонентів довгострокової архітектури цифрових об'єктів. У січні 2010 року CNRI випустила своє програмне забезпечення Digital Object Repository загального призначення, ще один важливий компонент цієї архітектури. Наявна додаткова інформація про випуск, включаючи специфікацію протоколу, вихідний код і готову до використання систему, клієнтів і утиліти.

Див. також

• ^[en] (ARK)
• Електронна бібліотека
• Електронне видавництво
• Гіпертекст
• Інституційний репозитарій
• ^[en]
• (OpenURL)
• ^[en]
• ^[en]
• Resource Description Framework
• Семантична павутина
• Uniform Resource Name

Примітки

1. Lannom, L.; Boesch, B. (November 2003). Handle System Overview. datatracker.ietf.org (англ.). IETF. RFC 3650. Процитовано 20 червня 2024.
2. Kahn/Wilensky Architecture (англ.). CNRI. 13 травня 1995. Процитовано 13 березня 2013.
3. DONA Foundation. dona.net (англ.).
4. Digital Object Identifier System. doi.org (англ.).
5. Redirect to Current Handle.Net web site content. handle.net (англ.). Процитовано 15 March 2018.
6. Sun, S.; Reilly, S.; Lannom, L. (November 2003). Handle System Namespace and Service Definition. datatracker.ietf.org (англ.). IETF. RFC 3651. Процитовано 20 червня 2024.
7. Sun, S.; Reilly, S.; Lannom, L.; Petrone, J. (November 2003). Handle System Protocol (ver 2.1) Specification. datatracker.ietf.org (англ.). IETF. RFC 3652. Процитовано 20 червня 2024.
8. handle.net (англ.). handle.net. Процитовано 13 березня 2013.
9. About "info" URIs – Frequently Asked Questions (англ.). Info-uri.info. Процитовано 13 березня 2013.
10. Van de Sompel, H.; LANL; Hammond, T.; NPG; Neylon, E.; Manifest Solutions; Weibel, S.; OCLC (April 2006). The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces. datatracker.ietf.org (англ.). IETF. RFC 4452. Процитовано 21 червня 2024.
11. (англ.). doi:10.1000/182. Архів оригіналу за 16 September 2022.
12. HDL.NET Services: Proxy Server System (англ.). Handle.net. Процитовано 13 березня 2013.
13. HS Software Download (англ.). Handle.net. Процитовано 13 березня 2013.
14. Software Client Libraries (англ.). Handle.net. Процитовано 13 березня 2013.
15. HDL Plug-in for Adobe Acrobat and Acrobat Reader (англ.). Handle.net. Процитовано 13 березня 2013.
16. . handle.net (англ.). Архів оригіналу за 5 вересня 2015.
17. DOI System Tools (англ.). Doi.org. 12 липня 2012. Процитовано 13 березня 2013.
18. adlnet.gov (англ.). adlnet.gov. Процитовано 13 березня 2013.
19. . adlnet.gov (англ.). Архів оригіналу за 14 червня 2008.
20. doi.org (англ.). doi.org. 8 січня 2013. Процитовано 13 березня 2013.
21. (англ.). Oscars.org. 24 серпня 2012. Архів оригіналу за 30 березня 2013. Процитовано 13 березня 2013.
22. (англ.). paradigm. 2 січня 2008. Архів оригіналу за 29 березня 2013. Процитовано 13 березня 2013.
23. Handle System (англ.). Itu.int. 16 квітня 2010. Процитовано 13 березня 2013.
24. LICENSE (PDF) (англ.). www.handle.net. Процитовано 11 травня 2020.
25. dorepository.org (англ.). dorepository.org. 8 січня 2013. Процитовано 13 березня 2013.
26. Digital Object Repository Server: A Component of the Digital Object Architecture (англ.). Dlib.org. 4 лютого 2010. Процитовано 13 березня 2013.
27. Reilly S, Tupelo-Schneck R (January 2010). Digital Object Repository Server: A Component of the Digital Object Architecture. ^[en] (англ.). DO Repository. 16 (1/2). doi:10.1045/january2010-reilly. ISSN 1082-9873. Процитовано 13 березня 2013.
28. Cordra. cordra.org (англ.).

Посилання

• Офіційний сайт