CC BY
64
УДК 025.32:004.4'234
О. С. Колобов, А. А. Князева, И. Ю. Турчановский, Н. Т. Чуприкова
Институт сильноточной электроники СО РАН пр. Академический, 2/3, Томск, 645055, Россия
Институт вычислительных технологий СО РАН пр. Академический, 10/4, Томск, 645055, Россия
Томский политехнический университет пр. Ленина, 30, Томск, 634050, Россия
[email protected], [email protected] [email protected], [email protected]
ПРОГРАММНАЯ ПЛАТФОРМА OPAC
Работа посвящена рассмотрению элементов программной платформы для распространения библиографических записей. Данная платформа может применяться для широкого класса приложений работающих с библиографическими записями. Дано описание общей архитектуры программной платформы, характеристика программного интерфейса (API). В качестве рабочего примера рассматривается приложение OPAC, которое включает в себя поддержку технологии единого входа. Все рассмотренные элементы программной платформы базируются на идее применения слабосвязанных компонентов, модулей для построения комплексных программных приложений.
Ключевые слова: сервис-ориентированная архитектура, веб-сервисы, коммуникативные форматы, протоколы поиска и извлечения информации.
Z39.50 and MARC21 seems perched right on the knife edge between lunacy and genius. #CouldGoEitherWay
Poul-Henning Kamp (@bsdphk)
Введение
Одним из актуальных вопросов, является вопрос об облегченном подходе к распространению библиографических записей. Под облегченным распространением библиографических записей мы понимаем процесс интеграции библиографических данных во всевозможные информационные системы на основе технологий, которые доступны обычному пользователю. Сегодня для пользователей предлагается различные системы на основе открытых стандартов Z39.50 и MARC 2. Эти системы успешно работают для решения локальных задач, но в то же время они часто не пригодны для интеграции с другими системами, которые ориентированы на массовый доступ и высокую доступность. Разработчики программного обеспечения считают, что стандарты Z39.50 и MARC являются примером масштабной работы, но программное обеспечение, применяющее эти стандарты сложно развивать и поддерживать в современных условиях. Учитывая этот аспект, мы предприняли попытку рассмотреть процесс
1 ANSI/NISO Z39.50 - 1995 - URL: https://www.loc.gov/z3950/agency/markup/markup.html
2 MARC (Machine-Readable Cataloging) - URL: http://www.loc.gov/marc/
Колобов О. С., Князева А. А, Турчановский И. Ю., Чуприкова Н. Т. Программная платформа ОРАС // Вестн. Новосиб. гос. ун-та. Серия: Информационные технологии. 2015. Т. 13, вып. 4. С. 14-23.
ISSN 1818-7900. Вестник НГУ. Серия: Информационные технологии. 2015. Том 13, выпуск 4 © О. С. Колобов, А. А. Князева, И. Ю. Турчановский, Н. Т. Чуприкова, 2015
распространения библиографических записей на основе сервис-ориентированной архитектуры.
В работе рассматривается программная платформа, которая на данный момент не имеет отдельного названия. В качестве примера применения данной платформы на практике рассматривается приложение OPAC 3, которое работает в Томском политехническом университете. Показано как реализуются основные подходы и задачи, для облегченного распространения библиографических записей.
Процесс распространения библиографических записей тесно связан с вопросами поиска и извлечения информации, форматами обмена данными и дисплейного отображения данных для конечного пользователя. Ключевое место в этом процессе занимает электронный каталог библиотеки, который включает в себя описание материалов библиотечного фонда, а также описания электронных документов, которые не являются частью фонда библиотеки, но доступны по сети на основе лицензии. Для организации удаленной работы читателя с электронным каталогом применяется система OPAC, которая предоставляет возможность читателю на основе электронного каталога получить доступ к материалам библиотечного фонда или электронным документам.
Функции каталога
В работе [1] определены основные функции библиотечного каталога и даны рекомендации по дисплейному отображению библиографических записей. Эти рекомендации являются хорошей практикой и составлены международной группой специалистов. Все функции рассматриваются на основе концептуальной модели и логической организации составляющих компонентов библиотечного каталога и для OPAC определены четыре функции:
1) Find. Найти документ или документы, которые соответствуют указанным критериям пользователя;
2) Identify. Выявить сущность (т.е. подтвердить, что документ соответствует искомому документу, или различить два или более документа с схожими характеристиками);
3) Selection. Выбрать документ, которые соответствует требованиям пользователя для выполнения дальнейших действий (составление списков, создания удаленного заказа и др.);
4) Obtain. Получить документ во временное пользование, получить удаленный доступ к содержанию документа, выгрузить документ в файл и др.
Кроме того, OPAC должен поддерживать различные виды дисплейного отображения библиографических записей, а также, в зависимости от результатов поиска, предоставлять возможность нового поиска, сортировки библиографических записей.
Сервис-ориентированная архитектура
Если рассматривать OPAC не как монолитную программу, а как набор составных элементов, которые могут многократно использоваться в различных приложениях, тогда мы можем обратиться к сервис-ориентированной архитектуре в качестве базового архитектурного каркаса для приложения OPAC. Сервис-ориентированная архитектура (SOA) 4 - это архитектурное решение для создания приложения на основе слабосвязанных, заменяемых, распределенных элементов. Базовым понятием SOA является понятие веб-сервиса. Каждый из веб-сервисов имеет формальное определение, интерфейс, протокол для взаимодействия. Реализация того или иного веб-сервиса может многократно применяться в различных приложениях. Именно этот аспект является наиболее интересным для нас.
3 Онлайн-каталог со свободным доступом (Online Public Access Catalogue)
4 SOA (Service-Oriented Architecture). URL: http://www.opengroup.org/standards/soa/
Хранение и передача данных
Известно, что формат MARC является форматом обмена библиографическими записями между различными системами. Формат MARC также применяется как формат хранения данных. Для создания, чтения, редактирования MARC-записей используется специализированные программные средства (утилиты, программные библиотеки), которые специально разрабатываются для каждой из систем. В результате мы имеем большое разнообразие всевозможных программных средств для работы. Кроме того, часто встречаются ошибки программного обеспечения, что отражается на качестве записей. В связи с этим хотелось бы иметь надежное средство для представления, обработки и проверки на корректность MARC-записей. Один из подходов основан на применении XML и XML-ориентированных технологий 5 для работы с MARC-записями [2]. При таком подходе снимается системное ограничение на размер записи, а также появляется ряд новых возможностей:
• автоматическая проверка записи на соответствие схеме данных;
• формальный контроль записи на основе правил, записанных на языке высокого уровня;
• конвертирование записей из одного формата в другой;
• индексирование записей на основе логических выражений;
• дисплейное представление записи на интерфейсе конечного пользователя с использованием языка высокого уровня.
Также известно, что для передачи данных по сети на основе веб-сервисов широко применяется формат XML. Вопрос представления библиографической записи в формате XML решен положительно и на данный момент имеется несколько XML-схем, которые успешно применяются на практике. Преобразование MARC-записи в XML является взаимно-однозначным преобразованием, т. е. без потери данных.
Протоколы доступа к данным
В качестве классического протокола для поиска и извлечения MARC-записей применяют протокол Z39.50. В общем случае Z39.50 является протоколом с состоянием и для работы требуется выделенное сетевое соединение. Известно, что на основе протокола Z39.50 был создан протокол SRU 6, который, в свою очередь, является протоколом без состояния и совместим с SOA. Протокол SRU использует развитый язык запросов CQL для задания поисковых выражений. Далее, протокол SRU является XML-ориентированным протоколом, т. е. все записи представляются в форме XML и должны соответствовать заданной XML-схеме. Для программных приложений функцию поиска и извлечения MARC-записей можно рассматривать как веб-сервис SRU. При таком подходе функция поиска и извлечения записей в электронном каталоге может быть интегрирована в различные приложения, начиная от специализированных веб-порталов, заканчивая страничкой пользователя в социальной сети.
Программная платформа OPAC
Мы предлагаем рассматривать приложение конечного пользователя как набор составных программных компонентов, каждая из которых выполняет отдельную функцию и каждая из функций пригодна для повторного использования. Это позволит нам создавать различные программные приложения, которые разделяют общую функциональность. Таким образом, мы подошли к необходимости определить программную платформу.
5 Имеется в виду XML 1.0 и трансформация XML-документа на основе XSLT 1.0 и XPath 1.0.
6 SRU. URL: http://www.loc.gov/standards/sru/
Архитектура
Архитектура программной платформы имеет три звена - клиент, сервер, хранение данных (рис. 1). Такой поход удобен, если необходимо скрыть от клиента детали организации доступа к данным и предоставить клиенту только программный интерфейс высоко уровня.
Рис. 1. Архитектура программной платформы
Рассмотрим два типа клиентов (см. рис. 1). Первый получает доступ к ресурсам уровня приложения (application layer). Такие клиенты предоставляют интерфейс конечного пользователя в форме веб-приложения или мобильного приложения. Второй тип получает доступ с ресурсами уровня данных (data layer), и представляет собой клиента по работе с данными. Такой клиент может работать без участия пользователя. Звено хранения данных включает в себя системы хранения контента, которые подключаются к программной платформе на основе специализированных программных интерфейсов (API I/O файловой системы, API клиента для работы с базой данных и др.). Эти специализированные программные интерфейсы недоступны для клиента программной платформы непосредственно, а только через про-
граммный интерфейс платформы. Для доступа к ресурсам уровня данных предлагается использовать программный интерфейс (API) высокого уровня. Для этого API мы накладываем требование соответствия архитектурному стилю REST [3].
API
Все основные функции OPAC, а также ряд дополнительных функций, могут быть реализованы в виде веб-сервисов. Рассмотрим набор основных веб-сервисов, который позволит нам создать полнофункциональное приложение OPAC.
Таблица 1
Функции OPAC
№ Веб-сервис Протокол Формат
1 search, scan, explain REST API (HTTP GET) JSON
2 itemOrder REST API (HTTP GET) JSON
3 update REST API (HTTP POST) JSON
4 userBasket, userLists RESTful API (HTTP GET, POST, PUT, DELETE) JSON
Веб-сервисы search, scan, explain. Функции поиска и извлечения библиографических записей в программной платформе доступны на основе веб-сервисов search и scan. Для получения технической информации в поисковом индексе применяется сервис explain. Веб-сервисы search, scan, explain реализованы на основе протокола SRU и повторяют его семантику. Так, сервис search соответствует операции searchRetrieve протокола SRU, а сервисы scan, explain соответствуют операциям scan, explain протокола SRU. Протокол SRU является XML-ориентированным протоколом и в ответ на запрос возвращается XML-документ. В нашем случае сервисы search, scan, explain ответ на запрос возвращают в формате JSON 7. Ответ на запрос содержит отобранные в результате поискового запроса запись или список записей, а также ряд дополнительных данных о деталях поискового запроса, об общем количестве записей, о схеме данных для записей и др. Веб-сервисы search, scan могут применяться для доступа к данным на основе протокола Z39.50. Программная платформа автоматически выполняет трансляцию запросов к сервисам search, scan в соответствующие задачи Search, Retreival, Browse протокола Z39.50.
Веб-сервис itemOrder. Функция удаленного заказа в программной платформе доступна на основе веб-сервиса itemOrder. Веб-сервис itemOrder реализуется на основе расширенного сервиса протокола Z39.50. Все запросы к сервису itemOrder транслируются в задачу Item Order расширенного сервиса протокола Z39.50.
Веб-сервис update. Функция добавления и обновления записей в поисковом индексе в программной платформе доступна на основе веб-сервиса update. Веб-сервис update реализуется на основе расширенного сервиса протокола Z39.50. Все запросы к сервису update транслируются в задачу Update расширенного сервиса протокола Z39.50.
Веб-сервисы userBasket, userList. Функции по работе с пользовательской корзиной и списками литературы в программной платформе доступны на основе веб-сервисов userBasket и userLists соответственно. Веб-сервисы userBasket и userLists реализованы на основе техники CRUD 8 для работы с SQL-ориентированными базами данных. Все запросы к сервисам userBasket и userLists транслируется в SQL-запросы к соответствующим базам данных. Для этих сервисов определены схемы данных, которые не являются частью какого-либо стандарта, а относятся к спецификации программной платформы.
7 JSON (JavaScript Object Notation) - [URL: http://json.org/index.html]
8 CRUD - Create-Read-Update-Delete a database record.
Поисковый индекс
Работа с распределенными источниками данных. Подход работы веб-сервисов search, scan с электронными каталогами основан на идее добавления промежуточного уровня между программной платформой и электронными каталогами. Промежуточный уровень скрывает сетевую архитектуру электронных каталогов и представляет собой автономный поисковый индекс, который мы называем поисковым индексом программной платформы. Поисковый индекс содержит индексы всех записей, которые входят в электронные каталоги. В этом случае необходимо добиться синхронизации данных в направлении от электронного каталога к поисковому индексу (двунаправленная синхронизация не применяется). Такой подход позволяет приобрести новое качество поиска, которое выражается в следующих аспектах:
• одна точка входа в распределенный электронный каталог;
• один профиль индексирования записей;
• результаты поиска не зависят от состояния сети;
• минимальное время ожидания ответа на поисковый запрос;
• балансировка нагрузки.
Однако при выбранном подходе, появляется ряд задач, которые требуют успешного и полного решения, так как неполное их решение отрицательно сказывается на качестве поиска. Нам удалось выявить следующие проблемные задачи, требующие решения:
• обеспечение ссылочной целостности поискового индекса;
• актуализация записей поискового индекса;
• слияние записей.
Обеспечение ссылочной целостности поискового индекса. Так как ссылочный механизм для MARC-записей создавался до появления сети интернет, он имеет ряд системных ограничений. Специфика электронных каталогов на основе MARC состоит в том, что ссылки на записи должны быть только в пределах используемой коллекции записей. Это означает, что нет возможности средствами MARC генерировать ссылки на записи из другой коллекции, отличной от используемой. Прямолинейное объединение нескольких коллекций MARC-записей приводит нас к некорректному построению поискового индекса.
Поисковый индекс потенциально может включать такие записи, которые имеют один и тот же контрольный номер, и, как следствие, разные по содержанию записи с одинаковым контрольным номером нарушают ссылочную целостность индекса. Очевидно то, что для обеспечения ссылочной целостности индекса требуется перестраивать все ссылки в записях и желательно это выполнять в автоматическом режиме. Для решения этого вопроса можно применять подход, который основан на добавлении в контрольный номер записи информации об источнике записи, в нашем случае это уникальный префикс электронного каталога.
Актуализация данных. Одним из решений задачи актуализации записей поискового индекса, является синхронное выполнение отдельного процесса для включения в индекс новых записей, а также записей, которые были отредактированы. Записи, которые необходимо актуализировать, могут быть отобраны на основе точки доступа вида «дата последней модификации записи». Периодичность выполнения этого процесса может быть задана в зависимости от поставленной задачи.
Новые или отредактированные записи в количественном отношении к общему количеству записей в поисковом индексе, составляют доли процента, и поэтому их добавление выполняется достаточно быстро. В случае если индекс создается заново, то для этого необходимо учитывать, что первоначальный перенос всех записей в индекс может занять достаточно много времени. Этот подход требует придерживаться определенного порядка действий, который достаточно просто может быть записан в виде набора инструкций для командного процессора.
Вычисление дублетных записей, слияние записей. Обеспечение ссылочной целостности поискового индекса не гарантирует отсутствие дублетных записей в нем. Потенциально могут встречаться дублетные записи на описание одного и того же материала (объекта), так как записи помещаются в индекс из различных источников. Дублетные записи также могут при-
сутствовать и в отдельно взятом источнике. Решению этого вопроса посвящена отдельная работа [4]. Здесь мы приведем только список основных положений в вопросе слияния:
• для всех записей выполняется формальный контроль на наличие обязательных для заполнения полей. Если запись не прошла формальный контроль, то она исключается из рассмотрения;
• в случае если было выполнено слияние нескольких записей, то итоговая запись должна содержать информацию об источниках и контрольных номерах записей, которые использовались при слиянии;
• при работе с авторитетными записями, рассматриваются только те записи, на которые есть одна и более ссылок со стороны библиографических записей.
Балансировка нагрузки для поискового индекса. Количество обращений к поисковому индексу за единицу времени может быть большим 9 (например, более 50 запросов в секунду) и в этом случае необходимо свести к минимуму время ожидания ответа на запрос со стороны клиентского приложения. Для этого необходимо применять механизм балансировки нагрузки. Для балансировки нагрузки можно применять подход на основе техники master-slave. Суть этого подхода состоит в том, что любые запросы на изменение индекса выполняются для master-index, а запросы на поиск и извлечение записей от приложений конечного пользователя обрабатываются одним или несколькими slave-index, число которых может динамически меняться в зависимости от нагрузки на индекс. Синхронизация записей между masterindex и slave-index выполняется на основе master-slave-реплики включающей в себя новые или обновленные записи. Так как все изменения master-index являются инкрементальными, то не возникает коллизии, когда приложение конечного пользователя запрашивает отдельную запись, так как записи не удаляются из индекса. В случае, если индекс создается заново, то должны быть созданы заново и все slave-index.
Приложение OPAC
Обычно приложение конечного пользователя выполняет какую-либо полезную работу, и работа с поиском является только одной из задач приложения. В таком случае подход к организации работы приложения с программной платформой не должен нарушать используемый архитектурный каркас приложения.
В качестве примера работы с поисковым индексом рассмотрим приложение OPAC, основанное на минимальном наборе средств. Будем применять веб-сервисы программной платформы search, scan для работы с индексом. В соответствии с REST для извлечения записи использовать отдельный URI. Для поиска предлагается также использовать отдельный URI, который содержит критерий поиска. В результате выполнения поиска будет возвращается список записей, соответствующий критерию поиска. Если в результате поиска отобрано большое количество записей, тогда есть возможность извлечь только часть записей, путем задания значений соответствующих параметров запроса. Аналогично предлагается отдельный URI для просмотра индекса.
Таблица 2
Ресурсы для работы с OPAC
# Ресурс Идентификатор URI Метод HTTP
1 Запись /api/v 1/catalogue/: id/document/: docid GET
2 Коллекция записей /api/v 1/catalogue/: id/search? {params} GET
3 Коллекция термов /api/v 1/catalogue/: id/scan? {params} GET
9 Высоко нагруженный сервис, к которому количество обращение может достигать 50 и более запросов в секунду.
Рис. 2. Модель приложения OPAC
Такой подход гарантирует, что для каждой записи, которая расположена в индексе, можно поставить в соответствие уникальный URI. В качестве ответа на запрос возвращается JSON-документ, который содержит отдельную запись, коллекцию записей или коллекцию термов. Далее полученные данные могут быть преобразованы с использованием различных стилей для представления на интерфейсе конечного пользователя.
Формат данных JSON. Вопрос представления записей не является простым. Достаточно просто создать представление записи по требованиям ГОСТ 7.1, но, если необходимо автоматически генерировать ссылки на другие связанные документы, или на основе имеющейся записи извлекать новые данные из индекса, тогда требуется применять развитый механизм интерпретации данных.
Для представления данных в современных веб-приложениях широко применяется формат JSON. Такой подход позволяет выполнять различные манипуляции с данными на интерфейсе конечного пользователя. В частности, различные системы HTML-шаблонов позволяют ссылаться на отдельные поля данных в случае если данные в формате JSON, а также автоматически выполнять сериализацию / десериализацию данных для передачи данных.
Применение шаблонов проектирования. Один из подходов организации работы с данными основан на применение шаблонов проектирования модель-представление-контроллер (MVC) [5]. Моделью, в нашем случае, будем считать данные индекса, представление - это возможные варианты дисплейного отображения данных, а контроллер обеспечивает связь между пользователем и приложением. Представление и контроллер зависят от модели, а модель не зависит от них. При таком подходе мы можем менять представление и контроллер, не изменяя модели (рис. 2).
Балансировка нагрузки для интерфейса конечного пользователя. Обработку запроса на стороне веб-сервера необходимо выполнять достаточно быстро. Для высоко нагруженного веб-приложения необходимо заранее позаботиться о возможности применения среды распределенного выполнения задач. Процесс обработки запроса на веб-сервере задействует среду распределенного выполнения задач, которая может включать в себя множество машин. Эта среда позволяет выполнять задачу на одной из свободных, на момент запроса, машин. Основное преимущество этого подхода заключается в том, что REST API в этом случае является сбалансированным. Все вопросы, связанные с очередностью, приоритетами выполнения задач решает сервер очередей. Для синхронизации сессионных параметров между экземплярами веб-серверов следует дополнительно применять сервер кеширования.
Заключение
В работе рассмотрена программная платформа OPAC для облегченного распространения библиографических записей на основе сервис-ориентированного подхода. Основные функции программной платформы доступны для клиентских приложений в виде набора веб-сервисов, которые совместимы с архитектурным стилем REST. Это позволило понизить технологический барьер доступа к реализации функций поиска и извлечения библиографических записей для клиентских приложений. В качестве рабочего примера рассмотрена модель веб-приложения OPAC, которое базируется на основе REST API программной платформы.
В работе также описаны детали подхода к созданию поискового индекса программной платформы. Показано, что с его помощью можно получить новое качество поиска, при условии выполнения ряда требований. Суть требований выражается в обеспечении ссылочной целостности индекса, автоматической актуализации индекса, а также выполнения слияния дублетных записей в индексе.
Предложенную программную платформу OPAC можно рассматривать как SaaS платформу (программное обеспечение как сервис) для организации облегченного процесса распространения библиографических записей. Описанный подход открывает возможности для разработки новых сервисов, связанных с электронным каталогом библиотеки, например, рекомендательных систем.
Список литературы
1. Guidelines for online public access catalogue (OPAC) displays / Ed. by Task Force on Guidelines for OPAC Displays. Series on Bibliographic Contol. Berlin; Munich: De Gruyter Saur, 2005. Vol. 27.
2. Skvortsov V., Zhlobinskaya O., Pashkova A. (2005). UNIMARC XML Slim Schema: living in new environment. In Proceedings of the World Library and Information Congress: 71th IFLA General Conference and Council, "Libraries - A voyage of discovery", August 14th-18th 2005, Oslo, Norway. Retrieved December 13, 2008, from http://www.ifla.org/IV/ifla71/papers/064e-Skvortsov.pdf
3. Fielding R. Architectural Styles and the Design of Network-based Software Architectures: diss. ... for the degree of DPh. Univ. of California. - Irvine, 2000.
4. Князева А. А., Колобов О. С., Турчановский И. Ю. Слияние авторитетных / нормативных данных для распределенного электронного каталога библиотек Ленинградской области // XV Российская конференция с международным участием "Распределенные информацион-
но-вычислительные ресурсы (DICR'2104)": материалы конференции. Новосибирск: ИВТ СО РАН, 2014. URL: http://konf.ict.nsc.ru/dicr2014/reportview/246578.
5. Krasner G. E., Pope S. T. A cookbook for using the model - view controller user interface paradigm in Smalltalk-80 // The JOT (SIGS Publications). 1988.
Материал поступил в редколлегию 01.06.2015
O. S. Kolobov, A. A. Knyazeva, I. Yu. Turchanovsky, N. T. Chuprikova
Institute of High Current Electronics SB RAS 2/3 Academichesky ave, Tomsk, 645055, Russia
Institute of Computational Technologies SB RAS 10/4 Academichesky ave, Tomsk, 645055, Russia
Tomsk Polytechnic University, 30 Lenin ave, Tomsk, 634050, Russia
[email protected], [email protected] [email protected], [email protected]
SOFTWARE PLATFORM OPAC
The elements of the software platform for the distribution of bibliographic records are considered in the paper. The platform can be applied to a broad class of applications for work with bibliographic records. A description of the overall architecture of the software platform, the characteristic of the software interface (API) are given. The OPAC-application, which includes support for single sign-on is considered as a working example of an application. All of the considered elements of a software platform are based on the idea of the use of loose coupling components, modules for building complex software applications.
Keywords: service-oriented architecture, Web services, communication formats, search/retrieve protocols.
References
1. Vol 27: Guidelines for online public access catalogue (OPAC) displays // Ed. by Task Force on Guidelines for OPAC Displays. Серия IFLA Series on Bibliographic Contol. - Ber-lin/Munich:De Gruyter Saur, 2005. - ISBN 10:3-598-24276-X.
2. Skvortsov, V., Zhlobinskaya, O., and Pashkova, A. (2005). UNIMARC XML Slim Schema: living in new environment. In Proceedings of the World Library and Information Congress: 71th IFLA General Conference and Council, "Libraries - A voyage of discovery", August 14th - 18th 2005, Oslo, Norway. Retrieved December 13, 2008, from http://www.ifla.org/IV/ifla71/ pa-pers/064e-Skvortsov.pdf
3. Fielding R. Architectural Styles and the Design of Network-based Software Architectures [Electronic resource] : diss. ... for the degree of DPh / Roy Thomas Fielding ; Univ. of California. -Irvine, 2000.
4. Knyazeva A. A., Kolobov O. S., Turchanovsky I.Yu. Authority/bibliographic data merging for the distributed online catalog of Leningrad district's libraries // XV Russian conference with international participation "The distributed information-computational resources (DICR'2104)". -Novosibirsk, 2014. - http://konf.ict.nsc.ru/dicr2014/reportview/246578 (in Russian).
5. Krasner, Glenn E.; Pope, Stephen T. A cookbook for using the model-view controller user interface paradigm in Smalltalk-80 // The JOT (SIGS Publications). - 1988.
