Место .15926 -- кто наши конкуренты?
Пройден важный milestone в проекте: в общих черта стали понятны черты .15926L -- теперь у нас есть "теории 15926" (семантическая сетка, данные в трипл-сторе) и "алгоритмы 15926" (тексты на Питоне, использующие специальные конструкты builder и scanner -- тот самый .15926L, о природе которого мы тут долго пытались рассуждать). Дальше можно переходить к знаменитому "программы -- это алгоритмы плюс данные", и продолжать рассуждать об онтологическом, языко-ориентированном и прочем продвинутом программировании. Это было исследовательской целью проекта, и очень радостно осознавать существенное продвижение к этой цели. Другое дело, что большой кусок языка (scanner) еще только в замыслах -- а ведь "семантический поиск" и использование ISO 15926 inside как раз завязаны на нём.
Теперь нужно разобраться (в очередной раз!), в каком направлении мы двигаем технологию. На сегодняшний день .15926 я рассматриваю в ряду:
IRING, XMpLant, ...., .15926, ..., VivoMind, CYC.
Мы точно должны быть более богаты в плане использования алгоритмов онтологической работы по сравнению с системами поддержки мэппинга/передачи разнородных данных (то есть мы поддерживаем outside, но целимся в inside), но на сегодняшний момент мы даже в наших мечтах явно менее богаты в алгоритмике по сравнению со знаниевыми системами.
Ключевым тут является обнаружение проблемы, которую можно было бы решать при помощи онтологического программирования. Далее -- разработка методики решения этой задачи (ибо проблема -- когда не знаешь, как решать, переводится путём использования онтологического программирования в задачу, которую знаешь как решать, и в этом вся фишка!). Далее -- поддержка методики софтом.
Выбор решаемой проблемы крайне важен (см. http://ailev.livejournal.com/936771.html).
Пока же решаются не столько проблемы (с неизвестным пока решением), сколько задачи (которые уже решаются при помощи IRING и XMpLant, и именно эти системы сейчас являются "конкурентами по факту"). Это прежде всего поддержка "ISO 15926 outside", т.е. интеграция данных жизненного цикла сложного инженерного объекта. Текущая архитектура пока обеспечивает именно это: откуда-то прочесть в нейтральный формат (семантическую сетку) через loader_X+builder, затем сделать выписку в другой формат (файл, или базу данны) через writer_Y+scanner.
На другом конце ряда потенциальных конкурентов -- полноценные системы работы со знаниями VivoMind (с vivomind analogy engine -- http://www.jfsowa.com/pubs/analog.htm, также см. другие публикации тут: http://www.jfsowa.com/pubs/index.htm) и CYC (http://cyc.com), до которых нам с нашими силами, как до Луны, но попасть в эти ряды очень хочется. В принципе, в отношении языкоориентированности тоже есть с кем соревноваться (иногда в буквальном смысле, см. http://www.theenterprisearchitect.eu/archive/2011/05/26/language-workbench-competition-2011, http://www.languageworkbenches.net/ar.html), хотя там всё насквозь пропахло Java, а мы ориентируемся на совсем другой класс языков (а именно, радиосхемы, 3D модели, P&ID диаграммы, BPMN 2.0 и прочие инженерные и менеджерские модели).
Хотелось бы решать проблемы в моделе-ориентированной инженерии (даже необязательно в системной инженерии, ибо тут можно говорить и о специальной инженерии), и моделе-ориентированном менеджменте (хотя тут еще нужно договориться, насколько пригодна компьютерная техника для ведения инженерно-менеджерских моделей -- флипчарт легко выигрывает у разных "моделеров", а современные подходы lean выигрывают у "систем проектного управления". Модели же 1С бухгалтерии можно пока смело отнести к "требуемым государством", а не "полезным для дела". Так что тут нужно думать, думать, думать).
И только после выбора этих проблем можно будет соображать, куда бежать в первую голову:
-- интеграция данных за пределы принятого в типовых САПРах (например, интеграция разных баз данных и словарей в типовые САПРы)
-- обработка естественного языка (осмысленные идентификаторы в диаграммах, определения в словарях и тезаурусах, комментарии в диаграммах, аннотации к документам, и далее любые полнотекстовые документы, например, моделирование нормативных документов, текстовых регламентов, стандартов, законодательства);
-- экспертные системы (или декларативное программирование): самые разные алгоритмы обработки - от обнаружения сложных коллизий до generative design/manufacturing/planning.
-- "универсальные моделеры" (SDK для создания САПР в разных предметных областях. Например, САПР для enterprise engineering -- "организационного моделера". Бороться с линейками механических и электрических САПРов, а также системами PLM тут ох как не хочется, хотя и было бы забавно).
В любом случае, к выбору первого приложения нужно относиться очень тщательно. Успех .15926 будет определяться не качеством его проекта, а качеством приложений, в которых использован .15926 -- актуальностью задачи, качеством разработанных для решения задачи инженерных онтологий, масштабами инженерных проектов, для которых будет использовано итоговое приложение. И после определения такой задачи нужно честно дать ответ на вопрос: почему использовать для этого приложения .15926 лучше, чем XMpLant или CYC.
В любом случае, для нашей "триангуляции" в мире приложений нужно начинать общаться не только с "родной" тусовкой ISO 15926, но и с тусовкой работы со знаниями -- всеми этими "семантическими поисками", "экспертными системами", "порождающими проектировщиками" и т.д.. Смотреть на них пару лет снизу вверх, с восхищением, а затем обнаружить в какой-то момент, что они все не отлитые в бронзе гиганты мысли, а просто талантливые коллеги.
* * *
Обратите внимание, у меня намеренно во всём постинге не помянут semantic web как что-то для нас значимое. Ибо SW-системы не конкуренты нам ни разу (http://ontolog.cim3.net/forum/ontolog-forum/2011-05/msg00066.html). Но мы вполне готовы подкушивать тамошние онтологии, дело ведь не в их форме, а в знаниевом содержании.
* * *
Итого: нужно определяться с предметной областью, и выбирать в этой предметной области решаемые технологиями .15926 проблемы. А затем просто реализовывать эти технологии, конкурируя с альтернативными реализациями.
Теперь нужно разобраться (в очередной раз!), в каком направлении мы двигаем технологию. На сегодняшний день .15926 я рассматриваю в ряду:
IRING, XMpLant, ...., .15926, ..., VivoMind, CYC.
Мы точно должны быть более богаты в плане использования алгоритмов онтологической работы по сравнению с системами поддержки мэппинга/передачи разнородных данных (то есть мы поддерживаем outside, но целимся в inside), но на сегодняшний момент мы даже в наших мечтах явно менее богаты в алгоритмике по сравнению со знаниевыми системами.
Ключевым тут является обнаружение проблемы, которую можно было бы решать при помощи онтологического программирования. Далее -- разработка методики решения этой задачи (ибо проблема -- когда не знаешь, как решать, переводится путём использования онтологического программирования в задачу, которую знаешь как решать, и в этом вся фишка!). Далее -- поддержка методики софтом.
Выбор решаемой проблемы крайне важен (см. http://ailev.livejournal.com/936771.html).
Пока же решаются не столько проблемы (с неизвестным пока решением), сколько задачи (которые уже решаются при помощи IRING и XMpLant, и именно эти системы сейчас являются "конкурентами по факту"). Это прежде всего поддержка "ISO 15926 outside", т.е. интеграция данных жизненного цикла сложного инженерного объекта. Текущая архитектура пока обеспечивает именно это: откуда-то прочесть в нейтральный формат (семантическую сетку) через loader_X+builder, затем сделать выписку в другой формат (файл, или базу данны) через writer_Y+scanner.
На другом конце ряда потенциальных конкурентов -- полноценные системы работы со знаниями VivoMind (с vivomind analogy engine -- http://www.jfsowa.com/pubs/analog.htm, также см. другие публикации тут: http://www.jfsowa.com/pubs/index.htm) и CYC (http://cyc.com), до которых нам с нашими силами, как до Луны, но попасть в эти ряды очень хочется. В принципе, в отношении языкоориентированности тоже есть с кем соревноваться (иногда в буквальном смысле, см. http://www.theenterprisearchitect.eu/archive/2011/05/26/language-workbench-competition-2011, http://www.languageworkbenches.net/ar.html), хотя там всё насквозь пропахло Java, а мы ориентируемся на совсем другой класс языков (а именно, радиосхемы, 3D модели, P&ID диаграммы, BPMN 2.0 и прочие инженерные и менеджерские модели).
Хотелось бы решать проблемы в моделе-ориентированной инженерии (даже необязательно в системной инженерии, ибо тут можно говорить и о специальной инженерии), и моделе-ориентированном менеджменте (хотя тут еще нужно договориться, насколько пригодна компьютерная техника для ведения инженерно-менеджерских моделей -- флипчарт легко выигрывает у разных "моделеров", а современные подходы lean выигрывают у "систем проектного управления". Модели же 1С бухгалтерии можно пока смело отнести к "требуемым государством", а не "полезным для дела". Так что тут нужно думать, думать, думать).
И только после выбора этих проблем можно будет соображать, куда бежать в первую голову:
-- интеграция данных за пределы принятого в типовых САПРах (например, интеграция разных баз данных и словарей в типовые САПРы)
-- обработка естественного языка (осмысленные идентификаторы в диаграммах, определения в словарях и тезаурусах, комментарии в диаграммах, аннотации к документам, и далее любые полнотекстовые документы, например, моделирование нормативных документов, текстовых регламентов, стандартов, законодательства);
-- экспертные системы (или декларативное программирование): самые разные алгоритмы обработки - от обнаружения сложных коллизий до generative design/manufacturing/planning.
-- "универсальные моделеры" (SDK для создания САПР в разных предметных областях. Например, САПР для enterprise engineering -- "организационного моделера". Бороться с линейками механических и электрических САПРов, а также системами PLM тут ох как не хочется, хотя и было бы забавно).
В любом случае, к выбору первого приложения нужно относиться очень тщательно. Успех .15926 будет определяться не качеством его проекта, а качеством приложений, в которых использован .15926 -- актуальностью задачи, качеством разработанных для решения задачи инженерных онтологий, масштабами инженерных проектов, для которых будет использовано итоговое приложение. И после определения такой задачи нужно честно дать ответ на вопрос: почему использовать для этого приложения .15926 лучше, чем XMpLant или CYC.
В любом случае, для нашей "триангуляции" в мире приложений нужно начинать общаться не только с "родной" тусовкой ISO 15926, но и с тусовкой работы со знаниями -- всеми этими "семантическими поисками", "экспертными системами", "порождающими проектировщиками" и т.д.. Смотреть на них пару лет снизу вверх, с восхищением, а затем обнаружить в какой-то момент, что они все не отлитые в бронзе гиганты мысли, а просто талантливые коллеги.
* * *
Обратите внимание, у меня намеренно во всём постинге не помянут semantic web как что-то для нас значимое. Ибо SW-системы не конкуренты нам ни разу (http://ontolog.cim3.net/forum/ontolog-forum/2011-05/msg00066.html). Но мы вполне готовы подкушивать тамошние онтологии, дело ведь не в их форме, а в знаниевом содержании.
* * *
Итого: нужно определяться с предметной областью, и выбирать в этой предметной области решаемые технологиями .15926 проблемы. А затем просто реализовывать эти технологии, конкурируя с альтернативными реализациями.