Научные и технические библиотеки

УДК 025:65.011.56

Козинс Ш.

Виртуальные OPAC и сводные базы данных:
две модели предоставления доступа

От переводчика. Несколько лет назад, просматривая зарубежную периодическую печать, я обнаружила статью – Shirley Cousins. Virtual OPACs Vversus Union Database: Two Models of Union Catalogue Provision. (The Electronic Library. 1999. Vol. 17, № 2 ), которая привлекла мое внимание своей крайней актуальностью как для ВГБИЛ им. М.И. Рудомино, так и для российских библиотек в целом.

К этому времени концепция распределенного сводного каталога стала активно обсуждаться в нашей профессиональной среде. Однако, к сожалению, не появилось ни одной вразумительной статьи, детально бы объяснившей, в чем преимущества и недостатки нового подхода к организации и ведению сводных каталогов. Мне показалось, что статья, написанная сотрудником службы COPAC – cводного каталога, отражающего фонды 11 исследовательских библиотек Великобритании, может быть полезной для всех участвующих и наблюдающих за дискуссией.

Принятая в англоязычной литературе аббревиатура ОРАС (Online Public Access Catalog) соответствует по своему значению стандартизованному у нас термину электронный каталог. Однако в данном переводе сохранена аббревиатура, используемая автором.

Кисловская Г.А.,
зам. генерального директора ВГБИЛ
им. М.И. Рудомино

1. Введение

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

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

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

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

2. Знакомство с COPAC

COPAC – сервис, финансируемый JISC, который поддерживает публичный доступ к слитным онлайновым ресурсам членов Консорциума университетских исследовательских библиотек (CURL). Таким образом, COPAC – важный ресурс, имеющий хорошую репутацию среди пользователей – является сводным каталогом, который с сентября 1998 г. предоставляет доступ к объединенным онлайновым каталогам 11 библиотек – членов CURL: университетских библиотек Кембриджа, Эдинбурга, Глазго, Лидса, Манчестера, Ноттингема, Оксфорда, Лондона, Библиотеки Королевского колледжа науки, техники и медицины, библиотеки колледжа Св.Троицы (Тринити колледж) в Дублине, Библиотеки Университетского колледжа в Лондоне.

Сводная база данных содержит 5 млн записей, представляющих приблизительно 8 млн единиц хранения.

3. Каталог, включающий сведения
из нескольких баз данных

Любой сводный каталог вбирает в себя данные целого ряда разнообразных источников. COPAC постепенно будет инкорпорировать записи из 22 исследовательских библиотек.

В 1995–1996 гг., когда COPAC начинал свою деятельность, рассматривался вопрос об использовании протокола Z39.50 для предоставления доступа к виртуальному каталогу конечному пользователю, но на то время библиотеки-участницы не обладали необходимыми технологиями. Эта ситуация изменилась в нескольких библиотеках, но не во всех, и вероятно, пройдет какое-то время, прежде чем виртуальный сводный каталог будет в состоянии предоставить доступ к разнообразным данным, ныне содержащимся в COPAC.

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

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

3.1. Обновление данных

Сводный каталог – не статичная база данных. После того, как все существующие каталоги отдельных библиотек загружены в COPAC, обновленные файлы предоставляются библиотеками с разными интервалами, обычно еженедельно. Таким образом, увеличивая объем базы данных, COPAC всегда будет отставать в плане актуальности от индивидуальных библиотечных каталогов на одну-две недели. Это как раз то, в чем виртуальный каталог имеет преимущество. Поиск в каждом отдельно взятом каталоге всегда будет проходить в самой актуализированной БД. Но при этом не стоит забывать, что не все каталоги доступны сегодня через протокол Z39.50.

3.2. Редактирование и контроль качества

Большинство сводных каталогов предполагает наличие определенного уровня качества. Поэтому все входящие в COPAC записи проверяются на присутствие существенных ошибок, явно некорректные записи возвращаются в библиотеки, а некоторые менее значимые ошибки исправляются. К наиболее типичным ошибкам относятся грамматические ошибки в записях, ошибки в присвоении кодов полей, отсутствие полей.

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

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

3.3. Устранение дублетных записей

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

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

3.3.1. Способы обработки дублетов в COPAC

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

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

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

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

