Читаем Фреймы для представления знаний полностью

Видимо, оба вопроса следует попытаться решить на основе, предложенной У.Мартином(1974) в противовес идее о "поддержке" и задуманной как стратегия обращения с ошибками и неудачами. Нельзя ни передавать управление подчиненным структурам, ни полностью сосредоточить его на верхнем уровне; поэтому нам требуется такой интерпретатор, который имел бы доступ и к целям верхнего уровня, и к работе отдельных демонов. Терминалы различных типов нуждаются в различных типах процессов, поэтому одной стратегией здесь не обойтись. Заполнение пробелов терминала стены фрейма комнаты предусматривает поиск и заполнение конкретными данными субфрейма "стена" более низкого уровня, в то время как конкретизация терминала "дверь" предусматривает присоединение фрейма комнаты к фрейму дома. Для включения в каждый фрейм данных относительно действий подобного типа каждый терминал мог бы указывать интерпретатору на те инструкции, где сказано, как собирать нужную информацию и как реагировать в случае трудностей и различного рода неожиданностей.

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

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

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

Цель работы системы зрительного восприятия заключается не в том, чтобы постоянно отыскивать все находящиеся вокруг нас предметы; ее главной задачей является помощь в выработке ответов на вопросы путем объединения визуальной информации с предположениями, вырабатываемыми внутренними процессами. Однако в любом случае мы должны иметь возможность правильно ориентироваться в пространстве относительно нашего ближайшего окружения, что, кстати говоря, требуется для ответа на большинство из встающих перед нами вопросов. Поэтому определенная часть процесса конкретизации будет выполняться независимо от каких бы то ни было специальных вопросов или целей. Ясно, что нам требуется такой механизм, который умел бы "идти на компромисс" и позволял бы легко заменять "слабые" задания отсутствия при выявлении демонами непредвиденных обстоятельств.

Структура управления "продукциями" А.Ньюэлла и Г.Саймона (1972) образуется последовательным расположением (в некоторой памяти) локальных правил поведения. В системах, подобных языку CONNIVER (А.Макдермотт, Дж.Суссман, 1972), существуют явные структуры управления высших уровней; однако и здесь многое зависит от того, какие утверждения (аналогичные "продукциям") активны в данный момент; такой вид управления полностью явным уже не назовешь. Обе эти системы характеризуются высокой степень" локального процедурального управления. Все, что удается заметить, сопоставляется со своим "образцом-предшественником", который вызывает другой субфрейм, подключает его к процессу поиска и выполняет некоторые предписанные им функции.

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

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

<p>4.2. Фреймы и процесс согласования (по С.Фальману (1974))</p>
Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT