Вторая жизнь библиотек

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

Автоматизация библиотеки может идти в двух направлениях: информационная поддержка традиционных видов деятельности библиотеки (комплектование фондов, ведение каталога, поиск, выдача литературы читателям); создание полнотекстовой электронной библиотеки путем оцифровки всего библиотечного фонда. Задачи первого направления решают Автоматизированные Информационные Библиотечные Системы (АИБС) , а второго — Электронные Библиотеки (ЭБ) . Обе системы могут работать одновременно.

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

Стандарты каталогизации

Первые машинные библиотечные каталоги появились в середине прошлого века, а в 1965 году в библиотеке Конгресса США был создан первый стандарт для хранения и обмена библиографическими данными. Формат представления данных, соответствующий этому стандарту, получил название MARC (MAchine-Readable Cataloging) , а затем появились его различные версии, ориентированные на национальные правила каталогизации: UKMARC, USMARC, AUSMARC, CANMARC, DanMARC, NorMARC, SwaMARC и др. Для преодоления несовместимости этих форматов в 1977 году Международной федерацией библиотечных ассоциаций (International Federation of Library Associations, IFLA) был выпущен «Универсальный формат MARC» (Universal MARC Format, UNIMARC), основанный на требованиях Международного стандарта библиографических описаний (International Standard Bibliographic Description, ISBD). Предполагалось, что UNIMARC станет посредником между любыми национальными версиями форматов MARC и обеспечит конвертирование данных из национального формата в него, а из него — в другой национальный формат. В 1999 году в результате согласования и последующего слияния библиографических форматов США и Канады (USMARC и CANMARC) было объявлено об образовании нового формата XXI века — MARC21.

В результате сегодня имеется две конкурирующие ветви — UNIMARC и MARC21; первая поддерживается международной организацией IFLA и используется в основном в Европе и Азии, а вторая поддерживается библиотекой Конгресса США и используется в Северной Америке. В 1998 году появилась российская версия формата UNIMARC, адаптированная к действующим в России ГОСТам и Правилам каталогизации. Коммуникативный формат RUSMARC был разработан по заказу Министерства культуры в рамках программы LIBNET под эгидой Российской библиотечной ассоциации и сейчас поддерживается Национальной службой развития системы форматов RUSMARC.

Если сначала форматы MARC служили для хранения библиографических записей и для обмена ими, то сегодня они применяются только для файлового обмена библиографической информацией, а внутри АИБС данные могут храниться в любом виде, удобном разработчикам системы. Тем не менее, для того чтобы АИБС могла обмениваться данными с другими системами, в ней должна быть предусмотрена возможность преобразования из внутренней структуры в MARC и обратно. Таким образом, эта структура должна быть логически эквивалентна структуре MARC.

Почти за полвека существования и развития форматы MARC претерпели ряд изменений, но их основа, заложенная в 60-х годах XX века, когда еще не было ни реляционных СУБД, ни объектно-ориентированного программирования, не изменилась. Логическая структура стандарта описывается в терминах, обозначаемых числами полей, которые могут быть отмечены как периодические, и подполей, имеющих буквенно-цифровые обозначения, тоже единичных или множественных. Некоторые подполя отмечаются как «точки доступа» и являются поисковыми атрибутами. Всего подполей насчитывается более тысячи, а множественных — несколько сотен. На рис. 1 приведен небольшой фрагмент краткого описания формата RUSMARC.

Рис. 1. Фрагмент описания формата RUSMARC (буква «П» означает периодичность, или множественность, соответствующего поля или подполя)

