Как стать автором
Обновить

Комментарии 124

Используя в нашей работе OWL...

Я несколько не в теме — а что значит "OWL"?

Краткое введение можно почитать на нашем сайте: http://trinidata.ru/files/SemanticIntro.pdf

Просканировав наискось 165 стр. краткого введения, пришел к выводу, что OWL — это Web Ontology Language.

Сорри, я думал под вопросом, что значит OWL, имелось ввиду его краткое описание.
Ваша основная методологическая ошибка — во фразе «моделирование подмножества с помощью типа». Вы не разделяете уровни моделирования. Есть уровень теории множеств. Над ним вы можете строить типы (онтологические) с именами, можете — мереологию с отношением часть-целое, можете — темпоральную логику. Можете математические графы, а над ними — описания систем. Но это моделирование имеет направление — снизу вверх, от абстрактного к конкретным потребностям.

То есть основной объём статьи посвящен моделированию типов, много чего понаписано. Но это никак не дополняет и не развивает математическую теорию множеств.
В качестве базовых объектов выбраны объекты, связи и множества. Это то, как мы моделируем мир с точки зрения теории множеств.
Объект (машина) — это тоже модель, модель пространственно-временной части вселенной. Эта модель существует в нашем сознании до тех пор, пока мы имеем понятие об автомобилях. Потеряв это понятие, мы теряем и объект. Никто уже не сможет сказать: это автомобиль, если никто не владеет понятием об автомобилях. Понятие — это тип. Поэтому первичным в нашем мире являются понятия об объектах. На основе этих понятий мы строим в нашем сознании объекты, связи и множества.То есть, первичное понятие — тип, вторичное — объект и множества. Все верно.

Правильно было бы говорить о порождении типом множества объектов, а не о моделировании множества при помощи типа. Спасибо!
В математике первичны множества и элементы. Уже связи определяются через декартово произведение множеств.

Вы называете множествами какие-то иные сущности, не те, что в математике.
Мы все время путаем математические объекты, которые есть объекты, не связанные с предметной областью, и объектами, которые эти математические объекты, моделируют.

В предметной области есть объекты: тарелка и ложка. Мы можем объединить их в множество А, помыслив их одним, — множеством.

Для моделирования тарелки мы используем букву а, для моделирования ложки — букву б. Для моделирования множества — букву Б. В итоге мы получили два набора:

тарелку, ложку и множество А,

а, б, и множество Б.

Второй набор объектов моделирует первый набор.

Первый набор можно дополнить связью между ложкой и тарелкой: «лежит в»
Эта связь может быть смоделирована во втором наборе разными способами.

при помощи надписи: «а лежит в б»,
при помощи элемента декартова произведения множества само на себя — элемента аб,

но во втором случае, имея в модели только элемент аб, мы не сможем восстановить смысл этого элемента. Поэтому для моделирования связи в предметной области мы используем связь «лежит в», которая является не элементом декартово произведения, а элементом множества триплетов, которые строятся на основании предиката: «ИКС „лежит в“ ИГРЕК» Заменяя ИКС и ИГРЕК на модели конкретных объектов, мы получаем модели конкретных связей.
У вас, как говорено выше, методологическая ошибка.
Теория множеств предназначана для моделирования только узкого набора свойств объктов реального мира: количества/конечности/т.п.
В рамках тероии множеств все объекты в множестве полагаются различимыми ТОЛЬКО по возможности их отличить один от другого, см. «аксиома выбора» (Цермелло, если не ошибаюсь).
Для моделирования прозивольных отношений между объектами (в вашм примере отношения "… находится в ...") — теория множеств НЕ предназначена.
Для этого НАД теорией множеств настраивается алгебра и теория отношений.
Так же не предназначета теория мноижеств для моделирования структуры объектов.
Повторяю, у ТМ очень специальная задача: исследование количества/конечности/бесконечности. И не более того.
Теория множеств предназначана для моделирования только узкого набора свойств объктов реального мира: количества/конечности/т.п.

У меня другие сведения, извините. Я могу построить модель чего угодно. Например, задав функцию на множестве всех подмножеств, построить модель атрибута. Кратко о возможностях теории множеств см: http://akuklev.livejournal.com/1261552.html
Для этого НАД теорией множеств настраивается алгебра и теория отношений.

Алгебра построена на основе теории множеств. Верно, и значит, что все, что моделируется при помощи алгебры транзитом моделируется при помощи множеств.
(Со вздохом) Это примерно то же самое, что утверждать: раз все состоит из элементарных частиц, то весь мир описываетсдя квантовой механикой…
Вы видели такое описание?
Не совсем, мы не знаем, из чего состоит мир. И состоит ли он вообще.

А тут все просто: мы строим агрегаты понятий. Одни понятия строятся на основе других. Все в математике построено на теории множеств и может быть выведено из нее. Удали ее и все развалится. То, что мы пользуемся теорией категорий, построенной на теории множеств, означает, что мы пользуемся теорией множеств, когда используем понятия из теории категорий. Тут ни прибавить, ни отнять. Я задался вопросом: что есть тип и атрибут с точки зрения теории множеств? Мог бы задать тот же вопрос, но с точки зрения теории категорий. Кстати, что это?
Алгебра построена на основе теории множеств. Верно, и значит, что все, что моделируется при помощи алгебры транзитом моделируется при помощи множеств.

Кстати нет. Раз некоторая алгебра это надстройка над теорией множеств, значит она содержит что-то еще, кроме теории множеств. Значит то, что можно смоделировать с помощью дополнительной части, нельзя смоделировать только теорией множеств. Верно только обратное утверждение — то что моделируется частью, можно смоделировать целым.

Верно. Добавляя новые концепты, мы строим здание. Но фундамент у него все тот же. И все, что мы моделируем, можно построить на нем. Об этом моя статья — попытка построить определение типа и атрибута на основании теории множеств.

Нет. Новые концепты (аксиомы, базовые понятия) это новый соседний фундамент. Вы не сможете построить склад длиной 10 пролетов, имея фундамент только для одного пролета.


Если в теории множеств используется N понятий, а в новой алгебре N+M, вы не сможете выразить новые понятия M через старые N. Например, если вы используете только понятия тепловой физики, вы не сможете через них выразить понятие "электрическое поле".

