— «Эйдотека» была задумана как система учёта фотографий в РОСФОТО и хранения их цифровых копий. Постепенно она развилась в систему хранения всех данных музея, в том числе мультимедийных материалов.

Прежде всего, в «Эйдотеке» хранятся данные, относящиеся к музейному фонду и вспомогательному научному фонду: изображения, видео и их описания. Среди них есть как цифровые копии физических единиц хранения (сканы и фото), так и непосредственно цифровые объекты.

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

Можно просмотреть информацию о том, кто из сотрудников какой проект готовил, какие были варианты экспозиции, как экспозиция выглядела в итоге в стенах музея. Все эти связные и структурированные данные собираются вокруг объектов. Таким образом, «Эйдотека» отражает не только объекты коллекции, но и жизнь этой коллекции.

В РОСФОТО есть такая практика: когда заканчивается проект, всё, что от него осталось, фиксируется и сохраняется. В случае с выставкой фотографируются все стенды, все комнаты, и они связываются с данными о представленных фотографиях. Так, кликнув на фотографию, мы попадаем на материалы, которые появились в процессе работы над выставкой, и видим финальный архив, который позволяет эту выставку пересобрать позже. Американский музей МoМА делал такой проект: по архивным фотографиям реконструировал свои выставки — где что висело, с какими описаниями, как выглядели экспонаты вместе.

Часто система выступает своего рода бэкендом для проекта — если речь о выставке с мультимедийными элементами. Например, в РОСФОТО был проект, где использовалось много разных мультимедийных решений, в том числе трёхэкранная система, которая имитировала окно и большой деревянный фотоаппарат, направленный в это окно.

Была настройка с картой, по которой можно было перемещаться и смотреть виды: много фотографий начала века снимали с натуры, и, поскольку город плоский, можно было переноситься в разные точки съёмки и видеть, как вид превращался в фотографию — как будто смотришь в окно. Добавлялся звук, менялась картинка; в сам «фотоаппарат» был встроен экран, чтобы показать, как фотограф видел изображение на матовом стекле, и так далее.

Все эти данные тоже хранились в «Эйдотеке» — причём не просто хранились, а сам инсталляционный объект обращался к библиотеке напрямую. Для экспонирования фотографию нужно оцифровать и разрезать на три или девять частей. Система управления мультимедийной выставкой сперва обращается к «Эйдотеке», забирает данные оттуда, а потом возвращает уже обработанные файлы. Все версии остаются в системе, прикреплённые к исходным объектам.

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

— Допустим, у нас есть один объект из музейного фонда, скажем, оцифрованная фотография — это не один файл, а сразу несколько. Как минимум, мы стараемся хранить RAW-файл (исходное изображение с камеры) и мастер-TIFF, обработка которого приближена к оригиналу.

Также будет набор данных в базе, описывающих объект — с точки зрения хранителей и с точки зрения выставочного отдела (это немного разные вещи). Но сама структура довольно гибкая: можно хранить минимальную информацию, а можно добавлять больше. Например, есть поле координат на карте — мы далеко не всегда знаем, где именно был сделан снимок, и не всегда это нужно. Иногда данные о локации есть — но часто на уровне «Россия» или «Санкт-Петербург, Россия». В отдельных случаях координаты известны точнее — вплоть до конкретной локации, и тогда для такого объекта можно указать широту и долготу с высокой точностью.

Самое интересное, что можно описывать не только сами фотографии, но и то, что на фотографиях изображено. Например, визуально — «объект A находится на объекте B»: когда на снимке выставки видна другая фотография на стене, или когда на фотографии изображено конкретное место или человек.

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

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

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

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

В ходе работы с «Эйдотекой» мы тоже сталкивались с дубликатами и необходимостью унифицировать некоторые данные. Тут уже другой вопрос: о каком объёме данных идёт речь, сколько ресурсов потребуется, чтобы навести порядок.

— Да, конечно. Идея в том, чтобы система была достаточно адаптивной. Любая такая система отражает взаимоотношения внутри организации и её бизнес-логику. Тем более что появляются новые возможности, и их тоже нужно как-то использовать. Мультимедиа постоянно развиваются.

Меняются и пользователи: сначала пользователями были только хранители, потом — кураторы, потом исследователи, теперь ещё и реставраторы. Поэтому лучше периодически прислушиваться к их запросам. При этом не всегда то, что хотят люди, практично: иногда это может привести к большим проблемам.

