Уолш Джон

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

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

Представленный John Walsh В XML Конференция В Орландо, Флорида, 9-14 декабря 2001

В своем докладе я опишу процесс создания электронного исследовательского инструмента, имеющего в своей основе печатный библиографический указатель, который предназначен для использования в научных целях, а также проанализирую некоторые трудности, с которыми мы столкнулись в ходе реализации данного проекта, и расскажу об избранных нами вариантах решения возникших проблем. Проект разрабатывается Цифровой Библиотечной Программой университета Индианы при поддержке в форме гранта от Департамента Образования США. Наш проект предполагает перевод в электронный формат двадцатилетнего периода (1956—1975) библиографического указателя советского периода «Летопись журнальных статей», в котором собраны ссылки на статьи из более чем 1700 научных и популярных журналов из различных областей человеческих знаний, как точных, так и гуманитарных наук.

Этапы проекта:

Создание цифровых изображения 250 000 страниц текста с бумажных оригиналов печатного выпуска Летописи.

Обработка изображений страниц системой Оптического Распознавания Символов с целью получения редактируемого электронного текста.

Разработка DTD.

Программное и ручное кодирование текста, его корректирование и проверка на соответствие тредованиям XML.

Создание Web-основанного интерфейса для поиска, просмотра и визуального представления электронного варианта «Летописи журнальных статей».

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

Проблемы проекта:

Очень большие и сложные документы XML и DTD. XML документы научно- исследовательского содержания, такие как коллекции полных текстов литературных работ, обширные словари или указатели масштаба «Летописи журнальных статей», имеют тенденцию разрастаться до огромных размеров, от сотен мегабайтов до более чем гигабайта. Соответственно, многие широкоупотребляемые DTD электронных библиотек, такие как Инициатива Кодирования Текста (TEI) или Кодированные Архивные Описания (EAD) отличаются своими большими масштабами и сложностью. Мы пришли к выводу, что несмотря на то, что эти DTD действительны, не все доступные инструменты (редакторы, XML процессоры, хранилища информации, и т.д.) способны справиться с задачами обработки документов и DTD такого размера и сложности. Поддержка Unicode. В «Летописи журнальных статей» в основном используется русский язык и кириллический алфавит. Однако, в тексте присутствуют и другие языки — английский и греческий, в основном в форме ссылок на иностранные источники, что обусловливает использование добавочных алфавитов. Подобное сочетание языков и алфавитов характерно для академической среды. Стандарт Unicode разрешает многие проблемы, связанные с перемешиванием различных наборов символов в одном электронном документе. Одним из требований проекта является надежная система поддержки стандарта Unicode во всех инструментах, используемых в разработке этого и других проектов цифровых библиотек. Быстрые, гибкие и сложные инструменты поиска и индексирования. Для того, чтобы такие масштабные коллекции исследовательских данных как «Летопись журнальных статей» использовались в полную силу необходимы высококачественные инструменты поиска. Необходим быстрый поиск по ключевым словам по всему тексту документа, а также более сложный поиск, с использованием преимуществ структуры XML и кодировки.

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

1. Введение

Данный доклад посвящен трудностям, с которыми мы столкнулись, и методологии и инструментам, применяемым Цифровой Библиотечной Программой университета Индианы в рамках реализации проекта «Летопись журнальных статей».

1.1. О проекте