Группа исследователей из Университета Северного Техаса проанализировала 56 млрд записей в формате MARC21, содержащихся во всемирном каталоге OCLC (Online Computer Library Center) [1], и оказалось, что 211 полей и 1596 подполей были использованы по крайней мере один раз, 7 полей встречались во всех записях, 14 полей встречались более чем в 80% случаев, 66% встречались менее чем в 1% случаев, а поле под номером 656 встретилось ровно один раз. Неизвестно, проводились ли аналогичные исследования в каком-либо из форматов семейства UNIMARC, однако можно предположить, что картина должна быть похожей — почти все поля и подполя используются, хотя значительная часть из них встречается редко. Таким образом, формальное следование стандарту предполагает использование более тысячи атрибутов, среди которых сотни множественных. Из-за этого разложение структуры библиографического описания на реляционные составляющие должно насчитывать сотни таблиц, что делает применение реляционной модели неэффективным. Запрос на получение одного библиографического описания должен включать сотни операторов Left Join, а обработка одного библиографического описания (вставка или редактирование) должна осуществляться сотнями SQL-предложений.

В конце 60-x годов была разработана специализированная база CDS/ISIS (Computerised Documentation Service / Integrated Set of Information Systems) для ведения каталогов библиотек и музеев данных, которая с 1985 года развивается и поддерживается ЮНЕСКО. База предназначена для хранения и поиска текстовых данных переменной длины, а ее структура, так же как и структура формата MARC, описывается в терминах нумеруемых полей и подполей с буквенно-цифровыми обозначениями. Разнообразные методы индексирования, включая создание индексов по ключевым словам, позволяют реализовать различные варианты текстового поиска. База ISIS распространяется бесплатно и имеется ее версия для Windows — WINISIS. Однако, поскольку финансовые возможности ЮНЕСКО слабее возможностей компаний-разработчиков СУБД, пакеты для создания прикладного программного обеспечения для баз данных из семейства ISIS содержат существенно меньше функций, чем пакеты для создания прикладного программного обеспечения для коммерческих СУБД. Сегодня семейство баз данных ISIS предназначается главным образом для развивающихся стран.

Еще одна возможность для хранения библиографических данных — это использование коммерческих нереляционных СУБД, например ADABAS, реализующей модель данных NF2 (не первая нормальная форма). Запись в такой модели может содержать множественные поля и периодические группы, что близко к логической структуре MARC. На сегодняшний день, пожалуй, выбор такой СУБД для хранения библиографических данных оптимален, хотя в реляционные СУБД, такие как Oracle, IBM DB2 и Microsoft SQL Server, сегодня добавляются расширения: поддержка XML-структур, полнотекстовый поиск и т. п., что приводит к постепенному вытеснению баз данных, основанных на других моделях. Таким образом, сегодня для MARC-совместимой библиотечной системы имеется три возможности: использовать коммерческую реляционную базу данных, но без реляционной модели; использовать слабую по программистским возможностям специализированную СУБД из семейства ISIS; использовать коммерческую нереляционную СУБД.

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

Новые правила каталогизации

Существовавшие на момент появления формата MARC правила каталогизации были адекватны стоявшим тогда задачам создания библиотечных каталогов и применяемым компьютерным технологиям, однако с ростом объемов библиотечных баз данных, с появлением новых форм электронных публикаций и сетевого доступа к информационным ресурсам и т. п. их недостатки стали очевидны. Правила каталогизации были чрезмерно детальны, и составление на их основе библиографических записей требовало много ресурсов, а с другой стороны, они не учитывали новых реалий, поэтому в сентябре 1997 года было проведено исследование под эгидой организации IFLA для определения функциональных требований к библиографическим записям. Была предложена модель Functional Requirements for Bibliographic Records (FRBR), которая представляла собой концептуальную референсную модель, составляющую основу для детализации и построения модели данных.

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

Сущности модели поделены на три группы. В первую входят сущности, которые отражают результат интеллектуального труда или художественного творчества: work (произведение), expression (выражение), manifestation (воплощение) и item (физическая единица). Вторую группу составляют сущности, соответствующие ответственным за этот результат: person (физическое лицо) и corporate body (организация). В последующих версиях FRBR-модели во вторую группу была добавлена еще одна сущность — family (род). Третью группу составляют сущности, отражающие содержание интеллектуального труда или результата художественного творчества: concept (идея, концепция), object (предмет), event (событие) и place (место). На рис. 2 приведен пример связи этих сущностей между собой для третьей группы.

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