— В «Эйдотеке» хранится вся история изменений, которые вносит каждый конкретный пользователь. Это важно для данных музейного фонда — мы по закону обязаны собирать и хранить эту информацию.

— Все данные хранятся локально. Одна из основных проблем с хранением данных, это сделать так, чтобы их можно было прочитать спустя 20−30−50 лет. Почему в случае с фото это особенно важно? Сами по себе бумажные фотографии хранятся не очень долго: сто-двести лет, некоторые даже меньше. Все они выцветают со временем.

Скажем, через 30 лет часть фотографий в фонде РОСФОТО, как бы хорошо их ни хранили, потеряют контраст на 80%. А изображение, которое мы оцифровали, сохранит. Со временем у нас будут такие объекты фонда, оригиналы фотографий, на которых изображения будут едва различимы. И в то же время будут их цифровые копии. А если мы говорим об изначально цифровых объектах, то они вообще не отсылают ни к какой материальной форме, кроме сервера, на котором они хранятся.

Даже если мы сможем сохранить файлы изображений, то программы, которые их воспроизводят, уже будут явно другими. Поэтому мы должны хранить данные так, чтобы они пережили саму систему, в которой они хранятся. Это означает, что мы должны пользоваться максимально открытыми и популярными форматами, чтобы они поддерживались как можно дольше. Сегодня фонды живут в «Эйдотеке», но в то же время они готовы к тому, чтобы жить за её пределами и быть воспроизводимыми в других системах.

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

Как я уже говорил, если мы храним изображение, то, скорее всего, используем формат TIFF в версии, в которой данные не сжаты (или сжаты без потерь), и их проще восстановить в случае проблем. GIF может не подойти по юридическим причинам, а JPEG — годится только для определённых задач.

Когда мы храним изображения, вместе с ними храним и манифест: описание того, что лежит в папке. Скажем, там десять JPEG-файлов, какие-то XML-данные и, возможно, данные в других форматах — манифест указывает, что это за файл, в каком он формате, кем и когда внесён. Благодаря этому в будущем любая система, которая примет эти данные, сможет понять, с чем имеет дело, — даже если формат хранения впоследствии придётся поменять.

При конвертации нужно будет удостовериться, что данные не изменились, что изображение не испортилось и не превратилось во что-то другое. По сути, это похоже на реставрацию: при реставрации мы документируем, что было и что стало, как проходил процесс, — чтобы объект не утратил статус оригинала. С цифровыми данными логика та же.

Самый продвинутый стандарт описания CIDOC CRM, к сожалению, пока не используется широко. Проблема в том, что заранее продумать всё невозможно, а этот стандарт как раз пытается это сделать: он в принципе успешен, но сложен и потому не получил широкого распространения.

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

Есть разные уровни описания объекта:

Табличные данные. Простейший уровень — как в Госкаталоге: у объекта есть автор, тема, тип файла и ограниченный набор других полей.

Данные, описываемые связями. Здесь автор — это не просто поле, а персона, которая относится к объекту как автор: получается трёхчастное описание. Именно так в «Эйдотеке» описываются связи между объектами: например, изображение относится к объекту визуально, в таких-то координатах, или персона относится к объекту как автор либо как тот, кто на нём изображён.

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

Пример: если искать «фотографии Толстого» по неструктурированным данным, поиск выдаст несколько братьев Толстых, которые в текстах часто различаются только инициалами (например, Л. Н. или А. Н.), плюс однофамильца-фотографа — и всё это смешивается, порождая ошибки. Если же данные структурированы и можно построить граф связей, такой путаницы не возникает — понятно, к чему именно относится объект. Обратная сторона: чем более структурированная система, тем сложнее заполнять данные.

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

Сейчас, стоит сказать, появилось уже больше зрелых коммерческих систем — рынок с тех пор заметно вырос. Один из показательных проектов — канадская система Access to Memory. Проблема в том, что не все зарубежные системы подходят для России по разным причинам.

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

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

Музеи в этом смысле в худшем положении: во многом потому, что типы объектов очень разные. Приходится постоянно следить за всеми изменениями.

Например, отдел Министерства культуры, который занимался цифровыми проектами, не исчез, но сильно изменился: ресурсов — как финансовых, так и человеческих — стало заметно меньше. Какие-то проекты поддерживаются, но нужно понимать: за тебя никто ничего не решит.

Значит, ответственность за решения приходится брать на себя.

интервью: Карина Никифорова