Сущность электронной библиотеки

Введение[править]

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

В статье рассматривается сущность библиотеки и ее взаимосвязь с метаданными и каталогом АБИС, а также возможность создания электронной библиотеки из каталога АБИС.

Стандарт ГОСТ Р 7.0.96 «Электронные библиотеки»[править]

В стандарте дается следующее определение электронной библиотеки (ЭБ):

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

Электронные объекты определены как:

Объект электронной библиотеки – идентифицируемая единица хранения. 

Примечание: объектом электронной 
библиотеки может быть документ, гиперссылка.

Т.е. ЭБ хранит не документы, а другую абстракцию – электронные объекты. Почему сделан такой переход?

Архитектура библиотек на базе АБИС[править]

Классическая архитектура крупных библиотек строится вокруг АБИС. Центральным звеном являются записи в каталоге, по которым ведется поиск, выстраиваются навигаторы и производится обслуживание.

Добавление любого электронного документа (ЭД) также описывается в АБИС, а ссылка на документ проставляется в соответствующее поле «полный текст» к записи в АБИС.

В этом смысле, все метаданные об электронных документах содержатся в АБИС и строить отдельную базу данных только для электронных документов не имеет смысла.

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

Но веб-плееры быстро устаревают и библиотека оказывается перед выбором: полностью заменить веб-плеер на новый или оставить возможность пользоваться и старым плеером и новым. В пользу использования старого плеера может быть, например, наличие в нем закладок, пометок и комментариев, оставленных пользователями и которые сложно мигрировать. Библиотека может добавить еще одну прослойку – сервер OpenURL, который позволит пользователям открыть документ в том плеере, в котором ему будет удобно и обеспечивает независимость (постоянство) ссылки на документ от конкретного плеера. В поле полного текста в АБИС тогда указывается ссылка на сервер OpenURL.

Сам веб-плеер, как правило, умеет только отображать документ, работать с закладками/комментариями и искать текст только по документу. Так как плееры делаются независимыми от АБИС поставщиками, то они, в большинстве случаев, владеют только информацией об документе и не привязаны к АБИС. В этом и есть преимущество такой схемы: жизненный цикл АБИС составляет 10-20 и более лет, в то время как плееры устаревают за 3-5 лет и менять их легко именно благодаря слабой связности между АБИС и плеером.

abis-openurl-player-storage.png

Применяя простой фильтр к каталогу АБИС можно получить каталог ЭБ, а при открытии записи перейти к просмотру документов. Чтобы такая схема формально попадала под определение ЭБ в проекте стандарта и введены электронные объекты (ссылки на OpenURL-сервер) вместо документов.

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

abis-openurl-player-storage-isnotlibrary.png

Федеральным библиотекам очень хотелось, чтобы реализованная у них архитектура называлась ЭБ, но реализовали они это желание спорным способом весьма неудачно.

Но можно ли назвать электронной библиотекой схему АБИС/OpenURL/плеер?

Недостатки использования АБИС в качестве электронной библиотеки[править]

Недостатки описанного подхода построения ЭБ как АБИС с плеером является обратной стороной слабой связности плеера с АБИС:

  1. Если плеер ничего не знает о контексте в котором документ открыт, он не может адаптировать свой интерфейс к размещению документа в каталоге, истории перемещения пользователя и т.д. Например, если пользователь провел поиск и открыл документ, для перехода к следующему найденному документу придется закрыть документ, вернуться к результатам поиска и открыть следующий найденный документ. Также изолированный плеер документа не может обеспечить такой функционал, как поиск по всем электронным документам просто потому, что ничего о них не знает.
  2. Если будет найдена ошибка в описании в каталоге, то исправлять описание придется не только в каталоге, но и во всех плеерах. В некоторых системах реализован импорт MARC-записи (Vivaldi), но импорт не решает всех вопросов, т.к. нужна автоматическая синхронизация, а лучше, использование единого источника метаданных.
  3. Комментарии, выделения и т.д. являются составной частью плеера, в то время как для переносимости их следует сделать частью метаданных документа и, в рамках подхода, переместить в АБИС.
  4. Физические метаданные, которые плеер может непосредственно извлечь из документа (размер, число страниц), в АБИС приходится заносить в ручном режиме.

Поколения электронных библиотек[править]

Так в чем отличие бытового понимания ЭБ от описанной выше архитектуры? Для ответа на этот вопрос я выделил четыре поколения электронных библиотек в хронологическом порядке появления первых решений:

  1. Документы хранятся и просматриваются на локальных компьютерах. Примеры: проект «Гутенберг», Adobe Digital Editions, Calibri.
  2. Документы доступны на сайтах в интернете без узкоспециализированного функционала. Примеры: библиотека Максима Мошкова, документы на системах управления контентом (Joomla!, WordPress) без библиотечных модулей.
  3. Документы доступны на сайтах с полнотекстовым поиском и метаданными. Примеры: DSpace, Biblio STOR-M, Xerox ПЭБ, некоторые ЭБС.
  4. Документы доступны на сайтах и собственных мобильных приложениях. Примеры: ЛитРес, Bookmate, ELiS, остальные ЭБС.

