ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

МЕНЕДЖМЕНТ ЯЗЫКОВЫХ РЕСУРСОВ

Постоянная идентификация и устойчивый доступ

ISO 24619:2011 Language resource management — Persistent identification and sustainable access (IDT)

Издание официальное

Москва

Стандартинформ

2015

Предисловие

1    ПОДГОТОВЛЕН ЗАО «Проспект» на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 55 «Терминология, элементы данных и документация в бизнес-процессах и электронной торговле»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 8 ноября 2013 г. № 1388-ст

4    Настоящий стандарт идентичен международному стандарту ИСО 24619:2011 «Менеджмент языковых ресурсов. Постоянная идентификация и устойчивый доступ» (ISO 24619:2011 «Language resource management — Persistent identification and sustainable access»).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)

© Стандартинформ, 2015

Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии

Настоящий стандарт распространяется на способы формирования машиночитаемых уникальных ссылок на электронные ресурсы. На рисунке 1 отображен постоянный идентификатор, включенный в исходный ресурс и указывающий на целевой (требуемый) ресурс. Этот РЮ может ассоциироваться с разнообразными метаданными.

В данном случае характер ресурса определен очень широко, и средства обращения к нему подлежат уточнению в соответствующем контексте. Например, изображение может быть независимым ресурсом, который снабжен своим собственным уникальным РЮ и может запрашиваться непосредственно, или оно может быть вложено в документ, где не имеет собственного идентификатора, и тогда оно является компонентом документа. Кроме того, ссылка может указывать на часть этого изображения. Отдельный ресурс в одной рабочей среде может рассматриваться как самостоятельный, а в другой — как раздел комбинированного ресурса. Внутренняя часть ресурса может считаться его конечной частью, но дальнейшая обработка такой части в динамической среде может привести к тому, что появится объект, который сам будет содержать доступные для запроса разделы нижележащего уровня. Настоящий стандарт предназначен для обеспечения поддержки всех таких ситуаций.

В случае комплексных языковых ресурсов некоторые из них должны снабжаться собственными индивидуальными неизменными идентификаторами. При этом другие ресурсы действуют как вложенные, состоящие из множества составляющих, и тогда содержащему их ресурсу должен присваиваться собственный РЮ, а его разделы могут запрашиваться посредством добавления к этому РЮ идентификаторов разделов. Настоящим стандартом устанавливаются руководящие принципы выбора надлежащего подхода применительно к любому заданному ресурсу.

В настоящем стандарте обобщаются опыт использования существующих стандартов и достижения сложившейся практики применения различных форматов идентификаторов разделов и фрагментов ресурсов; на этой основе предлагаются руководящие принципы принятия решений в тех ситуациях, когда существующие стандарты оказываются неадекватными или просто неприменимы. Более подробное обсуждение типов ресурсов, охватываемых настоящим стандартом, можно найти ниже, в приложении А.

Применительно к коллекциям языковых ресурсов далее выделяются два типа коллекций:

-    Коллекции ресурсов, которые поддерживаются как публикуемые комплексные ресурсы в режиме, близком к статическому, таким образом, что сама коллекция как таковая определяется архивом или репозиторием как независимый объект и получает постоянный идентификатор соответствующего типа. Организация, которой принадлежит архив, отвечает за обеспечение связи между РЮ и коллекцией, представленной, например, как элемент метаданных в каталоге.

-    Другой тип коллекции, которая изначально не рассматривалась создателями или архивными организациями как таковая, однако близка к достижению статуса комплексного ресурса в результате проведения научно-исследовательской или какой-то иной работы, в ходе которой требуется проверять достоверность информации, как, например, при подготовке монографии или выполнении научного проекта. Коллекции такого типа, хотя они и создаются авторами целенаправленно, могут не иметь никакой практической ценности вне контекста первоначальной работы, под которую создавались. Переход от научных документов к коллекции может стать громоздким уже при объеме коллекции в несколько сотен отдельных ресурсов. В результате этого появляется необходимость обращения к коллекциям такого типа с помощью постоянного идентификатора РЮ, который ассоциируется со всеми составляющими коллекцию ресурсами и надлежащими метаданными. Очевидно, что рассмотренный способ обращения к коллекции возможен лишь в том случае, если она реализована должным образом.

5 Требования к инфраструктуре и использованию постоянных идентификаторов

5.1    Общие сведения

Существующие стандарты и достижения сложившейся практики использования ссылок и цитат, главным образом, в сфере языковых ресурсов можно найти в приложении А, а в настоящем разделе сначала подробно рассматриваются требования к самой инфраструктуре РЮ, а затем формулируются требования к применению РЮ в качестве средства запроса и цитирования языковых ресурсов.

5.2    Требования к инфраструктуре постоянных идентификаторов

5.2.1 Общие положения

Инфраструктура РЮ должна поддерживать следующие функциональные возможности:

а) преобразование одиночного РЮ к множеству URI или служб;

6

ГОСТ Р ИСО 24619-2013

b)    установление связи с релевантными метаданными и обеспечение доступа к ним;

c)    адекватная защита для предотвращения злоумышленного или случайного изменения отображений PID/URI и связей РЮ/метаданные;

d)    адресация разделов ресурса (идентификаторы разделов или фрагментов, либо те и другие);

e)    кодирование РЮ как URI для представления идентификаторов как активируемых в среде веб-документов без требования изменений на стороне клиента.

5.2.2    Обеспечение возможности дублирования ресурсов

В целях защиты данных и обеспечения высокоскоростного доступа принято предоставлять дубликаты либо образы ресурсов или резидентные копии на серверах разных ресурсов. Инфраструктура PID должна поддерживать такой вид дублирования, разрешая ассоциирование многих URI с единственным РЮ.

5.2.3    Доступ к метаданным ресурса

Помимо предоставления надежного URI для ресурса, инфраструктура РЮ используется также для высоконадежной защищенной привязки метаданных к ресурсу. Хотя настоящий стандарт не требует наличия доступных метаданных какого-либо конкретного типа, в нем все же устанавливается требование возможности преобразования РЮ к соответствующей записи в формате XML, на основе которой может строиться работа других служб.

5.2.4    Надежное защищенное администрирование

Инфраструктура РЮ должна обеспечивать адекватную защиту, с тем чтобы только владелец или блюститель ресурса имели возможность изменить отображение PID/URI или ассоциируемые с ним метаданные.

5.2.5    Идентификаторы разделов ресурсов

Невозможно предоставить РЮ для каждого идентифицируемого раздела ресурса или даже просто определить в глобальном масштабе все возможные варианты разделения ресурсов на части. Следовательно, инфраструктуры РЮ должны обеспечивать систему присваивания идентификаторов разделам или фрагментам в комбинации с РЮ-идентификатором ресурса. Поскольку цель здесь состоит в том, чтобы использовать для идентификации разделов ресурса единственную строку, синтаксис РЮ должен поддерживать операцию конкатенации РЮ и идентификатора раздела. Например, система разрешения РЮ должна допускать такое конфигурирование, чтобы комбинация идентификатора раздела РЮ преобразовывалась в идентификатор URI, который может правильно интерпретироваться сервером ресурса для выдачи запрошенного раздела ресурса [см. раздел А.2,а].

1839/A#z Рисунок 2 — Обработка идентификаторов разделов резольвером РЮ (на примере реализации сервера дескрипторов)

Комбинированный ресурс «А» с составляющими х, у и z идентифицируется в рамках РЮ как «1839/А».

Резольвер РЮ преобразует идентификатор «1839/А» к URI вида http://oserver/objectA, который может распознаваться сервером как запрос на предоставление объекта «А». Раздел «z» ресурса «А» идентифицируется РЮ как «1839/A#z». Для простоты процедуры разыменования, выполняемой сервером ресурса, резольвер РЮ должен быть способен к преобразованию идентификатора «1839/A#z» в URI вида http://oserver/obiectA?part=z или в какую-то похожую запросную строку, из которой серверу объекта А будет понятно, что требуется предоставить раздел «z».

7

5.2.6 Унифицированные РЮ-идентификаторы

Инфраструктура РЮ должна предоставлять реализацию промежуточного резольвера, который способен разрешать постоянные идентификаторы PID, закодированные как URI. Это позволяет сетевым клиентам преобразовывать такой идентификатор с использованием схемы HTTP, не прибегая к специальным браузерным вставкам или другим специализированным программным средствам. В некоторых инфраструктурах сами РЮ изначально представляют собой универсальные указатели ресурсов HTTP, и в таких случаях промежуточные резольверы адресов становятся излишними.

5.3    Использование постоянных идентификаторов