Некоторая вводная информация представлена на web-сайте проекта: ( http://webapp1.dlib.indiana.edu/letopis/index.jsp?lang=ru). Это кракий обзор проекта «Летопись журнальных статей»:

Цифровая Библиотечная Программа университета Индианы получила грант от Департамента Образования США в рамках Раздела IV «Технологическая программа» с целью перевода в электронный формат и представления на World Wide Web «Летописи журнальных статей» за период в двадцать лет (1956—1975 гг.), библиографического указателя советских периодических изданий, издающегося с 1926 года по настоящее время. Указатель охватывает более чем 1700 журналов, серий и продолжающихся публикаций академий, университетов, научно-исследовательских институтов в областях гуманитарных, естественных наук, наук об обществе, а также популярную периодическую литературу. Переведенная в электронный формат и помещенная в World Wide Web Летопись обеспечит доступ к периодической литературе важного периода российской истории, начинающегося с хрущевской «оттепели», следующей за двадцатым съездом коммунистической партии советского союза (КПСС), и продолжающегося вплоть до первой половины так называемой брежневской «эпохи застоя». Студенты и ученые, изучающие российскую политологию, литературу или историю периода 1956—1975 гг. безусловно оценят по достоинству «Летопись журнальных статей».

1.2. Мотивы осуществления проекта

Стимулов осуществления проекта оцифровывания было два. Первый — увеличение возможностей использования указателя. Использование печатного варианта Летописи представляет определенные трудности. Летопись издавалась еженедельными выпусками, общего указателя по Летописи не существует, так что поиск по ней довольно сложен и занимает много времени. Цифровая версия позволит осуществлять поиск по всему двадцатилетнему периоду Летописи, который мы переводим в электронный формат, что существенно облегчит использование и увеличит полезность указателя.

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

1.3. Структура «Летописи журнальных статей»

Структура DTD Летописи повторяет структуру печатного варианта. В печатном варианте Летописи библиографические ссылки структирировны по более чем 300 предметным заголовкам. Предметные заголовки имеют трех-ступенную иерархию. Первый уровень включает 33 предметных заголовка, подразделяемых в свою очередь на подзагловки второго и третьего уровня. Заголовки первого уровня пронумерованы с использованием римских цифр; разделы второго уровня пронумеровны с использованием арабских цифр. Для третьего уровня подзаголовков были использованы строчные кириллические буквы. Ниже приведены некоторые примеры заголовков из иерархии:

I. Марксизм-ленинизм

1. Произведения основоположников марксизма-ленинизма.

2. Литература об основоположниках марксизма-ленинизма. Работы по марксизму-ленинизму.

XIII. Государство и право

1. Общие вопросы. Теория и история государства и права.

2. Государство и право СССР.

а. Общие вопросы. Советское строительство. Государственное и административное право.

б. Другие отрасли советского права.

в. Суд и прокуратура. Работа органов юстиции.

1.4. DTD «Летописи журнальных статей»

Ниже приводится DTD, которое мы используем для кодирования Летописи. Оно имеет элемент letopis, который вбирает в себя выпуски за несколько лет. В нем таже имеются контейнерные элементы для года и еженедельных выпусков. Мы использовали три элемента подразделов (div1, div2 и div3) для обозначения предметных подзаголовков внутри трехступенчатной предметной иерархии. Элемент cit заключает в себе одну библиографическую ссылку. Дополнительная информация об этих и других элементах и атрибутах содержится в комментариях к DTD приводимых ниже.

<!-- ...................................................................... -->

<!-- Letopis Russian Index XML DTD ........................................ -->

<!-- version: 2.4.xml2001 ................................................. -->

<!-- author: John A. Walsh ................................................ -->

<!-- Copyright 2000 The Trustees of Indiana University .................... -->

<!-- ...................................................................... -->

<!--                    LETOPIS                                    -->

<!--                    The letopis element can be a root element  -->

<!--                    to contain metadata (in letopisHeader)     -->

<!--                    and multiple volumes                       -->

<!ELEMENT letopis       (letopisHeader, volume+)                     >

<!--                    LETOPISHEADER                              -->

<!--                    Content model will be fleshed out later.   -->

<!--                    Will be modeled on TEI header and          -->

<!--                    contain metadata about the project and     -->

<!--                    the text.                                  -->

<!ELEMENT letopisHeader (#PCDATA)                                    >

<!--                    VOLUME                                     -->

<!--                    Used to contain a single volume of the     -->

<!--                    letopis, which includes fifty-two weekly   -->

<!--                    issues.                                    -->

<!ELEMENT volume        (issue+)                                     >

<!--                    VOLUME/@ID                                 -->

<!--                    Use the format "vXX", where XX is the year -->

<!--                    of the volume.                             -->

<!ATTLIST volume        id ID #REQUIRED                              >

<!--                    ISSUE                                      -->

<!--                    Used to contain a single weekly issue of   -->

<!--                    the index.                                 -->

<!ELEMENT issue         (div1+, back)                                >

<!--                    ISSUE/@ID                                  -->

<!--                    Use the format "vXXiYY", where XX is the   -->

<!--                    year of the volume and YY is the           -->

<!--                    week (01-52) of the issue.                 -->

<!ATTLIST issue         id ID #REQUIRED                              >

<!--                    DIV1                                       -->

<!--                    Contains the a top level subject in the    -->

<!--                    subject hierarchy.                         -->

<!ELEMENT div1          (head, ref*, (div2+ | (cit | citXref)+))     >

<!--                    DIV1|DIV2|DIV3/@N                          -->

<!--                    Short name or number for DIV1 subject      -->

<!--                    division                                   -->

<!--                    DIV1|DIV2|DIV3/@ID                         -->

<!--                    Unique ID for each subject division.  Use  -->

<!--                    the format "vXXiYYsAABBCCDD", where XX is  -->

<!--                    the year of the volume, YY is the          -->

<!--                    week (01-52) of the issue, AA is the       -->

<!--                    the subject number for the first level of  -->

<!--                    hierarchy (DIV1), BB is the subject number -->

<!--                    for second level of the hierarchy (DIV2),  -->

<!--                    CC is subject number for the third level   -->

<!--                    of the subject hierarchy (DIV3), and DD is -->

<!--                    the subject number for the fourth level    -->

<!--                    (DIV, a named but non-standard subdivision -->

<!--                    that is not part of the standard hierarchy.-->

<!ATTLIST div1          n CDATA #IMPLIED id ID #REQUIRED      >

<!--                    DIV2                                       -->

<!--                    Contains a second level subject in the     -->

<!--                    subject hierarchy.                         -->

<!ELEMENT div2          (head, ref*, ((div3| cit | citXref | div)+)) >

<!ATTLIST div2          n CDATA #IMPLIED id ID #REQUIRED        >

<!--                    DIV3                                       -->

<!--                    Contains a third level subjects in the     -->

<!--                    subject hierarchy.                         -->

<!ELEMENT div3          (head, ref*, (cit | citXref | div)+)         >

<!ATTLIST div3          n CDATA #IMPLIED id ID #REQUIRED         >

<!--                    DIV                                        -->

<!--                    Contains a named, but non-standard subject -->

<!--                    subdivision that is not part of the        -->

<!--                    standard subject hierarchy.                -->

<!ELEMENT div           (head, ref*, (cit | citXref)+)               >

<!ATTLIST div           n CDATA #IMPLIED                             >

<!--                    HEAD                                       -->

<!--                    Contains a subject heading.  Used in DIV1, -->

<!--                    DIV2, DIV3, and DIV.                       -->

<!ELEMENT head          (#PCDATA)                                    >

<!--                    CIT                                        -->

<!--                    Contains a single citation from the index. -->

<!ELEMENT cit           (#PCDATA | year)*                            >

<!--                    CIT/@ID                                    -->

<!--                    Contains a unique ID for each citation.    -->

<!--                    Use the format "vXXiYYcNNNNN", where XX is -->

<!--                    the volume year, YY is the week (1-52) of  -->

<!--                    the issue, and NNNNN is the citation       -->

<!--                    number (citations are numbered             -->

<!--                    sequentially, starting at 1 at the         -->

<!--                    beginning of each year.)                   -->

<!ATTLIST cit           id ID #REQUIRED                              >

<!--                    XREF                                       -->

<!--                    Cross-reference.  The attribute "target"   -->

<!--                    is used to point to the ID of the item     -->

<!--                    being referenced.  Used after subject      -->

<!--                    headings as a "see also" type reference    -->

<!--                    to similar subjects and within citXref     -->

<!--                    elements to point to the full citation     -->

<!--                    referenced by the abbreviated citXref      -->

<!--                    citation.                                  -->

<!ELEMENT xref          (#PCDATA)                                    >

<!ATTLIST xref          id ID #IMPLIED

target IDREF #REQUIRED                       >

<!--                    YEAR                                       -->

<!--                    Contains year of publication within an     -->

<!--                    individual citation.                       -->

<!ELEMENT year          (#PCDATA)                                    >

<!--                    CITXREF                                    -->

<!--                    Contains a special class of unnumbered     -->

<!--                    abbreviated citation that points           -->

<!--                    to the a full citation located elsewhere   -->

<!--                    in the index.                              -->

<!ELEMENT citXref       (#PCDATA | xref)*                            >

<!--                    BACK                                       -->

<!--                    Contains back matter located at the end of -->

<!--                    each issue.  The content model for "back"  -->

<!--                    will be fleshed out later with more        -->

<!--                    structure.                                 -->

<!ELEMENT back          (#PCDATA)                                    >

2. Процесс оцифровывания

Основные этапы процесса оцифровывания таковы:

Выпуски Летописи в печатном виде без переплета отосыляются фирме-подрядчику для перевода в электронный формат. Страницы Летописи сканируются и сохраняются с параметрами 600 точек на дюйм (dpi) в двухцветном режиме TIFF образов.

• По получении цифровых изображений страниц от подрядчика они подвергаются обработке системой Оптического Распознавания Символов (OCR) компании ABBYY(http://www.abbyy.com/). Программный продукт “Fine Reader” российской компании ABBYY, единственный из известных нам, способен распознавать русский (киррилический) текст. Тексты, распознанные при помощи процесса OCR, сохраняются как UTF-8 файлы Unicode.

• Файлы, содержащие выпуски Летописи, проходят через первоначальное ручное кодирование, включающее проставление символов элементов div1, div2 и div3 согласно подразделениям предметных заголовков. Необходмые атрибуты id каждого раздела на данном этапе игнорируются.

• Файлы, содержание выпуски Летописи, подвергаются заказчиком обработке программой Java, позволяюцей автоматизировать основной объем работы по кодированию текста. Программа Java, названная LMU от английского выражения “Letopis MarkUp” («Кодирование Летописи»), делает следующее:

1. Производит прекодировочную обработку по корректированию типичных ошибок OCR и форматирует текст с целью увеличения эффективности и надежности процесса кодирования.

2. Проставляет правильные значения id атрибутов (в соответствии с годом выпуска, номером выпуска и положением предметного заголовка в иерархии) во всех элементах div1, div2 и div3.

3. Заключает тысячи библиографических ссылок в символы элементов cit, проставляя автоматически правильные значения атрибутов cit/id.

4. Внутри каждого элемента cit проставляет символ года публикации “year”.

Программа кодирования Летописи, имеющая в своей основе Java, активно использует публичный источник gnu.regexp package (http://www.cacas.org/~wes/java/) для отражения регулярных выражений.

• Далее файлы, содержащие выпуски Летописи, подвергаются заключительному ручному редактированию и проверке. На данном этапе исправляются ошибки, выявленные в результате проверки на соответствие требованиям XML, и прочие неточности.

3. Проблемы

3.1. Слишком большой объем данных, слишком мало времени

Одной из основных проблем, с которыми мы столкнулись в ходе реализации проекта, является попытка перевода в цифровую форму громадного объема данных. Наша цель, повторюсь, перевод в электронный формат и кодирование выпусков Летописи за период в двадцать лет. Этот объем соответствует 1040 еженедельным выпускам Летописи, с более чем 250000 страниц и более чем тремя миллионами отдельных библиографических ссылок. Создание цифровых изображений страниц с печатных оригиналов и последующая обработка при помощи OCR прошли относительно гладко и безболезненно в первый год работы по гранту (октябрь 1999 — сентябрь 2000). Трудоемкий процесс кодирования и корректирования текста гораздо болезненнее и поглощает много времени.

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

3.1.1. Компромиссы DTD

Один из компромиссов, на которые мы были вынуждены пойти с целью увеличения производительности, было радикальное упрощение DTD, в особенности содержательной модели библиографической ссылки, заключемой в символы элемента cit (ссылка). Первоначально мы планировали использовать несколько других элементов внутри элемента cit. В частности элемент contributor с атрибутами type, обозначающими авторов, редакторов, иллюстраторов и т.д.; элемент title с атрибутами типа, обозначающими название статьи и журнала; элемент enumeration, в который предполагалось заключать год выпуска и номера страниц статьи в журнале; и элемент notes для прочей информации, содержащейся в библиографической ссылке. Ниже приводятся примеры вариантов кодирования одной и той же ссылки «до» и «после» - с использованием первоначального, более сложного варианта DTD, и нового, упрощенного.

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

<cit id="v56i01c000003"> <contributor type="author">Жаров, А.</contributor> <title>Величие и простота.</title> <notes>[К выпуску изд-вом «Молодая гвардия» сборника «Воспоминания о В. И. Ленине»].</notes> <srcTitle>Новый мир,</srcTitle> <enumeration><year>1955</year>, № 12, с. 232-233.</enumeration> </cit>

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

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

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

Перед нами по-прежнему стоит задача найти идеальную поисковую ситему XML, с тем чтобы она позволяла научный поиск и была применима для цифровых библиотек. Для проекта «Летопись журнальных статей» и других проектов Цифровой Библиотечной Программы университета Индианы, которые, как в приведенном выше примере, сочетают в себе фрагменты текста на современном английском, древнегреческом, иврите и латыни, мы в настоящее время разрабатываем XYZFind (http://www.xyzfind.com/) в качестве нашей основной поисковой системы и базы данных XML. Хотя XYZFind не соответствует некоторым предъявляемым нами требованиям, в частности требованию наличия возможности поиска по словам с учетом изменяющегося окончания, мы в основном удовлетворены его качеством. Разработчики и обслуживающий персонал данного продукта превзошли все ожидания, отвечая на наши запросы и просьбы. Мы надеемся, что все требования, предъявляемые нами, будут учтены к тому времени когда мы вынесем наш проект для общего использования на World Wide Web, что согласно плану должно случиться в следующем году. Нижеследующий параграф из введения к Руководству пользователя XYZFind сервером [XYZFind User’s Guide] дает некоторое представление в отношении функциональности и возможностей XYZFind:

XYZFind это сервер, содержащий XML хранилище информации и XML систему запросов.

Как хранилище информации XML, XYZFind принимает любое количество правильно сформированных XML документов и представляет данные в виде единого документа, вбирающего в себя все получаемые документы. Оригиналы документов могут быть извлечены, изменены или удалены из хранилища. После того как набор документов был проиндексирован XYZFind, становятся доступными поиск и запросы, о которых будет рассказано ниже.

Как система запросов XML, XYZFind принимает запросы, сформированные на языке XML, называемом XYZQL. XYZQL очень богатый по своим возможностям язык запросов, включающий поддержку запросов path-level, запросы булеан, поиск по ключевым словам и запросы по числовым диапазонам. XYZQL система запросов это система фильтрующих ограничений, которая определяет какие конкретно XML документы будут возвращены, а также какие части документов. XYZFind процессор запросов использует свое хранилище для оптимизации процесса фильтрации, превосходя по свом показателям выходных данных менее утонченные подходы.

3.2.2. Редакторы XML

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

Для предыдущих и текущих англоязычных проектов, не требовавших способности поддерживать Unicode, мы использовали emacs с PGSGML главным модулем (http://www.lysator.liu.se/~lenst/about_psgml/), и SoftQuad’s XMetaL (http://www.softquad.com/). С версией 2.1 XMetaL в настоящее время обеспечивает хорошую поддержку Unicode (хотя он не вполне справляется с задачей поддержки языков, читаемых справа налево, в частности иврита) по сравнению с временем, когда мы начали проект в 1999 году, когда поддержка Unicode, предоставляемая ими, была очень ограничена и XMetaL не показывал кириллические тексты Unicode. В качестве дефолтного варианта редактора XML для нашего проекта нами был избран WordPefect ( http://www.corel.com/). Он позволяет редактировать большие документы, имеет привычный для новичков в области XML интерфейс Word и обеспечивает приемлемый уровень поддержки Unicode. Остальные протестированные нами продукты мы решили не использовать поскольку их интерфейс не подходил для целей нашей работы, они либо не обеспечивали поддержку Unicode, либо требовали знания XML выше уровня нанятого нами персонала.

4. Создание интерфейса

Главная задача проекта «Летопись журнальных статей» — обеспечить свободный доступ посредством Web интерфейса к данным за двадцать лет публикации «Летописи журнальных статей», которые мы в конце концов приведем в электронную форму и закодируем при помощи XML. Трудоемкий процесс оцифровывания и кодирования по-прежнему продолжается, но мы уже начали работу по созданию Web интерфейса для данных.

Прототип Web интерфейса, используемый нами в настоящее время, представляет собой комбинацию HTML, Java и JavaScript, связанных с сервером XYZFind. Интерфейс Летописи это страница сервера Java (Java Server Page (JSP)), которая использует Javascript и Java, связанную с HTML, и побуждает локальную JavaBean без памяти о предыдущих результатах поиска к более сложной логике (которая скорее всего в конечном итого будет выделена в отдельную JavaBean). В дополнение к классам XYZFind JSP также использует Xerces для доступа к XML Document Object Model (DOM) и Xalan для Extensible Stylesheet Language Transformations (XSLT) трансформаций.

Динамическое содержание страницы управляется внешне загружаемым JavaScript. Первоначально код JavaScript также сочетался с JSP файлом. Проблемы возникали когда поисковые системы JSP/Servlet неправильно распознавали JSP файлы, когда они содержали нелатинские символы Unicode (еще одна трудность, порожденная Unicode).

Поисковый интерфейс позволяет пользователю вносить слова для поиска и сочетать их с булеаном «И» («Все слова») или булеаном «Или» («Любые слова»), или задавать кокретную фразу для поиска. Кроме того, пользователь может выбирать временной диапазон и предметную область. После того как пользователь выбирает какой-либо предмет поиска первого уровня (div1), страница динамично генерирует список заголовков второго уровня (div2), с уже выбраннным самым первым подзаголовком. Аналогично, как только пользователь выберет какой-либо подзаголовок второго уровня, страница динамично генерирует перечень входящих в него подзаголовков третьего уровня (div3). Если пользователь выбирает только раздел из верхнего уровня (div1) или второго уровня (div2), система запросов произведет поиск по всем div2 и/или div3 предметным категориям, содержащимся внутри выбранного верхнего или второго предметного заголовка. Это позволяет пользователю производить широкий поиск по одному общему предметному заголовку и всем подразделам, которые в нем находятся, либо ограничить поиск до одного определенного предметного подраздела второго или третьего уровня.

Рисунок 1 показывает интерфейс поиска, каким он первоначально предстает пользователю.

Рисунок 1: Поисковый интерфейс Летописи (Первоначальный вид)

На рисунке 2 изображен поисковый интерфейс с выбранным подзаголовком третьего уровня (div3) и другими опциями из меню «Найти» и падающего меню «Период».

Рисунок 2: Поисковый интерфейс Летописи (с изображением большего количества опций)

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

Рисунок 3: Результаты поиска по Летописи

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

Рисунок 4. Результаты поиска по Летописи (с данными на русском и английском языках)

5. Заключение

Проект «Летопись журнальных статей» ставит перед нами ряд значительных трудностей. Самая основная — завершение в срок оцифровки и кодирования большого объема данным, доступ к которым мы решили обеспечить на World Wide Web. Вторая трудность связана с техническими проблемами, присущими тексту на нескольких языках с несколькими задействованным алфавитами, с учетом того, что инструменты XML на сегодняшний день предоставляют поддержку Unicode, оставляющюю желать лучшего. Мы были вынуждены идти на компромиссы в целях преодоления этих трудностей, но мы уверены в том, что в итоге мы будем в состоянии предложить научному сообществу чрезвычайно ценный исследовательский инструмент и обеспечить сохранение интеллектуального ресурса, который в настоящее время находится на грани исчезновения. И в процессе выполнения этой важной научной миссии мы приобретем ценный опыт, который позволит нам и другим специалистам приниматься за осуществление более амбициозных научных проектов, пользующихся преимуществами огромного потенциала XML и других современных информационных технологий.

Библиография:

[IU DLP] Indiana University Digital Library Program. 23 August 2001. Indiana University. 14 October 2001. http://www.dlib.indiana.edu/.

[LZhS Web] Letopis' Zhurnal'nykh Statei Project. Indiana University Digital Library Program. 14 October 2001. http://www.dlib.indiana.edu/reference/letopis/

[XML 1.0] "Extensible Markup Language (XML) 1.0 (Second Edition)." Ed. Tim Bray et al. Vers. 1.0 (Second Edition). 6 October 2000. World Wide Web Consortium (W3C). 14 October 2001. http://www.w3.org/TR/2000/REC-xml-20001006

[XYZFind User's Guide] XYZFind Server User's Guide. PDF. Vers. 2.0. September 2001. XYZFind Corporation. 14 October 2001. http://www.xyzfind.com/

Цитата:

Walsh, John. Creating an XML-Based Scholarly Research Tool: Challenges and Methodology. XML Conference & Exposition 2001 (December 2001) < http://www.idealliance.org/papers/xml2001/papers/html/03-04-06.html>.

Перевод:

Переведенный с Английского языка Natalia Rome-Lindval

Content

Уолш Джон Создание инструмента научных исследований на основе XML: Проблемы и методология

Создание инструмента научных исследований на основе XML: Проблемы и методология Представленный John Walsh В XML Конференция В Орландо, Флорида, 9-14 декабря 2001

1. Введение

1.1. О проекте

1.2. Мотивы осуществления проекта

1.3. Структура «Летописи журнальных статей»

1.4. DTD «Летописи журнальных статей»

2. Процесс оцифровывания

3. Проблемы

3.1. Слишком большой объем данных, слишком мало времени

3.1.1. Компромиссы DTD

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

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

3.2.2. Редакторы XML

4. Создание интерфейса

5. Заключение

Библиография: