Курс "Управление знаниями" - 2004 год

Часть 1 - Краткое содержание курса

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

Лекция 1 - 15 февраля 2004 г. Определение знания

Лекция 2 - 21 февраля 2004 г. Определение знания (продолжение)

Лекция 3 - 28 февраля 2004 г. Простейшие когнитивные процессы. Формула Брукса.

Лекция 4 - 6 марта 2004 г. Экспертные системы. Основные компонеты - база знаний(KB - knowledge base), машина вывода (inference engine), блок диалога с пользователем, блок диалога с экспертом и инженером знаний. Блок объяснений. Почему в них важен блок понимания. Примеры непонимания ЭС на входе и на выходе.

Лекция 5 - 13 марта 2004 г. Инженерия знаний - 1. Язык KNOW.

Лекция 6,7 (двойная) - 3 апреля 2004 г. ИНЖЕНЕРИЯ ЗНАНИЙ - 2.

Всеобщая информационная программная бизнес-среда (онтогенез).


Лекция 8,9 (двойная) - 10 апреля 2004 г. ИНЖЕНЕРИЯ ЗНАНИЙ - 2.

Всеобщая информационная программная бизнес-среда (семиотические проблемы).

Лекция 10 - 17 апреля 2004 г. ИНЖЕНЕРИЯ ЗНАНИЙ - 2.


Всеобщая информационная программная бизнес-среда (семиотические проблемы). Semantic Web как один из способов их решения. Бизнес обоснование, структура, состав SW.

Простейшие когнитивные процессы (продолжение). Концептуализация предметной области как процесс построения онтологии. Понятие бизнес объекта.

Одно из определений бизнес объекта:

A business object is an object that represents a concept/entity that exists in the definition of a business problem or its solution. Business objects are used to model the business domain and pecifically the problem to be solved. Business objects should be known to and visible (in some way) to the business users of the application. At the same time, objects used to provide visualizations--graphics objects--are not business objects since they exist only to enable the user to solve the problem using a computer. Likewise, objects that represent components or services within the computing environment are not business objects if they essentially represent computational mechanisms rather than concepts relevant to the operation of the business.

Granted there are some gray areas here, but once we accept this notion, we can start concentrating on supporting a level of abstraction that enables application developers to easily translate a conceptual model of the business problem to an object implementation without worrying about computational mechanisms and systems integrity issues that come with using a computer.
~