Ссылки на доступные в сети Интернет электронные языковые ресурсы должны сопровождаться постоянным идентификатором РЮ, который преобразуется либо непосредственно к URI запрашиваемого ресурса, либо к метаинформационной записи, характеризующей требуемый ресурс. Последний вариант может использоваться в том случае, если сам ресурс не может быть сделан непосредственно доступным или представляет собой коллекцию, применительно к которой метаинформационная запись должна содержать идентификаторы для составляющих ресурсов коллекции.

Если РЮ превращается в URI ресурса, то метаинформационная запись формата XML, совместимая с объявленной схемой, принадлежащей ресурсу, должна ассоциироваться с идентификатором и делаться доступной через систему преобразования. Цитируемая информация подлежит включению в метаинформационную запись. Никакие другие требования к записи метаданных, связанной с идентификатором ресурса, не определяются.

В веб-документах идентификатор (например, описатель), вложенный в ссылки, должен помимо соответствия синтаксической схеме РЮ еще и присутствовать в форме закодированного URI, с тем чтобы он активизировался в веб-браузере или в другом приложении для визуального просмотра документов. Например, таким приложением может быть реализация Handle System (HS):

1839/00-0000-0000-0000-4 -> http://hdl.handle.net/1839/00-0000-0000-0000-0000-4

Адрес резольвера http://hdl.handle.net указывает на промежуточный преобразователь HTTP, который выступает в роли приложения, способного получать HTTP-запросы в виде идентификаторов РЮ, преобразованных в URI, и использовать «реальный» резольвер РЮ для перенаправления клиента к запрошенному ресурсу. В примере с технологией Handle System промежуточный преобразователь HTTP является либо центральным интерфейсным модулем резольвера Handle System, либо интерфейсным модулем резольвера, доступ к которому гарантируется поставщиком ресурса.

Спецификации разделов ресурсов, аналогичные спецификациям страниц или разделов, подлежат присоединению всюду, где это возможно, к релевантному РЮ с помощью соответствующего разделительного знака — например, с использованием стандартного расширения HS:

1839/00-0000-0000-0000-4@time(100s.200s)

Это расширение представляет собой ссылку на сегмент аудиофайла (где идентификатор раздела — не стандартный).

Если совместимый идентификатор фрагмента существует для данного типа ресурса, такой элемент может быть добавлен к закодированному URI с целью создания составного активируемого идентификатора. Для технологии HS примером может быть следующий идентификатор:

httD://handle.net/1839/00-0000-0000-0000-0000-4?urlaDDend=#ffD(track Ю=101 Y*mp(/~timernpt^l.'50¹’))

В этом примере используется специальная функция «urlappend» промежуточного преобразования абстрактного идентификатора к разрешенному дескриптору.

5.4    Цитируемая информация и постоянные идентификаторы

Лучшие достижения сложившейся практики могут быть реализованы лишь при условии, что идентификаторы URI заменены идентификаторами РЮ, а спецификации разделов документа преобразованы в идентификаторы разделов или фрагментов. Ссылки из веб-документов должны также содержать РЮ, закодированный как URI, если синтаксис РЮ не согласуется со схемой URI, зарегистрированной IANA [13].

5.5    Обращение к разделам ресурсов

5.5.1 Общие замечания

В качестве идентификатора раздела ресурса может использоваться любой существующий идентификатор, определенный стандартом ИСО или IETF, если не оговорено иное. Применительно к ресурсам, для которых таких стандартов нет, разрешается использовать удобный для прочтения человеком

ГОСТ Р ИСО 24619-2013

цитируемый текст; например, для интервала времени это может быть «от 10 до 120 с». Однако такой подход неприменим в случае клиентских программ.

При использовании идентификаторов разделов или фрагментов для извлечения или разыменования раздела ресурса важно четко понимать разницу между применением идентификаторов фрагментов, аналогичных определенным в стандарте IETF RFC 3986, и функциональных возможностей сервера соответствующего ресурса. Если, например, процесс разрешения идентификаторов РЮ возвращает URI, содержащий в себе идентификатор фрагмента со следующим URI (в котором фрагмент содержит спецификацию, отвечающую рекомендациям IETF RFC 5147 для носителя с открытым текстом):

http://mvserver/myresource#line= 10,20,

то такой URI приведет к выборке браузером целостного документа, а уже сам браузер выделит затем часть документа, содержащую строки с 10-й по 20-ю, и представит их пользователю. При малом размере документа такой ход операций приемлем; однако в случае необходимости представления фрагмента из файла, хранимого на носителе емкостью 2 Гб, возникает потребность в использовании специального сервера ресурса и такого URI, который имеет спецификацию разделов, определенную в Annodex [22]:

http://videoserver.com/videoA.anx?t= 15.0/30.0

Такая запись будет инициировать передачу сервером ресурса только видеосегмента, записанного в интервале от 15-й до 30-й секунды.

Ожидается, что по мере обновления настоящего стандарта список применимых форматов идентификаторов разделов и фрагментов ресурсов будет расширяться.

5.5.2    Носители данных (по интервалам времени)

Стандарт ИСО/МЭК 21000-17, касающийся ресурсов формата MPEG-21, должен применяться к информационным носителям и временным интервалам. Для определения временных интервалов в запросах URI и фрагментах может использоваться синтаксис Annodex [22] применительно к любым используемым информационным носителям. Для других форматов идентификатор фрагментов ресурса будет зависеть от используемого формата.

5.5.3    Текстуальные ресурсы

К текстовым ресурсам формата XML должна применяться технология XPointer. Для документов с открытым текстом действует стандарт IETF RFC 5147. Для других форматов идентификатор разделов ресурса будет зависеть от используемого формата.

5.5.4    Реестры метаданных, терминология и онтологии

Согласно ИСО 12620:2009, спецификация каждой категории данных в рамках Реестра категорий данных DCR (Data Category Registry), который ведется в ИСО ТК 37, должна иметь собственный PID, формируемый как идентификатор целостного DCR. Эти постоянные идентификаторы конфигурируются как «слабые» URI [30], что является сложившейся практикой для Консорциума Всемирной паутины (World Wide Web Consortium).

Конкретные части графа RDF могут адресоваться с помощью одного из предложенных запросных языков RDF, однако какой-либо определенной спецификации на данный момент нет. Для других форматов идентификатор раздела ресурса будет зависеть от используемого формата.

5.6 Коллекции

Существующие «опубликованные» коллекции должны снабжаться соответствующим PID, который поддерживается организатором коллекции. При этом PID должен обращаться к представляющему коллекцию описанию, которое может быть записью каталога или отдельным описанием метаданных. В случае виртуальных коллекций PID должен обращаться к машиночитаемому описанию метаданных, которое обеспечивает доступ к релевантной информации и, в частности, к ресурсам, имеющим свои собственные PID.

6 Дополнительные требования

6.1 Разбиение идентификаторов

Применительно к разбиению в настоящем стандарте различаются идентификаторы разделов и идентификаторы фрагментов, как показано в 5.5. Идентификатор фрагмента определяется в IETF RFC 3986 как необязательный компонент ссылки URI. Согласно IETF RFC 3986, URI может снабжаться факультативным идентификатором фрагмента, в соответствии с которым он отделяется от

9

остальной части ссылки URI знаком решетки «#». Сам разделитель не считается частью идентификатора фрагмента.

URI с идентификатором фрагмента может использоваться приложением для идентификации конкретного ресурса и, как правило, последующего доступа к этому ресурсу, который является разделом первичного ресурса или вложен в него. Формат идентификатора фрагмента зависит от типа ресурса.

Интерпретация и разыменование идентификатора фрагмента является функцией веб-клиента и, следовательно, требует загрузки полного первичного ресурса, после чего клиентское приложение получает возможность извлечь запрошенный фрагмент. Кроме того, поскольку идентификатор фрагмента в интервале его извлечения не пересылается другим системам, некоторые «посреднические» модули сетевой архитектуры (как, например, программы-агенты) никак не взаимодействуют с идентификаторами фрагментов, и при переадресации HTTP фрагменты не принимаются в расчет. Исключение составляют идентификаторы фрагментов для RDF-документов, которые содержат ссылки не на их части, а на конкретный объект документа, описанный как объект с идентификатором фрагмента. Благодаря этому использование идентификаторов фрагментов в сочетании с URI позволяет клиентскому приложению выделять разделы ресурса на основе учета специфических сведений клиентского приложения.

В противоположность процедурам разрешения фрагментов использование такого идентификатора раздела, как, например, «z» в ссылке

http://myserver/mvObiectService?part=z. рассчитано на то, что удаленный сервер выделит только часть ресурса и перешлет ее клиентскому приложению¹).

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

Настоящий стандарт поддерживает различные уровни разбиения ресурсов. Для обеспечения надлежащей эффективности этого процесса и совместимости с другими схемами именования служат приведенные ниже рекомендации.

