На пути к бесшовной интеграции электронного архива с системами-

На пути к бесшовной интеграции электронного архива с системамиисточниками комплектования (Часть 2)
Шарп Роберт (Sharpe Robert)
Аннотация
Во время интеграции источников записей (например, систем электронного управления
документами и записями, систем архивирования интернет-контента, отдельных поступлений
информации и т.д.) с электронными архивными системами, часто приходится переводить
различные схемы, используемые в различных источниках в схему метаданных, используемую
данной архивной системой. Это приводит к определенной потере данных, связанных с
неточностью схем. Кроме того, и источник, и архивная система со временем подвержены
изменениям, а произведение соответствующих трансформаций так же является затратным.
Можно попытаться решить проблему, сформулировав определенные стандарты, но, принимая
во внимание длительную временную шкалу архивирования, это только смягчит, но не решит
проблему (см. Часть 1). Архивная система неизбежно должна либо обрабатывать различные
схемы метаданных, либо производить какие-либо другие преобразования, потенциально
приводящие к потере информации.
В Части 2 мы представляем альтернативный подход, который упростит интеграцию
между источниками и долгосрочными архивами по перечню определенных пунктов, позволяя
каждому типу записей использовать оригинальную описательную схему, использованную
источником (т.е. использовать поля метаданных, предназначенных для этого типа данных).
Подходящие технологии используются для обеспечения возможности просматривать,
изменять (если необходимо) и осуществлять поиск по каждому полю метаданных. Поэтому
внутренняя схема метаданных должна хранить структурные и технические метаданные, а
также метаданные, относящиеся к процессу хранения. Следовательно, архив должен
предоставлять всю функциональность, которую он предоставлял бы в том случае, если бы он
использовал фиксированную схему описания, не требующую комплексных описаний.
Введение
Электронное содержание архивной значимости должно быть внесено в электронное
хранилище для обеспечения его хранения на протяжении длительного срока. Характеристики
такого хранилища должны соответствовать справочной модели Открытых Архивных
Информационных Систем (OAIS). Это определяет функциональную и информационную
модель, которой должны соответствовать эти хранилища.
Одной из шести функций, определенных в OAIS, является поглощение. Эта функция
позволяет брать содержание из внешнего источника и перемещать его в хранилище. Вдобавок
к содержимому, необходимо с нулевыми потерями передать метаданные из источника в
архивную систему таким образом, чтобы ее можно было интерпретировать вне системы
источника.
Информационная модель OAIS помогает в анализе этой проблемы, определяя перечень
элементов, которые необходимо сохранить, и это понимается как часть процесса поглощения.
Концептуальный элемент, представляющий реальный интерес, называется Информационным
Объектом. Он эквивалентен архивной записи. Точно так же, как и в случае с записями,
Информационные Объекты могут быть рекурсивными, т.е. высокоуровневые объекты могут
содержать дополнительные Информационные Объекты.
Электронные Информационные Объекты содержат как Электронный Объект (обычно
совокупность файлов, которые должны быть поглощены), так и Описательную Информацию.
Для электронных записей Описательная Информация определяется как информация,
необходимая для характеристики объекта в более значимых концептах. На практике это
означает, что она состоит из:
Семантической информации, описывающей Информационный Объект в
терминах, не зависящих от электронных технологий, используемых Цифровым
Объектом. В идеале, эта информация не должна меняться в том случае, если технология,
используемая Электронным Объектом, проходит трансформацию (в т.ч. переводится в
новый формат).
Структурной
информации, объясняющей
как
Информационный
Объект
описывается Электронным Объектом (например, список файлов и их относительные путей).
Технические метаданные, обеспечивающие сохранение Цифрового Объекта
(например, формат файлов Цифрового Объекта). Они обычно ссылаются на внешние
источники с дополнительной информацией, необходимой для дополнения описания
(подобные системе реестров PRONOM).
В этом отношении структурная информация извлекается напрямую из Электронного
Объекта. Один из вариантов состоит в обработке большой структуры файлов как единого
Информационного Объекта. Альтернативой является создание концептуальной иерархии
2
Информационных Объектов, основанной, например, на системе папок высокоуровневого
Цифрового Объекта, каждая из которых используется для хранения дополнительных
Информационных Объектов.
В общем случае, технические метаданные также являются прямыми производными
Цифрового объекта. Этот процесс подразумевает физическое описание через процесс
идентификации формата, валидации формата, извлечения свойств, определения и извлечения
встроенных объектов. Эти встроенные объекты, в свою очередь, проходят процесс физического
описания на рекурсивной основе, до тех пор, пока рекурсия не заканчивается. Кроме того, этот
процесс может включать концептуальное определение, при котором будет обеспечено сохранение
сети технологически независимых компонентов и их ключевых характеристик вне зависимости от
любых трансформаций (в т.ч. от изменений формата), вызванных появлением более новых
технологий.
Тем не менее, семантическая информация обычно не является производной от Цифрового
Объекта. Ситуацию упрощает то, что в случае большинства архивов Информационный Объект
уже хранился в предшествующей системе (например, в электронных системах управления
документами и записями). Это означает, что семантическая информация уже существовала в
той или иной форме.
Эту информацию можно хранить в нескольких форматах. В определенных случаях это
будет набор стандартных схем, таких как Дублинское ядро (DublinCore), Закодиророванное
архивное описание (EncodedArchivalDescription), Схема описания объекта метаданными
(MetadataObjectDescriptionSchema) и т.д. Во многих случаях это будут собственные средства
(например, табличные базы данных), выбор которых определен электронной системой
управления документами и данными или другой системой. В этом случае иногда возможен
экспорт информации в более стандартизированной форме, но даже при этом не исключена
возможность потери информации, поскольку процесс перекодирования информации из одного
шаблона в другой зачастую весьма непрост.
Одним из способов решения данной проблемы является стандартизация метаданных
организации-источника. Однако данный способ работает только если все организации
находятся под общей юрисдикцией (например, если департаменты и организации отдельно
взятой страны будут хранить свои данные в национальном архиве). Этот подход,
уменьшающий разнообразие источников, уже обсуждался в предыдущей статье. Однако он
невозможен, если в архив поступают данные от организаций, не связанных друг с другом,
3
поскольку подобные стандарты ими, очевидно, будут улучшаться. Поэтому, несмотря на то,
что данный подход имеет место на существование, долгосрочные архивы не могут пренебречь
необходимостью обрабатывать многочисленные варианты подобной схемы.
В данной статье мы рассматриваем альтернативный подход, в рамках которого
хранилище создается предварительно, чтобы обеспечить поддержку различных семантических
информационных схем. Сложность создания такой системы состоит в том, что хранилище
должно поддерживать функциональность, которая взаимодействует с отдельными полями
метаданных, чтобы обеспечить возможность просмотра и изменения метаданных, поиска по
отдельному полю и другие возможности, основанные на значениях отдельных полей. Однако,
для того, чтобы обеспечить всю эту функциональность и сохранить поддержку различных
схем, необходимо ограничить экспорт метаданных исключительно форматом XML-документа
(любого типа схемы).
Этот подход был реализован на практике в электронной системе хранения
"Депозитарная ячейка Теселла" (Tesella'sSafetyDepositBox - SDB), включающей облачную
систему "Презервика" (Preservica). Данная система применяется широким кругом организаций
для хранения описательных метаданных для разнообразных решений.
Виды метаданных
Для облегчения проблемы, связанной с описанным выше разнообразием источников и
схем метаданных, хранилище должно различать следующие типы метаданных:
Структурные метаданные. Они используются для:
O
Идентификации существования каждого Информационного Объекта
O
Идентификации отношений между Информационными Объектами (как
иерархичных, в т.ч. родительских и дочерних, так и кросс-ссылочных)
O
Идентификации
электронных
файлов,
которые
описывают
Информационный Объект в соответствии с определенной технологией
O
Идентификации многочисленных описаний Информационного Объекта,
которые определяют объект в соответствии с различными технологиями и
различными целями (например, оригинал и копия, как в случае с уменьшенной
копией изображения).
O
Идентификации отношений между описаниями, хранящими
информацию об изменении объекта (имеются в виду изменения,
происходящие внутри системы).
4
Технические метаданные. Они используются для:
O
Идентификации формата каждого электронного файла, и
определения, подходит ли файл под описание этого формата.
O
Идентификации ключевых свойств каждого файла, которые могут
быть использованы для определения потенциальных проблем хранения, а также
для
определения
сохранения
(т.е.
ключевых
должны
свойств,
остаться
которые
требуют
неизменными
с
обязательного
определенными
допущениями) в рамках будущих трансформаций.
O
Идентификации объектов, встроенных в каждый файл, которые
также требуют сохранения и могут в будущем вызвать проблему
хранения.
O
Рекурсивной идентификации встроенных объекты в каждом из
встроенных объектов.
O
Идентификации существования сети технологически независимых
компонентов и их свойств, которые должны быть сохранены даже если
технология,
использованная
для
описания
Информационных
Объектов,
радикально изменилась (например, перемещение файла с изменением файловой
структуры).
Семантические или описательные метаданные. Они необходимы для
обеспечения возможности корректной интерпретации метаданных объекта человеком.
И структурные, и технические метаданные являются ключевыми для обеспечения
долгосрочного хранения Информационных Объектов в хранилище. Как таковые, они
должны быть доступны для машинного анализа, осуществляемого системой хранения.
Поэтому, система SDB использует собственную схему описания метаданных (XIP). В
технические метаданные включается все, содержащиеся в системе PREMIS, а так же
некоторые расширения, характерные для системы SDB. Структурные метаданные
обеспечивают эффективное хранение многочисленных описаний (например, не требуя
повторения детальной информации о файле, если этот файл присутствует более чем в одном
описании). XIP поддерживает экспорт в в форме стандартных схем, подобных METS (со
встроенными метаданными PREMIS).
Однако, описательные метаданные не предполагают подобной автоматической
функциональности, поэтому нет никакой необходимости распространять данную структуру
на этот тип метаданных. Поэтому SDB поддерживает добавление описательных
метаданных с использованием любой схемы описательных метаданных. Единственное
5
ограничение состоит в том, что они должны быть представлены в формате XML. Кроме
того, поскольку иногда один и тот же объект требует описания в соответствии с
различными схемами для различных целей, SDB позволяет описывать каждый элемент по
разным схемам. Очевидно, что наилучшим решением является использование различных
схем с минимальным повторением, чтобы минимизировать наложение, но эта добавочная
гибкость может быть полезной, если данный объект описан в различных системах, и эти
описания необходимо скомбинировать.
Несмотря на гибкость, описательные метаданные используются в различных
процессах в хранилище, а именно:
Во время поглощения, для извлечения метаданных из источника и безопасного
хранения.
Для просмотра пользователем полей метаданных.
Для редактирования авторизированными пользователями любого поля метаданных.
Для пользовательского поиска по любому полю метаданных.
Для любых других функций, зависящих от значения определенного набора полей
метаданных.
Итак, оставшаяся часть статьи объясняет, как можно обеспечить все эти функции, не
накладывая ограничений на описательные метаданные.
Поглощение
Пакет, используемый для начала поглощения системой OAIS, называется Пакетом
Подачи Информации (SIP). SIP должен содержать не только электронные поля, но и все
метаданные, необходимые для архивирования, которые не являются автоматическими
производными от содержимого. В них включаются и описательные метаданные. Поэтому
описательные метаданные должны извлекаться из источника и правильно соотноситься с
соответствующим Информационным Объектом.
Конкретный способ поглощения зависит от источника. Например, если есть прямая
связь между архивным хранилищем и системой источника (например, через API), то
извлечение и соотнесение метаданных будет происходить одновременно (т.е. в систему
источника будут приходить запросы о том, какие объекты требуют архивирования, и эти
объекты будут извлечены вместе с метаданными за одну операцию). Именно так и строится
SIP.
Альтернативным решением (в случае отсутствия API у источника) является
6
экспортирование содержимого из источника в определенной структуре (например, в
структуре каталогов, отражающей иерархические соотношения объектов) и включение
фрагментов метаданных, относящихся к каждому элементу. В таком случае процесс
поглощения может корректно
автоматически определять, какие файлы являются
содержимым, а какие одержат описательные метаданные и построить SIP как результат
экспорта.
В том случае, если определенное содержимое происходит из неофициального
источника (например, архивные материалы общественности), нужно применять похожий
подход к созданию SIP, например, создание Информационных Объектов на основе
физической иерархии, как если бы это был экспорт из системы источника. Поскольку не
существует требования использовать конкретную схему описания метаданных, можно
быстро создать SIP, добавляя любые описательные метаданные, доступные на любом уровне
(например, путем добавления некоторых общих метаданных только к Информационному
Объекту верхнего уровня).
Другие материалы могут быть извлечены из неконтролируемых источников (например,
при обходе веб-сайтов) и опять, максимально возможный объем метаданных должен быть
добавлен к каждому объекту. Однако в случае, если такие метаданные недоступны, процесс
поглощения не будет осложняться тем, что человеку придется вручную добавлять
информацию. Это хороший пример гибкости подхода, поскольку в данном случае может
быть добавлена информация о URL и информация браузера, без необходимости вставлять
информацию в стандартные поля, изначально для нее не предназначенные.
Итак, каждый Информационный Объект в SIP может использовать наиболее
подходящие схемы метаданных (или комбинации схем метаданных), для собственного
описания. Таким образом, это позволяет создать SIP без потери информации независимо от
источника. Это ключевой момент. Альтернативные подходы включают преобразование
информации, что может привести к ее потере. Конечно, подход, изложенный выше, не
препятствует преобразованию метаданных: он просто не требует его. Это означает, что нет
необходимости ждать улучшения метаданных перед поглощением информации цифровым
хранилищем. Вместо этого поглощение может произойти быстро для обеспечения
безопасного хранения, а преобразование (если оно нужно вообще) может быть выполнено
позднее (в рамках полностью контролируемой среды, что означает, что, если позднее
обнаружится, что произошли некоторые потери информации, то информация может быть
восстановлена).
7
Просмотр и редактирование метаданных
Метаданные, встроенные в схему XML, находятся в хранилище, однако в форме, которая
затрудняет ее человеческий анализ. Чтобы обойти эту проблему, метаданные могут быть
преобразованы
из
XML в
HTML
с
использованием Расширяемого
языка
стилей
преобразования (XSLT).
Аналогичным образом, для обеспечения возможности
редактирования метаданных
авторизованным пользователями, метаданные могут быть преобразованы в различные
представления HTML с использованием альтернативных XSLT. Их редактирование всегда
проверяется для того, чтобы результат (новый документ XML) остается совместимым с
соответствующими XML-схемами. Кроме того, дальнейшая проверка может быть настроена в
соответствии с требованиями.
Можно добавить дополнительные XSLT для обеспечения дальнейших преобразований
между схемами. Это может быть полезно, если будет предприниматься рационализация схем
после поглоения или во время экспорта элементов для конкретного сценария использования.
Одним из преимуществ такого подхода является то, что полное описание каждого
объекта присутствует в соответствующем фрагменте документа XML. Таким образом, после
редактирования требуется только создание нового фрагмента и обеспечение того, чтобы
дальнейшее редактирование объекта проходило только через этот фрагмент. Это означает, что
система может автоматически сохранить историю всех фрагментов и оставить контрольные
записи для всех изменяемых элементов. В таком случае она сможет отменить изменение
любого объекта, если это будет необходимо.
Поиск по полям метаданных
Другая потенциальная проблема, связанная с обеспечением поддержки любой схемы
метаданных, является обеспечение пользовательского поиска по полям метаданных, даже в
том случае, если хранилищу заранее не известно, что это за поля.
В ранних версиях SDB эта проблема была решена, путем описания различных полей
выражениями XPath. Тем не менее, этот подход требовал затрат времени и был очень
трудоемким в части добавления новых схем. Таким образом, эта система была заменена
8
поисковой сервер ApacheLucene [12] с открытым исходным кодом. Он автоматически
индексирует все метаданные в любой схеме, что позволяет осуществлять поиск по полям
метаданных с минимальными усилиями по конфигурации. Кроме того, возможно улучшение
поведения по умолчанию в том случае, если схема XML не является оптимальной (например,
текстовое поле XML, которое на самом деле содержит дату, будет рассматриваться как дата,
что будет использовано в ходе поиска).
Другие функциональности
SDB представляет собой систему документооборота, поэтому любые функции, которые
должны быть выполнены (например, поглощение, хранение, доступ, управление данными и
сохранение), осуществляются через ряд шагов документооборота. Есть ряд ключевых шагов
документооборота, которые в совокупности определяют набор общих процессов, которые
могут быть использованы для выполнения типичных задач (например, перевод содержимого в
новый формат из формата, который считается опасным для хранения).
Система очень гибкая и позволяет комбинировать новые элементы документооборота с
уже существующими для создания процессов, выполняющих различные функции. Эти
процессы могут использовать API для поиска любой архивной информации (в т.ч. и полей в
описательных схемах) и использовать эту информацию, чтобы определить, какие действия
выполнить. Таким образом, подход к поддержке разнородных схем не исключает
возможности совершения действий, которые меняются в зависимости от значения какоголибо поля в любом типе записи.
Администрация
SDB позволяет администраторам отслеживать схемы, разрешенные в системе, путем
загрузки схем в систему. Кроме того такие функции, как просмотр, редактирование и другие
преобразования могут быть также загружены. Это означает, что административный процесс
добавления новых описательных схем является простым и гарантирует, что хранилище
является самоописательным, т.е. том смысле, что информация, необходимая для
интерпретации описательных метаданных находится в самом хранилище.
Выводы
9
Эта статья описывает, как цифровое хранилище может позволить использование
разнородных схем описательных метаданных, в то же время обеспечивая все те функции,
которые
обычно
требуют
одной
фиксированной
схему:
в
частности,
просмотра,
редактирования каждого поля метаданных и поиска по полям. Такой подход значительно
снижает расходы на поглощение цифрового материала из любого нового источника и
позволяет различным организациям использовать одно и то же программное обеспечение без
необходимости внедрения общей схемы метаданных. Кроме того, поскольку этот подход не
требует преобразования метаданных, он снижает вероятность потери информации в результате
ее включения в архив. Он
позволяет производить
отложенные преобразования в
контролируемой среде с возможностью их отмены, что исключает возможность окончательной
потери информации. Даже в ситуациях с одной схемой этот подход предусматривает ее
будущие изменения, поскольку новые версии этой схемы могут быть легко введены в
эксплуатацию, не требуя сложной модернизации и переноса данных.
Этот подход был протестирован путем его имплементации в систему TessellaSDB и
продукты Preservica и, как таковой, находится в оперативном использовании в большом
количестве архивов и библиотек по всему миру, которые являются авангардом цифрового
хранения.
Ссылки
[1]ISO 14721:2003 (http://www.iso.org/iso/catalogue_detail.htm?csnumber=24683)
[2] http://www.nationalarchives.gov.uk/pronom/
[3]Adrian Brown (2007), DevelopingPractical Approaches to ActivePreservation. The
International Journal ofDigital Curation,Issue 1,Volume 2
[4]Robert
Sharpe
(2010)ActivePreservation
ofweb
sites,
Proceedings
ofInternational
WebArchivingWorkshopIWAW2010
[5]http://dublincore.org/
[6] http://www.loc.gov/ead/
[7] http://www.loc.gov/standards/mods/
[8] http://www.digital-preservation.com/solution/safety-deposit-box
[9]http://www.preservica.com
[10]http://www.loc.gov/standards/premis/
[11]http://www.loc.gov/standards/mets
[12] http://lucene.apache.org/solr
10