Хотя, я подумал, что сам попал в стандартную ловушку шаблонного мышления. Перед глазами у меня всегда анализ: когда мы на основании типа объектов создаем объекты. В статье я вел разговор про другое направление — про синтез. Это, когда на основании множества объектов мы создаем тип объекта, — обобщаем признаки объектов в группе. И тогда все верно: множество моделируется при помощи типа.
Нет.
Конкретная машина это не модель. Это конкретный материальный объект в конкретнык промежуток времени в конкретной области вселенной.
Модель это ее описание (той или иной степени абстракции/детализации).
И понятие «машина» в человечском сознании тоже модель.
Но модель не тождественна самому объекту.
При исчезновении объекта — модель не исчезнет.
При исчезновении модели — объект не исчезнет.
Свойства объекта «модель машины» и свойства объекта «конкретная машина» — различны.
Для конкретной машины может существовать множество различных моделей.

Поэтому, первичными в нашм мире являеются именно материлаьные объекты. Понятия лишь отображют и моделируют их.
Мы уходим в область психологии. Мне не хочется туда углубляться сейчас, благо, что я в свое время написал статьи на эти темы. И статьи эти были проверены психологами. Так что могу заверить — машина не существует вне нашего сознания. Это легко доказать: если у нас есть всего один человек на земле, который кругом видит сипульки, но никто больше не знает ни термина сипулька, ни то, как они выглядят, то после его смерти ни один субъект не сможет найти ни одну сипульку.
По-моему психологии явно не допроверили теорию сипулек.

Это область не психологии, а философии. Ваша интерпретация суперсубъективности мира — солипсизм. Весьма маргинальная ниша.
После смерти единственного человека животный мир эволюционирует и возникнет другое разумное существо, которое так же будет видеть и изучать сипульки. Не говоря о жителях иных миров.

З.Ы. Боюсь, что статья не сблизила математиков и обывателей.
Естественно, не сблизила. Что будет, если биологию станет полуляризировать человек, честно признающий что он «не очень хорошо владеет языком биологии»?
Вот тут то же самое.
Боюсь, что другое разумное существо поймет, что все живые существа — это один единый организм, включающий в себя и неживое. И не станет делить мир на части, а будет наслаждаться единством. Мы не знаем, до чего еще дойдет эволюция, но вероятность того, что она придет к идее сипульки настолько мала, что равна вероятности того, что в нашей галактике есть человек, похожий на меня.
Это не пихология, а философия.
Ваше утверждение откуда-то из области между Поппером и Гегелем…
Хотя, ПМСМ, если продолжите в том же направлении, то психологи вами заинтересуются.
Все ж таки, если «от абстрактного — к конкретному», то это «сверху вниз».
Как мы знаем, что состав множества может быть задан двумя способами:
  1. Непосредственным перечислением объектов, выбранных из какого-то множества.
  2. Правилами идентификации объектов, выбранных из какого-то множества.

Вы не замечаете здесь рекурсию?


Во втором способе описания модели объектов должны обладать одним общим атрибутом

"Обладание общим атрибутом" это только один из возможных вариантов задания "правила идентификации".


Тот и только тот объект из находящихся в комнате, который имеет желтый стикер, входит в состав множества А.

Тот и только тот объект, который является тарелкой или маркером, входит в состав множества А. Следовательно, первый способ это тоже высказывание в предикатах.


Автор этой затеи не заметил, что в результате логического вывода из этих двух высказываний мы получаем две тавтологии

Автор этой статьи не заметил, что признак вхождения в одно множество можно сделать признаком вхождения в другое множество, и почему-то решил, что это высказывание относится только к одному множеству, хотя причин для такого вывода в том обсуждении нет.


было предложено само вхождение во множество при помощи перечисления тоже сделать атрибутом: «входит в состав множества А»

Было предложено "вхождение во множество А" сделать атрибутом для определения что объект "входит в состав множества B". См. определения множеств натуральных и целых чисел.

Как мы знаем, что состав множества может быть задан двумя способами:

Непосредственным перечислением объектов, выбранных из какого-то множества.
Правилами идентификации объектов, выбранных из какого-то множества.

Вы не замечаете здесь рекурсию?

Нет, потому что объекты для множества африканских слонов выбираются из множества слонов. То есть, дано: множество слонов, мы выбираем из этого множества подмножество при помощи перечисления объектов.

Вот именно поэтому признак "входит в состав множества А" не является тавтологией при задании правила, определяющего множество.

Мне уже немного затратно перечислять логические ошибки, которые вы допускаете в своих рассуждениях. Я еще раз рекомендую обратиться к математику, если вам интересна эта тема.

Вы не привели ни одного доказательства ошибки. Есть только неправильные понимания вами приведенных высказываний, что вы считаете ошибкой. Мне постоянно приходится пояснять, где именно вы поняли не так, что и приводит к длинным диалогам. При этом вы часто меняете тему и уходите от ответа. Как и сейчас, рекомендуя обратиться неизвестно к кому. Я не интересуюсь математикой, я указываю на логические ошибки в ваших рассуждениях. Математик не даст мне ответов, почему вы сказали так, а не иначе.

Вы постоянно дрейфуете в своих тезисах, не замечая этого. От этого много суеты, но мало толку.
То есть, в ИС хранятся модели не всех элементов множества, а лишь тех, которые на данный момент зарегистрированы.

Вот тут мы подошли к интересному вопросу. Как в вашем подходе смоделировать регистрацию нового объекта? То есть введение нового объекта в рассмотрение и идентификацию его как элемента некоторого множества?

Как в вашем подходе смоделировать регистрацию нового объекта?

Кейсов моделирования столько, сколько хватит воображения. Рассмотрим один из них.

Объект учета регистрируется в ИС. Его тип на момент регистрации может быть известен с какой-то точностью. Самые общие типы — это объект, или множество. Объект учета должен быть отнесен либо туда, либо туда. Возможно, тип объекта учета известен чуть точнее, например, это — операция, или даже: это операция из тех, что происходят в отделе кадров. Мы регистрируем эту операцию. Затем по ходу ее выполнения\планирования\выяснения деталей мы уточняем мы выясняем все новые и новые подробности, касающиеся этой операции, появляются новые атрибуты и их значения (чего сделать нельзя, используй мы стандартные способы моделирования предметных областей). В какой-то момент мы узнаем про операцию столько, что мы можем переклассифицировать операцию как «операция по составлению трудового контракта». Допустим, что этого нам достаточно для анализа или синтеза. На этом моделирование не заканчивается. О дальнейшей судьбе модели можно писать долго, но это уже не тема сегодняшней беседы.

