Данные

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

Основными предпосылками, которые рассматривались при отборе и анализе поддерживаемых типов, данных были следующие: 

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

В настоящий момент к типам поддерживаемых мультимедийных компонентов и типам, которые будут поддерживаться в перспективе, можно отнести следующие:

Наряду с представлением мультимедийных объектов важным аспектом является и способ хранения

Текстовые данные

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

Таким образом, для представления текстовых фрагментов может быть использован UNICODE для кодировки символов, формат TXT для простых текстовых фрагментов и RTF (RichTextFormat) для сложных, как общедоступные и открытые. 

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

Хранение фрагментов текста в виде отдельных файлов или текстовых полей серверов баз данных проблем не представляет.

Количественные данные

Ряд характеристик элементов коллекций может выражаться количественными значениями. Более того, ряд характеристик, не имеющих явную количественную природу, при оцифровке могут выражаться количественными значениями, так цвет, наряду с текстовым описанием (например, красный – red), может описываться числовым значением палитры (например, #FF0000). 

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

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

Растровые изображения

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

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

Формат - для браузеров стандартными форматами растровой графики являются форматы JPG (Joint Photogrph expert Group, возможны и другие суффиксы-расширения в названии файла - .jpeg, .jpe ), PNG (Portable Network Graphics) и GIF (Graphic Interchange Formаt), которые автоматически распознаются и обрабатываются браузерам и являются открытыми стандартами.

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

формат изображения  JPG,  PNG или GIF.

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

Аудио

Аудио фрагменты так же представляются компонентом, который должен поддерживаться в мультимедийной статье. Аудиофайлы характеризуются следующими хпрактеристиками форматом файла-контейнера, кодеком - алгоритмом компрессии аудиоданных, частотой дискретизации по времени и амплитуде, числом каналов воспроизведения. В настоящий момент имеется несколько форматов файла-контейнера - .WAV, .AAC, .OGG, .MP3, .M4A, .AIFF, .FLAC и другие. Как правило, формат файла-контейнера определяет кодек, которым осуществлено сжатие хранимых данных. Исходя из требования широкой доступности, следует учитывать, какие форматы аудиоданных воспроизводятся без дополнительных действий пользователя. Так на платформе WINDOWS в стандартном дистрибутиве устанавливаются кодеки, соответствующие контейнерам .WAV, .MP3, .WMA в iOS - .MP3, M4A, .AIFF, .WAV, в LINUX (в том числе и для OS ANDROID) - .WAV, .OGG, .MP3. Кроме того, подавляющее число компьютеров  оснащены двухканальными акустическими системами, так что, например, звук в формате DOLBY SURROUND 7.1 на них воспроизводиться не будет. Еще одним аспектом, который следует учитывать - длительность аудио фрагмента. Для фрагмента, длительность которого ограничивается несколькими секундами, содержащий его файл можно хранить непосредственно на сервере и передавать пользователю по прямой ссылке. Если длительность фрагмента в районе минуты и больше - то следует использовать потоковую передачу, что может потребовать поддержки отдельного потокового сервера. В подобной ситуации возможно использование внешнего хранения файлов на медиа серверах. В этом случае файл размещается на специальном медиа сервере (например YouTube.com) и от службы сопровождения сервера получается ссылка на доступ к ресурсу и, если нужно, фрагмент программного кода, который можно встроить в веб-документ, позволяющий получить из веб-документа доступ к ресурсу и обеспечить выполнение ряда условий. В случае использования подобной схемы хранения медиа-сервер при взаимодействии с пользователем анализирует состав программного и аппаратного обеспечения и передает данные в подходящем формате, даже если на сервер они помещались в другом формате. 

Таким образом, можно сформулировать следующие рекомендации для представления аудиофайлов : 

формат файла-контейнера - MP3, WAV, OGG (браузеры, поддерживающие стандарт HTML5 могут их воспроизводить самостоятельно), отдельно можно представлять файлы в формате MIDI

число каналов 1 или 2

частота дискретизации по амплитуде и времени на усмотрение автора

Видео

Видио файлы так же представляются компонентом, который должен поддерживаться в мультимедийной статье. Видеофайлы характеризуются следующими хпрактеристиками форматом файла-контейнера, кодеком - алгоритмом компрессии аудиоданных и видеоданных, частотой кадров и их размером. В настоящий момент имеется несколько форматов файла-контейнера - .AVI, .WMV, .FLV, .MP4, .MPEG, .MOV, .MKV и другие. Как правило, формат файла-контейнера определяет аудио и видео кодеки, которыми осуществлено сжатие хранимых данных. Для прогрессивных потоковых форматов может рассматриваться еще такая характеристика, как битрейт - объем данных, который требуется передать для воспроизведения одной секунды видео. 

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

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

Таким образом, можно сформулировать следующие рекомендации для представления видеофайлов : 

формат файла-контейнера - MP4, OGG (браузеры, поддерживающие стандарт HTML5 могут их воспроизводить самостоятельно)

Размер кадра (width x height) соответствует распространенным соотношениям 4х3, 16х9 и др.

Видео 360 

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

Особенностью использования такого типа ресурса является большая требовательность к пропускной способности коммуникационной среды. При современном уровне развития программных средств медиасервер отсылает пользователю полное сферическое изображение, а плейер выбирает для демонстрации некоторый фрагмент (примерно 10% от площади сферы), определяемый углом зрения и направлением «взгляда» пользователя. Это обстоятельство приводит к тому, что для приемлемого качества отображения видео360 минимальные требования к размеру кадра является 4K (распространенный телевизионный формат FullHD соответствует формата 2K. Формирование подобных медиапотоков накладывает высокие требования  на медиасервер (особенно, если ресурс пользуется популярностью), поэтом более предпочтительным представляется хранение ресурсов в формате Видео360 на сторонних стриминговых серверах (таких как YouTube) и использования встраиваимого кода для обращения к серверу. 

Таким образом, можно сформулировать следующие рекомендации для представления видеофайлов в формате Видео360 : 

формат файла-контейнера - MP4, OGG 

Размер кадра (width x height) соответствует соотношениям 2х1, формата не менее 4К.

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

3D модели, Сцены виртуальной и дополненной реальности

Использование 3D-моделей и интерактивных 3D-сцен для содержательной иллюстрации в документах привело к появлению автономных средств отображения таких объектов, в том числе и через интернет. Однако сложность и разнообразие инструментов создания таких ресурсов затрудняют их широкое использование в качестве элементов мультимедийных коллекций. Необходимость установки специализированного программного обеспечения на компьютер пользователя в общем случае не решает проблему отображения ресурса. Так, созданная в 3DS-max сцена может быть экспортирована в различные форматы (в том числе, и предназначенные для обмена 3D-моделями), однако при экспорте многие особенности модели будут утеряны, так как специфические модификаторы среды разработки не поддерживаются такими форматами. Более того, при использовании специальных плагинов, особенно коммерческих, воспроизведение сцены на компьютере пользователя может оказаться невозможным. Кроме того, для правильного воспроизведения сцены необходимо сохранить структуру проекта, содержащего для сложных сцен десятки каталогов и сотни, может быть, и тысячи отдельных файлов, причем в проекте могут сохраняться абсолютные пути к используемым ресурсам, так что даже при копировании всего дерева проекта в другое место правильное воспроизведение сцены может нарушиться. 

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

1. Использование специализированных веб-сервисов, позволяющих автору загрузить свой проект на сервер, при необходимости отредактировать и проверить адекватность его отображения и представить код для его внедрения в веб-страницу (как это сделано, например, на youtube.com). В качестве такого сервиса может, например, выступить сервис SketchFab . Недостатком такого решения можно считать то, что ресурс хранится на внешнем сервисе, и возник-новение проблем с аккаунтом владельца может сделать ресурс недоступным.

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

Использование картографической информации

В ряде профессиональных дисциплин информация привязывается к существующему или существовавшему ландшафту. Развитие современных картографических систем, размещенных в интернет позволяет каждому пользователю внедрить небольшой код в веб-документ, который обеспечит встраивание нужного фрагмента карты с набором функциональных элементов, которые могут предоставляться как владельцами картографического сервиса так и добавляться самим пользователем с использованием открытого API. Подобные сервисы предоставляются как российскими платформами, такими ка Yandex, MaiRu, так и глобальными сервисами, такими как Google, Microsoft, Apple и др. Причем для внедрения фрагмента карты в документ требуется указание географических координат и, если карта должна обладать дополнительной функциональностью, JavaScript библиотека, представляемая автором и разработанная на основе открытого API выбранного картографического сервиса. JavaScript библиотека представляет собой текстовый файл, который может храниться как текстовый фрагмент в базе данных сервера журнала (сервера поддержки коллекции)

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

Фрагмент кода, обеспечивающего отображение нужного фрагмента карты (обычно формируется на веб-странице соответствующего картографического сервиса), внедряемый в веб-документ

JavaScript библиотека, реализующая необходимую функциональность, разработанная на основе открытого API выбранного картографического сервиса (если карта должна обладать дополнительной функциональностью)