ИнфоРост
информационные технологии для архивов и библиотек
27 / 28
Главная Публикации, выступления, исследовательские проекты, рабочие записки... Открытое письмо авторам “Рекомендации для библиотек по организации...

Открытое письмо авторам “Рекомендации для библиотек по организации собственных репозиториев открытого доступа” (2017 г.)

     

(текст ниже взаимосвязан с рабочим материалом "Современные  требования  исследователей к интерфейсу и функциональности электронных библиотек и архивов")

 

Уважаемые Иван Бегтин и Ангелина Горбунова,

Большое спасибо за интересную новую книгу “Электронная библиотека: инструкция по установке”. Случайно нашел ее на интернете и с радостью обнаружил, что вы рассматриваете нашу платформу ИнфоРост вместе с ведущими зарубежными аналогами на открытом коде. Ваша работа воодушевила “излить душу” по некоторым из упоминающихся вопросов и предоставить дополнительную информацию по платформе ИнфоРост. Еще раз спасибо за прекрасную публикацию и эту возможность высказаться!

Сразу хочу вписать дисклеймер -  высказываю ниже очень субъективное мнение по вопросу платформ на открытом коде, которое я сформировал более 10 лет назад. С тех пор, вместе с группой коллег, я занимаюсь разработкой платформы ИнфоРост и у меня, к сожалению, физически не было времени отслеживать события на фронте открытого кода для библиотек и архивов. Надеюсь, что какие то из упоминаемых ниже старых замечаний разрешились в последние 10 лет!

* * *

 

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

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

 

Проблема перехода из двухмерного в трехмерное электронное информационное пространство

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

Одним из столпов устаревших информационных решений в библиотечной области является формат MARC (упрощенной версией которого стал Dublin Core), разработанный в 1960-х годах для целей обмена простыми структурированными библиографическими записями между библиотеками. Свою отличную роль в этом качестве MARC продолжает играть и сейчас.

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

Поэтому, в частности, информационному сообществу пришлось овладевать новыми форматами как, например, SGML/XML, для целей описания и представления на Интернет объектов с более сложной информационной организацией по сравнению с простой биб записью. В формате МАРК, последняя представляет собой лишь список полей и подполей в определенной кодировке и последовательности.

Например, как формат для библиографического описания изданий, MARC нормально справляется с “плоскими” записями, перечисляющими определенные поля описания в определенном порядке - Автор, Заглавие, Издатель, Год издания и т.д. Создатели формата MARC в 1960-х годах не особенно задумывались о таком понятии как “иерархичность организации информации”. Поэтому, когда под давлением развития информации в Интернете библиотекари захотели добавлять в биб описания книг дополнительную информацию как, например, содержания книг (для чего МARC не планировался), то им пришлось это делать путем перечисления глав книги одной за другой в отдельном зарезервированном поле. Основываясь на понятии простой плоской записи, MARC только таким образом мог отразить информацию об иерархичности организации книги на главы и подглавы. При таком подходе информация о содержании книги как бы сохраняется в биб записи, но с функциональной точки зрения особенно делать с этим нечего.

XML эту проблему снял легко. Осознавая требования нового времени, Библиотека конгресса выпустила серию новых стандартов, таких как MODS/METS, которые, в частности, были призваны разрешить проблемы плоского МАРКа для нужд современных электронных исследователей и издателей. Тем не менее большинство платформ на открытом коде все же концептуально и технологически были выстроены вокруг идеи МАРКа, а не XML/MODS/METS.

 

 

Если смотреть на эту ситуацию с точки зрения информационной вселенной, то можно сказать, что при переходе с МАРКа на XML/MODS/METS в качестве главных стандартов, осуществляется переход из плоского двухмерного электронного информационного пространства в трехмерное. Платформы, сделанные в парадигме двухмерного пространства, с большим трудом адаптируются к новым требования трехмерного информационного пространства. Как правило, такие платформы принципиальной переделке не поддаются так как в их основе лежат соответствующие ограничения. Новая универсальная платформа должна работать на новых принципах.

 

 

Родовая неспособность МАРКа и Dublin Core (и электронных каталогов и платформ, которые используют данный стандарт организации информации за базовый) эффективно описывать и представлять информацию в сложных иерархических структурах, продолжает оказывать сдерживающую роль для развития инновационных информационных технологий и ресурсов.

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

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

Технологическая заскорузлость и функциональная раздробленность платформ

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

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

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

В результате получается, что архивные, библиотечные и научные сообщества вынуждены использовать разные платформы, которые наиболее оптимально (не идеально!) решают их текущие задачи. Поэтому нередка ситуация, когда ОДНА И ТА ЖЕ ОРГАНИЗАЦИЯ (университет, библиотека) обрастает разными платформами для разных типов электронных проектов. Например:

1. Что-то - для электронного библиотечного каталога.