Ага, то есть типы позволяют моделировать предметную область. В прошлых статьях вы уверяли, что это не так, и поэтому языки программирования (и в частности ООП) не годятся для моделирования.

Типы объектов — это часть нашего представления о предметной области, и они требуют моделирования. Требования к моделированию типов я сформулировал в статье. Но не все, конечно. Конечно, в ООП нет возможности моделировать типы объектов.

При этом надо различать тип объектов, и тип данных, который связан с этим типом объектов. Типы данных в ИС можно попытаться связать с типами объектов, но в ООП сделать это можно только в исключительных случаях, да и то — если модель не потребует расширения. В противном случае придется переписывать структуру классов.

Поэтому я утверждаю, что ООП не создано ни для моделирования типов объектов, ни для хотя бы сопоставления типов объектов типам данных.

Сопоставить типы данных и типы объектов можно в OWL.

Вот как раз "переписывать" и надо в исключительных случаях. Когда модель неправильная. В остальных случаях при расширении предметной области расширяется и соответствующая ей модель в информационной системе. У вас снова неправильные утверждения, на основе которых вы делаете неправильные выводы.

То, что модель классов в ООП рпи расширении может потребовать перестройку модели классов — теоретически доказуемо. Хотя бы потому что атрибуты в ООП не отделены от классов. В OWL атрибуты от классов отделены.

Добавление атрибута в описание типа нельзя назвать "перестройка модели классов". Появилось новое свойство в предметной области — добавили свойство в описание типа в программе. Изменения в программе отражают изменения в предметной области, значит модель правильная.

Отделение атрибута от класса означает, что атрибуты, методы и классы существуют отдельно друг от друга, а не вместе, как в ООП,
Не знаю, что вы подразумеваете под словами «существовать вместе» и «существовать отдельно». В любой системе моделирования у вас будет место, где будут перечислены атрибуты некоторого типа, их имеющего. Описание понятий «атрибут», «метод» и «класс» (тип) и их взаимосвязей это модель модели, и для описания самой предметной области она не нужна. В языках программирования эта модель находится в компиляторах.

И неважно, как они существуют. Важно, что с помощью них можно задавать типы. Нигде в определении типа не сказано, что что-то где-то должно существовать отдельно. Следовательно, ООП позволяет моделировать предметную область.
В любой системе моделирования у вас будет место, где будут перечислены атрибуты некоторого типа, их имеющего.

Вы мыслите шаблоном: тип должен иметь атрибуты. Нет, не верно. Если сделать так, то модели станут нерасширяемые. Для этого надо отделить атрибуты от типов. Атрибуты не принадлежат типам.
В этом (и не только) сила OWL

типа, их имеющего
Вы мыслите шаблоном: тип должен иметь атрибуты
Тип, имеющий атрибуты, должен иметь атрибуты. Тип, не имеющий атрибутов, не имеет атрибутов. Я не зря там приписку после запятой написал. Рекомендую вам задуматься над своими шаблонами.

И все равно, наличие у типа атрибутов не запрещает нам добавлять в него новые атрибуты (расширять).

Атрибуты не принадлежат типам.
Они им и в ООП не принадлежат. Понятие «атрибут» образуется на уровне компилятора, и там оно отделено от понятия «тип», и все вместе они отделены от описания самого типа в исходном коде. В описании типа атрибуты только перечислены. Так же как они будут перечислены в вашем OWL.

И все равно, способ описания модели модели чего-то никак не влияет не ее способность моделировать это что-то.
Я не понимаю ваши тезисы. Я смотрю описание классов в ООП и вижу, что в них определены атрибуты и методы. Я не вижу определение в ООП атрибутов без классов, не вижу определения методов вне классов. Как в ООП можно создать атрибут, или метод без создания класса? Это уже не ООП, это — функциональное программирование, в котором эта проблема решена, и метод отделен от класса.
Зачем его создавать в ООП? Создание атрибута и описание его отношения с типом это модель модели. Для моделирования предметной области нужно описание типов. Если в предметной области понятия «атрибут» нет, то и в описании типов ООП его быть не должно.
Я не понимаю вас. Извините. Напишите свое видение в статье и мы ее обсудим. Если ООП декларирует описание типов и атрибутов, а вы настаиваете, что оно этого не делает, то напишите свою статью про свое видение и мы ее обсудим.
Это не потянет на статью. Потому что мало и потому что все программисты это и так знают. Вот пример, подумайте на досуге.

Допустим в предметной области есть только 3 понятия «слон», «загон», «зоопарк». В ООП языке будет 3 типа «Elephant», «Paddock», «Zoo». Всё. В предметной области понятия «атрибут» нет, значит и в коде программы, моделирующем эту предметную область, типа «Attirbute» или переменной с названием «attribute» или отдельного списка всех возможных атрибутов «attributeList» не будет.
Я понятия не имею, что есть в коде, но в нашем сознании есть атрибут высота. Этот атрибут должен моделироваться, если мы моделируем предметную область. И мы его моделируем. Если ООП не позволяет моделировать атрибут «высота», то мне жаль.
Объект в ООП не имеет отношения к объектам реальности. В самом начале декларировалось именно соответствие, а по факту — нет. Из-за этого и мисандестуд.
В реальности есть высота и у слона, и у загона, и у, скажем, самого высокого здания зоопарка. Но у объектов в ООП «Elephant», «Paddock», «Zoo», пока не ввели нет высоты.
Объект в ООП не имеет отношения к объектам реальности. В самом начале декларировалось именно соответствие, а по факту — нет. Из-за этого и мисандестуд.