-    Если для какого-то типа ресурсов уже существует схема идентификации, как, например, номер ISBN для книги, этот уровень разбиения должен сохраняться, то есть не следует создавать новые идентификаторы PID без должного обоснования необходимости такого действия (например, для глав книги). Главы должны предпочтительно адресоваться с использованием идентификаторов разделов в сочетании с PID-идентификатором книги.

-    Если ресурс ассоциируется со всем информационным содержимым (контентом) цифрового файла, то такому ресурсу, скорее всего, должен присваиваться индивидуальный PID.

-    Если ресурс независим и существует вне более широкого контекста, то такому ресурсу должен присваиваться индивидуальный PID.

-    Если какой-то ресурс должен цитироваться в отрыве от своего контейнера, то такому ресурсу должен присваиваться индивидуальный PID.

Эти рекомендации, однако, зависят от конкретных потребностей создателей ресурсов, которые сами определяют уровень разбиения, подходящий для их конкретной ресурсной среды.

^ Такое четкое разделение ролей между сетевым клиентом и сервером при разыменовании фрагментов может измениться. Рабочая группа по мультимедийным фрагментам разработала проект W3C, в котором предлагается, чтобы сетевые клиенты «договаривались» о транспортировке с сервера только раздела ресурса [27].

ГОСТ Р ИСО 24619-2013

Приложение А (справочное)

Автономные ресурсы, агрегированные ресурсы и разделы ресурсов

А.1 Общий обзор

А.1.1 Общие замечания

В науке и в промышленной сфере все острее ощущается потребность в непротиворечивом и постоянном обращении к электронным языковым ресурсам и их частям, а также к коллекциям таких ресурсов. При этом желательно не только иметь возможность извлечения и контроля нужной информации из научных публикаций, но и поддерживать различные типы перекрестных ссылок между языковыми ресурсами или их частями.

А.1.2 Ресурсы

Ресурсом называется всякая сущность, обладающая собственной индивидуальностью [7]. Несмотря на неопределенность такой характеристики, она важна для исследователей, которые стремятся идентифицировать лингвистически значимые единицы как связанные объекты репозитория для обеспечения удобства считывания их человеком и все чаще — машинным способом. Такие объекты должны участвовать в отдельных манипуляциях и использоваться в различных сценариях, а это означает, что они могут существовать автономно в более пространных контекстах. Зачастую подобный объект может идентифицироваться как «одиночный файл» в файловой системе, однако он может также извлекаться как включенный объект (например, как запись данных) из системы управления базой данных. Такие ресурсы могут относиться к различным типам или иметь разные форматы:

-    оцифрованные видеозаписи интервью;

-    аудиозапись песни;

-    комплексная аннотация сеанса коммуникации;

-    фотография, документирующая речевое событие;

-    словарь для определенного языка;

-    описание грамматики;

-    запись траектории движения глаза при исследовании процесса чтения;

-    описание метаданных ресурса или коллекции ресурсов;

-    интегрированный документ, содержащий тексты и фотографии и др.

Объем такого ресурса оставляется на усмотрение его создателя. Некоторые ресурсы образуются группой аннотаций разного уровня, тогда как другие могут создаваться для каждого уровня аннотирования с учетом тех или иных научных и управленческих аспектов. Например, для многих ресурсов метаданные могут храниться в единственной крупной реляционной базе данных. В таких случаях «описание метаданных» существует только как результат запроса, и не вовлекается никакой идентифицируемый ресурс, поскольку запрашиваемым ресурсом является целостная база данных. Подобный сценарий говорит о необходимости поиска способов адресации разделов такого ресурса.

Когда уникальный и постоянный идентификаторы ассоциируются с ресурсами, требуется, чтобы сами ресурсы тоже оставались неизменными. Рассматриваемый репозиторий предоставляет ресурс с уникальным идентификатором для гарантии того, что при разрешении ссылки будет обслуживаться именно «исходный контент» (здесь не учитываются аспекты пользовательского интерфейса, который может со временем изменяться и выдавать ту же самую содержательную информацию в ином виде, хотя это может влиять на ее интерпретацию). Когда контент ресурса изменяется в результате какой-либо манипуляции, он образует новый ресурс, так как приобретает новую индивидуальность, которая отделена от предыдущей версии ресурса. Динамические базы данных, постоянно меняющие свою индивидуальность именно таким образом, считаются образованными из «снимков мгновенных состояний» (snapshots), которые и должны быть объектами ссылок. Любые зависимости между такими снимками могут выражаться соответствующими метаданными, например специфицируемыми связями, цитируемой информацией или тем и другим вместе.

А.1.3 Связки ресурсов

Иногда в репозиториях содержится указание на то, что некоторые из его ресурсов тесно связаны в соответствии с тем или иным формальным критерием. Примерами могут служить:

-    сделанные одновременно аудио- и видеозаписи одинаковой длительности, которые могут включать в себя другие записи, созданные параллельно и снабженные касающимися их аннотациями; все эти ресурсы относятся к одному и тому же временному периоду и сделаны в одном месте, что тесно объединяет их, и пользователи часто хотят получать доступ к таким ресурсам как к единому целому;

-    словарь, содержащий фотографии или другие мультимедийные ресурсы, которые расширяют словарные статьи; в этом случае может оказаться желательным обращение к тесно связанным объектам как к единому пакету;

-    корпус текстов с соответствующими внешними аннотациями;

-    корпус исторических текстов с соответствующими факсимиле.

11

Как правило, подобные связки должны конфигурироваться как воплощение их группового статуса, обычно представляемого совместным метаинформационным описанием, в котором расставлены указатели на все составляющие ресурсы.

А.1.4 Коллекции ресурсов

Коллекции — это произвольные группировки любого числа ресурсов с индивидуальными идентификаторами, подобранными в соответствии с конкретным критерием, но запрашиваемые тем не менее как единое целое. Примерами таких коллекций могут служить:

-    опубликованный корпус речевых оборотов голландского языка (Dutch National Spoken Corpus) или британского варианта английского языка (British National Corpus) по состоянию на определенную дату;

-    коллекция всех ресурсов, описывающих конкретный язык, хранимая в определенном репозитории;

-    коллекция разрозненных ресурсов, используемая как основа для диссертационного исследования или написания монографии;

-    коллекция ресурсов, объединенных с целью сохранения их как сжатого пакета¹* в электронном архиве;

-    коллекции разделов ресурса — например ссылок на ряд сегментов мультимедийного файла и т. п.

Связи между ресурсами коллекции могут быть произвольными. Коллекции имеют свой формальный статус, и

их реализации должны быть доступны для запросов, что обычно обеспечивается с помощью метаинформационно-го описания. Связки ресурсов, рассмотренные в А.1.3, — это коллекции ресурсов, обладающих общими лингвистически значимыми параметрами.

А.1.5 Метаинформационные описания

Каждый ресурс и каждая коллекция ресурсов должны ассоциироваться с метаинформационным описанием, реализующим их существование. Это обеспечивает оптимизацию и долговременную защиту ресурсов; при этом различаются объекты как таковые и множество их копий, которые могут находиться в разных репозиториях. Метаинформационные описания не только служат воплощением ресурсов или коллекций, но еще и хранят дополнительные сведения о них. При необходимости обращения к самим метаинформационным описаниям они тоже должны трактоваться как объекты, наравне с другими ресурсами. Однако часто записи метаданных порождаются в динамическом режиме как результат выполнения запроса к комплексной базе данных, а это означает, что метаинформаци-онное описание является не ресурсом, а разделом ресурса. Настоящий стандарт учитывает оба сценария развития событий, поскольку PID может указывать либо на ресурсы, либо на различные разделы ресурсов. Сервер ресурса не должен конфигурироваться на генерацию одной и той же информации в обоих указанных случаях.

В случае коллекций и связок ресурсов метаинформационное описание как таковое содержит ссылки на включенные в коллекцию ресурсы, и процесс разрешения этих ссылок может быть рекурсивным. Настоящий стандарт не нацелен на определение какого-то конкретного способа представления ресурсов в рамках метаинформационного описания. Однако он четко определяет механизм, который должен использоваться в таких описаниях для запроса ресурсов с помощью РЮ-идентификаторов.

Нет также и какой-то строго установленной процедуры контроля различных версий метаданных. В некоторых репозиториях исходный номер версии вообще не меняется; в других этот номер меняется при изменении дополнительной информации; бывает и так, что номер версии метаданных изменяется, когда меняется объект, к которому эти данные относятся. Настоящий стандарт не преследует цели установления какого-то единого подхода к управлению версиями метаинформационных описаний.

А.1.6 Аспекты разбиения ресурсов

