dot15926 и praxos. Эти проекты существенно продвинулись, и самое время навести на них суровую "критику справа" (ибо левой критики, как всегда, и так предостаточно):1. Для PraxOS совершенно недостаточно опираться на "просто системный подход". Нужен "система-системный подход", который по факту находится в зачаточном состоянии. Мы же пока еще и с "просто системами" не разобрались, увы -- чем и порождаем обильный поток традиционной критики "социальной инженерии". Именно тут разница между systems of systems evolution (что запросто привязывается к "службе развития") и простой organizational development/engineering (что сводится к простой функции "организовывания").
2. Опять же, в PraxOS "организовывание в малом" (внутри фирмы, внутри единоначалия -- если оно может тут в принципе существовать) и "организовывание в большом" (расширенное предприятие, обеспечение модульности) пока не разведены явно, средства этого не описаны.
3. Во всех занятиях инженерным проектированием я не уделяю должного внимания уровню абстракции в методе и созданию соответствующего языка. В частности, мне нужно было бы сосредоточиться на проектах типа DARPA iFAB+META+FANG (ссылки в http://ailev.livejournal.com/859527.html и там еще в комментах), где ускорение времени разработки обещано в пять раз. Оно понятно, что мы занимаемся enabling technologies для этого, но собственно сами технологии проектирования чего бы то ни было у нас пропущены напрочь (наши потуги охватить DSM -- это как-то несерьезно по сравнению с обсуждаемыми DARPA подходами). Отсутствие клиентов на такие разработки объясняет, но не оправдывает наше невнимание.
4. Мы настолько далеко ушли вниз по стеку технологий, что это становится тревожным.
-- традиционно мы (TechInvestlab) организаторы организаторов. Наш традиционный клиент -- директор по развитию, или всё правление, когда оно озабочено развитием, а не просто воспроизводством (что бывает редко).
-- мы занимаемся методами, ибо освоение организацией все новых и новых методов работы (обычно все более и более автоматизированных и компьютеризированных) -- это и есть современное корпоративное развитие.
-- мы занимаемся корпоративным IT в силу того, что не бывает сегодня методов без поддержки IT.
-- мы занимаемся семантическими технологиями, потому что это и есть управление организационными знаниями. Без знаний IT -- груда железяк, ручка для секретарши.
Это я пересказал кратенько http://community.livejournal.com/praxos/11299.html
Действительно, организационные методы/технологии существенно зависят от того, как устроено предприятие (в том числе расширенное) в плане его производственных методов работы (например, как устроен инжиниринг крупных капитальных объектов в рамках расширенного предприятия), методы инжиниринга зависят от доступных айтишных средств (CAD/CAM/CAE/PLM/ERP/EAM/MDM/etc), доступные айтишные средства зависят от применяемых в них платформ (реляционные, объектные или семантические хранилища, SOA, языки и т.д.). Мы, обнаружив тотальную неподдержку современных методов организации наличным корпоративным софтом, вдруг провалились не столько в создание этого софта, сколько в создание платформ для этого софта (ибо
dot15926 -- это именно платформа, на ней корпоративный софт еще придется писать!). Это все равно как встретить неудобства в написании Hello World на Java вдруг начать разрабатывать даже не новый язык и его компилятор с виртуальной машиной, и даже не ассемблер процессора, но сразу перейти к разработке микропрограмм -- и потом удивляться, что клиенты никак не понимают, что для Hello World обязательно нужны микропрограммы, всенепременно самые передовые в мире. Этот огромный разрыв крайне напрягает. Как заметил 
vvagr сегодня, на конференции по софту CAD/PLM (http://isicad.ru/ru/2010/program/eng/) никто этот ISO 15926 даже не помянул. Конечно, абсолютно аналогичные системы предыдущего объектного поколения в нынешнем engineering software интересны только с точки зрения программистов этих систем, но никак неинтересны пользователям, поэтому эволюция инженерного софта обсуждается не в терминах его обеспечивающих и инструментальных систем, а в терминах его функциональности как обеспечивающей системы для пользователей. Мы оказались крайне далеко по supply chain, и меня это несказанно тревожит.Более того, руки чешутся и тут пройтись на еще более низкий уровень (потому как на каждом технологическом уровне по supply chain этих технологий есть свои грабли). Например, пообсуждать грамматики как объекты первого класса (ибо у нас ведь тучи языков!), пообсуждать RESTful архитектуру (ибо на той же isicad-2010 четко говорилось, что инженерный софт будет развиваться в том же направлении, что и WWW -- а это ведь сейчас обеспечивается в значительной мере прогрессом в RESTful реализациях), пообсуждать архитектуры language workbenches, приложимость идей FONC (телескопы/микроскопы, те же грамматики и Ometa и т.д.), пообсуждать варианты оптимизации онтологий с их ограничениями для графа по сравнению с "тупыми триплами", где перебор может быть только полный -- куда ни ткнись, везеде важно, везде интересно, и каждый такой шаг "вниз" еще больше отдаляет от нужд "служб развития".
Эта размазанность вниз по technology/platform supply chain и напрягает сейчас больше всего.
5. Даже наш выбор ISO 15926 может быть прокритикован как недостаточно соответствующий заявленным на более высоких уровнях technology/platform supply chain целям, ибо:
5.1. Текущий заход в использовании онтологий в инженерном и корпоративном софте -- это всё про данные ("базы данных" еще одного типа), и непонятно как выйти на программирование. Мы понимаем, что "простые приложения -- это сложный код с простыми структурами данных, а сложные корпоративные приложения -- это простой код со сложными структурами данных", но сложный или простой код -- он должен быть! Если "объектные базы данных" хорошо совмещались с объектными языками и объектными платформами программирования, то с какими языками и платформами программирования должны совмещаться семантические базы данных? В комьюнити ISO 15926 никак не задаются этим вопросом, и меня это настораживает. Нужен 15926L, язык. Как может выглядеть такой язык, я себе не представляю -- но делать нужно именно его. Любая реализация ISO 15926 должна предоставлять интерфейс на этом языке, и это отнюдь не SPARQL, как предполагается Частью 9 стандарта.
5.2. ISO 15926 с его федерациями непонятно как обеспечивает модульность онтологии ("программирование-в-большом"). Несмотря на то, что RDL в федерации умеют обменяться сообщениями (хоть и это и "не объектный" и "не язык"), непонятно как обеспечивать целостность и непротиворечивость федерации, распределенную разработку и т.д. "Нюхом чую", что тут теоретическая засада.
5.3. Онтология (а хоть и 4D) предлагает "вечные классы". Это не соответствует принципам конструктивизма, в котором онтологии конструируются (то есть эволюционируют, а не "открываются" готовенькими и далее неизменными). Мне лично даже в языках программирования более симпатичны динамические языки. ISO 15926 никак не соответствует этим ожиданиям. Скажу страшную мысль: может, правильный подход -- это основанный на акторах и прототипах, а не на классах и индивидах. Онтологи наверняка этим занимались, но мне об этом неизвестно -- и это меня страшно напрягает. Эта тема протаскивается как проблема версионирования онтологии/моделей, но мне она кажется более фундаментальной -- проблематизируется собственно нынешняя архитектура "семантической работы".
5.4. Онтология ISO 15926 не вполне деятельностна и ориентирована на выражение метода (понятно, что исторически она была ориентирована на выражение только продукта), и нужно еще разобраться, как ее развернуть в этом деятельностном направлении. То же самое можно сказать о поддержке этой онтологией системного подхода (не говоря уже о системо-системном подходе). Понятно, что это всё выразимо текущими средствами ISO 15926, но мне кажется, что системный подход и деятельностный подход должны быть введены тщательно на уровне upper ontology (т.е. Части 2).