Обсуждение

Статической является конкретная версия онтологии :) Собсно, если онтология фиксирована и не меняется, то в рамках софтостроения она избыточна, ибо вместо нее прекрасно подойдет иерархия ОО классов либо схема БД. Более того, как раз ОО подход и реляционные БД опираются по сути на статичные онтологии. Т.е. конкретная версия софта строго привязана к конкретной версией структуры классов и структуры БД. В ряде случаев, это бывает несколько версий, но в любом случае, они известны заранее. Кроме того эволюция ОО классов и (недо)нормализованных схем БД затруднена, по ряду причин. Введение онтологий в софт, кагбэ и имеет целью решение вышеозначенных проблем. Т.е. я бы сказал что компьютерные онтолии от ОО отличаются именно попыткой привнесения динамики в той или иной форме.

Думаю, тут дело ещё и в том, что Ваши оппоненты имеют в виду динамику, а Вы, зачастую, кинематику - движение, не связанное со временем.

Дык если я паттерны в методе ищу, я вынужден как в конкретном времени работать, так и в абстрактном, разве нет? А 4D позволяет и "настоящую динамику" обсуждать как "неподвижное время", я вот в этом потихоньку начинаю тренироваться. Ибо обсуждать процессы в 3D -- мутно, кучеряво, неудобно, хотя и можно.

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

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

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

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

Насколько я понимаю stepanbezusov, он пытается показать решение проблемы "исключения времени" или ухода от времённости, через использование категории "процесс - механизм". Когда мы изменчивость (динамичность) прячем мысленно, а потом и в реализациях внутрь процесса, т нам надо показать динамичнсть уже самого процесса. За счет чего? За счет обращения внимания на механизмы, котрые "двигают" этот процесс, в котором уже время спрятано внутри, свернуто. Механизмы могут быть не только из области механики (шестеренки), эт о же только пример. Механизм - это любая зависимость, которая двигает, меняет состояния процесса, даже такие, которые меняют фазовые состояния материала этого процесса. Механизмы могут быть техническими, физическими, химическими, социальными, деятельностными и прочие. И, так, время исключается, за счет работы с состояниями процесса, которые изменяются механизмами этого процесса. Грубо, если мы знаем все состояния процесса, время нам не нужно знать. Кстати, понятие жизненного цикла (процесса)- это движение в этой же линии, это представление "механики" процесса. А различение на "целевую систему" и "обеспечивающую" - это немного про другое, это про то, как управлять исполнением процесса, ведь, "обеспечивающая система" это же управляющий процесс, который управляет исполнением управляемеого процесса "целевой системы", это уже ближе к кибернетике.

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

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

Давайте вы разберитесь, время у вас 3D или 4D, и как вы поступаете с пространственно-временными экстентами -- тогда и поговорим. Я вот потихоньку ухожу в 4D, и жизнь становится проще, без "объективаций". У объектов есть темпоральные части, только и всего. Время вообще неподвижно, это такая же размерность, как длина и ширина. Процессы -- это отношения между темпоральными частями объектов. Задать процессы -- это задать отношения между объектами. Литературы на эту тему достаточно, чтобы показать полезность именно такой онтологии, и мутность и некомпактность выражения в других, 3D онтологиях. Про выполнимость-исполнимость -- это отдельный разговор, его нужно вести уже после того, как разборка со временем произошла. Критерий ясности объяснений -- объясните все эти "процессы" не мне, а компьютеру.