Текстовый редактор для формального языка семантических толкований

Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

"НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

"ВЫСШАЯ ШКОЛА ЭКОНОМИКИ"

ФАКУЛЬТЕТ КОМПЬЮТЕРНЫХ НАУК

МАГИСТЕРСКАЯ ДИССЕРТАЦИЯ

ТЕКСТОВЫЙ РЕДАКТОР ДЛЯ ФОРМАЛЬНОГО ЯЗЫКА СЕМАНТИЧЕСКИХ ТОЛКОВАНИЙ

по направлению подготовки 01.04.02 Прикладная математика и информатика

образовательная программа «Науки о данных»

Зверев Иван Сергеевич

Москва 2019

Аннотация

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

В работе также описан контекст, необходимый для понимания внесённых изменений, а именно: дан краткий обзор лингвистического процессора ЭТАП, основы структуры языка Эталог, устройства редактора семантических правил и библиотеки Scintilla, использованной для его улучшения.

Annotation

This paper describes the changes I have made to the text editor for formal semantic rules, which is a part of ETAP linguistic processor. The changes increase convenience of using the editor, and improve code architecture, thus increasing efficiency of the editor's code.

The paper also contains the context necessary for understanding mentioned changes, namely a brief overview of ETAP linguistic processor, the basics of Etalog language structure, semantic rule editor structure and Scintilla library, which was utilized to improve the editor.

Введение

Лаборатория №15 Института проблем передачи информации занимается исследованиями в области компьютерной лингвистики. В компьютерной лингвистике важна задача глубокого семантического анализа текста -- то есть, перевода текста с реально существующего языка на некоторый формальный язык, понимаемый компьютером. В частности, на данный момент понимание текста лингвистическим процессором можно проверить, задавая вопросы по тексту -- ЭТАП способен отвечать на вопросы, ответы на которые не были даны в тексте явно (такие, например, как «кто платил», в то время как в тексте сказано, кто и кому продал).

Текстовый редактор, являющийся частью ЭТАПа, и компилируемый им язык Эталог были разработаны для этой цели. На языке Эталог пишутся правила логического вывода, в частности правила толкования семантических концептов -- расшифровка того, сколько актантов есть у того или иного слова и в каких отношениях они находятся между собой или с самим словом; такие правила дают нам возможность получить дополнительную смысловую информацию о происходящем.

Например, если некто покупает товар, это всегда означает что:

1) он лишается денег;

2) он получает товар;

3) другой человек продаёт ему товар;

4) другой человек получает деньги, причём те, которых лишился первый; и так далее.

Помимо того, что редактор содержит кнопки для работы с текстом, он также выделяет синтаксис различными цветами. Как и в других языках программирования, мгновенное выделение различных синтаксических конструкций (переменных, операторов и прочее) существенно облегчает работу с семантическими правилами, написанными на Эталоге.

Тем не менее, на момент моего вмешательства подсветка синтаксиса в редакторе ЭТАПа периодически работала со сбоями -- слова выделялись частями или не выделялись, а кнопка отмены изменений не работала. Подробно об этих особенностях можно прочитать в разделе 4, но главной причиной проблем было изначально неоптимальное решение в устройстве проекта -- использованный класс СRichEditView поддерживал раскраску текста, но цвет сохранялся непосредственно в форматировании текста, в результате чего перекраска текста (а она совершалась постоянно) удаляла слова из текста и вписывала их же, но другим цветом. Возникающие проблемы теоретически возможно скрыть подручными средствами (см. раздел 5), однако, это чревато тем, что при дальнейшем изменении редактора те же проблемы вернутся. К тому же, форматированный, цветной текст не имеет смысла сохранять, потому что он нужен нам в раскрашенном виде исключительно на экране редактора, для удобства просмотра пользователем.

Таким образом, передо мной была поставлена задача изменить способ хранения редактируемого текста (чтобы он хранился в нераскрашенном виде) и способ отображения (чтобы он отображался в раскрашенном виде).

После долгих поисков (см. раздел 6), мне удалось найти библиотеку Scintilla, предназначенную именно для написания текстовых редакторов, причём достаточно старую её версию, чтобы классы, написанные при помощи этой библиотеки (CScintillaCtrl и CScintillaDemoView) были совместимы с уже написанным кодом. Базовый класс проекта был сменён на похожий, но написанный уже с использованием Scintilla, и четыре главные кнопки, необходимые для работы с правилами (просмотр существующих правил, компиляция, построение графа и перезагрузка онтологии), были привязаны к новой версии. В разделах 7, 8 рассказано о внесённых изменениях. По итогам выполненной работы, исправленный редактор успешно и эффективно выделяет синтаксис текста, сохраняя при этом исходную функциональность, что означает, что поставленную задачу можно считать выполненной.

