РОССИЙСКИЙ НАУЧНЫЙ ЭЛЕКТРОННЫЙ ЖУРНАЛ Электронные библиотеки

География и стандарты метаданных для электронных библиотек: содержание, применение, проблемы

О.Л. Жижимов, Н.А. Мазов

 

Аннотация

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

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

Введение

Развитие графических пользовательских интерфейсов, основанных на взаимодействии пользователя с географическими картами с развитым инструментарием по навигации, масштабированию и поиску информации с использованием ее географической привязки, позиционирует сервис работы с упомянутой информацией как неотъемлемую часть любой современной информационной системы. Примером могут служить не только популярнейшие справочные системы информирования мобильных пользователей с использованием спутниковой навигации, не только сервисы информационных монстров типа Google или Yandex, предоставляющие как возможность просмотра детализированной информации о земной поверхности, так и создание пользовательских мультимедиа архивов с координатной привязкой документов, но и всевозможные так называемые геоинформационные системы (ГИС), полностью основанные на работе с информацией, имеющей географическую привязку. Наверное, можно утверждать, что географическая привязка информации и способы работы с такой информацией – достаточно актуальная задача для разработчиков современных информационных систем. Актуальность этой задачи для так называемых ГИС-систем определяется потенциальной возможностью включения в область их действия огромных массивов информации, изначально к ним не относящимся – библиографической информации, цифровых коллекций, коллекций описаний музейных экспонатов и пр. Можно также утверждать, что эта задача актуальна и для так называемых электронных библиотек (ЭБ), поскольку в нашем понимании последние являются ничем иным, как хорошо регламентированными информационными системами, ориентированными на работу с электронными документами. Впрочем, под термином «Электронные библиотеки» сегодня могут пониматься [1]

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

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

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

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

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

  • Как должна выглядеть пресловутая географическая привязка для обеспечения минимальной функциональности геосервисов?

  • Что должна означать географическая привязка цифрового объекта, где в электронной библиотеке должна содержаться информация о географической привязке цифровых объектов?

  • Какие минимальные сервисы ЭБ необходимы для работы с географической информацией?

  • Какие программные продукты управления цифровым контентом электронных библиотек в России, претендующие на первые роли, сегодня могут обеспечить минимальный геосервис?

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


Ниже сделана попытка сформулировать ответы на поставленные вопросы.


Как должна выглядеть пресловутая географическая привязка

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

  • точку, определяемую парой координат;

  • замкнутый контур, определяемый последовательностью пар координат;

  • некоторый нормализованный термин, ассоциируемый с этой областью.

Очевидно, что последнее представление географической привязки не является однозначным, поскольку:

  • географические названия зависят от времени и языка;

  • любая область (контур) может содержать в себе множество названий включаемых в себя областей.

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

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

Табл.1 Схемы метаданных

Тип физического или цифрового объекта

Схема метаданных

Библиографическая информация

MARC21[5,6], RUSMARC [10]

Архивы, коллекции документов

OAI, Digital Collection, DC [11]

Описания предметов культурного наследия

CIMI [12,13,], CIDOC CRM [21]

Информационные ресурсы WWW

DC [11], GILS [14]

Цифровые карты, космические снимки, данные дистанционного зондирования

CSDGM [17], ISO-19139, ISO-19115, GEO [16]



И если в схемах метаданных для цифровых карт, космических снимков и т. п. (CSDGM, ISO-19115, ISO-19139, GEO и др.) элементы, описывающие географическую привязку цифрового объекта, с необходимостью присутствуют, то в других схемах наличие подобных элементов не очевидно, а заполнение их – не обязательно.

Табл. 2 Поля MARC21

Поле

Подполе

Описание

Примеры

034

$d - западная долгота

$e - восточная долгота

$f - северная широта


$g - южная широта


Coded Cartographic Mathematical Data.

Подполя $d, $e, $f, и $g всегда присутствуют вместе. Координаты могут быть записаны в форме hdddmmss (полушарие-градусы-минуты-секунды), однако другие формы записи также допустимы. Выравненные вправо подэлементы заполняются лидирующими нулями.

Односимвольный код полушария: W(-) = запад, E(+) = восток, N(+) = север, S(-) = юг. Возможны обозначения +/-. Лидирующий символ + может быть опущен.

hdddmmss:

