РОССИЙСКИЙ НАУЧНЫЙ ЭЛЕКТРОННЫЙ ЖУРНАЛ Электронные библиотеки
2005 | Том 8 | Выпуск 1

Среда сервисов
распределенных цифровых объектов

Роберт Канн
Корпорация национальных исследовательских инициатив

Роберт Виленский
Калифорнийский университет в Беркли


Содержание

1. Введение
2. Обзор и определения
2.1. Неформальный обзор
2.2. Определения
3. Доступ к цифровым объектам
3.1. Протокол доступа к репозиторию
(i) Доступ к цифровому объекту (ACCESS_DO)
(ii) Депонирование цифрового объекта (DEPOSIT_DO)
(iii) Доступ к сервисам ссылок (ACCESS_REF)
3.2. Инфраструктура серверов меток
3.3. Дополнительные сервисы ссылок
4. Придание семантики меткам
5. Заключение и выводы
Благодарности


1. Введение

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

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

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

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

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

2. Обзор и определения

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

2.1. Неформальный обзор

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

Такие взаимодействия, как помещение цифровых объектов в репозитории или доступ к цифровым объектам в репозиториях, совершаются на основе протокола доступа к репозиториям (repository access protocol, RAP), который должны поддерживать все репозитории.

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

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

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

2.2. Определения

Определим наши понятия более формально и несколько подробнее опишем операции над различными компонентами Системы.

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

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

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

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

Хранимый цифровой объект - это цифровой объект, помещенный в репозиторий. Кроме того, предполагается, что метки сделаны известными системе серверов меток, как описано ниже. Такие метки являются зарегистрированными. Зарегистрированный цифровой объект это хранимый цифровой объект, чья метка зарегистрирована. (Заметим, что метка не может быть зарегистрирована, пока соответствующий ей цифровой объект не будет сохранен). Репозитории обеспечивают пользователям доступ к хранимым объектам на условиях, которые могут быть установлены депонентом и/или данным репозиторием.

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

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

Простой протокол доступа к репозиторию (RAP) поддерживается каждым репозиторием (и определен в разделе 3.1). Здесь специфицированы только минимально необходимые аспекты RAP. Мы полагаем, что эти аспекты RAP, или RAP в целом, станут подмножеством протокола интерфейса, используемого для репозиториев, и требуют только функций или операций RAP, не связанных ни с какой реализацией надмножеств этого протокола. В частности, RAP предоставляет возможность доступа к хранимому цифровому объекту или его метаданным путем спецификации его метки, типа запроса к сервису и дополнительных параметров. Если этот запрос компилируется, то результат этого запроса к сервису называется распространением. Распространение является результатом запроса к сервису доступа вместе с дополнительными присоединенными к нему данными, специфицируемыми далее.

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

Первоначальный репозиторий, который используется для депонирования зарегистрированного цифрового объекта, называется репозиторием записи (repository of record, ROR). Репозиторий записи ROR отвечает за авторизацию дополнительных экземпляров цифровых объектов в других репозиториях, за внесение изменений или удаление этих дополнительных экземпляров цифровых объектов, как правило, под управлением создателя. Однажды назначенный репозиторий записи ROR может в последующем поменяться авторизованной стороной на другой репозиторий, но данная процедура здесь остается не специфицированной. Понятие репозитория записи ROR не определено для хранимых цифровых объектов, которые не зарегистрированы.

Метка - это глобально уникальная строка, создаваемая авторизованным генератором меток. Она состоит из двух логических частей, связанных промежуточным символом разделителя. Этими двумя логическими частями являются: 1) имя локального агентства по именованию, которое контролирует процесс порождения меток, и 2) локально уникальная строка, которая присваивается одним из генераторов меток. Создатель может запросить метку у генератора меток, но может и предложить локальную строку для последующего использования. Процесс порождения локальных меток должен гарантировать уникальность локальных строк. Метки, в принципе, не имеют ограничений по длине, однако в любой момент времени должно существовать значение максимальной длины, используемое по умолчанию, которое может быть при необходимости увеличено.

