... ↑
__hedin в посте Openmeta (оригинал в ЖЖ)
правда софт конкретно для организации нажитого - это такая довольно жесткая штука.
то есть как например рисовать майндмэпы или там вписывать в таблички модели - это мы умеем. но "организация нажитого" - это уровнем повыше задача будет.
"в плане организации нажитого"
что есть такое "организация"?
нечто объектно-реляционное: набор объектов, и связей между ними? Опциалнально по связям еще их "веса".
Или как-нибудь по-другому?
"нажитого".
что такое "нажитое"? Как оно будет извлекаться?
То есть допустим если процедура извлечения - перепросмотр по ККДХ, то формат данных один (допустим, отрывки видеофильмов).
Если сразу паттерны (или претендующие на них системные образы) - то другой. Если образы-ассоциации - то третий.
Можно конечно заимплементить сразу всё, но тогда есть подозрение что сил и времени не хватит на такой детализованный разбор опыта (и разработку сложного ПО, кстати!).
"нет сил"
это кстати, как? ;) я недавно для себя моделировал/рушил это самое "нет сил"...
"смотреть на это бардак"
то есть нужно или переструктурировать визуальный образ, или уйти в другую репрезентативную систему.
Компьютеры сейчас хорошо работают только с визуальной, гораздо хуже с аудиалкой, а кинестетика только в плане передачи ее через визуалку и аудио (например, расстояние между иконками на рабочем столе - это кинестетика).
7 комментариев
сначала старые сначала новые
Как я понимаю, автор удаленного коммента понимал "организацию" как "архитектуру "(я недавно писал про определение "архитектуры" через "организацию" -- http://ailev.livejournal.com/612830.html, а также см. замечание http://community.livejournal.com/methodology_ru/130741.html?thread=1881269): вынос на уровень собственного осознания основных концептов "нажитого" и их связей. То есть для "организации" ему (ибо он визуален) нужно было бы увидеть картинку "нажитого" крупными блоками, причем с интеракциями между этими блоками (основная идея как "архитектуры", так и "организации" -- это интеракция).
"Нажитое" тут -- это, конечно, "отчужденная модель себя", чтобы над ней можно было бы поразмышлять, как это говорится в GTD ("Главное -- это выкинуть все из головы на какое-то медиа. Нет никакой нужды думать одну мысль дважды, если только вы не любите думать именно её. Сознание -- это экран, не память. Сознание показывает то, что находится в кратковременной, оперативной памяти. А в этой памяти находится все то, о чем вы беспокоитесь: мысли отвлекаются, а никакого прогресса не делается. Поэтому нужно выгрузить все из оперативной памяти вовне, и там это и организовывать -- в внешней памяти не будет никаких "мелькающих мыслей", чистый текст", http://ailev.livejournal.com/384198.html).
Конечно, тут не имеется ввиду собственно переорганизация субъективного опыта -- а изучение его для того, чтобы понять, как и во что переорганизовывать. Тут, конечно, можно пойти по "помоги мне, бессознательное" пути, но бессознательное не слишком хорошо в вопросах целеполагания и упорядочивания. Оно в другом сильно: лошадь хорошо везет, но плохо знает, куда везти. Доверяться лошади в том, что тебя отвезут неслучайным образом, было бы неверно. Поэтому и предлагается путь через выгрузку модели "себя любимого"="нажитого" вовне, в какой-нибудь софт (ибо современный софт -- это аналог ручки и бумажки прошлого века. Доска и мел, скрижаль и долото).
Кстати, сама мысль о "личностной архитектуре", загруженной в софт наподобие Enterprise Architecture (с поддержкой разных view и их взаимосвязи) -- интересная мысль. Далее отсюда прямой проход к бэндлеровским "дизайнам" (альтернативное понятие "архитектуры" -- это ограничение в дизайн-принципах, при этом различение используемых моделей на конструктивные и функциональные и требование иметь в архитектуре обе -- про это в первой книжке из http://community.livejournal.com/openmeta/199621.html).
Понятно, что софтовые интерфейсы к этим моделям пока могут быть традиционными: графические и текстовые окошки с разными символьными репрезентациями моделей.
А насчет "нет сил": глаза боятся, руки делают ;)
"Нажитое" тут -- это, конечно, "отчужденная модель себя", чтобы над ней можно было бы поразмышлять, как это говорится в GTD ("Главное -- это выкинуть все из головы на какое-то медиа. Нет никакой нужды думать одну мысль дважды, если только вы не любите думать именно её. Сознание -- это экран, не память. Сознание показывает то, что находится в кратковременной, оперативной памяти. А в этой памяти находится все то, о чем вы беспокоитесь: мысли отвлекаются, а никакого прогресса не делается. Поэтому нужно выгрузить все из оперативной памяти вовне, и там это и организовывать -- в внешней памяти не будет никаких "мелькающих мыслей", чистый текст", http://ailev.livejournal.com/384198.html).
Конечно, тут не имеется ввиду собственно переорганизация субъективного опыта -- а изучение его для того, чтобы понять, как и во что переорганизовывать. Тут, конечно, можно пойти по "помоги мне, бессознательное" пути, но бессознательное не слишком хорошо в вопросах целеполагания и упорядочивания. Оно в другом сильно: лошадь хорошо везет, но плохо знает, куда везти. Доверяться лошади в том, что тебя отвезут неслучайным образом, было бы неверно. Поэтому и предлагается путь через выгрузку модели "себя любимого"="нажитого" вовне, в какой-нибудь софт (ибо современный софт -- это аналог ручки и бумажки прошлого века. Доска и мел, скрижаль и долото).
Кстати, сама мысль о "личностной архитектуре", загруженной в софт наподобие Enterprise Architecture (с поддержкой разных view и их взаимосвязи) -- интересная мысль. Далее отсюда прямой проход к бэндлеровским "дизайнам" (альтернативное понятие "архитектуры" -- это ограничение в дизайн-принципах, при этом различение используемых моделей на конструктивные и функциональные и требование иметь в архитектуре обе -- про это в первой книжке из http://community.livejournal.com/openmeta/199621.html).
Понятно, что софтовые интерфейсы к этим моделям пока могут быть традиционными: графические и текстовые окошки с разными символьными репрезентациями моделей.
А насчет "нет сил": глаза боятся, руки делают ;)
Глянув на дату исходного поста, я побил комментарии - и, наверное, зря.
Я, вообще-то, имел в виду софт, в котором в удобном и обозримом виде можно было бы прописать навыки, их зависимости друг от друга (см. мой коммент выше), и выбрать для любого набора навыков все, что он за собой тащит из зависимостей. НО. "Прописать навыки" не просто названиями, а как модели, пригодные для:
- инсталляции
- проверки - есть ли у человека такая модель.
с точки зрения поддержки софтом здесь много не сделаешь - но нужные поля ввести надо: внутренние критерии наличия, внешние критерии, алгоритм/стратегия, может, еще что-то...
С другой стороны - навыки должны организовываться в смысловые группы (к примеру, "изменение состояния", или "создание фокуса внимания"). Понятно, что такие группы могут пересекаться.
Это тот минимум, который пришел в голову сразу.
Кстати, в таком случае начиают происходить интересные вещи - если стратегия выписана не процессуально, как в НЛП, а по достигаемым целям - имеем сразу пучок различных вариантов - в которых стратегия одна, а методы достижения подцелей различны. Вот вам и "создание техник" нлп-мастерское...
То есть цель - создать софт поддержки репозитория - и как естественно вытекающее следствие - создания дистрибутива.
Дальше его, вероятно, можно будет расширить играми/упражнениями (в смысле - компьютерными) для установки навыков.
Я, вообще-то, имел в виду софт, в котором в удобном и обозримом виде можно было бы прописать навыки, их зависимости друг от друга (см. мой коммент выше), и выбрать для любого набора навыков все, что он за собой тащит из зависимостей. НО. "Прописать навыки" не просто названиями, а как модели, пригодные для:
- инсталляции
- проверки - есть ли у человека такая модель.
с точки зрения поддержки софтом здесь много не сделаешь - но нужные поля ввести надо: внутренние критерии наличия, внешние критерии, алгоритм/стратегия, может, еще что-то...
С другой стороны - навыки должны организовываться в смысловые группы (к примеру, "изменение состояния", или "создание фокуса внимания"). Понятно, что такие группы могут пересекаться.
Это тот минимум, который пришел в голову сразу.
Кстати, в таком случае начиают происходить интересные вещи - если стратегия выписана не процессуально, как в НЛП, а по достигаемым целям - имеем сразу пучок различных вариантов - в которых стратегия одна, а методы достижения подцелей различны. Вот вам и "создание техник" нлп-мастерское...
То есть цель - создать софт поддержки репозитория - и как естественно вытекающее следствие - создания дистрибутива.
Дальше его, вероятно, можно будет расширить играми/упражнениями (в смысле - компьютерными) для установки навыков.
А может, есть что-то такое? Задачка-то довольно распространенная, по идее - описать набор базовых блоков и то, как из них собирается что-то большее...
Т.е. "для себя" здесь вторично. первична - возможность коллективного наполнения этого репозитория.
Ну, я вас правильно понял. Только я использовал в своем комменте другие слова. Так, выписывание стратегии по достигаемым целям -- это как раз функциональное описание по Jan Dietz, а "процессуальное" -- конструктивное описание. И так далее: пройдитесь по рекомендованным мной ссылкам.
Софт при таком подходе сводится к обычному софту представления знаний. Я склоняюсь сейчас к использованию языка представления знаний Gellish, хотя специализированный софт для него (увы!) пока доступен только коммерческий. Впрочем, хранить знания на Gellish можно в электронных таблицах, или в базах данных -- там табличный формат представления данных. Опять же, пройдитесь по ссылкам ;)
Софт при таком подходе сводится к обычному софту представления знаний. Я склоняюсь сейчас к использованию языка представления знаний Gellish, хотя специализированный софт для него (увы!) пока доступен только коммерческий. Впрочем, хранить знания на Gellish можно в электронных таблицах, или в базах данных -- там табличный формат представления данных. Опять же, пройдитесь по ссылкам ;)
Конечно, есть. Задача неоднократно встречалась при создании САПР, в которых нужно собрать что-то огромное (скажем, собрать виртуальную модель самолета из мельчайших винтиков, или нефтяной платформы из отдельных трубопроводов, или электростанции -- и совместить при этом знания электриков, материаловедов, бизнесменов, логистиков, проектировщиков, пользователей и т.д.).
Ага. Со всеми вытекающими задачами отслеживания рассогласований. Т.е. операциями commit и отслеживанием версий.
Другая формулировка для той же проблемы -- это "технологическая платформа" против "конкретного продукта". Технологическая платформа -- это все, что бывает. А в конкретный продукт (вариант) входит только то, что нужно и взаимосогласовано. И тут уже не только нужно управление версиями продукта, но и управление вариантами (продуктами) в рамках технологической платформы.
В репозитории (сосуде, СУБД), вестимо, бултыхаются и технологическая платформа, и конкретные продукты (содержание, знание).
Я тут писал для этого случая привязку к концепции жизненных циклов: http://ailev.livejournal.com/626229.html. Только слова подставьте про НЛП, ЭГ и т.д.
Другая формулировка для той же проблемы -- это "технологическая платформа" против "конкретного продукта". Технологическая платформа -- это все, что бывает. А в конкретный продукт (вариант) входит только то, что нужно и взаимосогласовано. И тут уже не только нужно управление версиями продукта, но и управление вариантами (продуктами) в рамках технологической платформы.
В репозитории (сосуде, СУБД), вестимо, бултыхаются и технологическая платформа, и конкретные продукты (содержание, знание).
Я тут писал для этого случая привязку к концепции жизненных циклов: http://ailev.livejournal.com/626229.html. Только слова подставьте про НЛП, ЭГ и т.д.