Настоящий выпуск представляет собой первую часть работы, являющейся вводной к серии публикаций по проекту ЗАПСИБ. В препринте обсуждается цель проекта - создание последовательности прикладных лингвистических процессоров для обеспечения взаимодействия пользователя с ЭВМ на естественном языке в ограниченной предметной области. При этом рассматривается специфика использования лингвистического процессора для анализа обращения к базе данных "наивного" пользователя, в частности, возможные ограничения на входной (естественный) язык. Приводится подробный пример обработки запроса к базе, иллюстрирующий принцип семантически-ориентированного анализа. Этот принцип, взятый за основу в работах по проекту ЗАПСИБ, позволяет существенно упростить процессор по сравнению с традиционным синтаксически-ориентированным подходом. В заключение этого выпуска обсуждается структура компоненты и правила - двух основных объектов, используемых при организации процесса анализа. Во второй части работы, публикуемой отдельным выпуском в той же серии, рассматривается общая схема процессоров ЗАПСИБ и функции ее основных модулей, а также обсуждается проблема автоматизации настройки процессора на конкретную предметную область.

Linguistic Processors ZAPSIB

(Part I - Aims of the Project)

A.S. Narin'yani

Abstract

This issue presents the first part of the work introductory to the series of publications on the ZAPSIB project. We discuss here the purpose of the project, which is development of a sequence of applied linguistic processors for the natural language user - computer interaction in limited object domains. Some aspects of the linguistic processor usage for analysis of a "naive" user request to a data base are considered with special attention to possible limitations on the input (natural) language. A detailed example of processing of a query to the base is demonstrated as an illustration of the idea of semantics-oriented analysis. This idea is basic for the ZAPSIB project and its realization allows the process to be substantially simplified in correspondence to the traditional syntax-oriented approach. In the conclusion of the issue we discuss the structure of a component and a rule which are the two principle types of the objects being used in organization of the analysis process. The second part of the work, which is published as next issue in the same series, is dedicated to the general scheme of ZAPSIB processors and functions of its main modules as well as to the problem of automatization of the processor adaptation to a particular object domain.

1. Введение

1.1. Предлагаемая работа1 является по своему характеру вводной. Она открывает последовательность публикаций, которые будут отражать конкретные результаты разработок, объединенных общей целью - созданием серии прикладных процессоров, обеспечивающих взаимодействие с машинными системами на естественном языке. И проект, в русле которого ведутся эти работы, и сама серия названы ЗАПСИБ (ЗАПрос к Справочно-Информационной Базе), поскольку понимание такого запроса является сейчас, по-видимому, и самой достижимой, и наиболее актуальной с прикладной точки зрения задачей, на решение которой и будут направлены в первую очередь усилия разработчиков серии. Выделение этого направления работ нашей лаборатории в прикладной проект потребовало около пяти лет и прошло через ряд этапов, приведших нас как группу к идее семантически-ориентированного анализа. Поскольку наша точка зрения на место этого подхода в общем фронте работ по автоматическому анализу и синтезу текстов на естественном языке уже была достаточно полно изложена ранее ([Нариньяни 1977], [Левин-Нариньяни 1978]), мы позволим себе опустить здесь обоснование его права на жизнь и лишь в самом общем виде остановиться на тех "прагматических рамках", которые выделяют лингвистические про-цессоры (Л-процессоры) для взаимодействия с прикладными базами данных из ряда более универсальных и сложных систем автоматической обработки текста на естественном языке.

1.2. Для этого, существенно упрощая реальную ситуацию, будем рассматривать Л-процессор как про-граммный переводчик с естественного языка (ЕЯ) на формальный - доступный той базе данных, с которой общается пользователь.

Функции Л-процессора в этой схеме определяются входным и выходным языком, т.е. естественным языком пользователя и формальным языком, основной задачей которого является обычно не формальное представление смысла входного ЕЯ сообщения, а обеспечение взаимодействия пользователя с базой в отсут-ствии (либо помимо) лингвистического процессора. Остановимся на них подробнее.

