Сложности разработки онтологий для айтишников, базовые онтологии Партриджа и Веста
Умение анализировать и разрабатывать онтологии предметной области — комплекс довольно сложных навыков. Если ему учить как следует, то нужен как минимум семестр теории и практики. Запишу некоторые базовые идеи:
1. Любая теоретическая и практическая деятельность всегда оперирует понятиями какой‑то онтологии. Эта онтология может быть неотрефлексирована, интуитивна, не описана, но она есть. «Онтология» у меня здесь = онтика = система понятий. Я знаю, что сам термин означает «описанную систему понятий» — логия. Но, в конце концов, хотя бы в форме нейронных связей в головах каждого человека складываются некоторые онтологии.
2. Разные люди как правило используют разные онтологии для одной предметной области. Разные онтологии (разная структура системы понятий и разная терминология) — одна из причин почему люди часто друг друга плохо понимают. Чтобы понимать друг друга быстрее для некоторых задач нужно договариваться об общей онтологии.
3. Онтология не может быть правильной или не правильной. Однако онтология может быть более эффективной или менее эффективной для решения некоторых практических задач.
4. Проектировщики баз данных и информационных систем (некоторые) «прокачали» свои онтологические навыки в связи с необходимостью моделирования данных. Раньше онтологическими вопросами занимались только философы, ученые и некоторые хорошо образованные люди.
5. Айтишники сосредоточены на разработке «предметных» онтологий в рамках задач автоматизации. Системы понятий многих видов человеческой деятельности, «гуманитарных», но не только, чрезвычайно сложны, ими айтишники не занимаются.
6. Разработка онтологии — это не разработка структуры БД. Одна и та же онтология предметной области может быть спроектирована чрезвычайно разным образом для одной и той же СУБД.
7. Значительная часть знакомых мне проектировщиков ИС разрабатывают структуры БД, не описывая онтологии, лежащие в их основы, полагая, что «хорошая» структура таблиц — это и есть правильное описание онтологии предметной области. Это ошибка. Наличие «концептуальной модели» ‑хотя бы частичного описания онтологии сильно упрощает взаимопонимание, а еще сильнее — проекты по развитию, интеграции, миграции данных ИС.
8. Онтология всегда многоуровневая. В задачах автоматизации уровни выглядят, например, так:
a. Первый уровень — реальные физические объекты (например, конкретная ложка с уникальным инвентарным номером. Или, например, конкретная задача по проекту, выполняемая конкретным человеком).
b. Второй уровень — типы объектов (например, для ложки: чайная ложка определенного дизайна; для задачи: задача по разработке API по протоколу SOAP).
c. Третий уровень — типы типов объектов (например, товары на реализацию, запчасти, задачи разработчика).
d. Четвертый уровень — типы типов типов объектов, например, базовые понятия методологии, по которой ведется разработка. Например, стандарт BABOK Guide задает некоторую базовую онтологию для задач по бизнес‑анализу, PMBOK задает некоторую базовую онтологию для задач по управлению проектами и т. д. Между этим и предыдущим уровнем может быть еще некоторое количество уровней.
e. Пятый уровень — онтология методологии описания онтологий (например, например 3D‑ или 4D‑протяженность, или, например, базовые типы объектов, приводимые в книгах Партриджа, Веста и проч. — о них дальше). Между этим и предыдущим уровнем также могут «затесаться» другие уровни.
9. Онтологии не всегда иерархия/дерево, может быть и сложный граф. Но об этом долго рассказывать.
10. Базовые понятия Партриджа (5 уровень): объект, отношение, состояние, событие, класс.
11. Базовые понятия Веста (7–5 уровни, сильно упрощенно): a. Вещь (thing) — речь об абстрактной сущности — всё в этом мире «вещь», «нечто».b. Пространственно‑временные объекты, абстрактные объекты.c. Абстрактные объекты: классы, отношения. Физические объекты: состояния, события, агрегации, индивиды.i. Намеренно сконструированные объекты (физические): функциональные объекты, социально сконструированные объекты, собственность, соглашения, контракты, организации, продукты, репрезентации.ii. Физические объекты: системы.iii. Физические объекты: спецификации требований.
12. Проектирование БД — это перенос части онтологической модели в структуру БД. Наличие концептуальной модели уменьшает вероятность плохого проектирования БД, но не исключает этого. Физическое проектирование на основе концептуального — задача не всегда простая. Объект онтологии не равно таблица. Отношение между объектами не равно отношение между таблицами (например, отношение между объектами в БД может быть спроектировано как несколько таблиц; например, некоторые типы объектов могут быть объединены одной таблицей и т. д.).
Мораль: онтологическое мышление не самая простая дисциплина для освоения, но она на порядок повышает «умность» проектировщика и повышает вероятность создания качественных ИС.
Ссылки:
1. Мэтью Вест. Разработка высококачественных моделей данных (русский перевод)
2. Chris Partridge. Business Objects: Re-Engineering for Re-Use
