Технология построения многовариантных объектно-ориентированных структур текстов
Вид материала | Диссертация |
- Ландшафт области управления данными: аналитический обзор, 531.27kb.
- Развитие объектно-ориентированных систем управления базами данных, 122.52kb.
- Лекция № Элементы управления в графических и объектно-ориентированных интерфейсах, 307.9kb.
- Сводный научный отчет за 2010 г по совместному проекту «Разработка объектно-ориентированных, 204.3kb.
- Врамках настоящей работы на примере четырех произведений будут рассмотрены некоторые, 228.04kb.
- Программа вступительного экзамена по специальности 05. 13. 18 Математическое моделирование,, 115.33kb.
- Рабочая программа учебной дисциплины (модуля) Объектно-ориентированное программирование, 99.17kb.
- Исследование организационных структур управления, 469.08kb.
- Темы: Введение в язык rsl, 123.68kb.
- Программа дисциплины Объектно-ориентированное программирование Рекомендуется для направления, 591.42kb.
Вариант алгоритма с полным перебором всех шаблонов и позиций для их применения не годится для задач обработки больших объемов исходных данных. В качестве примеров таких задач можно назвать следующие:
- Построение полной объектной модели некоторого словаря, тезауруса, справочника, в качестве входа рассматривая его печатное представление в виде текста;
- В том или ином виде проверка правописания (орфография, пунктуация) больших текстов на естественном языке;
- Обработка большого массива правил некоторой продукционной системы (например, машинного переводчика) — в таких системах большое количество правил обычно обусловлено необходимостью повысить точность работы системы;
- Поиск информации в больших объемах данных, например, в технической документации — это может быть конструкторская или эксплуатационная документация на сложные изделия типа самолетов;
Можно также использовать ТОМАТ преимущественно как технологию хранения данных (при этом возможность анализа является второстепенной). Для этого всего лишь достаточно разработать эффективную подсистему персистентности системы объектов (например, на основе индустриальной СУБД).
В то же время для перечисленных задач требуется полное построение структуры входного текста, и требуется обеспечение такой же семантики работы планировщика, как если бы он работал полным перебором. Таким образом, мы приходит к необходимости рассмотрения возможности оптимизировать алгоритм полного перебора, не затрагивая результатов его работы.
Разумеется, можно предложить множество подходов, но один из них заслуживает особого внимания ввиду относительной простоты реализации и значительной пользы от его применения. Такой подход, точнее, алгоритм, положенный в его основу, был назван "виртуальной машиной графов" (ВМГ). Рассмотрим его подробно.
Взаимосвязь между шаблонами представляется ациклическим графом: на входе графа имеем системные шаблоны (объекты которых приходят от препроцессора), на выходе - самые сложные целевые шаблоны (то есть шаблоны классов, построение объектов которых является целью анализа текста). Дуга из шаблона X в шаблон Y означает, что шаблон X входит в качестве узла в шаблон Y. При этом X может входить в Y в качестве обязательного узла или альтернативного узла, т.е. узла одного из нескольких шаблонов, соответствующих данному узлу шаблона Y.
Очевидно, что ^ Y можно не проверять в тексте (фрагменте системы объектов) T, если в T хотя бы у одного из узлов Y или у всех альтернативных шаблонов нет объекта обязательного узла X.
Таким образом, для контроля применимости шаблонов можно использовать черно-белый и/или ориентированный граф , вершины которого взаимно однозначно соответствуют шаблонам, а дуги представляют связи между ними. Черный цвет присвоен вершинам, исключенным из на данном этапе процесса, в ходе которого множество исключенных монотонно растет (в начальном состоянии все вершины белые).
Для работы над определяется виртуальная машина ВМГ, базовой операцией которой является исключение из произвольной вершины (шаблона) А. Эта операция имеет для следующие последствия:
1. Исключаются все дуги, как исходящие из А, так и входящие в нее;
2. Исключаются те вершины следующего уровня, у которых А является обязательным узлом или последним из оставшихся альтернативных узлов;
3. Исключаются нецелевые вершины, у которых исключены все исходящие из них дуги.
Исключаемые вершины включаются во множество ^ М, к вершина которого в любом порядке применяется базовая операция. Та вершина, для которой выполнено последствие 1, получает черный цвет и исключается из М. Процесс останавливается, если М пусто.
Команды об исключении той или иной вершины (вершин) поступают в ВМГ извне, а она выполняет как саму команду, так и все ее следствия. Таким образом, ВМГ является частью ассоциативного аппарата, который работает с графом , постоянно сужая множество активных шаблонов, а, следовательно, и проверяющих их правил.
Причиной внешней команды "исключить вершину (шаблон) ^ А" может, в частности, быть:
- Отсутствие в тексте (фрагменте текста) хотя бы одного объекта шаблона А
- Отсутствие смежных объектов у шаблонов-аргументов шаблона А
ВМГ представляет собой грубый фильтр, отсеивающий те шаблоны, проверка которых не имеет смысла ввиду отсутствия у них полного набора аргументов-узлов. Оставшиеся "белые" шаблоны могут быть объектом следующих фильтров, проверяющих аргументы на некоторую часть условий правила: например, на условия порядка, непосредственное соседство и т.п. (например, объекты, соответствующие узлам, есть, но не в том порядке или не соседи и т.д.).
- ^ Рекурсивное применение шаблонов
Во многих продукционных системах, допускающих рекурсивное использование нетерминалов грамматики, возникает проблема, а точнее, явление неограниченной рекурсии (так как далеко не всегда это является проблемой). Проблема заключается в том, что анализатор может начать неограниченно применять к некоторому участку цепочки правила из одного и того же набора, сделав таким образом процесс анализа бесконечным.
Само по себе наличие в продукциях рекурсивного обращения к нетерминалам не является достаточным условием бесконечности процесса анализа, так как фрагмент входной цепочки, к которому применяются правила, может монотонно укорачиваться в силу конструкции самих правил. В системах с дополнительными ограничениями, к которым, безусловно относится ТОМАТ, остановить рекурсию может и развитие контекста ограничений, например, постепенное доуточнение значений полей.
В ТОМАТе эта проблема весьма существенна, так как возникновение неограниченной рекурсии приводит к строительству "башен" неограниченной высоты вместо деревьев — система объектов начинает неограниченно расти, отбирая ресурсы и не производя полезной работы. Разумеется, такого поведения системы следует избегать. Сделать это можно разными способами. В предлагаемой технологии не дается однозначного ответа на эту проблему. Предлагается два подхода, причем выбор рекомендуется производить исходя из конкретного класса задач.
Первое решение проблемы заключается в следующем. Предлагается запретить конструировать шаблоны, способные привести к неограниченной рекурсии. Например, таким шаблоном будет шаблон класса A, единственный узел которого указывает на класс, объект которого может быть сконструирован хотя бы косвенным применением шаблона, содержащего единственный узел класса A. На этапе проектирования системы классов и шаблонов можно запрещать такие шаблоны (на самом деле, это следует делать в компиляторе проекта).
Другое решение более сложное, но позволяет ограниченно применять рекурсию с последовательным доуточнением значений полей. Оно состоит в динамическом, на этапе исполнения, контроле рекурсии. Собственно проблема появляется тогда, когда на вершине некоторого дерева формируется объект, совпадающий либо расширяющий по множествам данных некий объект, ранее уже созданный в той же ветви дерева. Планировщик может запретить дальнейшее применение определенных шаблонов именно для данного дерева. Отметим, что вряд ли такое решение будет эффективным.
Ни в одной из задач, рассматривавшихся при подготовке данной работы, не возникало необходимости в динамическом разрешении данной проблемы, поэтому можно считать рекомендацией статический, на этапе компиляции проекта, запрет на использование "опасных" рекурсивных шаблонов. Подчеркнем еще раз, что не всякое рекурсивное упоминание класса шаблона в одном из его узлов, пусть даже косвенно через шаблон класса узла, приводит к возможному зацикливанию процесса анализа.
- ^ Полуавтоматический планировщик
Большинство работ, посвященных различным проблемам анализа текстов, как правило, предлагают решения, ориентированные на автоматическую обработку текстов. Однако, если внимательно присмотреться к задачам из области искусственного интеллекта, решения которых нуждаются в автоматизации, то можно увидеть широкий класс задач, для которых вполне подошли бы автоматизированные, а не автоматические решения.
Рассмотрим, например, задачу распознавания словаря, заключающуюся в построении его представления, основанного на объектной модели. Обычный способ индустриального решения данной задачи состоит в том, чтобы найти эксперта (исполнителя), который практически вручную, используя как максимум некоторые возможности текстового процессора, будет обрабатывать текст словаря, данный ему в форме электронного документа, предназначенного, вообще говоря, для бумажного представления. Целью работы эксперта в этом случае является получение описания конкретного словаря на некотором языке, приспособленном для публикации словаря в электронной форме. Этот язык описывает структуру словаря на некотором уровне. В большинстве коммерческих электронных словарей применяется многоуровневый подход. Сначала эксперт строит представление на языке, отражающем логическую структуру словаря (оперируя такими терминами, как словарная статья, часть речи, вариант перевода и т.п.). Затем некий компилятор этого языка порождает представление словаря на другом языке, обычно непосредственно используемом для публикации — этот язык интерпретируется приложением, предоставляющем конечному пользователю возможность работы со словарем. Этот язык оперирует абстракциями более низкого уровня (помета, примечание, заглавное слово и т.п.).
На неавтоматизированное решение такой задачи для словаря среднего объема обычно уходит около месяца. Конечно, труд эксперта является в большой степени рутинным, и возникает желание его автоматизировать. На самом деле полностью автоматическое решение может на практике и проигрывать автоматизированному. Часто лучше один день потратить на подготовку системы классов и шаблонов, и затем два дня на их полуавтоматическое применение, чем две недели разрабатывать полностью автоматическую систему. На практике объем материалов для распознавания вполне конечный, и расходы на полную автоматизацию редко окупаются.
Просто покрыть представление бумажного словаря в виде электронного документа некоторой формальной грамматикой не удается. Понятно, что это было бы идеальным решением. Но текст документа (как и его автор) не всегда последователен в оформлении тех или иных структурных элементов, в тексте встречаются ошибки. Да и сама структура словаря приспособлена для восприятия человеком (например, оригинал и перевод обычно даже не разделены ничем, кроме пробела).
Предлагаемая технология может автоматизировать этот процесс. Можно построить систему классов и шаблонов, распознающую текстовые конструкции словаря, и, в конечном итоге, строящую систему объектов, соответствующих понятиям формального языка, на котором требуется получить представление словаря.
Сложность возникает с тем, что в исходном обрабатываемом тексте обязательно найдутся исключения из правил, положенных в основу построения системы классов и шаблонов. Это происходит как благодаря опечаткам, так и некоторым не до конца формализованным конструкциям, редко, но все-таки встречающимся в исходном тексте.
Вообще с подобной проблемой можно бороться тремя способами. Первый предполагает колоссальное усложнение системы классов и шаблонов так, чтобы она покрыла все вновь встречающиеся сложные случаи. Этот путь напоминает попытки полностью покрыть некоторой формальной грамматикой структуру естественного языка. Практика показывает, что подобный способ не позволяет приблизиться полноте описания более, чем на 95% (цифра очень приблизительная, и, по скромному мнению автора, характерна практически для всех известных автоматических решений задач искусственного интеллекта). Второй путь заключается в многократных попытках применять одну и туже грамматику, пытаясь вносить "исправления" в исходный текст при каждой неудаче в применении подходящих правил. Этот способ дает уже не автоматическое, а автоматизированное решение проблемы, но также далек от идеала, так как не все можно обойти изменениями исходного текста — многие неприятности начинаются на более высоких уровнях абстракции.
Предлагается и третий способ, предполагающий использование технологии "ТОМАТ" — создание специального автоматизированного планировщика. Такой планировщик будет иметь некий интерфейс пользователя, предлагая применить правила из определенной группы. Для ТОМАТа это означает, что пользователь может выбрать группу классов и шаблонов (например, отметив соответствующие банки), и запустить автоматический планировщик, например, действующий (возможно оптимизированным) методом полного перебора. После завершения работы этого планировщика, пользователю предоставляется возможность отредактировать построенную систему объектов. Для этого в действия системы классов и шаблонов добавляется установка информационных флагов, оформленных в виде полей классов, означающих ошибку либо предупреждение. Флаги устанавливаются при применении соответствующих шаблонов. Пользователь должен иметь возможность с помощью интерфейса пользователя производить поиск объектов, помеченных этими флагами, и вручную корректировать проблемы. После этого пользователь может проводить дальнейшую обработку, применяя другие банки классов и шаблонов.
Описанный подход был апробирован и продемонстрировал отличные результаты для решения задачи распознавания структуры словарей, о чем рассказано в главе, посвященной базовой реализации.
- ^ Специальные модифицирующие планировщики
В этом подразделе предлагается еще один подход к построению планировщиков, специфичных для некоторого класса решаемых задач. А именно, предлагается расширить набор операций, которые выполняет планировщик.
Описание технологии "ТОМАТ", данное ранее, предполагало, что планировщик занимается построением деревьев объектов, вызывая исполнитель для применения тех или иных шаблонов в нужном месте системы объектов. При этом планировщик определяет стратегию обхода как объектов, так и шаблонов. Но если шире посмотреть на потребности обработки данных во многих прикладных программах, то можно увидеть, что иногда большая эффективность может быть достигнута за счет расширенных манипуляций с системой объектов. В основном предлагается разрешить планировщику удалять объекты, заменять одни на другие, и т.п. Указанием на необходимость проведения той или иной операции могут быть значения специальных поля классов, которые планировщик распознает по имени. Рассмотрим подробнее набор операций, предлагаемых для такого рода планировщиков.
- ^ Удаление дочерних объектов
При создании нового объекта вместо того, чтобы делать покрытые объекты дочерними, они просто удаляются из системы, и на их место помещается создаваемый объект. Дочерние объекты могут как становиться дочерними для вновь созданного, так и удаляться вместе с покрытыми — это дает еще два варианта этого пункта.
- ^ Виртуальное применение шаблона
В этом случае все выполняется как обычно при применении шаблона, но новый объект не создается, хотя все действия, в том числе указанные в классе шаблона, выполняются. Смысл этого варианта в том, чтобы только доуточнить или иным образом модифицировать данные в покрываемых объектах. Разумеется, модификация не произойдет, если не выполнится хотя бы одно ограничение, так как в ТОМАТе всегда действует принцип: если нарушены достаточные условия применимости шаблона, то есть исполнитель выдает отрицательный ответ, то система объектов остается нетронутой.
- ^ Выборочное удаление, изменение порядка объектов и т.п.
Решение о проведении тех или иных операций может быть принято в действиях и отражено в значении специально распознаваемых планировщиком служебных полей.
Планировщик, использующий эти приемы, должен аккуратно следить за многовариантными структурами, так как операции модификации существующих объектов могут привести к нарушению ранее справедливых ограничений. Возможна как их повторная проверка, с отменой (удалением) ранее созданных объектов, так и установка предупреждающих флагов (для полуавтоматического планировщика).
- ^ Предлагаемый метод анализа текстов
- Модель классов и шаблонов
- Модель классов и шаблонов
В этом разделе детально описывается принятая в технологии "ТОМАТ" концепция классов, шаблонов и их составляющих (все это так называемые сущности ТОМАТа), используемых при анализе данных.
- ^ Язык ТОМАТа
При описании сущностей ТОМАТа приходится иметь дело с двумя языками. Первый - это язык, на котором описывается система сущностей ТОМАТа. В базовой реализации для этого используется язык XML, в этом случае структура этих сущностей может быть описана с помощью грамматики в виде XML DTD, что и сделано в главе, посвященной базовой реализации. Второй - это язык, требования к которому определяются в настоящем разделе, который используется в строковых полях сущностей ТОМАТа и называется языком ТОМАТа. Он служит для формулирования ограничений по данным при создании объекта, для формирования значений полей создаваемых объектов, и вообще для записи любых действий в сущностях ТОМАТа.
Появление "языка в языке" было обусловлено необходимостью предоставить гибкие средства конструирования выражений над полями объектов (экземпляров классов), а также желанием сделать описание структуры классов и шаблонов независимым от языка действий. Это дает возможность реализациям, поддерживающим технологию "ТОМАТ", по-своему определять представления для классов и шаблонов, принимая предложенный в базовой реализации синтаксис языка ТОМАТа, либо, наоборот, вводить только альтернативный язык описания действий, принимая имеющуюся структуру классов и шаблонов.
Поля сущностей ТОМАТа, использующие язык ТОМАТа, представляются в виде строк, возможное содержимое которых описывается приводимыми в спецификации языка ТОМАТа продукциями грамматики. Строки на языке ТОМАТа обрабатываются компилятором языка ТОМАТа, который переводит их в соответствующее внутреннее представление, обеспечивающее эффективную обработку данных по технологии "ТОМАТ". Синтаксис языка ТОМАТа, приведенный в описании базовой реализации, используется и в этой главе для примеров. Многие из этих обозначений языка ТОМАТа заимствованы из языка Паскаль (за исключением, прежде всего, чувствительности к регистру букв — базовая реализация различает регистр во всех случаях).
Строка, которую получает на вход компилятор, подвергается лексическому анализу (представляется в виде списка лексем), затем производится генерация промежуточного представления (с помощью синтаксического анализатора), оптимизация, и, наконец, генерация внутреннего представления, которое используется при вычислениях в процессе обработки данных.
Этап оптимизации является существенным, как будет видно в дальнейшем при рассмотрении операторов языка ТОМАТа, так как позволяет эффективно производить вычисления со скалярными данными, являющимися частным случаем недоопределенных.
- ^ Структура сущностей ТОМАТа
В этом подразделе перечисляются сущности ТОМАТа и приводится их структура.
Как уже отмечалось, для обеспечения возможности модульной работы с описанием предметной области в виде системы классов и шаблонов, в ТОМАТе вводится понятие банка классов и шаблонов. Каждый банк непосредственно включает в себя различные сущности ТОМАТа, называемые глобальными, а они, в свою очередь, могут состоять из других сущностей ТОМАТа, называемых локальными. Принято, что банки образуют систему путем указания в каждом банке, какие другие банки он использует. При этом в любом банке будут доступны имена глобальных сущностей из банков, которые он использует. Также будут доступны имена локальных сущностей в соответствующих контекстах. Все имена полей некоторого класса, включая унаследованные поля, доступны во всех контекстах, где доступен сам класс.
Система банков ТОМАТа напоминает систему модулей в языке Турбо Паскаль. Правила видимости имен сущностей в языке ТОМАТа были выбраны аналогичными Турбо Паскалю. Существовала альтернатива — рассматривать использование банка другим банком как включение всех сущностей из используемого банка в начало использующего, аналогично традиции использования директивы #include в языках C и C++. Но такой подход был признан неудачным для ТОМАТа, так как появляется проблема случайного переопределения в новом банке некоторого имени из глубоко вложенного банка с "тихим" изменением смысла программы.
Следует различать случай, когда некая сущность ТОМАТа ссылается на другую сущность по имени, и случай, когда сущность является составной частью другой. В этом разделе при рассмотрении структуры сущностей о ссылках по имени говорится явно, указания же на списки сущностей как составляющую некоторой сущности подразумевают списки вложенных сущностей.
Все имена, встречающиеся не в строках на языке ТОМАТа, а в полях сущностей ТОМАТа, являющихся ссылками на другие сущности ТОМАТа, кроме имен банков в списке используемых банков, могут быть квалифицированы именем банка из числа используемых текущим банком. В базовой реализации в качестве обозначения такой квалификации был выбран способ добавления к имени сущности префикса из имени банка и двоеточия (если имя банка перед двоеточием опущено, то подразумевается имя текущего банка). В этом случае сущность должен находиться именно в указанном банке.
Использование квалификатора банка с опущенным именем банка (просто двоеточие) позволяет ограничить поиск сущности текущим банком, не проверяя используемые им банки. Хотя текущий банк и так имеет приоритет при поиске имени, подобная квалификация позволяет застраховаться от ошибки, когда сущность забыли описать в текущем банке, а один из используемых предлагает некую сущность с тем же именем.
Названия составных частей сущностей приведены также и на английской языке, эти названия используются в базовой реализации. Отметим, что английское название "PClass" для классов ТОМАТа является сокращением от "pattern class" — "класс шаблона".
Названия сущностей, имеющих имя — строковый атрибут "имя" (name) — подчеркнуты.
- Банк (Bank)
Банк состоит из списка имен используемых банков (UsedBanks), а также списков доменов (Domains), констант (Constants), классов (PClasses) и шаблонов (Patterns).
- Домен (Domain)
Домен состоит из списка токенов (Tokens).
^ Домен — это аналог перечислимого типа в языке Паскаль.
- Токен (Token)
Токен задается только своим именем.
Хотя формально токен и является глобальной сущностью ТОМАТа, он не имеет соответствующего ему элемента XML и в реализации скорее всего не будет представлен классом языка программирования.
- ^ Константа (Constant)
Константа определяется константным выражением на языке ТОМАТа — значением (Value). Тип константы автоматически выводится при вычислении константного выражения на этапе компиляции.
- ^ Класс (PClass)
Класс хранит список имен базовых классов (BaseClasses), состоит из полей (Fields) и может содержать действие (Action).
- Поле (Field)
Поле состоит из константного выражения на языке ТОМАТа — значения по умолчанию (DefaultValue) и действия (Action), задающего ограничение на возможное значение поля. Для поля также указывается его тип (DataType) — имя типа согласно продукции, приведенной в описании языка ТОМАТа, которое может быть квалифицировано именем банка (см. раздел о пространствах имен). Если значение по умолчанию опущено, то предполагается полное множество (полная неопределенность) соответствующего типа.
Указание типа поля в самом поле можно было бы отменить, потребовав обязательного указания значения по умолчанию (по которому всегда на этапе компиляции можно вычислить тип). Но явное указание типа позволяет лучше обнаруживать ошибки в выражениях, задающих значения по умолчанию.
- ^ Шаблон (Pattern)
Шаблон хранит имя класса и состоит из узлов (Nodes) и действий (Actions). Имеет флаг "включения" (Enabled), сброс которого делает невозможным применение шаблона (выключает шаблон из рассмотрения).
- Узел (Node)
Узел хранит имя класса (PClass) и содержит действие (Action). Класс, на который ссылается узел, имеет следующий смысл: объект именно этого класса, если установлен флаг "строгий тип" (StrictType), или в том числе производного, если не установлен флаг "строгий тип", может быть покрыт узлом в процессе применения шаблона, содержащего узел. Атрибут узла "вид контекстности" (ContextKind) указывает, является ли узел обычным неконтекстным (None), контекстным с положительным контекстом (Pos), либо контекстным с отрицательным контекстом (Neg). Также в узле указывается минимальное (MinCount) и максимальное (MaxCount) количество последовательных объектов, которые могут быть покрыты данным узлом при применении шаблона. Узлы, у которых MinCount=0, называются опциональными, узлы с MaxCount>1 называются множественными (эти категории узлов, очевидно, не являются взаимоисключающими), в противном случае (MinCount=MaxCount=1) узел называется одиночным.
Семантика работы с опциональными и множественными узлами является нетривиальной в отличие от семантики одиночных узлов. Наличие в технологии "ТОМАТ" поддержки множественных и опциональных узлов делает механизм шаблонов функционально эквивалентным регулярным выражениям (если в регулярном выражении используются скобки для группировки конструкций, то подвыражение в скобках образует некий концепт предметной области, следовательно, ему должен соответствовать класс ТОМАТа и шаблон этого класса, который представляет подвыражение).
- ^ Действие (Action)
Действие имеет текст (Source), записываемый на языке ТОМАТа и может содержать как ограничения (условия) на создание объекта, так и присваивания значений полям объекта. Действие состоит из одной или нескольких инструкций языка ТОМАТа (инструкции описаны в следующем разделе).
Как видно из приведенного описания, действия могут находиться в различных сущностях, так или иначе относящихся к шаблону. В принципе, можно было разрешить действия только для шаблона и не разбивать их на действия в узле и классе. Но такое разбиение позволяет группировать действия в соответствии с их семантикой.
В дополнение к изложенному необходимо пояснить, что подразумевается под наследованием классов в технологии "ТОМАТ". Класс, производный от некоторого базового, наследует все поля базового класса, как если бы они были объявлены в нем самом, включая все поля, унаследованные базовым классом от его базовых. В случае, если имя некоторого унаследованного и введенного в самом классе поля совпадет, поля все равно различаются — для выбора конкретного поля может использоваться квалификация (см. ниже).
Допускается указать в числе базовых некий класс, и так являющийся базовым в силу того, что его производный класс уже входит в список базовых. Такое указание не влияет на семантику.