Для обеспечения уникальности меток имена локальных агентств по именованию контролируются глобальным агентством по именованию для всей Системы. Глобальное агентство по именованию порождает и присваивает имена локальным агентствам по именованию, которые используются генераторами меток, ими авторизованными. Предполагаемое локальное агентство по именованию может предложить свое имя для проверки правильности и регистрации глобальному агентству по именованию. Локальное агентство по именованию с именем «X» может создать дополнительное производное агентство по именованию с именем «X.Y» и т.д., которое может авторизовать свой собственный генератор меток. (В данный момент остается не специфицированным, будут или нет различаться пространства имен агентств по именованию для репозиториев и генераторов меток.)

В дополнение к первому глобально присвоенному компоненту (скажем, «X»), каждый последующий компонент агентства по именованию (скажем, «Y» или «Z») должен быть непустой и не содержать символа «.». Могут быть и другие ограничения на использование буквенно-цифровых символов в именах, присваиваемых агентствами по именованию. Например, используемый по умолчанию символ разделителя – это «/» (так что «X.Y/локальная строка» является типичной меткой, присваиваемой агентством по именованию «X.Y»). Могут быть определены как другие символы разделителей, так и синтаксис для их определения (в рамках ограниченного класса буквенно-цифровых символов), что приведет к другим ограничениям в использовании агентствами по именованию возможных символов в именах. Например, можно представить синтаксис, в котором иным разделителем будет другой не буквенно-цифровой символ, так что «%X.Y%локальная-строка» будет допустимой меткой. В данный момент мы не уточняем, как это может быть осуществлено, можно ли достичь того, чтобы идентичные метки с различными разделителями были идентичными или различались, в зависимости от того, существует ли для ограниченного набора символов символ «выход» (escape), и ограничиваются ли символы разделителя (например, является ли «a/b» именем, разрешенным агентством по именованию, и может ли оно быть использовано с разделителем, не используемым по умолчанию). Вначале имена агентств по именованию будут присваиваться консервативно и ограничиваться буквенно-цифровыми символами.

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

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

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

Данные в каждом цифровом объекте типизированы. Предполагается, что в Системе поддерживаются типы: битовая-последовательность, цифровой-объект, метка, множество-битовых-последовательностей, множество-цифровых-объектов и множество-меток. Другие типы данных могут быть определены и становятся доступны в Системе благодаря операторам конструкторов типов установить и компоновать; эти типы должны быть в последующем зарегистрированы в глобальном реестре типов. Механизм подобной регистрации в настоящее время не специфицирован. Заметим также, что в настоящий момент не существует (определенной) регистрации методов, ассоциированных с типами.

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

Мы будем неформально называть цифровые объекты, чьи данные представляют собой множество, один из элементов которого имеет тип цифровой-объект, составными цифровыми объектами. Цифровой объект, который не является составным, называется элементарным. (Отметим, что это определение явно исключает использование прилагательного «составной» к цифровому объекту, чьи данные сами являются цифровым объектом, т.е. имеют тип цифровой-объект, как отличающемуся от одноэлементного множества этого типа. Тем не менее, ничто не препятствует существованию подобных объектов).

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

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

Так как мы преднамеренно избегаем вопросов информационного наполнения в данной инфраструктуре, отметим, что приводимые далее сущности дают пользователям ряд средств для включения цифровых объектов, которые содержат или могут быть интерпретированы как имеющие одну и ту же или похожую информацию или материал. Например, литературное произведение может быть представлено в различных форматах, например, как LaTeX, PostScript и GIF-образы страниц. Каждое представление может соответствовать различным (простым) цифровым объектам, каждый с собственной уникальной меткой и другими метаданными. Теперь можно создать составной цифровой объект, данными которого будет множество этих элементарных цифровых объектов. Аналогично можно создать составной цифровой объект, чьи составные объекты являются представлениями литературных произведений Шекспира в формате PostScript. Метка этого составного цифрового объекта, в сущности, указывает коллекцию литературных произведений Шекспира в формате PostScript.

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

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

Цифровой объект может быть изменяемым в том смысле, что он может изменяться после размещения в репозитории. Хотя ни ключевые метаданные, ни цифровые объекты их содержащие, не могут быть изменены (кроме случая, когда сам исходный цифровой объект изменен), большинство других изменений допустимо. Минимальные изменения могут быть сделаны для исправления опечаток или других подобных ошибок; смена названия изменяемого цифрового объекта также допустима. Изменяемый цифровой объект может быть модифицирован для включения представления лежащего в основе произведения в новом формате. Изменяемость будет также полезна для рассмотрения цифровых объектов, которые спроектированы для изменений во времени или являются динамически вычисляемыми.

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

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

