Онтологические уровни

Мы уже неоднократно упоминали, что при составлении онтологии (выборе набора понятий, словаря) для создания и обсуждения моделей обязательно нужно, чтобы эту онтологию разделяло какое-то сообщество. Самый простой способ моделировать – это взять (изучить) готовую онтологию (набор классов и отношений), уже принятую в нужной предметной области. Например, найти её в учебнике, стандарте, извлечь из базы данных, фреймворка, и так далее, а дальше – использовать её при описании тех индивидуальных физических объектов, с которыми вы хотите работать, и их отношений.

Ну а что делать, если такой онтологии нет? Что делать, если вы должны сами описать (отмоделировать) что-то для людей, которые про онтологии и не слышали?

Или что делать, если вы приходите в новую предметную область (в какой-то новый бизнес, или даже в новую фирму, работающую в том же самом бизнесе) – и вдруг обнаруживаете, что вокруг говорят на непонятном вам профессиональном языке, используют неизвестные вам термины, или используют известные вам термины, но в непонятных сочетаниях? А вам нужно коммуницировать с этими людьми, читать их модели, делать для них модели. И при этом учебник их языка вам не выдали.

Давайте опишем онтологическое моделирование (процесс описания индивидов, отношений, классов и типов), используя только что введённых нами понятия языков и мета-языков. Тогда станет понятнее, что и где искать, что использовать, а что создавать самим, для обеспечения успешности работы по моделированию. Организуем наши представления по уровням:

1. Мир: объекты. Это не модель, это реальный мир, это конкретные физические объекты, или ментальные объекты, выделяемые из фона. Ментальные объекты (категории, концепции, идеи) в наших головах (до их фиксации в экзокортексе, вне головы) тоже существуют в мире, мы выделяем их и моделируем на следующих уровнях. Мы строим модели мира, реальный (но иногда воображаемый, возможный, альтернативный) мир всегда должен быть первым предметом рассмотрения!

2. Экземпляры модели(индивиды, модели конкретных объектов). На этом уровне мы располагаем уже модели объектов в мире, то есть объектов, выделенных на предыдущем уровне. Тут мы работаем с описаниями, и то, что расположено на этом уровне – уже не объекты, а знаки, отсылающие к каким-то объектам. Это в общем-то основной продукт работы – перечисление (модель) конкретно ваших объектов, их свойств (характеристик) и связей между ними. Именно это является предметом интереса в коммуникации с вашими коллегами, собеседниками.

