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

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

     

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

 

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

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

Сразу хочу вписать дисклеймер -  высказываю ниже очень субъективное мнение по вопросу платформ на открытом коде, которое я сформировал более 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. Простота использования и администрирования”, можно осуществлять с помощью меню инструментов с подсказками.

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

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

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

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

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

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

 

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

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

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

* * *

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

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

 

С уважением,

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

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

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