1. Комплекс ЭТАП

Лингвистический процессор ЭТАП -- это комплекс программ, который начал создаваться Институтом ещё в 1980 году. Он написан на языке C++ и содержит в себе более 20 различных запускаемых приложений.

Приложения ЭТАПа применяются для выполнения многих лингвистических задач: машинный перевод [1], синонимичное перефразирование, обработка запросов на естественных языках, перевод на UNL (универсальный язык концептов, представимый графами), синтаксический и семантический анализ [2] и исправление ошибок синтаксиса.

Приложения процессора ЭТАП имеют модульную структуру, вследствие чего могут быть разбиты на более мелкие (но всё ещё сложные по своей структуре) функции и базы данных. Например, в машинном переводе процессор ЭТАП использует базы с морфологическими, синтаксическими и семантическими парсерами обоих языков, а текст, проходя от начального до конечного состояния, меняет свою форму 7 раз (спускаясь от текста к его семантическому разбору и обратно) [1].

Процессор ЭТАП применяется для решения многих задач; в этой конкретной работе мы рассматриваем часть процессора, отвечающую за семантический разбор текста и его дальнейшее «понимание» компьютером [3,4,5]. Применение подобного «понимания» заключается в том, чтобы можно было создавать информационные базы на естественных языках, после чего обращаться к ним с запросами на естественных языках. Проверка же этого «понимания» на данный момент заключается в том же, но в меньших масштабах: как правило, небольшой текст, часто из одного предложения, вводится в систему как информация, после чего система может отвечать на простые (для человека) вопросы по этому предложению.

Так, в работе [5] хорошим примером является предложение «Аршавин так и не смог спасти матч». Человеку сразу видно, что матч завершился не в пользу Аршавина, для компьютера же ответ на вопрос «Победила ли команда Аршавина?» будет нетривиален.

Как же компьютер справляется с этой задачей? Сначала к предложению применяются морфологический и синтаксический парсер. Результатом работы синтаксического парсера является дерево синтаксической структуры предложения [2]. Оно похоже на деревья синтаксиса, которые мы строили в школьной программе, но содержит больше различных отношений, благодаря чему после разбора все слова текста объединяются в дерево (то есть, даже предлоги и союзы получают свою вершину в этом дереве).

После этого из дерева синтаксической структуры при помощи словаря значений мы получаем семантический граф. Затем мы пользуемся семантическими правилами, которые делают этот семантический граф более полным. лингвистический программа семантический лексер

Семантические правила могут содержать в себе более-менее любую информацию; впрочем, удобнее всего привязывать информацию к тому или иному понятию и использовать её в построении графа, когда это понятие там есть. Например, недавно в правиле, характеризующем процесс «покупка» я увидел строки, которые были дописаны туда позже создания правила -- на языке Эталог было сообщено, что если человек получает бракованный товар, то он будет недоволен процессом покупки. Чем больше информации в семантических правилах, тем лучше мы можем расширять графы.

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

Я постепенно подошёл к тому, зачем нужно писать семантические правила. Однако, прежде чем мы перейдём непосредственно к редактору, стоит несколько разобраться в языке, на котором их пишут.

2. Язык семантических правил Эталог

Эталог -- это язык, используемый для записи правил логического вывода, используемый лингвистическим процессором ЭТАП. Подробно синтаксис Эталога описан в статье [6]. Тут я привожу суть языка в общих чертах, с упором на то что и как в нём предполагается выделять цветом.

Переход от текста на естественном языке к структуре, обрабатываемой компьютером, как правило, проходит следующие шаги: текст > синтаксическое дерево > семантическое представление. Например, есть предложение «Пётр купил зонт у Ивана». Его синтаксическим деревом будет набор синтаксических отношений -- купил (что?) зонт, купил (у кого?) у Ивана, и так далее.

Семантически можно прийти к чему-то похожему: есть «покупка», у неё есть объект «зонт» и субъекты «Иван» и «Пётр» (эти роли в лингвистике называются актантами и для разных процессов, как правило, известен список их актантов). Вместе эти смысловые отношения образуют граф. Но, работая в ЭТАПе, мы хотим использовать правила логического вывода и расширять этот граф, сохраняя в нём больше фактов, связанных с тем или иным действием.

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