2. Что то другое - для электронной библиотеки

3. Еще что-то другое - для электронных архивных описаний (finding aids).

4. Omeka - для полноимиджевых архивных документов и изображений.

5. DSpace - в качестве депозитория научных статей.

6. Что-то совсем другое - для собственной электронной издательской деятельности

7. Что-то еще - в качестве депозитория банков данных и т.д.

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

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

Поэтому в число требований к универсальной платформе нужно добавить следующие:

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

 Требование 3. Метаданные в разных стандартах  Универсальная платформа должна поддерживать любые стандарты метаданных, и иметь возможность содержать в себе разные коллекции, описанные в разных стандартах метаданных.

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

 

Открытый код и проблема “изобретения колес”

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

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

Западные исследователи, архивисты и библиотекари давно знают об упомянутых проблемах с решениями на открытом коде и ими было сделано несколько смелых попыток разрешить их путем создания всеобъемлющей технологической и организационной инфраструктуры для обмена инновационными электронными инструментами и улучшения доступа к разрозненным электронным коллекциям. Такая инфраструктура была призвана остановить процесс “изобретения колес” и позволить самому широкому кругу исследователей и организаций легко обмениваться плодами исследовательской и разработческой работы в области инновационных информационных инструментов и методологий. Одним из примечательных, но также неудавшихся проектов в этой категории был “Проект Бамбук” (www.projectbamboo.org, 2008 - 2013 гг.).

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

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

 

Другие важные требования к универсальной платформе

 Требование 6. Простота использования и администрирования  Универсальная платформа должна быть проста в использовании как для исследователей, так и администраторов. Исследователь и библиотекарь с навыками обычного пользователя компьютера и Интернет, должны иметь возможность самостоятельно, без привлечения программистов:

(1) создавать новые электронные коллекции и производить тонкую настройку их функциональности;

(2) настраивать работу метаданных, редактировать их и вносить любые изменения по мере необходимости;

(3) загружать электронные объекты в платформу и описывать их;

(4) определять параметры работы Указательного и поискового механизмов;

(5) приглашать к работе над электронным проектом других пользователей и присваивать им определенные права;

(6) регулировать режимы доступа к материалам в коллекции (открытый, полуоткрытый, по паролю/IP адресу);

(7) настраивать интерфейсы платформы и размещать на них необходимую функциональность и информацию;

(8) создавать веб сайты/веб странички и размещать их в любом месте электронной коллекции, и др.

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

 Требование 7. Работа с большими объемами данных  Успешные электронные коллекции имеют тенденцию к росту количества и сложности объектов. Современная платформа должна позволять, в случае необходимости, увеличивать количество объектов в коллекции с сотен и тысяч до сотен тысяч и многих миллионов. Крупные коммерческие платформы (LexisNexis, ProQuest, EBSCO, East View, Интегрум и т.д.), как правило, справляются с этой задачей намного лучше, чем платформы на открытом коде.

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

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

Или, например, опубликовав “по быстрому” большой комплект газет в мало структурированном виде (скажем газеты уложены по годам и месяцам), библиотекарь может в будущем захотеть вернуться к данной коллекции и далее “разложить” месячные комплекты ежедневных газет, где все номера свалены в одну кучу, по отдельным номерам. Т.е. углубить первоначальную иерархию когда появляется необходимость для этого и время c

Коллекция/Газеты/Наименование/Год издания/Месяц

до

Коллекция/Газеты/Наименование/Год издания/Месяц/Номер.

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

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

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

 

Другие требования к универсальной платформе (продолжение)

Указанный список “Требований к универсальной платформе” можно продолжать так как он не исчерпывается упомянутыми 8-ю пунктами.

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

Далее:

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

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

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

  • Есть уникальные требования к работе универсальной платформы и в качестве электронного каталога.

  • Электронные издатели академической литературы и учебников тоже предложат свои специфические требования к универсальной платформе.

  • Заглядывающие в будущее информационные специалисты предложат интегрировать в универсальную платформу технологию Блокчейн, инструменты Цифровых гуманитарных наук, и т.д.

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

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

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

* * *

Для справедливости нужно спросить - а возможно ли вообще теоретически и технически построить такую универсальную платформу, которая бы полностью удовлетворяла упомянутым требованиям и работала одновременно хорошо и для архивов, и для библиотек и научных депозиториев?

Ответа на этот вопрос мы не знаем. Однако считаем эту задачу интересной в долгосрочном плане и пытаемся экспериментировать с ее технической реализацией в рамках проекта “Платформа ИнфоРост”.

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

 

Универсальная платформа ИнфоРост

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

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

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

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

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

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

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

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

 

Открытость кода платформы ИнфоРост

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

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

* * *

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

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

 

С уважением,

Кирилл Фесенко

Руководитель группы разработчиков

платформы ИнфоРост