Постоянный универсальный указатель ресурсов
Постоянный унифицированный указатель ресурса ( PURL ) — это унифицированный указатель ресурса на основе местоположения (URL) (т. е. унифицированный идентификатор ресурса или URI), который используется для перенаправления к местоположению запрошенного веб-ресурса . PURL перенаправляют HTTP- клиентов, используя коды состояния HTTP .
Первоначально PURL можно было узнать по адресу purl.org или по другим именам хостов, содержащим purl. Раньше многие из этих хостов использовали потомки оригинального системного программного обеспечения OCLC PURL. Однако со временем концепция PURL стала общей и использовалась для обозначения любой службы перенаправления (называемой PURL Resolver ), которая: [1]
- имеет «корневой URL-адрес» в качестве ссылки на преобразователь (например,
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 году. [2] Система PURL была реализована с использованием разветвленной версии Apache HTTP Server до 1.0 . Программное обеспечение было модернизировано и расширено в 2007 году компанией Zepheira по контракту с OCLC, а официальный веб-сайт переехал на http://purlz.org («Z» произошло от названия Zepheira и использовалось для отличия сайта программного обеспечения с открытым исходным кодом PURL от преобразователь PURL, управляемый OCLC).
Номера версий PURL могут показаться запутанными. OCLC выпустила версии 1 и 2 дерева исходного кода на основе Apache, первоначально в 1999 году под лицензией OCLC Research Public License 1.0, а затем под лицензией OCLC Research Public License 2.0 ( http://opensource.org/licenses/oclc2 ). Zepheira выпустила PURLz 1.0 в 2007 году под лицензией Apache, версия 2.0 . PURLz 2.0 был выпущен в стадии бета-тестирования в 2010 году, но выпуск так и не был завершен. Проект Callimachus внедрил PURL с момента выпуска версии 1.0 в 2012 году.
Самый старый сопоставитель HTTP PURL эксплуатировался 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 , в результате которого служба распознавания и ее интерфейс администрирования передаются в Internet Archive. [3] Служба поддерживается во вновь созданном программном обеспечении отдельно от всех предыдущих реализаций. Передача вновь включила возможность управлять определениями PURL, которые были отключены в службе, размещенной на OCLC, в течение нескольких месяцев. Служба, размещенная на серверах Интернет-архива, поддерживает доступ через purl.org, purl.net, purl.info, и purl.com. OCLC теперь перенаправляет DNS-запросы для purl.oclc.org к purl.org.
Принципы работы [ править ]
Концепция PURL позволяет осуществлять обобщенное управление URL-адресами HTTP URI во Всемирной паутине . 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 INFO . Все схемы постоянной идентификации предоставляют уникальные идентификаторы (возможно, изменяющиеся) виртуальных ресурсов, но не все схемы предоставляют возможности курирования. Курирование виртуальных ресурсов определяется как «активное участие специалистов в области информации в управлении, включая сохранение цифровых данных для будущего использования». [4]
PURL подвергались критике за необходимость разрешения URL-адреса, тем самым привязывая PURL к сетевому местоположению. Сетевые расположения имеют несколько уязвимостей, таких как регистрация в системе доменных имен и зависимости хостов. Неспособность разрешить PURL может привести к неоднозначному состоянию: будет неясно, не удалось ли разрешить PURL, потому что этому помешал сбой сети или потому, что он не существовал. [5]
PURL сами по себе являются допустимыми URL-адресами, поэтому их компоненты должны соответствовать спецификации URL-адреса. Часть схемы сообщает компьютерной программе, например веб-браузеру, какой протокол использовать при разрешении адреса. Для PURL обычно используется схема HTTP. Хост-часть сообщает, к какому серверу PURL подключаться. Следующая часть, домен PURL, аналогична пути к ресурсу в URL-адресе. Домен представляет собой иерархическое информационное пространство, которое разделяет PURL и позволяет PURL иметь разных сопровождающих. Один или несколько назначенных сопровождающих могут администрировать каждый домен PURL. Наконец, имя PURL — это имя самого PURL. Домен и имя вместе составляют «идентификатор» PURL.
Сравнение с постоянной ссылкой [ править ]
И постоянная ссылка , и PURL используются в качестве постоянного/постоянного URL-адреса и перенаправляют к местоположению запрошенного веб-ресурса . Грубо говоря, они одинаковы. Их различия заключаются в доменном имени и временном масштабе :
- обычно Постоянная ссылка не меняет домен URL-адреса и рассчитана на сохранение в течение многих лет .
- Доменное имя PURL может быть изменено независимо и рассчитано на сохранение в течение десятилетий .
Типы [ править ]
Наиболее распространенные типы PURL названы так, чтобы совпадать с кодом ответа HTTP, который они возвращают. Не все коды ответов HTTP имеют эквивалентные типы PURL, и не все серверы PURL реализуют все типы PURL. Некоторые коды ответов HTTP (например, 401, «Неавторизованный») имеют четкое значение в контексте HTTP-сообщения, но не применяются к процессу перенаправления HTTP. Трем дополнительным типам PURL («цепочка», «частичный» и «клон») присвоены мнемонические названия, связанные с их функциями.
| Тип | ПУЛ значение | Значение HTTP |
|---|---|---|
| 200 | Созданный или агрегированный контент | ХОРОШО |
| 301 | Постоянно перемещен на целевой URL. | Переехал навсегда |
| 302 | Простое перенаправление на целевой URL-адрес | Найденный |
| Цепь | Перенаправление на другой PURL на том же сервере | Найденный |
| Частичный | Перенаправление на целевой URL-адрес с добавленной информацией о конечном пути. | Найденный |
| 303 | Посмотреть другой URL | См. другое |
| 307 | Временное перенаправление на целевой URL | Временное перенаправление |
| 404 | Временно ушел | Не найдено |
| 410 | Навсегда ушел | Ушел |
| Клонировать | Скопируйте атрибуты существующего PURL | Н/Д |
Большинство PURL — это так называемые «простые PURL», которые обеспечивают перенаправление на нужный ресурс. Код состояния HTTP и, следовательно, тип PURL для простого PURL — 302. Назначение 302 PURL — информировать веб-клиента и конечного пользователя о том, что PURL всегда следует использовать для обращения к запрошенному ресурсу, а не к конечному пользователю. URI разрешен. Это необходимо для продолжения разрешения ресурса в случае изменения PURL. Некоторые операторы предпочитают использовать PURL типа 301 (что указывает на то, что окончательный URI должен указываться в будущих запросах).
PURL типа «цепочка» позволяет PURL перенаправляться на другой PURL способом, идентичным перенаправлению 301 или 302, с той разницей, что сервер PURL будет обрабатывать перенаправление внутри себя для большей эффективности. Эта эффективность полезна, когда возможно множество перенаправлений; поскольку некоторые веб-браузеры перестают следовать перенаправлениям при достижении установленного ограничения (в попытке избежать циклов).
PURL типа «200» является «Активным PURL», в котором PURL активно участвует в создании или агрегировании возвращаемых метаданных. Активный PURL включает в себя некоторые произвольные вычисления для получения результата. Активные PURL были реализованы в PURLz 2.0 и The Callimachus Project . Их можно использовать для сбора отчетов о состоянии выполнения, выполнения распределенных запросов или любого другого типа сбора данных, где желателен постоянный идентификатор. Активные PURL действуют аналогично хранимой процедуре в реляционных базах данных. [6]
PURL типа «303» используется для направления веб-клиента к ресурсу, который предоставляет дополнительную информацию о запрошенном ресурсе, без возврата самого ресурса. Эта тонкость полезна, когда запрошенный HTTP URI используется в качестве идентификатора физического или концептуального объекта, который не может быть представлен как информационный ресурс. PURL типа 303 чаще всего используются для перенаправления к метаданным в формате сериализации структуры описания ресурсов (RDF) и имеют отношение к семантической сети и связанному содержимому данных . Такое использование кода состояния HTTP 303 соответствует http-range-14 выводу Группы технической архитектуры Консорциума World Wide Web .
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 для URL-адреса 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-адреса, или отбрасывать его, полагая, что ресурс с измененным местоположением также мог измениться. содержимое, что делает недействительными фрагменты, определенные ранее. Бос предложил сохранять фрагменты и передавать их по целевым URL-адресам во время перенаправления HTTP, что приводит к ответам 300 (множественный выбор), 301 (перемещено навсегда), 302 (найдено) или 303 (см. другое), если только назначенный целевой URL-адрес уже не содержит фрагмент. идентификатор. Если идентификатор фрагмента уже присутствует в целевом URL-адресе, любой фрагмент исходного URL-адреса следует удалить. Предложение Боса не прошло по стандартизации IETF и истекло без дальнейшей работы. Дубост и др. возродил предложения Боса в заметке W3C (не стандарт, а руководство в случае отсутствия стандарта). [9] Производители веб-клиентов, таких как браузеры, «обычно» [9] не смог следовать указаниям Боса.
Начиная с серии PURLz 1.0, служба PURL реализует частичные перенаправления, включая идентификаторы фрагментов, записывая фрагменты в целевые URL-адреса, пытаясь соответствовать [9] и избегать проблемного и непоследовательного поведения производителей браузеров.
См. также [ править ]
- Примеры реализации:
- Ключ архивного ресурса (ARK)
- Идентификатор цифрового объекта (DOI)
- Обрабатывать системные идентификаторы
- Ссылка гнилая
- НЕПАКОВЫЙ
- Постоянная ссылка
- перенаправление URL-адресов
- Сокращение URL-адреса
- Единое имя ресурса (URN)
- Вейбэк-машина
Ссылки [ править ]
- ^ Такие сервисы, как URN LEX , ELI и DOI , Permalink и другие, прямо или косвенно используют концепцию PURL.
- ^ Вейбель, Стюарт; Июль, Эрик (1995). «PURLs для улучшения доступа в Интернет» . Информационный бюллетень OCLC (ноябрь/декабрь): 19 . Проверено 17 декабря 2021 г.
- ^ «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.
- ^ Якель, Э. (2007). «Цифровое курирование». OCLC Системы и услуги . 23 (4): 335–340. дои : 10.1108/10650750710831466 . S2CID 33219560 .
- ^ Мартин, Шон (30 июня 2006 г.). «Примечания по LSID URN/URI» . Консорциум Всемирной паутины ESW Wiki . Проверено 5 января 2011 г.
- ^ Хайланд-Вуд, Дэвид (1 июля 2008 г.). «Основы метаданных для управления жизненным циклом программных систем» . Школа информационных технологий и электротехники Университета Квинсленда . Проверено 5 января 2011 г.
{{cite journal}}: Для цитирования журнала требуется|journal=( помощь ) - ^ Бернерс-Ли, Т.; Филдинг, Р.; Масинтер, Л. (январь 2005 г.). «Единый идентификатор ресурса (URI): общий синтаксис, RFC 3986 (STD 66)» . IETF Рабочая группа по сетевым технологиям . дои : 10.17487/RFC3986 . S2CID 30973664 . Проверено 1 марта 2008 г.
{{cite journal}}: Для цитирования журнала требуется|journal=( помощь ) - ^ «Обработка идентификаторов фрагментов в перенаправленных URL-адресах, просроченный интернет-проект» . IETF Рабочая группа по сетевым технологиям . 30 июня 1999 г. Проверено 1 марта 2008 г.
- ^ Jump up to: Перейти обратно: а б с «Распространенные проблемы с пользовательским агентом, примечание W3C» . Консорциум Всемирной паутины . 06 февраля 2001 г. Проверено 1 марта 2008 г.