Открытое письмо авторам “Рекомендации для библиотек по организации собственных репозиториев открытого доступа”
|
(текст ниже взаимосвязан с рабочим материалом "Современные требования исследователей к интерфейсу и функциональности электронных библиотек и архивов")
Уважаемые Иван Бегтин и Ангелина Горбунова, Большое спасибо за интересную новую книгу “Электронная библиотека: инструкция по установке”. Случайно нашел ее в интернете и с радостью обнаружил, что вы рассматриваете нашу платформу ИнфоРост вместе с ведущими зарубежными аналогами на открытом коде. Ваша работа воодушевила “излить душу” по некоторым из упоминающихся вопросов и предоставить дополнительную информацию по платформе ИнфоРост. Еще раз спасибо за прекрасную публикацию и эту возможность высказаться! Сразу хочу вписать дисклеймер - высказываю ниже очень субъективное мнение по вопросу платформ на открытом коде, которое я сформировал более 10 лет назад. С тех пор, вместе с группой коллег, я занимаюсь разработкой платформы ИнфоРост и у меня, к сожалению, физически не было времени отслеживать события на фронте открытого кода для библиотек и архивов. Надеюсь, что какие то из упоминаемых ниже старых замечаний разрешились в последние 10 лет! * * * |
|
|||||||||||
|
Хорошего о платформах на открытом коде и их общественной пользе и бесплатности было сказано много. Полностью присоединяюсь и к вашим выводам о пользе этих платформ, и к выводам многих других авторов, ранее высказывавшихся по этим вопросам. Однако это письмо я хочу посвятить концептуальной критике платформ, включая на открытом исходном коде, и объяснению, почему в 2009 году мы решили сделать новую платформу ИнфоРост, а не создавать и развивать электронные коллекции с помощью одной из доступных на тот момент платформ. По мере рассуждений ниже, я формулирую требования к “универсальной платформе”, которые наша группа старается реализовать в платформе ИнфоРост все эти годы.
|
||||||||||||
|
Проблема перехода из двухмерного в трехмерное электронное информационное пространство
Одним из столпов устаревших информационных решений в библиотечной области является формат MARC (упрощенной версией которого стал Dublin Core), разработанный в 1960-х годах для целей обмена простыми структурированными библиографическими записями между библиотеками. Свою отличную роль в этом качестве MARC продолжает играть и сейчас. Однако с развитием Интернет и появлением новых чудесных технологических возможностей по организации и презентации информации на экране компьютера, устарелость МАРКа как главного формата метаданных стала проявляться все более отчетливо. Как стала проявляться и все большая устарелость платформ, которые использовали этот формат в качестве принципиального стандарта для обустройства интерфейсов и функциональности (электронные каталоги библиотек и т.д.). Поэтому, в частности, информационному сообществу пришлось овладевать новыми форматами как, например, SGML/XML, для целей описания и представления на Интернет объектов с более сложной информационной организацией по сравнению с простой биб записью. В формате МАРК, последняя представляет собой лишь список полей и подполей в определенной кодировке и последовательности. Например, как формат для библиографического описания изданий, MARC нормально справляется с “плоскими” записями, перечисляющими определенные поля описания в определенном порядке - Автор, Заглавие, Издатель, Год издания и т.д. Создатели формата MARC в 1960-х годах не особенно задумывались о таком понятии как “иерархичность организации информации”. Поэтому, когда под давлением развития информации в Интернете библиотекари захотели добавлять в биб описания книг дополнительную информацию как, например, содержания книг (для чего МARC не планировался), то им пришлось это делать путем перечисления глав книги одной за другой в отдельном зарезервированном поле. Основываясь на понятии простой плоской записи, MARC только таким образом мог отразить информацию об иерархичности организации книги на главы и подглавы. При таком подходе информация о содержании книги как бы сохраняется в биб записи, но с функциональной точки зрения особенно делать с этим нечего. 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-ю пунктами. Отдельного серьезного разговора достойны и требования к точкам доступа исследователей и интерфейсам платформы. Интерфейсы электронного ресурса, среди прочего, должны эффективно показывать большие комплекты метаданных и их иерархии, а также взаимосвязи между ними - данная функциональность также, как правило, не является сильной стороной платформ на открытом коде. Далее:
Но даже если взять за основу только упомянутые 8 требований, которые представляются нам базовыми для универсальной платформы, и примерить их в комплекте для оценки платформ на открытом коде, то окажется, что платформы отвечают им только частично. Именно поэтому одна и та же организация вынуждена поддерживать разные системы для удовлетворения нужд в разных электронных проектах. При этом следует упомянуть, что платформы на открытом коде продолжают принципиально уступать коммерческим индустриальным информационным системами, используемым электронными издателями и агрегаторами по ряду параметров, включая качество интерфейсов и быстроту работы, функциональные возможности и их расширяемость, мощность полнотектсового поиска, способность работать с очень большими коллекциями и базами данных, и по другим параметрам. Оглядываясь назад на последние 15 лет активного развития платформ на открытом коде, на десятки миллионов потраченных долларов и работу сотен программистов в ведущих университетах и научно-исследовательских организациях по всему миру, все же приходится в целом признать достижения платформ на открытом коде по крайней мере “удовлетворительными” с точки зрения соответствия современным и будущим требованиям исследователей, архивистов и библиотекарей для создания новых электронных ресурсов и инструментов. * * * Для справедливости нужно спросить - а возможно ли вообще теоретически и технически построить такую универсальную платформу, которая бы полностью удовлетворяла упомянутым требованиям и работала одновременно хорошо и для архивов, и для библиотек и научных депозиториев? Ответа на этот вопрос мы не знаем. Однако считаем эту задачу интересной в долгосрочном плане и пытаемся экспериментировать с ее технической реализацией в рамках проекта “Платформа ИнфоРост”. Если суммировать указанные выше и другие требования от разных потенциальных пользователей, то их реализация в рамках одной универсальной платформы может показаться “неподъемной”. С другой стороны, по нашему опыту, подавляющее большинство требований разных специалистов в разных электронных проектах также не являются взаимоисключающими при условии, что платформа имеет достаточно гибкую, легко расширяемую и масштабируемую архитектуру.
Универсальная платформа ИнфоРост
В основе платформы ИнфоРост как конструктора лежит идея нодов или узлов, которые можно организовать в любые иерархические структуры, размещать на них широкий выбор электронных материалов, и присваивать им индивидуализированные интерфейсы и функциональность в зависимости от требований конкретной электронной коллекции, издания или документа. Все основные функции по управлению коллекциями, включая упомянутые в “Требовании 6. Простота использования и администрирования”, можно осуществлять с помощью меню инструментов с подсказками. Конструктор представляет собой фундамент платформы, на основе которого создаются новые электронные коллекции и веб сайты, функциональность и интерфейсы которых можно индивидуализировать для нужд конкретного проекта. Дополнительные сервисы подключаются к платформе в виде новых функциональных модулей, которые создаются и интегрируются с платформой по мере возникновения необходимости в электронных проектах. Однажды сделанный функциональный модуль для одной электронной коллекции, со временем распространяется с обновлениями версий платформы на другие проекты. Таким образом, достижения новой функциональности в одном проекте становятся доступны всем пользователям на платформе ИнфоРост. Саму задачу создания универсальной платформы мы рассматриваем в качестве важной стратегической цели. По мере ее достижения, организации смогут: а). постепенно мигрировать электронные ресурсы со старых разрозненных платформ на единую универсальную, и таким образом сокращать количество поддерживаемых платформ с трех-четырех до одной-двух (большая экономия времени и денег); б). интегрировать/улучшать доступ к разрозненным коллекциям (тоже растущая задача), и в). намного более эффективно планировать улучшение функциональности платформы и применять ее сразу ко всем электронным ресурсам (а не только к научным статьям, или коллекциям книг или карт, или коллекциям архивных документов и т.д.).
Открытость кода платформы ИнфоРост Идею об открытости кода платформы ИнфоРост наша группа поддерживает принципиально. Любая организация, устанавливающая платформу на своем сервере, автоматически получает бессрочные права на использование платформы и Лицензию, дающую права на доступ к коду и его изменению если необходимо (надо эту информацию отразить на сайте!). Техническая поддержка платформы возможна на основе долгосрочного договора или от случая к случаю когда у пользователя возникает необходимость. В настоящий момент мы не уверены, когда и по какой модели выпускать код платформы в качестве открытого. Мы даже не уверены, нужен ли вообще российскому информационному сообществу открытый код платформы ИнфоРост. А если нужен, то в каком формате лучше обеспечить разумную долгосрочную инфраструктурную поддержку такому проекту? Ответов на эти вопросы у нас пока нет. * * * В заключение этого длинного письма, я хотел бы еще раз поблагодарить вас за обзор платформ для электронных архивов, библиотек и депозиториев и эту возможность высказаться. Упомянутые выше требования и идеи для универсальной платформы безусловно не являются оригинальными - все эти вопросы хорошо известны специалистам и многие бьются над их решением. Особенно важным сегодня нам представляется открытая профессиональная дискуссия по вопросу платформ, которую вы стимулируете своей работой, и здоровая конкуренция между разными платформами и концепциями их развития для пользы исследователей, библиотекарей, архивистов и всех, кто стремится создавать и использовать современные электронные ресурсы.
С уважением, Кирилл Фесенко Руководитель группы разработчиков платформы ИнфоРост |
||||||||||||
