Обсуждение

В ссылках про SysMoLan пару раз один и тот же url. А вообще, ностальгичненько так (тот же .15926). Причём, без скрипок и нердов результаты могли бы быть интереснее.

Ой, url fixed, спасибо. А что там было скрипково, и что там было нердово, без чего можно было обойтись?

Нердами в данном случае были онтологи. Это была одна из двух целевых аудиторий продукта (наряду с инженерами), но я не помню ни контрактов, ни даже фактов полезной обратной связи от аудитории по этой линии. Разваливающейся скрипкой был сам стандарт ISO 15926. Он создавался в философском подходе "есть гипотеза - объявим истиной", в результате чего проверка гипотез и их относительной пригодности в интеграции данных легла на наши плечи. Конечным же клиентам такое было просто не интересно. В то же время, как показал ещё наш первый опыт с Росатомом, тогда был запрос на инструменты диагностики/отладки и управления интеграцией данных. А решения в этой нише наблюдались весьма эзотеричные, типа "мэппинг только между HL7 и XML, с удобством UI уровня Windows 3". Переход продукта к стандартонезависимости (где форматы ISO 15926 лишь возможные опции мэппинга) дал бы как возможность развития в этой нише, так и, с дальнейшими доработками, в нише data science. Кроме того, это дало бы обширную практику, позволяющую, в сочетании с проверкой идей BORO, ISO 15926, Gellish, HQDM и прочих, находить и улучшать эффективные способы описания мира.

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

А есть ли в истории человечества хоть один успешный проект, где роль онтологов сводилась не к "топору" в "Каше из топора"?

Мне в работе знание онтологии существенно помогает. Конечно, я онтики делал в изобилии и без знания upper ontology, но знание upper ontology позволяет структурировать всякие методологические материалы с нечеловеческой силой. Это избавляет от многих ошибок.

Навыки штука полезная и приобретаются в разных ситуациях ("вокруг всё так плохо, что пришлось научиться хорошо"). Вопрос в том, есть ли онтологический стандарт [название], онтологическая методика [название] или онтологическая технология [название], которая внесла необходимый вклад в успех какого либо проекта (не семантиквебовское "сделали на триплсторах, получилось лишь в несколько раз медленнее, чем на реляционках"), будучи разработанной вне его?