Такую модель ещё называют *операц**ионной моделью/*онтологией экземпляров

Моделью экземпляров может быть просто текст, описывающий объекты интереса.

Данные в компьютерной базе данных (само содержание таблиц СУБД) – тоже находится на этом уровне. В этих таблицах могут быть перечислены и описаны ваши объекты с инвентарными номерами и конкретными значениями их атрибутов (характеристиками).

Но и простая заполненная электронная таблица (точнее, её содержание) – это тоже модель экземпляров.

На этом уровне мы выделили (достаточно условно) именно модели индивидов (физических объектов). Далее, на более высоких уровнях, будет происходить то же самое – работа с моделями. Но это будет работа с объектами ментального пространства, которая необходима для понимания вашими собеседниками моделей уровня экземпляров.

3. Модель данных (система классов, рабочая онтология). Это уровень выделяется для описания (моделирования) уже не экземпляров, а того языка, на котором мы описываем экземпляры. Модель данных определяет, как мы классифицируем экземпляры, то есть по каким классам (категориям) мы их обязательно раскладываем, какие характеристики (атрибуты) учитываем, какие отношения находим.

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

Если модель экземпляров – карта, то модель данных – её легенда.

Если модель экземпляров – это таблица (включая какую-то сложную таблицу для анкеты или отчёта), то её модель – это «пустографка» - формат таблицы с названиями столбцов, строк, ячеек, инструкциями по их заполнению.

Модель данных СУБД – это специальный объект, составлению и поддержке которого программистов баз данных специально обучают.

Повторим, что модель данных задает шаблон описания(шаблон модели экземпляров). Шаблон определяет две важные вещи:

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

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

Так как модель данных – это уже модель модели, мы понимаем теперь, что её она является мета-модель**ю. Мы будем называть модель этого уровня «мета-С модель» - от слова «ситуационная». В ней как раз находятся те классы и отношения, которые «исторически сформировались» в вашей фирме, были выделены по ситуации*,* исходя из практического опыта, сформировали внутренний жаргон фирмы и перекочевали оттуда в документы, экселевские таблицы, самописные базы данных. Это уже почти онтология – но она, как правило, не слишком формализована, не очень подробно описана, и разделяется (понимается) только внутри нашей фирмы.

Хотя бывают и другие ситуации – когда мета-С модель в организации продумана, зафиксирована в виде корпоративных стандартов, включает обширные справочники, управление которыми идёт через систему мастер-данных. И всё это учитывается при создании корпоративных ИТ-систем. Так выглядит в некотором смысле идеальное состояние корпоративной модели данных.

Граница между моделью данных и следующим уровнем достаточно размыта, но важно понимать, где она может проходить.

4. Прикладная онтология (онтология предметной области).

При более пристальном взгляде (например, когда мы начинаем организационные преобразования в фирме, реинжиниринг бизнес процессов, внедрение новой ИТ-системы (ERP, PLM, или даже относительно простых систем ЭДО или бухгалтерии) – мы обнаруживаем, что наша ситуационная исторически сложившаяся мета-С модель на самом деле является версией (иногда упрощённой, иногда более развитой, иногда просто переименованной) какого-то более или менее известного (стандартного, общеизвестного, устоявшегося, классического) подхода к моделированию в предметной области. Это уже точно именно онтология предметной области, то есть она разделяется каким-то большим сообществом (больше, чем ваша фирма).

Такой «общеизвестный источник» для нашей модели можно считать ещё одним уровнем в нашей иерархии мета- , ведь это тот язык, на котором можно описать наш ситуационный язык. Будем называть модель (онтологию) этого уровня «мета-Умодель», от слова «учебник».

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

Мета-У модели можно поискать в каталогах поставщиков оборудования, по которым что-то покупаете вы, и ещё множество таких же фирм, как ваша.

Ещё одним возможным источником для мета-У онтологий являются широко распространённые компьютерные программы, типа программ для бухгалтерского учёта, управления бизнес-процессами, или софт для проектного управления.

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

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

Это вообще важно учитывать: переходя на какую-то компьютерную программу, автоматизирующую деятельность вашей фирмы – вы покупаете вместе с программой её онтологию, встроенную в неё мета-У модель. Ваша фирма не просто поменяет бизнес-процессы (это обычно понимается), но и будет вынуждена перейти на новый мета-язык, и связанные с этим ментальные издержки не всегда оцениваются адекватно. (Фирма, конечно, может заказать софт, реализующий в точности её мета-С модель, но это будет дорого и, скорее всего, вредно.)

Может быть, в конкретной фирме когда-то мета-С модель отличалась сильно, но, по мере роста фирмы, прихода высококвалифицированных и образованных сотрудников, внедрения нового софта – она заместилась мета-У моделью. Поэтому сравнительно часто вы вообще можете обнаружить в компании только минимальную разницу между мета-С и мета-У моделями. Чаще всего отдельные классы мета-У модели специализируются – в них выделяются подклассы мета-С модели, нужные для более точного отражения картины мира (структуры данных). Но это разделение не является обязательным, и граница этих двух моделей данных – не всегда явная!

Однако если вы, высококвалифицированный и образованный специалист, вдруг на новом месте обнаруживаете непривычные вам термины, выражения, коппьютерные интерфейсы – вы, возможно, столкнулись именно с мета-С моделью этой конкретной компании, и вам надо её изучить, связав особенности нового места работы с прекрасно известной вам профессиональной мета-У моделью и её онтологией.

Например, в системе управленческого учёта фирмы вы можете обнаружить классификаторы расходов и поступлений, отражающие взгляд её собственников – мета-С модель. А вот в налоговом учёте вы вряд ли найдёте что-то, отличающееся от законодательно определённой мета-У модели.

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

Баба и деда, бабушка и дедушка, сынишка и отпрыск – это всё могут быть понятия мета-С модели вашей семьи, расширенной семьи, общины или культурного слоя. Но в отношениях с государственными органами, при заполнении анкет и заявлений, вы будете использовать официальную терминологии Семейного кодекса и выпущенных государством регламентов, и это – мета-У модель.

5. Система типов **(**верхняя онтология). Если принимаются какие-то усилия по дальнейшей формализации, то на следующем уровне как раз находятся уже обсуждавшиеся нами системы типов:

• Система типов BORO (Физический объект, Класс, Кортеж).
• Созданная как расширение BORO система типов нашего руководства (ФФО, МФО, Роль, Описание).

Система типов определяет, какие типы объектов могут быть в моделях данных: мета-У и мета-С моделях. Это тот же механизм, который работает, когда классы из модели данных (мета-У или мета-С) определяют классификацию индивидов в модели экземпляров.

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

6. Язык записи. В иерархию мета-уровней можно включить в качестве следующего уровня тот язык записи, которым мы пользуемся для описания предыдущих уровней**.** Как правило,на верхних уровнях в качестве мета-языка выступает уже естественный язык, русский или английский. Книжка BORO написана на английском, мы описывали систему типов в предыдущем разделе на русском языке.

Но диаграммы BORO, которые вы найдёте в книжке – это специальный графический мета-язык, разработанный для описания языка BORO.

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

Наконец, формальные языки описания данных для компьютерной обработки (XML, RDF, UML, Express) – это мета-языки верхнего уровня, каждый со своей мета-мета-моделью, что позволяет нам подняться по иерархии мета- ещё и ещё выше.

Стандарт Meta-Object Facility (https😕/en.wikipedia.org/wiki/Meta-Object_Facility) является примером стандартизации формальных языков моделирования для описания компьютерных систем и их интерфейсов. В нём система типов явно поделена на уровни, из которых M****0 концептуально примерно соответствует нашему уровню экземпляров, M****1 – уровням мета-С и мета-У, M****2иM****3 - системе типов. Эти соответствия весьма условны, но иллюстрируют общие принципы построения онтологий.

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

Например, есть описанная нами выше экстенсионалистская картина мира, или картина мира, основанная на семиотической схеме треугольника Фреге.

А ещё бывает конструкционистский подход, постулирующий, что все объекты (физические и ментальные) получаются только из других объектов путём операций конструирования. При таком подходе онтолог не обнаруживает объекты в мире, а должен явно построить их (сгенерировать), начиная с очень небольшого количества изначально заданных объектов, и определив набор операций конструирования. Объекты, полученные таким способом, не будут иметь проблем, например, с отношением «часть-целое» (всегда можно будет понять, к каким объектам оно применимо, а к каким нет), или проблем, которые могут возникать, когда мы пытаемся понять, какой из двух классов включает в себя другой. Объекты в такой онтологии возникают в определенном порядке, с помощью определенных операций, и мы знаем в рамках этой онтологии, какая операция к чему привела.