Например, ниже приведён фрагмент кода правила Buying (фрагмент кода 3.1). В нём говорится, что у всякой переменной ?buying класса Buying должно быть отношение hasAgent c переменной класса Agent, отношение hasAgent2 с переменной класса Agent и так далее.

Язык Эталог оперирует переменными, классами, отношениями и индивидами. Каждая из этих единиц будет рассмотрена подробнее.

1) Переменная -- это базовая единица синтаксиса, ей отвечает некий абстрактный объект, узел в семантическом графе. Без классов и отношений переменные лишены смысла. Названия переменных можно заменять на другие, логика от этого не меняется.

2) Класс, технически, это унарный оператор. То есть, если x -- переменная, то можно написать, что она принадлежит к классу Event как Event x. Правило толкования определяет поведение всех переменных класса -- то есть, оно начинается с «Если есть x класса X, то: для x верно следующее...», после чего перечисляются условия на этот x.

3) Отношение, технически, это бинарный оператор. Отношения дают смысловую связь двух переменных, например, x hasAgent y - y является агенсом, активным деятелем события x. На семантическом графе переменные будут узлами, а отношения -- рёбрами.

4) Наконец, индивид -- это что-то вроде программной константы, аналог переменной, который уже внесён в язык и может полностью использоваться как переменная.

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

3. Редактор семантических правил и задача раскраски

Ниже приведен пример правила, семантически описывающего слово «виноватый», открытый в редакторе семантических правил (рисунок 4.1). Это старая версия редактора, поэтому здесь очевидны некоторые проблемы: ключевое слово Rule не выделено, а некоторые комментарии раскрашены в коричневый с чёрным, хотя должны быть выделены серым.

Тем не менее, раскраска классов/отношений/индивидов, а также переменных здесь рабочая, поэтому общую структуру правила можно проследить.

Рисунок 4.1. Правило, семантически описывающее слово «виноватый» в редакторе семантических правил.

Глядя на этот пример можно достаточно точно сформулировать задачу по раскраске:

1) Три группы ключевых слов, взятых из онтологии (классы/отношения/индивиды) должны краситься в соответствующие цвета.

2) Переменными считаются все слова, начинающиеся на вопросительный знак (это правило упрощает как раскраску, так и написание новых правил). Переменные красятся в коричневый цвет.

3) Комментарии -- всё что написано после двух слэшей, включая эти слэши -- должны быть покрашены в серый цвет.

Помимо раскраски комментариев в не свои цвета, которая наблюдалась в оригинальной программе, существовала проблема с кнопкой отмены изменений -- она не работала в принципе. Всё это предстояло починить с использованием библиотеки Scintilla. Помимо этого, в случае если редактор придётся не изменять, а переписывать (а так, в итоге, и произошло), требуется сохранить 4 ключевые для работы кнопки:

1) Кнопка загрузки правил: открывает окно «Загрузки правил», которое отображает список существующих в системе правил. В окне есть интерфейс для поиска/удаления правил и загрузки текста правил в окно редактора.

2) Кнопка компиляции: код в открытом документе проверяется на ошибки и компилируется во внутренний формат ризонера RDFox [7], который используется в системе для реализации логического вывода.

3) Кнопка построения графа: по тексту правил строится и отображается на экран граф, где переменные являются узлами, а отношения -- рёбрами.

4) Кнопка перезагрузки онтологии: на случай изменения файла онтологии, перезагрузить из неё списки классов, отношений и индивидов (и сразу же использовать новые списки в раскраске текста).

Редактор семантических правил построен с использованием библиотеки Microsoft Foundation Classes -- это удобное решение, так как большая часть нужных для редактора классов уже прописана.

Минусами такого решения является то, что многие используемые классы прописаны слишком жёстко, из-за чего возникают проблемы, когда необходим новый функционал. Например, возможности интерфейса для редактирования текста ограничены классом CRichEditCtrl. Я приведу конкретный пример -- почему кнопка отмены перестала работать с внесением раскраски в редактор.

Для раскраски текста редактор обращается к CRichEditCtrl с запросами вроде «дай мне посмотреть свой текст» и «замени вот эти символы на такие же, но другого цвета». Эта операция (для неё был написан отдельный класс CSyntaxColorizer) повторяется при каждом изменении текста. Однако буфер отмены тоже контролируется CRichEditCtrl, в результате чего выполненные замены символов тоже попадают в список операций для отмены.

Это вызывает не просто лишнюю необходимую операцию, а заколдованный круг: пусть мы внесли изменение и некоторые символы перекрасились. Тогда последней операцией в буфере отмены мы увидим «перекраску символов». Кнопка отмены перекрасит их обратно, что CRichEditCtrl воспримет как изменение текста и просто запустит покраску заново, снова изменит текст и занесёт операцию в буфер.