1.2.1. Естественный язык, на котором формулируется входное сообщение или запрос, безусловно ограничен, причем эти ограничения определяются и качеством процессора, и спецификой области взаимо-действия. Эти два типа ограничений носят принципиально разный характер, поскольку, в отличие от ограниче-ний, возникающих из-за несовершенства процессора, рамки области взаимодействия являются для пользова-теля "самим собою разумеющимся" контекстом и не воспринимаются как запреты, ограничивающие его свободу в использовании языка. Этот контекст определяется в первую очередь двумя факторами: Стилистическими рамками взаимодействия "человек-ЭВМ". Очевидно, что это - деловой язык, еще более "сухой", чем научно-технический текст. Пользователь прекрасно чувствует неуместность, напри-мер, подчеркнуто разговорных конструкций или чрезмерной синтаксической вычурности. Он действует с подсознательной презумпцией ограниченности языковых возможностей машины и необходимости упрощать текст для исключения неоднозначности его понимания. Специфичность и узость предметной области естественным образом ограничивает лексику, семан-тику и прагматику языка, что, в свою очередь, не может не привести и к сужению синтаксической свободы. Ограничения, более чувствительные для естественности взаимодействия, возникают из-за несовер-шенства системы анализа текста: реальный Л-процессор делит совокупность языковых средств пользователя на две части - те, которые он воспринимает правильно, и те, которые он не воспринимает (или восприни-мает неправильно). Таким образом, процессор навязывает пользователю дополнительные ограничения, ко-торые этот последний, в противоположность рассмотренным выше, отнюдь не ощущает как естественные. Если сумма таких запрещений превысит некоторый порог, то массовый, т.е. неподготовленный поль-зователь не сможет к ним приспособиться - в этом случае, как очевидно, естественно-языковой интерфейс не обеспечивает выполнения своей основной функции связи с пользователя с ЭВМ. Единственный выход - использовать дешевые и ограниченные процессоры в наиболее простых предметных областях, где накладываемые ими ограничения не будут заметны на фоне "естественных" огра-ничений проблемной среды. Взаимодействие с более сложными системами требует более мощных, более сложных и дорогих процессоров. Таким образом, вопрос ставится не о создании одного универсального Л-процессора, а о серии про-цессоров, растущих по сложности и способных обеспечивать восприятие текста во все более сложных пред-метных областях. Развиваемый в Лаборатории искусственного интеллекта ВЦ СО АН СССР подход к восприятию тек-ста на основе восходящего семантически-ориенти-ро-ван-ного анализа позволил приступить к разработке та-кой серии на основе единой общей схемы, состоящей из стандартного набора функциональных модулей, возможности которых расширяются от модели к модели.

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

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

Из трех этих групп только последняя "доросла" до эффективного использования естественного языка в качестве интерфейса при взаимодействии с пользователем: · в первом случае область взаимодействия так узка, что задается ограниченным списком доступных систе-ме директив, каждая из которых гарантирует однозначность понимания в отличие от пересказа содержа-ния этих директив на естественном языке. Можно сказать, что естественный язык в данном случае явля-ется чрезмерной роскошью и даже помехой; · во втором случае сам принцип организации взаимодействия требует от пользователя навыков програм-мирования. Таким образом, здесь речь не может идти о массовом, а только о подготовленном пользова-теле. В таком случае опять-таки гораздо естественнее и надежнее использовать формальные средства спецификации директив. С другой стороны, семантика формальных языковых средств для систем третьей группы оказывается достаточно сходной - более того, представляется вполне реальным построить формальный язык, покры-вающий возможности таких средств для отдельных систем. Подобный язык должен включать возможности, обеспечивающие разные "проекции" взаимодействия с базами данных, в том числе средства:

• определения информационной структуры базы,
• формулирования запроса к базе,
• ввода новой информации,
• изменения содержания базы без изменения ее информационной структуры,
• перестройки структуры базы.

Очевидно, что такой язык можно рассматривать как язык программирования, ориентированный на ра-боту с данными сложной структуры, причем задача операционной части этого языка сводится в основном к обсуждению действий, связанных с пп. (г) и (д). В рамках проекта ЗАПСИБ ведется разработка такого языка, пока включающего только средства, пе-речисленные в пп. (а)-(г). Предполагается, что этот язык будет служить стандартным выходным языком про-цессоров ЗАПСИБ. Для работы с базой, входной язык которой отличен от стандартного, можно использовать интерфейс-ный модуль, осуществляющий перевод с одного языка на другой. Однако более дешевым и эффективным является решение, при котором процессоры комплектуются модулем генерации выходного формального представления, включающим средства настройки на синтаксис языка базы (см. ниже п. 7).

