Комментарии 124
Используя в нашей работе OWL...
Я несколько не в теме — а что значит "OWL"?
Просканировав наискось 165 стр. краткого введения, пришел к выводу, что OWL — это Web Ontology Language.
То есть основной объём статьи посвящен моделированию типов, много чего понаписано. Но это никак не дополняет и не развивает математическую теорию множеств.
Объект (машина) — это тоже модель, модель пространственно-временной части вселенной. Эта модель существует в нашем сознании до тех пор, пока мы имеем понятие об автомобилях. Потеряв это понятие, мы теряем и объект. Никто уже не сможет сказать: это автомобиль, если никто не владеет понятием об автомобилях. Понятие — это тип. Поэтому первичным в нашем мире являются понятия об объектах. На основе этих понятий мы строим в нашем сознании объекты, связи и множества.То есть, первичное понятие — тип, вторичное — объект и множества. Все верно.
Правильно было бы говорить о порождении типом множества объектов, а не о моделировании множества при помощи типа. Спасибо!
Вы называете множествами какие-то иные сущности, не те, что в математике.
В предметной области есть объекты: тарелка и ложка. Мы можем объединить их в множество А, помыслив их одним, — множеством.
Для моделирования тарелки мы используем букву а, для моделирования ложки — букву б. Для моделирования множества — букву Б. В итоге мы получили два набора:
тарелку, ложку и множество А,
а, б, и множество Б.
Второй набор объектов моделирует первый набор.
Первый набор можно дополнить связью между ложкой и тарелкой: «лежит в»
Эта связь может быть смоделирована во втором наборе разными способами.
при помощи надписи: «а лежит в б»,
при помощи элемента декартова произведения множества само на себя — элемента аб,
но во втором случае, имея в модели только элемент аб, мы не сможем восстановить смысл этого элемента. Поэтому для моделирования связи в предметной области мы используем связь «лежит в», которая является не элементом декартово произведения, а элементом множества триплетов, которые строятся на основании предиката: «ИКС „лежит в“ ИГРЕК» Заменяя ИКС и ИГРЕК на модели конкретных объектов, мы получаем модели конкретных связей.
Теория множеств предназначана для моделирования только узкого набора свойств объктов реального мира: количества/конечности/т.п.
В рамках тероии множеств все объекты в множестве полагаются различимыми ТОЛЬКО по возможности их отличить один от другого, см. «аксиома выбора» (Цермелло, если не ошибаюсь).
Для моделирования прозивольных отношений между объектами (в вашм примере отношения "… находится в ...") — теория множеств НЕ предназначена.
Для этого НАД теорией множеств настраивается алгебра и теория отношений.
Так же не предназначета теория мноижеств для моделирования структуры объектов.
Повторяю, у ТМ очень специальная задача: исследование количества/конечности/бесконечности. И не более того.
Теория множеств предназначана для моделирования только узкого набора свойств объктов реального мира: количества/конечности/т.п.
У меня другие сведения, извините. Я могу построить модель чего угодно. Например, задав функцию на множестве всех подмножеств, построить модель атрибута. Кратко о возможностях теории множеств см: http://akuklev.livejournal.com/1261552.html
Для этого НАД теорией множеств настраивается алгебра и теория отношений.
Алгебра построена на основе теории множеств. Верно, и значит, что все, что моделируется при помощи алгебры транзитом моделируется при помощи множеств.
Вы видели такое описание?
А тут все просто: мы строим агрегаты понятий. Одни понятия строятся на основе других. Все в математике построено на теории множеств и может быть выведено из нее. Удали ее и все развалится. То, что мы пользуемся теорией категорий, построенной на теории множеств, означает, что мы пользуемся теорией множеств, когда используем понятия из теории категорий. Тут ни прибавить, ни отнять. Я задался вопросом: что есть тип и атрибут с точки зрения теории множеств? Мог бы задать тот же вопрос, но с точки зрения теории категорий. Кстати, что это?
Алгебра построена на основе теории множеств. Верно, и значит, что все, что моделируется при помощи алгебры транзитом моделируется при помощи множеств.
Кстати нет. Раз некоторая алгебра это надстройка над теорией множеств, значит она содержит что-то еще, кроме теории множеств. Значит то, что можно смоделировать с помощью дополнительной части, нельзя смоделировать только теорией множеств. Верно только обратное утверждение — то что моделируется частью, можно смоделировать целым.
Нет. Новые концепты (аксиомы, базовые понятия) это новый соседний фундамент. Вы не сможете построить склад длиной 10 пролетов, имея фундамент только для одного пролета.
Если в теории множеств используется N понятий, а в новой алгебре N+M, вы не сможете выразить новые понятия M через старые N. Например, если вы используете только понятия тепловой физики, вы не сможете через них выразить понятие "электрическое поле".
Конкретная машина это не модель. Это конкретный материальный объект в конкретнык промежуток времени в конкретной области вселенной.
Модель это ее описание (той или иной степени абстракции/детализации).
И понятие «машина» в человечском сознании тоже модель.
Но модель не тождественна самому объекту.
При исчезновении объекта — модель не исчезнет.
При исчезновении модели — объект не исчезнет.
Свойства объекта «модель машины» и свойства объекта «конкретная машина» — различны.
Для конкретной машины может существовать множество различных моделей.
Поэтому, первичными в нашм мире являеются именно материлаьные объекты. Понятия лишь отображют и моделируют их.
Это область не психологии, а философии. Ваша интерпретация суперсубъективности мира — солипсизм. Весьма маргинальная ниша.
После смерти единственного человека животный мир эволюционирует и возникнет другое разумное существо, которое так же будет видеть и изучать сипульки. Не говоря о жителях иных миров.
З.Ы. Боюсь, что статья не сблизила математиков и обывателей.
Вот тут то же самое.
Ваше утверждение откуда-то из области между Поппером и Гегелем…
Хотя, ПМСМ, если продолжите в том же направлении, то психологи вами заинтересуются.
Как мы знаем, что состав множества может быть задан двумя способами:
- Непосредственным перечислением объектов, выбранных из какого-то множества.
- Правилами идентификации объектов, выбранных из какого-то множества.
Вы не замечаете здесь рекурсию?
Во втором способе описания модели объектов должны обладать одним общим атрибутом
"Обладание общим атрибутом" это только один из возможных вариантов задания "правила идентификации".
Тот и только тот объект из находящихся в комнате, который имеет желтый стикер, входит в состав множества А.
Тот и только тот объект, который является тарелкой или маркером, входит в состав множества А. Следовательно, первый способ это тоже высказывание в предикатах.
Автор этой затеи не заметил, что в результате логического вывода из этих двух высказываний мы получаем две тавтологии
Автор этой статьи не заметил, что признак вхождения в одно множество можно сделать признаком вхождения в другое множество, и почему-то решил, что это высказывание относится только к одному множеству, хотя причин для такого вывода в том обсуждении нет.
было предложено само вхождение во множество при помощи перечисления тоже сделать атрибутом: «входит в состав множества А»
Было предложено "вхождение во множество А" сделать атрибутом для определения что объект "входит в состав множества B". См. определения множеств натуральных и целых чисел.
Непосредственным перечислением объектов, выбранных из какого-то множества.
Правилами идентификации объектов, выбранных из какого-то множества.
Вы не замечаете здесь рекурсию?
Нет, потому что объекты для множества африканских слонов выбираются из множества слонов. То есть, дано: множество слонов, мы выбираем из этого множества подмножество при помощи перечисления объектов.
Вы не привели ни одного доказательства ошибки. Есть только неправильные понимания вами приведенных высказываний, что вы считаете ошибкой. Мне постоянно приходится пояснять, где именно вы поняли не так, что и приводит к длинным диалогам. При этом вы часто меняете тему и уходите от ответа. Как и сейчас, рекомендуя обратиться неизвестно к кому. Я не интересуюсь математикой, я указываю на логические ошибки в ваших рассуждениях. Математик не даст мне ответов, почему вы сказали так, а не иначе.
То есть, в ИС хранятся модели не всех элементов множества, а лишь тех, которые на данный момент зарегистрированы.
Вот тут мы подошли к интересному вопросу. Как в вашем подходе смоделировать регистрацию нового объекта? То есть введение нового объекта в рассмотрение и идентификацию его как элемента некоторого множества?
Как в вашем подходе смоделировать регистрацию нового объекта?
Кейсов моделирования столько, сколько хватит воображения. Рассмотрим один из них.
Объект учета регистрируется в ИС. Его тип на момент регистрации может быть известен с какой-то точностью. Самые общие типы — это объект, или множество. Объект учета должен быть отнесен либо туда, либо туда. Возможно, тип объекта учета известен чуть точнее, например, это — операция, или даже: это операция из тех, что происходят в отделе кадров. Мы регистрируем эту операцию. Затем по ходу ее выполнения\планирования\выяснения деталей мы уточняем мы выясняем все новые и новые подробности, касающиеся этой операции, появляются новые атрибуты и их значения (чего сделать нельзя, используй мы стандартные способы моделирования предметных областей). В какой-то момент мы узнаем про операцию столько, что мы можем переклассифицировать операцию как «операция по составлению трудового контракта». Допустим, что этого нам достаточно для анализа или синтеза. На этом моделирование не заканчивается. О дальнейшей судьбе модели можно писать долго, но это уже не тема сегодняшней беседы.
Ага, то есть типы позволяют моделировать предметную область. В прошлых статьях вы уверяли, что это не так, и поэтому языки программирования (и в частности ООП) не годятся для моделирования.
При этом надо различать тип объектов, и тип данных, который связан с этим типом объектов. Типы данных в ИС можно попытаться связать с типами объектов, но в ООП сделать это можно только в исключительных случаях, да и то — если модель не потребует расширения. В противном случае придется переписывать структуру классов.
Поэтому я утверждаю, что ООП не создано ни для моделирования типов объектов, ни для хотя бы сопоставления типов объектов типам данных.
Сопоставить типы данных и типы объектов можно в OWL.
Вот как раз "переписывать" и надо в исключительных случаях. Когда модель неправильная. В остальных случаях при расширении предметной области расширяется и соответствующая ей модель в информационной системе. У вас снова неправильные утверждения, на основе которых вы делаете неправильные выводы.
Добавление атрибута в описание типа нельзя назвать "перестройка модели классов". Появилось новое свойство в предметной области — добавили свойство в описание типа в программе. Изменения в программе отражают изменения в предметной области, значит модель правильная.
И неважно, как они существуют. Важно, что с помощью них можно задавать типы. Нигде в определении типа не сказано, что что-то где-то должно существовать отдельно. Следовательно, ООП позволяет моделировать предметную область.
В любой системе моделирования у вас будет место, где будут перечислены атрибуты некоторого типа, их имеющего.
Вы мыслите шаблоном: тип должен иметь атрибуты. Нет, не верно. Если сделать так, то модели станут нерасширяемые. Для этого надо отделить атрибуты от типов. Атрибуты не принадлежат типам.
В этом (и не только) сила OWL
Тип, имеющий атрибуты, должен иметь атрибуты. Тип, не имеющий атрибутов, не имеет атрибутов. Я не зря там приписку после запятой написал. Рекомендую вам задуматься над своими шаблонами.типа, их имеющегоВы мыслите шаблоном: тип должен иметь атрибуты
И все равно, наличие у типа атрибутов не запрещает нам добавлять в него новые атрибуты (расширять).
Атрибуты не принадлежат типам.Они им и в ООП не принадлежат. Понятие «атрибут» образуется на уровне компилятора, и там оно отделено от понятия «тип», и все вместе они отделены от описания самого типа в исходном коде. В описании типа атрибуты только перечислены. Так же как они будут перечислены в вашем OWL.
И все равно, способ описания модели модели чего-то никак не влияет не ее способность моделировать это что-то.
Допустим в предметной области есть только 3 понятия «слон», «загон», «зоопарк». В ООП языке будет 3 типа «Elephant», «Paddock», «Zoo». Всё. В предметной области понятия «атрибут» нет, значит и в коде программы, моделирующем эту предметную область, типа «Attirbute» или переменной с названием «attribute» или отдельного списка всех возможных атрибутов «attributeList» не будет.
В реальности есть высота и у слона, и у загона, и у, скажем, самого высокого здания зоопарка. Но у объектов в ООП «Elephant», «Paddock», «Zoo», пока не ввели нет высоты.
Объект в ООП не имеет отношения к объектам реальности. В самом начале декларировалось именно соответствие, а по факту — нет. Из-за этого и мисандестуд.
Одна из тех мыслей, что я активно пытаюсь донести, — это то, что ООП не создано для моделирования реальности. Точнее, его пытаются натянуть на эту задачу, но получается плохо.
Отдельно хочу обратить внимание, что мы не никогда рассматриваем признаки как «просто какая-то высота», мы всегда подразумеваем «высота (чего)».
Отдельно хочу обратить внимание, что мы не никогда рассматриваем признаки как «просто какая-то высота», мы всегда подразумеваем «высота (чего)»
Вот я про это и говорю, что как только высота чего, то модель перестает удовлетворять требованиям расширяемости. В OWL атрибут не бывает чего-то. Есть область значений и область определений атрибута. Область определения — это те объекты, которые подвергаются классификации при помощи значений атрибута. Область значений — множество, элементами которого могут быть значения. атрибута. Но сам атрибут существует отдельно от «чего-то». И это принципиальное от отличие ООП, в котором из-за этого нельзя построить расширяемые модели. И именно поэтому в OWL отказались от этого интуитивного, но неверного решения — говорить атрибут чего-то.
Есть область значенийВот именно поэтому «цвет» пикселя черно-белого монитора и «цвет» лепестка растения это разные атрибуты. И область значений зависит только от объекта, так как определяется его характеристиками. Потому что даже у двух черно-белых мониторов будет свой набор оттенков. Поэтому отдельного атрибута «цвет» нет, есть «цвет чего-то».
И это принципиальное от отличие ООП, в котором из-за этого нельзя построить расширяемые модели.Да что мешает-то в тип «Слон» добавить новый атрибут «длина хобота»? Elephant { weight; height; trunkLength; } Просто взял и расширил.
Вот именно поэтому «цвет» пикселя черно-белого монитора и «цвет» лепестка растения это разные атрибуты.
В ООП — верно, но в OWL — это будет один атрибут. Или разный, если нам зачем-то это понадобится. Но, если разный, мы уже не сможем сравнить цвет пикселя и цвет лепестка. Или нам придется лезть в код и моделировать это вручную, а мы этого не хотим. Прелесть онтологии в том, что не надо кодить, надо моделировать. И, если кто-то замоделирует цвета разными атрибутами, то он сам дурак, — теперь это разные атрибуты и сравнивать их значения без создания костылей из кода уже нельзя.
И да, сравнивать значения так нельзя. Значения сравниваются с учетом единиц измерения, которые и задают диапазон возможных значений. И это не костыли, это физические свойства окружающего мира. Нельзя сравнивать мощность в ваттах с мощностью в джоулях, или ньютоны с метрами. Надо сначала сделать преобразование (если оно возможно). Вот и у цвета пикселя свой диапазон. И перед сравнением с цветом лепестка нужно будет перевести его в RGB или в общую для них третью единицу.
Вот я про это и говорю. В предметной области просто поменялось название. Пусть даже не "Оттенок", а "Уровень белого", так будет более выражено. Все единицы измерения и характеристики у всех существующих объектов остались те же. А у вас в модели надо отвязать атрибут "Цвет", создать новый, привязать его, скопировать значения. Изменения в модели не соответствуют изменениям в предметной области. Значит модель неправильная.
Это делается путем сохранения старого атрибута — ведь мы не имеем права просто удалить данные, внесенные другими пользователями. Если сдвинуть временную шкалу в прошлое, мы по-прежнему будем видеть цвета на мониторах. Однако, если мы говорим о будущем, то, после переноса данных на основе правил, которые мы сделаем, не прибегая к кодированию, у нас у монитора появится новый атрибут «Оттенок» и его значения. При этом мы сохраним обе точки зрения, которая была до ввода нового атрибута и после. Более того, на основе обратного правила, мы можем узнать, как выглядело бы описание монитора в старых терминах и сможем вернуться к ним, если новые не приживутся.
В программировании модель это код. Вы в принципе не можете поменять модель, не изменяя код. Для этого надо кодом описать модель модели, чтобы это все было можно сделать во время работы программы. Только это уже не будет модель предметной области, модель предметной области надо будет создавать вручную после запуска программы. Так же как вы делаете в редакторе OWL. Модель в оперативной памяти редактора — это аналог написанного кода. Добавление свойства в редакторе — это аналог добавления свойства в коде. Если вы требуете не менять код при добавлении атрибута, значит в OWL вы не должны добавлять его через редактор.
То, что черно-белый монитор не может засветиться желтым, не относится к атрибуту.
Черно-белый монитор так называется из-за свойств пикселей. Значит атрибут "цвет" относится к пикселю, а не к монитору. Кстати, если монитор у вас имеет атрибут "цвет", который означает "цвет пикселя", то вы не сможете добавить атрибут "цвет", который обозначает "цвет корпуса". Снова появляется связь "цвет (чего)".
Это и есть часть расширяемости модели.
Это не часть расширяемости, это заранее заложенный запас. Модель у вас не расширяется. В ней сразу заложено, что можно создать черно-белый монитор с желтым цветом. Только предметной области это не соответствует. А если завтра окажется, что он железо притягивать начнет? А у вас там только цвет задан.
Вы в принципе не можете поменять модель, не изменяя код.
Нет, не верно. Это одна из прелестей OWL, в котором и модели объектов и модели правил записываются одинаково. Вы же не меняете код, когда создаете модель нового объекта, правда вы меняете код, когда создаете модель нового класса, или новый метод.
Мы создаем новые классы и новые методы, не прибегая к кодированию так же, как вы создаете модели объектов
Нет, не верно
Я говорил про ООП, а не про принципиальную невозможность. Еще раз, в OWL модель в оперативной памяти, там вы можете ее менять, не меняя код самого редактора, в коде редактора этой модели вообще нет. Но добавляя новое свойство вы ее меняете, меняете значения в оперативной памяти. В ООП модель в коде, чтобы ее поменять, естественно надо менять код, менять символы в файлах. В обоих случаях чтобы изменить модель надо менять там, где она хранится.
И неважно, отдельно у нас хранятся свойства или накопированы в каждый тип. Важно то, что это в обоих случаях моделирует саму предметную область. Если термины "тип" и "атрибут" в предметной области не существуют, то описывать их и их взаимосвязь в модели не надо.
Что конкретно вы не можете сделать ООП? Добавить атрибуты можно, удалить можно. В OWL меняется интерфейс (списки, стрелочки, или что там у вас), так как модель задается списками и стрелочками, в ООП меняется код, потому что модель задается кодом. Но это тоже модель.
Кодирование на ассемблере, на ООП языке, на ФП языке, на каком-то DSL или метаDSL или тасканием квадратиков мышкой — это не принципиально. Модель или может быть реализована в рамках архитектуры современных компьютеров или нет (граничные случаи, связанные с физическими ограничениями не рассматриваем).
На ООП-языках можно представить любую модель, которую можно реализовать на популярных архитектурах. В каких-то случаях модель будет лаконичной, в каких-то понятия и связи предметной области надо будет выражать через конструкции языка громоздко, реализовывая самостоятельно то, что в языке и(или) ООП в целом не реализовано, а в каких-то обходя средствами языка ограничения этого же языка. Грубо, те же паттерны — это стандартные способы реализации того, что в языке не предусмотрено или даже запрещено.
В ООП мы вполне можем создать типы и атрибуты в ваших терминах, со связью 0..N:0..N. И типы, и атрибуты будут классами и(или) объектами в терминах ООП, связи между ними будут храниться в коллекциях объектов третьего типа и т. п., и вообще вся модель будет загружаться из БД или Интернета, но её термины, её метамодель будет написана на ООП-языке. А может на ФП. А может на ассемблере. А может на ООП без явного создания средств метамоделирования, простым или не очень кодом.
И не надо путать моделирование как задание соответствия (mapping) объекта в одной ИС объекту в другой ИС, и моделирование как описание структуры в понятиях более высокого уровня абстракции.
Я понятия не имею, что есть в коде, но в нашем сознании есть атрибут высота. Этот атрибут должен моделироваться, если мы моделируем предметную область.
Не должен, если в моделируемом контексте предметной области его наличие и(или) значение игнорируется. Кстати, это одна из самых частых ошибок в моделировании: есть что-то в сознании — переносим в модель, не задумываясь а нужно ли оно там, будет ли использоваться.
Типы объектов — это часть нашего представления о предметной области, и они требуют моделирования.
Зачем это? Нам не надо моделировать наше представление о предметной области, нам надо моделировать саму предметную область.
Давно уже хочу сказать, но как-то повода не было. Вы ошибочно разделяете понятия "информационная система" и "наше представление". Мозг человека это тоже информационная система. Есть внешние объекты и их модель в некоторой информационной системе. Всё. Мозг человека умеет производить анализ данных и выделять типы объектов. Компьютер так не умеет, и типы ему надо задавать. В результате и там и там получается модель предметной области.
Есть внешние объекты и их модель в некоторой информационной системе
Нет внешних объектов, есть модель пространства и времени в нашем сознании. (это, если допустить существование пространства и времени). Поэтому все, что мы делаем, мы делаем на одном поле — в нашем сознании. Там появляются модели пространственно-временных объектов, там же — их модели (модели моделей). Поэтому нет объектов, есть только модели.
Зачем моделировать типы? Понятия не имею, но, если понадобится это сделать, я сформулировал требования к моделлеру.
Мы строим модель окружающего мира на основе входной информации. Входная информация появляется не сама по себе, есть причины ее возникновения. Внешние по отношению к информационной системе причины. Можете не называть их объектами, сути это не меняет. В информационной системе "наше представление" мы выделяем типы (и другие сущности), на основе чего строим модель предметной области. Если эти типы (и другие сущности) заложить в информационную систему "компьютер", в ней тоже будет модель предметной области.
Зачем моделировать типы? Понятия не имею
Типы это средство моделирования нами предметной области. Я имел в виду, что модель средства моделирования (следующий уровень абстракции) делать не надо. А вы, видимо, под выражением "моделировать типы" имеете в виду их задание в другой информационной системе. Задавать типы в ООП можно.
Воспользуйтесь категорией множеств и задайте шкалу над ней.
И никакого множества множеств и прочих парадоксов
К счастью, на хабре запостили очень простой и понятный учебник для начинающих: https://github.com/George66/Textbook
P.S. Множества с непрерывностью не работают, с непрерывностью работает топология — так что вам надо в том направлении копать, чтобы подобрать подходящие абстракции.
Множества с непрерывностью не работают, с непрерывностью работает топология
Этот тезис я, увы, понять не могу. Про непрерывность можно говорить на множестве, где введено понятие расстояния. И это делается на первом курсе МФТИ при изучении метрических пространств. Я не вижу проблем с понятием непрерывности.
Теория категорий НЕ сводитсдя к теории множеств.
ТК была изначально разработана как альтернатива теории множеств в качестве основания метематики, но не содержащая парадоксов.
Поэтому ТК предлагает другой «язык математики», алтернативный «языку» теории множеств.
Одно из напревлений исследований ТК — построение и исследование категории, обладающей свойствами категории множеств (топосы).
ЕМНИП, в тех разделах ТК и ТМ, что мне известны понятия «атрибут» нет.
Это понятие возникает в информационном моделировании при выделении некоего домена и соотнесения ему имени.
За более детальным определением мозете обратится (например) к книшшке Плоткина (название что-то вроде «домены, множества, категории»), там это хорошо разобрано с чисто математической т.з.).
В теории программировании это поняли еще в шестидесятые годы, когда родился лозунг «типы это не множества» и началась разработка «теории абстрактных типов данных».
Методы и способы, которыми вы определяете и выделяете объекты, типы и атрибуты в предметной области составляют существенную часть парадигмы моделирования.
Меняете способ выделения объектов или типов, или атрибутов (или чего еще там у вас будет) — и получаете другую парадигму.
Теории множеств недостаточно для информационного моделирования, поскольку для получения сколь-нибудь нетривиальной модели нужно иметь инварианты, операции, предикаты. Для этого нужно иметь предикаты. Для них нужно имерь возможность определять отношения и по крайней мере два типа/домена. А для этого нужно… И так далее.
Т.е. теория множеств требует расширений для возможности построения ваших моделей. Расширить ее можно разными способамим, но все эти способы должны удовлетворять определнному набору условий/признаков (определяемых математически), что б давать в результате формальную модель, допускающую непротиворечивые интерпретации.
То, КАК МОЖНО раширить теорию множеств для построения информационных моделей уже хорошо изучено и описано.
Пока же, извините, ваши построения читаются как откровения человека, освоившего вводные главы в популярной книжке.
Мы моделируем предметные области. В них есть объекты определенных типов, типы и атрибуты
Не "в них есть", а "мы выделяем в них". Объективно в предметных областях как правило нет понятий объектов, типов и атрибутов. Их вводят при построении модели предметной области. Или не вводят, вводя, например, понятия класса, инстанса класса, свойств и методов. Или таблиц, их строк и столбцов. Вводим подобные абстракции мы, аналитики или исполняющие их роль на проекте, во время анализа предметной области, во время построения её модели.
Да и вообще, как тогда определять множество, состоящее из реальных объектов? Они же не существуют вечно. Получается, множества для моделирования реальных объектов не подходят.
Как тогда определить тип «африканский слон»?
Да и вообще, как тогда определять множество, состоящее из реальных объектов? Они же не существуют вечно.
Посмотрите, как моделируют множества в 4D парадигме. Я растолковал эту парадигму в начале статьи. Много писал об этом ранее. Время — это еще одно измерение, мы живем в 4-х мерном мире. В нем нет изменений, изменения у нас в сознании. Уберите эту мысль и научитесь моделировать реальные множества. У нас есть специалист по этой теме: habrahabr.ru/users/vvagr/ Виктор Агроскин
Либо покажите, как применить вашу теорию к этому примеру. В начале статьи вы предлагаете заменять объекты какими-то их частями, то есть меняете правило. Но задача стоит работать с множеством объектов, а не других частей.
Изменение только «знания о составе множества» подразумевает, что родившийся (после задания этого множества) слон входил в состав множества еще до своего рождения. Это в принципе неправильно, так как предполагает, что будущее (относительно момента задания множества) предопределено, и противоречит вашим другим тезисам, где вы говорили, что будущее вероятностно и имеет много вариантов развития.
«Знание о множестве» это и есть «множество». Потому что иначе нужно предполагать существование множества вне нашего мышления, как реальный объект.
Нам необязательно знать точный состав множества, чтобы им оперировать, достаточно ссылки на правило задания множества или ссылки на перечисление, чтобы описать все необходимые для модели операции над этим множеством. Уточнение состава множества будет происходить непосредственно в момент когда нужно получить результат, зависящий от состава множества.
И, да, слон, родившийся после задания множества правилом "все слоны мира", входит в состав этого множества. На момент задания этого правила мы имеем в виду и таких, ещё не родившихся слонов. Если у нас, например, определена операция "пометить всех живых слонов", то уточнение состава множества "все слоны" и отсеивание из них неживых будет происходить в момент исполнения операции, которая может быть исполнена в момент времени, сколь угодно удаленный в будущее от момента задания множеством правила и операции.
Нам необязательно знать точный состав множества, чтобы им оперировать
Правильно, оперировать мы будем множеством, а не объектами, входящими в его состав. Мы поэтому его и задаем, чтобы работать с ним как с единым целым, а не с отдельными объектами. Постоянно описание множества (правило), но не его состав.
Формально множество, определенное правилом "все слоны мира" включает, и слонов ещё не родившихся, и слонов уже погибших. На практике чаще используется множество "все известные нам живые слоны мира на данный момент времени", реже — на какой-то момент в прошлом, ещё реже — прогнозы о составе множества (как правило количественные метрики) на какой-то момент времени в будущем. Либо, как вариант, множества типа "все известные нам слоны мира на момент запуска отчёта в будущем".
Формально наверно да, но это не столь важно. Я о том, что можно придумать правило, зависящее от времени, а раз множество задается правилом, то его состав меняется. Либо это не множество, а что-то другое, значит теория множеств здесь не подходит. Можно как в ФП считать, что это просто разные множества, но это будет неправильное моделирование, так как мы в нашем мышлении считаем, что это один и тот же объект.
В таком случае множество слонов сегодня и множество слонов завтра это разные множества, и мы не можем с ними работать как с одним объектом. Мы в принципе не сможем работать с ними в реальности, так как ни одно действие не выполняется мгновенно.
Есть загон, в нем на данный момент 3 слона. Сколько элементов во множестве "множество слонов в этом загоне" в вашей 4D модели?
У множества может меняться как состав (в разные моменты времени к множеству могут относится разные объекты, правило задания множества может быть простой функцией от времени), так и правило его задания (правило задания множества может быть функцией высшего порядка от времени, возвращающей разные правила в разные моменты времени).
Как мы знаем, что состав множества может быть задан двумя способами:
Непосредственным перечислением объектов, выбранных из какого-то множества.
Правилами идентификации объектов, выбранных из какого-то множества.
Как же так? Почему правило идентификации не может быть функцией от времени?
Потому что получившийся "объект" ведет себя не как множество. На нем не задано отношение принадлежности. Но мы его можем мыслить как функцию, которая результатом будет иметь множество.
Но, похоже, уважаемый автор не понимает (или понимает, но не хочет никому говорить?), что теория множеств не универсальна. Даже, напротив.
В том смысле, что она изначально создавалась как иструмент для исследования достаточно специального класса задач, интересных «фундаментальным математикам».
А именно задач, связанных с понятиями конечности/бесконечности/отображения/количества/меры.
Все. Для моделеривания объектов реального мира, их структуры/поведения/взаимодействия/использования/т.п. — это теория изначально не предназначалась. От слова «совсем».
Вы, естественно, в полном праве иметь свою точку зрения. Она интересна, но… Но, право слово, стоит хотя бы попытаться «взойти на плечи гигантов».
Мне, к примеру, очень помогли книшшки Гильтерта по матлогике.
Метематика оперирует абстракциями.
Если вы заявляете это, то должны легко дать определение понятию абстракция. Дайте, пожалуйста
Писать определение абстракции мне, честно говоря, лениво. Если вы и его не знаете, то… бяда.
Формальная система есть неоднородная совокупность набора первичных термов («слов»), набора правил композиции термов, набора правил вывода и набора предикатов (который можно раделить на отношения и операции).
Наборы в простейшем случае можно полагать не более, чем счетными множествами.
Эта часть определяет «синтаксическую» компоненту семиотической системы.
Для задания семантической компоненты семиотической системы нужно определить «область интерпретации» и «правила интепретации»…
Синтаксически атрибуты суть разбиения на ис-ходном множетве термов. Синтаксически типы определяются как совокупность подмножествс термов и выделенного набора предикатов.
Для атрибутов и типов правила интерпретации должны обладать определенным исвойствами.
Слушайте, это все по многу раз описывалось к учебниках по представлению знаний и моделированию, неуж-то нужно перепечатывать азы?!..
Вам это тут уже говорено не один раз.
Число нуль (хотя это и не относится к обсуждаемому) определяется как класс множеств, изоморфных пустому множеству. Это в рамках теории множеств.
В общей алгебре нуль опредлеяется по-другому, но есть доказательство эвивалентности этих определений.
Книжка, которую надо б почтать перед началом разработки информационных моделей:
«Universal Algebra, Algebraic Logic, and Databases» by Plotkin B.
Вроде бы, издавалссь на русском.
В инженерном деле, науке вообще и математике в частности имеют значение совсем другие интеллектуальные категории…
Разумеется, при всем том вы можете оставаться при своем мнении, и точно так же раумеется, что это мнение без доказательства обратного может быть неверным.
Естественно, что в OWL атрибут определяется именно так, потому как OWL и разрабатывался с оглядкой на математические основы представления знаний.
Только в этой книге значения атрибута не образуют множества В моем определении разделение множества на подмножества при помощи значений атрибута более общее, нежели просто значение функции. Я всегда был недоволен делением атрибутов на качественные и количественные, потому что при таком делении не делалось обобщение, — не было общего определения, которое было бы удовлетворительным и для того и для другого случая. Мне удалось их обобщить. И, самое веселое, что при этом атрибут стал рядом с типом, отличаясь от него всего одним словом: тип выделяет объекты в группу, а атрибут разделяет по группам. Согласитесь, что такое понимание более глубокое и простое.
Понятия: множество, тип, атрибут