4. Быстрое исправление -- как починить кнопку отмены

Существует способ починить кнопку отмены изменений.

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

Метод OnEnChange, уже написанный в классе, унаследованном от CRichEditView, запускается при каждом изменении текста извне, выделяет часть текста и перекрашивает её в нужный цвет. Чтобы починить кнопку отмены, необходимо чтобы метод совершал следующую последовательность действий:

1) Дать буферу отмены понять, что все последующие операции нужно сцеплять с последней (и отменять за одну операцию отмены, соответственно);

2) Раскрасить текст;

3) Вернуть буфер отмены в обычный режим.

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

5. Scintilla и редакторы, написанные на ней

Библиотека Scintilla [8] разработана специально для написания текстовых редакторов с выделением текста. В Scintilla при выводе текста используется специальный файл, с кодом на C++, называемый «лексером» -- в этом файле описываются правила, по которым для частей текста определяется, к каким типам они относятся и в какие цвета должны краситься.

В свободном доступе на сайте лежит редактор SciTE [9], изначально созданный для того чтобы продемонстрировать возможности Scintilla, но уже ставший самодостаточной программой. SciTE содержит папку с большим количеством лексеров разной степени сложности, в том числе лексер для C++, Python, TeX и прочих.

Мои задачи свелись к следующим: написать лексер для языка Эталог (выделяющий нужные ключевые слова) и связать SciTE с функциями редактора семантических правил ЭТАПа. Если к первому мы ещё вернёмся, то второе оказалось сложнее ожидаемого.

Работа над изменением программного комплекса ЭТАП содержит две основные сложности: во-первых, этот комплекс большой -- не только буквально по месту на диске, но его проекты имеют много зависимостей, и вынуть какой-то из них, чтобы использовать в другом редакторе почти невозможно. Вторая, более досадная сложность -- ЭТАП написан под Visual Studio 2015, в то время как сейчас чаще используется VS2017 (на момент написания этого текста уже VS2019). Из-за этого код многих хороших редакторов, содержащих Scintilla, нельзя использовать, так как к ним не подключить функционал ЭТАПа из-за разницы версий Visual Studio.

Решением стал редактор ScintillaDemo [10, 11], написанный достаточно давно, чтобы не вызывать проблем с версией Visual Studio, и совместимый с Microsoft Foundation Classes. Основной класс этого редактора называется СScintillaEditCtrl (по аналогии с CRichEditCtrl). Мне удалось практически переписать главный проект редактора семантических правил ЭТАПа (semrule) с использованием этого класса, после чего остаётся использовать функции, привязанные к кнопкам в старом проекте.

6. Подсоединение кнопок к новому редактору

Так как ScintillaDemo была сделана для работы с Microsoft Foundation Classes, переделать кнопки в меню, буквально вставив туда иконки старых кнопок, было несложно. Точно так же несложно привязать к иконкам старые, уже написанные функции показа правил, графа и компилятора. Не работает сразу только онтология, потому что текст теперь красит лексер, а это новая структура, нуждающаяся в новых функциях.

Рисунок 7.1. Интерфейс измененного редактора

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

Ниже я привожу фрагмент кода с методом BroadcastOntology() (фрагмент кода 7.1). Этот метод запускается чтобы загрузить онтологию при открытии программы и при нажатии кнопки перезагрузки онтологии.

Действует он просто: сначала он получает указатель на ScintillaDemoView, привязанный к главному классу CMainFrame. После этого он получает у класса OntoShell онтологию, а у неё, по очереди -- классы, индивиды и отношения. Их он отправляет в ScintillaDemoView (я выделил в ней три поля string, которых там раньше не было), и затем запускает InitialUpdate().

При операции InitialUpdate() класс ScintillaDemoView создаст новый лексер и подаст ему на вход, как списки ключевых слов, слова из онтологии.

Можно также заметить, что над списками проводятся некоторые преобразования. Причиной этому служат разные способы их хранения. Названия классов и индивидов в онтологии ЭТАПа хранятся как строки из слов, разделённых запятыми. Названия отношений -- как список из строк. Лексер же принимает ключевые слова как строки, разделённые пробелами, отсюда и необходимость в преобразованиях.

7. Лексер для языка Эталог