1#$a a$b22000000$dW1800000$eE1800000$fN0840000$gS0700000

hddd.dddddd:

1#$a a$dE079.533265$eE086.216635$fS012.583377$gS020.419532

+-ddd.dddddd:

1#$a a$d+079.533265$e+086.216635$f-012.583377$g-020.419532

Без лидирующего +

1#$a a$d079.533265$e086.216635$f-012.583377$g-020.419532

hdddmm.mmmm:

1#$a a$dE07932.5332$eE08607.4478$fS01235.5421$gS02028.9704

hdddmmss.sss:

1#$a a$dE0793235.575$eE0860727.350$fS0123536.895$gS0202858.125

255

$с – сведения о координатах.

Cartographic Mathematical Data

##$aScale 1:41,849,600$c(W 180°--E 180°/N 90°--S 90°).

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

USmarc, marc21

USMARC, MARC21 – американский стандарт на библиографические описания различных объектов, ориентированный на структуру записи ISO-2709. Географические координаты могут присутствовать в полях 034 и 255.

Наличие огромных информационных массивов, описанных в соответствии с правилами MARC21, с незаполненными полями 034 и 255 обедняет возможности географического поиска информационных ресурсов. Поэтому сегодня выполняется ряд проектов по восстановлению в записях значения поля 034 в записях MARC21 на основе информации, содержащей географические названия, например, из поля 043 (географический код). Подобный проект сегодня выполняется совместно библиотекой конгресса США и OCLC (см. http://www.loc.gov/cds/notices/2010-04-19.pdf от 19 апреля 2010 года).

RUSmarc

RUSmarc – российский вариант схемы описания библиографических данных UNIMARC, ориентированный на структуру ISO-2709, учитывающий национальные правила каталогизации. Географические координаты могут присутствовать в полях 123 и 206.

Табл. 3 Поля RUSMARC

Поле

Подполе

Описание

Примеры

123

$d - западная долгота


$e - восточная долгота


$f - северная широта


$g - южная широта


Координаты для планетарных и земных картографических материалов. Обязательное для картографических материалов. Повторяется, если материал содержит данные в различных масштабах и с разными координатами. Каждое подполе координат ($d-$g) имеет фиксированную длину в 8 символов и не повторяется. Каждое подполе содержит следующие данные:

  • Позиция символа 0. Стороны света.
    Односимвольный код: w = запад, e = восток, n = север, s = юг

  • Позиции символов 1-3. Градусы.
    3 цифровых символа, выравниваемые вправо заполнителями - нулями.

  • Позиции символов 4-5. Минуты.
    2 цифровых символа, выравниваемые вправо заполнителями - нулями

  • Позиции символов 6-7. Секунды.
    2 цифровых символа, выравниваемые вправо заполнителями - нулями



123 2#$aa$b150000$b25000$de0150000$ee0173045$fn0013012$gs0023035

Часть карты Заира с линейными масштабами 1:150000 и 1: 25000, долгота - от 15oВ до 17o30'45" В, широта - от 1 o30'12" С до 2o30'35" Ю.


206

$d – сведения о координатах. Факультативное, не повторяется

Обязательное для картографических материалов.

Индикатор 1: Определяет, структурированы ли данные в поле

# - Данные представлены в неструктурированном виде
0 - Данные представлены в структурированном виде


Индикатор 2: # (не определен)


Неcтруктурированное представление

206 ##$aScale 1: 6 336 000 (W 170o -W 50o/N 80o -N 40o)

Структурированное представление

206 0#$bScale 1: 6 336 000$d(W 170o -W 50o/N 80o -N 40o)

Следует заметить, что поле 123 содержит те же данные о масштабе и координатах, которые записываются в поле 206, но в кодированной форме. Следует также обратить внимание, что представление координат в поле 123 в RUSMARC совместимо с представлением MARC21 (поле 034). Однако обратной совместимости нет! Возможное представление координат в RUSmarc ограничено единственным форматом DMS (градусы, минуты, секуды), отсутствует возможность представление координат в виде десятичной дроби от градусов (DDD), минут (DMM) или секунд (DMSS). Возможности представления координат в MARC21 существенно шире, они не ограничены жестким форматом и допускают представление DDD, DMM и DMSS. Следствием этого является тот факт, что точность представления координат в RUSmarc ограничена одной угловой секундой, что сегодня является явно недостаточным, т.к. одна угловая секунда на мериадиане соответствует примерно 33 метрам, точность доступных GPS приемников – 5-10 метров.

GILS

Более совершенной в части географической информации является схема GILS – Goverment Internet Locator Service [14].

<spatialDomain>

<boundingCoordinates>

<westBoundingCoordinate>112.5

</westBoundingCoordinate>

<eastBoundingCoordinate>129

</eastBoundingCoordinate>

<northBoundingCoordinate>=-13.5

</northBoundingCoordinate>

<southBoundingCoordinate>-35.5

</northBoundingCoordinate>

</boundingCoordinates>

<place>

<placeKeywordThesaurus>

</placeKeywordThesaurus>

<placeKeyword></placeKeyword>

</place>

</spatialDomain>

Dublin Core

DC – Dublin Core – наиболее известная схема данных для каталогизации информационных ресурсов общего назначения. Информация о географической привязке объекта может содержаться в элементе COVERAGE. Допускается применение элементов типа «точка» и типа «прямоугольник». Ниже приведен пример XML-представление этого элемента схемы DC.

DCMI Point

<coverage type="spatial"
scheme="DCMI Point">

<point>

<east> 115.85717 </east>

<north> -31.95301 </north>

</point>

</coverage>

DCMI Box

<coverage type="spatial" scheme="DCMI Box">

<box name=" Western Australia">

<northLimit> =-13.5 </northLimit>

<eastLimit> 129 </eastlimit>

<southlimit> -35.5 </southlimit>

<westlimit> 112.5 </westlmit>

</box>

</coverage>

CIMI

Схема CIMI – Computer Interchange of Museum Information. Информация о пространственных координатах описываемого объекта в схеме CIMI может присутствовать в следующих элементах

objectInfo

digitalObject

actualDo

spatialReferencingSystem

xCoordinateInSpatialReferencingSystem

yCoordinateInSpatialReferencingSystem

Кроме этого схема CIMI включает на верхнем уровне все элементы Dublin Core, что позволяет использовать элемент COVERAGE для географической привязки контента.

GEO

GEO [16] – профиль Z39.50 [15] соответствуют стандарту представления пространственных метаданных FGDC [18] Content Standards (CSDGM) [17]. В Табл.4 приведено соотношение полей, содержащих граничные географические координаты для профиля Z39.50 GEO, стандарта FGDC Content Standards и MARC21 [19-20].

Форма представления координат для профиля GEO соответствует форме MARC21. Также следует заметить, что стандарты ISO-19115, ISO-19139 содержат аналогичное описание географической привязки контента информационного объекта.

Табл. 4 Географические координаты в GEO

Элемент схемы

Содержание

FGDC

MARC21

idinfo/spdom/bounding/westbc

West Bounding Coordinate

1.5.1.1

034 d

idinfo/spdom/bounding/eastbc

East Bounding Coordinate

1.5.1.2

034 e

idinfo/spdom/bounding/northbc

North Bounding Coordinate

1.5.1.3

034 f

idinfo/spdom/bounding/southbc

South Bounding Coordinate

1.5.1.4

034 g

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



Что должна означать географическая привязка цифрового объекта

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

В качестве примера последнего можно привести следующее. Несомненно, явную географическую направленность имеет элемент «Место публикации» (MARC21 260$a) в традиционном библиографическом описании. Этот элемент не описывает информационный контент, но он описывает контекст (что, где, когда и пр.). К сожалению, в существующих библиографических схемах данных нет возможности указать явную географическую привязку в виде географических координат, как для этого элемента, так и для других элементов контекста.

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

  • место создания;

  • место публикации;

  • место проведения;

  • место находки;

  • место хранения;

  • место обитания;

  • место выставки;

  • место реставрации;

  • место съемки;

  • и др.

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

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

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

Справедливости ради следует отметить, что географическая координатная привязка контекста (класс E47) присутствует в определениях онтологии в сфере документов по культурному наследию (CIDOC CRM). Это не удивительно, т. к. в описаниях объектов культурного наследия описание контекста имеет не меньшее значение, чем описание контента. К сожалению, в CIDOC CRM геометрия всех объектов сводится к точке.

О географических сервисах ЭБ

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

Если иинимальными сервисами ЭБ считать следуюшие

  • каталогизация

  • навигация

  • поиск

  • извлечение данных

  • визуализация

то можно рассмотреть каждый их перечисленных применительно к географической информации.

Каталогизация

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

Навигация

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

Поиск

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

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

  • Поисковая компонента Z39.50 (CIP для геосистем).

  • Система SRW как попытка переформулировать идеологию Z39.50 в терминах http/xml/soap/, т.е. в терминах WEB-сервисов.

  • Система SRU – передача запросов SRW через URL.

Ниже мы рассмотрим только систему Z39.50 и CIP, т.к. функциональность SRW и, тем более, SRU весьма ограничена.

Модель поиска Z39.50 основана на использовании запросов RPN (возможно частичное строковое представление, например, PQF), которые используют логически (AND, OR, NOT) связанные операнды, включающие писковые термы и списки поисковых атрибутов. Поисковые атрибуты принадлежат различным классам (наборам) и группам, они уточняют смысл и структуру поискового терма. В Z39.50 для фиксации граничных координат существует следующие атрибуты (наборы BIB-1, GILS, GEO) для группы USE (тип 1)

Табл. 5 Атрибуты Z39.50 USE (тип 1)

Bib-1

GILS

GEO

Название

1118

2038

2038

West Bounding Coordinate

1119

2039

2039

East Bounding Coordinate

1120

2040

2040

North Bounding Coordinate

1121

2041

2041

South Bounding Coordinate


а также атрибуты группы Relation (тип 2)

Табл. 6 Атрибуты Z39.50 Relation (тип 2)

Attrubute type 2

Name

Название

1

Less than

Меньше чем

2

Less than or equal

Меньше чем или равно

3

Equal

Равно

4

Greater or equal

Больше чем или равно

5

Greater than

Больше чем



и Structure (тип 4)

Табл. 6 Атрибуты Z39.50 Structure (тип 4)

Attrubute type 4

Name

Название

109

Numeric String

Строковое представление числа


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

При этом запрос RPN (представление PQF) выглядит следующим образом

@and @and @and @attr bib1 1=1118 @attr 2=2 @attr 4=109 e1

@attr bib1 1=1119 @attr 2=4 @attr 4=109 w1

@attr bib1 1=1120 @attr 2=4 @attr 4=109 s1

@attr bib1 1=1121 @attr 2=2 @attr 4=109 n1

Как видно даже простой поисковый запрос имеет достаточно сложную структуру. Однако, если использовать расширения Z39.50, сформулированные в CIP в виде расширения наборов поисковых атрибутов (набор CIP), которые приведены в Табл.7-9,

Табл. 7 Атрибуты CIP Use (тип 1)

2060

BoundingRectangle

The limits of coverage of a item descriptor expressed by latitude and longitude values in the order western-most, eastern-most, northern-most, and southern-most. For item descriptors that include a complete band of latitude around the earth, the West Bounding Coordinate shall be assigned the value -180.0, and the East Bounding Coordinate shall be assigned the value 180.0.

2059

SpatialCoverage

The spatial coverage element indicates (usually in very coarse resolution) the spatial coverage of the data described.



Табл. 8 Атрибуты CIP Relation (тип 2)

7

Overlaps

The intersection between the target spatial/temporal coverage and the spatial/temporal coverage defined by the search term is non-null (i.e. the target and search coverage have an area in common).

8

Fully Enclosed Within

The target spatial/temporal coverage is fully enclosed within the spatial/temporal coverage defined by the search term.

9

Encloses

The target spatial/temporal coverage fully encloses the spatial/temporal coverage defined by the search term.

10

Fully Outside Of

The intersection between the target spatial/temporal coverage and the spatial/temporal coverage defined by the search term is null (i.e. the target and search coverage have no area in common).

Табл. 9 Атрибуты CIP Structure (тип 4)

Id #

Name

ASN.1 Type

Description

200

Coordinate

InternationalString

The term is a coordinate. The coordinate is formatted according to WGS84, i.e. a coordinate is in decimaldegrees and is represented as a string.

201

Point

InternationalString

The term is a point. A point is an ordered pair of coordinates, i.e. a x (longitude) and y (latitude) pair. The longitude and latitude are separated with a space or comma delimiter.

202

Bounding Polygon

InternationalString

The term is a bounding polygon. A bounding polygon is an ordered list of Coordinates as x (longitude) and y (latitude pairs expressed with a space or comma delimiter between the x and y and a space between the pairs, as so: x,y x,y x,y etc. (e.g. 102.32,45.003 " " -103.45,46.007 " " 103.79,46.141 etc.). If a bounding polygon is used to define an enclosing region, the terminal pair shall be encoded with the same values as the initial pair to define full enclosure. To determine the enclosed region, read the points counterclockwise, then the area to the left of the reading position is the one in question. A bounding polygon with only two pairs entered shall represent a bounding rectangle where the north-west and south-east corners of a described area are provided, using a system orthogonal to the axes of latitude and longitude. CIP 204 2.3 Composite EXTERNAL The term is a compound element which must be defined externally. The exact external compound is implied by the Use attribute.

то приведенный выше запрос для Z39.50 будет эквивалентен следующему запросу для CIP

@attr cip 1=2060 @attr cip 2=7 @attr cip 4=202 {(n1,w1),(s1,e1)}

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

  • пользователь задает геометрический примитив, например, в виде граничного прямоугольника

  • информационная система, используя сервис обратного геокодирования фиксирует все географические названия в заданной области

  • информационная система производит поиск в соответствющих полях по всем зафиксированным географическим названиям

Очевидно, эффективность этого варианта существенно проигрывает по сравнению с вариантом прямого геометрического поиска.

Извлечение данных

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

Визуализация

Для визуализации метаданных, имеющих географический аспект, должны использоваться не только обычные пользовательские интерфейсы, позволяющие просматривать содержание всех элементов, но и интерфейсы, связанные с визуализацией данных на географической карте (топооснове). Это обычный сервис для, так называемых, ГИС-систем. Однако в существующих ЭБ он не используется.

О программных и информационных продуктах

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

Из известных авторам программных комплексов единственным свободно распространяемым программным продуктом, который позволяет работать с географическим аспектом информационного контента, является программный комплекс GeoNetwork []. Несмотря на то, что основное его предназначение – обеспечение управления специализированным цифровым контентом на основе метаданных FGDC, ISO-19115 и ISO-19139, он допускает частичное использование дополнительных XML-схем данных и управление различными типами цифровых объектов (снимки, текстовые документы и т.д.).

Электронная библиотека

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

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

    • Текстовые файлы – статьи, отчеты, доклады и т.п.

    • Презентации выступлений

    • Векторные и растровые изображения

    • Аудио и видео записи

    • и пр.

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

Пример информационной системы

Одна из возможных реализаций основных серверов центра схематично представлена на Ошибка: источник перекрестной ссылки не найден2. На схеме показано, что этот набор практически не зависит от типа операционной системы и функционирует на наиболее распространенных ОС (Solaris, Windows, различные Linux). Представленные серверы являются бесплатными для некоммерческого использования (кроме ZooPARK) и реализуют большинство из необходимых функций.

Модернизированная DSpace и комплекс ZooPARK

Примером ЭБ с минимальными геосервисами может служить модернизированная в рамках текущих работ система DSpace.

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

Поиск информации по различным критериям осуществляется через интерфейсы ZooPARK, который напрямую связан с метаданными DSpace, хранящимися в СУБД PostgreSQL. Существенно, что одновременно поиск может происходить по разным информационным источникам. При этом поисковые запросы формулируются в терминах Z39.50 или CIP (для географической информации). Это обеспечивает единый язык запросов для разных информационных систем, не привязанный к схемам и структурам данных конкретных целевых систем.

Функция интеграции разнородных данных при поиске в сервере ZooPARK реализуется через модель поиска Z39.50, которая изначально не связана ни с какой целевой системой. В соответствии с международным стандартом это обеспечивается через специальный язык запросов, основанный на использовании стандартизированных наборов поисковых атрибутов и правил их комбинации

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

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

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

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

Литература

  1. Жижимов О.Л., Мазов Н.А., Федотов А.М. Некоторые заметки об эволюции цифровых репозитариев традиционных библиотек к полнофункциональным электронным библиотекам // Вестник Владивостокского государственного университета экономики и сервиса. Территория новых возможностей. - №3 (7). - 2010. - с.55-63.
  2. Жижимов О.Л., Мазов Н.А. Принципы построения распределенных информационных систем на основе протокола Z39.50. - ОИГГМ СО РАН, Новосибирск: ИВТ СО РАН. - 2004. - ISBN 5-9554-0017-6. - 361 с.
  3. Жижимов О.Л. Мазов Н.А. Об использовании географических координат при поиске библиографической информации // Научные и технические библиотеки. - 2009. - № 1. - С. 54-60.
  4. Жижимов О.Л. Мазов Н.А. Об интеграции библиотечно-информационных и геоинформационных технологий // Вычислительные технологии. Совместный выпуск. Вестник КазНУ им. Аль-Фараби. Сер. математика, механика, информатика. - 2008. - Т. 13. - № Ч. II. - С. 97-101.
  5. MARC Standards ( http://www.loc.gov/marc/).
  6. Форматы MARC21 (http://marc21.rsl.ru).
  7. Metadata Object Description Schema (MODS) / Offical Web Site. ( http://www.loc.gov/standards/mods/mods-schemas.html)
  8. MARCXML – Marc21 XML Schema / Offical Web Site. (http://www.loc.gov/standards/marcxml )
  9. Information and documentation — MarcXchange / DRAFT INTERNATIONAL STANDARD ISO/DIS 25577 ( http://www.loc.gov/standards/iso25577/ISO_DIS_25577__E_.pdf)
  10. RUSMARC. Российский коммуникативный формат представления библиографических записей в машиночитаемой форме. ( http://www.bookresearch.ru/rusmarc.htm).
  11. DCMI - Dublin Core Metadata Initiative (http://www.dublincore.org/).
  12. The CIMI Profile Release 1.0H A Z39.50 Profile for Cultural Heritage Information http://www.cimi.org/documents/HarmonizedProfile/HarmonProfile1.htm ( Профиль CIMI выпуск 1.0H: Профиль Z39.50 для информации о культурном наследии, ноябрь 1998, перевод Мазов Н.А., 2003, ОИГГМ СО РАН, 72 с.)
  13. Мазов Н.А., Жижимов О.Л. Профиль Z39.50-CIMI как основа интеграции информационных ресурсов по культурному наследию // Материалы Международной конференции EVA-2003, 1-5 декабря 2003, г. Москва, С. 2-8-1 - 2-8-3
  14. Application Profile for the Government Information Locator Service (GILS), Version 2, November 24, 1997. ( http://www.gils.net/prof_v2.html).
  15. ANSI/NISO Z39.50-1995. Information Retrieval (Z39.50): Application Service Definition and Protocol Specification / Z39.50 Maintenance Agency Offical Text for Z39.50-1995. - July 1995.
  16. Douglas D. Nebert. Z39.50 Application Profile for Geospatial Metadata or "GEO"/ Version 2.2 / U.S. Federal Geographic Data Committee
    (http://www.blueangeltech.com/Standards/GeoProfile/geo22.htm)
  17. Content Standard for Digital Geospatial Metadata (http://www.fgdc.gov/metadata/contstan.html)
  18. FGDC - Federal Geographic Data Committee (http://www.fgdc.gov)
  19. Crosswalk: USMARC to FGDC Content Standards for Digital Geospatial Metadata.// [электронный ресурс]
    http :// www . alexandria . ucsb . edu / public - documents / metadata / marc 2 fgdc . html
  20. Crosswalk: FGDC Content Standards for Digital Geospatial Metadata to USMARC // [электронный ресурс]
    http://www.alexandria.ucsb.edu/public-documents/metadata/fgdc2marc.html
  21. Definition of the CIDOC Conceptual Reference Model // Produced by the COM/CIDOC Documentation Standards Group, continued by the CIDOC CRM Special Interest Group, Version 4.2.1,October 2006. ( http://cidoc.ics.forth.gr/docs/cidoc_crm_version_4.2.1.doc).
  22. GeoNetwork Opensource Community website/ - http://geonetwork-opensource.org/
  23. Catalogue Interoperability Protocol (CIP) Specification - Release B // CEOS/WGISS/ICS/CIP-B, Issue 2.4.75. - April 2005.

Об авторах

О.Л. Жижимов - Институт вычислительных технологий СО РАН, Новосибирск.

Н.А. Мазов - Институт нефтегазовой геологии и геофизики им. академика А.А. Трофимука СО РАН, Новосибирск

Последнее обновление страницы было произведено: 2011-03-29

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