Все эти «измерения» это снова-таки всё абстракции, элементы выбранной вами модели. «физика говорит нам» только то, что в физике отсутствует «истина»как концепция — есть только гипотезы о том, насколько близко те или иные модели (основанные на тех или иных абстракциях) описывают реальность.
Термин «близко» тут следует понимать в бизнес-смысле практической применимости.
«момент времени» определите как вам удобно — с моей точки зрения, t от t' отличаются только тем, что указывают, в какой последовательности наблюдатели совершали свои действия по measurement и фиксации состояний A
состояние это совокупность векторов описанная выше
«X состоит в Y» значит, что сущность X является элементом вектора Y
вектор это упорядоченное множество элементов
«инструмент» это некий демон Максвелла (или кот Шредингера, если угодно) который магическим образом описывает состояние A в виде информационного объекта, который сохраняется неизменным на протяжении достаточно большого промежутка времени после момента измерения (типа «мгновенный снимок» ну то есть measurement)
почему вы не спрашиваете, что такое субъект, что такое объект, и что такое связывающий их предикат (relationship)? это же так увлекательно — спрашивать!
SergeIndex, я же это все для Марка пишу ;) его же интересует не практическая реализация в живой системе той модели, которая будет подробна и полна в необходимой и достаточной для достижения целей stakeholders и спонсоров проекта ;) его интересует абстрактная теория, и чем запутаннее, многомернее, ширее, глубжее и кустистее — тем лучше ;)
а в реальной жизни понятно, что действуя в инструментарии ООП удобно представлять событие объектом с методами и атрибутами — экземпляром типа (или ООП-класса) «событие» ;) но Марк же не этого добивается ;) он истины взыскует ;)
О, я чуть выше то же самое написал. И кстати для полной красоты модели надо бы сказать, что наблюдатель O в момент времени t с помощью инструмента I выполнил measurement и тем самым он ЗАФИКСИРОВАЛ (в виде информационного объекта — экземпляра типа «модель события», каковой тип есть подкласс класса «модели») СВОЮ ГИПОТЕЗУ о состоянии A, или если правильно то не «гипотезу» а his belief, каковой belief является верным лишь с вероятностью p( O, I, A ). Получаем байесову сеть гипотез (or better to say believes) и это уже вполне серьезная заявка на решение заданной Марком головоломки о событиях.
Марк, возьмите на вооружение — так модель становится достаточно сложной и запутанной, чтобы вам понравиться.
(Я правда не берусь уверенно утверждать, сколькимерна такая модель).
Говорить что событие есть «объект» это наверное все же натяжка. Оно и не субъект и не объект вообще говоря.
В моем понимании, событие — это зарегистрированный measurement того, что в определенный момент времени в определенном месте изменилось состояние системы, состоящей из N >= 0 субъектов и M >= 0 объектов.
в момент t наблюдатель O используя инструмент I зафиксировал состояние A( {subject}, {relationship}, {object}, {location} )
в момент t' наблюдатель O' используя инструмент I' зафиксировал новое состояние A'( {subject}', {relationship}', {object}', {location}' )
subject, relationship, object, location — все векторы, location — вектор неких представлений пространства (например трехмерных объемов или трехмерных координат), при этом часть relationship связывает компоненты subject и object с элементами location
понятно что из A в A' систему перевела некая последовательность из K >= 1 события (в случае «аналогового» процесса изменений можно представить дискретную последовательность K бесконечной длины) но поскольку в интервале [t, t'] никто ничего не измерял, мы для простоты считаем, что событие было одно — это ИЗМЕНЕНИЕ состояния от A к A'
да, это изменение может состоять в
— изменении {subject} в т.ч. изменении его размерности
— изменении {object} в т.ч. его размерности
— изменении количества (размерности) {relationship} между компонентами {subject} и {object}
— изменении направлений, типов и атрибутов {relationship}
— изменении location
Марк, парадигма/нотация как самоцель? это настолько же странное целеполагание, как «создать еще один язык программирования» или «создать еще одну методику логического моделирования данных». Такие вещи имеют смысл, если
— *и* есть задача,
— *и* существующие инструменты недостаточны или неудобны для её решения
а так вообще ставить задачу «создать Всеобщую Универсальную Онтологию Всего Сущего» чисто для души? оно вам надо? духовные искания молодого Вертера, онтология ради онтологии? Но тогда, Марк, получается, что ответ на вопрос на… я? ой то есть — зачем? отсутствует, и мы приходим в классическую ситуацию: если ты не знаешь, куда ты хочешь попасть, тебе безразлично, куда идти. ISO так ISO, почему бы и нет.
В реальности люди сталкиваются с определенными задачами, требующими решения — в частности, с задачами моделирования реальности с точностью ПРИБЛИЖЕНИЯ в степени И «не менее чем необходимая» И «не более чем достаточная» И для целей решения этой конкретной задачи. Кстати и Хэй говорит об этом да и все прочие авторы. Поэтому область знания о data modeling неисчерпаема и будет развиваться далее, поскольку неисчерпаемо пространство как задач, так и уровней детализации моделей для их решения. Поэтому все новые и новые статьи, методички и ликбезы будут писаться (и востребованы) снова и снова. А вы тут, Марк, хотите Придумать Всё Сущее и Закрыть Вопрос Раз И Навсегда, и тем самым оставить без работы уйму образованных и умных людей! Так даже у толкователей Талмуда за столько столетий такого не случилось, а ваша активность как раз наиболее родственна по своей сути именно к ним.
Марк — академический преподаватель, профессиональный толкователь онтологических сакральных книг. Человек несомненно уважаемый и весьма востребованный, но просьба не путать его с полевым инженером — РП.
Деятельность — ПСИХИЧЕСКАЯ??? функция??? Марк, не кажется ли вам, что вы путаетесь в собственных определениях?
И почему бы в целях моделирования не рассматривать организационную единицу как сущность, взаимозаменяемую с субъектом? (в конце концов, ничто не мешает о.е. состоять из одного человека, или состоять из нескольких людей, но взаимодействовать с миром единообразно).
Это ж Марк! ;) я всегда в него верил ;) но в глубине души я надеюсь, что 3-х книг Хэя + еще статей даже Марку хватит на полгода вдумчиво вникать (и выявлять ошибки, которые при втором и третьем прочтениях оказывается и не ошибки вовсе).
Кстати мне такая мысль пришла в голову — надо бы собраться с духом, где-то скачать и таки просмотреть этот великий и ужасный ISO 15926, после чего написать лично Хэю просьбу, если ему интересно — найти время и прокомментировать стандарт например серией заметок. Как минимум, мне интересно его мнение о границах практической применимости этого мега-ISO и (в случае применимости) — о границах целесообразности применения. Пока что у меня такое субъективное ощущение — для расчехления такой фундаментальной гаубицы далеко не любой воробей является достаточным поводом (не говоря уже «необходимым»). Я еще понимаю ну там при строительстве АЭС или новейшего аэробуса, а в более обыденных ситуациях сравнительно коротких и не настолько мегабюджетных проектов? ы?
Возможно, имеет смысл воздерживаться от введения собственных incompatible определений как можно дольше?
Например, термин «функция» уже настолько заезжен и столько раз переопределен… я бы его если трогал, то исключительно с указанием контекста:
функция организационной единицы — совокупность (сумма) деятельностей, которые организационная единица выполняет во всех деловых процессах и проектах, в которых она участвует, и успешное выполнение коих требует от о.е. наличия определенного набора сходных и/или однотипных знаний, умений и навыков
IMHO только так решается навязший в зубах смысловой клинч общеупотребительного словосочетания «функции бухгалтерии»
(почему именно деловых процессов — потому что технологический процесс как правило целиком находится в компетенции одной организационной единицы и не предусматривает кросс-функциональных взаимодействий разноподчиненных организационных единиц; таким образом, в контексте делового процесса технологический процесс является процедурой-компонентом, single task, хотя всё это обсуждаемо, конечно)
Проекты и процессы достаточно хорошо определены в PMBOK и CBOK, выдумывать IMHO нечего и незачем, главное — избегать корявых переводов. Кстати, ISO 15926-1 и ISO 15926-2 что говорят по поводу проектов и процессов? (честно говоря, не читал это ISO хотя для общей ерундиции надо бы, наверное)
Partridgе это 1996 год, по правде говоря с тех пор отрасль шагнула далеко вперед, думаю я пропущу его. По-моему Сильверстон на него еще в 2000 году ссылался. West — Ок, надо освежить в памяти — я видимо пропустил, спасибо. В свою очередь касаемо рационального мышления, логики, онтологий и семантик еще рекомендую такого автора как Eliezer Yudkowsky — кроме того, что он дописывает шикарный фанфик на Гарри Поттера hpmor.com/ (есть перевод на hpmor.ru есличё) он еще и центр сообщества lesswrong.com/ каковое рекомендую из общих соображений.
Термин «близко» тут следует понимать в бизнес-смысле практической применимости.
состояние это совокупность векторов описанная выше
«X состоит в Y» значит, что сущность X является элементом вектора Y
вектор это упорядоченное множество элементов
«инструмент» это некий демон Максвелла (или кот Шредингера, если угодно) который магическим образом описывает состояние A в виде информационного объекта, который сохраняется неизменным на протяжении достаточно большого промежутка времени после момента измерения (типа «мгновенный снимок» ну то есть measurement)
почему вы не спрашиваете, что такое субъект, что такое объект, и что такое связывающий их предикат (relationship)? это же так увлекательно — спрашивать!
Ну и как же без них-то, без сущностей, а?
а в реальной жизни понятно, что действуя в инструментарии ООП удобно представлять событие объектом с методами и атрибутами — экземпляром типа (или ООП-класса) «событие» ;) но Марк же не этого добивается ;) он истины взыскует ;)
Марк, возьмите на вооружение — так модель становится достаточно сложной и запутанной, чтобы вам понравиться.
(Я правда не берусь уверенно утверждать, сколькимерна такая модель).
В моем понимании, событие — это зарегистрированный measurement того, что в определенный момент времени в определенном месте изменилось состояние системы, состоящей из N >= 0 субъектов и M >= 0 объектов.
в момент t наблюдатель O используя инструмент I зафиксировал состояние A( {subject}, {relationship}, {object}, {location} )
в момент t' наблюдатель O' используя инструмент I' зафиксировал новое состояние A'( {subject}', {relationship}', {object}', {location}' )
subject, relationship, object, location — все векторы, location — вектор неких представлений пространства (например трехмерных объемов или трехмерных координат), при этом часть relationship связывает компоненты subject и object с элементами location
понятно что из A в A' систему перевела некая последовательность из K >= 1 события (в случае «аналогового» процесса изменений можно представить дискретную последовательность K бесконечной длины) но поскольку в интервале [t, t'] никто ничего не измерял, мы для простоты считаем, что событие было одно — это ИЗМЕНЕНИЕ состояния от A к A'
да, это изменение может состоять в
— изменении {subject} в т.ч. изменении его размерности
— изменении {object} в т.ч. его размерности
— изменении количества (размерности) {relationship} между компонентами {subject} и {object}
— изменении направлений, типов и атрибутов {relationship}
— изменении location
в любом наборе.
НУ И ЧТО ТЕПЕРЬ?
— *и* есть задача,
— *и* существующие инструменты недостаточны или неудобны для её решения
а так вообще ставить задачу «создать Всеобщую Универсальную Онтологию Всего Сущего» чисто для души? оно вам надо? духовные искания молодого Вертера, онтология ради онтологии? Но тогда, Марк, получается, что ответ на вопрос на… я? ой то есть — зачем? отсутствует, и мы приходим в классическую ситуацию: если ты не знаешь, куда ты хочешь попасть, тебе безразлично, куда идти. ISO так ISO, почему бы и нет.
В реальности люди сталкиваются с определенными задачами, требующими решения — в частности, с задачами моделирования реальности с точностью ПРИБЛИЖЕНИЯ в степени И «не менее чем необходимая» И «не более чем достаточная» И для целей решения этой конкретной задачи. Кстати и Хэй говорит об этом да и все прочие авторы. Поэтому область знания о data modeling неисчерпаема и будет развиваться далее, поскольку неисчерпаемо пространство как задач, так и уровней детализации моделей для их решения. Поэтому все новые и новые статьи, методички и ликбезы будут писаться (и востребованы) снова и снова. А вы тут, Марк, хотите Придумать Всё Сущее и Закрыть Вопрос Раз И Навсегда, и тем самым оставить без работы уйму образованных и умных людей! Так даже у толкователей Талмуда за столько столетий такого не случилось, а ваша активность как раз наиболее родственна по своей сути именно к ним.
Вот вам зато интересный ресурс тоже, после изучения работ Хэя и tdan.com рекомендую, вот есть у них например такой интересный автор Terry Halpin, см. www.brcommunity.com/b795.php серию и более раннюю www.brcommunity.com/b734.php а особенно вам понравится серия www.brcommunity.com/b471.php я гарантирую это. И другие их авторы тоже весьма интересные вещи пишут, как то www.brcommunity.com/b550.php в общем есть на что обратить внимание.
И почему бы в целях моделирования не рассматривать организационную единицу как сущность, взаимозаменяемую с субъектом? (в конце концов, ничто не мешает о.е. состоять из одного человека, или состоять из нескольких людей, но взаимодействовать с миром единообразно).
Кстати мне такая мысль пришла в голову — надо бы собраться с духом, где-то скачать и таки просмотреть этот великий и ужасный ISO 15926, после чего написать лично Хэю просьбу, если ему интересно — найти время и прокомментировать стандарт например серией заметок. Как минимум, мне интересно его мнение о границах практической применимости этого мега-ISO и (в случае применимости) — о границах целесообразности применения. Пока что у меня такое субъективное ощущение — для расчехления такой фундаментальной гаубицы далеко не любой воробей является достаточным поводом (не говоря уже «необходимым»). Я еще понимаю ну там при строительстве АЭС или новейшего аэробуса, а в более обыденных ситуациях сравнительно коротких и не настолько мегабюджетных проектов? ы?
Например, термин «функция» уже настолько заезжен и столько раз переопределен… я бы его если трогал, то исключительно с указанием контекста:
функция организационной единицы — совокупность (сумма) деятельностей, которые организационная единица выполняет во всех деловых процессах и проектах, в которых она участвует, и успешное выполнение коих требует от о.е. наличия определенного набора сходных и/или однотипных знаний, умений и навыков
IMHO только так решается навязший в зубах смысловой клинч общеупотребительного словосочетания «функции бухгалтерии»
(почему именно деловых процессов — потому что технологический процесс как правило целиком находится в компетенции одной организационной единицы и не предусматривает кросс-функциональных взаимодействий разноподчиненных организационных единиц; таким образом, в контексте делового процесса технологический процесс является процедурой-компонентом, single task, хотя всё это обсуждаемо, конечно)
Проекты и процессы достаточно хорошо определены в PMBOK и CBOK, выдумывать IMHO нечего и незачем, главное — избегать корявых переводов. Кстати, ISO 15926-1 и ISO 15926-2 что говорят по поводу проектов и процессов? (честно говоря, не читал это ISO хотя для общей ерундиции надо бы, наверное)