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

Указать, какая фреймовая информация представляет для него интерес, пользователь может двумя путями: (1) с помощью меню и (2) посредством текстовой спецификации. Первый способ — бо­лее прямой, тогда как второй удобнее и интереснее.

В случае спецификации при помощи меню пользователь в пер­вую очередь указывает, о каком типе выражений он будет запра­шивать; после этого система просит его указать заполнитель для каждого слота в соответствующем фрейме. Например, чтобы вы­яснить, какие объекты из определенной сферы могут находиться в (in) некотором округе (a county), пользователь должен произ­вести выбор, как показано на рис. 2.

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

2-е и 4-е меню (см. рис. 2) содержат одинаковое множество для

выбора. Вот какой внутренний список получится в результате этих спецификаций:

Тип Выражения: Предложная Группа

Хозяин: (все)

Предлог: in

Дополнение: county

Как видно на рис. 2, в ходе спецификации с помощью меню систе­ма последовательно рассматривает каждый слот указанного типа

Рассматривается информация для некоторых из следующих типов выражений:

Адъективная Группа Группа Существительное- Определение ►■Предложная Группа Глагольная Группа Группа Функционального Существительного Проанализировать исчерпывающим образом

[возврат]

ЛОЭМИИ

(в Предложной Группе) ADDRESS *адрес’ CITY ‘город’ COUNTY ‘округ’ FOOD ‘пища’ PHONE ‘телефон’ RESTAURANT ‘ресторан’

•(все перечисленные) (Прекращение!)

Предлог (в Предложной Группе) [Кэтому моменту: (все) ...] IN V

WITH ‘с’ (другие)

(все перечисленные)

(Прекращение)

Аргумент Предлога (в Предложной Группе)

[К этому моменту: (все) IN ...]

ADDRESS

CITY

-►COUNTY

FOOD

PHONE

RESTAURANT

(все перечисленные) (Прекращение!)

Рис.

округе (county).

выражений, и на каждом этапе дает на выбор пользователю список текущих заполнителей, предусматривая также возможность указа­ния рассмотреть их все. Для таких слотов, где возможный запол­нитель принадлежит к открытой категории (либо к закрытой, но на текущий момент еще не имеющей полного списка заполнителей), предусматривается возможность выбрать какой-либо иной, не на­званный в меню заполнитель (см. меню № 3 на рис. 2). Наконец, для факультативных элементов выражений (например, прямое до­полнение глагола) пользователю дается возможность слот не за­полнять вовсе.

Пользователь, оперирующий текстовыми спецификациями, пе­чатает выражение, указывающее на все желаемые значения сло­тов, причем в порядке, не обязательно совпадающем с внутрен­ним. Можно включать „шумовые" слова, а символ „?" используется как указание на то, что представляют интерес все возможные значения. Например, спецификация запроса, аналогичная данной выше с помощью меню, будет иметь вид:

a? can be in a county...

‘в округе может находиться..?’

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

an employee can report to a manager ‘служащий может быть подотчетен управляющему’ an employee can be responsible for a project ‘служащий может быть ответственным за проект’ an employee can be the supervisor of a project ‘служащий может быть руководителем проекта’,

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

Хотя использование символа „?“ в вышеприведенном примере может показаться неестественным в сравнении с более „гладким" методом, при котором запрос будет иметь вид what can be in a county (‘Что может находиться в округе’), тем не менее избранный нами прием удобен в том отношении, что позволяет просмотреть любой слот фрейма, а не только те, которые заполняются именами (то есть отвечают на вопрос „что?").

Например, пользователь может задать такую спецификацию;

a city can be? a county

‘город может находиться ? округе’.

Она служит целям поиска всех предлогов, связывающих ‘город’ с ‘округом’. А спецификация

an employee can? a project ‘служащий может ? проект’

служит для обнаружения всех пар „глагол — постверб", связываю­щих employee ‘служащий’ с project ‘проект’. Мы предпочитаем иметь малое число простых и мощных механизмов, хотя в неко­торых ситуациях другие методы могут быть предпочтительнее. Для читателя, чье эстетическое чувство отличается от нашего, укажем альтернативу, получаемую простой модификацией алгоритма, опи­санного в разделе 7.

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

Например, отсутствие слов сап и can be, соответственно, в спе­цификациях

employee responsible for project employee report to manager

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

Какого рода сведения были даны?

Глагольная Группа с Поствербом Обычная Глагольная Группа Адъективная Группа

[возврат]

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

Эксплуатация нашей системы показала, что при текстовых спе­цификациях система находила единственно правильную схему в 80% случаев, более одной схемы — в 15% случаев, ни одной — в 5%. Чаще всего несколько правильных схем отыскивается, если предлог используется в глагольной группе как постверб. Напри­мер, если пользователь печатает

an employee can pick a project up

‘служащий может выбрать проект’,

то up отождествляется как постверб по занимаемой позиции.

an employee can pick up a project,

