Онтология нужна для разделения труда в мышлении
Онтологическая работа важна, если вам когда-либо приходилось составлять какие-то формы или таблички для заполнения их какими-то людьми, то вы занимались онтологической работой, сами того не зная. Помним, что в колонке таблички вы пишете какой-то тип, а в строках таблички какие-то люди прописывают значения этого типа. И качественная или некачественная работа отличается тем, что вы или задумываетесь над тем, какого типа типы в заголовках ваших колонок (онтология) и что там ещё рядом пропущено из типов, на важность которых указывает более высокий уровень абстракции, чем тип колонки, или просто пишете какой-то тип, не задаваясь вопросом его типизации (работаете с онтикой, то есть нетипизированным «огрызком» какой-то более полной многоуровневой онтологии). Онтологическая работа (онтологическая инженерия/ontology engineering, можно спорить о том, говорить ли об этой работе как об инженерии, ибо она вроде не меняет непосредственно физический мир к лучшему, но аналогии с программной инженерией тут более чем прозрачные) даёт более точные описания ситуаций (объекты и отношения в этих ситуациях), в них упоминается больше важных объектов внимания и меньше упоминается отвлекающих это внимание неважных объектов.
Как и любую другую работу, онтологическую инженерию можно делать хорошо, если владеть мастерством онтологических рассуждений по трансдисциплине онтологии, но можно делать «интуитивно», то есть плохо — ибо в рассуждениях тогда нельзя будет заметить даже «новичковые» ошибки. Просто не будешь знать, что ты работаешь с какими-то типизированными объектами, просто ты «работаешь», и наверняка делаешь ошибки: просто потому, что не знаешь, «как надо», то есть не знаешь, что это ошибки. Эти ошибки незаметны, они оказываются вне сферы твоего внимания, «нет объектов, на которые надо поглядеть, чтобы обнаружить ошибку». Помним, что трансдисциплины, в том числе и трансдисциплина «онтология» — это прежде всего про собранность, про привлечение внимания к важному и возможность игнорирования всего остального неважного, которого в мире неизмеримо больше, чем важного!
Именно об этом подробно говорится при рассмотрении моделирования предприятия в курсе системного менеджмента, даются примеры моделирования. Для понимания всех нужных для моделирования типов нужно, конечно, закончить курс онтологики и собранности (про дисциплину онтологии рассказывается там, равно как там же рассказывается о том, как стать собранным не только лично, но и сделать собранным коллектив предприятия), затем как-то освоить системное мышление, методологию, системную инженерию и системный менеджмент (middle ontology нужно знать, чтобы успешно моделировать domain ontology, люди на предприятии рассуждают на уровне «рабочей онтологии» и ниже). Есть видео[1] наших выпускников, которые после знакомства со всеми этими курсами становятся понятными и воспринимаются как «руководство к действию». Впрочем, в современной версии курсов ШСМ всё это моделирование предприятия становится понятным и без таких видео, при этом особый упор делается на использование не специализированных, а универсальных моделеров. Грубо говоря, для моделирования в качестве экзокортекса используется любая внешняя память — более или менее приспособленная для целей моделирования, или даже не совсем приспособленная. Моделером лист бумаги и ручку делает тот, кто моделирует! То же относится к универсальным системам коллективного ведения компьютерных заметок, особенно к тем, в которых хорошо представлена табличная форма моделирования: notion.so, code.io и прочие productivity tools.
В «бытовой» жизни нельзя встретить полную, стройную и согласованную многоуровневую онтологию. В жизни вы обычно встречаете много плохо согласованных (то есть никак не согласованных!) онтик, как обрывков каких-то онтологий — это результаты самых разных и несогласованных между собой попыток моделирования мира. Попытка вписать значение температуры в градусах Цельсия в табличку, где температура понималась как физическая величина в градусах Кельвина — это ещё самая невинная онтологическая ошибка (объект, определённый в языке одной онтологии/мета-модели кажется объектом, определённым в похожем, но не совпадающем полностью языке другой онтологии/мета-модели). Высота над полом — это «высота над уровнем перекрытия» или «высота над фальшполом машзала» (реальная ошибка из опыта проектирования атомных станций), и она даётся в миллиметрах, сантиметрах, или метрах (или вообще в футах)?
Чтобы согласовывать онтики между собой, нужно вести довольно искусную онтологическую работу. Никакой объект физического мира не становится таковым сам по себе (атомы не существуют сами по себе: это люди придумали концепцию «атом» как «что-то такое устойчивое на микромасштабах с примерно таким поведением», и это понимание довольно сильно менялось по мере развития науки. Никакой физический разговор про «аттракторы в пространстве состояний» и self-evidence термодинамически устойчивых объектов не отменяет этих онтологических рассуждений), он становится таким в силу существования многочисленных уровней абстракции, интегрирующих знание об этом объекте в общие знания цивилизации — и существование предмета/сущности/объекта тем самым обеспечивается не только тем человеком, который обнаружил такой объект и определил его отношения с другими объектами впервые, но и теми (часто давно умершими) людьми (или в последнее время даже компьютерами или коллективными агентами), которые описали классы таких объектов, или классы классов, которые описывают описания классов, которые описывают эти объекты, и так на некоторую глубину уровней абстракции. Если этого не понимать, то не получится «нарезать» мир на такие объекты, с которыми потом можно будет выполнять длинные цепочки рассуждения по правилам (объекты, с которыми будет работать логика), трудно будет достигать надёжных результатов рассуждений. Рассуждения, в результате которых вы не уверены, обычно такие и есть: они содержат в себе ошибки, неразрешимые без специальных усилий противоречия.
Онтология за счёт формализации описаний (подбор математических объектов, поведение которых хорошо известно, и которые заменяют физические объекты в мышлении) и многоуровневого наведения внимания на важные объекты за счёт многоуровневой классификации/присвоения типа, помогает избавиться от ошибок в мышлении. Ещё онтология помогает разделению труда в мышлении: можно выделить разные объекты, которые подробно продумываются разными людьми, а в общении потом эти люди обмениваются результатами своих размышлений — и эти результаты можно потом собрать в одно целое, ибо про каждый результат будет понятно, в каком языке этот результат выражен, и так на несколько уровней абстракции вверх и вниз. Так, в инженерном проекте кто-то может продумывать нужность системы в надсистеме (визионер), кто-то продумывать функциональные части системы (разработчик), а кто-то может продумывать способ объединения конструктивных частей (архитектор), потом они должны как-то договориться по итогам своих размышлений.
В СМД-методологии это постепенное формулирование объекта рассмотрения (как именно выделять предмет в физическом мире — откуда мы вообще знаем понятие «предмета»? Какое отношение этот предмет-объект имеет к субъекту? и прочие эпистемологические вопросы для онтологического рассмотрения) называют «проблемой объективации»: все «одноуровневые указания объекта» упираются в «проблему» зависимости выделения объекта от выделяющего объект субъекта (разные субъекты выделяют разные объекты, нельзя что-то «объективировать», выделить объект «объективно»). Решение этой проблемы в том, что отношение субъект-объект формируется многоступенчато, на многих уровнях абстракции. В программировании, когда обсуждают уровни метамоделирования — все эти M0-M9 из Meta Object Facility[2], имеют в виду именно эти уровни абстракции в моделировании мира, но верхние уровни абстракции мало кого волнуют, если ты не занят действительно большими и сложными проектами, где мультидисциплинарность начинает доставлять мыслительные сложности и требуется сделать какие-то онтологические выборы (ontological commitments, онтологические посылки) для более-менее беспроблемного выражения знаний о самых разных предметных областях. Например, вы занимаетесь капитальным строительством сложных инженерных объектов: атомных электростанций, морских нефтяных платформ и сталкиваетесь с необходимостью как-то собрать воедино знания о комплектующих, которых в таких проектах набирается несколько миллионов. Если вы выберете 4D онтологию, то огромное количество отношений превращаются в отношения «часть-целое» и задача описания сложнейшего проекта упрощается. Если выберете 3D онтологию, то мир будет описывать более сложно, в более объёмном и разнообразном описании у вас вероятность ошибок будет больше. На проекте с десятком миллионов индивидуальных деталей эта разница в сложности будет очень существенной, хотя если у вас пара тысяч деталей в вашем проекте, то вы не будете замечать эту разницу в сложности описаний. Или вы медик, и нужно собрать воедино знания об огромном количестве болезней/патологий, или генов, или организмов, или химических веществ как потенциальных лекарств. Профессиональные онтологи работают именно в таких проектах, где очень много всего разного. Наша идея в том, чтобы использовать элегантное/lean онтологизирование: иметь самый низкий уровень формальности для верхних уровней абстракции в описаниях, но саму эту технику упрощения описания «пестрого мира» в проектах за счёт удачно выбранных онтологических посылок, «где очень много всего разного» перетаскивать в менеджерские и инженерные проекты, где всего не так много, но тоже хорошо бы поднять качество описания.
Если у вас проекты относительно простые, то профессиональные онтологи будут для вас слишком дороги, и вам придётся быть онтологом самостоятельно. Плохое понимание онтологии в интеллект-стеке ведёт к плохому пониманию системного мышления, далее к плохому пониманию сути методологии, трудовой кругозор становится несвязным, далее будет невозможность осмыслить связность между собой разных прикладных трудовых практик в рамках одного проекта, ибо будет непонятна их «одинаковость», «сравнимость». Разорванная на лоскуты отдельных практик картина мира — это беда, будут огромные трудности с тем, чтобы договориться о сотрудничестве в проекте! Будет огромное количество «споров о терминах», абсолютно бесполезных и бесперспективных. Взять хотя бы слово «сервис»: это поведение, или та штука, которая как-то себя ведёт? Если «сервис» это «та штука, которая себя как-то ведёт», то что такое сервис-провайдер — то же самое, что сервис? А сервис — это услуга или служба, это ж просто перевод английского service? Функциональный объект и функция — это одно и то же? И чем они отличаются от рабочих продуктов и работ? Без разбирательства с этими вопросами (это типичные вопросы для онтологии) в инженерных и менеджерских проектах вы не разберётесь. И обратите внимание, что для разговора об онтологии вам требуется и знание понятизации (работаем с понятиями), и собранности (описания документируем!), и семантики, и разбирательство с ментальным миром (математика) и физическим миром (физика), и работа в рамках какой-то теории понятий (опять же, работаем с понятиями!).
Увы, совсем уж согласованных между собой онтологий не бывает в природе, поэтому чаще всего люди довольствуются просто собирательством самых разных онтик (полезно уже хотя бы сделать их явными!) и их более-менее неформальным объединением. Итоговая клочковатая структура знаний не даёт надёжности для длинных цепочек рассуждений, но уровень точности рассуждений для понятий, типы которых проговорены явно, даёт достаточную степень правдоподобности. Если нужно увеличить вероятность правильности рассуждений, то можно всегда предпринять дополнительные усилия по доформализации получившегося общего знания: вам нужно будет создать на предприятии службу качества данных (и инженерных, и менеджерских), где собрать каких-то разбирающихся в онтологии людей.