 |
|
| Протокол
является одним из наиболее
перспективных к развитию понятий. Он
достаточно строг (чтобы удовлетворить
потребности математиков в
формализованности), он достаточно полно
и эффективно используется в информатике
(чтобы быть своим среди программеров), он
достаточно функционален (чтобы играть
роль правил в различных системах) и,
наконец, у него почти нет
множественности толкования содержания,
что является большой редкостью по
нынешним временам.
Единственный недостаток протокола - это полное неприятие его гуманитариями. А совершенно напрасно, ибо Ритуал - это такой античный :-) предок протокола, а онтология является не более, чем попыткой протоколирования мира. К протоколу относится такая вещь как нотация, что заставляет нас сразу и всерьез искать общее в Протоколе и Языке. Описание технологического процесса - это тоже протокол. И вот в этом месте возникает (не знаю как у вас, а у меня всегда) вопрос о связи протокола и алгоритма. Важный такой вопрос. Упирающийся и в структуру, и в формат и в возможность эволюции протокола как информационной сущности, без которой [этой эволюции] невозможно создание системы ИИ. Пусть у нас есть две системы, которые обмениваются данными. Одна, назовем ее А1, генерирует коллекцию данных, другая (А2) принимает к обработке. Каковы условия возможности устойчивой поддержки такого потока? Системы должны иметь представление о формате данных. Этого достаточно. Это представление может быть реализовано предельно просто - мы имеем заголовок у коллекции данных, который типизирует объекты ее и код обработки внутри программы для каждого. Вопрос: как сделать так, чтобы изменение формата в А1 давал возможность продолжать обрабатывать данные в А2 корректно? Снова нет ничего проще: надо вместо идентификатора типа вставлять в коллекцию данных сам описатель формата (мы предполагаем, что обработка на уровне "элементарных" типов (байт) у нас не меняется). А как синхронизировать процесс обработки, когда есть множественность функций меняются условия ветвления? Опять без проблем: над описателем формата надстроить описатель обработки. В этом месте у нас должна возникнуть первое беспокойство: а есть ли у такого описания предельный верхний уровень? Как далеко можно зайти с нагружением протокола метаданными? (А в таком подходе мы сталкиваемся именно с ними.) Ответ ужасен: предельного верхнего уровня нет, более того, чем выше мы будем абстрагироваться, тем большая нечеткость нам потребуется, которая для некоторых задач может привести к невозможности решения. Второе беспокойство связано с описанием описания. Интуитивно мы предполагаем, что есть некий стандарт (снова метаданные и протокол) самого описателя. И это чаще всего (в условиях бытовых) именно так. А если системы А1 и А2 не имеют представления друг о друге? Каким должен быть протокол, чтобы дать А2 возможность обработать данные с А1? Можно ли избежать постоянно возникающей автореферентности такого протокола? Третье беспокойство связано с процессом обработки. Пусть А1 сильно развивается, а А2 тормозит. Каким должен быть протокол, чтобы не только дать возможность прочитать данные куда-то в буфер (пусть мы решили два предыдущих беспокойства), но и обработать их? Ведь в этом случае нужно, чтобы протокол включал в себя программу модернизации А2 до уровня А1!!! Вот такие любопытные проблемки. Прежде, чем приступать к написанию ИИ, необходимо найти удовлетворительные ответы к каждой. Мои подсказки я сформулирую в виде трех рисунков :-)
Алеф Эгг |
|