1.3. Вернемся еще раз к структуре входного ЕЯ текста. Даже в пределах столь специфической облас-ти, как взаимодействие с прикладными базами данных, сложность этой структуры может меняться в весьма широких пределах:

• (а) сообщение - отдельная фраза;
• (б) последовательность связанных между собой предложений.

  Например, запрос вида:

  Например, запрос вида:

  Как отмечалось в [Виноград 1978], между текстами вида (а) и (б) нет принципиальной разницы - любую последовательность фраз, относящихся по смыслу "к одному абзацу", можно превратить в одно предложение, заменив точки на точку с запятой. В данном случае мы отнесли к виду (а) сообщения, более простые по структуре, чем предложения, образованные механическим объединением нескольких фраз (хотя условность такого разделения совершенно ясна);

• (в) последовательность сообщений, участвующих в диалоге.

  Например:

• "По каким проектам Лаборатории искусственного интеллекта имеются публикации?
• Восток, СЕТЛ, ЗАПСИБ.
• Кто участвует во втором проекте?"

Различие между текстами вида (б) и (в) достаточно очевидно: первый и второй запрос в последнем примере не могут быть объединены в один, поскольку до ответа на первый пользователь вообще мог не знать о существовании проекта СЕТЛ. Естественно, что анализ сообщений, относящихся к трем выделенным категориям (как бы условны ни были границы между ними) требует существенно различных по своей мощности лингвистических процессо-ров. Если для анализа более простых сообщений вида (а) достаточно рамок структуры отдельной фразы, то сообщения (б) требуют анализа структуры связного текста, а сообщения (в) - структуры диалога. Предполагается, что младшие модели ЗАПСИБ будут ориентированы на анализ отдельных предложе-ний, хотя это не исключает их использования для анализа связного текста при ограничении на вид входящих в него предложений. Эксперимент по обработке текста, состоящего из последовательности простых предло-жений, был реализован в системе ВОСТОК-0, см. [Кандрашина и др. 1979 а, б].

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

(1) "Сообщите артикул синих шерстяных тканей дороже 20 рублей".

На некотором гипотетическом, но вполне типичном формальном языке (синтаксис нам в данном слу-чае не важен, а семантика, как уже отмечалось, у этих языков достаточно сходная) данный запрос мог бы быть представлен в следующем виде:

(2) А2 | Т4 | (А4=3) и (А6=11) и (А9 > 20.00),

где Тi - i-ая таблица базы (здесь Т4 - таблица данных о тканях), Аj - j-ый атрибут данной таблицы (А2 - артикул, А4 - тип ткани, А6 - цвет и А9 - цена), а цифры справа от отношений суть либо коды значений соответствующих атрибутов (3 = 'шерсть', 11 = 'синий'), либо сами числовые значения (20.00). Использование такого языка существенно упрощает систему анализа запроса, но его неудобство для пользователя - очевидно. Можно сделать существенный шаг навстречу пользователю, включив в запрос лексические (ЕЯ) иден-тификаторы и значения, - запрос при этом примет следующий вид:

(3) Артикул | ткани | (тип = шерсть) и (цвет = синий) и (цена > 20.00).

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

(4) Артикул для ткани | шерсть, цвет синий, цена выше 20.00.

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

2. Пример

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

• FR - строка таблицы;
• F - атрибут; для того чтобы отличить атрибуты друг от друга, будем снабжать их индексами. Например, Fп - страна производства, Fд - дальность, Fм - марка и т.д. Индекс будем называть ориентацией.
• V - значение атрибута. Например, значением Vп могут быть СССР, Франция, США и т.д. Значения также имеют ориентацию (ту же, что и соответствующие атрибуты).
• R - отношение: 'равно', 'больше', 'не меньше' и т.д.; отношения также имеют ориентацию: например, 'старше' может относиться только к возрасту.

