Обсуждение

>>Нужен 15926L, язык. Как может выглядеть такой язык, я себе не представляю -- но делать нужно именно его. Такая версия пришла в голову. Предположим, существует платформа моделирования реальных (бизнес-)процессов, с каким-то внутренним "ассемблером", удобным с т.з. исполнения и проверки разных сценариев. Язык 15926L должен компилировать реальные процессы из описания в 15926-темплейтах в этот "ассемблер".

Т.е. например так: описание на "24744-языке" -> описание в "15926-темплейтах" -> модель в "моделирующем ассемблере" -> запускаем, генерируются важные случаи, неустойчивости, развилки, дедлоки и дедлайны и т.п.

Анатолий, вы очень ёмко сформулировали в пункте 5.1 то, о чем я думал последние две недели про собственно активную составляющую онтологического программирования, поэтому, как бы в ответ, позволю себе поделиться своими мыслями на этот счёт. Во-первых, для меня, как для практика, очевидна пройденная уже даже мэинстримом точка невозврата на пути к мультипарадигмальному подходу. Уже нормально воспринимается описание интерфейсов на декларативном HTML+CSS, бизнес-правила на чем-то вроде RuleML/DRL, workflow на BMPN/jBPM, логику доступа к данным на SQL/OQL/HQL, причём все это в рамках одной единоначальной системы. Да чего уж там, современные фрэймворки для процедурных языков третьего поколения впитали в себя наследие казалось бы красивых, но не слишком удавшихся XForms и XBL. В общем, вопрос о том, на каком языке будут писаться системы следующих поколений я считаю решённым в общем случае -- на нескольких, каждый к своей задаче. Следовательно и во-вторых, нам уместно задаться вопросом каково же место 15926L под солнцем. Примерный ответ -- где-то начиная с чуть ниже слоя контроллеров (в смысле MVC-парадигмы) и вплоть до слоя ресурсов (СУБД, внешние- или legacy-системы). Мы говорим, что семантический репозиторий на базе "окончательной онтологии" отличается от СУБД тем, что каждая запись в нём имеет вполне конкретный смысл в самом реальном мире, укоренённый в самых базовых понятиях и, тем самым, в любой момент является полностью (само)описанным. Комплиментарно, на языке, с которым стыкуется семантический репозиторий, говорят о том, каким образом преобразуются смыслы записей или, точнее, какие по смыслу преобразования связывают старый и новый смысл. Точка сопряжения -- место, где "процедурный" клик отобразился на "инфологическое" изменение смыслов. В-третьих, если вспомнить о "статической" 4D-онтологии ISO 15926, где нет течения времени, а есть только темпоральные части, то кажется уместным и о преобразованиях говорить как об _инвариантных соотношениях между различными темпоральными частями_. Примерно вижу, что на "онтологическом языке" 15926L будут естественны конструкции такого типа: "Значение любой темпоральной части остатка банковского счёта равно значению предшествующей темпоральной части изменённому на сумму операции, представляющей (represents) момент окончания предыдущей и начала этой темпоральной части остатка банковского счёта" -- FOL, в общем-то. В точке стыковки же будет лаконичное утверждение, что "появилась новая операция по банковскому счёту". К слову, чтобы обеспечить этот в общем-то заурядный и очевидный пользователю инвариант в "мэинстримных технологиях", требуется изрядная инфраструктура, что выводит требования в разряд архитектурных, так что компактификация от 4D-онтологического описания на лицо. Любопытно, что писать "на монадах" с некоторыми оговорками можно почти в процедурном стиле. Боюсь, что в пике своего развития язык онтологического программирования будет со стороны выглядеть как "ещё один язык".

Я согласен со многими вашими утверждениями (а по мелочам и спорить не буду). Но хотелось бы понять, как именно это все может выглядеть. Например, как выглядит онтологическое факто-ориентированное программирование из объектного Питона. Ну, или как именно будут закрываться URI разноязычными labels. И тысяча подобных вопросов. Но вы правы с особенностью такого программирования. Если вас заставить к каждому идентификатору делать привязку к окружающему миру, вы взвоете с одной стороны, а с другой стороны, открываются удивительные возможности по взаимодействию с другими программами и людьми.

