Онтологическая инженерия в 2018
Онтологическая инженерия -- это подход и средства, позволяющие описать успешную онтологию. Успешная онтология -- это которая будет затем использована для реализации успешных систем. Такое "словарное определение" я смастерил по образу и подобию определения системной инженерии (Systems Engineering (SE) is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal. -- https://sebokwiki.org/wiki/Systems_Engineering_(glossary)). Но не системная инженерия ближе всего к онтологической инженерии, а инженерия требований и инженерия системной архитектуры. Инженерия требований выявляет, описывает/документирует и далее использует описание системы как чёрного ящика, инженерия системной архитектуры занимается придумыванием и документированием описания системы как белого ящика. Онтологическая инженерия делает это не с системой, а с более сложным случаем: с какой-то предметной областью, domain. В пределе этой предметной областью является весь мир, но чаще всего это и впрямь одна или несколько довольно узких предметных областей. Какая-то с этим связанная терминология была дана в "Онтике онтологизации" https://ailev.livejournal.com/1427265.html.
Для меня важно сейчас, что методология онтологической инженерии (обсуждение методов онтологической работы) по факту имеет дело с онтологическими описаниями "по форме", а вот содержание этих онтологиxеских описаний может быть крайне разнообразным. Как и в методологии инженерии требований, мы обсуждаем разные форматы документирования требований, разные варианты моделей требований. Как в методологии работы с системной архитектурой разбираемся с формами архитектурных описаний (помним тот же ISO42010). Так и в онтологической инженерии всё то же самое, но акценты другие: описываем не систему, а какой-то промежуточный уровень стека абстракций, описание предметной области (про "глубокий стек абстрактности мышлений" и онтологические уровни см. в https://ailev.livejournal.com/1442975.html, а про абстракции как чеклисты см. в https://ailev.livejournal.com/1446993.html).
Работа с абстракциями, работа с описанием предметных областей ни разу не является прерогативой "настоящих онтологов". Как и с инженерией требований и с системной архитектурой главным образом работают отнюдь не дипломированные инженеры по требованиям и инженеры-архитекторы, так и с онтологическими описаниями работают в абсолютно других местах. Говорит прозой всё население земного шара, но не все знают, что они говорят "прозой". Так и тут: смотрим на деятельность, а не на то, как она называется. Где искать сегодня state-of-the-art онтологической инженерии? Прошлый мой пост на эту тему был ровно два года назад, "онтологии и бибинарная модель мышления" -- https://ailev.livejournal.com/1305176.html.
1. То, что происходит с классическими онтологиями и даже с computational ontology, просто пока сбрасываем со счетов. Там пока ничего не происходит, никаких прорывов. Всё очень трудоёмко и ждёт enablers из других областей (про машинное обучение заговаривают всё чаще). Поэтому тут притормаживаем, интересуемся теми местами, где всё бежит бегом.
2. Стандарты и публичные документы. Стандарты -- это где есть проверка соответствия. Публичные документы -- это где нет проверки соответствия, но в последнее время появляются разные формы проверки на их знание (т.е. они кладутся в основу учебных процессов, ибо в них документируется дисциплина). Все BoK как раз сюда и относятся. Я уже давно говорил, что методологическая/онтологическая работа происходит в области стандартизации -- в 2004 по механизмам стандартизации -- http://ailev.livejournal.com/212819.html, выступление по стандартизации как "месте, где живёт методология" в 2009г. -- http://ailev.livejournal.com/664154.html, или в 2012 я сопоставляю институализацию и стандартизацию -- http://ailev.livejournal.com/982274.html, или обзорчик по стандартизации роботов в 2014 году -- http://ailev.livejournal.com/1103887.html. Прорывов тут нет, она идёт, как идёт. Новые предметные области появляются и по мере созревания документируются в стандартах и публичных документах разной степени формальности, а это и есть онтологическая инженерия.
3. Разработка корпоративного софта -- это текущий state-of-the-art "классической" онтологической работы. Вот некоторая линейка рассуждений:
а) вся разработка корпоративного софта это внесение и исправление многочисленных багов, при этом баги могут появляться и из-за изменений во внешней среде, и приходить от собственных разработчиков. Цикл выпуска новых версий, в которых баги исправляются, сейчас недопустимо длинный. Поэтому DevOps -- это наше всё, непрерывная интеграция и выпуск тут цель и средство. Изменения вносятся маленькими порциями (small batch size) и выпускаются в жизнь очень быстро.
б) микросервисы позволяют ещё уменьшить порции выпусков, а также изолировать распространение ошибок по системе (это же модули!). Микросервисы содержат собственные данные, и они нарезаются так, чтобы как-то соответствовать business capability (оргвозможностям, см. про их связь с практиками в "к онтологии организационного моделирования": https://ailev.livejournal.com/1446903.html. А сами микросервисы (включая моделирование данных в них) делаются с использованием DDD (domain-driven-development), где одно из основных понятий -- это bounded context, поиск модульности в организации. На выходе тем самым мы получаем распределённые данные.
в) дальше мы должны обеспечить методы работы с распределёнными данными (включая изменения в моделях данных), в которых время от замысла до реализации изменения должно стремиться к нулю. Можно обсуждать, как это связано с онтологической инженерией (всё-таки онтологии это больше про типы, но ведь работа с типами бессмысленна, если в какой-то момент мы не обращаемся к индивидам -- и недаром в "классике" индивиды и абстрактные объекты рассматриваются как имеющие общую презентацию, хранящиеся и обрабатывающиеся в одной "базе знаний"). Тем не менее, задача именно такая: найти изменение предметной области, документировать его, далее вывести это документированное изменение в "эксплуатацию". Обычный инженерный цикл. Этот цикл хорошо описан в книжке Edson Yanaga "Migrating to Microservices Databases. From Relational Monolith to Distributed Data" -- http://b-ok.xyz/book/3493751/b6ab98. Тем самым DDD+DevOps+microservices = современная "классическая" онтологическая инженерия, да ещё со смещением акцента с чисто "разработки" к "эксплуатации" и в какой-то мере даже "вывода из эксплуатации" -- то есть просматривается работа с полным жизненным циклом онтологического описания, а не просто "академическое упражнение в описании мира".
4. Работы по машинному обучению, абсолютно неклассическая онтологическая инженерия. Часть работ по этой тематике я указывал в "компьютерной поддержке полного спектра формальности мышления" -- https://ailev.livejournal.com/1438749.html. Конечно, этот "спектр формальности мышления" нужно ещё как-то соотносить с "глубоким стеком абстрактности мышления" из https://ailev.livejournal.com/1442975.html (где вообще я рассказываю об онтологических уровнях как уровнях абстрактности -- и помним, что уровни нейросети выучивают разные уровни абстракции в рамках обучения представлениям, representation learning, http://ailev.livejournal.com/1045081.html). Тут работы идут главным образом по связке "классических онтологий" в виде knowledge graph и нейросетей с attention в этом графе -- это основной поток работ, типа Learning beyond datasets: Knowledge Graph Augmented Neural Networks for Natural language Processing.
Важнейшей чертой "классических" онтологий была возможность логического вывода по ним, всякие пруверы/солверы рассматривались чуть ли не как главное достоинство "формализации концептуализации" -- вплоть до заявлений, что "по чему нельзя логически выводить, то не онтология", появления важнейших новаций в модульности онтологий типа "микротеорий" именно на базе критерия непротиворечивости в части логического вывода. Похоже, что сейчас в этой части будут прорывы, и эти прорывы идут из абсолютно практической задачи создания вопросно-ответной системы, способной ответить на вопросы, относящиеся к разным документам (сделав при этом несколько тактов логического вывода). Это будет происходить, похоже, на базе "соревновательной науки" -- опубликован соответствующий датасет и baseline для отслеживания SoTA -- HotpotQA: https://hotpotqa.github.io/.
Но практическая онтологическая инженерия идёт много дальше этой notebook data science (когда кто-то придумывает очередной алгоритм и очередную архитектуру для представления данных в нейросети или в knowledge graph). И идёт по той же самой линии, которая была заявлена в предыдущем пункте с "классикой" из DDD+DevOps+microservices. В machine learning ключевым словом тут является pipeline -- "Getting Better at Machine Learning" https://medium.com/@rchang/getting-better-at-machine-learning-16b4dd913a1f прямо указывает, что всякие "соревнования" и победы в алгоритмах и представлениях это не вся инженерия! Инженерное решение должно закрывать полный жизненный цикл: от постановки задачи до использования результатов, поддерживаться должен полный жизненный цикл данных и их моделей (которыми можно в том числе считать и выученные на базе этих данных нейронные сети -- новая форма представления вероятностных онтологий, а inference в нейронных сетях -- новая форма использования онтологий). Pipelines (вариант того же самого: plumbing) в машинном обучении, которое мы будем считать одним из видов неклассической онтологической инженерии (там ведь тоже идёт работа с данными и их моделями!), активно сейчас нарезается на практики и получает свои инструменты -- "AI Plumbing: mapping the landscape", https://medium.com/digital-catapult/ai-plumbing-mapping-the-landscape-d213e41842d прямо говорит, что в эпицентре там DataTech, и там нужно как-то организовать данные, поместить данные в базу данных. А это прямая отсылка к классическому моделированию данных, классической онтологической инженерии. Всё в этой онтологической инженерии переплетено и смешано на многих уровнях: дискретные и коннекционистские модели данных поддерживают друг друга -- и в обозримой перспективе будут сосуществовать вместе. И тут появляется уже DataOps (см.также "от DataOps к NoOps" -- https://ailev.livejournal.com/1367897.html).
Ещё один аспект -- это проблемы модульности коннекционистских онтологий ("модульность", https://ailev.livejournal.com/1294242.html), то есть отсутствие "таблеток знаний". Тут огромное количество работ, из самых знаменитых работ последнего времени можно указать, например, использование pretrained language models вроде ElMo https://arxiv.org/abs/1802.05365, ULMFit https://arxiv.org/abs/1801.06146, июньской работы по комбинированию transformers и unsupervised pre-training от OpenAI https://blog.openai.com/language-unsupervised/, и, конечно, BERT -- https://arxiv.org/abs/1810.04805. А ещё бесконечный поток по multitask learning, transfer learning и многим схожим до неразличимости направлениям -- это же тоже ровно оно для коннективистских онтологий, отражение всех этих идей по "микротеориям" в классике онтологии и reference data library в классике моделирования данных. Разделение труда, модульный синтез, все проблемы "моделирования в большом" ("онтологические модели -- это про проектирование/программирование/моделирование-в-большом", https://ailev.livejournal.com/748188.html, я писал это ещё в 2009).
5. Ещё одно направление работы в онтологической инженерии связано с тем, что в причинных моделях всё одно нужно иметь какую-то гипотезу по модели причинности, которую подтверждать или опровергать данными. И эта гипотеза, по идее, строится на онтологии -- её делает subject expert. Это ещё одно место, где можно ожидать интереса к онтологической инженерии ("Ложь, наглая ложь, и причинный вывод" -- https://ailev.livejournal.com/1435703.html). Мне также кажется, что попытка иметь "объяснимые модели" в нейронных сетях (гуглите "interpreting and understanding deep neural networks" -- этих работ огромное количество) это того же поля ягода, это попытка привязать когнитивистскую модель к модели какой-то theory theory "классической" онтологии, а для этого эту самую "классическую онтологию" нужно построить. Вот типичная такая работа: https://www.quantamagazine.org/been-kim-is-building-a-translator-for-artificial-intelligence-20190110/
Одно очевидно:
-- онтологическая инженерия давно уже не существует под привычными для онтологов именами. Как всегда, прогресс приходит "сбоку". Онтологической работой занимаются не онтологи, достижения "олдовых онтологов" используются по минимуму. Это похоже на то, что происходит с философией в целом: инженеры, менеджеры, программисты по-быстрому переизобретают давно известные философские идеи, потому как получить их в приемлемой форме от философов не представляется возможным (те ж начинают не с сути дела, а с Платона и Аристотеля -- и до сути дела уже не добраться). Потом философы приписывают достижения всех этих творцов себе, типа "они ж давно говорили". То, что от их говорения при этом толку не было, не упоминается. "После того -- значит вследствие того" в философии это умолчание, а зря. Вот в онтологии наступают похожие времена: онтологической инженерией занимаются люди, практикующие DDD и моделирование данных, а их заслуги припишут себе академические философы, задним числом.
-- переход от онтологии (и даже онтологики!) к онтологической инженерии сразу даёт 1. выход на понятие жизненного цикла и обращает внимание на прагму: как, когда, в какой форме, кем используется результат онтологической работы, какие инструменты это поддерживают. 2. упор на модульность и модульный синтез как основную решаемую проблему -- уход от ontology engineering-in-the-small (laptop data science) к ontology engineering-in-the-large, со всеми этими идеями разделения труда и непрерывной интеграции в части объединения результатов труда.
-- классическое и когнитивистское онтологическое моделирование/моделирование данных уже сосуществуют, взаимно питают и дополняют друг друга, они отнюдь не отрицают друг друга. Заниматься в онтологической инженерии в 2018 году нужно и тем, и другим.
Для меня важно сейчас, что методология онтологической инженерии (обсуждение методов онтологической работы) по факту имеет дело с онтологическими описаниями "по форме", а вот содержание этих онтологиxеских описаний может быть крайне разнообразным. Как и в методологии инженерии требований, мы обсуждаем разные форматы документирования требований, разные варианты моделей требований. Как в методологии работы с системной архитектурой разбираемся с формами архитектурных описаний (помним тот же ISO42010). Так и в онтологической инженерии всё то же самое, но акценты другие: описываем не систему, а какой-то промежуточный уровень стека абстракций, описание предметной области (про "глубокий стек абстрактности мышлений" и онтологические уровни см. в https://ailev.livejournal.com/1442975.html, а про абстракции как чеклисты см. в https://ailev.livejournal.com/1446993.html).
Работа с абстракциями, работа с описанием предметных областей ни разу не является прерогативой "настоящих онтологов". Как и с инженерией требований и с системной архитектурой главным образом работают отнюдь не дипломированные инженеры по требованиям и инженеры-архитекторы, так и с онтологическими описаниями работают в абсолютно других местах. Говорит прозой всё население земного шара, но не все знают, что они говорят "прозой". Так и тут: смотрим на деятельность, а не на то, как она называется. Где искать сегодня state-of-the-art онтологической инженерии? Прошлый мой пост на эту тему был ровно два года назад, "онтологии и бибинарная модель мышления" -- https://ailev.livejournal.com/1305176.html.
1. То, что происходит с классическими онтологиями и даже с computational ontology, просто пока сбрасываем со счетов. Там пока ничего не происходит, никаких прорывов. Всё очень трудоёмко и ждёт enablers из других областей (про машинное обучение заговаривают всё чаще). Поэтому тут притормаживаем, интересуемся теми местами, где всё бежит бегом.
2. Стандарты и публичные документы. Стандарты -- это где есть проверка соответствия. Публичные документы -- это где нет проверки соответствия, но в последнее время появляются разные формы проверки на их знание (т.е. они кладутся в основу учебных процессов, ибо в них документируется дисциплина). Все BoK как раз сюда и относятся. Я уже давно говорил, что методологическая/онтологическая работа происходит в области стандартизации -- в 2004 по механизмам стандартизации -- http://ailev.livejournal.com/212819.html, выступление по стандартизации как "месте, где живёт методология" в 2009г. -- http://ailev.livejournal.com/664154.html, или в 2012 я сопоставляю институализацию и стандартизацию -- http://ailev.livejournal.com/982274.html, или обзорчик по стандартизации роботов в 2014 году -- http://ailev.livejournal.com/1103887.html. Прорывов тут нет, она идёт, как идёт. Новые предметные области появляются и по мере созревания документируются в стандартах и публичных документах разной степени формальности, а это и есть онтологическая инженерия.
3. Разработка корпоративного софта -- это текущий state-of-the-art "классической" онтологической работы. Вот некоторая линейка рассуждений:
а) вся разработка корпоративного софта это внесение и исправление многочисленных багов, при этом баги могут появляться и из-за изменений во внешней среде, и приходить от собственных разработчиков. Цикл выпуска новых версий, в которых баги исправляются, сейчас недопустимо длинный. Поэтому DevOps -- это наше всё, непрерывная интеграция и выпуск тут цель и средство. Изменения вносятся маленькими порциями (small batch size) и выпускаются в жизнь очень быстро.
б) микросервисы позволяют ещё уменьшить порции выпусков, а также изолировать распространение ошибок по системе (это же модули!). Микросервисы содержат собственные данные, и они нарезаются так, чтобы как-то соответствовать business capability (оргвозможностям, см. про их связь с практиками в "к онтологии организационного моделирования": https://ailev.livejournal.com/1446903.html. А сами микросервисы (включая моделирование данных в них) делаются с использованием DDD (domain-driven-development), где одно из основных понятий -- это bounded context, поиск модульности в организации. На выходе тем самым мы получаем распределённые данные.
в) дальше мы должны обеспечить методы работы с распределёнными данными (включая изменения в моделях данных), в которых время от замысла до реализации изменения должно стремиться к нулю. Можно обсуждать, как это связано с онтологической инженерией (всё-таки онтологии это больше про типы, но ведь работа с типами бессмысленна, если в какой-то момент мы не обращаемся к индивидам -- и недаром в "классике" индивиды и абстрактные объекты рассматриваются как имеющие общую презентацию, хранящиеся и обрабатывающиеся в одной "базе знаний"). Тем не менее, задача именно такая: найти изменение предметной области, документировать его, далее вывести это документированное изменение в "эксплуатацию". Обычный инженерный цикл. Этот цикл хорошо описан в книжке Edson Yanaga "Migrating to Microservices Databases. From Relational Monolith to Distributed Data" -- http://b-ok.xyz/book/3493751/b6ab98. Тем самым DDD+DevOps+microservices = современная "классическая" онтологическая инженерия, да ещё со смещением акцента с чисто "разработки" к "эксплуатации" и в какой-то мере даже "вывода из эксплуатации" -- то есть просматривается работа с полным жизненным циклом онтологического описания, а не просто "академическое упражнение в описании мира".
4. Работы по машинному обучению, абсолютно неклассическая онтологическая инженерия. Часть работ по этой тематике я указывал в "компьютерной поддержке полного спектра формальности мышления" -- https://ailev.livejournal.com/1438749.html. Конечно, этот "спектр формальности мышления" нужно ещё как-то соотносить с "глубоким стеком абстрактности мышления" из https://ailev.livejournal.com/1442975.html (где вообще я рассказываю об онтологических уровнях как уровнях абстрактности -- и помним, что уровни нейросети выучивают разные уровни абстракции в рамках обучения представлениям, representation learning, http://ailev.livejournal.com/1045081.html). Тут работы идут главным образом по связке "классических онтологий" в виде knowledge graph и нейросетей с attention в этом графе -- это основной поток работ, типа Learning beyond datasets: Knowledge Graph Augmented Neural Networks for Natural language Processing.
Важнейшей чертой "классических" онтологий была возможность логического вывода по ним, всякие пруверы/солверы рассматривались чуть ли не как главное достоинство "формализации концептуализации" -- вплоть до заявлений, что "по чему нельзя логически выводить, то не онтология", появления важнейших новаций в модульности онтологий типа "микротеорий" именно на базе критерия непротиворечивости в части логического вывода. Похоже, что сейчас в этой части будут прорывы, и эти прорывы идут из абсолютно практической задачи создания вопросно-ответной системы, способной ответить на вопросы, относящиеся к разным документам (сделав при этом несколько тактов логического вывода). Это будет происходить, похоже, на базе "соревновательной науки" -- опубликован соответствующий датасет и baseline для отслеживания SoTA -- HotpotQA: https://hotpotqa.github.io/.
Но практическая онтологическая инженерия идёт много дальше этой notebook data science (когда кто-то придумывает очередной алгоритм и очередную архитектуру для представления данных в нейросети или в knowledge graph). И идёт по той же самой линии, которая была заявлена в предыдущем пункте с "классикой" из DDD+DevOps+microservices. В machine learning ключевым словом тут является pipeline -- "Getting Better at Machine Learning" https://medium.com/@rchang/getting-better-at-machine-learning-16b4dd913a1f прямо указывает, что всякие "соревнования" и победы в алгоритмах и представлениях это не вся инженерия! Инженерное решение должно закрывать полный жизненный цикл: от постановки задачи до использования результатов, поддерживаться должен полный жизненный цикл данных и их моделей (которыми можно в том числе считать и выученные на базе этих данных нейронные сети -- новая форма представления вероятностных онтологий, а inference в нейронных сетях -- новая форма использования онтологий). Pipelines (вариант того же самого: plumbing) в машинном обучении, которое мы будем считать одним из видов неклассической онтологической инженерии (там ведь тоже идёт работа с данными и их моделями!), активно сейчас нарезается на практики и получает свои инструменты -- "AI Plumbing: mapping the landscape", https://medium.com/digital-catapult/ai-plumbing-mapping-the-landscape-d213e41842d прямо говорит, что в эпицентре там DataTech, и там нужно как-то организовать данные, поместить данные в базу данных. А это прямая отсылка к классическому моделированию данных, классической онтологической инженерии. Всё в этой онтологической инженерии переплетено и смешано на многих уровнях: дискретные и коннекционистские модели данных поддерживают друг друга -- и в обозримой перспективе будут сосуществовать вместе. И тут появляется уже DataOps (см.также "от DataOps к NoOps" -- https://ailev.livejournal.com/1367897.html).
Ещё один аспект -- это проблемы модульности коннекционистских онтологий ("модульность", https://ailev.livejournal.com/1294242.html), то есть отсутствие "таблеток знаний". Тут огромное количество работ, из самых знаменитых работ последнего времени можно указать, например, использование pretrained language models вроде ElMo https://arxiv.org/abs/1802.05365, ULMFit https://arxiv.org/abs/1801.06146, июньской работы по комбинированию transformers и unsupervised pre-training от OpenAI https://blog.openai.com/language-unsupervised/, и, конечно, BERT -- https://arxiv.org/abs/1810.04805. А ещё бесконечный поток по multitask learning, transfer learning и многим схожим до неразличимости направлениям -- это же тоже ровно оно для коннективистских онтологий, отражение всех этих идей по "микротеориям" в классике онтологии и reference data library в классике моделирования данных. Разделение труда, модульный синтез, все проблемы "моделирования в большом" ("онтологические модели -- это про проектирование/программирование/моделирование-в-большом", https://ailev.livejournal.com/748188.html, я писал это ещё в 2009).
5. Ещё одно направление работы в онтологической инженерии связано с тем, что в причинных моделях всё одно нужно иметь какую-то гипотезу по модели причинности, которую подтверждать или опровергать данными. И эта гипотеза, по идее, строится на онтологии -- её делает subject expert. Это ещё одно место, где можно ожидать интереса к онтологической инженерии ("Ложь, наглая ложь, и причинный вывод" -- https://ailev.livejournal.com/1435703.html). Мне также кажется, что попытка иметь "объяснимые модели" в нейронных сетях (гуглите "interpreting and understanding deep neural networks" -- этих работ огромное количество) это того же поля ягода, это попытка привязать когнитивистскую модель к модели какой-то theory theory "классической" онтологии, а для этого эту самую "классическую онтологию" нужно построить. Вот типичная такая работа: https://www.quantamagazine.org/been-kim-is-building-a-translator-for-artificial-intelligence-20190110/
Одно очевидно:
-- онтологическая инженерия давно уже не существует под привычными для онтологов именами. Как всегда, прогресс приходит "сбоку". Онтологической работой занимаются не онтологи, достижения "олдовых онтологов" используются по минимуму. Это похоже на то, что происходит с философией в целом: инженеры, менеджеры, программисты по-быстрому переизобретают давно известные философские идеи, потому как получить их в приемлемой форме от философов не представляется возможным (те ж начинают не с сути дела, а с Платона и Аристотеля -- и до сути дела уже не добраться). Потом философы приписывают достижения всех этих творцов себе, типа "они ж давно говорили". То, что от их говорения при этом толку не было, не упоминается. "После того -- значит вследствие того" в философии это умолчание, а зря. Вот в онтологии наступают похожие времена: онтологической инженерией занимаются люди, практикующие DDD и моделирование данных, а их заслуги припишут себе академические философы, задним числом.
-- переход от онтологии (и даже онтологики!) к онтологической инженерии сразу даёт 1. выход на понятие жизненного цикла и обращает внимание на прагму: как, когда, в какой форме, кем используется результат онтологической работы, какие инструменты это поддерживают. 2. упор на модульность и модульный синтез как основную решаемую проблему -- уход от ontology engineering-in-the-small (laptop data science) к ontology engineering-in-the-large, со всеми этими идеями разделения труда и непрерывной интеграции в части объединения результатов труда.
-- классическое и когнитивистское онтологическое моделирование/моделирование данных уже сосуществуют, взаимно питают и дополняют друг друга, они отнюдь не отрицают друг друга. Заниматься в онтологической инженерии в 2018 году нужно и тем, и другим.