Аджиев А.C.ЦНТК РАН
Бездушный А.Н., Серебряков В.А.
ВЦ РАН
На основе проведенного ранее анализа российских математических электронных ресурсов, а так же опыта зарубежных математических информационных систем описан проект создаваемой математической информационной системы Math-Net.RU. Базовой платформой системы Math-Net.RU является универсальная информационная система ИСИР.
Проект описан в терминах перечня требований и условий, которым должна удовлетворять создаваемая система. Рассмотрены и проанализированы альтернативные варианты реализации различных компонент системы, а также пути решения возникающих при этом проблем. Очерчены категории хранимой информации, целевой круг пользователей системы и требуемая функциональность. Описана общая архитектура, схема данных, пользовательские интерфейсы, а также способы наполнения системы информацией, актуализации и синхронизации данных из других информационных систем и баз данных. Рассмотрены проблемы представления математических текстов и формул в информационных системах, дан сравнительный анализ существующих форматов хранения. Очерчены так же перспективы участия системы Math-Net.RU в создаваемой Всемирной математической информационной системе Math-Net, а также требования к системе-участнику.
Проведенная исследовательская работа показала, что существующие российские электронные информационные ресурсы в области математики слабо систематизированы и разрознены, как логически, так и физически. Математическая информация в целом слабо представлена для доступа в Сети. Хотя в ряде организаций и проводится работа по публикации данных в сети Internet, но эти представления информации преимущественно статические, плохо структурированы, обладают разнородными интерфейсами и форматами, и не всегда имеют средства поиска. В России отсутствует, как таковая, единая специализированная общенациональная система дистанционного поиска научной математической информации и доступа к ней [12].
Таким образом, основными задачами, определяющими дальнейшее развитие этой информационной инфраструктуры, является не только ее информационное наполнение, но и интеграция существующих и вновь создаваемых математических ресурсов в единую интегрированную информационную систему.
Для удовлетворения информационных потребностей российских математиков необходимо создание общедоступного через Internet общероссийского математического информационного портала, удовлетворяющего весь спектр информационных и коммуникационных потребностей российских математиков, а также лиц, обучающихся математике и интересующихся математикой.
Создаваемая система будет включать в себя различные компоненты, удовлетворяющие различным потребностям российских математиков, и охватывающих в совокупности всю российскую математическую жизнь. На первом этапе предполагается создать систему, решающую более узкий круг задач, а именно, удовлетворяющую основные потребности математиков в получении существующей в настоящий момент традиционной информации научного характера, то есть, информации о математических публикациях, организациях, персонах, проектах, грантах, конференциях, семинарах, программном обеспечении и web-ресурсах.
Создаваемая информационная система будет основана на технологиях и принципах построения информационной системы ИСИР [9]. В связи с этим, ниже в этой статье не рассматриваются теоретические аспекты и принципы функционирования информационной системы как таковой, а внимание уделено приложению этих принципов для создания российской математической информационной системы.
Ниже рассмотрены требования, определяющие структуру создаваемой информационной системы.
Предполагается, что пользователями системы будут российские и иностранные математики, а также аспиранты и студенты, выбравшие научную работу в области математики в качестве своей будущей профессии. Это означает, что, по крайней мере, часть функций создаваемой системы должна быть доступна широкому кругу любых заинтересованных пользователей, считающих себя в той или иной степени математиками.
Пользователями системы также будут административные работники Отделения математики РАН.
В системе будет храниться любая информация, необходимая для обеспечения научной работы или обучения в области математики. Основными типы хранимых информационных ресурсов являются:
Система должна обеспечивать:
Поскольку система должна интегрировать в себе информацию из различных источников, то для обеспечения эффективной поддержки системы, в частности, решения задач актуализации данных, архитектура должна быть распределенной. Это означает прежде всего распределенность хранения информации, т.е. должна допускаться возможность физического хранения информации в разных географически удаленных базах данных, имеющих разную структуру и поддерживаемых разными командами независимо друг от друга. Такие базы данных должны обеспечивать поддержку единых открытых интерфейсов поисковых запросов системы, чтобы пользователь мог осуществлять поиск и навигацию по всем базам данных системы одновременно.
Этим требованиям вполне соответствует разрабатываемая в настоящее время распределенная архитектура ИСИР, которая и будет использована при реализации математической информационной системы.
Схема данных была выработана на основе результатов анализа российских электронных математических ресурсов, потребностей российских математиков и на основе обобщения опыта европейских и американских математических информационных систем [12].
Модель данных была разработана на основе и в терминах объектной модели данных OWL/RDF [14], то есть представляет собою фиксированный набор типов (классов) ресурсов. Каждый класс характеризуется набором характеризующих его атрибутов и допустимых связей с другими ресурсами.
Как уже упоминалось, предполагается хранить в системе 7 типов информационных ресурсов, а также информацию о связях между ресурсами.
Многие ресурсы могут быть отражены несколькими способами в этой модели данных. Например, web-сайт организации может быть представлен, как атрибут соответствующей организации, или быть включенным в систему как самостоятельный ресурс типа “web-ресурс”, если он интересен как информационный ресурс безотносительно к организации, которой он принадлежит.
При разработке модели данных необходимо, прежде всего, установить уровень детализации при описании каждого типа ресурса. В простейшем случае любой ресурс можно описать одним текстовым атрибутом, в значении которого будет изложена в свободной форме вся информация о ресурсе. В более сложных случаях одному описываемому объекту может соответствовать в схеме данных целая совокупность ресурсов разных типов, связанных между собою разными связями. Примером может служить приведенный ниже эскиз модели описания конференции в системе поддержки конференций, разрабатываемой в рамках проекта ИСИР.
Высокая детализация описания ресурса обладает следующими преимуществами:
Недостатками высокой детализации описания являются:
Пожалуй, наиболее общими и неизбежными ошибками будут ошибки идентификации описанных ресурсов. Например, если в двух конференциях участвует некто Иванов И. И., и нам ничего о нем не известно, кроме фамилии и инициалов, в приведенной выше модели невозможно достоверно определить, стоит ли привязывать 2 доклада с этой фамилией к одной и той же персоне, или к разным.
Таким образом, уровень детализации и конкретный набор атрибутов и связей для ресурсов в системе должен быть разумным компромиссом между:
Очевидно, что нет смысла делать детализацию описания ресурсов ниже, чем детализация в большинстве источников данных системы, поскольку потеря детализации – это потеря данных и потеря возможностей поиска и трансформации.
В то же самое время излишняя детализация, мало востребованная пользователями в поисковых запросах, будет лишь порождать ошибки в данных при идентификации ресурсов.
Оптимальным, по-видимому, будет подход, при котором на первом этапе реализуется минимальная детализация, определяемая уровнем детализации источников информации, а также требованием обеспечения обработки основных пользовательских поисковых запросов, но обеспечивающая бесшовное (seamless) повышение уровня детализации.
Впоследствии, по мере развития средств детализации загружаемой и уже загруженной в систему информации, детализацию описания ресурсов можно увеличивать, расширяя, таким образом, возможности поиска, навигации и обмена с другими системами.
Как отмечалось выше, в российской математике для тематической классификации ресурсов традиционно используется международная система тематической классификации публикаций УДК (UDC) [4], а также математический рубрикатор MSC [3], созданный Американским математическим обществом (AMS), и получившим широкое всемирное признание.
Исследования показали, что российские математики в целом неплохо знакомы с обеими этими системами тематической классификации, и знают коды MSC и основной таблицы УДК, соответствующие тематике их работы.
Для тематического обозначения специальности персон в России используется также рубрикатор ВАК. Все проекты, поддерживаемые Российским фондом фундаментальных исследований (РФФИ) также классифицируются тематическим рубрикатором РФФИ.
Рубрикатор MSC имеет древовидную иерархическую структуру, а также содержит некоторые горизонтальные связи, характерные для одноязычного тезауруса.
Код УДК является сложной синтаксической конструкцией, которая описывает коды из основной таблицы УДК, определители, и также соотношения между ними, наиболее полно отражающие тематику ресурса. Например, код
621.923.014.5-185.4:[621.922.023:621.921.34](597+598)"18" обозначает тематику «Высокоскоростное шлифование алмазными брусками в Лаосе и Вьетнаме в 19 веке».
Основная таблица, а также таблицы определителей, имеют, также как и MSC, иерархическую древовидную структуру с горизонтальными связями одноязычного тезауруса.
Задача реализация полнофункциональной поддержки УДК, включая поиск по основному коду и определителям, является самостоятельной сложной задачей, и не будет решаться на первом этапе создания системы.
В то же время, основная таблица УДК сама может являться тематическим рубрикатором, который можно использовать для классификации ресурсов всех типов. Преимуществом такого рубрикатора, определяющим необходимость его использования, является знание большинством математиков кодов основной таблицы УДК, соответствующих их специальности.
Таким образом, в качестве основных тематических рубрикаторов в системе будет использован рубрикатор MSC, и основная таблица УДК, реализованные как тезаурусы-классификаторы [13]. В перспективе будет реализована полная поддержка системы классификации УДК.
Кроме этого, в системе для тематической классификации специальностей персон будет использован рубрикатор ВАК, а для проектов – рубрикатор РФФИ.
Как уже отмечалось выше, степень детализации описаний ресурсов, а именно набор атрибутов и связи между ресурсами системы, выбирались исходя из выполнимости необходимых пользователю поисковых запросов, а также исходя из характера доступной в перспективе для загрузки в систему информации.
Анализ того, какие именно поисковые запросы и навигационные возможности в действительности необходимы пользователям, затруднительно провести непосредственно. Потому за основу была взята совокупность поисковых и навигационных возможностей, реализованных в известных зарубежных математических информационных системах, имеющих большой опыт работы и обратной связи с пользователями. Логично предположить, что реализованные в них поисковые возможности перекрывают, как минимум, наиболее насущные потребности математиков.
Таким образом, в отдельные атрибуты и связи в схеме данных были выделены именно те атрибуты ресурсов, по которым, как можно ожидать, исходя из указанных выше соображений, в наибольшей степени будет востребован атрибутный поиск и агрегирование информации.
Кроме того, при выборе набора атрибутов была учтена также детализация описаний ресурсов в схемах данных систем, с которыми в перспективе может быть налажен обмен данными. Прежде всего, схема данных создающейся международной системы Math-Net, а также детализация описания ресурсов в стандартных международных форматах, таких как, например, DublinCore и VCard, с целью обеспечения по возможности легкого и обратимого преобразования данных к этим форматам.
Приведенные в модели списки атрибутов ресурсов и свойств связей являются предварительными и могут незначительно меняться.
Атрибуты:
Связи с рубрикаторами и тезаурусами.
Связи с другими ресурсами
Атрибуты:
Связи с рубрикаторами и тезаурусами:
Связи с другими ресурсами:
Организация и подразделения имеют следующие атрибуты:
Связи с рубрикаторами и тезаурусами:
Связи с другими ресурсами:
Проект или грант имеет следующие атрибуты:
Связи с рубрикаторами и тезаурусами.
Связи с другими ресурсами.
Конференция или семинар имеют следующие атрибуты:
Связи с рубрикаторами и тезаурусами:
Связи с другими ресурсами.
Имеет следующие атрибуты:
Связи с рубрикаторами и тезаурусами:
Связи с другими ресурсами:
Имеет следующие атрибуты:
Связи с рубрикаторами и тезаурусами:
Связи с другими ресурсами:
Как уже упоминалось, в системе Math-Net.RU предусмотрено разграничение доступа к ресурсам, как для чтения, так и для редактирования (см. ниже о пользователях системы и их правах). Для реализации разграничения доступа будут использованы технологии системы ИСИР, предусматривающие индивидуальное определение прав на чтение, модификацию и удаление каждого хранимого объекта в репозитории системы.
Помимо разграничения доступа к ресурсам в целом, будет ограничен доступ на чтение к некоторым атрибутам некоторых ресурсов. Например, при вводе информации о себе некоторые персоны могут пожелать, чтобы их домашние адреса и телефоны были доступны только сотрудникам системы и Отделения Математики для контактов с ними, но не показывались в интерфейсах системы всем желающим. Публичный доступ к полным текстам некоторых публикаций также может быть ограничен, в то время как остальные их атрибуты и связи будут общедоступны.
В соответствии с моделью разграничения прав доступа ИСИР, пользователи системы могут проходить аутентификацию двумя способами: вводя логин и пароль зарегистрированного в системе пользователя, либо осуществляя запрос с зарегистрированных IP-адресов. Пользователь, не прошедший аутентификацию, имеет только права на чтение общедоступных ресурсов и их атрибутов. Права доступа прошедшего аутентификацию пользователя могут быть специфицированы индивидуально, либо в соответствии с правами группы, к которой принадлежит этот пользователь.
Система должна иметь пользовательские WEB-интерфейсы, чтобы быть доступной как можно большему количеству пользователей. Пользователей системы можно условно разделить на 3 группы:
Эти интерфейсы должны быть на русском и английском языках, для обеспечения возможности доступа к ресурсам в качестве обычных пользователей большей части математиков мира.
Кроме того, среди российских математиков, особенно старшего поколения, велик процент людей, слабо владеющих компьютером. Часто даже обычные широко известные общеупотребительные термины, пришедшие в русский язык вместе с компьютерами и Internet, не понятны таким людям. Потому интерфейсы по возможности должны быть рассчитаны именно на такой круг людей.
Интерфейсы обычных пользователей должны обеспечивать следующие способы доступа к информации:
При навигации пользователь переходит между узлами, соответствующими разным рубрикам рубрикатора. При просмотре каждого узла он должен получать список ресурсов указанного типа, соответствующих текущей рубрике, а также список рубрик, для которых текущая рубрика является родительской.
На странице просмотра каждого ресурса должны быть соответствующие гипертекстовые ссылки на страницы просмотра связанных с ним ресурсов, по которым пользователь может осуществить переход к просмотру соответствующих ресурсов.
Такие интерфейсы должны быть для всех типов ресурсов. Помимо собственных атрибутов ресурсов, поиск также может быть осуществлен по рубрикам рубрикаторов.
Поисковые запросы должны вводиться в WEB-формы.
Ограничения на значения атрибутов должны иметь вид “в значении атрибута встречаются слова, удовлетворяющие данному простому регулярному выражению”.
Интерфейсы должны позволять использование в запросах логических операций между ограничениями на значения атрибутов.
Ниже приведен предварительный список атрибутов, по которым должны быть возможны поиск для каждого ресурса:
Помимо атрибутного поиска и навигации для каждого типа ресурсов будет возможен также полнотекстовый поиск по значениям ряда атрибутов (для некоторых публикаций и по полным текстам публикаций), а также исходных текстов, файлов кода и документации программного обеспечения.
Делятся на интерфейсы пакетной загрузки и интеграции и интерфейсы редактирования данных.
Интерфейсы загрузки данных работают с еще не загруженными в базу данных системы данными. Их задачи:
Подробнее о загрузке, нормализации и интеграции данных будет сказано ниже.
Интерфейсы редактирования данных работают с уже загруженными в систему данными. Они должны обеспечивать ввод, удаление и модификацию атрибутов ресурсов и связей между ними.
Все интерфейсы администраторов данных будут рассчитаны только на достаточно компетентных в техническом плане пользователей.
Предполагается, что такими пользователями будут российские математики или достаточно компетентные в математике и связанные с математикой по роду занятий люди, пожелавшие на каких-либо условиях сотрудничать с системой. Например, независимые авторы рефератов. По этой причине эти интерфейсы также как и интерфейсы обычных пользователей, должны быть рассчитаны на некомпетентных в техническом плане людей, и иметь простую структуру, не привязанную к схеме данных системы.
Интерфейсы должны обеспечивать возможность ввода информации, как через web-форму, так и другими способами. Например, такие пользователи могут присылать письма в установленном текстовом формате по электронной или обычной почте (текстовые формы). Такой формат должен быть опубликован и доступен всем заинтересованным лицам. Кроме того, должны быть обеспечены механизмы эффективной обработки операторами загрузки данных текстов в этом формате.
Как уже упоминалось, предполагаются следующие источники наполнения системы информацией:
В первых четырех случаях вводимая информация должна быть обработана подсистемой загрузки и интеграции данных. Эта подсистема производит преобразование информации к схеме данных системы, а также контроль адекватности информации и ошибок преобразования информации (см. об этом также выше, в описании схемы данных).
При этом, как уже упоминалось, оператор может осуществлять контроль адекватности, а также принимать участие при необходимости в нормализации и интеграции данных с другими ресурсами.
Под нормализацией далее будем подразумевать приведение значений атрибутов ресурсов и связей в соответствие с областями значений этих атрибутов. Например, если фамилия персоны написана с маленькой буквы, а также содержит случайно попавшие туда посторонние символы (например, скобки), первая буква фамилии должна быть заменена на заглавную, а посторонние символы должны быть удалены. Нормализацией также будет, например, приведение дат к установленному формату или устранение опечаток.
Под интеграцией далее будем подразумевать процессы идентификации ресурса, т.е. определения, существует ли уже такой ресурс в системе, идентификации связанных с ним ресурсов, создание при необходимости нужных ресурсов и объединение загружаемых ресурсов с уже существующими ресурсами, описывающими те же объекты реального мира.
Ниже источники наполнения системы данными рассмотрены подробнее.
Это наиболее простой способ ввода ресурсов. Однако на практике он должен применяться относительно нечасто. Например, при исправлении ошибок. При вводе данных оператором данных используются интерфейсы редактирования данных системы, которые работают непосредственно с базой данных системы.
Пакетная загрузка должна осуществляться из структурированных текстовых файлов, т.е. файлов, написанных в соответствии с некоторым форматом или синтаксисом. Такой формат должен позволять описывать ресурсы разных типов. В качестве такого формата предполагается использовать формат XML. В процессе загрузки на первой после нормализации значений атомарных атрибутов данные преобразуются к формату RDF, структура которого соответствует OWL-схеме репозитория системы, после чего происходит собственно загрузка данных в репозиторий и интеграция.
Предусматривается, также поддержка форматов данных некоторых других международных информационных систем (например, SOIF [11]). Данные в таких форматах могут быть сначала преобразованы к XML классическими методами синтаксического анализа, поскольку такие методы на выходе представляют информацию входного файла в виде дерева, которое становится структурой входного XML-файла.
При пакетной загрузке предполагается, что загружаемая информация адекватна по своему содержанию. В этом случае часто удается полностью или частично автоматизировать загрузку при помощи соответствующих алгоритмов. При этом конкретные случаи, в которых работа таких алгоритмов может дать сбой, должны быть распознаны этими алгоритмами и обработаны оператором вручную с помощью соответствующих интерфейсов.
Алгоритмы нормализации и, в особенности, идентификации и интеграции не могут быть достаточно универсальны для всех ресурсов и всех источников данных. Эффективный алгоритм, обрабатывающий высокий процент ресурсов без вмешательства оператора, и допускающий при этом минимум ошибок, может быть создан только с учетом специфических особенностей конкретного источника и характерных ошибок в получаемой из него информации.
Например: В системе – источнике данных имена персон хранятся в виде текстовых полей, в каждом из которых последовательно идут разделенные пробелом фамилия, имя и отчество персоны. Иногда после фамилии в скобках для женщин указывается девичья фамилия. При выгрузки данных для Math-Net.RU скрипт первое слово прописывает в качестве значения атрибута «фамилия», второе – «имя», все остальное – «отчество». Если встречается строка с девичьей фамилией, то именем становится, соответственно, Открывающая скобка, а отчеством – девичья фамилия + закрывающая скобка + имя + отчество.
Зная такую характерную ошибку источника данных, легко написать алгоритм, исправляющий все такие случаи без вмешательства оператора, и не допускающий при этом ошибок. Написать же универсальный алгоритм, учитывающий ошибки такого рода практически невозможно.
Для разрешения этого противоречия подсистем нормализации и интеграции должна быть построена по модульному принципу, позволяющему подключать разные алгоритмические модули для разных источников данных. Модули должны обмениваться информацией и взаимодействовать между собою на основе стандартных интерфейсов. Каждый модуль должен реализовывать один из вариантов алгоритмов решения данной подзадачи, и может быть использован для одного, или нескольких ресурсов и источников данных, специально под которые он и был создан.
Процессы нормализации, идентификации и интеграции идут в автоматическом режиме, для тех ресурсов, для которых вероятность ошибки, исходя из конкретной ситуации, минимальна. Если алгоритмы подсистемы не могут обеспечить достаточную безошибочность некоторой операции для некоторых конкретных ресурсов (например, не могут однозначно идентифицировать какой-либо ресурс), необходимо вмешательство оператора загрузки данных.
Например: фамилия персоны начинается со строчной буквы, либо в теле фамилии обнаружены заглавные буквы. Перед фамилией стоят пробелы. В этом случае подсистема удаляет лишние пробелы и приводит буквы к нужному регистру. Если в фамилии обнаружены посторонние символы – требуется вмешательство оператора.
Еще пример: при загрузке информации о персоне в базе данных системы не находится ни одной персоны с такой фамилией и инициалами, подсистема загрузки без участия оператора создает такую персону. Если же обнаружены 2 персоны с теми же инициалами, подсистема, в зависимости от реализованных в ней алгоритмов, может либо начать анализ других атрибутов, либо вызвать оператора, который должен принять решение по идентификации загружаемой персоны.
При пакетной загрузке существует 2 способа взаимодействия оператора с системой в сомнительных случаях:
Практика работы прототипа системы Math-Net.RU (см. о прототипе ниже) показала, что первый вариант предпочтительнее, когда процент сомнительных случаев невелик (около 1 – 3 % загружаемых ресурсов). При большем проценте предпочтителен второй вариант.
Требуемые алгоритмы компоненты и технологии для реализации нормализации и интеграции, удовлетворяющие описанному модульному принципу, в настоящий момент разрабатываются в рамках проекта ИСИР.
Предварительный вариант разбиения на модули, а также взаимодействия между модулями подсистемы нормализации и интеграции ресурсов для пакетной загрузки представлен на рисунке.
Пользователь системы предоставляет данные через рассмотренные выше интерфейсы пользователей, предоставляющих информацию. Если априори известно, что предоставляемая некоторым пользователем информация не требует контроля адекватности ее содержания (получена из надежного источника), загрузка сразу проводится по технологии пакетной загрузки. В противном случае все загружаемые данные проверяются предварительно на адекватность содержания вручную (ответственность за содержание ложится на оператора).
Для работы механизма загрузки данных из другой БД необходимо осуществить отображение онтологии источника на онтологию нашей информационной системы.
При этом возникает задача актуализации информации, включая как добавление в систему ресурсов, добавленных в базу-источник, обновление ресурсов, обновленных в базе - источнике, и удаление ресурсов, удаленных в базе-источнике. Следует также учесть, что информация об одном и том же ресурсе может быть получена из разных источников. В этом случае, если его описание было удалено только в базе данных, являющейся одним из таких источников, вряд ли стоит удалять ресурс из системы. Конфликты также могут возникнуть при изменении описания ресурса в одном из источников.
В соответствии с технологией ИСИР каждый ресурс в системе может иметь любое количество URI разных типов. В метаданных из базы данных - источника для каждого ресурса необходимо выделить свой уникальный идентификатор, который и будет храниться в базе данных системы в форме соответствующего типа URI – URI источника происхождения данных. Тип этого URI должен идентифицировать базу данных - источник происхождения данного ресурса, а его значение – быть уникальным идентификатором ресурса в базе данных источнике.
Такие URI присваиваются также ресурсам, полученным из других источников. В случае, если информация об дном и том же ресурсе получается из разных источников, ресурс получает несколько URI источников происхождения. Причем, если источник не является другой базой данных, из которой система получает информацию в режиме актуализации (например, информация вводится пользователем или оператором), такой URI получает формальное значение, не идентифицирующее фактически ресурс. Имеет смысл только его тип, идентифицирующий источник его происхождения.
Сначала из базы источника осуществляется выгрузка данных в установленном формате в соответствии со схемой отображения схем данных, после чего данные загружаются в систему по технологии пакетной загрузки. Идентификация ресурсов при этом проводится по вышеописанному URI. В режиме актуализации ресурсы, отсутствующие в базе-источнике, но имеющие в системе URI источника происхождения, тип которого соответствует этой базе-источнику данных, лишаются этого URI, поскольку они были удалены из базы – источника, а значит эта база уже не может считаться источником происхождения данных ресурсов. Если такой ресурс при этом не имеет других URI источника происхождения, он удаляется из базы данных системы.
Под харвестингом в данном случае понимается сбор информации, не предназначенной изначально для загрузки в систему из источников в сети Internet. Такими источниками могут быть, например, математические web-сайты. Имеет смысл осуществлять харвестинг только из тех источников, адекватность информации которых не вызывает сомнений.
Компонента харвестинга должна в соответствии со структурой источника извлекать из него информацию (метаданные ресурсов), и выдавать структурированный текст описаний ресурсов в доступном для пакетной загрузки формате, после чего данные загружаются в систему по технологии пакетной загрузки.
Такая компонента харвестинга также должна быть уникальна для каждого источника, и строиться по модульному принципу.
Математические тексты в электронном виде могут храниться в разных форматах. Такие форматы должны удовлетворять по возможности следующим свойствам:
Ниже перечислены распространенные универсальные, а также специализированные математические форматы для математических текстов, а также оценка их применимости.
Хорошо удовлетворяет пунктам 1-3 и 5-6, однако совершенно не имеет средств представления математических формул, и вообще какого-либо форматирования текста.
Ограничено удовлетворяет пунктам 1, 4 и 6. Совершенно не удовлетворяет пунктам 2, 3 и 5.
Хорошо удовлетворяет пунктам 1-3 и 5-6. Однако возможности HTML по записи математических формул весьма ограничены. В разных браузерах формулы в HTML могут выглядеть по-разному.
Этот формат удовлетворяет пунктам 1-2 и 4 и отчасти 6. В настоящее время практически для всех используемых форматов существует программное обеспечение для приведения текстов с формулами к такому виду. Однако, такое представление получается довольно громоздким, и совершенно не позволит осуществлять индексацию и поиск по математическим формулам. Потому пункт 7 не удовлетворяется, а пункт 5 удовлетворяется частично.
Этот формат широко распространен и общепринят для обмена печатными текстами (удовлетворяет пунктам 1, 6). Он так же хорошо удовлетворяет пунктам 2 и 4, и отчасти пунктам 3 и 5. Однако формат довольно сложен, и позволяет один и тот же текст представить многими разными способами (например, текст может быть упакован разными способами, или вообще представлен как картинка). В связи с этим индексация текста в PDF довольно затруднительна. Математические формулы в PDF также обычно представлены графически, а потому их индексация невозможна.
Этот формат очень хорошо удовлетворяет всем вышеперечисленным требованиям, за исключением пункта 2, поскольку этот формат описывает в большей степени структуру самой формулы (безотносительно к математической семантике), а не только ее отображение. Потому конверторов из каких-либо форматов в TeX практически не существует. Еще одним недостатком формата TeX является необходимость наличия громоздкого компилятора для просмотра формул не знакомыми с этим форматом людьми. Однако очень многие математики знают TeX и создают свои статьи в формате TeX. Кроме того, TeX имеет несколько версий, и каждая из них требует свой компилятор.
Этот формат, как и PDF, по сути является графическим, и возник, как производный от формата TeX. Он отчасти удовлетворяет требованиям 4 и 6 и не удовлетворяет остальным.
Как и PDF, в этом формате в ряде случаев текст может быть представлен разными способами, в том числе и как графический объект, а математические формулы всегда будут представлены как графические объекты. Он удовлетворяет требованиям 1, 2, 4, 6, частично 5 и совсем не удовлетворяет требованию 3, поскольку очень некомпактен.
Эти форматы появились относительно недавно и основаны на формате XML. MathML, так же как и TeX, определяет структуру отображения математической формулы, в то время как OpenMath определяет семантику формулы. Запись формулы в MathML может содержать ссылки на объекты, семантика которых определяется средствами OpenMath. Структура описания математических объектов в OpenMath позволяет использовать этот формат в системах формальной логики и в системах поиска доказательств.
В настоящий момент ведется создание единой базы данных математических объектов в OpenMath, что можно считать первым шагом на пути создания единой математической базы знаний в формате, пригодном для машинной обработки.
В целом MathML и OpenMath, также как и TeX, удовлетворяет всем вышеперечисленным требованиям к форматам представления математических текстов, за исключением пункта 2. Однако в настоящий момент эти форматы и весьма перспективные технологии, основанные на них, пока не получили широкого распространения.
В качестве дальнейшего развития MathML и OpenMath в настоящее время создается также стандарт “OpenMathematicalDocuments” (OMDoc)
Максимально удовлетворяет этим требованиям формат TeX. Он полностью удовлетворяет требованиям 3, 4, 5, и в значительной степени требованиям 1 и 6. В меньшей степени удовлетворяют этим требованиям форматы DVI, PDF, PostScript, HTML, ASCII-текст и RTF. Именно эти форматы традиционно используются также в существующих математических информационных системах для хранения полных текстов публикаций и их аннотаций. Новый перспективный формат MathML/OpenMath также хорошо удовлетворяет требованиям 3, 4 и 5, однако он не успел получить пока широкого распространения, и под него пока не создан весь спектр необходимого программного обеспечения.
Для заголовков и других строковых атрибутов математических публикаций к вышеперечисленным требованиям добавляется еще одно: тексты должны быть встраиваемы в HTML-файлы в виде ASCII-текста и хорошо читаемых формул. Этому требованию полностью удовлетворяет только формат TeX, и, частично, HTML и ASCII-текст (с неполной поддержкой формул). В перспективе этому требованию может удовлетворять также MathML/OpenMath.
В существующих математических информационных системах эта проблема решается использованием заголовков в формате TeX. Преимуществом такого подхода является возможность индексировать формулы в атрибутах так же, как и слова. Кроме того, пользователи, не знакомые с TeX, также могут читать атрибуты без формул и искать ресурсы по словам в этих атрибутах.
В системе Math-Net.RU также предполагается хранение формул в текстовых атрибутах ресурсов в форматах TeX или ASCII-текст. Кроме того, в качестве допустимых форматов для хранения полных текстов могут быть использованы форматы DVI, PDF, PostScript, HTML, ASCII-текст, RTF. По мере развития и распространения перспективных форматов MathML/OpenMath (OMDoc), их поддержка также может быть обеспечена в Math-Net.RU.
В настоящий момент проект всемирной системы Math-Net весьма расплывчиват и далек от стадии технического задания. Существует очень немного требований, которые в настоящее время предъявляются к информационной системе, чтобы быть узлом всемирной Math-Net. Ниже перечислены эти требования, а также описано, каким образом система Math-Net.RU будет удовлетворять этим требованиям.
Как было указано выше, реализация системы Math-Net.RU предусматривает англоязычный интерфейс поиска информации.
В рамках проекта ИСИР разрабатываются технологии, обеспечивающие выгрузку и загрузку информационных ресурсов в виде наборов метаданных в стандартных форматах, таких, как DublinCore, Vcard, и RDF. Эти технологии также будут использованы и в системе Math-Net.RU.
Для интеграции в систему Math-NetIMU рекомендовал математическим организациям создавать вторичные страницы организаций.
Вторичная страница организации или подразделения представляет собою HTML-документ установленного формата и дизайна, содержащий название и логотип организации или подразделения, а так же расположенные в установленных местах ссылки на страницы, содержащие основные сведения об организациях.
Существуют инструментальные средства, генерирующие вторичную страницу организации на основе вводимой в диалоговый интерфейс необходимой информации об организации и необходимых WEB-ссылок.
Система Math-Net.RU предусматривает выдачу по специальному запросу URL вторичной страницы любой организации. Если организация не имеет своей вторичной страницы, система выдаст URL специального вида. Ответ на запрос по такому URL система выдаст динамически сгенерированную “суррогатную” вторичную страницу на основе атрибутов организации, содержащихся в базе данных Math-Net.RU. Таким образом, каждая организация, представленная в Math-Net.RU, автоматически будет представлена и во всемирной Math-Net.
Этот рубрикатор фактически уже стал стандартом в мировой математики для тематической классификации ресурсов любых типов. Поддержка классификации ресурсов всех типов этим рубрикатором будет реализован также и в Math-Net.RU.
В настоящий момент электронная публикация рассматривается IMU и CEIC как наиболее перспективное средство обмена научной информацией. Поддержка публикаций такого рода также предусмотрена в Math-Net.RU.
Здесь под функциями узла распределенной базы данных подразумевается способность системы обрабатывать поисковые запросы в соответствии с определенным протоколом, утвержденным в качестве протокола общения между узлами системы. К настоящему моменту такой обязательный для всех участников протокол в Math-Net утвержден не был, а разные потенциальные участники Math-Net пользуются разными протоколами.
Таким образом, имеет смысл говорить не о протоколе, а о требованиях, которым он должен удовлетворять. Требования к возможностям обработки поисковых запросов для Math-Net.RU, сформулированные выше, вполне соответствуют возможностям существующих информационных систем, таких, как, например, сервисы AMS, ZentralblattMATH и немецкая система Math-Net.
В настоящее время реализован прототип портала Math-Net.RU, доступный в Web по адресу http://www.math-net.ru/ . Прототип был реализован на основе уже реализованных технологий ИСИР.
Прототип поддерживает хранение, поиск, выдачу и сопровождение (ввод и редактирование) следующих ресурсов
Прототип поддерживает представление информации на русском и английском языках в интерфейсах поиска и навигации.
Прототип поддерживает также интерфейсы оператора данных на двух языках (ввод любых ресурсов) и пользователя, предоставляющего информацию (ввод персон, интерфейс на русском языке). Частично реализован также интерфейс оператора, загрузки данных.
Кроме того, имеется возможность пакетной загрузки информации из простого текстового и структурированного (XML) формата.
Используя эти средства в рамках проекта Math-Net.RU, был создан Директорий российских математиков, ставший частью всемирного Директория математиков 2002 года.
В настоящий момент база данных Math-Net.RU включает достоверную информацию о более чем 4000 математиков, а также полную базу данных журналов OM РАН.
При создании директория были реализованы средства для рассылки математикам писем, с приглашением ввести информацию о себе для Директория российских математиков и паролей для ввода и система учета активности математиков, которым разосланы письма и даны права на ввод информации.
Материал опубликован на http://www.elbib.ru/