...  ↑

Ну, мой пост как раз на эту тему: задает понятия, в которых возможны обсуждения этих способов.

И у нас было множество заходов на эту тему (например, про ДлинныеТехники и метанойи -- были попытки обсуждать их потребный список, сравнительные эффективности для того или сего. Говорилось про Курсы и Загрузчики, делалась попытка создать прообраз заведомо избыточного репозитория моделей -- http://community.livejournal.com/openmeta/164632.html). И были проблематизации как раз по поводу сборки дистрибутивов (например, http://community.livejournal.com/openmeta/164632.html).

С заданным мной разведением репозитория и дистрибутива можно возвращаться к этим темам много более конструктивно и обсуждать проблемы а) сборки разнозаточенных дистрибутивов, обсуждая вопросы их разнообразия и находя незанятые и нестандартные ниши -- типа как пикапщики юзают репозиторий НЛП, сделав свой вторичный репозиторий и создав несколько разных весьма специфических дистрибутивов; б) разницу между авторами моделей, сборщиками и пользователями (а не только авторами и пользователями. Впрочем, мы уже сделали заход на эту тему, когда ввели троицу Алисы, Боба и Чарли, но опять-таки это "получилось по факту", но не было достаточно отрефлектировано. Скажем, в ОпенМете взаимодействие между этими ролями не было отыграно -- Алисы и Бобы чем-то таким занимались вокруг репозиториев, а "дистрибутив как путь к пользователю" не складывался, что оставило огромное количество Чарли-зевак без ожидаемого удовлетворения); в) рассматривать технологии сборки более-менее полных дистрибутивов, а не обрывочно-дырявых (как минимум для этого задав понятие ядра). Это очень большой пласт тем.

Я бы чуть расширил метафору.

То, что мы имеем в НЛП, ЭГ и прочем - это скорее некий исходный код, разбросанный на просторах неведомо чего - со своими (хитрыми) правилами и инструментами сборки, специфическими (и явно не прописанными) зависимостями, требованиями к платформе и так далее.

Здесь первым шагом было бы как раз построение репозитория - систематизированного хранилища, в котором содержимое заведомо может быть использовано при соблюдении ряда явно описанных критериев.

Вот тогда можно будет сказать, что входит в ядро (на основе зависимостей), и планка требований к дистрибутиво строителям опустится до терпимого уровня...

Сейчас этого репозитрия и близко нет - даже для арсенала НЛП, являющегося самым структурированным из всех подобных проектов, не прописаны зависимости навыков друг от друга, не прописаны критерии существования навыков, нет внятных методик обучения. Кое-что из дыр с критериями и методиками закрыто в Опенмете, кое-что - вероятно, в Метапрактике. А толку - найдут их там опять несколько авторов, которым они, собственно, и не слишком нужны. Какие уж тут дистрибутивы...

Соглашусь.

Только вот с "зависимостями" тут трудно -- я бы их называл "совместимостями". Это ведь все-таки не "фреймворки" или "библиотеки" (в смысле "того, откуда пользовательский код вызывается" и "того, что вызывается пользовательским кодом").

