Comments 9
Очередной раз наблюдаю карго культ. Автор проникся принципами логического программирования и теперь, как настоящий молоток, во всём видит только гвозди. В результате пропагандирует применение математической логики (а ранее - алгебры) в тех областях, где они заведомо обречены на провал.
Автор, разумеется, гневно потребует доказательств. Но на это я могу сказать одно - читайте о результатах многочисленных неудачных попыток внедрения формализмов в повседневную жизнь. И поменьше увлекайтесь умными словами, вроде "эпистемологии" и тому подобного. Ну и не смешивайте умные слова с, например, такими перлами - "знаниевый инженер", а то выглядит реально по детски.
Начинайте гуглёж с фразы "инжененрия знаний", и не забывайте добавлять ключевые слова вроде "ошибки", "провалы", "неудачи".
Хотя можно и от обратного - где в мире хоть одна контора смогла хоть чего-то достичь при массовом внедрении предлагаемой математики?
Ну и если автор вдруг не в курсе, замечу, что пока в реальной жизни все формализмы ограничиваются весьма произвольно трактуемыми простенькими диаграммами. А большей частью - имеем просто текст. Введение математики в это суп сделает его неперевариваемым для большинства потребителей.
В результате пропагандирует применение математической логики (а ранее - алгебры) в тех областях, где они заведомо обречены на провал.
В любом случае, спасибо что прочитали все мои опусы, включая про алгебру процессов.
Автор, разумеется, гневно потребует доказательств.
А как иначе? Критика бывает разная, тут я вижу:
Признаки деструктивной критики:
1) Критикующий ощущает себя последней инстанцией, слова которой нельзя подвергать сомнениям.
2) Критика не чего-то конкретного, а буквально всего.
3) Нет примеров и доводов.
4) Критик зацикливается на мелочах, которые не важны.
5) Критика идет по поводу и без повода, даже если об этом не просят.
6) Выражение мнения о самом человеке в неуважительной форме, а не о действиях, мнениях.
https://biznesrealnost.ru/vidy-kritiki-razlichaem-i-delaem-vyvody/
Ну и не смешивайте умные слова с, например, такими перлами - "знаниевый инженер", а то выглядит реально по детски.
https://moskva.jobfilter.ru/vacancy/185300250
Спустя время на hh сменили название (но как видим, это не очень помогло), но инженер знаний, инженер по знаниями и т.п. - уже типовые запросы в интернете. Неужели большинству "Онто-инженер" понятнее знаниевому?
Вы концентрируетесь на выдуманной проблеме "Выражение мнения о самом человеке в неуважительной форме" полностью забывая о сути сказанного. Соответственно, с вами нельзя взаимодействовать конструктивно - вы обязательно воспримете критику ваших идей как критику лично вас, ну и потому я не смогу вам что-либо объяснить пока вы не смените подход.
Так вот в чём основная проблема меня и всех остальных разработчиков - мы пытаемся чтобы ПО работало формально - в соответствии с ТЗ, а оказывается это "попытки внедрения формализмов в повседневную жизнь". ПО и разные информационные системы должны работать исключительно неформально, т.е. не соответствовать ТЗ, документации и инструкциям.
Очень.......странная статья. С одной стороны автор явно человек знающий, образованный, начитанный. В общем явно разбирается в том, о чем говорит. Даже в какой - то мере - фанатеет. Но сама статья скорее не статья а набор мыслей, фактов и ссылок. Поток сознания, выплеснутый на бумагу. И в этом выплеснутом, как в морском прибое на песчанном пляже очень много ценных (ну по крайней мере для меня лично) вещичек, идей, понятий, ссылок. Но в целом логика потерялась.
Но за бриллианты, янтарь и ракушки в этом материале - огромное спасобо!
"По секрету", преследовал две основные цели: “Так объяснял, что и сам понял” и поиск единомышленников.
Причин традиционно было несколько.
Статья - способ уложить накопленные знания
Мне нравится выражение: “Так объяснял, что сам понял”. Это отлично работает не только при личном общении, но и в статьях. Излагая тему в тексте, ты видишь, где есть пробелы в логике, и заполняешь их, тем самым дополняя собственные знания. Даже если никто не пришел комментировать статью, сам факт подготовки материала как правило идет на пользу. А если завязывается дискуссия в комментариях, всплывают интересные и даже нестандартные взгляды на проблему, а также рекомендации, как ее можно решить иначе. Это отличный способ получить идеи для развития своего проекта.
Развитие публичного профиля
Статья - способ показать, что ты специалист в вопросе, найти единомышленников …
https://habr.com/ru/company/maxilect/blog/712606/
Однако на комментарии, особо не надеюсь, т.к. часто приходят комментировать "муркины коты". Статьи - больше как популяризация идей (полнометражные примеры ЕА, WF2M сети, semantic BPM, инструменты типа SmartDesign и др.) в расчете, что когда-нибудь получится собрать несколько единомышленников (на общественных началах) и что-то реализовать практическое или попасть в подобный проект. Эти темы пока не популярны, но надежда погибает последней. К сожалению, в теме ВРМ куда больше лукавства, чем математики, семантики и научного менеджмента.
Немного по существу:
"простые случаи перевода между языками человеческими (ru/ en)" - перевод между языкам человеческими как раз очень часто упирается в семантику. Потому как человеческий язык базируется на внутренних культурных образах, которые у народов с разными языками порой очень сильно не совпадают. И использование тут простых (дословных) переводчиков в лучшем случае делает текст плохочитаемым на другом языке. А в худшем (и наиболее частом) - смыслы искажаются, порой до полностью обратных.
По поводу перевода языка графики в XML и обратно. Ну во первых, любая компьютерная графика изначально существует в некоем НЕ-графическом языке - как минимум набор вызовов функций графического процессора. Пример - формат wmf, а далее уже форматы, в той или иной степени уходащие на дистанцию от графических примитивов графического процессора (SVG, EPS). Вплоть до автогенерации размещения элементов на итоговой картинке (DOT - Graphvis и прочие "diagrm-as-code"). Но самая главная проблема как раз в том, что такие языки возможно отражают семантику ФОРМИРОВАНИЯ КАРТИНКИ, но очень слабо или совсем никак не отображают семантику иллюстрируемого смысла. Даже весьма популярынй PlantUML. Он максимально близок к кодлированию именно смыслов модели, но всеравно более склоняестя к кодированию именно картинок. Пример: как только в подобном языке возникает возможность указать ЦВЕТ блока или стрелки, или возможность на концах стрелки задать разное количество разных закорючек - это уже про картинку а не про смысл. Про смысл будет, если мы эти цвета и закорючки сначала определим внутрь семантического шаблона, а потом уже с помощью таких шаблонов будем описывать предметную область. То есть разделяем вопросы "как нарисовать" от вопросов "каков смысл взаимоотношений".
"Такой инженер может не знать ни одного синтаксиса (языка), поэтому он передает смысл «человеку-интерпретатору» языка Б" - сильная мысль, но скорее всего - не правильная. Потому как мы (люди) судя по всему до сих пор слабо понимаем, что такое "смысл" и как он представлен у нас в мозгу (или где там он еще может быть представлен). Но передавать его мы умеем ТОЛКО через какую-нибудь знаковую систему. Через язык, через схемы, визуальными образами, в конце концов - кинестетически, ударами по лицу или заду. В любом случае исходный "смысл" перекодируется в "знаковую систему" а потом у получателя перекодируется обратно. И на каждом этапе НЕИЗБЕЖНЫ искажения. Можно ли определить некий "Эталонный" смысл и как то передать его таким образом БЕЗ искажений - не знаю. И будет ди это в таком случае передачей именно СМЫСЛА, или же еще одна комплексная знаковая система?
По первому абзацу. Вроде бы в статье показаны два концепта перевода: «синтаксис - синтаксис»
«синтаксис – семантика - синтаксис». Подробно показаны различия. Не знаю, что добавить.
По второму. Продублирую из источника картинку из указанной в статье ссылки:
Пример «синтаксис - синтаксис» из «языка графики» в XML и обратно (в динамике): Editing the Diagram and its XML Side by Side
Снизу XML, сверху графика. Формально это не семантика. Что у рисовальщика в голове может быть "поднят" уровень семантики - этот сюжет не исключает.
По третьему.
Есть разные подходы к градации "Данные - Информацию - Знания", например, пятиуровневая:
https://www.comindware.ru/book-inventing-information-systems-of-the-future/
Про концепт знаний: https://biblioteka.sibsau.ru/pdf/izdv/izdv_sibgtu/Lutoshkina_Modeli_2021.pdf
Одна и та же смысловая тройка (триплет) будет иметь разный смысл, если, например, к используемым в ней предикатам (отношения) подключать разные онтологии (переключать ссылки на разные словари). Только когда при интерпретации триплета используется одинаковая или схожая онтология, мы получим (передадим) единый смысл.
Не столь важен, объективен (к спору идеалистов или материалистов) этот мир идей, образов или нет, но через семантические технологии мы можем конкретизировать и публиковать этот «мир идей / образов». Об этом мире у Платона, у калининградца Канта, у современника Левенчука это "Пространство смыслов" , см. книжку «Визуальное мышление» (заодно и «Системное мышление»). https://ailev.livejournal.com/1418832.html
и как он представлен у нас в мозгу (или где там он еще может быть представлен).
Конечно интересно знать «как», но применительно к semantic BPM – это и неважно, что же там внутри черепной коробки и как работает, биты там или нет (может квадро: да\ нет\ не знаю\ вообще ничего нет - т.е. пусто, Null PL/SQL Oracle), физический канал передачи данных электрический или химический, биополе и т.п.
Даже если вдруг окажется, что мысли \ знания внутри нас «кодируются никак» (перефразировано из Левенчука), то это ничего не меняет. Это все в сторону философии, а не практики semantic BPM.
сильная мысль, но скорее всего - не правильная.
Так и не понял, в чем неправильность.
Где-то встречал интерсную мысль о том, чем западные стратапы отличаются от российских.
Западные стартапы берут ПРОБЛЕМУ, а потом создают ЧТО-ТО, что может ее решить.
Российские старапы создают ЧТО-ТО, а потом ищут к какой-бы ПРОБЛЕМЕ это применить
Так и тут. Мы придумали semantic BPM! Хммм... К какой бы проблеме его применить?
Semantic BPM. Семантика и синтаксис бизнес-процессов