2.2. Пусть на вход Л-процессора, обеспечивающего взаимодействия с нашей базой, поступает сле-дующий запрос: "Марки самолетов производства США с дальностью свыше 6 000 км." Смысл этого запроса совер-шенно однозначен и может быть более формально перефразирован следующим образом: "Сообщите значение атрибута "марка" для всех строк базы со значением атрибута "страна производ-ства", равным "США", и значением атрибута "дальность полета", превышающим "6 000". Этот смысл на некотором условном формальном языке можно было бы представить в следующей форме:

(1) Fм | FR | ( Fп = США) и (Fд > 6 000).

Снабдим слова нашего запроса словарными статьями, каждая из которых есть тройка (ТИП, ОРИЕНТАЦИЯ, ТЕЛО) - смысл последней составляющей будет понятен из приведенных словарных статей:

• Марка - (F, м, Fм),
• Самолет - (FR, -, FR),
• Производства - (F, п, Fп),
• США - (V, п, США),
• Дальность - (F, д, Fд),
• Свыше - (R, д, больше).

Пусть некоторая процедура распознавания числовых значений определяет "6 000 км" как значение ат-рибута Fд и приписывает ему статью (V, д, 6 000).

2.3. После подстановки статей вместо соответствующих лексем во входной фразе получим следую-щую цепочку (от каждой статьи здесь для наглядности оставлено только тело):

(2) Fм FR Fп США F больше 6 000

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

Правило 1: R _ V | У1 а (H1, op1, C1 * C2);

Здесь У1 - условие, требующее, чтобы ориентации обоих аргументов совпадали; ор1 - ориентация перво-го аргумента; С1 и С2 - тела соответственно первого и второго аргументов; H1 - вспомогательный тип "полуинтервал" (например, > 200, = 4,5 и т.д.); тело Н1 образовано конкатенацией (знак *) тел аргументов. После применения этого правила к последним двум составляющим цепочки (2) вместо них появится новая составляющая (Н1, д, 'больше 6 000').

Правило 2: F _ H1 | У1 а <П, ор1, '(' * С1 * С2 * ')'>;

П - в-спомогательный тип "предикат", тело образовано конкатенацией тел аргументов. Результат примене-ния правила к последним двум составляющим преобразованной цепочки есть составляющая (П, д, '(Fд боль-ше 6 000) ').

Правило 3: F _V | У1 а (П, ор1, '(' * C1 * 'равно' *C2 * ')').

Это правило восстанавливает опускаемое обычно в русском тексте отношение 'равно'. После него вторая и третья с конца составляющие заменятся на новую (П, п, '(Fп равно США) ').

Правило 4: П _ П а (П, -, С1 * 'и' * С2);

Смысл этого правила очевиден: оно превращает пару следующих друг за другом предикатов в конъюнкцию.

Правило 5: FR _ П а (LR, -, C1 * '|' * C2);

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

Правило 6: F _ LR а (S, op1, C1 * '|' * C2 * ')' );

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

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

3. Компоненты и правила

3.1. Выше элементы цепочки, обрабатываемой с помощью правил, мы называли составляющими. Это не совсем точно - грамматика правил, которую мы будем обсуждать ниже, не является грамматикой непо-средственно составляющих. Она допускает разрывы между аргументами правила и каждому нетерминаль-ному объекту в общем случае сопоставляет структуру более сложную, чем структура составляющих. Поэто-му далее объекты этой грамматики мы будем называть компонентами. Структура компоненты зависит прежде всего от сложности процесса анализа, т.е. от уровня процессо-ра, однако несмотря на существенные различия, все компоненты построены по одной схеме: каждая компо-нента есть четверка, включающая:

• имя;
• тип, всякому типу соответствует характеристика - набор признаков, каждый из которых мо-жет принимать фиксированное множество значений;
• описание, приписывающее конкретные значения всем признакам, входящим в характеристику данного типа;
• тело: несколько упрощая, можно сказать, что тело компоненты есть заготовка фрагмента выход-ной структуры (формулы запроса или ее семантического представления), снабженная ссылками, обеспечи-вающими его "сты-ко-в-ку" с телами компонент, вложенных в данную.

