Проект Диалинг
В данном подразделе дано краткое описание модулей автоматической обработки текста и морфологических словарей, разработанных рабочей группой Aot.ru [29]. Изначальный проект, посвящённый разработке русско-английского машинного перевода, назывался Диалинг. Разработанный процессор Диалинг включает графематический, морфологический и синтаксическим модули. Программная реализация процессора выполнена на языке C++. «Неоспоримым достоинством процессора Диалинг является его завершённость: программная реализация доведена до уровня промышленного использования, – система характеризуется приемлемой скоростью анализа и устойчивостью на открытом пространстве реальных текстов» (цит. по [24]).
Морфологический словарь, или лексикон, содержит все словоформы одного из языков: английского, немецкого или русского. Словарь предоставляется в двух вариантах: с возможностью редактирования и в бинарном варианте. Оболочка редактирования словаря позволяет выполнять: поиск в словаре по лемме, словоформе, морфологической интерпретации, редактирование словаря. Словарь в бинарном формате предоставляет возможность выполнять: морфологический анализ (получение по словоформе леммы, её свойств, уникального ID леммы, морфологических характеристик входной словоформы1 и морфологический синтез (получение по уникальному ID леммы всей парадигмы слова со всеми словоформами и их морфологическими характеристиками). Бинарное представление словаря оптимизировано для проведения морфологического анализа. Основу этого представления составляет конечный автомат. Работает морфологическое предсказание слов, отсутствующих в словаре [29], [51].
В Институте лингвистики РГГУ авторами [17] предпринята попытка разработки модуля автоматического синтаксического анализа (АСА) русского текста. Автоматический синтаксический анализ в данном случае рассматривается ими как самостоятельная составная часть системы автоматического понимания естественноязыкового текста, работающая после модулей графематического и морфологического анализа и перед модулем семантического анализа текста. Для этой цели А.М. Баталиной и М.Е. Епифановым создана специальная программная среда ЭСЛА. Предложенный авторами [19] модуль синтаксического анализа является частью анализатора текста русского языка SMART (на нынешний момент разрабатывается), ориентированного на грамматический разбор текстов на литературном русском языке.
Резюме
Достаточно объемный материал, приведенный в историко-библиографическом обзоре, позволяет детально оценить уровень научно-технического развития главных направлений компьютерной лингвистики, который для некоторых из этих направлений можно считать высоким. Но все же следует отметить, что революционных разработок, позволяющих добиться значительных успехов в каких-либо направлениях, очень мало. Это относится и к такому специфическому направлению, как визуализация компьютерно-лингвистических систем. Существующие универсальные средства поддержки визуализации не могут удовлетворить потребности пользователей в изучении новых модельных сущностей, обладающих не до конца ясными свойствами, или требуют от пользователя для представления этих сущностей слишком больших усилий.
В то же время в учебниках, справочниках и словарях по визуальному программированию однозначно констатируется, что даже наиболее популярные системы типа Visual C, Visual BASIC и Delphi, которые осуществляют визуальную поддержку процесса объектно-ориентированного проектирования и программирования, не могут претендовать на звание классических систем визуального программирования, несмотря на распространение такого наименования. Опыты формализации визуальных языков показывают отсутствие значимых результатов для реальных проектов. Следовательно, необходима разработка специализированных систем визуализации, при проектировании которых максимально учитываются нужды конкретных пользователей, решающих конкретный класс задач. Одной из важнейших задач проектирования является обеспечение прагматических свойств систем визуализации, которые должны оцениваться с субъективных, пользовательских позиций. В связи с этим можно сформулировать субъективный, ориентированный на пользователя подход к проектированию специализированных систем визуализации. Уже указывалось, что выделяются три аспекта разработки систем компьютерной визуализации - собственно компьютерная графика, инженерия программного обеспечения и набор “человеческих”, когнитивных факторов, связанных с проблематикой мышления и восприятия пользователя. В связи с нашим подходом в данном исследовании значительное внимание уделяется именно когнитивной составляющей. Два других аспекта, обеспечивающие адекватность в визуализации, воплощены в нашем исследовании в составе технических и программных средств на основе разработанных программных модулей, которые можно использовать автономно для полуавтоматического определения тематики текстовых массивов на языке, близком к естественному.
Глава II. РЕЗУЛЬТАТЫ СОБСТВЕННЫХ ИССЛЕДОВАНИЙ
Особенности решения задачи с текстовыми условиями
Созданные нами в ходе выполнения работы программные компоненты предназначены для работы с текстовыми исходными данными с использованием методов частичного морфологического и синтаксического анализа на основе правил, не использующих развёрнутые словари английского языка, с интерактивным (полуавтоматическим) созданием требуемых списков слов. Код указанных компонентов написан на языке программирования C++ (среда Microsoft Visual Studio 8.0) для ЭВМ с операционными системами семейства Microsoft Windows NT.
Правильность работы программы можно проверить с помощью примеров исходных данных, указанных далее.
1.1. Время
Допустим, что решается задача моделирования какого-то явления, и имеется текст, описывающий это явление (а возможно, и другие источники информации: изображения, чертежи, видеозаписи). В этом случае, если возможно, следует объединить всю имеющуюся информацию, которую можно будет использовать.
Введем модель явления, которая будет использоваться в CFVR.
Выделим пространство всех представлений моделируемого явления (назовем его Root), которые потребуются, и введем измерение времени (Timeline) (Рис.1).
Как относятся эти введенные понятия? Можно ли сказать, что Timeline не зависит от других измерений, которые могут быть в Root?
Для простоты предположим, что нет, не зависит. В случае если происходят явления, содержащие зависимость времени, по возможности выполним действия, заменяющие эти явления похожими, но не содержащими таких зависимостей.
Вообще, это возможно не всегда.
Примеры.
“Then I noted the clock. A moment before, as it seemed, it had stood at a minute or so past ten; now it was nearly half-past three!” [58] – т.к. указано слово «показалось», можно интерпретировать действие машины, например, как «замораживание» путешественника на некоторое время, такое, что замедляется скорость восприятия.
«Волшебник замедлил ход времени для всех, кроме себя» - интерпретировать это как внезапное ускорение всех процессов, не связанное со временем.
«Армия роботов переместилась назад во времени» - тяжело представить в модели: например, вставим между началом и концом перемещения новый промежуток, по длине равный «расстоянию во времени». Считаем, что этот промежуток времени требуется для того, чтобы вернуть пространство в исходное состояние… (зависимость времени исчезла).
«Космический исследовательский крейсер Орион плыл в гиперпространстве. Впрочем, слово «плыл» не совсем уместно. В гиперпространстве нет понятий времени, расстояния и даже массы. Человек не может представить этого» [4] – процесс перемещения, в котором задействовано время, не удастся описать в модели, где Timeline обозначает время. Но, если Timeline будет обозначать какую-то величину, которая монотонно возрастает во время такого «перемещения», а остальные могут быть интерпретированы как величины, зависящие от нее, то, возможно, модель может каким-либо образом помочь.
Теперь: с учетом модели будем описывать явления такими диаграммами:
Далее, Root может потребоваться рассматривать с точки зрения разных моделей.
Такие «представления» Root (назовем их «World» - мир) могут содержать некоторую информацию, которая может представлять то же, что другие, а может – какую-то другую информацию.
В отличие от Root, все его части на диаграмме, в т.ч. представления, могут относиться не ко всей линии времени, а только к части, или к одному моменту на ней. Для этого введем деление линии времени.
Будем обозначать некоторый момент на линии времени (возможно, еще не определенный), «маркером времени» (рис.2).
В их числе будут вспомогательные «маркеры бесконечности», которые нужны для того, чтобы задавать бесконечные промежутки. Обозначим их « -I », « +I » (Рис.3).
Пусть все маркеры, кроме –I, +I пронумерованы. Промежутки будем задавать так:
« 1 . 2 » - время после маркера 1, до маркера 2, если такое существует.
« 2 . I » - время от маркера 2 и до +I.
« I . 2 » - время от –I до маркера 2.
« 2 . 2 » - момент под маркером 2.
Деление пространства
Теперь, рассмотрим состояние Root в определенный момент времени. В пространстве распределено что-то, что вызывает те явления, которые нужно описать в задаче. Значит, все это на диаграмме должно входить в World непосредственно, или в какие-то его части (Рис. 4, 5, 6). Причем, т.к. оно тоже может оказаться состоящим из частей, то следует по возможности описывать объекты и их группы похожим образом.
Поэтому, будем добавлять описания частей World как узлы дерева, в котором обозначение World будет корнем, по мере того, как они будут определяться. В общем случае, получившийся мировой граф может перестать быть деревом (из-за того, что один узел будет рассматриваться как часть нескольких узлов-групп).
Теперь рассмотрим другие моменты времени. Если новый момент времени позже рассмотренного, то, вероятно, мировое дерево будет похожим на уже составленное. Поэтому имеет смысл описывать изменения в дереве как операции над ним. Если их описание будет таким, что после любой такой операции можно будет выполнить обратную операцию, приводящую к исходному дереву, то можно будет использовать моменты будущего в описании прошлого.
Назовем узлы мирового дерева структурами.
Наконец, если имеются какие-то мировые деревья для всех маркеров времени (это выполняется в любом случае, даже если они одинаковые или не содержат потомков World), то при анализе новых условий можно интерпретировать их как «ограничения», условия на узлы дерева (причем сначала как ограничения на корневой узел, «Root»).
Уточнения, связанные с естественными языками
Как будут выглядеть эти ограничения, например, если входными данными был текст на английском языке?
Существительные английского языка могут описывать объекты (стол, облако, шарнир), и просто явления (дождь, дружба). Анализатор может не знать слово, которое определяется прямо в тексте, поэтому имеет смысл считать существительные, задающие объекты, подклассом всех существительных, задающих явления.
Если в тексте описаны чьи-то действия, то упоминание производящих действия будет сильно отличаться от упоминания других объектов; это не означает, что предложение «Механик оказался на станции измельчения руды» не похоже на предложение «На станцию измельчения руды приехал вагон угля». Но в случае субъектов могут быть дополнительные указания на смысл происходящих явлений, связанные с внутренним миром субъекта (которые, однако, нет смысла описывать внутри того же World: ведь они часто происходят с абстрактными понятиями, которые не сильно связаны со структурой основного пространства. Именно для этого нужны дополнительные представления).
Однако, по вышеуказанным причинам, описания субъектов должны быть подклассом описаний объектов.
Далее, смысл, в частности, глаголов, может стать для анализатора более понятным, если известно, в каком подклассе лежит существительное, к которому он относится. И здесь важны не только подклассы объектов и субъектов. Поэтому введем «дерево категорий» - всех полезных в задаче подклассов.
Подклассы будут вводиться по мере подготовки к решению задачи или самого процесса решения.
Сразу же определим особенности глаголов в том же дереве категорий следующим образом: для корневой категории явлений (которая называется Template) определим наиболее общие значения; значения, определенные в потомках, будут применяться к соответствующим подклассам (хотя, в этом случае будет учитываться возможность выбора любого значения из классов-предков, так как это иногда необходимо). Будем рассматривать простое употребление глагола и употребление глагола с модифицирующим предлогом (модификатором) (напр, «go» и «go for»), как употребление разных глаголов, учитывая при этом, что предлог после глагола может не быть модификатором.
Далее, рассмотрим «NP-объект» - конструкцию из артиклей, числительных, прилагательных, причастий, существительных (напр., «the three little screaming brown birds»).
Прилагательные с точки зрения особенностей синтаксиса обычно не сильно отличаются от существительных (напр., прилагательное может быть употреблено для описания явлений: «the big will not offend the little anymore»). Поэтому не будем относить их к разным классам слов. В этом классе будут и причастия, и некоторые местоимения. Из-за наличия в этом же классе причастий придется учитывать необходимость использования дерева категорий для формирования этого класса.
Артикль в некоторых случаях помогает сразу распознать слово этого класса (если оно стоит непосредственно между артиклем и концом предложения, или словом, которое не может быть частью NP-объекта). Это правило очень эффективно, но его применение возможно только при допущении, что в тексте нет сокращений с точкой. Есть еще несколько эвристических правил, которыми можно воспользоваться при таком распознавании.
Числительные можно распознавать, только учитывая изменения, вызванные применением этих правил, и особенности употребления (т.к., напр., в случае «You are the one who may go there» слово one будет местоимением, хотя в этом случае распознавание допустимо и имеет смысл, т.к. числительные все равно будут в том же классе слов, способных обозначать явления).
Обзор фундамента CFVR-UGD
<Заголовок сцены>
begin scene
( <Заголовок Категорий>
или <Заголовок Маркеров>
или <Заголовок Промежутков>
или <Заголовок Структур>
или <Заголовок Отношений>)
сколько угодно раз
end
<Заголовок Маркеров>
begin markers
<Определение Маркера>
сколько угодно раз
end
<Определение Маркера>
begin marker
num
discreet
continuous <Составной формат времени>
end
пока не определен.
<Заголовок Промежутков>
begin ticks
<Определение промежутка>
сколько угодно раз
end
<Определение промежутка>
tick def <первый маркер> . <второй маркер>
Категории, структуры и ограничения
<Заголовок категорий>
begin categories
<Определение категории>
end
<Определение категории>
begin category
name
[parent ]
end
<Заголовок структур>
begin structure
<Определение узла>
end
<Определение узла>
begin node
num
name
ctg
x
y
end
<Заголовок ограничений>
begin relations
<Временный формат ограничения>
сколько угодно раз
end
<Временный формат ограничения>
arrow
<Узел1 > <Узел2 > <метка >
Обработчики CoreRuntime
1.5. Формат представления маркеров и промежутков времени в Radius
Добавим в модель уточнения. Как было сказано выше, явления, связанные с внутренним миром субъекта, описываются не так, как другие. Поэтому допустим, что в этих случаях имеются дополнительные представления, которые взаимодействуют с основным миром через конечное число входов и выходов данных. Эти представления могут быть разных форматов. Выделим обработчики этих форматов в динамические библиотеки (которые находятся в одном каталоге и называются core_runtime_<имя>.dll).
Для того, чтобы в рамках данного модуля core определить постоянные ограничения на данный объект (они могут иметь большой объем), будем использовать бинарные файлы. Лучше, чтобы формат файла был таким, чтобы любое содержимое файла определяло какой-нибудь объект, т.к. в этом случае можно использовать больше алгоритмов для поиска объекта. Т.е. требуется взаимно однозначное отображение из множества объектов во множество цепочек байтов.
Интерфейс:
DWORD GetCoreRuntimeUID();
DWORD GetFormatProperties();
BOOL Plusctor(HINSTANCE pins, LPCSTR HashFile);
void Minusctor();
DWORD RegisterLink(BOOL direction, DWORD id, WORD DataType);
BOOL SendLinkDword(DWORD id, DWORD data);
DWORD RecvLinkDword(DWORD id);
BOOL SendLinkDouble(DWORD id, double data);
double RecvLinkDouble(DWORD id);
Кроме этого, у этих объектов может быть непостоянное состояние, для которого тоже может быть более или менее удобный формат.
BOOL LoadState(LPCSTR SnapshotFile);
BOOL SaveState(LPCSTR SnapshotFile);
Интерпретация формата состояния в общем случае зависит от определения объекта.
Обработчики CoreRuntime действуют только в том случае, если входы и выходы с чем-то соединены (с объектом, или с отладчиком).
При работе на уровне геометрии определение типа CoreRuntime может производиться не сразу (возможно рассматривать управление объектом как неопределенное).
Камеры
Введем вспомогательные типы объектов для того, чтобы возможно было работать с проекциями объектов в пространстве: камеры и боковые виды. Они не могут быть использованы сразу, так как они определяют величины (цвет, координаты), которые зависят от обработчика формата объекта.
1.6. Возможный вариант определения объекта
1. Шар
Возможно такое определение объектов: объект – это шар в пространстве (возможно, его размер произвольно меняется со временем), такой, что, если камера или вид обозревает какие-то части его области, то цвет, видимый на камере или виде на соответствующих участках, может произвольно измениться (изначально он черный). Можно теперь допустить, что этот тип объектов определяет категорию Object – подкатегорию самой общей категории (можно назвать ее Template или Templ_auto). Далее, можно считать, что если имеется группа объектов с таким определением, то их группы – тоже такие объекты (т.е. категория допускает вложение).
2. Локальный объект первого типа.
Для большинства объектов можно в каждый момент времени указать набор многогранных областей, в которых находятся его компоненты связности. Локальные объекты первого типа в каждый момент времени определяют такой набор многогранных областей.
Форматы, которые применяются после этой стадии, зависят от спецификаций конкретных модулей.
Таким образом, в одной цепочке вложения должны быть следующие классы:
Иерархия структур
Обработчики формата объекта
Обработчики Core
Требуется класс, который мог бы поддерживать сравнение, тестирование и взаимодействие структур.
Все пространство
Иерархия структур
Обработчики формата объекта
Обработчики Core
Так как этот класс для правильного тестирования сцены должен получить однозначные правила перехода от предшествующих к новым моментам времени, можно потребовать, чтобы независимо от выбора начального момента времени состояние сцены в любой из последующих моментов зависело от состояния в начальный момент. В этом случае, задачу поиска всей сцены можно свести к поиску ее глобальных характеристик и состояния в какой-нибудь удобный момент времени (скорее всего, это будет самый ранний момент, на котором задано какое-то локальное (по времени) условие).
Дополнительно можно разделить глобальные характеристики сцены (и объектов) на «формат» (правила для этой сцены или типа объектов) и «код» (состав сцены или характеристики конкретного объекта).
Такая иерархия соответствует введенным ранее диаграммам:
Все пространство (правила, состав, состояние)
Иерархия объектов в соответствии с составом сцены
Объект (тип, характеристики, состояние)
Обработчик Core (тип, основной файл, состояние)
Форматы для объектов, вероятно, должны выбираться вручную, а после выбора форматов должна получиться задача.
2. Интерфейс
2.1. Radius
Будем рассматривать возможности решения поставленной задачи добавлением функций в редактор Radius, созданный мною годом ранее на основе разработанного тогда же языка визуального программирования для выполнения задач обработки исходных данных для создания трёхмерных сцен. Редактор Radius демонстрирует пользовательский интерфейс, пригодный для эффективного преобразования исходных данных для задач имитационного моделирования, позволяет ускорить подготовку данных для создания трёхмерных сцен и обеспечивает широкие возможности импорта данных.
Дополненный в рамках данной работы новыми функциями и модулями редактор Radius (Рис.7) предназначен для решения задач преобразования исходных данных (в т.ч. текстовых) и задач имитационного моделирования, при этом он обеспечивает организацию связанных файлов данных моделей как единого проекта с автоматическим созданием папок и тегов файла RDP.
Редактор обеспечивает поддержку концепции схем и чертежей в режиме ресурсов с возможностью предварительного просмотра сцены в окне Radius с помощью режима сцен, формирование и сохранение в файлы RDG, предварительный просмотр списка вершин XVB 3.0 (или XVB 2.0), экспорт (без записи тегов) формата DGO.
2.1.1. Архитектура Radius, взаимодействие режимов
Иерархия окон представлена на рис. 8.
Редактор Radius имеет 6 основных режимов: Project, Resources, Material, Geometry, Behavior, Scene. Режим можно переключить, выбрав его на нижней панели. Режим Project нельзя выбрать в текущей версии. Каждая кнопка панели имеет индикатор, который может принимать 4 состояния:
режим недоступен/ошибка
режим запущен, файлы не изменены
режим запущен, файлы изменены, есть несохраненные файлы
режим запущен, файлы изменены, все файлы сохранены
Индикаторы нижней панели показаны на рис. 9.
Режимы Radius могут взаимодействовать, при любой из них может принимать данные только от тех режимов, кнопки которых находятся слева от его кнопки.
Для того, чтобы данные можно было сохранить в Radius, необходимо выбрать папку проекта, в которой будут сохраняться данные. Тогда в этой папке сохраняется файл с расширением RDP, в котором будет указано местоположение всех значимых для Radius файлов, которые находятся в этой папке. Он будет иметь имя, совпадающее с названием папки проекта (в дальнейшем – «имя проекта»). Для удобства при создании проекта в папке проекта создаются папки с названиями 5 режимов Radius, а также папка «uses» для часто используемых файлов с входными данными, и папка «exports» для вывода файлов в форматах, используемых в UGD.
Хранение сохраняемых в проект данных в коде Radius отделено от других функций режимов. Поэтому обычно при переключении режима рабочие данные (в отличие от некоторых временных данных (обычно в редакторах режима ресурсов), которые необходимо сохранять перед выходом из режима) не теряются.
Radius может использовать одну папку для хранения папок нескольких последовательно созданных проектов. Для её выбора используется следующее окно (Control -> Global Settings) (Рис. 10):
Для правильного создания проектов нужно здесь ввести путь. Проекты создаются с помощью команды меню (она есть во всех режимах) Project -> New Project. В диалоговое окно вводится имя нового проекта; после нажатия «ОК» после ввода правильного имени создаются папки проекта и главный файл проекта (Рис.11).
Есть возможность открыть существующий проект (Команда Project -> Open Project) (Рис. 12). Открывается стандартное окно выбора файла; в данном случае надо выбрать файл RDP, представляющий проект. Фильтр файлов оставляет здесь только файлы RDP.
Команда копирования или (в некоторых режимах) сохранения проекта копирует данные (с замещением) в другой (уже созданный) проект; при этом файл RDP переписывается. В окне копирования (Рис. 13) следует указать файл RDP из папки назначения.
В текущей версии для начала работы с созданным проектом следует закрыть редактор и отредактировать файл RDP вручную (записать относительные пути и имена файлов, с которыми будет производиться работа, учитывая ограничения на количество для соответствующих режимов).
В следующем сеансе работы с Radius файлы будут созданы.
2.1.2. Режим сцен
Режим для применения исходных данных для сцены и предварительного просмотра сцены. Пользовательский интерфейс режима показан на рис. 14. Иерархии классов и окон представлены на рис. 15.
П
ри запуске режим загружает модуль ugdgraph.dll (основной модуль движка UGD) и отображает его вывод в рабочей области Radius. Предварительный просмотр сцены отличается от работы с UGD напрямую тем, что обновление изображения происходит только при движении курсора над рабочей областью. Рабочая папка режима – папка Radius (исключение: модуль ugdgraph.dll загружается из папки UGD). Переключение в режим редактирования Schematic вызывает другой вид. Таким образом, введённые ранее понятия категории, маркера, промежутка, структуры, отношения в интерфейсе представлены соответственно: в виджете «категории» боковой панели, окнами маркеров на линии времени на нижней панели, закрашенной жёлтым цветом области на линии времени (Рис. 16), окнами структур и стрелками между ними.
Дополнение словаря по маркированному тексту и поиск структур в режиме сцен
Для поиска структур используется модуль режима ресурсов TextConv (Рис.17) и режим сцен (в режиме редактирования Schematic).
Входной формат
Текст на английском языке.
Фаза 1. Модуль TextConv.dll (новый модуль режима ресурсов).
Требуется ввести имя файла. После нажатия «Далее» будет проверено, существует ли такой файл.
После повторного использования кнопки «Далее» будет запущен первый шаг предобработки, и далее второй шаг и сохранение результатов.
Из каждой страницы выбранного текстового файла данные копируются в массив символов, указатели на эти массивы составляют массив FlipBuffer1. Дополнительно создается массив FlipBuffer2 для хранения такого же количества страниц. На первом шаге обработки данные будут многократно копироваться из одного массива в другой.
На первом шаге для каждой страницы применяются следующие операции:
Удаляются символы, кроме символов из диапазонов A-Z, a-z, 0-9, пробелов и символов ( ) . ! ? < > “ , ' - : ; (символы, использующиеся вместо пробела, заменяются на знак пробела).
Выделение абзаца не используется из-за того, что большинство текстов импортируется из форматов HTML, PDF и других, где абзац специально не маркируется.
Проверяется правильность расстановки скобок и кавычек. Если обнаружена ошибка, анализ останавливается. Для анализа используется алгоритм из [14].
Удаляются лишние символы пробела.
Знаки препинания отделяются от слов.
Отделяются знаки препинания, стоящие подряд. При этом из вариантов отделяемого знака выбирается тот, в котором больше символов (он должен стоять выше в файле punctuation_patterns.dgs)
На втором шаге с помощью эвристик маркируются некоторые слова, чтобы лексический анализатор проверял меньше вариантов разметки предложения.
Страницы объединяются в массив слов, при этом учитывается возможность переноса слова между страницами.
Проверяется наличие файлов словарей. Если они не найдены, создаются незаполненные словари. Файлы словарей открываются для чтения, и их содержимое копируется в массивы.
В последовательностях “ . - ”, “ ! - ”, “ ? - ”, “ , - ”, не стоящих в скобках или кавычках, или если тире стоит в начале текста, тире заменяется на знак < (Предполагается, что в исходном файле нет сокращений с точкой. Без этого предположения алгоритмы будут значительно менее эффективными. Если сокращения присутствуют, следует убрать точки).
Для каждого знака < (т.к. эти знаки не должны быть вложенными; они обозначают диалог) ведется поиск ближайшего знака из < > - . ? ! справа. Этот символ заменяется на >. (Возможны ошибки. Не найден метод, который позволял бы правильно расставлять кавычки диалога, тем более, что эта операция при корректном выполнении должна изменять размер массива слов)
Ставится флаг пунктуации для знаков препинания (при этом файл punctuation_patterns.dgs уже игнорируется)
Для известных союзов ставится флаг “может быть <2-арным союзом” и/или “может быть сложным союзом” (При этом пока не учитывается возможность того, что слово может быть предлогом или названием).
Из файла prepositions.dgs считываются простые и сложные предлоги, на похожие конструкции ставится отладочный флаг предлога.
Если слово заканчивается на знак ', проверяется, не выводится ли оно из словарного существительного по правилам образования множественного числа. Если да, ставится флаг.
Если слово заканчивается на 's, то, если слова нет в списке исключений (let's, where's, what's, who's, how's, when's, there's, that's, he's, she's, it's), оно записывается в список существительных (т.е. туда попадут разные части речи (one's, everybody's), если они могут иметь суффикс принадлежности, даже если в данном случае это сокращение от is).
Если слово заканчивается на ist / age, установить флаги существительного и глагола. В списке глаголов уже должны быть все исключения из этого правила (напр., assist, enrage), произвести проверку и оставить один флаг.
Если слово заканчивается на hood / ism / ment / ship / tude / ization, установить флаг существительного.
Установить флаг для артиклей (a, an, the).
Если единственное неизвестное слово стоит между артиклем и союзами (кроме and, or, but, yet) или знаком конца предложения, установить флаг существительного.
Произвести замену числительных и некоторых производных на теги.
Установить остальные префиксы тегов (с символом ‘$’ в начале).
Новые определенные слова записать в словарь.
Вывести результат анализа на экран.
Дальнейшие действия будут должны производиться в других модулях (работа модуля TextConv завершена). Возможно, для следующих этапов анализа необходим более сложный интерактивный пользовательский интерфейс (сложность соответствующих задач может потребовать подтверждений или участия пользователя в сложных случаях).
Результаты сохраняются в файле формата dgs
Фаза 2. В режиме редактирования Schematic режима сцен в командную строку вводится имя входного файла. После нажатия «+» будет запущен один из шагов, и в папке с входным файлом будет создан файл <имя>_dbg.dgs с меткой, обозначающей выполнение какого шага ожидается далее.
Шаг 1. Подозрительные слова после артикля (Рис. 18).
Шаг 2. Автоматическое определение чисел. На этом шаге создается копия входного текста (место копирования задается пользователем), в дальнейшем используется новый адрес файла.
Шаг 3. Незнакомые слова после слов в составе NP-объекта (Рис. 19).
Шаг 4. Выделение структур. После анализа найденные категории и структуры будут готовы к использованию (сохранению в файл проекта).
 
В случае больших файлов может быть невозможно отобразить все структуры.
Промежуточный формат ContainerMap DGS
begin containermap
begin timedot 1 атрибуты
[begin hierarchy
[begin object 1 ''имя''
[virtualnode]
[maxradius значение]
[begin viewpoint 1
[begin coordinate 1
name ''имя''
rule выражение
end]
end]
end]
end]
end
begin timedot 2 атибуты
[begin hierarchy
end]
end
…
begin restriction
(формат не определен)
end
...
end
Н
а рис. 21 показана диаграмма деятельности, соответствующая текстовой части проекта CFVR, которая описывает логику процедур, осуществляемых в этом проекте.
|