В 2002 году было принято решение заменить вторую редакцию англо-американских правил каталогизации, существующую с 1978 года, новыми правилами каталогизации RDA (Resource Description and Access), основанными на FRBR-модели. Новый стандарт в первую очередь предназначен для электронных каталогов. Разработка велась Объединенным комитетом (Joint Steering Committee), организованным Американской ассоциацией библиотек, Австралийским комитетом по каталогизации, Британской библиотекой, Британским институтом специалистов в области библиотек и информации, библиотекой Конгресса США. В июне 2010 года был опубликован окончательный вариант этих правил, а поскольку правила основаны на FRBR-модели, разработанной IFLA, они претендуют на роль международного стандарта.

Рис. 2. Пример связей тема/содержание

Работы по адаптации правил RDA в России ведутся, в частности, в национальном информационно-библиотечном центре «Либнет», и, хотя профессиональные каталогизаторы воспринимают новые правила критически и не стремятся их внедрять (например, главный библиотекарь Российской государственной библиотеки существенными недостатками правил RDA считает то, что они не годятся для карточных каталогов, до сих пор ведущихся во многих библиотеках нашей страны, и то, что терминология FRBR слишком абстрактна и плохо воспринимается как библиотекарями, так и читателями [2]), надо полагать, что компьютеризация библиотек постепенно будет сопровождаться внедрением новых правил.

Российские АИБС и их реализации

На российском рынке имеется более десятка АИБС (табл. 1), реализующих, как правило, АРМ библиотекаря. Дополнительно к АИБС может быть поставлен OPAC (Online Public Access Catalog) – модуль доступа к электронному каталогу библиотеки через Сеть. Исключение составляет система OPAC-Global (Midi, Mini), в которой соединены и АРМ библиотекаря, и читательский интерфейс доступа к каталогу.

Таблица 1. АИБС на российском рынке

Системы «Руслан» и «Фолиант» в качестве кандидатов не рассматривались: несмотря на положительные отзывы, их стоимость из-за необходимости приобретения лицензий на СУБД Oracle слишком высока для бюджетной организации. Система «Колибри+» отпала, поскольку использует морально устаревшую СУБД Btrieve. Система «Нева» использует собственный механизм управления данными и предназначена для небольших библиотек, в которых, как правило, нет администраторов баз данных, что для институтов РАН не актуально. Система «Ирбис» имеет большое число внедрений, в том числе в институтах РАН, однако построена на CDS/ISIS и для нее потребуется в будущем переделка электронного каталога под новые правила каталогизации RDA, для которых больше подходит реляционная модель данных.

Хорошее впечатление произвела система OPAC-Global. Работа читателя и библиотекаря ведется через браузер и не требует установки специального ПО на рабочем месте, и если бы в дальнейшем не планировался переход на правила RDA, то эта АИБС была бы достойным кандидатом. К сожалению, разработчики не планируют переход на одну из распространенных коммерческих реляционных СУБД.

Клиентская часть системы «Буки» написана на морально устаревшей Visual FoxPro, а при анализе других систем на платформе Microsoft SQL Server выяснилось, что в них реализован один из трех вариантов хранения библиографического описания.

1. Хранение всего библиографического описания в одном поле типа text или image в одном из форматов MARC.
2.  Распределение библиографического описания по двум таблицам: в первой, основной таблице для каждого библиографического описания заводится строка, и часть атрибутов библиографического описания, не являющихся множественными, хранится в отдельных столбцах этой строки; во второй, дополнительной таблице, связанной с первой, каждому оставшемуся атрибуту, имеющему непустое значение, соответствует отдельная строка.
3. Хранение всего библиографического описания в одном поле в виде библиографической карточки.

Первый вариант хранения реализован в системах «Академия+», «АС Библиотека-3», «МАРК-SQL» и «Моя библиотека», второй вариант реализован в системах «Абсотек Юникод», «АзЪ», третий реализован в системе «Библиобус». Ни один из этих вариантов не воплощает реляционную модель, в которой каждому атрибуту сущности должен соответствовать отдельный столбец, что согласуется со сформулированным утверждением о невозможности эффективной реализации реляционной модели при действующих стандартах.