У нас есть ISO 24744 (жизненный цикл), проектное управление (кажись, только с графическими языками), процессное управление (BPMN 2.0), работа сервисов (всякие SoaML, хотя они и не совсем про это), а также business rules (которые часто используются как язык для ограничений в этих процессах). Что из этого берем? Я надеялся, что ISO 15926 поможет как-то в этом месиве разобраться. А вот что тут будет "вычислять" .15926L, я не представляю. Это традиционный вопрос к декларативным программам: что они "вычисляют", нужно отдельно прописывать в силу непроцедурности языка. И еще я не понимаю, как язык что-то "компилирует". Это компилятор компилирует, а язык должен лаконично и в удобной с точки зрения мыслительных манипуляций форме выражать. У меня вопрос не про целевой язык, куда компилировать, а про то, что на нем программируется и в чем семантика "выполнения". Пока программируются только структуры данных, но не операции с этими данными. У меня есть подозрение, что операции с данными будут питоновские, например, а вот структуры данных -- 15926. Как будет выглядеть такой мультипарадигмальный язык?

Вы тут говорите, что описание в темплейтах -- это промежуточное описание парсированной программы при переводе ее с одного языка на другой язык. Типа байт-кода для языка высокого уровня, который потом интерпретируюется виртуальной машиной этого языка до уровня исполняемых машинных кодов. У меня вопрос чуть другой: как вы исполняете описание в темплейтах? Судя по всему, вы "исполняете в особом смысле", т.е. просто компилируете его в исполняемый код (который тоже, замечу, не очень-то исполняем). В вашем примере проблемы начинаются с описания на 24744L, которое еще нужно сообразить в каком смысле "исполняемо" -- тоже только в смысле компилирования описания и какого-то анализа (даже не соображу, какого: какие там можно из этого описания извлечь "важные случаи, неустойчивости, развилки, дедлоки и дедлайны", там ведь никакой информации для этого нет!). Я имею ввиду более простую ситуацию: нужно написать какую-нибудь простую программу анализа данных, например, на Питоне. А структура данных -- из ISO 15926 (то есть дана в терминах URI, и даже label на парочке языков привязаны к этим URI отношениями). Как писать операции на Питоне, чтобы синтаксически и семантически нормально работать с данными из RDL как с родными питоновскими структурами данных? И на питоне ли это нужно писать, или лучше какой-то другой язык взять (функционально-логический, или объектно-функциональный или еще какой-то более мультипарадигмальный, чем Питон)? Как бы могли выглядеть программы на таком языке? И кто был бы способен такие программы писать? На питоне ведь многие люди писать способны, но на функционально-логической экзотике только единицы... См. также комментарий cryozot чуть ниже.

Да, с "компилирующим языком" это я загнул.

Я думаю, в этом случае нужно доделать Mapper как я планировал - и тогда уже будет какая-то песочница, чтобы делать опыты. А без такой песочницы сказать как будет выглядеть этот язык, очень сложно. Это должно появиться естественно, в ходе решения реальных задач.

Попробую сформулировать как это выглядит. Мыслим о платформе онтологического программирования как о двух взаимосвязанных компонентах. Первый компонент -- семантический репозиторий, который помимо схемы и 4D-фактов о сущностях реального мира содержит также декларативные описания инвариантных соотношений между темпоральными частями этих сущностей. Описание соотношений делается в терминах логики предикатов первого порядка. Делать такие описания достаточно легко на тех же шаблонах, которые определяются специализированную локальную онтологию (OIM, хоть это и deprecated термин) для таких соотношений. Однако, в силу четырёхмерности онтологии в семантическом репозитории "время остановилось": описания соотношений есть, а вот действия нет. На философский вопрос о возможности движения мы отвечаем выделением второго компонента -- "пульт" или активатор. Задачей активатора является порождение изменений в фактах, которые представлены репозиторием -- "импульс воли". Для 4D-онтологии изменения фактов сводится к порождению темпоральных частей сущностей репозитория, как новых, так и ранее известных. Дальше проще: поскольку соотношения между темпоральными частями уже заданы в репозитории, появление новых вызывает каскад проистекающих из этого факта преобразований других фактов, которое в свою очередь также выражается в появлении новых темпоральных частей. Etc, etc, etc, до тех пор, пока волна активации не затухнет. Взаимодействие с внешними ресурсами (теми же веб-сервисами), кстати, можно достаточно легко "упихнуть" в 4D-соотношения, если представить их как монады в том смысле, что они декларативно описывают последовательность операций с side effect'ом. Тут потребуется некоторая локальная онтология для описания такого набора монад. Теперь разовью пример из предыдущего ответа: 1) Берём простую онтологию: есть банковский счёт со своим текущим остатком, есть операции со своей суммой (пусть будут просто операции списания и операции начисления). Онтология четырёхмерная, у банковского счёта есть темпоральные части. 2) Описываем соотношение: любая операция по банковскому счёту связывает две последовательные темпоральные части банковского счёта, при этом сумма операции и остаток банковского счёта до операции вместе равны остатку банковского счёта после операции. Это соотношение тривиально формулируется в терминах логики предикатов. 3) Активатор позволяет сделать из того же питона вызов "новая операция для указанного банковского счёта", после чего в семантическом репозитории появляется сущность операции с указанной суммой и счётом. 4) Волна активации раскручивает соотношение из п.2, что приводит к появлению новой темпоральной части соответствующего банковского счёта и вычислению его остатка в этой части. Сигнатуры вызовов для активатора могут легко байндится к любому языку, будь до веб-сервисы или тот же питон.