Правильно тут было бы (о чем я все время писал) провести работу по мэппингу разных понятий разных кусков кода, которые были наработаны во всех психотехнических направлениях. Я тут все время писал про онтологическую работу, но никак не мог понять, как это можно было бы сделать технологически. Вот только сейчас примерно понял (см., например, http://ailev.livejournal.com/627019.html пункт 2 -- об использовании Gellish и его метода моделирования предметной области для стыковки понятий разных дисциплин). Это и будет аналогом "прописывания взаимозависимостей", только взятой не из наработок по "исполняемому коду", а из наработок по интегрированию промышленных данных (ISO 15926 и Gellish).

Именно зависимости. Возьмем, к примеру, навык "установка якоря". Если грубо, он зависит от:
- навыка "создание фокуса внимания" - вероятно, бессознательного
- навыка "калибровка изменений в физиологии"
- навыка "выбор нужного состояния"
- навыка "калибровка пика состояния" (зависящего от "калибровки изменений".
- навыка "выбор сигнала, который станет якорем"

Из этого в НЛП, к примеру, осознается как отдельный навык только "калибровка изменений".
И с этой точки зрения - это именно библиотеки вызываемого кода - для обучения установке якоря все навыки, от которых он зависит, должны уже быть установлены как автоматические стратегии, именно "вызываемые" в нужный момент.

А что такое "зависит"? Если нет навыка по цепочке зависимостей, то навыка не может быть?

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

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

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

Сам же конструируемый навык, насколько я понимаю, должен быть описан именно конструктивно, это некий алгоритм.

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

А до ссылочек не доберусь никак - может, сначала их осилить, как думаете?

Если конструируемый навык описан как алгоритм, то он вызывает навыки-функции? Вам придется тогда сказать, что любой "навык состоит из навыков" ("цепь состоит из цепи"), а это не слишком конструктивно. Нужны какие-то базовые кирпичики, конструктивы, из которых состоят навыки. Так, описание алгоритма состоит из операторов, выражений и т.д. С другой стороны, описанный подробненько алгоритм имеет цель -- это его функция. Цепочка "взаимозависимостей" тем самым оказывается не функциональной, а конструктивной. Когда вы вызываете какую-то процедуру, то пишете ее вызов с параметрами (конструктив) и объясняете (в комментах, ибо это не конструктивно, а функционально) зачем вызывали.

Тут еще важно заметить, что с простым объектным программированием это все может быть несравнимо. Какое-нибудь аспектное программирование лучше подойдет: описываются навыки-аспекты, а при исполнении происходит weaving (где сам черт не разберет, как соединяются два навыка -- там же параллельное исполнение нескольких навыков в конечном итоге, а не последовательный "вызов" одного из другого!).

Ссылки, конечно, осилить. Разговор станет много точнее. Ибо от вас требуется онтология (например, определить понятие "зависимость" через связи с другими понятиями. Определить, какого типа связь между навыками и зависимостями навыков -- ведь навыки не только из зависимостей состоят (у вас же "зависимости" не макросы?), но и из чего другого? Какого типа связь между навыками, как она исполняется?).

не знаю в тему ли - а если в тему то в какую но я вот разрабатываю такую прикладную табличку :

Примитивы связанные с состоянием или проблемой
Состояние
описание в свободной форме
Пассивность-вовлеченность
Зона комфорта
Проблема-препятствие
Цель – рационале
Диагностич алгоритм
Пререквизиты по технике
Техника
Действия по технике
физизиология
мои кейсы
отдача\противопоказания
Дидактический материал
Методика тренинга
Алгоритмы нормализации
Тулзы
Визуализация
Документы
Специалисты

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

Сделайте следующее: для каждой строчки из списка укажите, какого она типа объект. Типа "пассивность -- вовлеченность" : шкала. Далее будут естественные вопросы типа "а чего это шкала?". Ну, или "диагностический алгоритм" : последовательность действий. Техника: последовательность действий. Далее вопросы типа "диагностический алгоритм -- это такая техники?".

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

Можно ожидать, что у вас появятся вопросы к вашему списку, и итогом работы будет уже список немного других объектов, причём эти объекты будут типизированы и читателям этого списка станет про эти объекты понятней.

Упс пропустил я этот камент, а за это время табличка выросла до 40 полей и 130 записей... Из мета-описания Я почему-то ломанулся составлять таблицу типов связей полей, а сами типы полей не пришло в голову сравнивать. Теперь буду соображать.

Упс пропустил я этот камент, а за это время табличка выросла до 40 полей и 130 записей... Из мета-описания Я почему-то ломанулся составлять таблицу типов связей полей, а сами типы полей не пришло в голову сравнивать. Теперь буду соображать.

Я полагаю мне нужны вот такой велосипед,

"Что" определяемое через "как", или как связаны цели и предметная область.

Разработка
Гипотезы
Критерии проверки
Методики проверки
Инструменты
Ресурсы разработки

Внедрение
Методики обучения
Методические материалы

Эксплуатация
0) Ценности, принципы и миссия ч/з Этапы
1) Этапы ч/з цели
2) Цели, достижимые в определенных состояниях, через параметры свойств состояний.
3) Проблемы и задачи через функции и роли
4) Функции и роли которые нужно исполнять в контекстах, через

