Компактификация методического знания и сопутствующие гносеологические проблемы
1. Первоначально сформулированная задача PraxOS -- это дать компактное описание организационных практик, опирающихся на некоторый компактный набор мощных (контринтуитивных -- пункт 1 из http://ailev.livejournal.com/848622.html) идей. Это работа со знанием, гносеология чистой воды. Мы тут не столько отвечаем на вопрос "что есть в мире" (т.е. занимаемся онтологией), сколько пытаемся проделывать какие-то операции со знанием о методе -- добывать его, чистить, ужимать, осваивать, проверять истинность или хотя бы приемлемость и т.д.
2. Одним из методов продвижения PraxOS является опора в первую очередь на международные стандарты, которые выражают те или иные идеи (ISO 15288, ISO 15926, ISO 24744, ISO 15944 и т.д.) и прошли интенсивное коллективное обсуждение, и только во вторую очередь опора на великолепные методы, которые изложены в книгах авторов-одиночек (например, теория ограничений, LastPlanner или Beyond Budgeting) и поэтому выглядят как "публично не обсужденные", "без штампика". Эта ориентация на "стандартные методы" (в смысле "стандартных классов" из ISO 15926, классов, отмоделированных по содержанию стандартов) только позволяет "снимать сливки" с методологической работы, которая ведется в комитетах по стандартизации, но также и сократить объем объяснений начальству при получении его "одобрямса" на выделение ресурсов для освоения методов PraxOS в организационных проектах. А там лиха беда начала -- дойдём и до методов из книг.
3. Недавно мне удалось довольно точно сформулировать, какая принципиальная развилка маячит на линии прихвата лучших практик в постинге для нашего проекта dot15926 "онтологический мэппинг, онтологический рефакторинг и пространство концепций" (http://community.livejournal.com/dot15926/13941.html):
-- проделать рефакторинг для всех этих компонент методов, изложенных в стандартах, излагая собственное компактное содержание PraxOS, как это и было задумано. И немедленно столкнуться с трудностями формального принятия (ибо это будет явный отход от международных стандартов) результата.
-- пойти по пути "интеграции-через-мэппинг", привязывая все эти стандарты друг ко другу по мере их добавления -- и декларируя прямое соответствие стандартам при отсутствии какого-то собственного компактного содержания, кроме разве что "технически необходимых добавок к глобальному RDL, нужных только для мэппинга" (vvagr обозвал это "путь simantics", имея ввиду явное нежелание команды проекта Simantics разбираться с перепиской решателей на какой-то один язык, после чего роль проекта виделась только в объединении разных решателей в одну как-то работающую систему за счет качественно выполненного мэппинга данных для этих решателей).
4. Забавно, что это противопоставление можно прочесть с точностью до прямо противоположной терминологии как противопоставление паковщиков и картостроителей (packers and mappers) в знаменитом Программистском камне (http://m1.sm.bmstu.ru/Mirrors/progstone.nm.ru/reciprocality/r0/). Программисты из тусовки экстремальных программистов/разработчиков языков паттернов имели схожие концепции -- но называли их "коллекционер марок" и "моделедел". Часто также отмечалось, что в жизни мэпперам приходится не так сладко, как многим пэкерам -- хотя от мэпперов сплошная польза. Многие критики писали, что это разделение искусственно и вредно, и в проектной команде нужны обе деятельности -- возможно, в разные моменты времени, или в рамках разделения ролей в пределах команды.
По иронии судьбы, знаниевый рефакторинг-моделеделание в "Программистском камне" чисто лексически приписывается мэпперам, а собирательство-интеграция там именуются пэкерством (хотя для меня в этом термине слышится родство с "упаковкой", компактификацией). Мэпперство интеграторов данных оказывается странной деятельностью -- с одной стороны, это моделирование, и тем самым неизбежный поиск паттернов (как любит говорить Магне, "неявное делать явным") с другой стороны, последующее за моделированием интеграторство -- чистое коллекционирование, пэкерство, "путь simantics". Разделение оказывается искусственным, дело в общем рецепте, а не названиях.
Далее мы не будет пользоваться терминологией "программистского камня", только заметим, что "идея витает в воздухе".
5. Ежели рассматривать жизненный цикл человеческого знания, то наилучшей формулировкой, которую я нашел на настоящий день, является lerning by discovery, или Accretion Model of Theory Formation Дугласа Лената. Компактифицирование знания, его рефакторинг, изменение формы презентации являются существенными стадиями этого жизненного цикла (конечно, эти стадии пересекаются!). Переведу заново эту "модель прироста в формировании теорий" (http://eksl.isi.edu/files/library/Lenat-1983-theory-formation-by-heuristic-search-AIJ-heuristics.pdf, а более ранняя цитируемая там работа -- http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA096511&Location=U2&doc=GetTRDoc.pdf): 1. Когда дано немного новых (не полностью исследованных) определений, объектов, операций, правил и т.д., немедленно собери о них эмпирические данные: найди их примеры, попробуй их применить и т.д.
2. По мере того, как это продвигается, пробуй заметить в данных регулярности, паттерны и исключения для паттернов.
3. Из этих наблюдений сформируй новые и модифицируй старые гипотезы. В мире, который ты можешь как-то контролировать, спланируй и проведи эксперименты для проверки этих гипотез.
4. По мере того, как развивается набор догадок, экономизируй путем создания новых определений, которые укорачивают формулировки наиболее полезных догадок. Весь циклический процесс сейчас начнется заново с шага 1, на материале этих новых определений.
5. По мере прохождения цикла (шаги 1-4), становится необходимо время от времени обобщать некоторые новые специализированные эвристики, перерабатывая прошедший опыт обучаемого [тут нужно учесть, что Ленат описывает "обучение открытиями" -- lerning by discovery]
6. В еще более редких случаях будет необходимо дополнить или сдвинуть репрезентацию, в которой кодировано знание о предметной области.
7. Для всех шагов в этой модели, даже для шагов 5, 6 и 7, достаточно собирать и использовать набор эвристик, неформальных правил рассуждения, которые ведут исследователя к наиболее приемлемым альтернативам и уводят от наиболее неприемлемых.
В этом цикле непрерывно пухнущее и разбухающее знание регулярно компактифицируется, иногда со сменой репрезентаций. Старое знание в новом компактном может быть даже неузнаваемо -- не вся компактификация и рефакторинг сводятся к сокращениям длиннот путем их переобозначения трехбуквенными акронимами (http://en.wikipedia.org/wiki/Three-letter_acronym).
6. Это же рассуждение повторяется в эвристическом понимании инженерного метода (обобщаемого до понимания "метода вообще") Билли Коэном (http://www.me.utexas.edu/~koen/OUP/OUP.html), он даже вводит понятие state-of-the-art для обозначения текущего набора доступных на данный момент инженерам эвристик (темпоральной части корпуса человеческих эвристик). Правда, в этой книге компактификации набора эвристик не придается большого значения, а просто доказывается общеупотребимость основных черт описания жизненного цикла знаний о методе, как жизненного цикла корпуса эвристик.
7. Когда смотришь на движение языков паттернов, понимаешь, что они пытаются делать пункты 1-2 (то есть не доводят даже до новых гипотез, не говоря уже об экономизировании выражения). Это весьма и весьма продуктивно -- сформулированное знание уже можно передавать, ему можно учить. Именно так начали учить объектно-ориентированному программированию: учить использованию паттернов, под которыми никакой особой теории не было. Ни о какой компактификации тут тоже речи не шло. Поэтому тома "языков паттернов" получались пухлые, в них зачастую содержались прописные истины, "интуитивные идеи". Но шанс обнаружить контринтуитивную идею уже был!
8. Почему нужно иметь компактное представление знания? Алан Кей приводит пример: один том суперсложно (контринтуитивно) изложенного знания есть шанс одолеть одному человеку за всю свою жизнь. Десять тысяч томов не очень сложно (интуитивно) изложенного знания нет шанса одолеть -- даже просто прочесть уже нет шанса! Думать, писать, программировать, действовать нужно "высокоуровнево", в парадигме "одного тома" -- это означает иметь выразительные модели, "динамическую математику", как ее называет Алан Кей (http://ailev.livejournal.com/469995.html). Знание принципов освобождает от знания фактов.
9. Все вышеприведенные примеры по сути, представляют собой явный "паттерн", набор эвристик, описание одного и того же метода. Радикальным изменением, позволяющим надеяться на компактификацию, тут служит смена формы представления метода -- представление его в виде хорошо специфицированного набора формальных паттернов, "алгебраического типа" (и тут, конечно, снова встретится слово "паттерн"! http://en.wikipedia.org/wiki/Algebraic_data_type) для абстрактного синтаксиса метода, составленного в терминах компонент метода. Слитные описания методов разбиваются на повторноиспользуемые компоненты (виды рабочих продуктов, виды временнЫхЦиклов, видов единиц работы, видов акторов и т.д.) из относительно компактного множества которых может быть составлено огромное множество описаний отдельных методов "на все случаи жизни".
10. Тем самым мы говорим о синтаксических/структурных/паттерн-ориентированных описаниях метода, возможности в этих описаниях pattern matching -- запроса к множеству паттернов для вытаскивания из них релевантных и пертинентных данной ситуации, и регулярной компактификации этого множества компонент метода, компактификации каталога методов. В этой работе пока не до "оптимизации" метода, тут другой подход -- нужно научиться находить хотя бы удовлетворительный метод, и уже в этом будет счастье!
11. И тут вступают в силу внешние ограничения: компактифицированное (то есть выраженное в новой терминологии, а то и со сменой представления в совсем другой парадигме) множество компонент методов может быть компактным, выражать потенциально бОльшее число ситуационных методов и быть всяко лучше, чем текущий пушистый и развесистый в этом плане state-of-the-art. Одна книжка вместо ста других томов, но... люди требуют предъявления соответствия лучшим практикам еще до того, как что-то будет сделано, и наступит шанс показать превосходство результатов! Вам не дадут использовать стандарт PraxOS01, который будет представлять отрефакторенную и компактифицированную сумму ISO 42010 и ISO 24744, причем будет короче этой пары текстов. Вас будут проверять на compliance к этим двум стандартам, причем порознь!
12. Единственным выходом тут мне кажется следующий:
а) рефакторинг все равно делается, но при этом также делается мэппинг к остающимся стандартам
б) деятельность разворачивается согласно отрефакторенному, обучение деятельности -- по отрефакторенной версии
в) при проверке соответствия предъявляется мэппинг к старому знанию, даже если этот мэппинг выглядит уже нелепым (так, ежели проверяющие хотят всё видеть в римских числах, им показывают все в римских числах, хотя сами считают в арабских -- накладно по времени, но дешевле по нервам).
13. Тем самым выбора по развилке между "рефакторить" или "интегрировать" для PraxOS нет -- только "и". Иметь собственное компактное представление (в формате ISO 15926), и одновременно иметь мэппинг к понятиям оригинальных стандартов.
14. Это значит, что необходима более тонкая работа с моделированием стандартных классов:
-- классы PraxOS относятся к компонентам метода, определяемым в PraxOS. "Рассказы PraxOS" представляют собой знание в максимально компактифицированной форме.
-- тем не менее, все стандартные классы конкретного стандарта заводятся тоже, с пометкой их как онтолета данного стандарта (что трудно: определения используемых в каком-то стандарте терминов даются в совсем других стандартах, использование концепта затем может не совпадать с тем использованием, которое предполагалось при начальном определении, тексты стандартов меняются со временем и их совокупность становится противоречивой и т.д. -- всё то, что заставляет время от времени выпускать "своды законов", а не довольствоваться сборниками).
-- нужно уметь отождествить уже имеющиеся в компактифицированном каталоге (RDL) PraxOS классы со вновь заводимыми стандартными так, чтобы не потерять labels стандартных классов (они пригодятся, когда потребуется делать "вывод" в терминах оригинальных стандартов -- как минимум, предъявлять проверяющим мэппинг)
15. При освоении методов каталога PraxOS есть несколько преимуществ и недостатков:
-- преимуществом является то, что получающийся каталог компактен. Не нужно читать 100 томов по "организационной науке", достаточно прочесть парочку праксовских томов,
-- недостатком является то, что коммуникация учеников с окружающими читателями разных книг из текущих популярных 100 томов будет затруднена: будут использоваться другие слова, другие способы размышления.
-- поэтому придется по мере возникновения коммуникационных (в том числе -- с проверяющими всех мастей) трудностей учить и эти 100 томов тоже (хотя бы в их лексической части, как "иностранные слова" -- обеспечивая мэппинг к компактному знанию PraxOS)
Придется постоянно находиться между творящей Сциллой модерна очередной "теории всего" и релятивистской Харибдой растворения в изобилии постмодернистского цитирования результатов все более и более микроскопических проектов модерна. Конструктивизм хорош, но новое знание сдохнет без того, чтобы у него появился шанс быть воспринятым. Для этого его нужно отмэппить к "надёжным источникам".
16. Роль самого ISO 15926 в качестве онтологии для такого мэппинга пока неясна:
а) существующие правила предполагают внесения в RDL стандартных классов (то есть "классов из конкретного стандарта"), а не компактифицированного по итогам работы с совокупностью стандартов множества классов и отношений. Более того, приоритет отдается "интуитивным" понятиям, а не контринтуитивным -- для этого специально оговаривается, что значения оксфордского словаря перевешивают значения определений из стандартов. Хотя это довольно легко обходится, но нужно сразу быть готовым не столько править глобальный RDL, сколько возиться в собственной песочнице PraxOS.
б) четырехуровневая архитектура стандарта очень хороша для представления насосных агрегатов, для методов еще нужно понять сколько-там-уровневая архитектура (и это нужно делать срочно). Вполне возможно, что в стандарте эта архитектура не только никак не отражена, но и все нужные слова (labels) уже давно заняты под конкурирующие мейнстримные пушистые гроздья расхожих старинных организационных концептов.
в) описанные в данном постинге проблемы тонких различий похожих, но не идентичных наборов знаний (онтолетов) пока непонятно, как отражать в ISO 15926 -- все эти разборки с презентацией-репрезентацией информации и самоописываемостью в полный рост вдруг вырастают в проблему моделирования даталогии в форме computer science и software engineering (см. http://community.livejournal.com/dot15926/12746.html), помноженных на моделирование гносеологической составляющей -- представления именно знаний.
17. Начинать придется с методов представления методов, то есть ISO 42010+ISO24744+идеи жизненого цикла (4D) и четырехуровневой архитектуры метода. В итоге будут следующие рабочие продукты:
-- стандартные классы для ISO 24744 и ISO 42010, отмоделированные as is
-- часть нашей метамодели компонент метода (чьей "нашей" -- см. пункт 18)
-- возможные высокоуровневые добавки в RDL/WIP (вплоть до предложений об изменении Части 2, невзирая на всю крамольность таких мыслей -- а что делать, если нам нужно не железки моделировать?!)
18. Тут непонятно, делать ли эти компоненты "метода работы с методами" о в рамках praxos, или в dot15926. С одной стороны, PraxOS занимается организационными методами, а тут "методологические методы", ежели можно о таковых говорить. С другой стороны праксеология как раз начинается с обсуждения того, что кто-то что-то делает -- и это прерогатива PraxOS. Это если мы идем по линии ISO 24744 и выходим сначала на языки-нотации в тамошней метамодели. C третьей стороны, развивать идеи групп описаний, презентации-репрезентации, языков и нотаций, DSL и прочих "архитектурных языков" нужно будет, если заходить со стороны ISO42010 и сопутствующей тематике "универсальных моделлеров", DSL и language workbenches -- это явно лучше делать в порядке обсуждения .15926 и его гносеологического/программистского/модельерского содержания.
Поэтому публикую пока у себя в ЖЖ (а желающие понять, о чем это -- идите в praxos и dot15926, начинайте там с профайлов этих сообществ, где даны кое-какие ссылки на литературу и другие сайты).
2. Одним из методов продвижения PraxOS является опора в первую очередь на международные стандарты, которые выражают те или иные идеи (ISO 15288, ISO 15926, ISO 24744, ISO 15944 и т.д.) и прошли интенсивное коллективное обсуждение, и только во вторую очередь опора на великолепные методы, которые изложены в книгах авторов-одиночек (например, теория ограничений, LastPlanner или Beyond Budgeting) и поэтому выглядят как "публично не обсужденные", "без штампика". Эта ориентация на "стандартные методы" (в смысле "стандартных классов" из ISO 15926, классов, отмоделированных по содержанию стандартов) только позволяет "снимать сливки" с методологической работы, которая ведется в комитетах по стандартизации, но также и сократить объем объяснений начальству при получении его "одобрямса" на выделение ресурсов для освоения методов PraxOS в организационных проектах. А там лиха беда начала -- дойдём и до методов из книг.
3. Недавно мне удалось довольно точно сформулировать, какая принципиальная развилка маячит на линии прихвата лучших практик в постинге для нашего проекта dot15926 "онтологический мэппинг, онтологический рефакторинг и пространство концепций" (http://community.livejournal.com/dot15926/13941.html):
-- проделать рефакторинг для всех этих компонент методов, изложенных в стандартах, излагая собственное компактное содержание PraxOS, как это и было задумано. И немедленно столкнуться с трудностями формального принятия (ибо это будет явный отход от международных стандартов) результата.
-- пойти по пути "интеграции-через-мэппинг", привязывая все эти стандарты друг ко другу по мере их добавления -- и декларируя прямое соответствие стандартам при отсутствии какого-то собственного компактного содержания, кроме разве что "технически необходимых добавок к глобальному RDL, нужных только для мэппинга" (vvagr обозвал это "путь simantics", имея ввиду явное нежелание команды проекта Simantics разбираться с перепиской решателей на какой-то один язык, после чего роль проекта виделась только в объединении разных решателей в одну как-то работающую систему за счет качественно выполненного мэппинга данных для этих решателей).
4. Забавно, что это противопоставление можно прочесть с точностью до прямо противоположной терминологии как противопоставление паковщиков и картостроителей (packers and mappers) в знаменитом Программистском камне (http://m1.sm.bmstu.ru/Mirrors/progstone.nm.ru/reciprocality/r0/). Программисты из тусовки экстремальных программистов/разработчиков языков паттернов имели схожие концепции -- но называли их "коллекционер марок" и "моделедел". Часто также отмечалось, что в жизни мэпперам приходится не так сладко, как многим пэкерам -- хотя от мэпперов сплошная польза. Многие критики писали, что это разделение искусственно и вредно, и в проектной команде нужны обе деятельности -- возможно, в разные моменты времени, или в рамках разделения ролей в пределах команды.
По иронии судьбы, знаниевый рефакторинг-моделеделание в "Программистском камне" чисто лексически приписывается мэпперам, а собирательство-интеграция там именуются пэкерством (хотя для меня в этом термине слышится родство с "упаковкой", компактификацией). Мэпперство интеграторов данных оказывается странной деятельностью -- с одной стороны, это моделирование, и тем самым неизбежный поиск паттернов (как любит говорить Магне, "неявное делать явным") с другой стороны, последующее за моделированием интеграторство -- чистое коллекционирование, пэкерство, "путь simantics". Разделение оказывается искусственным, дело в общем рецепте, а не названиях.
Далее мы не будет пользоваться терминологией "программистского камня", только заметим, что "идея витает в воздухе".
5. Ежели рассматривать жизненный цикл человеческого знания, то наилучшей формулировкой, которую я нашел на настоящий день, является lerning by discovery, или Accretion Model of Theory Formation Дугласа Лената. Компактифицирование знания, его рефакторинг, изменение формы презентации являются существенными стадиями этого жизненного цикла (конечно, эти стадии пересекаются!). Переведу заново эту "модель прироста в формировании теорий" (http://eksl.isi.edu/files/library/Lenat-1983-theory-formation-by-heuristic-search-AIJ-heuristics.pdf, а более ранняя цитируемая там работа -- http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA096511&Location=U2&doc=GetTRDoc.pdf): 1. Когда дано немного новых (не полностью исследованных) определений, объектов, операций, правил и т.д., немедленно собери о них эмпирические данные: найди их примеры, попробуй их применить и т.д.
2. По мере того, как это продвигается, пробуй заметить в данных регулярности, паттерны и исключения для паттернов.
3. Из этих наблюдений сформируй новые и модифицируй старые гипотезы. В мире, который ты можешь как-то контролировать, спланируй и проведи эксперименты для проверки этих гипотез.
4. По мере того, как развивается набор догадок, экономизируй путем создания новых определений, которые укорачивают формулировки наиболее полезных догадок. Весь циклический процесс сейчас начнется заново с шага 1, на материале этих новых определений.
5. По мере прохождения цикла (шаги 1-4), становится необходимо время от времени обобщать некоторые новые специализированные эвристики, перерабатывая прошедший опыт обучаемого [тут нужно учесть, что Ленат описывает "обучение открытиями" -- lerning by discovery]
6. В еще более редких случаях будет необходимо дополнить или сдвинуть репрезентацию, в которой кодировано знание о предметной области.
7. Для всех шагов в этой модели, даже для шагов 5, 6 и 7, достаточно собирать и использовать набор эвристик, неформальных правил рассуждения, которые ведут исследователя к наиболее приемлемым альтернативам и уводят от наиболее неприемлемых.
В этом цикле непрерывно пухнущее и разбухающее знание регулярно компактифицируется, иногда со сменой репрезентаций. Старое знание в новом компактном может быть даже неузнаваемо -- не вся компактификация и рефакторинг сводятся к сокращениям длиннот путем их переобозначения трехбуквенными акронимами (http://en.wikipedia.org/wiki/Three-letter_acronym).
6. Это же рассуждение повторяется в эвристическом понимании инженерного метода (обобщаемого до понимания "метода вообще") Билли Коэном (http://www.me.utexas.edu/~koen/OUP/OUP.html), он даже вводит понятие state-of-the-art для обозначения текущего набора доступных на данный момент инженерам эвристик (темпоральной части корпуса человеческих эвристик). Правда, в этой книге компактификации набора эвристик не придается большого значения, а просто доказывается общеупотребимость основных черт описания жизненного цикла знаний о методе, как жизненного цикла корпуса эвристик.
7. Когда смотришь на движение языков паттернов, понимаешь, что они пытаются делать пункты 1-2 (то есть не доводят даже до новых гипотез, не говоря уже об экономизировании выражения). Это весьма и весьма продуктивно -- сформулированное знание уже можно передавать, ему можно учить. Именно так начали учить объектно-ориентированному программированию: учить использованию паттернов, под которыми никакой особой теории не было. Ни о какой компактификации тут тоже речи не шло. Поэтому тома "языков паттернов" получались пухлые, в них зачастую содержались прописные истины, "интуитивные идеи". Но шанс обнаружить контринтуитивную идею уже был!
8. Почему нужно иметь компактное представление знания? Алан Кей приводит пример: один том суперсложно (контринтуитивно) изложенного знания есть шанс одолеть одному человеку за всю свою жизнь. Десять тысяч томов не очень сложно (интуитивно) изложенного знания нет шанса одолеть -- даже просто прочесть уже нет шанса! Думать, писать, программировать, действовать нужно "высокоуровнево", в парадигме "одного тома" -- это означает иметь выразительные модели, "динамическую математику", как ее называет Алан Кей (http://ailev.livejournal.com/469995.html). Знание принципов освобождает от знания фактов.
9. Все вышеприведенные примеры по сути, представляют собой явный "паттерн", набор эвристик, описание одного и того же метода. Радикальным изменением, позволяющим надеяться на компактификацию, тут служит смена формы представления метода -- представление его в виде хорошо специфицированного набора формальных паттернов, "алгебраического типа" (и тут, конечно, снова встретится слово "паттерн"! http://en.wikipedia.org/wiki/Algebraic_data_type) для абстрактного синтаксиса метода, составленного в терминах компонент метода. Слитные описания методов разбиваются на повторноиспользуемые компоненты (виды рабочих продуктов, виды временнЫхЦиклов, видов единиц работы, видов акторов и т.д.) из относительно компактного множества которых может быть составлено огромное множество описаний отдельных методов "на все случаи жизни".
10. Тем самым мы говорим о синтаксических/структурных/паттерн-ориентированных описаниях метода, возможности в этих описаниях pattern matching -- запроса к множеству паттернов для вытаскивания из них релевантных и пертинентных данной ситуации, и регулярной компактификации этого множества компонент метода, компактификации каталога методов. В этой работе пока не до "оптимизации" метода, тут другой подход -- нужно научиться находить хотя бы удовлетворительный метод, и уже в этом будет счастье!
11. И тут вступают в силу внешние ограничения: компактифицированное (то есть выраженное в новой терминологии, а то и со сменой представления в совсем другой парадигме) множество компонент методов может быть компактным, выражать потенциально бОльшее число ситуационных методов и быть всяко лучше, чем текущий пушистый и развесистый в этом плане state-of-the-art. Одна книжка вместо ста других томов, но... люди требуют предъявления соответствия лучшим практикам еще до того, как что-то будет сделано, и наступит шанс показать превосходство результатов! Вам не дадут использовать стандарт PraxOS01, который будет представлять отрефакторенную и компактифицированную сумму ISO 42010 и ISO 24744, причем будет короче этой пары текстов. Вас будут проверять на compliance к этим двум стандартам, причем порознь!
12. Единственным выходом тут мне кажется следующий:
а) рефакторинг все равно делается, но при этом также делается мэппинг к остающимся стандартам
б) деятельность разворачивается согласно отрефакторенному, обучение деятельности -- по отрефакторенной версии
в) при проверке соответствия предъявляется мэппинг к старому знанию, даже если этот мэппинг выглядит уже нелепым (так, ежели проверяющие хотят всё видеть в римских числах, им показывают все в римских числах, хотя сами считают в арабских -- накладно по времени, но дешевле по нервам).
13. Тем самым выбора по развилке между "рефакторить" или "интегрировать" для PraxOS нет -- только "и". Иметь собственное компактное представление (в формате ISO 15926), и одновременно иметь мэппинг к понятиям оригинальных стандартов.
14. Это значит, что необходима более тонкая работа с моделированием стандартных классов:
-- классы PraxOS относятся к компонентам метода, определяемым в PraxOS. "Рассказы PraxOS" представляют собой знание в максимально компактифицированной форме.
-- тем не менее, все стандартные классы конкретного стандарта заводятся тоже, с пометкой их как онтолета данного стандарта (что трудно: определения используемых в каком-то стандарте терминов даются в совсем других стандартах, использование концепта затем может не совпадать с тем использованием, которое предполагалось при начальном определении, тексты стандартов меняются со временем и их совокупность становится противоречивой и т.д. -- всё то, что заставляет время от времени выпускать "своды законов", а не довольствоваться сборниками).
-- нужно уметь отождествить уже имеющиеся в компактифицированном каталоге (RDL) PraxOS классы со вновь заводимыми стандартными так, чтобы не потерять labels стандартных классов (они пригодятся, когда потребуется делать "вывод" в терминах оригинальных стандартов -- как минимум, предъявлять проверяющим мэппинг)
15. При освоении методов каталога PraxOS есть несколько преимуществ и недостатков:
-- преимуществом является то, что получающийся каталог компактен. Не нужно читать 100 томов по "организационной науке", достаточно прочесть парочку праксовских томов,
-- недостатком является то, что коммуникация учеников с окружающими читателями разных книг из текущих популярных 100 томов будет затруднена: будут использоваться другие слова, другие способы размышления.
-- поэтому придется по мере возникновения коммуникационных (в том числе -- с проверяющими всех мастей) трудностей учить и эти 100 томов тоже (хотя бы в их лексической части, как "иностранные слова" -- обеспечивая мэппинг к компактному знанию PraxOS)
Придется постоянно находиться между творящей Сциллой модерна очередной "теории всего" и релятивистской Харибдой растворения в изобилии постмодернистского цитирования результатов все более и более микроскопических проектов модерна. Конструктивизм хорош, но новое знание сдохнет без того, чтобы у него появился шанс быть воспринятым. Для этого его нужно отмэппить к "надёжным источникам".
16. Роль самого ISO 15926 в качестве онтологии для такого мэппинга пока неясна:
а) существующие правила предполагают внесения в RDL стандартных классов (то есть "классов из конкретного стандарта"), а не компактифицированного по итогам работы с совокупностью стандартов множества классов и отношений. Более того, приоритет отдается "интуитивным" понятиям, а не контринтуитивным -- для этого специально оговаривается, что значения оксфордского словаря перевешивают значения определений из стандартов. Хотя это довольно легко обходится, но нужно сразу быть готовым не столько править глобальный RDL, сколько возиться в собственной песочнице PraxOS.
б) четырехуровневая архитектура стандарта очень хороша для представления насосных агрегатов, для методов еще нужно понять сколько-там-уровневая архитектура (и это нужно делать срочно). Вполне возможно, что в стандарте эта архитектура не только никак не отражена, но и все нужные слова (labels) уже давно заняты под конкурирующие мейнстримные пушистые гроздья расхожих старинных организационных концептов.
в) описанные в данном постинге проблемы тонких различий похожих, но не идентичных наборов знаний (онтолетов) пока непонятно, как отражать в ISO 15926 -- все эти разборки с презентацией-репрезентацией информации и самоописываемостью в полный рост вдруг вырастают в проблему моделирования даталогии в форме computer science и software engineering (см. http://community.livejournal.com/dot15926/12746.html), помноженных на моделирование гносеологической составляющей -- представления именно знаний.
17. Начинать придется с методов представления методов, то есть ISO 42010+ISO24744+идеи жизненого цикла (4D) и четырехуровневой архитектуры метода. В итоге будут следующие рабочие продукты:
-- стандартные классы для ISO 24744 и ISO 42010, отмоделированные as is
-- часть нашей метамодели компонент метода (чьей "нашей" -- см. пункт 18)
-- возможные высокоуровневые добавки в RDL/WIP (вплоть до предложений об изменении Части 2, невзирая на всю крамольность таких мыслей -- а что делать, если нам нужно не железки моделировать?!)
18. Тут непонятно, делать ли эти компоненты "метода работы с методами" о в рамках praxos, или в dot15926. С одной стороны, PraxOS занимается организационными методами, а тут "методологические методы", ежели можно о таковых говорить. С другой стороны праксеология как раз начинается с обсуждения того, что кто-то что-то делает -- и это прерогатива PraxOS. Это если мы идем по линии ISO 24744 и выходим сначала на языки-нотации в тамошней метамодели. C третьей стороны, развивать идеи групп описаний, презентации-репрезентации, языков и нотаций, DSL и прочих "архитектурных языков" нужно будет, если заходить со стороны ISO42010 и сопутствующей тематике "универсальных моделлеров", DSL и language workbenches -- это явно лучше делать в порядке обсуждения .15926 и его гносеологического/программистского/модельерского содержания.
Поэтому публикую пока у себя в ЖЖ (а желающие понять, о чем это -- идите в praxos и dot15926, начинайте там с профайлов этих сообществ, где даны кое-какие ссылки на литературу и другие сайты).