Обсуждение

Анатолий, еще одну вещь забывают в классификаторах и НСИ. Поскольку это по сути атрибуты процесса, важное его свойство - изменчивость. Почти любые внутренние и внешние (в т.ч. дико экзогенные которые невозможно предугадать) могут потребовать перестройки процесса и его параметров. И если разработчик тупо не вставил в сущности механизмы версионности, изменчивости, хронологии, в т.ч. и многофазное акцептование и наоборот, "откат" на прежние значения - то система получается бетонной. Говоря языком математики - текущее значение справочников и НСИ можно считать производной, экстремумом функции более высокого порядка, имеющей большее число размерностей. Т.е. текущие значения - это просто некий мгновенный фазовый срез более сложной функции, до которой нужно добираться интегралами p.s. похожая история сейчас возникла у Ростелекома в электронном правительстве. С таким трудом написанные (естественно не в машиночитаемом виде - а в Word/Excel) процессы госуслуг устаревают - а то что их нужно пересогласовывать, и это тоже процесс - не подумали. Заказчики саботируют - отговарияваясь что больше на амбразуру они не полезут, ИТ системы не могут обслуживать "старые" и "новые" процессы хотя бы для design-time отладки, и даже непонятно - как увидеть дифференциальную картинку между старым и новым - не читая заново многотомные описания...

А вы разве не обратили внимание на то, сколько раз я написал "управление конфигурацией и управление изменениями"? Например: "Это не просто нарезка знания на содержательные куски, удобные для коммуникации и учёт этих знаниевых конфигурационных единиц и их изменений, как материальную систему нарезают на конфигурационные единицы и затем ведут их учёт". Опять же, в инженерии знаний/онтологической инженерии регулярно говорят об эволюции онтологий, belief revision и т.д.. В справочных данных есть понятие stewardship (ведение). Что же касается изменения самой практики управления операциями -- так я привёл ссылку с полной типологией деятельности предпринятия в самом начале текста (http://praxos.livejournal.com/14905.html), и там я выделяю деятельность по организационно-техническому развитию, в том числе организационно-техническому развитию операционного управления, в том числе управления знаниями/данными.

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

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

Вот. Я одного понять не могу \\научиться выстраивать информационный конвейер предпринятия-киборга, самого состоящего из имеющих разные компетенции и по-разному загруженных работой киборгов-выполнителей так же, как сначала Форд, а затем люди в Toyota научились выстраивать свой автомобильный конвейер. Это -- максима? Или вы допускаете\интересуетесь возможностью (необходимостью?) какого-то кардинально нового подхода и соответственно непривычно нового решения (естетсвенно не потому что "новое -- значит лучше", а потому что работающее, позволяющее обойти и решить те и такие проблемы, которые ни за что не решались и были оставлены "на потом" или вообще признаны нерешаемыми (или как вариант -- давно решеными))?

Анатолий Игоревич, Вы пользуетесь понятием "управление знаниями" (УЗ). Насколько мне известно, любая Система Управления (СУ) оперирует конкретными физическими (материальными) Объектами, которые, собственно, и являются Элементами (или Органами, если они наделены функциями). Однако, все известные нам "Знания" находятся исключительно в черепушках людей и пока ещё не материализованы, чтобы могли быть управляемы машинами. Поэтому, на мой взгляд, прежде чем решать задачу УЗ, необходимо создать "Знания" в физическом (или цифровом) виде. Наша группа iknowww.ru занимается, как раз, данной проблематикой.

Вы пользуетесь совсем другим понятием "управления" (а именно, кибернетическим -- control). У меня же это management, более того -- операционное управление, operation management. Есть много постингов, в которых я прописывал это различие. Насчёт "знаний в черепушках людей" -- это да, knowledge management главным образом про это. Но уже knowledge engineering -- это как раз про формализацию знаний, и мы активно этим занимаемся. Обратите внимание на первый абзац пункта 2, там как раз предлагается некоторое разбиение по степени формализации, чтобы не ограничиваться "знаниями под черепушкой". Но мы предпочитаем эксплицированные и оцифрованные знания таковыми больше не называть, чтобы не путаться. Мы называем их справочными данными (данными, используемыми во многих проектах). "Оживляют" же эти справочные данные разные программы -- солверы, ризонеры, оптимизаторы и т.д.. Спасибо за ссылку на вашу страничку. Конечно, там использованная терминология для нас немного непривычна, а слов типа "сознание" мы так вообще боимся. Зато нам очень нравится слово "парсер", и мы бы его попробовали. Увы, пока он даёт ошибку: [SocketException (0x274d): No connection could be made because the target machine actively refused it [2001:0:5ef5:79fd:2426:344d:f5fe:fefa]:8310] System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress) +305 и далее много-много строчек текста. Надеюсь, когда парсер починят, мы его попробуем на фразах типа "Реактивное сопротивление генератора, а также его повышающего трансформатора должно быть таким низким, насколько это технически и экономически возможно для того, чтобы поддерживать стабильность системы и регулирование реактивной мощности".

Благодарю за уточнение по терминам "управления". Теперь всё намного понятнее и яснее. Фраза, которую Вы привели, даёт серьёзные затруднения абсолютно для всех Технологий АОТ, будь то с "онтологиями" или без, включая и такие, как Compreno. Однако, ТЭСОТ "Ontology", о которой я Вам говорил, легко справляется с анафорами и другими вариантами полисемии, поскольку технология использует Модели Образов и их Поведения (МПО), которые используются для восстановления исходной МЫСЛИ (мыслеформы) автора, заложенной в текстовом сообщении. Мы не вычисляем Парсер, как синтаксические (и постсемантические) отношения между словами, ТЭСОТ достаёт их из своей памяти, как готовые ответы на основе РАСПОЗНАВАНИЯ МПО. К сожалению, мы сегодня не отвечаем Вашему требованию ГОТОВНОСТИ технологии и потому, наверное, нет основания для обсуждения сотрудничества. Но, если у Вас возникнет интерес к нашим разработкам, даже в плане познавательном, то мы всегда готовы Вам всё показать и рассказать.

То, что вы рассказываете про свою технологию, очень похоже на опору на image schema и работу с базовым уровнем школы Lakoff (его книжка "Огонь, женщины и опасные вещи" широко известна, а работы по блендингу это развивают). У нас сейчас не реализованы эти подходы, они действительно весьма перспективны, мы это отслеживаем. Когда у вас будут готовы эти технологии, с удоволствием попробуем поработать с ними.

Добро! Удачи Вам.