Это ровно то, что я тоже хотел предложить. Когда ни у кого нет особого понимания, теория говорит "нужно делать эксперименты". Mapper с шаблонами, и попробовать на него посадить Editor.

Я думаю, что это неподъемная вычислительно задача. Онтология всего мира едина, и ежели у вас появился маааахонький факт, то вам нужно будет при таком механизме провести глобальное вычисление по всей онтологии, обойти всё дерево Thing. Мне кажется, что при постановке задачи нужно четко разделять "онтологизирование в большом" и "онтологизирование в малом", то есть думать про модуляризацию вычислений. Это само по себе проблема, ибо вычисление, по идее, идет в федерации библиотек справочных данных (которые "типы и константы"), но может быть и федерация несправочных (т.е. инстансов) данных -- и как вычисление идет там, понятия не имею. Я пока для себя думаю, что как "апплеты" есть "онтолеты". Всё сложно...

Я провёл некоторые эксперименты. В принципе, эти самые инвариантные соотношения между различными темпоральными частями, записанные в терминах логики предикатов, достаточно легко компилировать правила для прямого логического. Например, соотношение в пункте №3 моего примера в предыдущем комментарии ("любая операция по банковскому счёту связывает две последовательные темпоральные части банковского счёта, при этом сумма операции и остаток банковского счёта до операции вместе равны остатку банковского счёта после операции") достаточно просто автоматически преобразуется в правило вывода "появление новой операции на банковском счету приводит к появлению новой темпоральной части этого банковского счёта". Прямой вывод по таким правилам с помощью вариаций алгоритма RETE имеет очень хорошие скоростные характеристики, так как меняет скорость на память, и при этом он отлично масштабируется на огромное число правил вывода. Однако для онтологий с большим числом фактов это не подходит, поэтому может быть и не RETE, а что-то гибридное -- надо смотреть по сторонам. Собственно, какая-то картинка сложилась, наверное можно написать виденье в сообщество dot15926, чтобы было о чём подумать. Однако вопрос к вам как к координатору усилий по проекту: стоит ли сейчас тратить время на дальнейшую проработку этой темы или лучше вернуться к текущим базовым вопросам про федерации и версионирование?

Мне кажется, что базовые вопросы про федерацию и версионирование важнее сейчас. Более того, их никто не понимает, поэтому тема кажется "лёгкой и незначительной". Кроме того, пока непонятно, насколько мы влезаем в программирование в условиях федерации серверов. Но даже для одного сервера с редактором возникают всякие варианты с undo-redo, связанные с непонятками по "расширению" шаблонов и принятыми оптимизациями. Я тут глубоко за пределами собственной компетенции. Просто я вижу, что версионирование является важнейшей частью любых систем программирования -- и ежели сразу не делать любое хранилище в формате системы работы с версиями, а редактирование в стиле "коммитов", то можно нарваться на проблемы.

Для полностью корректной онтологической проработки вопроса банковского счёта надо обсудить ещё несколько моментов. В соответствии с лекциями отцов стандарта 15926, существуют не только прошлые и настоящие, но и все будущие темпоральные части, при том для всех возможных миров. То есть "новая" темпоральная часть не "появляется", а "актуализируется". Видимо, адекватное описание логических оотношений темпоральных частей должно выполняться не на FOL, а в какой-то модальной логике, с темпоральными и деонтическими операторамию

И я тут же вспоминаю учебник по агентскому программированию, нашпигованный именно такими логиками...

Ну да, это вообще вопрос об устройстве человеке - в "состоянии покоя" его голова нашпигована разнообразными модальными, темпоральными и деонтическими утверждениями (фактами), а потом в применении к реальному миру возникает процедурная программа. But how?