Изначально нет никаких специальных требований, как должен храниться цифровой объект в репозитории. Концептуально, описание цифрового объекта является строго логическим и не предполагает описания никакой практической реализации. В частности, возможно, чтобы в ответ на запрос доступа к конкретному цифровому объекту, сервер запускал программу, которая вычисляет цифровой объект на лету. Для разнообразных цифровых объектов также возможно их встраивание в программу, которая выдает их по запросу (например, в СУБД или системах управления знаниями). Программа сама может быть цифровым объектом. Таким образом, доступ и депонирование являются виртуальными процессами, и они могут или не могут вызывать реальный поиск и депонирование реальных объектов самих по себе, хотя такое реальное хранение и поиск, вероятно, будут общепринятыми.

3. Доступ к цифровым объектам

3.1. Протокол доступа к репозиторию

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

(i) Доступ к цифровому объекту (ACCESS_DO)

Доступ к цифровому объекту будет в общем случае вызывать сервисную программу, которая выполняет требуемые операции с цифровым объектом или с его метаданными, в зависимости от параметров, которые использованы в запросе к сервису. К числу определенных запросов к сервису относятся: metadata (метаданные), key-metadata (ключевые-метаданные) и digital object (цифровой объект). Первый из них запрашивает только метаданные, второй – только ключевые метаданные, а последний – весь цифровой объект (т.е. ключевые метаданные и данные). Могут быть определены также другие сервисы системного уровня. Возможными примерами таких сервисов могут быть encrypt (шифрование), т.е. возврат цифрового объекта в зашифрованной форме, или compress (сжатие), т.е. получение записи с меньшим множеством битов, которая применяется вместе со свойством (возможно, полного) восстановления исходных битов. Однако мы здесь не определяем подобные дополнительные запросы.

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

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

Как отмечалось выше, в зависимости от природы запроса к сервису ACCESS_DO, распространение может не храниться как цифровой объект сам по себе. Оно может вместо этого включать те данные, которые не содержатся ни в одном зарегистрированном цифровом объекте, например, фрагмент данных цифрового объекта, данные цифрового объекта в сжатом формате или результат исполнения данных цифрового объекта. Тем не менее, во всех случаях в него включаются ключевые метаданные (и, безусловно, метка) цифрового объекта.

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

(ii) Депонирование цифрового объекта (DEPOSIT_DO)

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

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

(iii) Доступ к сервисам ссылок (ACCESS_REF)

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

Первоначальный протокол RAP преднамеренно создавался простым, а управление всеми более сложными транзакциями предполагается осуществлять с помощью других протоколов или посредством последовательных расширений протокола RAP. В первом случае основное применение протокола RAP для более сложных репозиториев предполагает наличие других поддерживаемых протоколов (например, Z39.50, SQL3, ZQL, Dienst) как альтернативных протоколов доступа.

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

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

3.2. Инфраструктура серверов меток

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

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

Серверы меток предоставляют ряд сервисов, три из которых RESOLVE (разрешить), INSERT (вставить) и DELETE (удалить). Сторона, которая обладает полномочиями на ввод, удаление и другого рода изменения записей меток, для конкретного агентства по именованию называется администратором меток. Агентство по именованию в общем случае назначает от своего имени один или несколько репозиториев, которые будут действовать как администраторы меток. Агентство по именованию сообщает об этом назначении системе серверов меток.

(i) RESOLVE: Метка направляется серверу меток для определения сетевых адресов репозиториев, содержащих данный объект. Сначала эта метка отображается, чтобы определить местоположение сервера меток по таблице сервера справочника меток, но иным образом она не интерпретируется. Чтобы найти объект, можно также представить метку и в некоторую специальную систему, которая вызывает описанную выше процедуру, чтобы найти указанный объект. Локальные серверы меток могут использовать произвольную технологию для отображения. Серверы меток, поддерживаемые как часть инфраструктуры, отображают метки путем их хеширования.

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