Одна из тех мыслей, что я активно пытаюсь донести, — это то, что ООП не создано для моделирования реальности. Точнее, его пытаются натянуть на эту задачу, но получается плохо.
Не вводите человека в заблуждение. «В реальности» то есть в предметной области может не быть высоты. Ну вот не волнует нас рост слона, мы его не знаем и указать не можем. И не будем. И в ООП его не будет. Когда мы построим крытый загон и начнем учитывать рост слона, перед постройкой мы измерим рост всех слонов, в предметной области у слона появится новая характеристика, а у нас новое знание. Новая характеристика появится в коде в описании типа «Elephant», новые знания о росте в базе данных слонов. Изменения в предметной области отражаются соответствующими изменениями в коде. Модель правильная.
так все-таки в ООП моделируются атрибуты и типы, или нет?
В ООП можно описать тип и работать с объектами этого типа. Эти типы и объекты (заложенные в ИС «компьютер») можно использовать как соответствующие типам и объектам предметной области (используемым в ИС «мышление человека»). См. значения слова «модель», про «замещает объект-оригинал». Как описываются типы с атрибутами я уже показал. «У слона есть вес и рост» — «Elephant { weight; height; }».

Отдельно хочу обратить внимание, что мы не никогда рассматриваем признаки как «просто какая-то высота», мы всегда подразумеваем «высота (чего)».
Отдельно хочу обратить внимание, что мы не никогда рассматриваем признаки как «просто какая-то высота», мы всегда подразумеваем «высота (чего)»

Вот я про это и говорю, что как только высота чего, то модель перестает удовлетворять требованиям расширяемости. В OWL атрибут не бывает чего-то. Есть область значений и область определений атрибута. Область определения — это те объекты, которые подвергаются классификации при помощи значений атрибута. Область значений — множество, элементами которого могут быть значения. атрибута. Но сам атрибут существует отдельно от «чего-то». И это принципиальное от отличие ООП, в котором из-за этого нельзя построить расширяемые модели. И именно поэтому в OWL отказались от этого интуитивного, но неверного решения — говорить атрибут чего-то.
Есть область значений
Вот именно поэтому «цвет» пикселя черно-белого монитора и «цвет» лепестка растения это разные атрибуты. И область значений зависит только от объекта, так как определяется его характеристиками. Потому что даже у двух черно-белых мониторов будет свой набор оттенков. Поэтому отдельного атрибута «цвет» нет, есть «цвет чего-то».

И это принципиальное от отличие ООП, в котором из-за этого нельзя построить расширяемые модели.
Да что мешает-то в тип «Слон» добавить новый атрибут «длина хобота»? Elephant { weight; height; trunkLength; } Просто взял и расширил.
Вот именно поэтому «цвет» пикселя черно-белого монитора и «цвет» лепестка растения это разные атрибуты.

В ООП — верно, но в OWL — это будет один атрибут. Или разный, если нам зачем-то это понадобится. Но, если разный, мы уже не сможем сравнить цвет пикселя и цвет лепестка. Или нам придется лезть в код и моделировать это вручную, а мы этого не хотим. Прелесть онтологии в том, что не надо кодить, надо моделировать. И, если кто-то замоделирует цвета разными атрибутами, то он сам дурак, — теперь это разные атрибуты и сравнивать их значения без создания костылей из кода уже нельзя.
Если у вас это будет один атрибут, то черно-белый монитор сможет иметь розовый цвет. Это значит, что модель у вас никуда не годится. Если вам так надо, дело ваше, только не надо говорить, что это правильно.

И да, сравнивать значения так нельзя. Значения сравниваются с учетом единиц измерения, которые и задают диапазон возможных значений. И это не костыли, это физические свойства окружающего мира. Нельзя сравнивать мощность в ваттах с мощностью в джоулях, или ньютоны с метрами. Надо сначала сделать преобразование (если оно возможно). Вот и у цвета пикселя свой диапазон. И перед сравнением с цветом лепестка нужно будет перевести его в RGB или в общую для них третью единицу.
А, еще одна проблема. Если в предметной области название «Цвет» для монитора поменяется на «Оттенок», то в вашей модели «Цвет» лепестка тоже станет называться «Оттенок».
Так вы должны следить за тем, что пишете. Если атрибут меняет название, то это — другой атрибут. Мы не вправе переименовывать атрибуты только потому что у монитора нет цвета, а есть оттенок

Вот я про это и говорю. В предметной области просто поменялось название. Пусть даже не "Оттенок", а "Уровень белого", так будет более выражено. Все единицы измерения и характеристики у всех существующих объектов остались те же. А у вас в модели надо отвязать атрибут "Цвет", создать новый, привязать его, скопировать значения. Изменения в модели не соответствуют изменениям в предметной области. Значит модель неправильная.

Если у вас был атрибут цвет и значения этого атрибута. Потом пришел парень и сказал, что название для этого атрибута было неверным, надо переименовать этот атрибут. Вы переименовываете. Никаких проблем. Если же парень сказал, что раньше мы использовали одно название для обозначения цвета монитора и цвета цветка, а теперь он просит для монитора заменить название на новое, то это значит, что он просит создать новый атрибут, а значения старого по определенным правилам перенести в значения нового атрибута.

Это делается путем сохранения старого атрибута — ведь мы не имеем права просто удалить данные, внесенные другими пользователями. Если сдвинуть временную шкалу в прошлое, мы по-прежнему будем видеть цвета на мониторах. Однако, если мы говорим о будущем, то, после переноса данных на основе правил, которые мы сделаем, не прибегая к кодированию, у нас у монитора появится новый атрибут «Оттенок» и его значения. При этом мы сохраним обе точки зрения, которая была до ввода нового атрибута и после. Более того, на основе обратного правила, мы можем узнать, как выглядело бы описание монитора в старых терминах и сможем вернуться к ним, если новые не приживутся.
То, что черно-белый монитор не может засветиться желтым, не относится к атрибуту. Это свойство объекта — монитора. Сегодня он не может светиться желтым, завтра — сможет. Атрибут с этим поведением конкретного монитора никак не связан. Это и есть часть расширяемости модели. Если завтра окажется, что там в мониторе был желтый, в нашей модели ничего не поменяется, а в вашей модели придется переписывать код. Мы, конечно, в качестве правил логического вывода можем сказать, что, если у монитора появился желтый пиксель, нельзя называть этот монитор чб, он должен быть переклассифицирован в цветной, что мы и сделаем, если на то будет указание. И никаких правок кода!

В программировании модель это код. Вы в принципе не можете поменять модель, не изменяя код. Для этого надо кодом описать модель модели, чтобы это все было можно сделать во время работы программы. Только это уже не будет модель предметной области, модель предметной области надо будет создавать вручную после запуска программы. Так же как вы делаете в редакторе OWL. Модель в оперативной памяти редактора — это аналог написанного кода. Добавление свойства в редакторе — это аналог добавления свойства в коде. Если вы требуете не менять код при добавлении атрибута, значит в OWL вы не должны добавлять его через редактор.