Различия между разделами ресурса, самим ресурсом и конкретной коллекцией ресурсов порождают множество актуальных проблем, связанных с определением целесообразных уровней разбиения репозитория, которые должна поддерживать организация, ответственная за архивирование данных. Существует множество разных подходов к решению этих проблем, и все они могут отражать специфику конкретных потребностей и рабочей среды. Поэтому настоящий стандарт не определяет каких-либо жестких правил разбиения, а только дает некоторые руководящие принципы выделения уровней PID, присваиваемых коллекциям ресурсов, ресурсам и разделам ресурсов, с учетом конкретных целей обеспечения высокой производительности, совместимости, эффективности и управляемости.

В рамках многих проектов разработчикам приходится решать, какие из объектов подходят для присвоения им собственных индивидуальных PID-идентификаторов, а какие могут обрабатываться с использованием идентификатора раздела в сочетании с PID более крупного ресурса-контейнера. Здесь важны аспекты производительности и управляемости, и хотя инфраструктуры PID предназначаются для работы с множественными идентификаторами, каждый идентификатор все равно требует каких-то операций технической поддержки и обработки, вследствие чего достижениями сложившейся практики диктуется резервирование индивидуальных PID для использования в тех ситуациях, когда они действительно полезны. Существенную роль играют также соображения логической связности и совместимости, и потому объекты одного типа должны рассматриваться по возможности на одном и том же уровне разбиения.

ГОСТ Р ИСО 24619-2013

Для некоторых типов ресурсов существуют действующие и предлагаемые стандарты, указывающие способ адресации разделов интернет-ресурсов, основанный на использовании идентификатора фрагмента, присоединяемого к URI. В разделе 6 показано, что при большом объеме ресурса этот подход не эффективен; тем не менее само наличие такой функциональной возможности обеспечивает мощный механизм адресации, при наличии которого в документах могут поддерживаться активируемые идентификаторы.

А.2 Общие практические рекомендации по запрашиванию интернет-ресурсов

В архитектуре сети Интернет унифицированный идентификатор ресурса URI (Uniform Resource Identifier) определяется как последовательность символов, используемая для обращения к сетевым ресурсам. Унифицированные идентификаторы ресурсов разделяются на множество подклассов или схем: многие схемы URI определяют механизм доступа к ресурсам и потому имеют второе (неофициальное) название «унифицированные указатели ресурсов» [Uniform Resource Locators (URL)], поскольку они указывают местонахождение ресурса в сети [5]. Использование URI — наиболее распространенный способ вызова ресурсов, хотя бы потому, что при вложении в веб-документ URI становится непосредственно аюивируемым объектом. Синтаксическая структура URI зависит от конкретной используемой схемы (http, ftp, file, gopher и др.). Самая популярная схема HTTP, определяемая стандартом IETF RFC 2616 [8], поддерживает следующие функциональные возможности, важные для настоящего стандарта:

a)    возможность добавления параметров в URI в рамках запроса для передачи дополнительной информации удаленному веб-серверу. Например, в URI вида http://server/service?part=12 параметры интерпретируются удаленным сервером ресурса;

b)    возможность добавления идентификатора фрагмента с целью определения запрашиваемого раздела ресурса. Например, в URI вида http://server/document1#part1 идентификатор фрагмента не пересылается на удаленный сервер, а используется клиентским приложением для выделения требуемого фрагмента документа из полностью передаваемого ресурса.

Довольно часто данные о размещении ресурса в сети и о локальном пути доступа к нему вкладываются в URI ресурсов²), что порождает целый ряд проблем при изменении местонахождения ресурса. «Подмешивание» в идентификатор семантики указателя временного местоположения опасно. Например, защищенный на какой-то момент времени ресурс

http://mvhost.ourdomain/protected/R1.wav

может на следующий день стать незащищенным, а со временем может измениться даже семантическая структура имени ресурса.

Схема URN URI, определенная в стандарте IETF RFC 2141 [21], наоборот, предоставляет имена для ресурсов вместо их адресации. Унифицированное имя ресурса URN (Uniform Resource Name) несет в себе идентификатор пространства имен из списка, который ведет IANA [13]; этот идентификатор обеспечивает бесконфликтную интеграцию данных из других схем именования (например, ISBN, ISSN) как подмножеств URN. Схемы URN должны предоставлять глобально уникальный постоянный идентификатор, используемый для идентификации ресурсов и доступа к ним.

URN имеет следующую синтаксическую структуру:

игп:<идентификатор пространства имен ^Ю)>:<конкретная строка данных пространства имен (NSS)>

Строка данных пространства имен может принимать любую форму, определяемую администрацией службы имен, при условии, что имя будет уникальным в этом пространстве и согласно IETF RFC 2141 не будет ограничено малым числом разрешенных символов. Хотя идентификатор URN очень хорошо подходит для именования ресурсов, для него нет никакого общепринятого механизма разрешения имени к адресу местоположения ресурса, что стало поводом к появлению различных систем постоянных идентификаторов, рассматриваемых ниже, в приложении В.

Консорциум W3C, осознавая трудности вложения адресной информации в идентификаторы URI, опубликовал результаты изысканий Группы по технической архитектуре [Technical Architecture Group (TAG)] в этой области [25, 30]. Полученные этой группой результаты содержат такие важные ссылки, как документ Бернерса—Ли (Berners—Lee) по идентификаторам URI, и показывают, что конструирование неизменных URI возможно и должно быть предпочтительным по отношению к другим техническим решениям и, в частности, к инфраструктурным РЮ.

А.З Системы разрешения постоянных идентификаторов

Постоянные идентификаторы, ассоциируемые со службой разрешения ссылок, предназначены для решения общей проблемы разорванных связей, которая возникает в тех случаях, когда сетевой ресурс переносится в другое место или вообще удаляется. Для работы с неизменными идентификаторами было предложено много разных подходов, нацеленных как на предоставление непротиворечивых схем именования оперативно доступных ресурсов, так и на создание службы разрешения ссылок для переадресации пользователей к текущему местоположению запрошенного ресурса с помощью неизменного идентификатора.

Свойство неизменности РЮ-идентификатора означает, что он никогда не может быть «переназначен» ни для какого иного ресурса и не должен изменяться ни при каком перемещении данного ресурса или изменении протокола доступа к нему. Известно множество формальных схем присвоения идентификаторов и имен; эти схемы уже обсуждались выше в контексте именования электронных ресурсов (например, URI, URN, handles, DOI, ARK, ISBN, ISSN, SICI, BICI, PI Is). Однако применительно к упрощению доступа к сетевым ресурсам в распределенной системе лишь очень немногие из существующих схем могут быть действительно эффективными, если они официально не зарегистрированы в качестве схем именования URI и не поддерживаются системой разрешения идентификаторов или не встроены в другую схему присвоения имен, которая оснащена соответствующей системой разрешения.

Клиентское приложение нуждается в доступе к ресурсу, PID для которого ему известен.

Оно запрашивает у резольвера PID, ассоциированный с тем URL, который используется для доступа к ресурсу. Выполняемые резольвером преобразования PIDOURL должны поддерживаться архивной организацией, связанной с репозиторием

Рисунок А.1 —Схема разрешения РЮ-идентификатора

Без системы разрешения запросы, в которых используется идентификатор, не могут быть направлены нужному серверу для последующего извлечения запрошенного ресурса или его правомерного «заменителя» в виде метаданных (см. рисунок А.1). Краткие описания большинства используемых систем разрешения РЮ-идентификаторов можно найти в приложении В.

А.4 Адресация разделов ресурса

А.4.1 Общие замечания

Ниже описываются сложившаяся практика и существующие стандарты адресации разделов ресурсов. Некоторые стандарты и практические методы используются в действующих соглашениях о цитировании и в рамках сетевой архитектуры. Основной предметной областью настоящего стандарта являются интерпретируемые машинным способом идентификаторы, которые однозначно указывают требуемую часть или сегмент более крупного ресурса. Такие идентификаторы способны переключать удаленные серверы ресурсов на выдачу некоторого представления запрошенной части ресурса клиентскому приложению или «заставлять» его самостоятельно выделять из ресурса нужный раздел. Применительно ко многим типам ресурсов, для которых нет действующих стандартов или практических рекомендаций, возможно внесение соответствующих поправок в уже существующие стандарты и рекомендации.

А.4.2 Мультимедийные средства (в порядке появления)

В настоящее время существуют следующие практические рекомендации и стандарты, применимые к мультимедийным средствам:

ИСО/МЭК 21000-17 Информационные технологии. Основы мультимедиа (MPEG-21). Часть 17. Идентификация фрагментов ресурсов MPEG определяет нормативную синтаксическую структуру идентификаторов фрагментов ресурсов URI, которые подлежат использованию при адресации разделов любого интернет-ресурса, относящегося к одному из следующих типов сред: audio/mpeg, video/mpeg, video/mp4, audio/mp4, application/mp4, video/MPEG4-visual, application/mp21.