Во многих случаях конечным результатом процесса консолидирования является более полная запись, чем та, которая была представлена большинством, если не всеми библиотеками. Это дает возможность улучшить доступ к консолидированным записям, а также повысить ценность записи для релевантности результатов поиска (making relevance judgements). Естественно, весь процесс должен находиться под постоянным контролем, чтобы можно было идентифицировать проблемы и содействовать привнесению изменений в каталогизационную практику библиотек-участниц.

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

Одной из характеристик процесса устранения дублетов, которая особенно часто критикуется, является его недостаточная скорость. Клиффорд Линч приводит цифру 1–2 тыс. записей в час за одну сессию загрузки в режиме oфлайн в БД MELVIL, отмечая, что ограничителем скорости загрузки является процесс устранения дублетов. При загрузке данных в COPAC была зафиксирована скорость 2–4 тыс. записей в час. Качество консолидации, свойственное многим сводным каталогам, достигается за счет существенной стоимости процедуры офлайновой обработки.

3.3.2. Устранение дублетов в виртуальном каталоге

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

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

Другие "простые" способы сверки на дублетность следует также использовать с известной долей осторожности, поскольку многие записи имеют очень незначительные отличия. Упрощение может легко закончиться как слиянием записей, которые не являются настоящими дублетами, что приведет к потере некоторых материалов, так и сохранением большого числа дублетных записей.

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

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

3.4. Локальные данные

Наличие локальных данных (Local Date) – сведений об экземпляре – важно как для конечного пользователя, так и для библиотечного персонала.

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

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

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

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

Эта проблемная область в настоящее время находится в поле зрения заинтересованных сторон. Некоторое время даже обсуждались перспективы развития протокола Z39.50. В частности, было сделано предложение от NISO по развитию "Протокола взаимодействия в области книговыдачи".

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

4. Поиск по каталогу

4.1. Общие проблемы поиска по каталогу

Одной из важных базовых проблем, возникающих при поиске в БД через протокол Z39.50, является последовательность поиска между разными библиотечными системами.

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

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

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

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

Эти разработки нельзя легко применить по отношению к поиску в виртуальном сводном каталоге. Таким образом, улучшенный поисковый сервис, доступный местному пользователю, будет потерян. Та же озабоченность, а именно потенциальная потеря специальных поисковых характеристик была высказана в исследовании Корнельского университета. Следовательно, это проблема, о которой пользователи знают.

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

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

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

4.2. Другие аспекты поиска

При обсуждении виртуальных сводных каталогов стало нормой, что используется протокол Z39.50, и именно поэтому на нем концентрируются все дискуссии. Однако следует подчеркнуть, что Z39.50 позволяет взаимодействовать клиенту с сервером. Действительно, используя Z39.50, возможно создать виртуальный сводный каталог, позволяющий провести скрытое взаимодействие клиента со многими серверами, которое затем проявляется для пользователя в виде единого поискового результата. Тем не менее каждое из этих взаимодействий – единичное взаимодействие клиента и сервера. Z39.50 не создан для поиска в нескольких БД. Соответственно, многие из вопросов, которые следует решить при создании виртуального сводного каталога, в настоящее время находятся вне сферы действия стандарта, а потому и нет прямой поддержки. Например:

Просмотровые списки. Z39.50 предоставляет функцию Scan, которая позволяет пользователю просматривать список (перечень) и делать из него выборку. Но стандарт не дает никаких инструкций относительно того, как работать перечнем, поступающим не из одного источника, а из нескольких; как просмотровый список можно представить пользователю в том случае, если каждая из 10 разных библиотечных систем составляет отдельный перечень. К тому же не все библиотеки могут поддерживать функцию Scan, а там, где она поддерживается, информация, включенная в список (Index), может варьироваться.

Сортировка и ранжирование по степени релевантности. Еще одной характеристикой поиска в нескольких БД является то, что существует потребность производить ранжированные списки записей (в Корнельском исследовании пользователи отнесли это к важным обстоятельствам).

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

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

Еще более очевидным является вопрос о результатах сортировки, он также требует внимания. На каком этапе группа записей должна подвергаться сортировке? Должны ли все записи отправляться пользователю из нескольких различных источников или сортировка производится клиентом? Это обстоятельство может существенно влиять на время выполнения запроса, когда высок сетевой трафик. Или следует положиться на индивидуальные процедуры сортировки, выполняемые серверами? Различные механизмы сортировки могут сработать совсем по-разному и в результате дать пользователю списки, отсортированные внутри, а не между библиотеками.