То, что черно-белый монитор не может засветиться желтым, не относится к атрибуту.

Черно-белый монитор так называется из-за свойств пикселей. Значит атрибут "цвет" относится к пикселю, а не к монитору. Кстати, если монитор у вас имеет атрибут "цвет", который означает "цвет пикселя", то вы не сможете добавить атрибут "цвет", который обозначает "цвет корпуса". Снова появляется связь "цвет (чего)".


Это и есть часть расширяемости модели.

Это не часть расширяемости, это заранее заложенный запас. Модель у вас не расширяется. В ней сразу заложено, что можно создать черно-белый монитор с желтым цветом. Только предметной области это не соответствует. А если завтра окажется, что он железо притягивать начнет? А у вас там только цвет задан.

Вы в принципе не можете поменять модель, не изменяя код.

Нет, не верно. Это одна из прелестей OWL, в котором и модели объектов и модели правил записываются одинаково. Вы же не меняете код, когда создаете модель нового объекта, правда вы меняете код, когда создаете модель нового класса, или новый метод.

Мы создаем новые классы и новые методы, не прибегая к кодированию так же, как вы создаете модели объектов
Нет, не верно

Я говорил про ООП, а не про принципиальную невозможность. Еще раз, в OWL модель в оперативной памяти, там вы можете ее менять, не меняя код самого редактора, в коде редактора этой модели вообще нет. Но добавляя новое свойство вы ее меняете, меняете значения в оперативной памяти. В ООП модель в коде, чтобы ее поменять, естественно надо менять код, менять символы в файлах. В обоих случаях чтобы изменить модель надо менять там, где она хранится.


И неважно, отдельно у нас хранятся свойства или накопированы в каждый тип. Важно то, что это в обоих случаях моделирует саму предметную область. Если термины "тип" и "атрибут" в предметной области не существуют, то описывать их и их взаимосвязь в модели не надо.

Опять не понимаю. Я говорю о том, что в OWL атрибут отделен от типа. Вы говорите, что в ООП атрибут привязан к типу. В этом разница. И она позволяет мне делать то, что в ООП я делать не могу. А что там хранится в компе, — я понятия не имею. Я работаю с представлением, которое мне предоставляет интерфейс. То, что там байты, нолики и электроны, меня не трогает.

Что конкретно вы не можете сделать ООП? Добавить атрибуты можно, удалить можно. В OWL меняется интерфейс (списки, стрелочки, или что там у вас), так как модель задается списками и стрелочками, в ООП меняется код, потому что модель задается кодом. Но это тоже модель.

Кодирование на ассемблере, на ООП языке, на ФП языке, на каком-то DSL или метаDSL или тасканием квадратиков мышкой — это не принципиально. Модель или может быть реализована в рамках архитектуры современных компьютеров или нет (граничные случаи, связанные с физическими ограничениями не рассматриваем).


На ООП-языках можно представить любую модель, которую можно реализовать на популярных архитектурах. В каких-то случаях модель будет лаконичной, в каких-то понятия и связи предметной области надо будет выражать через конструкции языка громоздко, реализовывая самостоятельно то, что в языке и(или) ООП в целом не реализовано, а в каких-то обходя средствами языка ограничения этого же языка. Грубо, те же паттерны — это стандартные способы реализации того, что в языке не предусмотрено или даже запрещено.


В ООП мы вполне можем создать типы и атрибуты в ваших терминах, со связью 0..N:0..N. И типы, и атрибуты будут классами и(или) объектами в терминах ООП, связи между ними будут храниться в коллекциях объектов третьего типа и т. п., и вообще вся модель будет загружаться из БД или Интернета, но её термины, её метамодель будет написана на ООП-языке. А может на ФП. А может на ассемблере. А может на ООП без явного создания средств метамоделирования, простым или не очень кодом.

Я думаю, что достаточно рассказал про OWL. Если есть желание, могу отослать к методичке, которую мы написали для обучения моделированию в OWL, или к материалам, которые выложены в общем доступе.
Если в предметной области у слона есть высота, то в коде будет «Elephant { height }». Моделируется? Моделируется.
И не надо путать моделирование как задание соответствия (mapping) объекта в одной ИС объекту в другой ИС, и моделирование как описание структуры в понятиях более высокого уровня абстракции.
Я понятия не имею, что есть в коде, но в нашем сознании есть атрибут высота. Этот атрибут должен моделироваться, если мы моделируем предметную область.

Не должен, если в моделируемом контексте предметной области его наличие и(или) значение игнорируется. Кстати, это одна из самых частых ошибок в моделировании: есть что-то в сознании — переносим в модель, не задумываясь а нужно ли оно там, будет ли использоваться.

Хорошо, нам надо переносить, потому что мы моделирует типы и атрибуты. Кстати, в книжке, ссылку на которую мне дал Катричек Игорь: Языки моделирования" (1979 год, перевод 1985 год), есть все, что я рассказал. Так что я оказался не уникален. Все уже давно описано, но позабыто.
Типы объектов — это часть нашего представления о предметной области, и они требуют моделирования.

Зачем это? Нам не надо моделировать наше представление о предметной области, нам надо моделировать саму предметную область.


Давно уже хочу сказать, но как-то повода не было. Вы ошибочно разделяете понятия "информационная система" и "наше представление". Мозг человека это тоже информационная система. Есть внешние объекты и их модель в некоторой информационной системе. Всё. Мозг человека умеет производить анализ данных и выделять типы объектов. Компьютер так не умеет, и типы ему надо задавать. В результате и там и там получается модель предметной области.

Есть внешние объекты и их модель в некоторой информационной системе

Нет внешних объектов, есть модель пространства и времени в нашем сознании. (это, если допустить существование пространства и времени). Поэтому все, что мы делаем, мы делаем на одном поле — в нашем сознании. Там появляются модели пространственно-временных объектов, там же — их модели (модели моделей). Поэтому нет объектов, есть только модели.

Зачем моделировать типы? Понятия не имею, но, если понадобится это сделать, я сформулировал требования к моделлеру.

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


Зачем моделировать типы? Понятия не имею

Типы это средство моделирования нами предметной области. Я имел в виду, что модель средства моделирования (следующий уровень абстракции) делать не надо. А вы, видимо, под выражением "моделировать типы" имеете в виду их задание в другой информационной системе. Задавать типы в ООП можно.