Так как метка представляет собой уникальную строку, то она может быть отображена в реальный репозиторий с помощью одного из нескольких механизмов, включая механизм, который позволяет интерпретировать строку. Названия репозиториев не являются реальными сетевыми адресами; они сначала должны быть отображены на сетевое местоположение. Метод, совершающий подобные отображения, не специфицирован. Сервис меток является одним из возможных средств для обоих видов отображений; он может специфицировать, по крайней мере, местоположение интерфейса, который поддерживает протокол RAP для данного репозитория. Может также возникнуть потребность в явном предоставлении для репозиториев идентификатора страны, агентств по именованию и/или создателей. В данный момент, тем не менее, идентификаторы страны не используются.

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

(ii) INSERT (DELETE): Информация, ассоциирующая метки с сетевыми сервисами, помещается администратором меток или другими авторизованными им сторонами в систему серверов меток (удаляется из нее). Такие авторизованные стороны включают репозитории записей. Предполагается, что репозиторий записей информирует систему серверов меток, что он содержит (или уже не содержит) конкретный цифровой объект некоторое приемлемое время после депонирования его в репозитории (или удаления из него). Аналогично, репозиторий записей может информировать систему серверов меток об идентификаторах других репозиториев, которые авторизованы им хранить данный цифровой объект. Система серверов меток может исполнять некоторые административные функции при получении неавторизованных запросов. Кроме того, могут быть желательны некоторые формы информирования для того, чтобы могли быть обнаружены сущности с "плохим поведением".

3.3. Дополнительные сервисы ссылок

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

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

4. Придание семантики меткам

Как обсуждалось ранее, предполагается, что метка состоит из двух логических компонентов - имени локального агентства по именованию и идентификатора, уникального в рамках этого агентства. Эти агентства по именованию будут назначены некоторым образом. Например, может быть «агентство», называемое «berkeley», которое будет назначать другие агентства по именованию внутри домена «berkeley». Внутри домена «berkeley» имена локально присваиваются другим агентствам по именованию. Так, имя «berkeley.cs» может быть присвоено агентству, отвечающему за именование серии технических отчетов по информатике Калифорнийского университета в Беркли (или нескольких таких серий). Отметим, что имя этого конкретного агентства по именованию, вообще говоря, не соответствует корректному адресу Интернет, хотя и может следовать похожим синтаксическим соглашениям.

Конкретные агентства по именованию могут следовать своим собственным соглашениям относительно присвоения семантических или несемантических строк (в качестве идентификаторов – Прим. пер.) их объектам. Например, «berkeley.cs» может следовать предложенному соглашению для его технических отчетов и давать каждому из соответствующих цифровых объектов (будь то составные объекты или мета-объекты) локальную метку, например, «csd-93-712». (Сокращение «csd» - "Computer Science Division", факультет информатики - является, возможно, избыточным; тем не менее, мы используем его здесь чтобы указать на возможность отдельного агентства по именованию выпускать несколько различных серий.)

Полная уникальная метка для этого цифрового объекта будет иметь вид:

     berkeley.cs/csd-93-712,

где «/» отделяет имя агентства по именованию от уникального в рамках этого агентства идентификатора.

Наряду с этим, могут существовать цифровые объекты для данного произведения в каждом из представлений (форматов). Метки для этих представлений могут также быть семантически интерпретируемыми, например, строка «csd-93-712/all.ps» может быть уникальной локальной частью метки для цифрового объекта, соответствующего PostScript-версии этого произведения; «csd-93-712/all.tif» – меткой для версии в формате tiff. (Заметим, что символ «/» допускается в локальном имени. Может быть, полезно выделить и другие символы, но это не обсуждается далее в данной статье.)

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

     berkeley.cs/1994.12.05.23.42.12;7

Эти формы меток могут быть встроены в различные синтаксические адаптеры, чтобы отличать их от других нотаций в различных контекстах. Например, метка может быть выражена в синтаксисе унифицированных имен ресурсов (URN) следующим образом:

     <URN:ASCII:ELIB-v.2.0:berkeley.cs/csd-93-712>

