Постоянный универсальный указатель ресурсов - Википедия - Persistent uniform resource locator

"PURL" перенаправляется сюда. Чтобы узнать о других значениях слова "purl", см. Purl (значения).

А постоянный унифицированный указатель ресурсов (PURL) это единый указатель ресурсов (URL) (т.е. на основе местоположения единый идентификатор ресурса или URI), который используется для перенаправить до места запрошенного веб-ресурс. Перенаправление PURL HTTP клиенты, использующие Коды состояния HTTP.

В Концепция PURL является универсальным и может использоваться для обозначения любой службы перенаправления (с именем Преобразователь PURL) который:[1]

  • имеет "корневой URL" в качестве решатель ссылка (например, http: //myPurlResolver.example);
  • предоставляет возможность своему сообществу пользователей включать новые имена в корневом URL (например, http: //myPurlResolver.example/name22);
  • предоставляет средства для связи каждого имя с его URL-адресом (для перенаправления) и для обновления этого URL-адреса перенаправления;
  • обеспечить постоянство (например, по контракту) корневого URL и Преобразователь PURL Сервисы.

PURL используются для управления процессом разрешения URL, тем самым решая проблему временных URI в основанных на местоположении Схемы URI как HTTP. Технически разрешение строки на PURL похоже SEF URL разрешающая способностьОстальная часть статьи посвящена системе PURL OCLC, предложенной и реализованной OCLC (Центр компьютерной онлайн-библиотеки).

История

Концепция PURL была разработана в OCLC в 1995 году и система PURL была реализована с использованием разветвленной версии до 1.0 HTTP-сервер Apache. Программное обеспечение было модернизировано и расширено в 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 году, но выпуск так и не был завершен. В Каллимах Проект реализовал PURL в версии 1.0 в 2012 году.

Самый старый 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. Услуга поддерживается новым программным обеспечением, отдельно от всех предыдущих реализаций. Передача снова активировала возможность управления определениями PURL, которые были отключены в службе, размещенной на OCLC, на несколько месяцев. Сервис, размещенный на серверах Internet Archive, поддерживает доступ через 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. Все схемы постоянной идентификации предоставляют уникальные идентификаторы для (возможно изменяющихся) виртуальных ресурсов, но не все схемы предоставляют возможности курирования. Курирование виртуальных ресурсов определяется как «активное участие специалистов в области информации в управлении, включая сохранение, цифровых данных для будущего использования».[2]

PURL критиковали за необходимость разрешать URL-адрес, тем самым привязывая PURL к сетевому местоположению. Сетевые местоположения имеют несколько уязвимостей, таких как регистрации в системе доменных имен и зависимости хостов. Неспособность разрешить PURL может привести к неоднозначному состоянию: неясно, не удалось ли разрешить PURL, потому что отказ сети предотвратил это или потому, что он не существовал.[3]

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, Unauthorized) имеют четкое значение в контексте разговора HTTP, но не применяются к процессу перенаправления HTTP. Трем дополнительным типам PURL («цепочка», «частичный» и «клон») даны мнемонические имена, связанные с их функциями.

Типы PURL
ТипЗначение PURLЗначение HTTP
200Созданный или агрегированный контентOk
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 Каллимах Проект. Их можно использовать для сбора отчетов о состоянии выполнения, выполнения распределенных запросов или любого другого типа сбора данных, где требуется постоянный идентификатор. Активные PURL действуют аналогично хранимая процедура в реляционных базах данных.[4]

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 типа «clone» используются исключительно во время администрирования 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 / и / some / more / data приведет к частичному перенаправлению на http://example.com/another/path/and/ некоторые / еще / данные. Концепция частичного перенаправления позволяет адресовать иерархии веб-ресурсов через PURL, при этом каждый ресурс не требует своего собственного PURL. Одного PURL достаточно, чтобы служить узлом верхнего уровня для иерархии на одном целевом сервере. Новая служба PURL использует тип «частичный» для обозначения PURL, который выполняет частичное перенаправление.

Частичные перенаправления на уровне URL-пути не нарушают общепринятые интерпретации спецификации HTTP 1.1. Однако обработка фрагментов URL-адресов при перенаправлении не стандартизирована, и консенсус еще не достигнут. Идентификаторы фрагментов указывают указатель на более конкретную информацию в ресурсе и обозначаются как следующие за разделителем # в URI.[5]

Частичное перенаправление при наличии идентификатора фрагмента проблематично, поскольку возможны две конфликтующие интерпретации.[6] Если фрагмент прикреплен к PURL типа «частичный», если служба PURL предполагает, что фрагмент имеет значение для целевого URL, или если она отбрасывает его, полагая, что ресурс с измененным расположением также мог изменить содержимое, таким образом сделать недействительными фрагменты, определенные ранее? Bos предположил, что фрагменты следует сохранять и передавать по целевым URL-адресам во время перенаправления HTTP, что приводит к ответам 300 (множественный выбор), 301 (перемещено окончательно), 302 (найдено) или 303 (см. Другое), если указанный целевой URL уже не включает фрагмент. идентификатор. Если идентификатор фрагмента уже присутствует в целевом URL-адресе, следует отказаться от любого фрагмента в исходном URL-адресе. К сожалению, предложение Боса не смогло пройти по дорожке стандартов IETF и истекло без дальнейшей работы. Дубость и другие. воскресил предложения Бос в заметке W3C (не стандарт, а руководство в отсутствие стандарта).[7] Создатели веб-клиентов, например браузеров, "обычно"[7] не последовал указаниям Боса.

Начиная с серии PURLz 1.0, служба PURL реализует частичные перенаправления, включая идентификаторы фрагментов, записывая фрагменты в целевые URL-адреса в попытке соответствовать[7] и избежать проблемного и непоследовательного поведения поставщиков браузеров.

Смотрите также

Рекомендации

  1. ^ Услуги как URN LEX, ELI и DOI, Постоянная ссылка и другие, они прямо или косвенно используют концепцию PURL.
  2. ^ Якель Э. (2007). «Цифровое курирование». Системы и услуги OCLC. 23 (4): 335–340. Дои:10.1108/10650750710831466.
  3. ^ Мартин, Шон (30.06.2006). "LSID URN / URI Примечания". Консорциум World Wide Web ESW Вики. Получено 2011-01-05.
  4. ^ Хайленд-Вуд, Дэвид (2008-07-01). «Основы метаданных для управления жизненным циклом программных систем». Школа информационных технологий и электротехники, Университет Квинсленда. Получено 2011-01-05. Цитировать журнал требует | журнал = (помощь)
  5. ^ «Универсальный идентификатор ресурса (URI): общий синтаксис, RFC 3986 (STD 66)». IETF Сетевая рабочая группа. Январь 2005 г.. Получено 2008-03-01.
  6. ^ «Обработка идентификаторов фрагментов в перенаправленных URL-адресах, черновик с истекшим сроком действия». IETF Сетевая рабочая группа. 1999-06-30. Получено 2008-03-01.
  7. ^ а б c «Общие проблемы с пользовательским агентом, примечание W3C». Консорциум World Wide Web. 2001-02-06. Получено 2008-03-01.

внешняя ссылка