Без заголовка

Много чего написали, постараюсь хотя бы упомянуть направления для ответов. Отношения часть целое (крыльчатка часть насоса) это холархии, а не классификации. Composition, а не Classification (и не Specialisation, кстати тоже). Для того, чтобы мне так уверенно отвечать, нужно иметь как раз (разделяемую многими, общую) онтологию -- знать, что кроме классификаций есть ещё примерно 3500 тысяч основных отношений, встрачающихся в инженерии, из них 500 более-менее основных (это исследовалось для предметной области инженерии в проекте Gellish). Констрейнты можно задавать не только логически, но и функционально. Карри-Ховард, всё такое. Логический язык очень плохо поддерживает работу с последовательностями, там работается сразу со множествами. Это тяжело для инженерии и для менеджмента. Более того, в работу логических алгоритмов тяжело вставлять моменты интерактивности (диалоги с пользователем, ожидания отвалившихся на 200ms удалённых серверов и т.д.). Поэтому мы тут пойдём другим путём. Именно поэтому логические языки в мире в загоне, а функциональные (как шаг к декларативности) хоть как-то, но выживают. Вообще, и логические языки выживают только "фортраноподобные", такие как Prolog, в котором большая часть функциональности -- это управление оптимизацией логического вывода, и поэтому все отмечают его "наполовину императивность". Для работы с онтологиями совершенно необязательно иметь именно OWL и логику. Это подробно обсуждается самими онтологами (тот же John Sowa считает OWL и шаг к обязательной decidability -- это ошибочные шаги для большинства в сообществе прикладных онтологов. Выразительность требуется всем, а вот логическая вычислимость -- немногим). Дискуссия о преимуществах логического и текстового представления для языков сошла в последние годы на нет: требуются оба. С одной стороны, топология задач лучше видна на графах, а с большими объемами нужно работать на текстах -- плюс порождаем-то мы в других программах именно тексты, они нужны, чтобы не только человек мог работать с этими данными. Примером такого для строгих языков служит Modelica, там предписан способ связи визуальных моделей и текстового их содержания. Мы пойдём именно таким путём: основная работа с текстами, но есть и возможность визуальной работы с получающимися моделями. Кстати, в текущей версии .15926 Editor у нас псевдографическое представление (специального вида редактируемые деревья: что-то среднее между полнографическим и текстовым представлениями). Юзер должен вводить данные не на полуестественном языке, а на естественном языке. А потом парсер должен переспрашивать, ежели чего не понял. И делать огромную интеллектуальную работу, восстанавливая контекст. Но это ещё некоторое будущее. Мы хотим прорваться через другое, не через controlled english (то есть не через синтаксис похожести высказываний на языке на обычный текст). Мы хотим прорваться через особенности выражения мысли человека в инженерных "псевдокодах". Чтобы человек мог сказать "поток высотой 18 см" и компьютер его не поправил, что "поток это activity, а у activity нет высоты", а вывел сам "поток это activity, но вы имели ввиду system component/FunctionalPhysicalObject, реализующий эту activity". Вот это одна из основных целей, и паттерны позволяют надеяться, что её можно попытаться достигнуть -- просто закодировав паттерны типичных инженерных высказываний. В работах по инженерии требований есть моделеры требований, которые имеют уже порядка 3000 лингвистических паттернов для выражения требований. Вот и мы пойдём таким путём, только для этих лингвистических паттернов представим форму фиксации модельного знания, гарантированно укладывающуюся в общие данные.