УМОЗАКЛЮЧЕНИЯ И ЗНАНИЯ (ЧАСТЬ II)[59] СИСТЕМА, БАЗИРУЮЩАЯСЯ НА ’’ДЕМОНАХ"
В конце нашей первой статьи мы рассмотрели язык программирования PLANNER. Мы отметили, что в этом языке имеются определенные средства для вывода умозаключений и представления знаний.
Но насколько удачны эти средства? Один из недостатков языка PLANNER был уже отмечен выше. Поскольку PLANNER — это и язык программирования, и теория использования знаний, его можно реализовать самыми разнообразными способами, при этом весьма трудно усмотреть конкретные ограничения, диктуемые данным языком. Подобная гибкость является достоинством для языка программирования, но делает слабой соответствующую теорию. Итак, первый недостаток языка PLANNER как теории представления знаний и вывода умозаключений состоит в том, что это теория с большой степенью неопределенности.Естественно, что названный недостаток затрудняет определение других недостатков. Для того чтобы выявить их, нам придется отвлечься от самого языка PLANNER и рассмотреть способы его использования. В частности, мы остановимся на работе Чарняка, посвященной анализу детских рассказов (С h а г п і а к, 1972).
Это поможет нам показать, что некоторые недостатки названной модели, в сущности, являются недостатками языка PLANNER как такового.
Задача модели (или системы) Чарняка совпадает с одной из задач, о которой говорилось в нашей первой статье: она состоит в генерации разумных ответов на вопросы по достаточно простым исходным текстам (детским рассказам).
Janet needed some money. She got her piggybank (PB), and started to shake it. Finally some money came out.
‘Дженет были нужны деньги. Она достала свою копилку и начала трясти ее. Наконец деньги высыпались.’
Типичными вопросами будут следующие:
Why did Janet get the PB?
‘Почему Дженет достала копилку?’
Did Janet get the money?
‘Достала ли Дженет деньги?*
Why was the PB shaken?
‘Почему трясли копилку?’
Читателю следует отметить, что для нахождения ответов на подобные вопросы нужны знания о мире действительности.
Данная модель направлена исключительно на решение задачи использования необходимых знаний о действительности при выводе умозаключений, тогда как проблемы, касающиеся естественного языка как такового, специально не рассматриваются. В особенности это касается синтаксиса; правда, в модели отчасти отражаются проблемы, которые лежат на стыке между синтаксисом и теорией умозаключений (например, установление кореферентных связей для именных групп), но здесь мы эти проблемы затрагивать не будем.Мы исходим из того, что рассказ, подающийся на вход модели, сразу же преобразуется в семантическое представление, удобное для вывода умозаключений. Семантическим представлением фразы будем называть набор утверждений, записанных на языке MICRO-PLANNER. Модель будет пытаться "заполнить пробелы" рассказа, анализируя его пофразно. Так, она будет пытаться устанавливать связи между событиями рассказа (обычно это причинные связи) и вставлять пропущенные факты там, где это покажется важным.
’ДЕМОНЫ*4 И БАЗОВЫЕ СТАНДАРТНЫЕ ПОДПРОГРАММЫ
Рассмотрим следующий факт:
(1) If "it is (or will be) raining" and if "person P is outside" then ”P will get wet".
‘Если ’’идет (пойдет) дождь" и если ’’лицо Р находится на улице", то ”Р промокнет".’
У всех нас есть интуитивное убеждение, что (1) — это факт о ’’дожде", а не, скажем, об ’’улице". На улице случаются разные вещи, и то, что некто промокнет,— лишь одна из них. С другой стороны, во время дождя происходит лишь ограниченный набор событий.
Мы вводим это убеждение в нашу систему, приписывая правило (1) единице rain ‘дождь’ с тем, чтобы при появлении в рассказе понятия ”rain“, встал вопрос о возможности использования правила (1). Будем говорить, что rain — это понятие -тема (или центральное понятие; topic concept) для правила (1). Когда в рассказе встречается некоторое понятие-тема, факты, приписанные этому понятию, могут быть использованы при выводе умозаключений.
(Будем также говорить, что эти факты подаются на вход аппарата умозаключений в качестве исходных утверждений.) Итак, если понятие-тема, например ”цирк“, не встретилось, то программа не сможет обратиться к тем фактам, которые приписаны именно этому понятию.Отметим, однако, что мы не требуем непосредственного упоминания в тексте слова rain, прежде чем мы сможем использовать (1). Необходимо только, чтобы в базу данных было введено утверждение о ’’дожде". Сформировать же утверждение о том, что идет дождь, программа может под воздействием фактов, содержащихся в других частях рассказа, например:
One afternoon Jack was outside playing with Bill. Bill looked up and noticed that the sky was getting dark. ”1 think we should stop" said Bill. ”We will get wet if we keep playing".
‘Однажды днем Джек играл на улице с Биллом. Билл посмотрел вверх и заметил, что небо темнеет. ”Я думаю,нам надо остановиться,— сказал Билл.— Если мы будем продолжать играть, мы промокнем".!
В этом примере предполагается, что если небо днем потемнело, то это означает приближение дождя. Если данное соотношение занесено в базу данных, то этого будет достаточно для того, чтобы вызвать факты, приписанные понятию ”дождь“.
Отметим также, что понятие-тема не обязательно должно иметь однословную манифестацию в качестве "ключевого слова". Существуют факты, к которым система может обратиться только через сложный набор связей в базе данных. Факт может быть сколь угодно сложным, он может также активизировать другие факты в зависимости от наличия или отсутствия определенных отношений в рассказе.
Проспективный и ретроспективный поиск. Не исключен случай обращения системы к некоторому факту тогда, когда мы еще не располагаем всей информацией, необходимой для его использования. Важно иметь в виду, что мы делаем умозаключения в процессе движения по тексту. Поэтому, если требуемая информация поступает лишь после того, как было вызвано соответствующее правило, мы должны осуществлять вывод умозаключений в том месте, где накоплена информация.
Так, могут встретиться обе последовательности:(2) Jack was outside. It was raining.
‘Джек был на улице. Шел дождь.’
(3) It was raining. Jack was outside.
‘Шел дождь. Джек был на улице.’
Пример (2) не содержит трудностей. В тот момент, когда мы вводим понятие дождя, в нашем распоряжении имеется достаточная информация для использования правила (1) и вывода умозаключения о том, что Джек должен промокнуть. В примере же (3) мы узнаем о том, что Джек был на улице уже после упоминания о дожде. Если мы хотим применить правило (1), мы должны уметь просматривать дальнейший текст в поисках нужного нам факта. Для этого мы будем представлять факты в форме антецедентных теорем языка PLANNER, таким образом, чтобы факт состоял из двух частей — образца и "тела" (последнее может быть любой программой на языке PLANNER). ”Тело“ теоремы применяется только тогда, когда в базу данных вводится утверждение, отвечающее образцу этой теоремы. Для (1) образцом будет ’’некто, находящийся на улице". Поэтому, когда при анализе текста (3) мы обращаемся к (1), в базе данных еще нет утверждения, которое отвечало бы образцу. Однако нужное нам утверждение содержится в следующей фразе, и потому программа, выводящая соответствующий факт, срабатывает. Мы будем называть поиск некоторого факта проспективным, когда понятие-тема встречается в тексте раньше, чем утверждение, отвечающее образцу. Те же случаи, когда утверждение, отвечающее образцу, предшествует понятию-теме, будем называть ретроспективным поиском (как в тексте (2)). (Это незначительное расширение антецедентных теорем в MICRO-PLANNER, которые могут пользоваться только проспективным поиском.)
Покажем на ряде примеров, насколько важную роль играет проспективный поиск.
(4) Janet was thinking of getting Jack a ball for his birthday. When she told Penny, Penny said, "Don’t do that. Jack has a ball".
‘Дженет собралась подарить Джеку на день рождения мяч. Когда она сказала об этом Пенни, Пенни ответила: “Не делай этого.
У Джека есть мяч".’Здесь фраза Jack has a ball ‘У Джека есть мяч’ интерпретируется в том смысле, что Джеку не нужен второй мяч. Общеизвестен факт, что во многих случаях человек, имеющий X, не хочет получить еще один X. Этот факт, возможно, следует отнести к информации о том, "чем руководствоваться при выборе подарков". В нашем случае соответствующая ситуация была упомянута в предыдущей фразе, где было сказано, что Дженет собиралась сделать Джеку подарок.
(5) Bill offered to trade his pocket knife for Jack’s dog Tip. Jack said "I will ask Janet. Tip is her dog too". ‘Билл предложил обменять свой перочинный нож на собаку Джека по кличке Тип. Джек сказал: "Я посоветуюсь с Дженет. Тип — это и ее собака"/
Последняя фраза интерпретируется как причина, в связи с которой Джек должен посоветоваться с Дженет, и является информацией об отношениях между обменом и собственностью.
(6) Janet wanted to get some money. She found her piggybank and started to shake it. She didn’t hear anything.
‘Дженет нужны были деньги. Она нашла свою копилку и начала трясти ее. Она ничего не услышала.’
Последняя фраза означает, что копилка была пуста, что следует из знаний о копилках.
В каждом из приведенных примеров информация, используемая для получения нужной интерпретации, со-
держится в одной из предшествующих фраз. Так, в примере (4) фраза Jack has a ball ‘У Джека есть мяч’ сама по себе не означает, что "не надо давать ему второй мяч". Если бы это было так, нам бы понадобилась специальная проверка для отсечения этого умозаключения в ситуациях типа:
Bill and Dick wanted to play baseball. When Jack came by Bill said. "There is Jack. He has a ball". ‘Билл и Дик хотели поиграть в бейсбол. Когда мимо проходил Джек, Билл сказал: ’’Вон Джек. У него есть мяч".’
Tom asked his father if he would buy him a ball. "Jack has a ball" said Tom.
‘Том спросил отца, купит ли он ему мяч. ”У Джека есть мяч",— сказал Том.’
Bill’s ball of string was stuck in the tree.
He asked Jane how he could get it out. Jane said, ’’You should hit it with something. Here comes Jack. He has a ball".‘Веревочный клубок Джека застрял на дереве. Он спросил Джейн, как его достать. Джейн сказала: ’’Его надо чем-нибудь вышибить. Вон идет Джек. У него есть мяч".’
Факты были представлены нами в форме антецедентных теорем из-за очевидной необходимости проспективного поиска. Далее, однако, мы будем называть эти факты не антецедентными теоремами, а ”демонами", поскольку это более короткое и выразительное название.
Спецификация и «выключение» демонов. Следует подчеркнуть, что модель получает информацию, содержащуюся в демонах, не в результате самостоятельного ’’познания". Эта информация вводится создателем модели. С другой стороны, демоны не специфичны для того или иного текста, поскольку в них нет таких единиц, как red ball ‘красный мяч’ или Jack ‘Джек’. Они содержат обобщенные сведения типа a person X ‘лицо X’, которому в одном месте будет соответствовать имя Джек, а в другом — Билл. Мы предполагаем наличие механизма связывания некоторых переменных ("спецификации" демона) в момент, когда данный демон вводится в действие.
Далее, мы хотим, чтобы демоны действовали только тогда, когда они релевантны для рассказа. Рассказ может начаться с разговора о подарке Джеку, а потом перейти к играм, в которые играют дети у него в гостях. Нам нужны способы "выключения" демонов, которые уже не нужны на данном этапе рассказа. (Нерелевантный, но действующий демон не только отнимает время и место, но и может вызвать неправильную интерпретацию фраз.) В первом приближении будем считать, что демон объявляется нерелевантным по окончании обработки определенного количества фраз в тексте.
Базовые стандартные подпрограммы. До сих пор мы говорили, что обращение к демонам производится тогда, когда в тексте встречается соответствующее понятие. Но из этого следует, что существуют некоторые указатели, приписанные понятию, которые показывают, к каким именно демонам следует обратиться.
Если мы обратимся к конкретному примеру, скажем, примеру (5), мы заметим, что именно предложение Билла произвести обмен явилось основанием для дальнейшего хода событий. Мы исходим из того, что информация, отвечающая за обращение к демонам, записана в форме подпрограмм. Эти стандартные подпрограммы мы будем называть ”базовыми стандартными подпрограммами".
Отношения между базовыми подпрограммами и демонами можно представить следующим образом:
Базовая стандартная | |||
подпрограмма | |||
центрального понятия | |||
вызывает | |||
ПРОГРАММА: | |||
ИМЯ ДЕМОНА | |||
(образец) |
Эти базовые подпрограммы отвечают не только за обращение к демонам. Пусть нам сообщается, что у Джека есть мяч, а у Билла — волчок. Затем Джек обменивает свой мяч на волчок Билла. Теперь мы можем задать вопрос: "Кому сейчас принадлежит волчок?" Поскольку вопросы владения существенны для наших рассказов, мы хотим быть в курсе соответствующей информации. В нашем конкретном случае о перемене владельцев предметов нам должно сигнализировать высказывание с упоминанием понятия trade ‘обмен’.
Итак, каждый раз, когда будет происходить обмен, нам нужно будет иметь сведения о перемене владельцев; поэтому при каждом появлении понятия trade мы должны запускать в действие соответствующую базовую подпрограмму. Конечно, программа должна быть не столь прямолинейной, чтобы считать фиксацией обмена такие фразы, как I will trade... ‘Я обменяю...’ или Will you trade...? ‘Не обменяешь ли ты...?’
Хорошим тестом для проверки того, следует ли относить какой-либо факт к базовой подпрограмме или к демону, может служить то, в скольких фразах выразима соответствующая информация. (Естественно, мы отвлекаемся от того, что фразы можно объединять в одну сочинительными союзами. Речь идет только об интуитивной проверке того, какое утверждение нам необходимо — сложное или достаточно простое.) Так, мы видели, что фраза Jack has a ball ‘У Джека есть мяч’ сама по себе недостаточна для умозаключения о том, что Джеку не нужен второй мяч. Поэтому соответствующее отношение следует отнести к демону, а не к базовой подпрограмме.
УПОРЯДОЧЕНИЕ ФАКТОВ ВО ВРЕМЕНИ И ПОИСК ФАКТОВ
Состояние в текущий момент и упорядочение фактов во времени. Мы рассмотрели две части нашей модели — демоны и базовые подпрограммы. В настоящем разделе будут описаны две ее оставшиеся части. Вернемся к ситуации, когда у Джека был мяч, у Билла — волчок, и они обменялись. Если мы теперь говорим, что у Билла есть мяч, то это имплицирует отсутствие мяча у Джека. То есть мы должны некоторым способом убрать из базы данных утверждение о том, что Джек владеет мячом. Однако мы не хотим полностью забывать об этом факте, так как он нужен нам для ответов на вопросы о том, кто владел мячом до Билла. Вместо этого мы хотим пометить соответствующее утверждение как имевшее место в прошлом. Мы исходим из того, что существует специальный аппарат, достаточно независимый от других частей модели, который отвечает за постоянное обновление информации. Назовем этот аппарат ”упорядочением фактов во времени11 (book-keeping).
Поиск фактов. Чтобы заключить, что один факт сменяет другой, тоже требуются специальные знания. Пусть мы имеем:
(7) Jack was in the house. Sometime later he was at the store.
‘Джек был в доме. Некоторое время спустя он был в магазине.’
Мы хотим, чтобы на вопрос Is Jack in the house? ‘Находится ли Джек в доме?’ система отвечала No, he is at the store. ‘Нет, он в магазине.’ Но как аппарат упорядочения фактов во времени получит этот ответ? В нем имеется простое правило, согласно которому ((состояние) А В) сменяет ((состояние) А С), где В=+С. Например, (AT JACK FARM) ‘(НА ДЖЕК ФЕРМА)’ может сменить (AT JACK NEW- YORK) ‘(В Джек Нью-Йорк)’. Но в примере (7) мы не можем просто искать утверждение AT JACK (someplace which is not the store) ‘В ДЖЕК (некоторое место, не являющееся магазином)’, поскольку Джек находится именно в доме. Еще более сложным примером является следующий:
Jack was in the house. Sometime later he was in the kitchen.
‘Джек был в доме. Некоторое время спустя он был на кухне.’
Для решения этой проблемы нам понадобится теорема (8):
(8) Для того, чтобы установить, что некто (PERSON) не находится в месте (LOC),
надо выяснить, где находится PERSON, и назвать это место X.
Если X=LOC, теорема ложна, выдать ответ ’’нет". Если X является частью LOC, выдать ответ ’’нет". Если LOC является частью X, попытаться найти другое значение X.
Если другое значение X не найдено, выдать ответ ”да“.
Для примера (7) аппарат упорядочения фактов во времени попытается доказать, что Джек не находится в магазине, с помощью использования (8) и утверждения, что Джек находился в доме. Затем первая из двух фраз будет отмечена как относящаяся к более раннему времени. Теоремы типа
(8) мы будем называть аппаратом "поиска фактов". Они будут представлены в форме консеквентных теорем языка
MICRO-PLANNER. (В частности, это касается (8), которая упоминалась в нашей первой статье, правда, в форме антецедентной теоремы.)
Основная идея при введении аппарата поиска фактов состоит в том, что этот аппарат используется для нахождения фактов, которые не слишком важны, в связи с чем их не хотелось бы вводить в базу данных. Например, в случае
(7) нежелательно вводить факт "Джек не находится в доме" наряду с фактом "Джек находится в магазине". Аппарат поиска фактов отвечает и за умозаключения типа "(лицо) знает (факт)", выводимые через посредство вопросов типа "находилось ли (лицо) в том месте, где произошел (факт), или присутствовало при его упоминании?" Подобная информация может легко быть выведена, и в то же время она не слишком важна, поэтому ее не следует непосредственно записывать в базу данных.
Таким образом, наша модель имеет следующий вид:
пять ВОПРОСОВ
Чтобы суммировать вышесказанное, вернемся к нашим пяти вопросам и посмотрим, какие ответы на них дает рассмотренная модель. Однако при ответе на вопросы следует быть особенно внимательным, поскольку, как мы увидим, эта модель (так же как и те, которые будут рассмотрены ниже) некоторым образом отвечает на все эти вопросы. Это объясняется тем, что модель воплощена в машинные программы, а в таком случае опустить тот или иной вопрос просто невозможно. Все же в нашем изложении говорилось очень немногое, например о семантическом представлении, и данная модель в действительности вообще не включала в себя разработку вопросов, связанных с семантическим представлением.
Выходом из названного противоречия является строгое разграничение между машинной программой и той теорией, которая воплощена в машинной программе. В литературе много говорилось об отношениях между программами и теориями. К этому мы хотим добавить одно разграничение. Это разграничение весьма просто. Если лицо Р пишет программу ИИ, которая выполняет задачу Т, то теорией, которой руководствуется Р при моделировании Т, являются те части программы, которые Т считает важными. Из данного определения следует, что в основе одной программы могут лежать две разные теории. Это похоже на ситуацию, когда два человека писали бы одну программу, но придерживались разных мнений относительно того, какие части программы важны.
Итак, принимая во внимание названное разраничение, попытаемся ответить с позиций рассмотренной теории на наши вопросы.
СЕМАНТИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ. О нем наша теория говорит весьма немногое. В сущности, единственное позитивное утверждение состоит в том, что не следует ограничиваться лишь небольшим набором семантических элементов. Например, в модели используются такие специфические, неэлементарные понятия, как "дождь", "копилка", "подарок". Может показаться, что это противоречит подходу. Шенка и Уилкса, которые используют семантические элементы (см. вторую статью Уилкса). Однако требование разложения единиц на семантические элементы, выдвигаемое этими исследователями, не исключает использования инструментов более высокого уровня. Фактически эти авторы не отрицают, что применение инструментов более высокого уровня может оказаться полезным.
ПРИМЕНЕНИЕ УМОЗАКЛЮЧЕНИЙ. Модель осуществляет только ненаправленный вывод во время обработки входного текста. Мотивировка такого подхода была дана выше, при описании аппарата умозаключений. Такой подход является единственно возможным в модели, использующей демоны.
ОРГАНИЗАЦИЯ. Теория, представленная выше,— это прежде всего теория организации. Она утверждает, что при наличии некоторого утверждения факты, необходимые для построения умозаключений, связанных с этим утверждением, выводятся в следующей последовательности: сначала с использованием базовых стандартных подпрограмм, а затем — с использованием демонов, активизированных базовыми подпрограммами. Иначе говоря, в нашей системе важный' для языка PLANNER принцип вызова процедур по образцу диктует способ расположения фактов.
МЕХАНИЗМ ВЫВОДА УМОЗАКЛЮЧЕНИЙ. Согласно рассматриваемой теории, механизмом вывода служат демоны, записанные на языке MICRO-PLANNER (или их эквивалент на другом языке программирования). В дальнейшем мы укажем на недостатки такого подхода, равно как и на недостатки принятого способа организации.
СОДЕРЖАНИЕ. Модель в своем настоящем виде не содержит требований о том, что в точности мы должны знать о тех понятиях, которыми манипулируем, таких, как, например, "копилка". В принципе можно использовать модель для формулирования подобных требований, но пока никаких шагов в этом направлении не делалось.
НЕДОСТАТКИ МОДЕЛИ
Существует много пунктов, по которым описанную модель нельзя считать удовлетворительной. Но мы рассмотрим только один из них, поскольку он связан с более общей проблемой использования языков программирования высокого уровня как средства для представления теорий знания и теорий вывода умозаключений.
Рассмотрим такой факт:
(9) Umbrellas are used to keep rain off one’s head. ‘Зонты используются для того, чтобы уберечь от дождя голову человека.’
Для введения этого факта в модель мы должны представить его следующим образом:
(10) Базовая стандартная подпрограмма, которая активизирует демон: "Возможность дождя". Образец: Человек достает зонт.
Программа: Если человек может попасть
под дождь, он достает зонт, чтобы не промокнуть.
Такая процедура будет хорошо работать для примеров типа:
It looked like rain. Jack got his umbrella. ‘Казалось, что должен начаться дождь. Джек достал свой зонт.’
Используя механизмы модели, о которых мы не упоминали, можно справиться и с такими примерами, как
As Jack was leaving the house he heard on the radio that it might rain. He went to the closet.
‘Когда Джек выходил из дома, он услышал по радио, что может пойти дождь. Он пошел в кладовку.’
На вопрос о том, зачем Джек пошел в кладовку, система ответит, что, возможно, он это сделал, чтобы достать зонт. (Другой возможный ответ состоит в том, что он хотел взять плащ, но для нас это не существенно, поскольку плащ также связан с дождем.) Для этого требуется дополнительный механизм, обладающий способностью объединять ожидание "доставания зонта" с нашими знаниями о том, где обычно зонты хранятся, для вывода о том, что Джек собирается достать свой зонт, хотя слово umbrella ‘зонт’ в тексте и не упоминалось.
Трудность заключается в том, что при таком подходе нельзя правильно понять примеры типа:
(11) Jack began to worry when he realized that everyone on the street was carrying an umbrella.
‘Джек начал волноваться, когда заметил, что у всех прохожих есть зонты.’
Вопрос: What was Jack worrying about?
‘Почему волновался Джек?’
Ответ: That it might rain, and he was without an
umbrella.
‘Мог пойти дождь, ay него не было зонта.’
Интуитивно совершенно очевидно, что здесь следует использовать факт типа (9), однако его формулировка (10), в том расплывчатом виде, как она записана, ничего не даст для понимания примера (И). Трудность состоит в том, что, поскольку (И) не содержит упоминания о дожде, демон, сформулированный в (10), не будет активизирован. Другими словами, наличие в (10) указателя, направленного от понятия "дождь" к понятию ’’зонт", не означает, что существует и указатель, направленный в обратном направлении — от понятия ’’зонт" к понятию ’’дождь", в связи с чем из (11) нельзя перейти к утверждению о возможности дождя. На самом деле найти решение для подобной
проблемы не сложно, например так: (12)
ЗОНТ ----------
Основные способі
Нажать на кноп
использования:*
(Защита человека от дождя)
ч.
Размер:-------
Цель*
Форма: —«— —
Плащ
В (12) утверждается следующее. Имеется заголовок, относящийся к понятию "зонт", который характеризует способы использования зонта с помощью указания на набор фактов такого использования. Использование зонта имеет указатель, направленный к понятию "зонт", поскольку для использования зонта необходимо иметь сам зонт. Отмечается также, что цель использования зонта — защита от дождя, а защита от дождя в свою очередь может осуществляться с помощью использования зонта. Подобные сведения, за исключением фактов, перечисленных под рубрикой "использование зонта", вовсе не напоминают программы, или демоны. Скорее, это сложный набор указателей, или, другими словами, "структура данных". Более того, как показано в работе (Charniak, 1975а), даже "использование дождя" нельзя рассматривать как программу, это скорее фрагмент данных.
Нельзя не признать, что наша аргументация носит спекулятивный характер. Прежде всего, мы утверждаем, что надлежащее представление факта (9) имеет форму фрагмента данных, а не программы, и это указывает на определенный недостаток системы PLANNER и процедурного подхода (см. статью Скрэгга в наст, сб.) вообще. Обе части нашего утверждения открыты для критики. Прежде всего можно представить себе такое видоизменение демона (10), которое позволило бы использовать его и при упоминании единицы umbrella ‘зонт’. Это видоизменение не является простым, поскольку программа должна принимать во внимание ряд условий, при которых следует активизировать этот демон, но в принципе оно возможно. В ответ на возражение такого рода мы можем повторить то, что мы говорили относительно исчисления предикатов первого порядка: если использование аппарата вступает в противоречие с внутренними свойствами самого аппарата, то это с большой вероятностью прогнозирует ошибочность такого подхода. (Справедливо и то, что четкой границы между программой и данными не существует. Одним из факторов, позволяющих судить о том, является ли некоторая структура программой или данными, служит степень детерминированности способов использования этой структуры. Если программу можно использовать более чем одним способом, то это ставит под сомнение сам ее статус программы. Попытавшись же модифицировать некоторую программу таким образом, чтобы она включала структуры типа (11), можно незаметно для себя превратить эту программу в набор данных.)
Отметим также, что, отказываясь от использования демонов для представления единичных фактов типа (9), мы тем самым отходим от принципа вызова процедур по образцу, с помощью которого мы получали доступ к важным для нас фактам. Иначе говоря, поскольку мы больше не представляем (9) в форме демона, исчезает разграничение образца и программы, которое придавало смысл концепции вызова процедур по образцу.
Но когда мы говорим, что (9) следует представлять в формате данных типа (12), а не в формате демона типа (10), мы вовсе не утверждаем, что знания вообще не следует представлять на языке PLANNER. Как было отмечено выше, PLANNER — это язык программирования, в связи с чем он обладает значительной гибкостью. Так, один из путей обхода рассматриваемой трудности состоит в том, чтобы не выделять утверждения (9) в качестве отдельного демона, а включить его в программу, содержащую всю информацию из (12), но записанную на языке PLANNER. Тогда возражения сведутся к неоднократно повторяемой нами формуле: вызывает подозрения необходимость преодолевать свойства, внутренне присущие некоторому формализму.