инструменты(дистрибутивы техник), ресурсы, права доступа,
5) Дистрибутивы техник, через набор техник.
соответствующих TCO, Пассивность/вовлеченность
6) Техники, работающие с диапазонами подмножеств объектов, свойств и методов начального состояния и приводящих к диапазону конечных состояний объектов, их

свойств и методов
7) Состояния объектов предметной области -через диапазоны параметров их свойств и

методов, выраженные в шкалах
8) Объекты предметной области - через их свойства и методы

Другой вариант
1) Компетенции
2) Исполняющие функции и роли
3) И используя дистрибуты
4) Техник
5) Работающих по изменяющим алгоритмам (загрузчик, тело алгоритма)
6) Инструментами
7) с внешними ресурсами (информация, время, деньги, человеки с компетенциями),
7) В контекстах (проектов и внешней среды)
8) Достигают целей (SMART параметры)
9) Решая задачи и преодолевая проблемы (зоны комфорта, диагностические алгоритмы)
10) Изменяя состояния (Гран условия, зоны комфорта)
11) Объектов психики
12) их методов, свойств, вовлекаемых и освобождаемых инкапсулированных ресурсов психики)

Для каждого этапа

Документация содержащая
текстовые описания, рисунки и диаграммы, шкалы, списки граничных условий, чеклисты проверки, списки наблюдаемого, аналитика работы)

А поглядите на http://semat.org/wp-content/uploads/2012/02/2012-11-01.pdf как пример стандарта для подобных описаний и попробуйте разработать kernel для этой спечифической ситуации (когда нет команды, а объекты и практики весьма специфичны) в инструменте http://www.ivarjacobson.com/Practice_Workbench_Download/ (с getting started для SEMAT users).

Это в разы облегчит разбирательство с "мета" (описание практик как таковых) и позволит сосредоточиться на содержании этих практик, т.е. на моделировании.

проще говоря почему и зачем, кто, делает что, когда, как, каким, чем, за сколько

Где почему, зачем, что, как, каким, чем относится к системе объектов и состояний предметной области

Спасибо, на первый взгляд выглядит весьма релевантно. По первому впечатлению мне начинать 2012-11-01.pdf (KUALI-BEH kernal extension) со страницы 182, правильно я понял ? Это чтобы начинать не с ядра а с его применения.

Нет, вам бы всё это прочесть, чтобы понять -- а потом сделать сущности (kernel) для ОпенМеты. Ибо они будут другие, нежели чем для программной инженерии. На базе этих сущностей можно потом описать практики (репозиторий в терминах комментируемого поста), и далее описывать метод (дистрибутив в терминах комментируемого поста).

Попробуйте поглядеть презентацию http://semat.org/wp-content/uploads/2012/12/Universals_Track_Intro_Stockholm.pdf (там показан как раз путь, которым разработчики essence дошли до своего ядра, плюс применения этого ядра -- вот нам нужно для ОпенМета такое сделать).

Я сейчас как раз с этим подробно разбираюсь, через некоторое время начну предлагать терминологию на русском, но пока это будет для программной инженерии и попытки думать, каким может быть ядро для других domains (системная инженерия прежде всего, операционный менеджмент следующий). Методы ОпенМеты это как раз новый дисциплинарный домен для essence, т.е. требует разработки для него новых сущностей (kernel) на базе предложенного языка (language).