1. Мысль о ISO15926L несколько трансформировалась и сейчас выглядит как система типов с графовой семантикой, которая обеспечивает данные примерно так же, как платформа .NET, но с начальным наполнением этой системы типов RDL ISO 15926 независимо от использующего эту "внешнюю систему типов" языков-минус-типы (компиляторы которых, конечно же, придется немного подхакать, чтобы они вместо своих типов использовали "пришлые"). Тем самым получаем платформу онтологического программирования "дот онто" как принцип, или .15926 в качестве конкретного варианта. В качестве пробных языков в этом проекте указывались Python (эксперименты идут и были доложены), Scala (ибо тамошняя система типов "наиболее похожа"), Factor (по совокупности его заслуг), coq (логическая парадигма тоже имеет право на существование).
Вообще, "онтологическое программирование" (когда программист картирует используемые им типы к RDL -- то есть привязывается к более-менее "стандартной картине мира", а не изобретает картину мира каждый раз заново по любому малейшему поводу) стоило бы рассмотреть отдельно и специально. Это вовсе не использование библиотек или фреймворков, это имено "входные и выходные картины мира", алгоритмы приведения входных в выходные картины мира могли бы быть разными -- т.е. это "недобиблиотеки", или "недофреймворки" с одной стороны, а с другой стороны -- речь идет о моделировании внешней среды (стульев, столов, насосов, кораблей), а не "подсистемы графического вывода, как ее изнутри видят программисты" (окошек, курсора, веб-сервиса и API).
2. Наиболее вероятное первое приложение технологии -- это не развитие прототипов и экспериментов в сторону "еще одного iRING", а аналог EPF Composer со следующими характеристиками:
-- позволяет редактировать тексты, соответствующие метамодели ISO 24744, выраженные в ISO 15926 для последующего расширения. Входной текст -- текст с "разметкой", соответствующий ISO 24744 (текстовый DSL). Выходной текст -- это обычный текст с провязанными ссылками, собранным глоссарием и т.д.
-- редактор позволяет также рисовать простейшие онтологические модельки предметных областей в терминах ISO 15926 (для чего к тестовому питоновскому приложению может быть прикручен GraphVis или что-то подобное). Речь идет о редакторе, позволяющем более просто выражать модели с диаграммами классов и инстансов (включая слои Powertypes/clabjects и экземпляризацию). По факту это позволяет редактировать ModelKinds, ModelUnitKinds и т.д. из ISO 24744 в ходе ситуационной инженерии методов.
-- экспорт моделей в популярные PLM (через фасад ISO15926).
Достоинства такого выбора:
-- альтернатива EPF Composer с более "правильной" метамоделью. Таких приложений сейчас нет, если не считать закрытую и весьма ограниченную разработку zAgile.
Недостатки такого выбора:
-- много мелкой программистской работы, ибо по сути речь идет о создании language workbench (хотя поначалу речь и идет только о парочке DSL-24744 плюс DSL-классов-и-инстансов, в любом случае придется делать IDE надлежащего качества).
Замечу, что "конечная точка" для такого софта описана в пункте 3 тут: http://community.livejournal.com/praxos/1719.html
3. Поскольку пошла интенсивная работа со множеством самых разных DSL и речь идет о более чем одном "базовом языке", имеет смысл подумать об "идейном" (то есть не привязанном к конкретному языку программирования) языкостроительному инструментарию STEPS/FONC (http://www.vpri.org/html/writings.php), который может позволить иметь короткие коды. Описанные там идеи являются "паттернами программирования", а не примерами программ. Так, парсер OMeta2 уже реализован на Python (http://www.allbuttonspressed.com/projects/pymeta) и вполне возможна реализация того же подхода на Scala, Factor и т.д. (неполный список уже имеющихся реализаций на разных языках см. http://tinlizzie.org/ometa/). Про редактор-с-форматированием-по-правилам (что может быть крайне интересно для language workbench) можно сказать то же самое: http://www.vpri.org/pdf/m2010002_lobjects.pdf, http://www.vpri.org/pdf/m2010001_pobjects.pdf. Chains of meaning по факту очень близки к pointless style / теоркатегорному / компиляторщицкому описанию модельных трансформаций -- http://www.vpri.org/pdf/m2010001_pobjects.pdf.
И так далее по всему помянутому списку публикаций: если использовать сильные идеи, то код итоговой language workbench будет коротким и понятным.
4. Замыкание ISO 15926 на базе использования теории категорий. Для начала (это довольно быстро) теория категорий используется для выражения ISO 15926 наряду с FOL и OWL.
Достоинства этого действия: теория категорий по своей сути ближе к зависимым типам (см. для справки: http://community.livejournal.com/ru_deptypes/), нежели "просто FOL". Поэтому такая "перекодировка" будет приближать реализацию .15926
Недостатки: непонятно, какая математика/теория может быть использована для реализации ленивых проверок и минимизации представления семантических сеток ISO 15926 в оперативной памяти (предложения avlasov по ОПSL -- "оперативная память specific language" для представления ISO 15926-семантических сеток в оперативной памяти в ходе вычислений).
Собственно "замыкание" заключается в задании вопроса об онтологическом кодировании понятий теории категорий в терминах части 2 (возможно с жесткими вопросами к онтологическим выборам самой части 2). Тем самым мы имеем шанс получить систему типов, выраженную в собственных терминах. В качестве тестового различения для этой работы приводится неэквивалентность теории категорий теории множеств: в теории множеств объекты "копируются" и "уничтожаются", а вот в теории категорий есть и "некопируемые" и "неуничтожимые бесследно" объекты -- т.е. ведущие себя не как "информационные объекты", а как "материальные объекты".
Достоинства "замыкания" как такового представляются настолько большими и очевидными, что не требуют особого обсуждения.
5. ISO 24744 должен быть картирован в терминах не только части 2, но еще и части 4 (что означает, в частности, что все эксперименты должны вестись не с 201 понятием в оперативной памяти, а сразу с 50тыс. понятий).
Сюрприз оказывается в том, что понятия ISO 24744 в существенной мере высокоуровневы, и большие куски его метамодели таки будут картированы для языка части 2. Вот две дополнительные мысли от этого рассмотрения:
-- согласно теории деятельности, все онтологические рассмотрения имеют смысл только в контексте деятельности. Это означает, что ISO 24744 (ежели мы считаем, что этот стандарт как-то отражает описание деятельности/метода) должен быть глубоко интегрирован с частью 2, и отсутствие его там говорит о теоретической слабости самого ISO 15926.
-- системный подход является "попыткой создания светской онтологии", поэтому его понятия ("система", "жизненный цикл" и т.д.). ISO 24744 кроме "деятельностной" части содержит важнейшие понятия "системо" (если и не system, то очень близкие к lifecycle -- timecycle), а также "мысле" (понятия моделей, языков, нотаций и т.д.).
В любом случае, опыт ISO 24744 по кодированию метода заслуживает тщательного рассмотрения в контексте "правильной части 2" следующего поколения онтологической стандартизации.
6. Варианты упрощения ISO 15926 по тому же принципу, как из SGML был сделан XML: отрезав буквально чуть-чуть и потеряв в редко используемых возможностях, можно получить огромный выигрыш в простоте реализации, понятности и вычислимости. Де-факто по этому пути уже идут:
-- Gellish (где отрезали 4D-семантику со словами "4D время может не пригодиться"
-- OWL-представление (куда вошло отнюдь не всё, выразимое в изначальном EXPRESS-представлении).
7. Масштабируемость реализации крайне важна для действительно больших приложений типа САПРовских, где OIM могут быть весьма развесистыми. Поскольку iRING немасштабируем, то вполне осмысленно заниматься собственными вариантами реализации (видео и слайды доклада
avlasov на эту тему тут: http://community.livejournal.com/incose_ru/15696.html).8. Терминологии для мегамодели нет, и у присутствующих пока нет идей, как ее сделать. Затруднения вызывает даже термин для диаграммы/модели/семантической сетки и т.д., порождаемой какой-то OIM или совокупностью OIM, нарисованных друг на друге (отмеченное Онно Паапом "кодирование OIM более высокого уровня в терминах OIM менее высокого уровня")...