> Например, математическое множество не существует во времени, как и операции над ним. Это значит, что нельзя сказать, что состав множества меняется во времени.

Воспользуйтесь категорией множеств и задайте шкалу над ней.
Мы можем строить любые конструкции: множества множеств, например. Но это не отменяет того, что состав множества постоянен. Непостоянно только наше знание о его составе.
А что вам мешает представить время как категорию, где одни немутабельные множества перетекают в другие немутабельные множества?
К сожалению, я не понял тезиса. Что такое категория времени, в которой множества «перетекают». Если время как параметр, то каждое множество — это множество, существующее с и по. Тогда куча песка описывается множеством множеств.
Возьмём категорию, где объектами выступают множества, а морфизмами — функции с соответствующими областями определения/значений. Возмём малую категорию предпорядка. Построим категорию функторов из последней категорию в первую. Построенная категория хорошо отображает понятия времени. К тому же множества перетекают вместе со своими морфизмами — т.е. отношениями между ними.

И никакого множества множеств и прочих парадоксов
Я уважаю знания и людей, которые ими владеют. Сам я имею среднее образование в области математики, а хорошее — в области физики. Поэтому мне трудно понимать математиков. Поэтому я пишу статьи, чтобы таким как я было понятно, о чем говорят математики. Есть ли возможность сказать то же, но более простым языком? Или дать ссылку на достаточно понятный и простой учебник по теории категорий, до которой у меня руки так и не дошли пока?
Я и сам не математик. Просто однажды я задумался о том, что мне придётся объяснять ребёнку, что такое число, и с ужасом понял, что сам не знаю. Стал потихоньку в вебе искать математические книжки. Оказалось, что теория категорий в современной математике — это универсальный язык, как теория множеств в старой.

К счастью, на хабре запостили очень простой и понятный учебник для начинающих: https://github.com/George66/Textbook

P.S. Множества с непрерывностью не работают, с непрерывностью работает топология — так что вам надо в том направлении копать, чтобы подобрать подходящие абстракции.
Я искренне признателен за внимание к теме, но тут я могу сказать лишь одно, — все построения (в том числе теория категорий) основаны на теории множеств. Если мы не согласны с этим, то надо спросить у математика. Не знаю, поможет ли он нам, потому что он очень занят, но я попробую к нему обратиться с этим вопросом.

Множества с непрерывностью не работают, с непрерывностью работает топология

Этот тезис я, увы, понять не могу. Про непрерывность можно говорить на множестве, где введено понятие расстояния. И это делается на первом курсе МФТИ при изучении метрических пространств. Я не вижу проблем с понятием непрерывности.
Нет.
Теория категорий НЕ сводитсдя к теории множеств.
ТК была изначально разработана как альтернатива теории множеств в качестве основания метематики, но не содержащая парадоксов.
Поэтому ТК предлагает другой «язык математики», алтернативный «языку» теории множеств.
Одно из напревлений исследований ТК — построение и исследование категории, обладающей свойствами категории множеств (топосы).
Здорово! Тогда как будет трактоваться тип и атрибут в этой парадигме?
В какой «парадигме»?
ЕМНИП, в тех разделах ТК и ТМ, что мне известны понятия «атрибут» нет.
Это понятие возникает в информационном моделировании при выделении некоего домена и соотнесения ему имени.
За более детальным определением мозете обратится (например) к книшшке Плоткина (название что-то вроде «домены, множества, категории»), там это хорошо разобрано с чисто математической т.з.).
Мы моделируем предметные области. В них есть объекты определенных типов, типы и атрибуты. Нам надо моделировать и то и другое. Поэтому я задаюсь вопросом, как в одной из парадигм представить, что такое атрибут и что такое тип, чтобы можно было его моделировать. То, что я нашел, я представил в терминах теории множеств. Этого достаточно, чтобы строить модели как атрибутов, так и типов. В теории категорий как будут выглядеть модели типов и модели атрибутов? Я не говорю, что они там есть, но они должны моделироваться в терминах ТК. Вот об этом вопрос
Нет. Теории множеств недостаточно для моделирования атрибутив, объектов и типов.
В теории программировании это поняли еще в шестидесятые годы, когда родился лозунг «типы это не множества» и началась разработка «теории абстрактных типов данных».
Методы и способы, которыми вы определяете и выделяете объекты, типы и атрибуты в предметной области составляют существенную часть парадигмы моделирования.
Меняете способ выделения объектов или типов, или атрибутов (или чего еще там у вас будет) — и получаете другую парадигму.
Теории множеств недостаточно для информационного моделирования, поскольку для получения сколь-нибудь нетривиальной модели нужно иметь инварианты, операции, предикаты. Для этого нужно иметь предикаты. Для них нужно имерь возможность определять отношения и по крайней мере два типа/домена. А для этого нужно… И так далее.
Т.е. теория множеств требует расширений для возможности построения ваших моделей. Расширить ее можно разными способамим, но все эти способы должны удовлетворять определнному набору условий/признаков (определяемых математически), что б давать в результате формальную модель, допускающую непротиворечивые интерпретации.
То, КАК МОЖНО раширить теорию множеств для построения информационных моделей уже хорошо изучено и описано.
Пока же, извините, ваши построения читаются как откровения человека, освоившего вводные главы в популярной книжке.

Вы так и не ответили на вопрос: как в парадигме, которая известна вам, строится модель типов и атрибутов?
Я и не собирался отчечать на этот вопрос. Я сказал, что у вас неверные представления о роли и месте теории категорий в математике.
Хорошо, я почитаю. Но смысл статьи был в том, что я дал определения для типа и атрибута в рамках теории множеств таким способом, что я теперь могу их моделировать, выбирать способы их моделирования осознанно. Так что, если теория категорий не позволит мне это сделать, то мы говорим вне темы поста.
Мы моделируем предметные области. В них есть объекты определенных типов, типы и атрибуты

Не "в них есть", а "мы выделяем в них". Объективно в предметных областях как правило нет понятий объектов, типов и атрибутов. Их вводят при построении модели предметной области. Или не вводят, вводя, например, понятия класса, инстанса класса, свойств и методов. Или таблиц, их строк и столбцов. Вводим подобные абстракции мы, аналитики или исполняющие их роль на проекте, во время анализа предметной области, во время построения её модели.

