Руджеро Гиляревский - Развитие принципов книгоописания

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

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

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

Библиотека Конгресса начала эти работы в 1961 г., к 1966 г. был разработан первый вариант формата MARC (Machine-Readable Cataloging), а в 1990-е гг. их число превысило 50. Понадобилось создание формата для международного обмена библиографическими данными UNIMARC, который стал моделью для разработки некоторых национальных форматов. Только на территории бывшего СССР имеют хождение несколько вариантов этого формата: RUSMARC, UNIMARC-BAN, BELMARC, UKRMARC. В конце прошлого века тенденция к унификации хотя бы этого семейства форматов привела к созданию на базе USMARC и CAN MARC формата MARC21 , который широко используется во многих странах и как внутренний, и как обменный формат.

Для иллюстрации избыточности форматов, хочу привести пример полей данных из Российского формата машиночитаемой каталогизации (RUSMARC) {257} . В его 10 блоках содержится 113 полей, большинство которых при обработке потока поступающих в библиотеку книг не имеет наполнения. Самый большой Блок связи записей (30 полей) предназначен для относительно редко встречающихся в обыденной практике приложений, продолжений, замен, конволютов, переводов, перепечаток и т.п.

Один из самых крупных в мире распространителей библиографических описаний в электронной форме — Онлайновый компьютерный библиотечный центр (с 1981 г. OCLC — Online Computer Library Center ), развившийся из американского регионального учреждения централизованной каталогизации {258} предложил эффективный способ решения этой задачи, получивший название Дублинского ядра (Dublin Core). В нем использована для электронной формы старая библиотечная идея каталогизации в источнике, которая в свое время широко обсуждалась в международных кругах {259} и до сих пор используется на практике, в том числе и у нас. Нужно заметить, что в виде публикации каталогизационного описания, помещаемого издательством на обороте титульного листа книги, эта идея воплощается с большими отклонениями от правил. Курьезно, что ошибки встречаются даже в учебниках по каталогизации. При этом издательства иногда включают в описание сведения, нигде в самой книге не встречающиеся {260} .

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

_Создатель_ (Creator). Лицо, несущее первичную ответственность за создание содержания ресурса. Примеры Создателя включают лицо, организацию или службу. Обычно имя Создателя используется для индикации объекта.

_Предмет и ключевые слова_ (Subject). Тема содержания ресурса. Обычно Предмет выражается с помощью ключевых слов, ключевых фраз или классификационных индексов, которые описывают тему ресурса. Для практического использования рекомендуется выбирать значение из контролируемого словаря или официальной классификационной схемы.

_Описание_ (Description). Сообщение о содержании ресурса. Описание может быть представлено (по необходимости) в виде: реферата, оглавления, ссылки на графическое представление содержания или простого текстового изложения содержания.

_Издатель_ (Publisher). Лицо, ответственное за ввод ресурса в обращение. Примеры Издателя включают лицо, организацию или службу. Обычно имя Издателя используется для индикации объекта.

_Соисполнитель_ (Contributor). Лицо, внесшее вклад в создание содержания ресурса. Примеры Соисполнителя включают лицо, организацию или службу. Обычно имя Соисполнителя используется для индикации объекта.

_Дата_ (Date). Дата, связанная с событием в жизненном цикле ресурса. Обычно Дата ассоциируется с созданием или доступностью ресурса. На практике рекомендуется для кодировки значения даты использовать определение профиля ISO 8601 (Форматы даты ГГГГ-ММ-ДД).

_Тип ресурса_ (Туре). Природа или жанр содержания ресурса. Тип включает термины, описывающие общие категории, функции, жанры или объединенные уровни содержания. Для практического использования рекомендуется выбирать значение из контролируемого словаря (например, рабочего проекта списка типов Dublin Core ). Для описания физического или цифрового представления ресурса используется элемент Формат.