Цифровой формат Annodex, разработанный австралийским государственным объединением научных и прикладных исследований [Commonwealth Scientific and Industrial Research Organisation (CSIRO)], включает в себя еще и спецификацию временной адресации с использованием специального синтаксиса URI [22]. Этот синтаксис позволяет обращаться к сегментам аудио- и видеофайлов. Синтаксическая структура такого URI подлежит интерпретации удаленным сервером, который выделяет запрошенный сегмент из мультимедийного файла и пересылает его клиенту. Например, URI, имеющий вид

http://example.com/video.anx7tH 5.2/18.7. будет вызывать для передачи сегмент записи video.апх, начинающийся в точке 15,2 секунды и заканчивающийся в точке 18,7 секунды.

А.4.3 Текстовые ресурсы

В случае текстовых ресурсов конкретные разделы могут адресоваться идентификаторами разделов до тех пор, пока они специфицируются поставщиком ресурса. Кроме того, если ресурс текстовых корпусов состоит из пре-

ГОСТ Р ИСО 24619-2013

жде опубликованных текстов и по ним доступны соответствующие метаданные, то такие тексты и их части при необходимости тоже будут адресоваться с использованием обычных соглашений по косвенному цитированию.

К числу практических рекомендаций по адресации фрагментов текстовых файлов относятся следующие материалы:

-    по использованию байтовых или символьных сдвигов для указания позиций или «пропусков» в тексте имеется релевантная технология: Типстера [26], GATE [10] и всевозможные производные методы от GATE;

-    IETF RFC 5147, URI Fragment Identifiers for the text/plain Media Type (Идентификаторы URI для текстовых и открытых мультимедийных фрагментов), основывающиеся на использовании строковых или символьных сдвигов либо тех и других одновременно;

-    для документов XML, FITML, XPointer имеется, например, технология Annotea [2], которая представляет собой проект, поддерживаемый консорциумом W3C и предназначенный для расширения сотрудничества в области электронных документов на основе использования тегов, закладок и прочих атрибутов аннотирования.

А.4.4 Источники знаний

К источникам знаний относятся словари, терминологии, реестры основных понятий, онтологии и т. п. Эта предметная область отличается динамичными разработками, в том числе в части форматов представления информации. В задачу настоящего раздела не входит исчерпывающее описание современного состояния разработок; его основная цель — показать лишь некоторые возникающие проблемы. В настоящем стандарте не ставится также задача предложить какие-то конкретные решения, поскольку выбор способов доступа к тем или иным разделам имеющихся ресурсов, как и гарантирование живучести используемых механизмов адресации — это сфера ответственности конкретных профессиональных сообществ, которые могут остановить свой выбор, например, на методах, проверенных практикой. Таким методом может быть использование постоянных унифицированных указателей ресурсов (PURL), как в стандарте «Дублинское ядро».

Что касается словарей, то в этой области ИСО 24613:2008 [15] предлагается метамодель для представления информации в лексических базах данных. Необходимо, чтобы эта информация была доступной на разных уровнях для внешних ресурсов или инструментальных средств, которые обеспечивают адресацию отдельных лексических единиц, смысловых значений или даже более мелких информационных объектов, таких как хранимые в словаре морфологические части слов. Когда словарь представляется в формате XML, для описания ссылок на него может использоваться расширяемая спецификация XPointer. Сам словарь может тоже содержать ссылки на внешние ресурсы, такие как звук или видео, для иллюстрации произношения или примеров использования лексических единиц. Такие ссылки, как правило, относятся не только к ресурсу в целом, но и к его частям, таким как видеофрагменты. В случае обращения к части ресурса его идентификатор должен быть дополнен специализированным указателем раздела ресурса, предназначенным для обеспечения доступа к нужному фрагменту информации. Наконец, лексиконы LMF, как и все другие модели, охватываемые семейством стандартов технического комитета ИСО/ТК 37, обеспечивают ссылки на элементы Реестра категорий данных DCR (Data Category Registry), определенного ИСО 12620.

Такие инструментальные средства, как LEXUS [17] (где реализована схема лексической разметки), работают в среде мультимедийных словарей, в которых ресурсы различных типов оказываются тесно переплетенными друге другом. В таких случаях необходимо иметь механизм непротиворечивой адресации для гарантии совместимости ресурсов.

Применительно к терминологиям и реестрам основных понятий, таким как ISO DCR, должна существовать возможность обращения к отдельным статьям. Базовый уровень совместимости может быть обеспечен путем выборки статей, которые считаются идентичными, и объявления их таковыми.

Если отдельный ресурс может адресоваться с использованием некоторого унифицированного механизма, такого как PID-идентификатор, то идентификаторы разделов ресурса в значительной степени зависят от типа запрашиваемого ресурса. Для некоторых типов ресурсов появляются стандарты, в которых рассматривается эта проблема, однако существуют типы, для которых ситуация остается в значительной мере неясной, что иллюстрируется следующим примером.

Пример — Применительно к базам знаний, которые содержат в дополнение к определениям концептов еще и отношения между ними, для представления информации все чаще используется формат RDF. В таких случаях для обращения к графу или подграфу должен применяться идентификатор раздела ресурса. Для этой цели обсуждались различные технические решения, в том числе стандартизованные запросы, сформулированные на языке запросов RDF [12].

А.5 Адресация коллекций ресурсов

Проблема адресации коллекций ресурсов, относящихся к классу «публикуемых», хорошо известна, однако до сих пор нет ясности в отношении сложившихся практических методов, а используемые механизмы доступа не всегда пригодны для машинной реализации и удобной интерпретации. Обычно пользователи работают с публикациями текстовых лингвистических корпусов так, как описано в документе Пенсильванского университета, касающемся корпуса американского варианта разговорного английского языка:

ГОСТ Р ИСО 24619-2013

Содержание

1    Область применения............................................1

2    Нормативные ссылки............................................1

3    Термины и определения..........................................2

3.1    Ресурсы................................................2

3.2    Идентификаторы...........................................3

3.3    Ролевые функции, организации и службы..............................4

3.4    Действия................................................5

4    Общее описание..............................................5

5    Требования к инфраструктуре и использованию постоянных    идентификаторов...........6

5.1    Общие сведения............................................6

5.2    Требования к инфраструктуре постоянных идентификаторов...................6

5.3    Использование постоянных идентификаторов...........................8

5.4    Цитируемая информация и постоянные идентификаторы.....................8

5.5    Обращение к разделам ресурсов..................................8

5.6    Коллекции...............................................9

6    Дополнительные требования.......................................9

6.1    Разбиение идентификаторов.....................................9

6.2    Рекомендации............................................10

Приложение А (справочное) Автономные ресурсы, агрегированные ресурсы и разделы ресурсов . 11

Приложение В (справочное) Реализации системы постоянных    идентификаторов...........19

Приложение С (справочное) Сокращения.................................22

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

ссылочным национальным стандартам Российской Федерации...........25

Библиография................................................26

John W. Du Bois, Santa Barbara Corpus of Spoken American English. Parts 1,2 and 3, Linguistic Data Consortium, University of Pennsylvania, Philadelphia (2000),

либо обращаются непосредственно к оригиналам, представленным в той или иной форме, как, например, коллекция Калифорнийского университета:

Santa Barbara Corpus of Spoken American English. Part 1.2000. Collected by University of California, Santa Barbara Center of the Study of Discourse, directed by John W. Du Bois.

Подобные ссылки осуществимы лишь в тех случаях, когда четко определена ответственность за процесс создания корпусов в части авторства участвующих творческих организаций, архивных учреждений и т. п. Однако, даже при наличии всех этих атрибутов, желательно иметь прямой доступ к машиночитаемому РЮ-идентификатору, который мог бы использоваться далее, например для автоматического извлечения из формализованного метаин-формационного описания сведений о размерах корпуса или для получения какой-либо другой информации.

Не существует сложившейся практики и для виртуальных коллекций, которые создаются исследователями в процессе выполнения конкретных проектов и могут содержать богатый набор информационных ресурсов, порождаемых различными творческими коллективами многочисленных организаций и учреждений; при этом, однако, необходимо документирование выполняемой работы в такой форме, чтобы другие специалисты имели возможность проверить правильность утверждений авторов. Причина отсутствия такого документирования кроется в том, что лишь в редких случаях (как в репозиториях, основанных на стандарте метаданных IMDI для описания мультимедийных ресурсов [28]) исследователи могут создавать метаинформационные описания виртуальных коллекций, играющие роль их реализаций, например для инициирования операций поиска.

А.6 Цитируемая информация

А.6.1 Общие положения