Здесь относительно «ELIB-v.2.0» предполагается, что это - унифицированное имя ресурса в электронной библиотеке «ELIB», а относительно «-v.2.0» - что агентство по именованию использует свое специфическое соглашение по именованию. Другую возможность предоставляет нотация Грасса и Армса (1994), которая имеет сходство с универсальными локаторами ресурсов (URL) и порождает метку с префиксом «hdl://» (чтобы показать, что далее следует метка) или просто «//» (если важно отделить глобальный корень для метки), например:

     hdl://berkeley.cs/csd-93-712
     //berkeley.cs/1994.12.05.23.42.12;7

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

5. Заключение и выводы

Эта статья предлагает метод именования, идентификации и/или вызова цифровых объектов в системе распределенных репозиториев, который предоставляет высокую гибкость и хорошо приспособлен для реализации проектов национального масштаба. Он допускает возможность определения местоположения цифровых объектов без каких-либо предположений об объекте или его местоположении. Он также допускает соглашения, которые различные пользователи могут использовать для своей выгоды. Например, сервер ссылок может внутри ссылаться на объект с использованием его глобальной метки, и, кроме того, располагать сведениями о репозиториях, в которых этот объект предположительно (или известно, что) хранится постоянно. Если пользователь запрашивает объект, то сервер ссылок может обнаружить имя или адрес репозитория, определить сервис репозитория, и запросить репозиторий предоставить копию объекта пользователю. Альтернативно, вместо этого сервер может использовать метку объекта на стадии исполнения и направить запрос к серверу меток, чтобы получить имена репозиториев или сервисов, которые хранят данный объект. Эта система допускает также как общедоступные, так и закрытого типа агентства по именованию. Многие агентства по именованию будут закрытого типа, и будут обслуживать идентификаторами только их избранную клиентуру (например, сотрудников факультета, которым разрешено выпускать технические отчеты). Однако общедоступные агентства по именованию могут предоставлять идентификаторы всем, кому они требуются. Индивидуальные граждане, не связанные ни с каким официальным органом, могут использовать общедоступные агентства по именованию для получения идентификаторов объектов, которые они хотят хранить для своих нужд или для предоставления в общественный доступ по их собственной инициативе (это пример ситуации, когда создатель не контролирует агентство по именованию). В рамках проекта создания электронной библиотеки технических отчетов по информатике (Computer Science Technical Reports, CS-TR) Корпорация национальных исследовательских инициатив реализовала глобальное агентство по именованию и сервис по управлению метками, который допускает метки, как с семантикой, так и без нее. Этот сервис не предполагает использования семантики меток; тем не менее, участники имеют возможность использовать преимущества семантики меток, чтобы получать прямой доступ к объектам. Каждая участвующая организация вольна предложить или запросить имена по своему усмотрению. Каждое из этих имен может также иметь ассоциированный с ним не семантический идентификатор (такими как отметка-дата-время), который нигде иным образом не специфицируется в данном документе.

Благодарности

Это исследование было поддержано Агентством по перспективным исследовательским проектам (ARPA), грант No. MDA-972-92-J-1029 Департамента военно-морских исследований. Мы хотим поблагодарить Джерри Зальцера (Jerry Saltzer), Майкла Стоунбрекера (Michael Stonebraker), Джима Дэвиса (Jim Davis), Карла Лагозе (Carl Lagoze), Билла Армса (Bill Arms), Гектора Гарсиа-Молину (Hector Garcia-Molina), Джима Грея (Jim Gray), Патрика Лиона (Patrice Lyons), Дэвида Эли (David Ely), Джуди Грасс (Judy Grass), Барри Лейнера (Barry Leiner), Джона Гаррета (John Garrett) и всех участников проекта CS-TR за их полезные комментарии и прояснения в данной работе.


©  Роберт Канн, Роберт Виленский, 1995
©  Перевод на русский язык. Юрий Хохлов, 2005

Русский перевод публикуется в журнале с любезного разрешения авторов и Корпорации национальных исследовательских инициатив.
Оригинал работы: N.B. Kahn, R. and R. Wilensky, "A Framework for Distributed Digital Object Services". http://www.cnri.reston.va.us/home/cstr/arch/k-w.html


Последнее обновление страницы было произведено: 2005-06-28

Все предложения и пожелания по содержанию и структуре портала направляйте по адресу rdlp@iis.ru