Scintilla обладает достаточно интуитивным интерфейсом для написания лексеров -- всё взаимодействие с текстом осуществляется через класс StyleContext -- он является чем-то вроде указателя на символ текста, но с дополнительными возможностями. Так, он всегда хранит данный и следующий символы, а также может «менять их состояние» -- на деле, конечно, смена состояния сохраняется не в символах, а в StyleContext-е, и будет использована при выводе на экран.

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

Ниже я разбираю код написанного мной лексера для языка Эталог.

Я ввёл состояния «по умолчанию» (для чёрного текста), «комментарий» (для серого текста комментариев) и «неразрешённое». Неразрешённое состояние не привязано к цвету и нужно нам на тот случай, если символ находится внутри слова, которое мы ещё не знаем. С их состояниями мы разберёмся позже; для них же написана первая строка в цикле -- если состояние не «комментарий» и не «разрешённое», то нужно выставить «по умолчанию».

С «неразрешёнными» состояниями мы разберёмся во второй половине кода, что до «комментариев» -- они изменяются только с началом новой строки. Поэтому мы обновляем состояние только если оно «по умолчанию» или началась новая строка. Комментарий начнётся, если там стоят два слэша, а неизвестное слово, если там стоит «словесный символ» (буква, цифра, подчёркивание или вопросительный знак).

После этого мы разбираемся с «неразрешённым» состоянием. Если слово не закончилось, мы добавляем символ в буфер и продолжаем. Если же оно закончилось, то мы используем функцию ChangeState(). Эта функция заменяет все символы, которые были в состоянии «внутри неизвестного слова» на нужное состояние из четырёх: «переменная», «класс», «отношение», «индивид» или «по умолчанию». Уже эти состояния привязаны каждый к своему цвету.

Мы знаем, какое состояние выбирать, потому что BroadcastOntology() при создании лексера передала нам все списки ключевых слов, а в буфере обмена сохранено слово, которое нужно выделить. Плюс нам необходимо проверить, не начинается ли название на вопросительный знак -- в таком случае мы красим его в цвет переменных.

Заключение

В работе была задача изменить редактор (или создать новый), сохраняющий старый функционал, но при этом выделяющий синтаксис только на этапе хранения, а не на этапе просмотра. Благодаря библиотеке Scintilla, эту задачу удалось выполнить.

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

Библиографический список

[1] Apresian J. et al. 2003. ETAP-3 Linguistic Processor: a Full-Fledged NLP Implementation of the MTT / Jurij D. Apresian, Igor M. Boguslavsky, Leonid L. Iomdin, Alexander V. Lazursky, Vladimir Z. Sannikov, Victor G. Sizov, Leonid L. Tsinman // First International Conference on Meaning - Text Theory (MTT"2003). June 16-18, 2003. Paris: Ecole Normale Superieure, 2003. P. 279-288.

[2] Iomdin L. et al. 2012. ETAP parser: state of the art / Leonid Iomdin, Vadim Petrochenkov, Victor Sizov, Leonid Tsinman // Computational Linguistics and Intellectual Technologies. Papers from the Annual International Conference "Dialogue" (2012) (pp. 119-131).

[3] Boguslavsky, I. et al. 2015. Semantic analysis and question answering: a system under development / Igor Boguslavsky, Vyacheslav Dikonov, Leonid Iomdin, Alexander Lazurski, Victor Sizov, Svetlana Timoshenko // Computational Linguistics and Intellectual Technologies. Papers from the Annual International Conference Dialogue (Vol. 2015).

[4] Rygaev I. 2017. Rule-based reasoning in semantic text analysis. Proceedings of the Doctoral Consortium, Challenge, Industry Track, Tutorials and Posters @ RuleML+RR 2017

[5] Boguslavsky I. et al. 2018. Semantic analysis with inference: high-spots of the football match / Igor Boguslavsky, Tatiana Frolova, Leonid Iomdin, Alexander Lazurski, Ivan Rygaev, Svetlana Timoshenko // Computational Linguistics and Intellectual Technologies. Papers from the Annual International Conference "Dialogue" (2018)

[6] Rygaev I. 2018. Etalog -- a natural-looking knowledge representation formalism // Труды школы-конференции ИТиС 2018

[7] Nenov, Y., Piro, R., Motik, B., Horrocks, I., Wu, Z., and Banerjee, J. 2015. RDFox: A highly-scalable RDF store. In International Semantic Web Conference (pp. 3-20). Springer, Cham

[8] https://www.scintilla.org/

[9] https://www.scintilla.org/SciTE.html

[10] http://www.naughter.com/scintilla.html - совмещение Scintilla и MFC

[11] https://github.com/wingkinl/ScintillaWrapper - облако со старыми.

Размещено на Allbest.ru

версиями