Необходимо понимать различия между адресуемыми текстами разного характера. Применительно к некоторым контекстам, таким как «картинки» в словаре, запрашивающую сторону обычно не интересует никакая информация об изображении в дополнение к тем сведениям, которые уже были найдены в тексте словарной статьи. Инициатора запроса будет интересовать только активация ссылки и мгновенное получение самого изображения. В других случаях, когда полученная по ссылке информация предназначается для чтения человеком, более подходящим, может оказаться представление пользователю цитируемой информации в полном объеме, как она выглядела бы в традиционной распечатке. В случае виртуальных коллекций пользователю может понадобиться увидеть более подробные сведения о ресурсах, включенных в коллекцию, и, следовательно, он может запросить метаинфор-мационное описание. В первом и последнем случаях ссылки представляют собой PID-идентификаторы с присоединенным, при необходимости, указателем фрагмента. Второй из рассмотренных выше случаев требует более глубокого рассмотрения цитируемой информации.

В научных работах цитирование символизирует признание важности работ предшественников и выражение доверия к ним. Читатели могут при этом проверить свои утверждения, сравнив их с результатами цитируемых работ. То же самое можно сказать и о первичных научных данных, на базе которых авторы строят свои исследования и желают выразить свою признательность создателю первоисточника или составителю коллекции. Поэтому при цитировании электронного ресурса в каком-либо документе запрос такого ресурса или ссылка на него сопровождается выдачей цитируемой информации: текста (метаинформации) для прочтения человеком, указывающего держателей ресурса (создателя, составителя коллекции, издателя и др.).

Существует множество стандартов и практических рекомендаций, касающихся определения цитируемой информации, и перечислять их здесь нецелесообразно, но некоторые широко используемые документы приведены в А.6.2—А.6.6.

А.6.2 ИСО 690:2010

В ИСО 690:2010 [16] представлен обзор многочисленных типов электронных документов и определены элементы данных, подлежащие включению в библиографические ссылки. Это важный источник информации в части сложившейся практики цитирования. ИСО 690 в основном касается примеров использования идентификаторов DOI, но допускает и применение PID-идентификаторов. В отличие от ИСО 690, который не выдвигает никаких требований к инфраструктуре PID, настоящий стандарт устанавливает такие требования. Представленная в нем инфраструктура PID позволяет, например, осуществлять более эффективный контроль над дополнительной информацией (метаданными) с такими идентификаторами и обеспечивает возможность использования других бизнес-моделей, отличных от DOI. Все рекомендации, содержащиеся в ИСО 690, могут быть реализованы при условии, что допускаются к использованию PID-идентификаторы из любых инфраструктур, которые удовлетворяют требованиям настоящего стандарта.

Для оперативно доступных ресурсов важно присутствие следующих элементов:

-    «Готовность и способ доступа» (например, «Доступен по адресу: URL» или «Доступен также в формате PDF по адресу: URL»);

-    «Стандартный номер» (например, «ISBN 0-7710-1932-7» или «ISSN 1045-1064»);

-«Нумерация и пагинация» (например, «Инвентарный номер 01209277», «страницы 5—21» или «строки 30—40»).

Значением элемента «Готовность и способ доступа» обычно является URL.

Введение

Ссылки и цитаты являются важной частью документации и публикаций. Авторы обычно используют цитаты и ссылки как средство выражения своей признательности авторам других публикаций, служащих источником информации для их собственной работы, либо в поддержку собственной аргументации. Цитаты, как правило, содержат сведения, помогающие читателю оценить степень связи цитируемой публикации с рассматриваемой проблемой и однозначно идентифицировать эту публикацию. На основании приводимых в цитате сведений любой библиотекарь или соответствующее компетентное лицо могут легко найти нужный документ, воспользовавшись установленными для этого стандартными процедурами.

Существование документов, непосредственно доступных во всемирной сети, способствовало добавлению к ссылочной информации указаний о ее местонахождении (с помощью так называемого универсального идентификатора ресурсов URI [4]). Такая практика сделала возможным прямой доступ к ссылочным документам через веб-браузеры и другие аналогичные средства визуализации. Подобные механизмы уже были установлены в таких стандартах, как ИСО 690, хотя там основное внимание уделяется скорее простому поиску в библиографических каталогах публикаций, чем обеспечению их постоянной доступности. Все чаще и чаще справочники такого рода требуются для использования прикладными программно-техническими системами, равно как и людьми, которым необходим надежный доступ к запрашиваемым ресурсам. Трудности с получением доступа, возникающие при перераспределении ресурсов, привели к созданию инфраструктуры (framework) постоянных идентификаторов (РЮ) [23, 24]. В рамках современных подходов [18, 19, 24] к решению проблемы перераспределения ограниченных ресурсов организуются соответствующие координационные службы, которые преобразуют идентификатор ресурса в адрес его текущего местоположения. Такие координационные службы обладают одним важным дополнительным преимуществом, состоящим в ассоциировании с каждым идентификатором расширенных метаданных. В более сложных инфраструктурах, таких как система цифровых идентификаторов объекта DOI (Digital Object Identifier) [14], эта возможность используется для привлечения дополнительных услуг — например информации по авторским правам.

Практика использования наряду с отдельными ресурсами и наборами данных постоянных идентификаторов для целей цитирования и извлечения научной информации имеет более скромные результаты. Однако она располагает не меньшими ресурсами в том смысле, что позволяет читателям публикаций и пользователям ресурсов научных знаний получать прямой доступ к информации научных первоисточников, на которых основаны соответствующие ресурсы. При использовании ссылок для доступа к научным данным, включая языковые ресурсы, важную роль приобретает возможность доступа, в том числе и к отдельным компонентам (частям) ресурсов. В особенности это касается сферы языковых ресурсов, где один и тот же набор данных или коллекция ресурсов обычно имеют несколько уровней разбиения. Поэтому предметом настоящего стандарта, касающегося использования инфраструктур PID и требований к ним, является, в первую очередь, анализ механизмов эффективной организации идентификации и обеспечения доступа к компонентам требуемых ресурсов. Содержащиеся в стандарте конкретные рекомендации показывают, каким образом следует подходить к решению задачи разбиения применительно к использованию постоянных идентификаторов отдельных ресурсов и их коллекций.

Потребность в применении инфраструктур постоянных идентификаторов для определения ресурсов, имеющихся в наборах научных данных, возрастает еще и потому, что современные архивы и репозитории начали превращаться в сплетения сетей родственных комплексных ресурсов, которые могут быть распределены по множеству сетевых узлов. В такой ситуации обязательным условием становится наличие постоянных устойчивых связей. Например, в мультимедийной среде словарных ресурсов лексическая единица может быть связана с наглядными представлениями, которые необязательно физически присутствуют в данном словаре или даже могут запрашиваться по ссылке с другого сайта, принадлежащего совсем другой организации. Несмотря на это связь между данной лексической единицей и относящимся к ней изображением должна оставаться действующей даже в тех случаях, когда некоторые серверы или файлы могут со временем изменять свое местоположение. Появляющиеся сценарии электронного распространения научной информации, делающие возможным использование распределенных услуг по обработке распределенных ресурсов, целиком и полностью зависят от наличия удобного и прозрачного доступа к любым службам обработки данных независимо от их местонахождения и от конкретных организаций, эксплуатирующих соответствующие ресурсы. Это значит, что

механизм разрешения обращений к используемым ресурсам не должен обременяться никакими излишними ограничениями и зависимостями, которые влекли бы за собой создание нежизнеспособной или непредсказуемой сети услуг как в техническом, так и в организационном плане.

Выполнение требований доступности таких служб, как инфраструктуры PID для всего сообщества поставщиков языковых и технологических ресурсов, еще больше усложняется из-за необходимости предоставления системы разрешимых ссылок с постоянными идентификаторами без обременения поставщиков ресурсов какими-либо иными коммерческими условиями кроме четко сформулированных основополагающих требований технической поддержки и сопровождения соответствующих ресурсов в сети Интернет.

v

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

МЕНЕДЖМЕНТ ЯЗЫКОВЫХ РЕСУРСОВ Постоянная идентификация и устойчивый доступ

Language resource management. Persistent identification and sustainable access

Дата введения — 2015—01—01

1    Область применения

Настоящий стандарт устанавливает требования к инфраструктуре постоянных идентификаторов [persistent identifier (PID)] и их использованию в качестве средств запроса и цитирования языковых ресурсов в официальных документах, равно как и в рамках самих этих ресурсов. В этом плане примерами языковых ресурсов могут служить электронные словари, лингвистические терминологические ресурсы, лексикон систем машинного перевода, аннотированные мультимедийные и многоцелевые корпуса текстов, снабженные морфосинтаксической информацией и прочими атрибутами. Такие ресурсы создаются специалистами по прикладной лингвистике и информационным технологиям.

Настоящий стандарт охватывает также вопросы стойкости идентификаторов и разбиения запросов к ресурсам прежде всего в аспекте необходимости реализации постоянных ссылок на основе использования инфраструктуры РЮ и последующего предъявления жестких требований к любым применяемым для этого инфраструктурам РЮ.