Требуется исследование вопросов, относящихся к поиску внутри нескольких БД, чтобы найти эффективные способы ответа на ожидания пользователя. С нашей стороны будет шагом назад, если мы предоставим пользователям доступ к нескольким БД и наряду с этим менее надежные или /и более ограниченные поисковые и презентационные возможности чем те, которые в настоящее время внедрены в библиотечных системах.

Это не только вопрос, который относится к системам, использующим Z39.50. Поиск между множественными системами можно производить, используя и другие механизмы, такие, как http, что подтверждается опытом виртуального каталога Карлсруэ. Все вышесказанное относится к разряду общих проблем, возникающих при развитии новой модели: один клиент – много серверов, которая еще потребует много времени и усилий.

5. Вопросы управления

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

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

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

5.1. Сетевое взаимодействие

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

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

5.2. Загрузка поиска

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

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

Такие альтернативы, как разрешение пользователю выбирать каталоги для проведения поиска или использование метаданных для перенаправления пользователей в соответствующие каталоги, вероятнее всего, могут помочь снизить нагрузку до некоторой степени. Но тем не менее такое нововведение в виртуальном каталоге Карлсруэ, как chech-boxes, позволяющее пользователю выбрать те библиотеки, в каталогах которых они хотят поискать, несущественно повлияло на использование COPAC из этого источника.

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

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

Доступность каталогов также является проблемой. Там, где доступно большое количество индивидуальных каталогов, вполне вероятно, что хотя бы один из них может быть недоступен по какой-то причине: сбоя в поддержке системы, проблем в локальной системе, в связи с перегрузкой сети или по другим причинам. Надежда на время прекращения обработки запроса по timeout как на средство, определяющее доступность каталога, может закончиться ничем, поэтому требуются другие механизмы для проверки доступности каталога еще до того, как последует отправка запроса.

6. Объединение сильных сторон

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

Сотрудники COPAC вовлечены в разработки, связанные с Z39.50. В COPAC есть Z-сервер, разработка которого выявила проблему стандарта записи. В настоящее время по соображениям авторского права COPAC не предоставляет доступа к любым марковским записям, а предоставляет клиенту записи в SURTS (Simple Unstructured Text Record Syntax) или в формате GRS1 (Generic Record Syntax). Однако некоторые Z-клиенты в настоящее время принимают записи только в MARC-формате. В этом очевидная трудность как с точки зрения авторского права, так и с точки зрения необходимости конвертирования записей на лету между различными MARC-форматами.

Для COPAC разработан шлюз Web/Z39.50, который заменил оригинальный веб– и текстовый интерфейсы и предоставляет одинаковые возможности для всех пользователей, независимо от того, получают они доступ к COPAC, используя веб-браузеры или телнет. Эта разработка позволяет предоставлять одновременный доступ к другим каталогам, например к каталогу Британской библиотеки. В этом есть огромный потенциал, но и в то же время COPAC ввергается в пучину тех проблем, о которых сказано выше.

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

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

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

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

Этот подход поддержан результатами недавнего исследования, проведенного для изучения возможностей приложения Z-технологий для COPAC и профинансированного JISC. Одним из самых главных выводов исследования является следующее соображение: на современном уровне развития представляется целесообразным сохранить архитектуру COPAC как физического сводного каталога, но сделать так, чтобы он стал шлюзом для других важнейших источников, таких, как Британская библиотека.

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

Возможно и то, что некоторые различия останутся неразрешимыми. Так, пользователь будет просматривать ранжированные записи библиотека за библиотекой, а не в виде единого списка. Но сделать это будет проще, когда в процесс поиска вовлечено всего 3 каталога, а не 30.

Z39.50 играет огромную роль в развитии каталогов, как в области предоставления доступа к отдельным каталогам, так и в области развития виртуальных каталогов. Тем не менее существующие сегодня проблемы делают желательным поддержку физически слитных сводных каталогов. К аналогичным выводам приходят и другие исследователи. Например, НБ Австралии сохраняет физически слитный сводный каталог, несмотря на шаги, предпринимаемые Сетевой службой Кинетика (Networked Service Kinetica) и проектом LIDDA. Сводный каталог является центральным звеном в инфраструктуре взаимоиспользования ресурсов и альтернативный виртуальный подход не рассматривается в качестве убедительного для поддержки библиотечного сервиса.

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