Говоря слово, вы употребляете термин и у него есть значение, которое относится к объектам одного типа (группы), но не класса. Поэтому знание того, что такое тип, понятие и атрибут — обязательны.
Состав множества всех слонов мира постоянно изменяется.
Нет, не меняется. Если множество имеет переменный состав, его нельзя ни сравнивать, ни производить операции над ним ни… и тд. Состав может меняться, но уже не множества. https://www.facebook.com/permalink.php?story_fbid=1382834025162408&id=100003074717050
То есть множества всех слонов мира не существует? Как тогда определить тип «африканский слон»?
Да и вообще, как тогда определять множество, состоящее из реальных объектов? Они же не существуют вечно. Получается, множества для моделирования реальных объектов не подходят.
Как тогда определить тип «африканский слон»?
Да и вообще, как тогда определять множество, состоящее из реальных объектов? Они же не существуют вечно.

Посмотрите, как моделируют множества в 4D парадигме. Я растолковал эту парадигму в начале статьи. Много писал об этом ранее. Время — это еще одно измерение, мы живем в 4-х мерном мире. В нем нет изменений, изменения у нас в сознании. Уберите эту мысль и научитесь моделировать реальные множества. У нас есть специалист по этой теме: habrahabr.ru/users/vvagr/ Виктор Агроскин

Зачем мне читать теорию? У вас ошибка в логических рассуждениях. Множество определено правилом «все слоны мира». Родился новый слон, множество изменилось. Если множество у вас не меняется, значит с помощью множества вы не можете работать с реальными слонами.

Либо покажите, как применить вашу теорию к этому примеру. В начале статьи вы предлагаете заменять объекты какими-то их частями, то есть меняете правило. Но задача стоит работать с множеством объектов, а не других частей.
Вы опять сидите в рамках 3D. Слон — это не просто пространство, это еще и дата начала существования слона и дата окончания — смерти. Рождение нового слона — не пополняет множество слонов, оно пополняет наше знание о множестве слонов, потому что будущее закрыто. Я писал об этом в статье. Множество слонов не меняется, меняется наше знание о нем. Можно сказать и так: дай мне множество слонов, существующих сейчас. Понятно, что множество слонов, существующих сейчас отличается от завтра. Но это будут разные множества.
«Знание о множестве» это и есть «множество». Потому что иначе нужно предполагать существование множества вне нашего мышления, как реальный объект. А вы ниже утверждали, что реальных объектов не существует, есть только модели в нашем мышлении.

Изменение только «знания о составе множества» подразумевает, что родившийся (после задания этого множества) слон входил в состав множества еще до своего рождения. Это в принципе неправильно, так как предполагает, что будущее (относительно момента задания множества) предопределено, и противоречит вашим другим тезисам, где вы говорили, что будущее вероятностно и имеет много вариантов развития.
Как сказал бы математик — я не понимаю, о чем вы говорите. Я предупредил, что знание о множествах контринтуитивно и обросло мифами, порой религиозными.
«Знание о множестве» это и есть «множество». Потому что иначе нужно предполагать существование множества вне нашего мышления, как реальный объект.

Нам необязательно знать точный состав множества, чтобы им оперировать, достаточно ссылки на правило задания множества или ссылки на перечисление, чтобы описать все необходимые для модели операции над этим множеством. Уточнение состава множества будет происходить непосредственно в момент когда нужно получить результат, зависящий от состава множества.


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

Нам необязательно знать точный состав множества, чтобы им оперировать

Правильно, оперировать мы будем множеством, а не объектами, входящими в его состав. Мы поэтому его и задаем, чтобы работать с ним как с единым целым, а не с отдельными объектами. Постоянно описание множества (правило), но не его состав.

Формально множество, определенное правилом "все слоны мира" включает, и слонов ещё не родившихся, и слонов уже погибших. На практике чаще используется множество "все известные нам живые слоны мира на данный момент времени", реже — на какой-то момент в прошлом, ещё реже — прогнозы о составе множества (как правило количественные метрики) на какой-то момент времени в будущем. Либо, как вариант, множества типа "все известные нам слоны мира на момент запуска отчёта в будущем".

Формально наверно да, но это не столь важно. Я о том, что можно придумать правило, зависящее от времени, а раз множество задается правилом, то его состав меняется. Либо это не множество, а что-то другое, значит теория множеств здесь не подходит. Можно как в ФП считать, что это просто разные множества, но это будет неправильное моделирование, так как мы в нашем мышлении считаем, что это один и тот же объект.

Мышление человека способно ухватить либо пространственные аспекты мира, либо времЕнные. Но нет слов, чтобы передать одновременно и пространственные и временные аспекты. Поэтому у вас множество меняется, хотя оно не меняется. Вы просто движетесь на транспорте вдоль оси времени. А математике нет дела до вашего движения и ваших представлений. Мы сразу строим 4D модель, в которых движение вдоль оси времени — это не более чем трехмерный срез.

В таком случае множество слонов сегодня и множество слонов завтра это разные множества, и мы не можем с ними работать как с одним объектом. Мы в принципе не сможем работать с ними в реальности, так как ни одно действие не выполняется мгновенно.


Есть загон, в нем на данный момент 3 слона. Сколько элементов во множестве "множество слонов в этом загоне" в вашей 4D модели?

Множество слонов в загоне может быть лишь в определенный момент времени. данный момент времени мы рассматриваем множество слонов, состоящее из трех элементов. В другое время — это будет уже другое множество. Но в 4D модели множество содержит не слонов, как я писал ранее, а их темпоральные части. И там объектов может быть сколь угодно. Чтобы понять, какие слоны были на заданный момент времени, мы строим подмножество этого множества из тех темпоральных частей, которые актуальны на данное время.

У множества может меняться как состав (в разные моменты времени к множеству могут относится разные объекты, правило задания множества может быть простой функцией от времени), так и правило его задания (правило задания множества может быть функцией высшего порядка от времени, возвращающей разные правила в разные моменты времени).

Я задал этот вопрос математику. Его ответ меня не порадовал, но был таков: это не множество.
Как мы знаем, что состав множества может быть задан двумя способами:

Непосредственным перечислением объектов, выбранных из какого-то множества.
Правилами идентификации объектов, выбранных из какого-то множества.