Инфраструктуры РЮ позволяют ассоциировать метаданные общего характера с идентификатором, который может содержать также цитируемую информацию. Настоящий стандарт устанавливает минимальные требования, касающиеся эффективного использования постоянных идентификаторов применительно к языковым ресурсам, и содержит ссылки на несколько подходящих действующих стандартов и стандартов de-facto, таких как ИСО 690 [16], АРА [3], MLA [9] для цитируемой информации, ИСО/МЭК 21000-17, IETF RFC 5147, Annotea [2], документ temporal-fragment [22], XPointer для синтаксиса идентификаторов разделов, PURL [23], ARK [18], Handle System [24] и DOI [14].

2    Нормативные ссылки

ИСО 12620:2009 Терминология, другие языковые ресурсы и ресурсы содержания. Спецификация категорий данных и ведение реестра категорий данных для языковых ресурсов (ISO 12620:2009, Terminology and other language and content resources — Specification of data categories and management of a Data Category Registry for language resources)

ИСО/МЭК 21000-17:2006 Информационные технологии. Мультимедийная инфраструктура (MPEG-21). Часть 17. Идентификация фрагментов ресурсов MPEG (ISO/IEC 21000-17:2006, Information technology — Multimedia framework (MPEG-21) — Part 17: Fragment Identification of MPEG Resources)

Документ W3C 2003, XPointer Framework: [в режиме онлайн] Рекомендация W3C от 25 марта 2003 г. [по состоянию на 4 августа 2010 г.]. Доступна по адресу: http://www.w3.org/TR/xptr-framework/

Wilde, Е. and Duerst, М. URI Fragment Identifiers for the text/plain Media Type, IETF RFC 5147, апрель 2008 г. [по состоянию на 22 декабря 2010 г.]. Ресурс доступен по адресу: http://www.rfc-editor.org/rfc5147.txt

Издание официальное

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1    Ресурсы

3.1.1    ресурс (resource): Цифровой объект в сети Интернет, снабженный индивидуальным идентификатором, который может запрашиваться с помощью унифицированного идентификатора ресурса URI (3.2.2).

Примечание 1 — Определение заимствовано из документа IETF RFC 3986.

Примечание 2 — В контексте настоящего стандарта ресурсом может быть также языковой ресурс, имеющий оперативно доступное электронное представление.

Примечание 3 — Ресурс может иметь несколько разных представлений. В зависимости от инфраструктуры PID (3.2.5) способ распознавания конкретного представления может быть закодирован в идентификаторе (см. ARK, В.З) или определяться в процессе взаимодействия между клиентом сети (3.3.8), использующим развернутый РЮ для вызова ресурса (3.1.1), и сервером ресурсов (3.3.6).

3.1.2    языковой ресурс (language resource): Электронный ресурс, который предоставляет информацию по одному или нескольким языкам.

Примечание — к языковым ресурсам относятся лексикографические, терминологические, морфосинтаксические, корпусно-ориентированные и семантические ресурсы, а также электронные ресурсы, используемые для изучения лингвистических явлений, подобных связным текстам и мультимедийным/многомодальным записям. Они создаются и применяются, в частности, лингвистами, специалистами по информационным технологиям, лексикографами и терминологами. Подобные информационные продукты состоят из множества коротких записей, скомпонованных в более крупные публикации, и зачастую являются авторитетными изданиями, как, например, стандартизованные терминологические справочники и глоссарии, выпускаемые органами по стандартизации, такими как ИСО, IETF, W3C и др.

3.1.3    комбинированный ресурс (complex resource): Ресурс (3.1.1), состоящий из множества компонентов, каждый из которых может быть запрошен отдельно.

Примечание — Комбинированный ресурс может быть интегрированным, если его составные части распределены по различным репозиториям (3.1.6).

3.1.4    коллекция (collection): Компоновка, образованная любым числом ресурсов (3.1.1) и запрашиваемая как единое целое.

3.1.5    публикуемая коллекция (published collection): Коллекция ресурсов определенного назначения, которая поддерживается как независимая сущность в рамках архива (3.1.7) либо репозитория (3.1.6) и для которой существует адекватная форма цитирования (3.1.16) информации.

3.1.6    (цифровой) репозиторий (digital repository; repository): Средство, обеспечивающее надежный доступ к управляемым электронным ресурсам (3.1.1).

3.1.7    (цифровой) архив (archive; digital archive): Репозиторий (3.1.6), предназначенный для надежного долговременного хранения специализированных данных.

Примечание — Часто данные цифровых архивов бывают доступны в интерактивном режиме, что требует использования надежных постоянных идентификаторов (3.2.4).

3.1.8    реализация коллекции ресурсов, реализация (resource collection incarnation; incarnation): Виртуальное воплощение не согласуемой иным способом разрозненной коллекции (3.1.4) определенного назначения, запрашиваемой по единственному идентификатору РЮ (3.2.4), который связан с идентификатором компонентов (3.2.7) в целях обеспечения раздельного доступа к ним.

Примечание — В библиографическом или предметном указателе может применяться единственный идентификатор PID в сочетании с расширениями для обеспечения доступа к различным компонентам совокупности ресурсов (3.1.1), используемой при подготовке монографии или разработке проекта, без фактического сосредоточения физических файлов в одном месте; то есть отдельные элементы коллекции остаются на своих исходных местах, но запрашиваются как части виртуального целого.

3.1.9    версия (version): Конкретная форма или вариант ресурса (3.1.1), отличающиеся от других реализаций ресурса хотя бы по одному аспекту или элементу информации.

Примечание — Версии часто идентифицируются по порядковому номеру (например, версия 1, версия 2 и т. д.), однако идентификация версий динамических ресурсов, подверженных частым изменениям, осуществляется зачастую с привязкой к отметке даты и времени.

2

ГОСТ Р ИСО 24619-2013

3.1.10    мгновенная копия (snapshot): Мгновенная копия текущих характеристик ресурса (3.1.1), отображающая состояние ресурса или коллекции в определенный момент времени.

3.1.11    абстрактный ресурс (abstract resource): Запрашиваемый несетевой ресурс, идентифицируемый по URI (3.2.2); обычно это бывают такие концепты, как класс или свойство.

Примечание — На практике распространены, например, в рамках онтологий RDFS (RDF Schema) или OWL (язык сетевых онтологий) способы идентификации абстрактных ресурсов с помощью URI. В веб-архитектуре никогда не требуется вызов такого информационного ресурса. Если идентификатор абстрактного ресурса не отмечен как подлежащий разыменованию (3.4.1), что имеет место применительно к URI пространства имен языка ХМL, то для такого ресурса нет необходимости формировать идентификатор PID (3.2.4).

3.1.12    раздел ресурса, часть (resource part; part): Идентифицируемый доступный объект, встроенный в автономный ресурс (3.1.1) или в более крупную часть этого ресурса.

Примечание — Возможно встраивание одних разделов в другие. В динамичной сетевой среде разбиение на разделы подлежит изменению и интерпретации, вследствие чего требуется определенный уровень участия пользователя в принятии решений относительно обозначения и идентификации получаемых подобъектов.

3.1.13    фрагмент (fragment): Некоторая порция или подмножество первичного ресурса (3.1.1), какое-либо из представлений первичного ресурса или некоторый другой ресурс, определенный или описанный как компонент ресурса, определенного или описанного этими представлениями.

Примечание 1 — Определение заимствовано из документа IETF RFC 3986.

Примечание 2 — В контексте настоящего стандарта термин фрагмент используется только в смысле определения, данного в IETF RFC 3986, тогда как в сетевом контексте фрагмент извлекается клиентским приложением (3.3.5) из содержащего этот фрагмент ресурса.

3.1.14    конечная (неделимая) часть (terminal part): Часть (3.1.12) ресурса (3.1.1), которая не может быть разбита на более мелкие части.

3.1.15    внутренняя часть (internal part): Часть (3.1.12) ресурса (3.1.1), которая является вложением ресурса и одновременно разбита на более мелкие части.

3.1.16    цитата (citation): Информационный объект, содержащий сведения, которые переориентируют внимание читателя или пользователя с одного ресурса (3.1.1) на другой.

3.1.17    ссылка (reference): Цифровой объект, указывающий на данные, хранимые в каком-либо месте.

Примечание — Хотя термины «цитата» (3.1.16) и «ссылка» обычно используются почти как синонимы, для целей настоящего стандарта цитаты несут информацию для читателей и пользователей, тогда как ссылки указывают точное местоположение запрашиваемого ресурса (3.1.1). Ссылки могут быть машиночитаемыми и могут конфигурироваться как активизируемые при соответствии заданным критериям.

3.1.18    уровень аннотирования (annotation tier): Отдельный информационный уровень, содержащий комментарии, примечания, объяснения или иные типы внешних ремарок, которые могут присоединяться к ресурсу (3.1.1).

