Создание инструмента научных исследований на основе XML: Проблемы и методология - [5]

«До» - первоначальный вариант DTD:

Жаров, А. [К выпуску изд-вом «Молодая гвардия» сборника «Воспоминания о В. И. Ленине»]. Новый мир, 1955, № 12, с. 232-233.

«После» - используемый в настоящее время, упрощенный вариант DTD:

Жаров, А. Величие и простота. [К выпуску изд-вом «Молодая гвардия» сборника «Воспоминания о В. И. Ленине»]. Новый мир, 1955, № 12, с. 232-233.

К сожалению, из-за непостоянства и бессистемности в расположении составных элементов библиографических ссылок, нам не удалось запрограммировать простановку символов дочерних элементов в рамках символов ссылок в первоначальном варианте DTD. Ручная простановка занимала слишком много времени. Мы были вынуждены убрать почти все дочерние элементы их DTD и остановится на варианте модели ссылки cit, содержащем общие данные и символы года “(#PCDATA| year)*”. Элемент year, обозначающий год , мы не могли упразднить, поскольку он необходим для поиска по году публикации статьи. Один год выпуска Летописи может содержать ссылки на статьи, опубликованные в течение четырех предыдущих лет, так что мы не можем полагаться на год выпуска Летописи для точного задания параметров поиска по дате публикации. Кроме того, мы можем проставить символы элементов года “year” с высокой точностью при помощи разработанного приложения Java, предназначенного для обработки данных и кодирования.

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

3.2. Трудности применения Unicode

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

Следствием данного выбора стала проблема поиска подходящих инструментов XML, поддерживающих Unicode. Несмотря на то, что спецификация XML 1.0 определенно указывает: «Все XML процессоры должны принимать UTF-8 и UTF-16 кодировки [ISO/IEC] 10646» [XML 1.0], мы пришили к выводу, что не все доступные XML инструменты хорошо воспринимают Unicode. Ситуация в этом отношении улучшается, но когда мы начали проект в октябре 1999, она была достаточно неблагоприятной.  

3.2.1. Поисковые системы

На протяжении многих лет мы успешно использовали поисковую систему “Pat” (версию 5.x), предлагаемую Open Text Corporation (http://www.opentext.com/), для индексирования и поиска по нашим обширным коллекциям текстов SGML. Но “Pat” не поддерживает Unicode и другие многобайтовые кодировки символов. Поэтому мы отказались от “Pat” в пользу “XPAT” университета Мичигана (http://www.dlxs.org/), который основан на “Pat” корпорации Open Text, но модифицирован Мичиганом специально для применения электронными библиотеками. Из названия понятно, что “XPAT” поддерживает XML; тем не менее, несмотря на то, что разработчики “XPAT” работают над обеспечением поддержки Unicode, в настоящее время “XPAT” не в состоянии поддерживать многобайтовые кодировки. Поскольку ни один из продуктов, которые мы использовали для поиска по документам SGML и XML, не поддерживает Unicode, мы были вынуждены потратить много времени на анализ других вариантов.  

Некоторые критерии выбора поисковой системы XML включали:

Поддержка платформы Unix (предпочтительно AIX, Solaris или Linux). Поиск по всему тексту. Возможность задания слов для поиска с учетом изменяющегося окончания и поддержка регулярных выражений. Поддержка очень больших XML файлов (сотни мегабайтов). Поддежка Unicode. Java и/или XML API.  

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