Среди систем, реализующих первый вариант хранения, наиболее популярна «МАРК-SQL», а среди систем, реализующих второй вариант, можно отметить «Абсотек Юникод». К достоинствам этой системы можно отнести структурированное хранение данных, а также наличие в базе данных представлений, хранимых процедур и функций, использование технологии «тонкий клиент», открытость значительной части кода. Система функционально богата, однако пользовательский интерфейс не очень удобен для библиотекаря, например система создавалась путем перевода и адаптации французской системы, что было сделано не везде удачно. К недостаткам системы можно также отнести неполное соответствие стандарту RUSMARC — тест на соответствие стандарту эта система не прошла, и при импорте пропали, например, связи многотомника с отдельными томами. Благодаря структурированному хранению данных система «Абсотек Юникод» удобна для перехода в дальнейшем на правила RDA, однако для того чтобы библиотекари могли начать ее использовать, нужно потратить много времени на доработку.

Система «МАРК-SQL» имеет очень много внедрений и получила свидетельство национальной службы развития системы форматов RUSMARC на соответствие стандарту, однако неструктурированное хранение данных в формате MARC осложняет переход на правила RDA. Пользовательский интерфейс тоже не слишком удобен для библиотекаря — формы ввода сведений об издании содержат много полей и подполей, хотя реально заполняются далеко не все и пользователь может потратить много времени на выбор нужных. В системе предусмотрена возможность создания шаблонов, в которых задается список полей и подполей для заполнения, но, чтобы создавать шаблоны, администратор системы должен быть хорошо знаком с форматом MARC, что, возможно, имело бы смысл, если бы в будущем не планировался переход на RDA.

В итоге из систем «Абсотек Юникод», «МАРК-SQL» и «Библиобус» наилучшей для библиотекаря, на наш взгляд [3], оказалась система «Библиобус». Интерфейс сделан с заботой о библиотекаре — здесь удобно вводить данные в привычном для него виде библиографической карточки, а не заполнять отдельные поля, соответствующие формату MARC, как это делается в «МАРК-SQL», тем более что потом эти отдельные поля все равно преобразуются в одно и хранятся в одном столбце в базе данных. Дополнительным преимуществом системы является возможность импорта из базы данных БЕН РАН сведений о тех изданиях, которые поступают в библиотеку ИПМ через БЕН.

Если же сравнивать поставляемые отдельно OPAC-модули, предоставляющие доступ к электронному каталогу через Интернет, то электронный каталог «ABSOPAC Unicode», соответствующий системе «Абсотек Юникод», несомненно, выигрывает по сравнению с электронным каталогом, соответствующим системе «Библиобус». Главное преимущество «ABSOPAC Unicode» в том, что он позволяет не только найти нужную литературу в каталоге, но и увидеть, доступны ли экземпляры, и сделать заказ, а электронный каталог системы «Библиобус» такой возможности не предоставляет. Система заказа литературы может быть приобретена дополнительно как отдельный модуль, однако разработчики «Библиобуса» обещают в будущем добавить функцию заказа литературы в свой электронный каталог.

Литература

1. Moen William. Data-Driven Evidence for Core MARC Records // Information Standards Quarterly. — 2010. — Special Edition: State of the Standards and Year in Review. — №1: V. 22.

2. Бахтурина Т. А. Будущее каталогизации в России и в мире // Научные и технические библиотеки. — М.: Министерство образования и науки Российской Федерации; Государственная публичная научно-техническая библиотека России, 2010. — Вып. 9. — С. 34-44.

3. Горбунов-Посадов М. М., Ермаков А. В., Луховицкая Э. С., Скорнякова Р.Ю. О выборе автоматизированной информационной библиотечной системы для библиотеки ИПМ . Препринт ИПМ № 2, М.: ИПМ, 2011. — 32 с.

Алексей Ермаков (ermakov@keldysh.ru), Римма Скорнякова (rimmaskorn@gmail.com) — сотрудники ИПМ им. М. В.Келдыша РАН (Москва).