Примечание — Например, карты или изображения могут аннотироваться с привлечением дополнительной информации, а текстовые корпуса могут аннотироваться как прямо в тексте, так и автономно.

3.1.19    автономное аннотирование (standoff annotation): Режим аннотирования, при котором аннотации хранятся вне аннотируемого документа.

3.2 Идентификаторы

3.2.1    (цифровой) идентификатор (identifier; digital identifier): Последовательность символов, ассоциируемая с цифровыми/нецифровыми или абстрактными объектами, такими как книги, изображения, статьи, метаинформационные записи или события.

3.2.2    унифицированный идентификатор ресурса (URI; Uniform Resource Identifier): Символьная строка, используемая для идентификации или назначения имени некоторого ресурса (3.1.1) в соответствии с синтаксическими правилами, определенными документом IETF RFC 3986.

3.2.3    схема именования URI (URI naming scheme): Верхний уровень структуры присваивания имен URI.

Примечание 1 — Каждая такая схема устанавливает собственные синтаксические правила для URI (3.2.2).

3

Примечание 2 — Типичными примерами схем URI являются http, https, ftp, mailto и др.; все они регистрируются в Полномочном органе по цифровым интернет-адресам IANA (Internet Assigned Numbers Authority).

3.2.4    постоянный идентификатор (РЮ; persistent identifier): Уникальный идентификатор (3.2.1), который гарантирует постоянный доступ к цифровому объекту с помощью механизма доступа, не зависящего от физического расположения объекта и от его текущей принадлежности.

Примечание — «Уникальный» означает в данном случае, что РЮ не будет повторяться применительно к другим ресурсам. Однако один и тот же РЮ может по усмотрению поставщика ресурса вызывать разные формы представления или разные реализации (3.1.8) конкретного ресурса.

3.2.5    инфраструктура РЮ (РЮ framework): Схема определения строк идентификатора [схема РЮ (3.2.4)] для цифровых объектов, доступных через сеть Интернет, и механизм, позволяющий преобразовывать эти идентификаторы в текущие унифицированные индикаторы URI (3.1.1) запрашиваемых

объектов.

Примечание 1 — Инфраструктура РЮ в контексте настоящего стандарта облегчает доступ к индивидуальным объектам, равно как к разделам (3.1.12) и фрагментам (3.1.13), содержащимся в таких объектах. Инфраструктура РЮ может целиком зависеть от существующих сетевых протоколов преобразования адресов или может закреплять схему взаимодействия преобразователей адресов на основе программ-посредников.

Примечание 2 — Инфраструктура РЮ в контексте настоящего стандарта позволяет также оперировать другой информацией, ассоциируемой с конкретным РЮ.

3.2.6    активируемый идентификатор (actionable identifier): URI (3.2.2), имеющий ресурсный идентификатор (3.2.1), который закодирован таким образом, что при вложении этого URI в веб-документ и последующем выборе с помощью указателя мыши браузер будет перенаправлен на запрашиваемый ресурс (3.1.1) и, возможно, на связанные с этим ресурсом дополнительные услуги.

Примечание 1 — Эта функциональная возможность приводит к тому, что URI указывает на подходящий промежуточный преобразователь адресов (3.3.7).

Примечание 2 — В некоторых инфраструктурах РЮ (3.2.5) идентификаторы РЮ (3.2.4) представляют собой URI и активируются автоматически.

3.2.7    идентификатор раздела (ресурса) (resource part identifier; part identifier): Строка символов, вызывающая раздел ресурса (3.1.12), который может идентифицироваться тем или иным способом в рамках данного типа ресурса (в рабочей среде это может быть время, в изображении — нужная область, в потоке данных — запись и т. п.).

Примечание — Идентификаторы разделов в контексте настоящего стандарта предназначаются для использования на стороне сервера — в противоположность клиентской стороне преобразования адресов, где для этого служат идентификаторы фрагментов (3.2.8).

3.2.8    идентификатор фрагмента (fragment identifier): Идентификатор (3.2.1), используемый для вызова раздела (3.1.12) ресурса (3.1.1) в сетевой среде.

Примечание 1 — Определение заимствовано из документа IETF RFC 3986.

Примечание 2 — Идентификатор фрагмента, как он определен в IETF RFC 3986, начинается со знака «решетки» («#») и завершается идентификатором URI (3.2.2). Фрагменты (3.1.13) в смысле RFC разрешаются и извлекаются из ресурса с помощью локального клиентского приложения (3.3.5).

Примечание 3 — Существует проектное предложение W3C по изменению указанного способа обработки фрагментов [27].

3.3 Ролевые функции, организации и службы

3.3.1    институт архивирования (archiving institution): Организация, ответственная за ведение электронного архива (3.1.7).

3.3.2    поставщик ресурса (resource provider): Организация, которая обеспечивает оперативную доступность ресурса (3.1.1).

Примечание — Ресурсом может быть и какая-либо служба.

3.3.3    резольвер, преобразователь PID-идентификаторов (resolver; РЮ resolver): Прикладная программа, преобразующая исходный идентификатор (3.2.1) в другой, более удобный идентификатор, который транслирует РЮ (3.2.4) ресурса в его URI (3.2.2) и таким образом указывает клиентскому приложению местоположение нужного ресурса (3.1.1).

4

ГОСТ Р ИСО 24619-2013

3.3.4    система разрешения идентификаторов (resolution system): Система, предназначенная для поддержки представления неизменного идентификатора (3.2.4) сетевой службе в целях получения в ответ одной или нескольких порций текущей информации, относящейся к идентифицируемому объекту, например о местонахождении [URI (3.2.2)] объекта или метаданных.

Примечание — Сложная система разрешения идентификаторов может рассматриваться как резольвер PID-идентификаторов (3.3.3), но часто реализуется как совокупность различных преобразователей адресов или служб разрешения имен.

3.3.5    клиентское приложение (client application): Прикладная программа, которая получает доступ к дистанционному обслуживанию обычно в другой компьютерной системе.

3.3.6    сервер выделения ресурсов (resource server): Компьютер, который в конечном итоге предоставляет доступ к объекту, указанному в запросе конкретного клиентского приложения.

3.3.7    промежуточный преобразователь адресов; преобразователь адресов HTTP (resolver proxy; HTTP resolver proxy): Приложение, которое реализует службу поддержки использования РЮ (3.2.4), преобразованных в URI (3.4.3), для доступа к ресурсам или к иной информации, относящейся к РЮ, или к тому и другому одновременно.

3.3.8    сетевой клиент (web client): Клиентское приложение, способное осуществлять доступ к интернет-ресурсам с использованием протокола HTTP.

3.4 Действия

3.4.1    разыменовать (dereference): Осуществить доступ к запрошенному значению по ссылке (3.1.17).

Примечание — Использование URI (3.2.4) в контексте разыменования означает получение того представления ресурса, на которое указывает URI.

3.4.2    преобразовать, разрешить (resolve): Преобразовать идентификатор (3.2.1) в другое имя или в адрес, подходящий для осуществления доступа к ресурсу.

Примечание — Процесс преобразования (разрешения) адресов может потребовать нескольких шагов, вплоть до получения соответствующего адреса ресурса.

3.4.3    преобразовать идентификатор в URI (urlify an identifier): Закодировать идентификатор (3.2.1) как соответствующий URI (3.2.4).

Примечание — Например, это может быть сделано в целях создания активируемого идентификатора (3.2.6).

4 Общее описание

Постоянные идентификаторы (РЮ) могут существовать в любых видах электронных ресурсов, и настоящий стандарт не устанавливает для них никаких явных ограничений, однако следует иметь в виду, что тип ресурса, определенный РЮ, оказывает определенное влияние на требования к конкретным индивидуальным постоянным идентификаторам. Ресурсы могут принадлежать к одному из трех основных типов:

-    независимые ресурсы, отображенные на рисунке 1;

-    любой раздел подобного индивидуального ресурса, требующий в дальнейшем описания, и

-    коллекция ресурсов, запрашиваемая как единое целое.

Электронный    Электронный

Рисунок 1 — Использование уникальных PID для указания пути от исходного ресурса к целевому

5

1

* Различные типы пакетов, которые могут использоваться для организации хранения собранных ресурсов как идентифицируемых объектов архива, обсуждаются в модели OAIS. При этом решение по контенту пакета принимается его создателем на основе какого-либо содержательного или управленческого критерия. Например, стандарт METS [20] обеспечивает именно такую идентификацию пакетов.

2

) Это может показаться неудачным практическим результатом, так как большинство http-серверов допускает манипулирование унифицированными идентификаторами ресурсов независимо от конкретного местоположения ресурса. Однако в действительности бывает очень трудно поддерживать эту независимость без применения механизмов переадресации с аналогичными функциями администрирования, как, например, в системе PURL, которая рассматривается в разделе В.1.

13