Современная архитектура систем учёта фольклорно-этнографических материалов
Мой доклад на конгрессе фольклористов 2022
Небольшое предварительное уточнение по терминологии:
База данных (БД) — это упорядоченное хранение информационных ресурсов в виде объединённых структурированных данных, обеспечивающих быстрый доступ и удобное рациональное взаимодействие между данными.
Банк данных (БнД) — это автоматизированная система, обеспечивающая хранение, накопление, поиск и выдачу информации в совокупности программных и технических средств.
База данных это составная часть банка данных и отвечает за хранение текстовой и служебной информации. Один банк данных может использовать несколько баз данных.
Введение
За последние пятнадцать лет IT мир сделал существенный рывок вперед. Для рядовых пользователей это выражается в том, что у нас появились смартфоны по мощности превосходящие самые продвинутые компьютеры рубежа веков, появились социальные сети, видео хостинги, облачные хранилища и мессенджеры. Менее заметны изменения произошедшие в сфере разработки и управления данными. Но, важно отметить, что вместе с возросшими мощностями произошла и своего рода революция в сфере разработки приложений, все это напрямую касается и таких небольших разработок как банк данных экспедиционных материалов для одного конкретного учреждения.
О программировании
Пятнадцать — двадцать лет назад, при заказе разработки у программиста или у специализирующейся фирмы программного обеспечения его разработка велась практически с нуля. Это значит, что вся логика и структура и в первую очередь весь код писался от начала и до конца. Для типовых задач программисты использовали свои наработки, и они оставались их интеллектуальной собственностью. Конечный продукт при этом был уникален и чем более он был сложным и объемным, тем сильнее была зависимость заказчика от разработчика в плане дальнейшей поддержки и модернизации. Часто при потере контакта с разработчиком приходилось переписывать приложение заново просто потому, что, из-за недобросовестного документирования и объема кода новому разработчику было проще создать что-то новое используя свои привычные наработки. Такая ситуация была повсеместна, то есть это не касалось только банков данных фольклорно этнографических материалов.
Современный подход в программировании выразился в первую очередь в создании множества свободных к распространению фреймворков. Фреймворк — ядро или каркас приложения с поддержкой разнообразных протоколов и функций. При использовании фреймфорка код пишется по определенным правилам и соглашениям, что существенно облегчает его чтение. По сути фреймворки, это тот самый велосипед, который теперь не надо каждый раз заново изобретать программисту. Существенно сократилось время общей разработки и для новых программистов в штате существенно снизилось время на освоение проектных знаний. То есть снизилось время на изучение кода проекта и освоение его специфики, что в итоге делает заказчика более свободным от конкретного программиста.
Так же, развитие сетевых и облачных решений показало то, что однопользовательские банки данных на сегодня морально устарели. Уже в 2011 году на конференции “Мультимедийные и цифровые технологии в собирании, сохранении и изучении фольклора” большинство представленных в докладах решений были созданы с применением сетевых технологий и рассчитаны на доступ из локальной сети или интернет обеспечивающих одновременный доступ к данным многим пользователям с разным уровнем прав в системе.
Подход к разработке
Базовые принципы разработки, это определение конечных задач, которые должен решать разрабатываемый продукт с учетом дальнейшего развития отрасли в целом. И в этом смысле, к сожалению, большинство решений с которыми мне удалось ознакомиться лично, либо по материалам вышеупомянутой конференции созданы исходя только из внутренних потребностей организаций и не предполагают какой-либо внешней коммуникации. Практически отсутствуют системы позволяющие обмениваться данными между собой и если организация принимает решение делиться с обществом какой-то частью информации, то как правило для этого создается отдельный вебсайт, и система внутреннего учета никак с ним технически не связана. Описания и материалы выкладываются на него отдельно без какой-либо автоматизации процесса, что в свою очередь замедляет процесс публикации. Необходимость же в публикациях есть.
Единый архив
Уже не первый год в фольклорном сообществе звучит идея о едином открытом архиве, но для людей, более-менее углубленных в специфику и знающих современное состояние дел такие заявления в первую очередь ассоциируются с простой мыслью героя произведения Булгакова «Собачье сердце» Шарикова, который предлагал профессору Преображенскому «Всё взять и поделить». Запуск процесса передачи всех материалов в какой-либо единый центр может породить множество критических проблем. Минуя вопросы о финансировании, выделении помещений, аппаратуры и штата квалифицированных сотрудников возникает проблема качества описаний материалов, сведения их к одному формату. Даже при условии передачи в единый архив только оцифрованных данных, без владельцев архивов их опыта и знания своего архива, описания будут содержать множество ошибок в силу того, что специфику своего материала знают только владельцы. На работников единого архива и тех, кто передал в него свои материалы, помимо их повседневных задач ляжет необходимость согласования своих описаний с единым архивом. Разноплановость и разнородность коллекций, добавит еще больше проблем. Помимо этого, есть еще и юридическая сторона дела, где все тоже обстоит не так просто. Достаточно сказать, что в подавляющем большинстве пабликов в социальных сетях при размещении экспедиционных записей есть устойчивая традиция не упоминать автора записи и источник, что является прямым нарушением авторских прав собирателя. Собиратели не торопятся отдавать свои материалы на хранение в силу того, что их авторские права попросту нигде не заявлены и не задокументированы.
Тем не менее, проблема есть, и она требует решения. Доступность информации как минимум об имеющихся коллекциях фольклорно этнографических материалов необходима не только любителям фольклористами, фольклорным ансамблям и родственникам информантов, но, в первую очередь ученым. На сегодняшний день сведения о количестве и качестве всех экспедиционных материалов во всех собраниях и коллекциях на территории Российской Федерации носят чаще мифический характер. Это затрудняет научный процесс, ограничивая исследователей рамками уже имеющихся публикаций и собственными материалами и в итоге влияет на качество научных публикаций. В Центре русского фольклора ГРДНТ им. Поленова ведется работа по пополнению реестра фольклорно-этнографических экспедиций. На сайте центра на карте Российской Федерации можно посмотреть обследованные области, районы и населенные пункты, даты экспедиций, руководителя экспедиции и номера реестров. Пользуясь случаем, призываю всех держателей архивов делиться информацией для пополнения реестра.
Распределенная сеть
Говоря о разработке приложений, в перспективе видится идеальным создание распределенной сети Банков данных фольклорно этнографических материалов с возможностью автоматического и полуавтоматического обмена данными между ними и выборочной публикацией в автоматическом режиме в интернет готовых описаний и данных.
Уточню, что для построения таких распределенных систем при проектировании своего приложения заказчик должен учитывать возможность импорта и экспорта данных по единому стандарту. Функционал и внутренняя логика при этом остаются на усмотрение организации заказчика.
Обобщенно архитектура современных систем выглядит так: есть административная часть банка данных (backend), в которой ведется работа по добавлению и описанию материалов. Внешняя часть приложения (frontend), то, что видит пользователь. Эта схема многим знакома, так сегодня устроены практически все популярные систему управления контентом наподобие Wordpress и Joomla. Современный подход разделяет frontend и backend в две независимые сущности, это сделано, например для того, чтобы одна административная часть обслуживала несколько фронтендов — сайт, приложение в телефоне, бот в мессенджере и так далее. Так же есть и обратная возможность, когда один сайт обслуживается несколькими разными бэкендами. Бэкенды так же в свою очередь могут обмениваться между собой информацией. Каждый узел такой сети обменивается с другими по определенным протоколам, протоколы универсальны и это обеспечивает в свою очередь свободу выбора того программного обеспечения, которое будет использоваться на каждом отдельно взятом узле такой сети.
По этому принципу работают все распределенные современные системы. Начиная от банков и туроператоров, заканчивая театрами и автомобильными заправочными станциями.
Таким образом, разработка банков данных фольклорно этнографических материалов, которая ведется уже на базе современного подхода дает возможность, публикации подготовленных материалов на своих ресурсах и делает первый шаг на пути создания агрегаторов различного уровня, что в перспективе существенно облегчит поиск необходимой информации, передачу данных на резервное хранение и будет являться по сути тем самым шагом к единому открытому архиву, где каждый владелец материалов, тем не менее, по-прежнему распоряжается своими материалами, работает с ними и управляет условиями доступа к ним. Технически, агрегатор описаний является относительно простой и недорогой системой, при условии агрегации только текстовых описаний.
Единый стандарт
Рано или поздно, любая отрасль проходит к моменту, когда необходимо вырабатывать единые стандарты и общие соглашения. В этом плане подход к разработке Банка данных для фольклорно этнографических записей является насущным примером этой необходимости. Ниже я приведу некоторые соображения, которые касаются именно этномузыкологических экспедиций, допускаю, что при детальном рассмотрении материалов, записанных филологами или этнографами, могут выявиться существенные отличия, которые потребуют выработки других соглашений или корректировки предлагаемых мной.
Критическим для проектирования распределенной системы является общее соглашение о количестве и типе полей минимального описания объекта учета.
Например, минимальный набор может состоять из полей: страна, субъект, район или округ, населенный пункт, именование единицы записи, информатор, собиратель, регистрационный номер, дата, тип материала.
Для корректного импорта в единую систему необходимо общее соглашение в части именований стран, субъектов, районов, населенных пунктов и других общих для разных коллекций полей. Например, ФИО руководителя экспедиции. «Иван Иваныч Иванов» не равно «Иванов Иван Иваныч», а «станица Алексеевская» не равно «Алексеевская станица» Единый формат даты и именования типа материала. Какие-то поля практически невозможно сделать общими — например ФИО информанта в описаниях часто фиксируется как фамилия и сокращение имени отчества, в других отсутствует отчество уточнение этих данный иногда просто невозможно.
Несмотря на кажущуюся простоту описания, есть некоторые проблемы, связанные с содержанием полей паспорта единицы хранения.
Примером может быть типичное поле “место записи”. С одним этим полем существует несколько сложностей:
1) Переименование населенного пункта — в описании указывается название не на момент записи.
2) Смена района или области, страны — В описании указывается название не на момент записи.
3) Запись исполнителей вне их места проживания (фестиваль, запись на тв и прочее) — указывается место записи, а не бытования традиции. И в банке данных по запросу Московская область вдруг оказывается ансамбль из Афанасьевки.
Это не единственные разногласия в этой части. Есть проблема указания названий песни —по первой строчке, по общепринятому названию или по версии информанта. Именование жанра, принцип формирования реестрового номера единицы хранения. Но, все эти вопросы находятся вне сферы проблемы выработки единого формата и могут быть оставлены на усмотрение организации, хотя по-прежнему нуждаются в проработке научным сообществом и принятии общих соглашений.
Минимальное описание не ограничивает организацию при создании в своем банке данных дополнительных полей для удобства работы.
Коммуникация между любыми программами осуществляется с помощью протокола передачи данных. Это понятие имеет весьма широкую трактовку, но применительно к нашей задаче суть сводится к выбору формата импорта и экспорта данных. Таковых форматов в IT индустрии сегодня много. Из популярных можно выделить YAML, JSON, XML. Важным с технической точки зрения здесь является соглашение об очередности полей при выгрузке в выбранный формат экспорта. Внутри банка данных организации очередность полей остается так же на усмотрение заказчика.
Существующие аналоги
К сожалению, среди существующих государственных архивов на территории РФ не существует единой системы поиска документов доступной рядовым пользователям. Те кто занимался когда нибудь генеалогическими исследованиями с этим хорошо знакомы. Работа по оцифровке и представлению данных населению тем не менее ведется, региональные архивы публикуют на своих сайтах номера дел и их краткие описания. В силу большого количества типов архивных документов это делается в каждом отдельном архиве с разной степенью полноты детализации и разными способами. Вспоминая вчерашний доклад на пленарном заседании Александра Васильевича Черных, можно утверждать, что уже есть успешный опыт передачи фольклорных коллекций в муниципальные или городские архивы. Это может быть хорошим решением, особенно если сотрудники архива участвуют в его оцифровке и систематизации. Такой путь позволяет декларировать права на экспедиционные записи собирателя и организации, и при необходимости подтверждать их документально.
Если же рассматривать ближайшие аналоги среди существующих распределенных систем, которые наиболее схожи по своей структуре и задачам, то в первую очередь стоит обратить внимание на то, как организован электронный обмен в библиотечном деле. В отличие от архивов, крупные библиотеки всего мира могут обмениваться данными. И уже давно, существуют агрегаторы разной степени охвата и системы единого поиска. Многим известен специальный поиск книг https://books.google.com в электронном формате, но возможно не все знают о том, что, есть и единая система поиска книг по библиотекам мира https://worldcat.org созданный OCLC Online Computer Library Center именно ее записи индексируются поисковым сервисом google. OCLC — некоммерческий членский компьютерный библиотечный сервис и научно-исследовательская организация. Более 74 000 библиотек в 170 странах и территориях используют услуги OCLC для поиска, приобретения, каталогизации, заимствования и сохранение библиотечных материалов.
Библиотечные системы используют для обмена формат машиночитаемой каталогизации MARC, Mаchine Readable Cataloging) Библиотеки самостоятельно загружают в систему worldcat.org описания в формате MARC. Решение о том, какую информацию предоставлять принимают сами библиотеки. По заявлению OCLC примерно 20% каталога занимают данные из Российской Государственной Библиотеки. Сами библиотеки сегодня оснащены большим и разнообразным парком программного обеспечения для каталогизации, но главная их особенность в том, что все они используют формат MARC.
Примером может служить распространенная в российских библиотеках платная система «Ирбис» или бесплатная Koha.
К слову, история формата очень давняя впервые он был разработан в 1960х годах в Библиотеке конгресса США. С тех пор формат претерпевал множество изменений, появились национальные форматы MARC в том числе и российский RUSMARC.
Несмотря на то, что формат MARC создавался для описания книг, его возможности давно вышли за эти рамки. На сегодня он способен описывать достаточно большое количество данных, в том числе и все типы материалов, которые хранятся в фольклорно-этнографических коллекция. В Центре русского фольклора уже проводился эксперимент по использованию программного обеспечения Научной библиотеки Московского гуманитарного университета имени Михаила Васильевича Ломоносова.
Таким образом можно утверждать, что использование автоматических библиотечных систем для описания фольклорно этнографических материалов возможно, с тем условием, что их использование ограничено только каталогизацией и поиском описания, некоторые библиотечные системы могут предоставлять полнотекстовые электронные документы. Многие позволяют публиковать в сети часть описаний. Работать со звуком и видео они не умеют, поэтому тема создания своих собственных программ для фольклористов по-прежнему актуальна.
Заключение
В качестве отступления хочу сказать, что на сегодняшний день, фольклорно этнографических архивов, которые были бы полностью юридически легализованы, ничтожно мало. Даже при наличии в организации соответствующего подразделения, сами материалы экспедиций не стоят на балансе. На балансе могут числиться носители, но не информация, записанная на них. Библиотечный ГОСТ от 2018 года подразумевает наличие аналогово носителя и цифровой копии и позволяет ставить содержимое на баланс предприятия, присваивать инвентарный номер и прописывает процедуры доступа пользования материалами и соответствующие права. Что в свою очередь тоже позволяет подтверждать при необходимости права собирателя документально.
Не секрет, что большая часть фольклорных коллекций не имеет вообще никакого программного обеспечения. Описи хранятся в exel и word файлах. Здесь нужно отметить, что при соблюдении выработанных соглашений и строгом соблюдении формата описания в каждом файле экспорт таких данных достаточно легко делается при помощи небольших скриптов, написанных практически на любом из современных популярных интерпретируемых языков программирования. Такие скрипты не требуют высокой квалификации программиста и в целом, это не является большим препятствием для подготовки выгрузки описаний в каком-либо формате и не обязывает организацию к внедрению у себя программных комплексов учета для участия в единой сети.
Независимо от выбора способа учета и хранения материалов, будь то библиотека или государственный архив или частная коллекция, выработка единых соглашений на сегодня является первоочередным шагом к внедрению современных технологий в сфере сохранения нематериального культурного наследия.