Во всех поколениях есть метаданные о документах (как минимум заголовок). Есть навигация и/или поиск.

Сущность электронной библиотеки[править]

Если рассмотреть структуру DSpace, то в нем есть метаданные, навигация, поиск и документы в виде файлов (bitestream). Т.е. нет даже плеера и кажущееся отличие от АБИС с заполненным полем «полный текст» только в том, что для АБИС сам файл хранится за пределами системы, а в DSpace непосредственно внутри.

Но есть принципиальное отличие DSpace, Calibri, ЛитРес от АБИС с ссылкой на плеер: в электронной библиотеке метаданные и документы хранятся в одной информационной системе. Части этой информационной системы взаимодействую между собой, а не изолируются.

ditital-library.png

При загрузке книги в Calibri или DSpace нет нужды в ручном режиме указывать MIME-тип или размер файла в отдельных полях записи т.к. MIME-тип можно определить из расширения файла, а размер просто подсчитать.

Если вы импортируете EPUB в Calibri, программа сама извлечет из документа метаданные в Dublin Core.

Еще одно очевидное отличие ЭБ от АБИС с плеером: основной сущностью ЭБ является электронный документ, метаданные лишь часть документа и без документа не имеют смысла. В АБИС основной сущностью является запись о документе, т.е. метаданные.

Каталог АБИС традиционно спроектирован для нахождения документа из поиска или навигации. ЭБ проектируются для выдачи документа. Различие в решаемых задачах влияет на архитектуру системы и видимость в интернете. Т.к. каталоги АБИС традиционно имеют плохую видимость для внешних поисковых систем (как и сами плееры), внешний поисковый трафик типично низкий. Типовой внешней поисковый трафик публичных ЭБ составляет 40-70% и SEO-оптимизация оказывает значительное влияние на успешность проекта.

Подводя предварительный итог, следует заключить, что не следует называть решение на АБИС с использованием OpenURL и набора плееров электронной библиотекой. А DSpace является ЭБ, не смотря на полное отсутствие плеера.

Место плеера в электронной библиотеке[править]

Но тогда следует поставить вопрос об месте плеера в ЭБ. По отношению к ЭБ плеер может быть специально-разработанный (собственный) и внешний. Если разработанный для ЭБ плеер является неразрывной часть ЭБ, то не отделяет ли внешний плеер метаданные от самого документа подобно тому, как это делает АБИС? Иными словами, может ли информационная система с внешним плеером быть ЭБ?

Да, может. Достаточно посмотреть на современные ЭБС, большинство из которых используют внешние плееры. При этом требуется интегрировать плеер в ЭБ.

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

Работа плеера ЭБ отличается от открытия документа из АБИС через OpenURL: у внешнего плеера есть методы (API) выполнения функциональных запросов и библиотека обязана их реализовать и правильно настроить плеер для использования с конкретным документом и в конкретном контексте.

Итак, для ЭБ неважно используется собственный плеер или внешний, само использование внешнего плеера не обязано приводить к малой функциональности ЭБ.

Как сделать библиотеку из АБИС[править]

Раз можно использовать внешние плееры в ЭБ, то можно ли сделать на базе АБИС электронную библиотеку? Как уже пояснялось, нельзя сделать ЭБ просто добавив фильтр наличия непустого поля «полного текста». Возможный вариант здесь такой: ЭБ должна быть модулем к ЭК АБИС. При размещении документов, они должны загружаться через интерфейс ЭБ, но метаданные размещаться в ЭК АБИС. ЭБ должна иметь собственный интерфейс и размещаться на отдельном сайте (подсайте). Плеер ЭК должен быть интегрирован в ЭБ и ее поиск.

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

Более реалистичным является другой подход: ЭБ и ЭК – совершенно разные системы. Документ добавляется в ЭБ и проводится его первичное описание, затем метаданные синхронизуются с АБИС. Чтобы изменения метаданных из АБИС попали в ЭБ, синхронизация метаданных АБИС – ЭБ должна быть двунаправленной. Требования и к АБИС и к ЭБ при этом упрощаются: достаточно наличие OAI-PMH для каждой из систем.

Итак, создать из каталога АБИС электронную библиотеку возможно, но требуется работа по глубокой интеграции плеера с АБИС, которая приведет к созданию отдельного модуля ЭБ к АБИС.

Электронный объект, информационный объект, документ, DELOS[править]

Достаточно давно была разработана модель электронной библиотеки под названием DELOS. В этой модели применялся термин information object в центре модели. И я сам рассказывал недавно, что электронная библиотека скорее работает с ресурсами, чем с документами. Ресурсы, информационные объекты, электронные объекты... Дак может электронный объект из ГОСТ - это просто другое название информационного объекта или ресурса?

content_domain_DELOS.png

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

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

Библиотека хранит (с точки зрения пользователя) документы. А внутри себя оперировать может и ресурсами и информационными (можно назвать и электронными) объектами. Но все равно - хранит она документы.

Заключение[править]

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

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

Конечной целью ЭБ является выдача документа.

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