Я очень плохо разбираюсь в программировании, и в ООП ещё хуже чем в других направлениях. Поэтому для меня это во многом две области реальности со случайно совпадающими терминологиями. Однако в моделирование данных ООП проникает через объектные модели данных, и тут я разбираюсь чуть лучше. В этой области простое понимание разницы между объектами и их описаниями творит чудеса. Становится понятно, как разделить концептуальную модель и её реализацию без конфронтации.
Реализация концептуальной логической модели средствами СУБД или ООП как правило вообще проблемы не представляет. Хотя конечно если реализатор не понимает сути того, что он реализует — выгод от концептуальной модели остаётся после реализации ноль.
В обратную сторону хуже — восстановить концептуальную логическую модель по объектной или реляционной крайне сложно, чаще проще поработать со специалистом предметной области.
Разумеется, моё утверждение на русском языке можно и в UML нарисовать. Это не называется «закладывается».
Реализацию в коде через жёсткую прошивку ограничения мы сразу не рассматриваем, это не про эту задачу, надеюсь, это понятно.
А вот про реализацию в хранилище я и говорю. Надо придумать структуру хранения сущностей Машина, Колесо. В то время как в таблице конкретных машин Машина — это вся таблица, а Колесо — это колонка. Что в одной модели объект — то во второй атрибут.
Таблицу надо таки называть «Машины». Потому что таблица — это вообще другой уровень, это реализация, а не концептуальная модель. А вот перечень заголовков её столбцов — это описание класса «Машина».
Да, именно это решение для такого класса задач и применяется. Правда, пока в извращённой форме. Отдельно дизайнится реляционная или объектная система хранения ограничений. Отдельно — система хранения данных о конкретных машинах. А в RDF хранится общая концептуальная модель предметной области и мэппинг, который отдельный engine может использовать для извлечения правил из первой БД и верификации данных во второй.
Очень просто указать на такой класс задач. Вам может понадобиться одновременно хранить в системе ограничение «машина имеет ровно 4 колеса», а также в таблице для каждой конкретной машины хранить серийные номера всех колёс. И, разумеется, хранить информацию о том, что машина и колёса в ограничении — это те же самые машина и колёса, что в таблице конкретных машин.
Всё-таки зря вы написали статью, направленную на антагонизацию и противопоставление терминологии. Гораздо лучше было бы написать статью, показывающую разумный мэппинг терминологий и онтологий аристотелевского и логического подходов, ограничения этого мэппинга, и принципы выбора подходов.
«Итак: экстент относится со множество разных физических объектов: операция, объект, событие, и так далее. „
Не понимаю. Экстент один, это 4Д индивид. Я с трудом представляю себе, какими определениями операции, объекта и события (классов!) вы пользуетесь, но если они есть и индивид (экстент) всем этим определениям удовлетворяет одновременно — классифицируйте его всеми этими классами.
Отношения классификации могут быть сами класифицированы, так что отмоделировать точки зрения тоже проблемы нет. Хотя я не уверен, что вам нужны именно точки зрения. я упорно советую посмотреть на механизм ролей.
Ещё раз — один и тот же физический индивид может быть частью нескольких функциональных индивидов, тут вообще нет проблемы.
«Но не могу, потому что такой сущности, как модель объекта в голове у субъекта в ИСО нет. „
Так введите её. Если речь о субъекте Вася, то эта модель — индивид, состоящий из конкретных синапсов там. В справочных данных введите класс таких моделей. Это класс индивидов. Он связан с представлением отношением репрезентации.
“Не молотка и не экстента, а именно физического объекта, у которого есть ширина, высота и длина. „
Не понимаю. Экстент и физический объект — это одно и то же.
“И я хочу иметь возможность смотреть на тот же экстент как на операцию. „
Не понятно опять. Смотрите. Операция (индивидуальная) — это тоже экстент. Полностью соответствует.
“Потому что в ИСО считается, что функциональность объекта предопределена создателем этого объекта.»
Вовсе нет. Для пилота и для техника функциональность автопилота совершенно разная, и границы даже могут отличаться.
Изменения функции, если они непротиворечивы, рассматриваются через введение разных функциональных объектов. Если противоречивы — можно ввести альтернативные миры, разумеется. Possible worlds — это мощный механизм, они пересекаются в настоящем, но могут различаться в прошлом и в будущем.
Ну вот та же самая проблема :-( Ну не понимаю я, где вы увидели противоречие.
«В своем определении гвоздодера Вы предложили определять его только теми экстентами, когда они выполняли функцию, но в другие моменты времени Вы отказали экстенту быть связанным с функциональным объектом гвоздодер. „
Вы какой “гвоздодёр» имеете в виду? Класс или индивида?
И с примером Мэтью вы не разобрались. Автопилот (индивидуальный автопилот конкретного самолёта, функциональный объект) существует всегда, пока он не демонтирован с самолёта. Но когда демонтирован — не существует.
А вот «рулевой» не существует гораздо чаще. Например, пока самолёт стоит — ни автопилот, ни пилот не пересекаются в этот момент с рулевым. И никакой иной объект не пересекается. Нету рулевого.
Что касается операций и событий, то, скорее всего, это классы, которые вы можете определить в своей системе справочных данных сами. Их тип — ClassOfActivity, видимо. Если Event вам не нужны — вы можете их не использовать, только не считайте тогда свои «события» переводом Event. Реально у вас появятся в модели неявные Event для определения последовательности Activity, но никто не заставляет вас определять их для каждой возможной куликовской битвы!
Хороший ответ на первый вопрос и мне неизвестен. Только дисциплина моделирования может помочь. Для Куликовской битвы более-менее очевидно, что её моделирование в виде Event было бы ошибкой, её ненулевая продолжительность во времени более-менее ясна.
«4 структуры, которые мне известны: операция, процесс, функция, функциональная структура.»
Тут мы опять не продвинемся, пока вы не приучитесь различать (и явно ууказывать) индивиды и классы. Я бы сказал, что скорее всего Операция, Процесс, Функция, Функциональная структура — это всё классы индивидов, членами которым могут быть Activities и Events.
Вы не понимаете принципов моделирования 15926, к сожалению. Ваши слова всегда настолько неточны, что не позволяют как-то оценить, верно ли ваше высказывание с точки зрения 15926, или нет. Постараюсь пояснить примерами:
Молоток — это класс функциональных объектов
Гвоздодёр — это класс функциональных объектов
Индивиды, использовавшиеся дядей Васей между 01.01.2014 и 01.01.2015 для выдирания гвоздей — это один индивидуальный «Гвоздодёр дяди Васи в 2014 году». Он принадлежит классу Гвоздодёр.
Молотк с зелёной ручкой и выцарапанным словом «Вася» — это временнАя часть объекта «Гвоздодёр дяди Васи в 2014 году». Но точно так же это временнАя часть объекта «Молоток дяди Васи в 2014 году».
Если вы нуучитесь выделять и чётко обозначать индивиды и классы — станет намного легче беседовать.
Никакого отношения к тому «кто что считает» — функциональные объекты не имеют. Если дядя Петя умеет и любит вытаскивать гвозди зубами — его зубы являются темпоральной частью функционального объекта индивиды «Гвоздодёр дяди Пети».
И ещё раз — по 15926 при совпадении экстентов совпрадают индивиды. Функциональный объект и физичекий невозможно различить на основе только анализа их экстентов.
Если вы вводите «функциональное событие» по аналогии с функциональным объектом — покажите, как именно оно состоит из обычных событий. Если же аналогии такой нет, то, пожалуйста, откажитесь от использования слова «функциональный», чтобы не сбивать понимание тех, кто работает в рамках ISO 15926.
Это не совсем точная трактовка. Функциональные объекты позволяют моделировать смысл только в некоторых специальных случаях, и это скорее не множественный субъективный смысл, а очень объективированный смысл.
Для множества субъективных смыслов в стандарте есть Roles and Domains. Их и надо использовать.
В 15926 есть два понятия — Activity и Event. Первое — занимает промежуток времени, второе — временнАя граница. Я не очень понимаю, что именно не вмещается в эти понятия?
Но моменты знать «абсолютно точно» никогда не надо. Можно указывать отношения предшестования-следования без указания точного времени. А уж моделирование типовых процессов, любых схем и шаблонов вообще делается в классах а не в индивидах, то есть никакого точного знания не предполагается.
15926 предписывает выбирать из очень ограниченного набора отношений, и не выдумывать. И утверждает, что это ограниченное количество — достаточно для описания 4Д мира.
Если очень грубо, то все свойства объектов описываются через классификации, а все отношения — через часть-целое.
У отношения часть-целое есть ряд важных подвидов. В случае выполнения разными физическими объектами по-очереди одной и той же роли — это выделение функционального объекта и его временнЫх частей. В случае выполнения разными физическими объектами ролей в активности (это тоже отношения часть-целое) — имеется механизм ролей как дополнительной классификации частей.
Множественые классификации позволяют сохранить один механизм для всех возможных нужд — трактовка, восприятие, что-бы-там-ещё-ни-было.
15926 — это определённое предложение по тому, как моделировать мир. Бессмысленно говорить, что он «в целом верен», или что «но там что-то пропустили при создании». И ничего дополнительного изобретать не надо, надо либо им пользоваться, либо создавать свой стандарт.
Победа — это не событие. Победа — это класс событий. Если вы с этим не согласны — я не совсем понимаю, как продолжать дискуссию
«Победа с точки зрения Донского» и «Поражение с точки зрения Мамая» — это два разных класса событий.
«Победа в Куликовском сражении» и «Поражение в Куликовском сражении» — это два имени одного события, ибо их 4Д области не просто имеют общий элемент, а совпадают.
Реализация концептуальной логической модели средствами СУБД или ООП как правило вообще проблемы не представляет. Хотя конечно если реализатор не понимает сути того, что он реализует — выгод от концептуальной модели остаётся после реализации ноль.
В обратную сторону хуже — восстановить концептуальную логическую модель по объектной или реляционной крайне сложно, чаще проще поработать со специалистом предметной области.
Реализацию в коде через жёсткую прошивку ограничения мы сразу не рассматриваем, это не про эту задачу, надеюсь, это понятно.
А вот про реализацию в хранилище я и говорю. Надо придумать структуру хранения сущностей Машина, Колесо. В то время как в таблице конкретных машин Машина — это вся таблица, а Колесо — это колонка. Что в одной модели объект — то во второй атрибут.
Не понимаю. Экстент один, это 4Д индивид. Я с трудом представляю себе, какими определениями операции, объекта и события (классов!) вы пользуетесь, но если они есть и индивид (экстент) всем этим определениям удовлетворяет одновременно — классифицируйте его всеми этими классами.
Отношения классификации могут быть сами класифицированы, так что отмоделировать точки зрения тоже проблемы нет. Хотя я не уверен, что вам нужны именно точки зрения. я упорно советую посмотреть на механизм ролей.
Ещё раз — один и тот же физический индивид может быть частью нескольких функциональных индивидов, тут вообще нет проблемы.
Так введите её. Если речь о субъекте Вася, то эта модель — индивид, состоящий из конкретных синапсов там. В справочных данных введите класс таких моделей. Это класс индивидов. Он связан с представлением отношением репрезентации.
“Не молотка и не экстента, а именно физического объекта, у которого есть ширина, высота и длина. „
Не понимаю. Экстент и физический объект — это одно и то же.
“И я хочу иметь возможность смотреть на тот же экстент как на операцию. „
Не понятно опять. Смотрите. Операция (индивидуальная) — это тоже экстент. Полностью соответствует.
“Потому что в ИСО считается, что функциональность объекта предопределена создателем этого объекта.»
Вовсе нет. Для пилота и для техника функциональность автопилота совершенно разная, и границы даже могут отличаться.
Изменения функции, если они непротиворечивы, рассматриваются через введение разных функциональных объектов. Если противоречивы — можно ввести альтернативные миры, разумеется. Possible worlds — это мощный механизм, они пересекаются в настоящем, но могут различаться в прошлом и в будущем.
«В своем определении гвоздодера Вы предложили определять его только теми экстентами, когда они выполняли функцию, но в другие моменты времени Вы отказали экстенту быть связанным с функциональным объектом гвоздодер. „
Вы какой “гвоздодёр» имеете в виду? Класс или индивида?
И с примером Мэтью вы не разобрались. Автопилот (индивидуальный автопилот конкретного самолёта, функциональный объект) существует всегда, пока он не демонтирован с самолёта. Но когда демонтирован — не существует.
А вот «рулевой» не существует гораздо чаще. Например, пока самолёт стоит — ни автопилот, ни пилот не пересекаются в этот момент с рулевым. И никакой иной объект не пересекается. Нету рулевого.
Что касается операций и событий, то, скорее всего, это классы, которые вы можете определить в своей системе справочных данных сами. Их тип — ClassOfActivity, видимо. Если Event вам не нужны — вы можете их не использовать, только не считайте тогда свои «события» переводом Event. Реально у вас появятся в модели неявные Event для определения последовательности Activity, но никто не заставляет вас определять их для каждой возможной куликовской битвы!
«4 структуры, которые мне известны: операция, процесс, функция, функциональная структура.»
Тут мы опять не продвинемся, пока вы не приучитесь различать (и явно ууказывать) индивиды и классы. Я бы сказал, что скорее всего Операция, Процесс, Функция, Функциональная структура — это всё классы индивидов, членами которым могут быть Activities и Events.
Молоток — это класс функциональных объектов
Гвоздодёр — это класс функциональных объектов
Индивиды, использовавшиеся дядей Васей между 01.01.2014 и 01.01.2015 для выдирания гвоздей — это один индивидуальный «Гвоздодёр дяди Васи в 2014 году». Он принадлежит классу Гвоздодёр.
Молотк с зелёной ручкой и выцарапанным словом «Вася» — это временнАя часть объекта «Гвоздодёр дяди Васи в 2014 году». Но точно так же это временнАя часть объекта «Молоток дяди Васи в 2014 году».
Если вы нуучитесь выделять и чётко обозначать индивиды и классы — станет намного легче беседовать.
Никакого отношения к тому «кто что считает» — функциональные объекты не имеют. Если дядя Петя умеет и любит вытаскивать гвозди зубами — его зубы являются темпоральной частью функционального объекта индивиды «Гвоздодёр дяди Пети».
Если вы вводите «функциональное событие» по аналогии с функциональным объектом — покажите, как именно оно состоит из обычных событий. Если же аналогии такой нет, то, пожалуйста, откажитесь от использования слова «функциональный», чтобы не сбивать понимание тех, кто работает в рамках ISO 15926.
Для множества субъективных смыслов в стандарте есть Roles and Domains. Их и надо использовать.
Но моменты знать «абсолютно точно» никогда не надо. Можно указывать отношения предшестования-следования без указания точного времени. А уж моделирование типовых процессов, любых схем и шаблонов вообще делается в классах а не в индивидах, то есть никакого точного знания не предполагается.
Если очень грубо, то все свойства объектов описываются через классификации, а все отношения — через часть-целое.
У отношения часть-целое есть ряд важных подвидов. В случае выполнения разными физическими объектами по-очереди одной и той же роли — это выделение функционального объекта и его временнЫх частей. В случае выполнения разными физическими объектами ролей в активности (это тоже отношения часть-целое) — имеется механизм ролей как дополнительной классификации частей.
Множественые классификации позволяют сохранить один механизм для всех возможных нужд — трактовка, восприятие, что-бы-там-ещё-ни-было.
15926 — это определённое предложение по тому, как моделировать мир. Бессмысленно говорить, что он «в целом верен», или что «но там что-то пропустили при создании». И ничего дополнительного изобретать не надо, надо либо им пользоваться, либо создавать свой стандарт.
«Победа с точки зрения Донского» и «Поражение с точки зрения Мамая» — это два разных класса событий.
«Победа в Куликовском сражении» и «Поражение в Куликовском сражении» — это два имени одного события, ибо их 4Д области не просто имеют общий элемент, а совпадают.
Это всё — в строгом соответствии с ISO 15926.