системе придется устанавливать, является ли UP поствербом. Хо­тя в целом мы стараемся избегать вопросов типа „да/нет“ (об этом см. ниже), мы все же решили допустить их в этой часто повто­ряющейся и предсказуемой ситуации:

Можно ли

AN EMPLOYEE CAN WORK FOR A MANAGER? (‘служащий может работать на управляющего*) перефразировать в виде AN EMPLOYEE CAN WORK A MANAGER FOR Да

^ _HeT

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

Which corridor is Stumberger’s office adjacent to?

‘К какому коридору примыкает контора Штумбергера?’

и пользователь принимает предложение системы помочь в поиске причин неудачи. Поскольку слово adjacent ‘примыкающий’ — при­лагательное, а прилагательные могут входить в состав адъектив­ных групп, система выдает всю текущую информацию о тех адъек­тивных группах, где слово adjacent заполняет слот „прил", все остальные слоты оставляя не определенными. Иначе говоря, систе­ма отреагирует так, как если бы пользователь своим запросом задал следующую спецификацию:

Тип Выражения: Адъективная Группа

Хозяин: (все)

Прилагательное: adj acent

Предлог: (все)

Дополнение: (все)

7. КАК ОБРАБАТЫВАЮТСЯ ТЕКСТОВЫЕ СПЕЦИФИКАЦИИ

Когда от пользователя получена текстовая спецификация, систе­ма должна: (1) определить, с каким типом выражений она имеет дело; (2) обнаружить новые слова, если таковые имеются; (3) объяс­нить неспецифицированные слоты, если таковые имеются. К примеру, положим, что пользователь печатает

an employee can be associated with а?

‘служащий может быть связан с ?’,

и положим далее, что системе еще неизвестно слово associated ‘связан’. В этом случае она, естественно, не может непосредствен­но ответить на запрос, но даст пользователю возможность по­полнить ее знания.

a employee can be?? with а ?

‘служащий может быть ?? с ?’,

где символ „??" указывает позицию незнакомого слова, а „?" по- прежнему обозначает изначально неспецифицированный слот. Следует заметить, что, во-первых, здесь задействовано шумопреоб- разование — применительно к AN (см. раздел 5), и, во-вторых, „шумовые" слова сап и be пока не устранены, так как они могут играть роль содержательных слов в схемах, отличных от адъективных групп.

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

а (объект-существительное) can be ?? (предлог) а ? На этом шаге может быть предпринята попытка сопоставить ее с внутренними схемами, представляющими приемлемые фреймовые спецификации.

Сопоставление со схемами, происходящее на этом этапе, бу­дет простым, и в нем

? соответствует любому слоту

?? соответствует слоту из „открытой" категории

х соответствует X

(х у...) соответствует любой единице из набора х, у,...

В нашем случае представлено единственное соответствие вышепри­веденной структуре:

а объект can be прил предлог а объект.

Данная модель, как известно системе, относится (в соответствии с замыслом разработчиков) к адъективным группам.

На этом этапе промежуточная структура, содержащая символ „??", рассматривается вновь и сравнивается с первоначальным определением, напечатанным пользователем. Пользователя просят подтвердить, что associated действительно является новым прила­гательным. Вызывается стандартная программа обновления лекси­кона, которая заносит туда слово associated как прилагательное.

Затем система удаляет „шумовые" слова, и таким образом падежные фреймы, которые нужно рассмотреть, задаются следую­щим образом:

Тип Выражения: Адъективная Группа

Хозяин: employee

Прилагательное: associated

Предлог: with

Дополнение: (все)

Наконец, система представляет одномерное меню, похожее на изо­браженное на рис.

В TELI выбор форматов для вывода на экран текущей информа­ции о фреймах, релевантной для осуществления спецификации поль­зователя, основан на желании

1) сделать возможным одновременную проверку и обновление информации, и

2) свести к минимуму число конкретных типов меню, предла­гаемых пользователю.

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

а)

Предложная Группа: EMPLOYEE IN DEPARTMENT (‘служащий в отделе*)

И

Выход ? Обновление I I

Предложная Группа: EMPLOYEE IN ?

DEPARTMENT ‘отдел’ IS

EMPLOYEE ‘служащий* Q

MANAGER ‘управляющий* ?

OFFICE *контора* E3

в)

PROJECT ‘проект*__________________________________ ?

Выход П Обновление ?

Рис. 3. Вывод на дисплей фреймов с разным количеством неопределенных слотов, которые могут быть объектом запроса.

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

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

Хотя мы решили, насколько возможно, воздержаться от настоя­щих да/нет-вопросов, главным образом вследствие их малой инфор­мативности, принятая нами схема с позициями выбора в скрытом виде представляет собой некоторое количество одновременных да/нет-вопросов. Так, когда пользователь проверяет в меню предло­га in позицию, для которой меткой ряда является city ‘город’, а меткой колонки — county ‘округ’, он по сути отвечает „да" на подра­зумеваемый вопрос „может ли город находиться в (in) округе".

9.