Интеграция/федерирование данных жизненного цикла -- 2016
Я писал в 2011 году про четыре поколения информационных систем для инженерных проектов -- электронная бумага, электронный инженерный документооборот, гибридные системы и датацентричные системы (http://ailev.livejournal.com/965124.html). Что изменилось за прошедшие пять лет? В текущей жизни практически ничего, но в даже ближайшей переспективе -- всё поменялось драматически.
Так или иначе, мы говорим об интеграции данных жизненного цикла -- как сделать так, чтобы все эти данные любого частного описания (view) для любой точки жизненного цикла были доступны для совместной обработки. При этом слово "интеграция" чисто терминологически подразумевает то, что все эти данные проектируются изначально так, чтобы быть согласованными между собой, что совсем не так. Некоторые люди, занимающиеся manufacturing enterprise interoperability однажды решили договориться о терминах, поэтому выпустили стандарт ISO 11354-1:2011 Advanced automation technologies and their applications — Requirements for establishing manufacturing enterprise process interoperability — Part 1: Framework for enterprise interoperability. В нём, в частности, написано в пункте 5.4.1
There are three approaches to achieve enterprise interoperability:
-- integrated,
-- unified,
-- and federated.
These three approaches were first identified in ISO 14258.
Унификация -- это когда все внимательно поглядывают на какой-то общий источник правды о картине мира (скажем, стандарт), и подлаживают свои конструкции под этот стандарт, чтобы облегчить последующую сборку. Например, используют чью-то чужую модель данных, чтобы дальше можно было собрать из кусочков общую для жизненного цикла модель данных.
Но тут у нас в случае жизненного цикла сложной инженерной системы правильным термином является "федерирование", ибо разные стейкхолдеры и знать друг о друге не хотят, когда они разрабатывают свой кусочек IT -- и CTO/CIO потом вынуждены разгребать это небрежение друг другом.
ISO 15926 был попыткой свести "федерирование" к "унификации", когда стандарт предлагает "как надо", а потом конвертеры приводят всё к единому "рабочему языку", уходя от вавилонской ситуации трансляции всех языков во все. Стандарт был задуман как "резиновый", чтобы легко натягиваться на самые разные неожиданные виды данных -- но при этом чтобы сохранялись его базовые положения, а не просто эти "неожиданности" кодировались как "текстовые поля", значение которых определялось бы только интерпретирующим эти поля софтом. Одна картина мира на весь инженерный проект, один источник правды про устройство мира в проекте -- очень, очень привлекательная идея!
Под давлением owner-operators (прежде всего работы консорциума FIATECH) вендоры инженерного софта нехотя на словах согласились, что будут поддерживать ISO 15926. По факту же этого не произошло, несмотря на то, что совместимость с этим стандартом была декларирована практически всеми. Поставщики систем CAD/CAM/CAE/PLM по факту саботировали независимые стандарты унификации и пытались сами прорваться к ситуации интеграции через движение к датацентрическим системам с собственными конверторами "из чужого в своё" (а не предлагаемое "из чужой в нейтральную-универсальную онтологию") ко всему, что шевелится.
Я неоднократно участвовал в переговорах на эту тему с Dassault Systemes, Bentley Systems, AVEVA, Intergraph, Autodesk и даже Siemens (и не российскими офисами, а штаб-квартирами). Более того, кроме переговоров были и попытки каких-то проектов (иногда даже удачных -- но явно не таких, какие предполагались авторами ISO 15926). Мы (TechInvestLab) были достаточно глубоко вовлечены в дела сообщества ISO 15926, и даже выпустили программную онтологическую платформу .15926 (можете её взять тут, там есть и исходные коды, множество примеров, плюс хорошая документация -- https://github.com/TechInvestLab/dot15926), предназначенную для федерирования данных жизненного цикла в соответствии с данным стандартом. Эту нашу платформу проверял вручную на соответствие стандарту NIST (если вам это что-то говорит), по факту это эталонная реализация ISO 15926. Тем не менее, стандарт так и не "взлетел". Люди до сих пор обмениваются информацией в режиме "точка-точка", а "грамотную онтологию всего" игнорируют.
А что с owner-operators? Их усилия добиться стандарта обмена информацией инженерных моделей (в том числе самого передового, предлагающего грамотную онтологическую работу и стык по форматам данных с семантическими технологиями ISO 15926) потерпели неудачу. Очередная такая попытка идёт в BIM, где мучаются с IFC, а рядом при этом электрики развивают CIM -- и задача собрать их всех "в одной базе данных с общим доступом, чтобы можно было найти конфигурационные коллизии одним запросом" сводится к уже решавшейся раньше сообществом ISO 15926. Трудоёмкость проектов по онтологическому федерированию данных запредельна, природа упруго сопротивляется онтологическому подходу, и это не случайно. Онтологическая мечта оказалась утопией, хотя и очень продуктивной утопией.
В трёхдневной давности посте "Онтологии и бибинарная модель мышления" http://ailev.livejournal.com/1305176.html в том числе сказано:
-- сначала нет шанса, что вся информация по проекту станет формализованной, "в модели",
-- потом нет шанса, что формализация случится в рамках одной онтологии, и связи между онтологиями как-то нужно будет обеспечивать: полнотекстово, коннекционистски, как-нибудь -- но выходя за пределы аристотелевой логики.
Даже если удаётся формализовать буквы или нарезку на куски текста (а хоть и в UTF-16, или круче того, в XML), это явно не тот уровень формальности и нейтральности ("семантичности", про внеситуативные "значения"), который ожидается от универсального стандарта передачи данных иженерного проекта. От перехода ручного аннотирования на чертежах к аннотированию на 3D моделях ровным счётом ничего не изменится: геометрию более-менее и сейчас передают (хотя тут есть тоже теоретические сложности, но их потихоньку решили), проблемы начинаются с попытками передавать дополнительную информацию -- она каждый раз оказывается разной, и стандартизовать это "онтологически", априорно по отношению ко времени и ситуации проекта, похоже, нельзя. Хотя очень хочется.
Это всё абсолютно не значит, что от формализации нужно отказываться. Формализация важна, и именно формализация и онтологичность двигают вперёд цивилизацию (см., например, размышления В.Широнина на эту тему -- http://ailev.livejournal.com/1281819.html). Но любой сверчок, включая онтологического сверчка, должен знать свой шесток.
Дальше нужно обсуждать технологии искусственного интеллекта, и как они нам помогут в построении онтологий, а также обсуждать роль онтологий в человеческом, машинном и общем для человеков и машин мышлении (что и делается в тексте про онтологии и бибинарную модель мышления). Федерирование данных жизненного цикла в 2016 году не так категорично в части настаивания на "одной нейтральной онтологии для всех", и даже не так категорично по части требования перевода всей информации по проекту в структурированные данные, "настоящие модели". Сегодняшнее движение по части федерирования данных жизненного цикла инерционно (декларируют следование стандартам, делают передачи данных "точка-точка"), но экспоненциальные технологии deep learning уже очень скоро тут всё взорвут, камня на камне не останется. САПРы, конечно, будут -- но мир PLM будет совсем другим. И да, ко всей системной информатике (http://ailev.livejournal.com/1272169.html) это предрекание скорых больших перемен тоже относится, коннекционистская проблематизация системного подхода уже начинает показывать зубы (http://ailev.livejournal.com/1252230.html).
* * *
Первое лирическое отступление: "бибинарная модель" -- это термин, выдуманный для потакания моей жене. У меня был клиент в Бибирево (район Москвы), и когда я ей сообщал, что я "еду в Бибирево", она обязательно просила произнести это "Бибирево" ещё несколько раз -- "уж больно хорошо звучит!". Так что пару дихотомий я назвал "бибинарной моделью" ради лулзов -- "уж больно хорошо звучит!". И я совсем не держусь за этот термин, но держусь за то, что там есть пара дихотомий для мышления: культурное-дичок, формальнодискретное-непрерывное.
Второе лирическое отступление: тот текст про онтологии и бибинарную модель мышления некоторые люди не понимают вообще, некоторые понимают там каждое слово, но не весь текст, но я также рад и счастлив был обнаружить людей, которые его понимают целиком. Согласен, этот текст -- не попса, в какой-то мере он эзотеричен, его не понять, если не знакомиться с материалами по тамошним ссылкам и не представлять хотя бы примерно ситуацию в исследованиях по deep learning, байесовской статистике, логике, когнитивистике и традиционной computational ontology. Тем не менее, свою аудиторию текст имеет. И он как раз из серии "программных", определяющих на долгое время направление деятельности.
Так или иначе, мы говорим об интеграции данных жизненного цикла -- как сделать так, чтобы все эти данные любого частного описания (view) для любой точки жизненного цикла были доступны для совместной обработки. При этом слово "интеграция" чисто терминологически подразумевает то, что все эти данные проектируются изначально так, чтобы быть согласованными между собой, что совсем не так. Некоторые люди, занимающиеся manufacturing enterprise interoperability однажды решили договориться о терминах, поэтому выпустили стандарт ISO 11354-1:2011 Advanced automation technologies and their applications — Requirements for establishing manufacturing enterprise process interoperability — Part 1: Framework for enterprise interoperability. В нём, в частности, написано в пункте 5.4.1
There are three approaches to achieve enterprise interoperability:
-- integrated,
-- unified,
-- and federated.
These three approaches were first identified in ISO 14258.
Унификация -- это когда все внимательно поглядывают на какой-то общий источник правды о картине мира (скажем, стандарт), и подлаживают свои конструкции под этот стандарт, чтобы облегчить последующую сборку. Например, используют чью-то чужую модель данных, чтобы дальше можно было собрать из кусочков общую для жизненного цикла модель данных.
Но тут у нас в случае жизненного цикла сложной инженерной системы правильным термином является "федерирование", ибо разные стейкхолдеры и знать друг о друге не хотят, когда они разрабатывают свой кусочек IT -- и CTO/CIO потом вынуждены разгребать это небрежение друг другом.
ISO 15926 был попыткой свести "федерирование" к "унификации", когда стандарт предлагает "как надо", а потом конвертеры приводят всё к единому "рабочему языку", уходя от вавилонской ситуации трансляции всех языков во все. Стандарт был задуман как "резиновый", чтобы легко натягиваться на самые разные неожиданные виды данных -- но при этом чтобы сохранялись его базовые положения, а не просто эти "неожиданности" кодировались как "текстовые поля", значение которых определялось бы только интерпретирующим эти поля софтом. Одна картина мира на весь инженерный проект, один источник правды про устройство мира в проекте -- очень, очень привлекательная идея!
Под давлением owner-operators (прежде всего работы консорциума FIATECH) вендоры инженерного софта нехотя на словах согласились, что будут поддерживать ISO 15926. По факту же этого не произошло, несмотря на то, что совместимость с этим стандартом была декларирована практически всеми. Поставщики систем CAD/CAM/CAE/PLM по факту саботировали независимые стандарты унификации и пытались сами прорваться к ситуации интеграции через движение к датацентрическим системам с собственными конверторами "из чужого в своё" (а не предлагаемое "из чужой в нейтральную-универсальную онтологию") ко всему, что шевелится.
Я неоднократно участвовал в переговорах на эту тему с Dassault Systemes, Bentley Systems, AVEVA, Intergraph, Autodesk и даже Siemens (и не российскими офисами, а штаб-квартирами). Более того, кроме переговоров были и попытки каких-то проектов (иногда даже удачных -- но явно не таких, какие предполагались авторами ISO 15926). Мы (TechInvestLab) были достаточно глубоко вовлечены в дела сообщества ISO 15926, и даже выпустили программную онтологическую платформу .15926 (можете её взять тут, там есть и исходные коды, множество примеров, плюс хорошая документация -- https://github.com/TechInvestLab/dot15926), предназначенную для федерирования данных жизненного цикла в соответствии с данным стандартом. Эту нашу платформу проверял вручную на соответствие стандарту NIST (если вам это что-то говорит), по факту это эталонная реализация ISO 15926. Тем не менее, стандарт так и не "взлетел". Люди до сих пор обмениваются информацией в режиме "точка-точка", а "грамотную онтологию всего" игнорируют.
А что с owner-operators? Их усилия добиться стандарта обмена информацией инженерных моделей (в том числе самого передового, предлагающего грамотную онтологическую работу и стык по форматам данных с семантическими технологиями ISO 15926) потерпели неудачу. Очередная такая попытка идёт в BIM, где мучаются с IFC, а рядом при этом электрики развивают CIM -- и задача собрать их всех "в одной базе данных с общим доступом, чтобы можно было найти конфигурационные коллизии одним запросом" сводится к уже решавшейся раньше сообществом ISO 15926. Трудоёмкость проектов по онтологическому федерированию данных запредельна, природа упруго сопротивляется онтологическому подходу, и это не случайно. Онтологическая мечта оказалась утопией, хотя и очень продуктивной утопией.
В трёхдневной давности посте "Онтологии и бибинарная модель мышления" http://ailev.livejournal.com/1305176.html в том числе сказано:
Системы -- они в глазах смотрящего. Каждый viewpoint (метамодель, онтология) несовместим с другими, просто по определению. Потуги загнать всех а хоть и в тот же ISO 15926 -- это просто потуги, хотя любой локальный успех в этих потугах значим и сильно облегчает жизнь.Другими словами: создать онтологию для объединения всех данных про целевую систему не просто запредельно трудоёмко. Похоже, что это сделать теоретически нельзя. Теоретически нельзя все полнотекстовые документы перевести в структурированный формат, потому как при этом будет потеряна информация: ответы на одни вопросы в структурированный формат переведутся, а ответы на какие-то другие вопросы (а они будут!) не переведутся. Например, Donald Firesmith любит замечать, что в архитектуре нельзя всё сводить только к формальным моделям -- как минимум, должно быть архитектурное эссе, в котором рассказывается что-то связное и понятное людям про эти модели, приводятся архитектурные метафоры, по определению неформализуемые. Естественный язык, плохоформализуемые текстовые аннотации на чертежах или даже моделях -- они останутся всегда:
Объединить все эти (foundational, upper, middle, domain, ontology modules/microtheories) онтологии можно только деятельностно: только через то, что все эти view (определяемые вполне дисциплинарно, через viewpoints-онтологии как метамодели, как классификаторы) оказываются на один и тот же индивид в реальном мире. Он разный в разных онтологиях, но в реальности-то он один -- и можно договориться, сверяясь с происходящим в реальности. Для этих договорённостей мы переходим на естественный язык, плюс в парадигмальный формализм (ух! если это, конечно, формализм -- но по мере понимания это можно и формализмом считать) непрерывного (а не дискретного Аристотелевского) рассмотрения: байесовский, коннекционистский или любой другой, подходящий для обучения и вывода/reasoning.
-- сначала нет шанса, что вся информация по проекту станет формализованной, "в модели",
-- потом нет шанса, что формализация случится в рамках одной онтологии, и связи между онтологиями как-то нужно будет обеспечивать: полнотекстово, коннекционистски, как-нибудь -- но выходя за пределы аристотелевой логики.
Даже если удаётся формализовать буквы или нарезку на куски текста (а хоть и в UTF-16, или круче того, в XML), это явно не тот уровень формальности и нейтральности ("семантичности", про внеситуативные "значения"), который ожидается от универсального стандарта передачи данных иженерного проекта. От перехода ручного аннотирования на чертежах к аннотированию на 3D моделях ровным счётом ничего не изменится: геометрию более-менее и сейчас передают (хотя тут есть тоже теоретические сложности, но их потихоньку решили), проблемы начинаются с попытками передавать дополнительную информацию -- она каждый раз оказывается разной, и стандартизовать это "онтологически", априорно по отношению ко времени и ситуации проекта, похоже, нельзя. Хотя очень хочется.
Это всё абсолютно не значит, что от формализации нужно отказываться. Формализация важна, и именно формализация и онтологичность двигают вперёд цивилизацию (см., например, размышления В.Широнина на эту тему -- http://ailev.livejournal.com/1281819.html). Но любой сверчок, включая онтологического сверчка, должен знать свой шесток.
Дальше нужно обсуждать технологии искусственного интеллекта, и как они нам помогут в построении онтологий, а также обсуждать роль онтологий в человеческом, машинном и общем для человеков и машин мышлении (что и делается в тексте про онтологии и бибинарную модель мышления). Федерирование данных жизненного цикла в 2016 году не так категорично в части настаивания на "одной нейтральной онтологии для всех", и даже не так категорично по части требования перевода всей информации по проекту в структурированные данные, "настоящие модели". Сегодняшнее движение по части федерирования данных жизненного цикла инерционно (декларируют следование стандартам, делают передачи данных "точка-точка"), но экспоненциальные технологии deep learning уже очень скоро тут всё взорвут, камня на камне не останется. САПРы, конечно, будут -- но мир PLM будет совсем другим. И да, ко всей системной информатике (http://ailev.livejournal.com/1272169.html) это предрекание скорых больших перемен тоже относится, коннекционистская проблематизация системного подхода уже начинает показывать зубы (http://ailev.livejournal.com/1252230.html).
* * *
Первое лирическое отступление: "бибинарная модель" -- это термин, выдуманный для потакания моей жене. У меня был клиент в Бибирево (район Москвы), и когда я ей сообщал, что я "еду в Бибирево", она обязательно просила произнести это "Бибирево" ещё несколько раз -- "уж больно хорошо звучит!". Так что пару дихотомий я назвал "бибинарной моделью" ради лулзов -- "уж больно хорошо звучит!". И я совсем не держусь за этот термин, но держусь за то, что там есть пара дихотомий для мышления: культурное-дичок, формальнодискретное-непрерывное.
Второе лирическое отступление: тот текст про онтологии и бибинарную модель мышления некоторые люди не понимают вообще, некоторые понимают там каждое слово, но не весь текст, но я также рад и счастлив был обнаружить людей, которые его понимают целиком. Согласен, этот текст -- не попса, в какой-то мере он эзотеричен, его не понять, если не знакомиться с материалами по тамошним ссылкам и не представлять хотя бы примерно ситуацию в исследованиях по deep learning, байесовской статистике, логике, когнитивистике и традиционной computational ontology. Тем не менее, свою аудиторию текст имеет. И он как раз из серии "программных", определяющих на долгое время направление деятельности.
написал(а) в своем ЖЖ
Я писал в 2011 году про четыре поколения информационных систем для инженерных проектов -- электронная бумага, электронный…
AILEV.LIVEJOURNAL.COM
Комментарии
Владимир Кириллов Пока что темы онтологий достаточно далеки от практического применения. Практическое общение более похоже на собирание пазла-рисунка с совершенно неизвестным по времени результатом. В реальном проекте на это просто нет времени. Еще большая проблема - эт...Еще
Анатолий Левенчук Я об этом и пишу: "результат по времени совершенно неизвестен", особенно когда у людей уже сложены свои онтологии. И совмещение онтологий происходит отнюдь не путём мэппинга к какой-то третьей "стандартной" онтологии -- а ad hoc. После чего все надежды онтологов на принесение счастья миру не оправдываются, и мир ждёт совсем другого по типу инструментария, в котором любые онтологии будут только начальными priors.