Максимальную пользу нанесла книга Криса Партриджа и знание ISO 15926-2 как конкретизации этого подхода. Вообще никак не связано в выбором реализационного инструментария: чисто концептуальные схемы, основные решения принимаются на концептуальном уровне. Например, можно разговаривать о самых разных проектах, применяя одно и то же мышление -- и быстро выправлять коленвал. Системное мышление, в основе которого какая-то 4D экстенсиональная онтология в консалтинге -- это страшная сила. Просто разговоры о менеджменте и инженерии становятся весьма доходчивыми и структурированными. Тут нужно учесть, что я ж не разработчик софта и не консультант фирм, разрабатывающих софт, чтобы вот так сразу про "применение триплсторов" говорить. Была идея поработать в этом направлении с инженерами, но она не оказалась плодотворной (и есть разные точки зрения на счёт "почему" -- http://ailev.livejournal.com/1343851.html). DSL в Julia тут задаёт новый поворот разговора, наряду с чьим-то замечанием, что "то, что мы хотели сделать в экспертных системах, давно сделано уже в обычном софте: сложность логики там примерно та же, только результат более сопровождаемый за счёт очевидных прорывов в управлении конфигурацией, изменениями и инструментария обеспечения модульности". И помним, что как в SBVR, эти экспертные системы на 5% продукции и на 95% онтологии (чтобы выразить правила, нужно определить объекты, над которыми эти правила работают).

Вот том и дело, что польза получается неким "влиянием на умы" через гипотезы, которые должным образом не протестированы их авторами. Например, работа с временем в BORO и ISO 15926-2 построена на базе темпоральных частей. Но при создании .15926 у меня всё время было ощущение "да, идея кажется правильной, я могу так _говорить_ о некоторых ситуациях, но почему попытки применить её в данных или коде лишь вредят?". Возможный ответ нашёлся сильно позже - темпоральные части это шаг в правильном направлении, но совершенно непрактичная метафора. Однако, если я выкину темпоральные части и буду рассуждать в терминах темпоральных подмножеств, позволяющих компактно выразить даже "светофор id123 в те периоды, когда горит зелёный свет", то получается совместимо и с человеческим восприятием, и с речью, и с кодом. Но и такое предположение требует проверки. В этом мой пойнт. То, что предлагается по лейблом "онтологического" или "семантического", представляет собой наборы сырых гипотез. И лишь некоторые из них являются хотя бы "пищей для ума". Однако, BORO, ISO 15926, семантиквебовщина - всё это позиционируется для использование "как есть". Чего делать нельзя.

Ну, "как есть" ничего использовать нельзя. С какого-то момента (когда понимаешь хорошо, что там неправильно) приходится подхакивать. Тот же Essence, например, нами был существенно подхакнут (и, кстати, Lawson до сих пор за наш вариант, а Jacobson против -- было подтверждено буквально на этих днях). Что касается "онтологий" то это слово сегодня как "программирование", внутри него может подразумеваться что угодно -- вот, например, только сегодня опубликовано: http://serge-gorshkov.livejournal.com/46586.html (и хорошо понятно, что в реальности это может быть чем угодно: от традционной экспертной системы до просто трипл-стора, от системы интеграции данных до NoSQL базы данных к какой-то прикладной программе, от кривой онтики до вполне респектабельного онтологически проекта). Что же касается полных темпоральных частей, то если делать упор на них как события и них как состояния, то очень хорошо получается разговаривать про физические объекты. Но они другим интересны: разговором про функциональные объекты -- смену исполнителей для ролей проще всего обсуждать через состояния функциональных объектов, когда их роль исполняется одним физическим объектом и другим как разными темпоральными частями. И экстенсионализм, которые эти два разговора склеивает. Очень удобно. Но это нужно только тогда, когда описываешь ситуации проектирования, и когда при проектировании хорошо понимаешь работу с функциональными объектами. Мой опыт показывает, что с функциональными объектами и их пониманием полный швах. С одной стороны, всё знание несётся именно через функциональные объекты, а с другой стороны осознанности в понимании этой функциональности ни у кого нет. Принцев Гамлетов и Василиев Пупкиных, играющих их роли путают отчаянно все. Пока не распутаешь -- никакого тебе 4D, ибо это лекарство от болезни, которой не знаешь, что болеешь. До софта и кода даже дело не доходит, всё превращается в тыкву уже при попытках понять задачу. Вот примеры: http://ailev.livejournal.com/1361455.html и http://ailev.livejournal.com/1361765.html, и буквально в пятницу мне один из клиентов сказал, что до сих пор они в КБ бьются над объяснением заводу "ситуации заказа ножниц" (хотя там не ножницы, а другое оборудование). И когда ты начинаешь этим людям говорить про темпоральные части в любом языке, то этими частями в их мозгах становятся совсем уж монстры, и далее full stop всех проектов, всех разговоров.

Сейчас "онтология" это не "программирование", а скорее алхимия, в противовес химии. Лучше оставить зашквареный термин. В отличие от системной инженерии, которая (пока?) нет. Что касается "physical vs. functional object", то подобная дихотомия работает для стандартного примера "замена насоса", но до того момента, как оказывается, что "роль" _физического_ насоса id123 после возвращения из починки исполняет насос id234 (по каталогу ремонтного сервиса, предприятие же отправило id123 и получило id123). Всё может быть ролью, и "Принц Гамлет", и "Вася Пупкин". У нас есть лишь прикидка, что множество сегодняшних молекул/атомов Васи мало чем отличаются по интересующему поведению от вчерашних. В общем, трудность объяснения может быть обусловлена не контринтуитивностью ситуации, а неработающей метафорой вроде "physical vs. functional".

Сегодняшняя (не моделеориентированная) системная инженерия не алхимична, а "псевдокодна": модели не формальны, но и не "просто метафоры". Формальные хоть как-то модели в моделеориентированной системной инженерии, и в эту сторону всё стремительно и катится. С онтологией чисто философская онтология по факту метафорична, философская логика работает уже с псевдокодом (несмотря на название), а computational ontology пытается работать с кодом, моделирует. Другое дело, что модели крайне трудоёмки, этих онтологов мало и они как математики -- для прикручивания к делу нужны какие-то хитрые люди типа физиков для математиков, это место пока не сформулировано, может быть это и есть "программисты" (исходя из того, что моделирование-программирование-онтологизирование это одно). В Julia чем интересно, они предлагают стиль программирования, завязанный на типы (http://www.stochasticlifestyle.com/type-dispatch-design-post-object-oriented-programming-julia/, http://www.stochasticlifestyle.com/modular-algorithms-scientific-computing-julia/) -- и неожиданно можно пробовать развернуть онтологические построения на этом месте в части моделирования "псевдокодных" работ философских логиков и дальнейшей проверки их идей на удобство работы с ними на уровне кода.

Отдельно fhysical vs functional: я предпочитаю говорить "функциональный и конструктивный", "компонентный и модульный", вынося физичность за скобки. Физичны/молекулярны/атомны они оба, это экстенсионализм. Различалка же в другом, она используется в архитектурном компонентном/функциональном анализе и модульном синтезе, замена насосов даже не главное. Я просто хотел заметить, что замену насосов не объяснить, пока не понимаешь про все эти различалки с разными ролями и их пятьюдесятью оттенками функциональности, конструктивности, пространственности (allocation) и прочих viewpoints. Мой опыт в том, что у людей в головах тут винегрет, и все эти диаграммы экстенсионализма плохо воспринимаются: один невнятный-непонятный объект своими молекулами вдруг совпадает с другим невнятным-непонятным объектом, а что оба этих объекта вдруг называются "насос такой" и "насос сякой" только запутывает дело -- в ментальной темноте нынешних инженеров все насосы серы, бестипны и мутны в их различениях и именованиях. Так что приходится сначала зажигать свет разума во viewpoints, чтобы потом объяснять совмещения объектов viewpoints через экстенсионализм.

Тут дело даже не в физичности, а в излишней типизации. "Функциональный насос" - мутно, эзотерично. "Функциональное представление" - уже ок. Явление того же порядка, что "вид с высоты" и "вид с парадного входа". Или даже "переключение между плиточкой и списком" в Explorer.

ну вот это традиционная путаница: считать, что функциональные предметы существуют на самом деле, или существуют только функциональные описания, а самих предметов нет и есть только конструктивные предметы. На принципиальных схемах описаны предметы, которые в реальности-то как существуют? Студенты часто у меня говорят, что компоненты живут только в описаниях. То есть лезвий у ножниц нет, двигателя в компрессоре нет. Мэтью Вест такому подходу возражает, и справедливо. Лезвия есть, и двигатель есть. Хотя заказать их отдельно от ручек ножниц и турбины компрессора нельзя. Вот в этом месте мозг нужно напрягать, в месте модульного синтеза, а не на объектах, где функция и конструкция совпадают (типа того же насоса с их заменой).

С функциональными срезами можно работать теми же способами, что и с темпоральными, достаточно "понять один раз". Вообще, у меня была мысль написать пост или серию о решениях тех проблем (включая проблемы восприятия неподготовленной публикой), которые были хорошо идентифицированы в ISO 15926 (плюс BORO, Gellish и HQDM), но плохо или никак решены там же. Однако, я решил этого не делать. У нас есть общий опыт (включая разработку .15926), позволяющий обыденно обсуждать подобное в текстах, но для показа того же сторонней аудитории не обойтись без видео. Здесь получается как с выворачиванием сферы ( https://www.youtube.com/watch?v=-6g3ZcmjJ7k ).

Ну да, это речь о пространстве (хоть и 4D), поэтому без видео или хотя бы изобилия картинок не обойтись. Действительно, "функциональный срез" это интересный термин, так же как "временной срез". Он и есть, но он и срез -- то есть накладываемая на пространство знаниевая структура. Есть базовый предмет и есть его срез. Дальше можно рассуждать по линии fff -- function follow form, form follow function. У "просто архитекторов" form follow function, у ТРИЗовцев function follow form, то есть они подбирают функцию под данную им физическую форму, у них первична форма, а "срез" подбирается. И это нормально. А вот у "просто архитекторов" есть функция, которая существует в уме ещё до формы, "срез пустого места", что труднопредставимо. Со срезами об этом размышлять трудней, чем когда участвуют равноправные объекты. Ну, или не трудней. Тут действительно нужно проводить эксперименты. Но я согласен, что есть какие-то дидактические препятствия кроме чисто мыслительных. После того, как я перепаковал порядок изложения материала (и неоднократно), курс системного мышления стал в разы более доходчив до людей и более практичен. Всего-то пять лет практической учебной деятельности, с 2012 ))) Мысль написать пост хороша, но в один пост это не упакуешь (исходный материал-то на сотни страниц), поэтому для начала нужно просто список проблем, чтобы к нему можно было возвращаться и раскрывать постепенно.

У "просто архитекторов" есть очень понятный "вид с парадного входа", ещё до реализации проекта. Но это частный случай, для иллюстрации общего подхода необходимо видео. Иначе получится как с текстовым описанием танца. Которое человек теоретически способен понять... но если хоть раз такой танец видел.

Уже в который раз с вашей подачи смотрю на этот язык. И опять смешанные чувства. Динамическая типизация. Уже столько раз пробовал языки с ней, но каждый раз возвращался на какой-то строгий язык типа C#, Java, Go... Динамическая типизация - это легкое вхождение (что важно для непрофессиональных разработчиков), но масса проблем в сложных проектах. Возможно, только для меня. Может быть это просто какая-то особенность конструкции мозга определенного разработчика - ведь масса людей с удовольствием пишет на языках с динамической типизацией. В то же время, есть не меньшее количество тех, кто предпочитает "статику".

Почитайте ответ Стефана Карпински на вопрос про динамичность типов в Julia вот тут: https://stackoverflow.com/questions/28078089/is-julia-dynamically-typed -- ибо в языке есть особенности и усиления в части работы с типами, это ж не какой-нибудь Питон.