Формат RUSMARC в автоматизированных библиотечных системах.

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

В 2002 г. Американской национальной организацией стандартов опубликован документ «Руководство для составителей запроса предложений применительно к стандартам для библиотечных систем». Руководство предназначено, прежде всего, не для разработчиков систем, а для заказчиков – библиотек: в нем, по сути, фиксируются условия задачи со стороны заказчика, которые придется решать разработчику библиотечной системы, и, в частности, требования, которым должна удовлетворять система с точки зрения поддержки библиотечных и коммуникационных стандартов. В соответствии с Руководством, проектное задание на разработку АБИС должно включать следующие общие положения: - система должна кодировать БЗ в MARC-формате без ограничения длины записи (кроме ограничений, определяемых форматом);

- система должна обеспечивать импорт и экспорт БЗ в формате без дополнительного вмешательства разработчика, с полным сохранением определителей содержания (меток полей, индикаторов, идентификаторов подполей) и сохранением порядка полей в записи; - система должна обеспечивать вывод БЗ с определителями содержания на рабочие станции пользователей.

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

I. Общие требования:

1. Отсутствие ограничений на длину записи, полей, подполей 2. Поддержка всех существующих и ранее использовавшихся меток полей, идентификаторов подполей, индикаторов, разделителей, определенных в формате 3. Поддержка повторяющихся полей и подполей в соответствии с форматом 4. Поддержка техники встроенных полей 5. Реализация связей между записями

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

8. Проверка правильности записи при вводе и редактировании, с генерацией соответствующих сообщений об ошибках

9. Наличие справочников контролируемых данных (прежде всего, кодированных) и контроль их использования в записях

10. Возможность работы с неполными записями (например, на этапе заказа)

11. Возможность внесения изменений в системе в случае изменений формата

II. Поиск.Для обеспечения поиска в массиве MARC-записей система должна обеспечивать:

1. Возможность индексирования до уровня подполей и индикаторов (с выбором полей и подполей для индексирования)

2. Возможность индексирования КС

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

III. Импорт и экспорт записей.Возможность импорта и экспорта корректных MARC-записей является обязательным условием, без которого невозможно говорить об эффективной работе в корпоративной среде.

1. Импорт и экспорт записей в MARC-формате должен осуществляться без дополнительного вмешательства разработчика с сохранением всех определителей содержания.

2. Экспорт записей должен осуществляться в соответствии со стандартом ISO 2709

3. Должна быть предусмотрена возможность использования локальных полей (полей блока 9--), которые определяются соглашениями между участниками обмена

4. Необходим контроль дублетов при импорте.

5. Должна допускаться возможность импорта неполных или кратких записей

6. Если RUSMARC является только коммуникативным форматом – необходимо корректное преобразование записи из внутреннего формата в RUSMARC (при импорте) и обратно (при экспорте)

7. Возможность работы с авторитетными файлами, в том числе – национальными

8. Контроль правильности записи.

Создание и основные направления развития компьютерной сети Либнет

Основные периоды развития центра Либнет