Как же так? Почему правило идентификации не может быть функцией от времени?

потому что в теории множеств время — это одна из размерностей множества, в котором определяются подпространства, которые мы называем объектами. Нам надо ввести ось, координаты для этой оси, надо ввести правила, каждое из которых приписано к значению координаты на этой оси, каждое из которых породит свое множество. Это один способ. Второй способ — правило единое, но оно касается темпоральных частей объектов, а не объектов. И в том и в другом случае множества неизменны. Только в первом случае — к нас множество множеств, а во втором — множество темпоральных частей

Потому что получившийся "объект" ведет себя не как множество. На нем не задано отношение принадлежности. Но мы его можем мыслить как функцию, которая результатом будет иметь множество.

У множества нет поведения. вести себя может только объект.

Что значит: на множестве задать отношение принадлежности? Это значит, сказать, какой объект относится к множеству? Я рассказал как это сделать: надо отнести к множеству не объекты, а их темпоральные части.
Все это, конечно, интересно и заслуживает всяческого уважения, но…
Но, похоже, уважаемый автор не понимает (или понимает, но не хочет никому говорить?), что теория множеств не универсальна. Даже, напротив.
В том смысле, что она изначально создавалась как иструмент для исследования достаточно специального класса задач, интересных «фундаментальным математикам».
А именно задач, связанных с понятиями конечности/бесконечности/отображения/количества/меры.
Все. Для моделеривания объектов реального мира, их структуры/поведения/взаимодействия/использования/т.п. — это теория изначально не предназначалась. От слова «совсем».
Очень интересное замечание! Я как раз обратного мнения, Я считаю, что математики всю свою силу направляли на попытку создать язык для описания предметных областей. А то, что они строили обобщения, — это признак их незаурядного ума. Но обобщения при их применении к конкретным задачам напрямую применимы к практическим задачам. Как говорит мой знакомый математик, мне все равно, что моделировать.
Метематика оперирует абстракциями. В т.ч. и строит на их основе абстракции более выского уровня. Или менее.
Вы, естественно, в полном праве иметь свою точку зрения. Она интересна, но… Но, право слово, стоит хотя бы попытаться «взойти на плечи гигантов».
Мне, к примеру, очень помогли книшшки Гильтерта по матлогике.
Метематика оперирует абстракциями.

Если вы заявляете это, то должны легко дать определение понятию абстракция. Дайте, пожалуйста
(Со вздохом) Вы ошибаетесь, полагая что я вам что-то должен.
Писать определение абстракции мне, честно говоря, лениво. Если вы и его не знаете, то… бяда.
Я знаю — это модель. Вы сказали, что математика оперирует абстракциями, то есть моделями. Моделями чего? чего угодно, в том числе моделями типов и атрибутов. Вот и вопрос: как выглядит модель атрибута с точки зрения математики?
Модель предметной области представляется в виде формальной системы в некоем алфавите.
Формальная система есть неоднородная совокупность набора первичных термов («слов»), набора правил композиции термов, набора правил вывода и набора предикатов (который можно раделить на отношения и операции).
Наборы в простейшем случае можно полагать не более, чем счетными множествами.
Эта часть определяет «синтаксическую» компоненту семиотической системы.
Для задания семантической компоненты семиотической системы нужно определить «область интерпретации» и «правила интепретации»…
Синтаксически атрибуты суть разбиения на ис-ходном множетве термов. Синтаксически типы определяются как совокупность подмножествс термов и выделенного набора предикатов.
Для атрибутов и типов правила интерпретации должны обладать определенным исвойствами.
Слушайте, это все по многу раз описывалось к учебниках по представлению знаний и моделированию, неуж-то нужно перепечатывать азы?!..

Нет, я выдвинул два простых определения типа и атрибута с точки зрения теории множеств. Они читаются за один раз и понятны, что бы вы ни говорили. Попробуйте также просто сформулировать определения этих терминов в модели, о которой вы говорите. Если это трудно, как, например, сформулировать, что такое число 0, то так и скажите, это сложно и дайте ссылку на литературу. Я ее почитаю. Но с точки зрения теории множеств, объясните, чем не устраивает вас мое определение?
(Со вздохом) В рамках теории множеств эти понятия не имеют адекватного непротиворечивого определения.
Вам это тут уже говорено не один раз.

Число нуль (хотя это и не относится к обсуждаемому) определяется как класс множеств, изоморфных пустому множеству. Это в рамках теории множеств.
В общей алгебре нуль опредлеяется по-другому, но есть доказательство эвивалентности этих определений.
Книжка, которую надо б почтать перед началом разработки информационных моделей:
«Universal Algebra, Algebraic Logic, and Databases» by Plotkin B.
Вроде бы, издавалссь на русском.

Спасибо большое! Хотя я не отвергаю своего мнения. Мои определения были выстраданы годами и проверены вдоль и поперек. Пользоваться ими я могу в рамках решаемых задач. Это главное. Более нигде и никогда я не встречал определения типа и атрибута достаточного для моделирования. Хотя в OWL само то, что атрибут определяется через область значений и область определений, наводит на мысль о функции.
Увы, «выстраданность» иммет значение в области веры и убеждений.
В инженерном деле, науке вообще и математике в частности имеют значение совсем другие интеллектуальные категории…
Разумеется, при всем том вы можете оставаться при своем мнении, и точно так же раумеется, что это мнение без доказательства обратного может быть неверным.
Естественно, что в OWL атрибут определяется именно так, потому как OWL и разрабатывался с оглядкой на математические основы представления знаний.
Неожиданно пришло подтверждение моей догадке относительно того, что такое атрибут. Игорь Катричек прислал скрин из книги Е.Киндлера «Языки моделирования» (1979 год, перевод 1985 год), где атрибут определяют похожим образом.
image
Только в этой книге значения атрибута не образуют множества В моем определении разделение множества на подмножества при помощи значений атрибута более общее, нежели просто значение функции. Я всегда был недоволен делением атрибутов на качественные и количественные, потому что при таком делении не делалось обобщение, — не было общего определения, которое было бы удовлетворительным и для того и для другого случая. Мне удалось их обобщить. И, самое веселое, что при этом атрибут стал рядом с типом, отличаясь от него всего одним словом: тип выделяет объекты в группу, а атрибут разделяет по группам. Согласитесь, что такое понимание более глубокое и простое.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.