Остановимся несколько подробнее на структуре характеристики и тела.

3.1.1. Характеристика является описанием "внешности" компоненты: она содержит все сведения, необходимые для определения применимости правил. Вне зависимости от типа характеристика любой ком-поненты включает признаки, фиксирующие ее положение в анализируемой цепочке. В простейшем случае таким признаком может быть переменная (назовем ее зона), значением которой является множество позиций исходной строки, занимаемой данной компонентой. Очевидно, что для исходных компонент значение зоны равно номеру позиции соответствующей компоненты, а для компонент, образовавшихся в процессе анализа, зона, как правило, равна объединению значений зон аргументов. В зависимости от уровня процессора и типа компоненты ее характеристика может включать морфоло-гические, синтаксические, семантические и другие признаки. Что же касается компонент того простейшего типа, который рассматривался в нашем примере, отметим наиболее важный признак - ориентацию. Если в примере значением ориентации был символ соответствующего атрибута, то для реальной базы, состоящей не из одной, а множества "таблиц" и включающей сотни атрибутов, значением ориентации будет множество символов атрибутов и соответствующих таблиц. Так, для системы более реальной, чем рассмотренная в примере, слово "производство" могло относиться не только к стране, но и ко времени ("... производства до 1972 года ..."), а отношение "свыше" не только к дальности, но и к стоимости, расходу топлива, грузоподъ-емности и т.д. При этом условие У1 в правилах 1 - 3 будет требовать не совпадения, а пересечения ориентаций аргументов.

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

3.2. Правило в самом общем виде представляет собою импликацию

ИМЯ: УСЛОВИЯ ПРИМЕНИМОСТИ а ОПЕРАТОР,

все три части которой требуют специального рассмотрения.

3.2.1. Имя правила является структурным и состоит из трех элементов:

• номера группы,
• указателя ("начало", "основная часть", "конец"),
• номера правила.

Имена сопоставляются правилам однозначно и служат для определения порядка применения правил в процессе анализа. Если в ходе обработки не появляется явного указания к переходу на группу5 правил с не-которым конкретным номером, то группы правил участвуют в процессе одна за другой (начиная с первой) в порядке возрастания номеров. При переходе на очередную группу просматриваются по одному в порядке возрастания номеров все правила с указателем "начало". Для каждого очередного правила реализуется следующий цикл:

При исчерпании правил с указателем "начало" процессор переходит к правилам основной части, ко-торые могут просматриваться в любом порядке и применяться любое число раз (естественно, при выполне-нии каждый раз условий применимости соответствующего правила). После того как все правила основной части оказываются неприменимыми, процессор переходит к правилам с указателем "конец", просматривая их по порядку номеров так же, как это делалось для правил начала. По завершению работы с последним правилом текущей группы система переходит на группу со сле-дующим по величине номером. Таким образом, все правила организованы по принципу двухуровневого порядка: последовательность на уровне групп и частичный порядок внутри группы. Очевидно, что для организации применения правил в определенном порядке в тех случаях, когда это необходимо, хватило бы упорядочения на уровне групп (внутри группы при этом правила были бы не упорядочены, как в "основной части"). Однако обозримость такой структуры была бы существенно меньше ввиду возрастания числа групп: каждое правило с указателя-ми "начало" и "конец" должно было бы при этом выделяться в отдельную группу (состоящую только из это-го правила). Кроме содержательной группировки правил для разделения уровней обработки и повышения эффек-тивности процесса, упорядочение по группам позволяет успешно использовать в правилах простые контек-стные условия, о чем будет сказано ниже.

3.2.2. Условия применимости правила содержат описание некоторой конфигурации компонент в об-рабатываемой цепочке - обнаружение такой конфигурации является условием выполнения оператора дан-ного правила. Условия применимости в общем случае представляют совокупность условий разного вида:

• Требования, предъявляемые к отдельным компонентам, входящим в данную конфигурацию; в опи-сании каждой компоненты указывается значение некоторых признаков и, как правило, ее тип.
• Требования к согласованию значений некоторых признаков для тех пар компонент, у которых эти значения взаимообусловлены (например, согласование падежа и числа или пересечение ориентаций).
• Требование к взаимному положению компонент в цепочке (фикси-ро-ван-ный или свободный поря-док, возможность/обязательность разрыва и т.д.).
• Дополнительные условия, проверяемые с помощью логических процедур, использующих инфор-мацию из описания предметной области (см. ниже п. 9).

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

3.2.3. Оператор состоит из таких частей, как:

• Спецификация компоненты-результата (таких компонент может быть не одна, а несколько). Все части этой компоненты, кроме тела (т.е. тип, значения характеристик, зона), определяются в явном виде. Что же касается тела, то оно либо тоже может быть определено явно (например, выражением, вычисляющим его с помощью операций над телами компонент-аргументов), либо заменяется указанием процедуры, конструи-рующей его по параметрам, заданным ссылками на тела компонент-аргументов. Правило определяет несколько конкурирующих компонент в том случае, когда конфигурация, опи-санная в условиях применимости, порождает не одну, а несколько альтернативных гипотез (гипотезы, по-рождаемые одним правилом - несовместимы).
• Указание о том, исключаются ли из анализа какие-либо (или все) из аргументов.
• Указание о том, куда помещается новая компонента. Такое указание необходимо, если исключае-мые аргументы правила в цепочке стоят с разрывом (т.е. не рядом). Отсутствие этого указания означает, что новая компонента подставляется на место исключаемых аргументов.
• Информация о совместимости одного, некоторых или всех аргументов с компонентой-результатом6.
• Указание к переходу на группу правил с номером К. Отсутствие такого указания означает, что ра-бота правил продолжается в стандартном порядке, определяемом их именами.

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

Наиболее простым и естественным решением представляется развитие языка спецификации в виде последовательности вкладывающихся версий с тем, чтобы каждая из этих версий обслуживала соответст-вующий уровень процессоров. Разработка первой (наиболее простой) версии таких средств уже заканчивает-ся - предварительный ее вариант будет опубликован в одном из ближайших выпусков материалов по про-екту. Отметим, что при своем развитии язык спецификации компонент и правил будет сближаться с анало-гичным, но более универсальным (не ориентированным на обработку текста) языком для процессора BUMP [Нариньяни 1979 б], специализированные версии которого предполагается использовать в качестве прототи-пов основного процессора в старших моделях серии ЗАПСИБ.

* * *

Во второй части работы будет рассмотрена общая схема Л-процессоров ЗАПСИБ и функции основ-ных модулей, а также проблема автоматизации настройки универсального Л-процессора на конкретную предметную область.

Литература

Виноград 1978 - Виноград Т. Об одном подходе к изучению дискурса. В сб. "Взаимодействие с ЭВМ на естественном языке", Новосибирск, ВЦ СО АН СССР, 1978, с. 11-47.

Кандрашина и др. 1979 а - Кандрашина Е.Ю., Очаковская О.Н., Голубева Л.А. Экспериментальная вопрос-но-ответная система ВОСТОК-0. Описание средств для представления семантической инфор-мации. Препринт ВЦ СО АН СССР ? 174, 1979.

Кандрашина и др. 1979 б - Кандрашина Е.Ю., Очаковская О.Н., Голубева Л.А. Экспериментальная вопрос-но-ответная система ВОСТОК-0. Программная реализация. Препринт ВЦ СО АН СССР ? 200, 1979.

Левин-Нариньяни 1978 - Левин Д.Я., Нариньяни А.С. Экспериментальный минипроцессор: семантически-ориентированный анализ. В сб. "Взаимодействие с ЭВМ на естественном языке", Новосибирск, ВЦ СО АН СССР, 1978, с. 223-233.

Нариньяни 1977 - Нариньяни А.С. Работы по искусственному интеллекту в Вычислительном центре СО АН СССР. Доклад на Международной конференции по искусственному интеллекту, Репино, 1977.

Нариньяни 1979 - Нариньяни А.С. Восходящий недетерминированный процесс, его организация и приме-нения. Препринт ВЦ СО АН СССР ? 175, 1979.

Все права защищены. © 2000-2001 РосНИИ ИИ

Copyright. © 2000-2001 by RRIAI