В данной статье я дам свое, более общее определение атрибута, чтобы можно было легко его себе представить.
В прошлой статье Моделирование конструкций. Требования к моделлеру я говорил о том, что несколько объектов, мыслимых нами как целое, существуют в нашем сознании, но не осознаются нами явно. Математики осознали это и сделали явным, введя для этого понятие множества. Я также напомнил, что понятие множество и понятие объект — аксиомы, которые невыводимы из других понятий. При этом понятие объект для нас привычно, и мы имеем достаточный опыт, чтобы работать с ними, а вот со множеством мы знакомимся в институте при изучении основ математики, и представление о них не столь очевидно. Для тех, кто ищет возможность научиться представлять множество более ясно, я рассказал, где мы можем найти хороший образ – в представлении конструкций. В этой статье я продолжу рассказ про множества, и расскажу, что такое тип и атрибут с точки зрения теории множеств. И самое главное – я расскажу, как эти понятия находят свое отражение в моделях, которые мы строим.
Множества в математике и физике
Мы воспринимаем мир либо как пространство, либо как время, но не можем одновременно представить и то и другое. Это накладывает свои ограничения на язык, которым мы пользуемся, и модели, которые мы строим.
Например, математическое множество не существует во времени, как и операции над ним. Это значит, что нельзя сказать, что состав множества меняется во времени.
Мне самому это кажется контринтуитивным и неочевидным требованием, но без него мы не сможем проводить операции над множествами и делать сравнения. Это значит, что, если мы хотим описать множество песчинок в куче песка, то у нас есть два способа это сделать: для каждого нового состава песчинок вводить новое множество, или рассмотреть множество темпоральных частей песчинок в исследуемой куче. Под темпоральной частью песчинки понимается временная часть песчинки, которая имеет атрибут: начало и конец, моделирующие присутствие данной песчинки в куче. Это множество темпоральных частей еще называют 4D-представление, выполненное в 4D парадигме. Состав песчинок на конкретный момент можно получить из этого множества путем временного среза: выбрать только те темпоральные части песчинок, которые «актуальны» на данный момент времени, то есть те, которые появились в куче раньше, а ушли из кучи позже выбранного момента времени.
Так моделируется состав реальных «физических» множеств. Но для текущей статьи такое представление будет достаточно сложным, и я вернусь к обычному представлению простых множеств «замороженных» во времени, то есть таких, которые существуют «вне времени».
Определение состава множества
Множество– это многое, мыслимое как целое, где многое – это состав множества. Рассмотрим способы определения состава множества. Как мы знаем, что состав множества может быть задан двумя способами:
- Непосредственным перечислением объектов, выбранных из какого-то множества.
- Правилами идентификации объектов, выбранных из какого-то множества.
Например, пусть в комнате среди прочих объектов есть два: белая тарелка и зеленый маркер.
- Множество А, состоящее из этих двух элементов можно задать путем перечисления: белая тарелка входит в состав множества А и зеленый маркер входит в состав множества А. Больше ничто из находящегося в комнате, не входит в состав множества А.
- Можно поступить иначе. Можно к тарелке и маркеру приклеить желтый стикер и проследить, чтобы других стикеров в комнате не было. Тогда можно сказать, что те и только те объекты в данной комнате, которые имеют желтый стикер, входят в состав множества А.
Первый способ определения состава – это перечисление
Второй способ – задание условия идентификации.
В ходе обсуждения прошлой статьи я понял, что не все ясно понимают разницу между этими двумя способами определения состава множества. Поэтому я расскажу про них подробнее.
Первый способ основан на серии высказываний:
Тарелка входит в состав множества А
Маркер входит в состав множества А
Больше никто не входит в состав множества А
Второй способ – это высказывание в предикатах:
Тот и только тот объект из находящихся в комнате, который имеет желтый стикер, входит в состав множества А.
В первом способе описания состава могут участвовать любые модели объектов. Во втором способе описания модели объектов должны обладать одним общим атрибутом, значение которого определяет вхождение или не вхождение объекта в состав множества. То есть, если в моделях объектов нет общих атрибутов, построить условия идентификации невозможно.
В обсуждении статьи было предложено само вхождение во множество при помощи перечисления тоже сделать атрибутом: «входит в состав множества А». Таким образом, те объекты, которые входят во множество А, имеют значение этого атрибута «да». Затем было предложено на основании этого атрибута сделать признак для отбора в состав того же самого множества А: те объекты, которые имеют значение «да», входят в состав множества А. Автор этой затеи не заметил, что в результате логического вывода из этих двух высказываний мы получаем две тавтологии:
В состав множества А входят те и только те объекты, которые входят в состав множества А и
Объект входит в состав множества А тогда и только тогда, когда он входит в состав множества А.
Эти очевидные высказывания не содержат информации ни о конкретных объектах, ни о множестве А. Если я возьму тарелку, то на основании этого высказывания нельзя будет определить, относится ли она к множеству А, или нет.
Поэтому перечисление и правило – два принципиально разных способа описания состава множества, и в математике они указаны как два основных и совершенно разных способа определения состава множества.
Кстати, в свое время был длительный спор об определении того, что такое функция. Этот спор возник по причине того, что не могли принять решение о том, какие правила идентификации считать корректными, а какие – нет. В итоге была принята идея Дирихле о том, что любые правила будут считаться корректными. Именно поэтому я не буду замахиваться на классификацию всех правил, но рассмотрю лишь несколько, которые в данном контексте нам понадобятся.
В учебниках часто правило идентификации называют правилом отбора. Термин «правило отбора» вводит в заблуждение, потому что предполагает некую операцию по отбору. А это намек на то, что множество может пополняться. Но это не так. Множество имеет фиксированный состав. Поэтому лучше говорить не об отборе, а об идентификации. Мы не отбираем элементы во множество, мы идентифицируем их как элементы множества.
Определение состава подмножества
Давайте посмотрим, как мы определяем состав множества африканских слонов. Я насчитал четыре разных способа это сделать.
- Можно определить их путем перечисления.
- Можно приклеить стикер к слонам, и сказать, что те слоны, у которых есть приклеенный стикер, считаются африканскими. Это определение состава множества через атрибут. Атрибутом будет считаться наличие или отсутствие стикера.
- Можно определить состав через пересечение двух множеств: множества слонов и множества животных, обитающих в Африке.
- Можно ввести понятие типа «африканские слоны».
Используя в нашей работе OWL, мы имеем возможность реализовать три описанных выше способа задания подмножества:
- Явно перечислить входящие в подмножество объекты,
- Определить правило идентификации через любые условия на любые атрибуты, с разными операциями: от самого факта обладания значением какого-либо атрибута до попадания этого значения в определенный диапазон
- Задать операции над другими множествами: например, в состав множества A входят только те объекты, которые входят в состав множества B и не входят при этом в состав множества С.
Чтобы понять, можем ли мы реализовать четвертый способ идентификации при помощи типа объектов, рассмотрим его подробнее.
Моделирование подмножества при помощи типа
Для определения типа «африканский слон» нам понадобятся:
- Группа объектов, из которой мы выбираем объекты для под-типа. В данном случае эта группы имеет название – это группа слонов.
- Уникальное свойство, котором объекты типа отличаются от остальных объектов группы: проживают в Африке.
- Уникальное название для объектов данного типа
Можно поступить иначе и в качестве группы взять животных, проживающих в Африке. Тогда уникальным свойством, выделяющим африканских слонов от других африканских животных будет то, что эти животные – слоны.
Итого, чтобы дать определение типа, надо:
- Указать над-множество объектов.
- Указать отличительные особенности (дифференциальные свойства) объектов данного типа от объектов группы.
- Указать название объектов данного типа
Дополнительно можно указать:
- Причины, по которым данный тип объектов стал востребован (дифференциальные функциональные свойства объектов данного типа
- Пользу от введения данного типа объектов
- Историю термина
- Итд.
Объекты одного типа отличаются от прочих объектов надмножества каким-то уникальным свойством. Это уникальное свойство может моделироваться через любые условия на любые атрибуты. Но при этом не обязательно, чтобы все значения всех атрибутов совпадали, или чтобы состав атрибутов у всех однотипных объектов был одинаков.
Зная, что такое тип, можно подумать, что четвертый способ выделения подмножеств совпадает со вторым. Однако, для определения типа нам потребуется дополнительно, как минимум, указать специализированное название, а в качестве опции — указать другие атрибуты типа, например, указать причины выделения данного типа объектов, историю термина и тд. При помощи второго способа это сделать невозможно. Поэтому четвертый способ отличается от второго и не реализуется пока в стандартах моделирования, которые мне известны.
Понятие тип
Итак, с точки зрения теории множеств:
Тип – это способ выделения подмножества из над-множества и присвоение нового имени объектам этого подмножества
Если над-множества нет, то тип считается аксиоматическим, невыводимым. Как я говорил ранее, понятие объекта и понятие множества являются невыводимыми понятиями, потому что для них нельзя указать над-множество объектов.
Разница между типом объектов и множеством объектов
Из обсуждений статьи я понял, что есть люди, которые считают, что тип объектов и множество объектов – это то ли связанные понятия, то ли одно и тоже. Попробую объяснить, почему это не так. Тип — это одновременно и правило идентификации объектов, и название этих объектов. То есть тип служит одновременно и специализации (или выделению) подмножества из множества, и дает новое название специализированным объектам.
Каждый тип определяет состав множества, но не каждому множеству соответствует тип, определяющий его состав, например, когда мы говорим о множестве, состав которого задан перечислением его элементов, или, когда мы говорим о множестве, чьи элементы не имеют своего названия.
Понятно, что правило, задающее множество не есть само множество.
Мне кажется, что из всего сказанного ясно, чем понятие «тип объектов» отличается от понятия «множество объектов».
Моделирование однотипных объектов
Часто в ИС однотипные объекты моделируются при помощи моделей, содержащих одинаковый набор атрибутов. Теперь можно видеть, что данное ограничение избыточное, поскольку у объектов одного типа могут быть разные наборы атрибутов. Такое ограничение вызвано техническими особенностями реализации, но не требованиями предметной области.
В ИС список однотипных объектов пополняется. Это наводит на мысль о переменном составе множеств, которые мы моделируем. Однако, это не так. Список объектов, которые были зарегистрированы в ИС, не является исчерпывающим списком множества. То есть, в ИС хранятся модели не всех элементов множества, а лишь тех, которые на данный момент зарегистрированы. Поэтому, когда мы делаем запрос, его смысл такой: дай мне все объекты данного типа, которые зарегистрированы на данный момент в ИС.
Жизненный цикл объекта
Кроме того, что объект может быть отнесен к определенному типу объектов, есть еще два момента, про которые нельзя забывать:
- Классификация (отнесение объекта к определенному классу, или типу объектов) всегда субъективна. Один и тот же объект с разной точки зрения может выглядеть по-разному. Если мы строим расширяемую модель предметной области, использование которой предполагает наличие разных стейкхолдеров, то должна быть возможность моделирования контекста и различных точек зрения. При этом с разных точек зрения один и тот же объект может быть отнесен к разным типам.
- Учет жизненного цикла объекта предполагает не только учет изменений объекта, но и учет изменения нашего восприятия этого объекта, поскольку наравне с процессом синтеза и анализа идет процесс объективации и деобъективации.
Процесс объективации и деобъективации выглядит так:
Объективация
Обладая представлением о типах, мы пытаемся найти объекты этих типов в окружающем нас мире. Найденные объекты, как правило, относятся к самым широким типам. Например, если речь идет о предприятии, то на первом шаге найденные объекты могут относиться к операциям, функциям и объектам. Или если речь идет о растениях, сначала мы делим их на деревья, траву и кустарники. Далее происходит уточнение типа объекта путем проверки различных гипотез. В процессе уточнения мы пытаемся найти такой тип, который скажет нам об объекте достаточно, чтобы этим знанием можно было эффективно пользоваться на практике (пытаемся найти более узкий тип, к которому можно отнести этот объект). В процессе уточнения модель объекта обрастает новыми деталями. Параллельно мы используем наши знания об этом объекте на практике. Если применение этих знаний успешное, объект считается правильно полученным и правильно классифицированным (тип объекта выбран верно).
Деобъективация
Однако все меняется: меняются представления об окружающем нас мире, появляются новые знания и т. д. В результате оказывается, что модель объекта перестает удовлетворять требованию полезности. И тогда слишком узкая специализация объекта становится его же врагом. Объект подвергается переклассификации (заявка превратилась в требование), а порой и полностью уничтожается, как был уничтожен эфир, или теплород. И тогда цикл начинается сначала: выбор объектов, уточнение знаний о них и т. д.
Примеры из практики:
Объективация:
Пусть клиент пришел для подачи заявки. До тех пор, пока заявка не исполнена, мы можем знать ее тип только с некоторой долей вероятности. Поэтому сначала регистрируется заявка самого широкого типа. Затем по мере уточнения деталей и в процессе ее исполнения, модель заявки обрастает новыми атрибутами. Спустя какое-то время становится ясно, к какому типу заявок отнести данную заявку и происходит окончательная ее классификация.
Деобъективация:
Пусть у нас есть типовой сценарий поиска информации в интернете. Пусть в нем сказано, что всякий раз, когда надо найти нужную информацию, воспользуйтесь таким-то поисковиком – программой для поиска нужной информации. Пусть мы пользовались этой программой многократно, каждый раз совершая операцию поиска. Таких операций за время эксплуатации этой программы было много, и все они были классифицированы как операции типа «поиск информации». Спустя какое-то время выясняется, что программа-поисковик выполняет шпионские функции, «сливая» данные о пользователе заинтересованным в этой информации лицам. И тогда выясняется, что те операции, которые использовал этот поисковик, теперь будут переклассифицированы из операций по поиску информации в операции по пересылке данных заинтересованным лицам. Но вполне может статься, что мы узнаем еще что-то про эту программу и тогда нам придется пересматривать и другие операции, в которых она принимала участие.
Требования к моделлеру, моделирующего типы
Сформулируем требования к моделлеру, который предназначен для моделирования типов:
- Необходимо уметь моделировать однотипные объекты, состав атрибутов которых не совпадает
- Необходимо уметь моделировать правила, которые выделяют объекты в один тип
- Необходимость моделировать другие атрибуты типа: название объектов данного типа, историю этого названия и проч.
- Необходимо уметь моделировать разные точки зрения на один и тот же объект
- Необходимо уметь моделировать жизненный цикл объекта
- Необходимо уметь моделировать изменение нашего представления об объекте с течением времени .
Как в ИТ отрасли реализовать эти требования без обращения к структуре БД? Как, не обращаясь к структуре данных, учитывать разные точки зрения, добавлять новые типы объектов, уточнять тип объектов, переклассифицировать объекты в случае необходимости?
Моделирование объектов при помощи OWL
Есть одно ограничение, которое присутствует в OWL: в нем множество и тип объектов не различаются. Из-за этого мы имеем ограниченный функционал для моделирования типов объектов. Однако, этот функционал намного шире того, что дают нам другие способы моделирования, потому что у нас есть следующие возможности:
- Добавление нового множества объектов в OWL ничем не отличается от добавления нового объекта.
- Можно потребовать, что, если тип объекта известен, то модель объекта создается с заданными, наперед известными атрибутами. При этом после создания атрибуты могут как добавляться, так и удаляться. Пример: создавая модель заявки, мы можем потребовать указать значения атрибутов (номер заявки, дата заявки, заявитель, адресат). Надо только помнить, что эти атрибуты в OWL существуют отдельно от типов объектов. И один атрибут может быть использован при моделировании объектов разных множеств. Это принципиальное отличие от распространенных языков программирования, где атрибут существует только в рамках одного типа объектов. Другой атрибут в другом типе, пусть и называемый так же, будет другим атрибутом.
- Можно потребовать наоборот: определять подмножество моделируемого объекта на основе атрибутов модели объекта и его принадлежности к над-множеству. Для этого в правиле будет записано, что если модель объекта, относящегося к определенному над-множеству, содержит такие-то атрибуты и их значения удовлетворяют определенным правилам, то объект автоматически будет отнесен к определенному подмножеству. Так при помощи правил будет реализована, так называемая, «утиная классификация». Например, если в модели заявки есть значение атрибута «Телефонный номер», а «Подключение» — это значение атрибута «Тип выполняемых работ», то заявка автоматически будет классифицирована как заявка на подключение телефонного номера.
Разделения множества на подмножества
Пусть есть множество объектов. И пусть стоит задача по разделению этого множества на семь подмножеств, каждому из которых приписан свой цвет: «красные объекты», желтые объекты». И тд.
Разделение множества на подмножества можно провести разными способами.
- Можно разделить множество на непересекающиеся подмножества, распределив объекты по подмножествам путем их перечисления. Создать семь подмножеств и перечислить объекты, которые принадлежат каждому из подмножеств.
- Для каждого подмножества можно придумать свой подтип. Тогда все множество можно разделить на семь подмножеств, введя семь подтипов: «Тип красных объектов», «Тип желтых объектов» и т. д. Каждый объект можно отнести к одному из перечисленных типов и сказать, например, так: объект относится к типу красных объектов.
- Можно разделить надмножество при помощи атрибута и его значений. Например, можно ввести атрибут «Цвет» и семь его значений: «Красный», «Желтый» и тд. Тогда название цвета станет прилагательным для объекта и будет звучать так: красный объект, желтый объект и тд.
Первый способ в OWL реализован при помощи создания семи разных классов и указания объектов, которые к ним относятся.
Второй способ может быть реализован тремя разными способами:
- При помощи создания отдельных под-множеств, объединенных одним типом, но сами типы, как я говорил ранее, не моделируются. Этот способ ничем не отличается от способа разделения перечислением.
- При помощи справочника «Типы цветных объектов», значениями которого будут объекты, моделирующие типы: «Красные объекты», «желтые объекты» и тд
- При помощи атрибута с названием «тип объекта», значения которого будут иметь текстовую форму: «Тип красных объектов», «Тип желтых объектов» и тд
Третий способ разделения множества на подмножества в ИС моделируется двумя способами:
- При помощи справочника «Цвета», значениями которого будут объекты, моделирующие значения атрибутов: красный, желтый и т. д.
- При помощи атрибута с названием «Цвет», значения которого будут иметь текстовую форму: «красный», «желтый» и тд.
Видно, что разделение при помощи типов и атрибутов моделируется в двух случаях одинаковым способом, но имеет разные названия. И действительно, обладание значением атрибута в OWL моделируется таким триплетом:
#объект #атрибут #значение
Принадлежность классу — таким:
#объект rdf:type #класс
То есть можно сказать, что принадлежность классу просто выражается при помощи специального служебного атрибута, определенного в стандарте — rdf:type.
Понятие атрибут
Сформулируем утверждение:
Атрибут – это способ разделения множества объектов на подмножества. При этом каждому значению атрибута соответствует определенное подмножество, объекты которого имеют атрибут с таким значением.
Моделирование подмножеств при помощи атрибута
Каждый из трех способов перечисленных ранее способов моделирования подмножеств имеет свои преимущества и недостатки в зависимости от контекста и выбранного способа реализации.
Если подмножеств немного, можно выбрать любой и перечисленных способов разделения на подмножества и любую реализацию.
Если подмножеств много (в пределе бесконечно, например, когда каждое из множеств группирует объекты одинаковой длины), то формально остаются:
- третий способ моделирования типа и
- второй способ моделирования атрибута.
Однако, я писал ранее, что каждому типу нужно дать название. Если подмножеств много (бесконечно), то дать имя каждому из них нереально. Поэтому мы не моделируем такое деление при помощи типов. Мы моделируем такое деление только при помощи атрибута, областью значений которого будет одно из распространенных множеств: множество вещественных чисел, множество, моделирующее временную шкалу, множество натуральных чисел, множество строк конечной длины и тд. Узнаете типы данных?
О том, как вводится функция на множестве подмножеств и не только про это, можно почитать тут.
Третий способ реализации атрибута хорош тем, что при помощи него можно моделировать огромное количество подмножеств (вариантов написания строки – очень много), но плох тем, что не понятно, как узнать, что объекты относятся к одному множеству: «Красный», красный», «»кра)сный_» — это значения одного и того же множества, или разных?
О том, как лучше моделировать подмножества написано море литературы, и я не буду здесь повторяться. Просто запомним, что атрибут – это модель подмножеств, а значение – это указание на подмножество.
Комментарии (128)
vvagr
05.06.2017 12:02+1Ваша основная методологическая ошибка — во фразе «моделирование подмножества с помощью типа». Вы не разделяете уровни моделирования. Есть уровень теории множеств. Над ним вы можете строить типы (онтологические) с именами, можете — мереологию с отношением часть-целое, можете — темпоральную логику. Можете математические графы, а над ними — описания систем. Но это моделирование имеет направление — снизу вверх, от абстрактного к конкретным потребностям.
То есть основной объём статьи посвящен моделированию типов, много чего понаписано. Но это никак не дополняет и не развивает математическую теорию множеств.
maxstroy
05.06.2017 12:29В качестве базовых объектов выбраны объекты, связи и множества. Это то, как мы моделируем мир с точки зрения теории множеств.
Объект (машина) — это тоже модель, модель пространственно-временной части вселенной. Эта модель существует в нашем сознании до тех пор, пока мы имеем понятие об автомобилях. Потеряв это понятие, мы теряем и объект. Никто уже не сможет сказать: это автомобиль, если никто не владеет понятием об автомобилях. Понятие — это тип. Поэтому первичным в нашем мире являются понятия об объектах. На основе этих понятий мы строим в нашем сознании объекты, связи и множества.То есть, первичное понятие — тип, вторичное — объект и множества. Все верно.
Правильно было бы говорить о порождении типом множества объектов, а не о моделировании множества при помощи типа. Спасибо!vvagr
05.06.2017 12:38В математике первичны множества и элементы. Уже связи определяются через декартово произведение множеств.
Вы называете множествами какие-то иные сущности, не те, что в математике.maxstroy
05.06.2017 13:04Мы все время путаем математические объекты, которые есть объекты, не связанные с предметной областью, и объектами, которые эти математические объекты, моделируют.
В предметной области есть объекты: тарелка и ложка. Мы можем объединить их в множество А, помыслив их одним, — множеством.
Для моделирования тарелки мы используем букву а, для моделирования ложки — букву б. Для моделирования множества — букву Б. В итоге мы получили два набора:
тарелку, ложку и множество А,
а, б, и множество Б.
Второй набор объектов моделирует первый набор.
Первый набор можно дополнить связью между ложкой и тарелкой: «лежит в»
Эта связь может быть смоделирована во втором наборе разными способами.
при помощи надписи: «а лежит в б»,
при помощи элемента декартова произведения множества само на себя — элемента аб,
но во втором случае, имея в модели только элемент аб, мы не сможем восстановить смысл этого элемента. Поэтому для моделирования связи в предметной области мы используем связь «лежит в», которая является не элементом декартово произведения, а элементом множества триплетов, которые строятся на основании предиката: «ИКС „лежит в“ ИГРЕК» Заменяя ИКС и ИГРЕК на модели конкретных объектов, мы получаем модели конкретных связей.
aristarh1970
05.06.2017 22:50У вас, как говорено выше, методологическая ошибка.
Теория множеств предназначана для моделирования только узкого набора свойств объктов реального мира: количества/конечности/т.п.
В рамках тероии множеств все объекты в множестве полагаются различимыми ТОЛЬКО по возможности их отличить один от другого, см. «аксиома выбора» (Цермелло, если не ошибаюсь).
Для моделирования прозивольных отношений между объектами (в вашм примере отношения "… находится в ...") — теория множеств НЕ предназначена.
Для этого НАД теорией множеств настраивается алгебра и теория отношений.
Так же не предназначета теория мноижеств для моделирования структуры объектов.
Повторяю, у ТМ очень специальная задача: исследование количества/конечности/бесконечности. И не более того.maxstroy
06.06.2017 08:13+1Теория множеств предназначана для моделирования только узкого набора свойств объктов реального мира: количества/конечности/т.п.
У меня другие сведения, извините. Я могу построить модель чего угодно. Например, задав функцию на множестве всех подмножеств, построить модель атрибута. Кратко о возможностях теории множеств см: http://akuklev.livejournal.com/1261552.html
Для этого НАД теорией множеств настраивается алгебра и теория отношений.
Алгебра построена на основе теории множеств. Верно, и значит, что все, что моделируется при помощи алгебры транзитом моделируется при помощи множеств.aristarh1970
06.06.2017 17:43(Со вздохом) Это примерно то же самое, что утверждать: раз все состоит из элементарных частиц, то весь мир описываетсдя квантовой механикой…
Вы видели такое описание?maxstroy
06.06.2017 18:01Не совсем, мы не знаем, из чего состоит мир. И состоит ли он вообще.
А тут все просто: мы строим агрегаты понятий. Одни понятия строятся на основе других. Все в математике построено на теории множеств и может быть выведено из нее. Удали ее и все развалится. То, что мы пользуемся теорией категорий, построенной на теории множеств, означает, что мы пользуемся теорией множеств, когда используем понятия из теории категорий. Тут ни прибавить, ни отнять. Я задался вопросом: что есть тип и атрибут с точки зрения теории множеств? Мог бы задать тот же вопрос, но с точки зрения теории категорий. Кстати, что это?
michael_vostrikov
06.06.2017 20:27Алгебра построена на основе теории множеств. Верно, и значит, что все, что моделируется при помощи алгебры транзитом моделируется при помощи множеств.
Кстати нет. Раз некоторая алгебра это надстройка над теорией множеств, значит она содержит что-то еще, кроме теории множеств. Значит то, что можно смоделировать с помощью дополнительной части, нельзя смоделировать только теорией множеств. Верно только обратное утверждение — то что моделируется частью, можно смоделировать целым.
maxstroy
06.06.2017 20:48Верно. Добавляя новые концепты, мы строим здание. Но фундамент у него все тот же. И все, что мы моделируем, можно построить на нем. Об этом моя статья — попытка построить определение типа и атрибута на основании теории множеств.
michael_vostrikov
06.06.2017 22:14Нет. Новые концепты (аксиомы, базовые понятия) это новый соседний фундамент. Вы не сможете построить склад длиной 10 пролетов, имея фундамент только для одного пролета.
Если в теории множеств используется N понятий, а в новой алгебре N+M, вы не сможете выразить новые понятия M через старые N. Например, если вы используете только понятия тепловой физики, вы не сможете через них выразить понятие "электрическое поле".
maxstroy
05.06.2017 13:52Хотя, я подумал, что сам попал в стандартную ловушку шаблонного мышления. Перед глазами у меня всегда анализ: когда мы на основании типа объектов создаем объекты. В статье я вел разговор про другое направление — про синтез. Это, когда на основании множества объектов мы создаем тип объекта, — обобщаем признаки объектов в группе. И тогда все верно: множество моделируется при помощи типа.
aristarh1970
05.06.2017 22:41Нет.
Конкретная машина это не модель. Это конкретный материальный объект в конкретнык промежуток времени в конкретной области вселенной.
Модель это ее описание (той или иной степени абстракции/детализации).
И понятие «машина» в человечском сознании тоже модель.
Но модель не тождественна самому объекту.
При исчезновении объекта — модель не исчезнет.
При исчезновении модели — объект не исчезнет.
Свойства объекта «модель машины» и свойства объекта «конкретная машина» — различны.
Для конкретной машины может существовать множество различных моделей.
Поэтому, первичными в нашм мире являеются именно материлаьные объекты. Понятия лишь отображют и моделируют их.maxstroy
06.06.2017 08:29+1Мы уходим в область психологии. Мне не хочется туда углубляться сейчас, благо, что я в свое время написал статьи на эти темы. И статьи эти были проверены психологами. Так что могу заверить — машина не существует вне нашего сознания. Это легко доказать: если у нас есть всего один человек на земле, который кругом видит сипульки, но никто больше не знает ни термина сипулька, ни то, как они выглядят, то после его смерти ни один субъект не сможет найти ни одну сипульку.
ACPrikh
06.06.2017 11:39-1По-моему психологии явно не допроверили теорию сипулек.
Это область не психологии, а философии. Ваша интерпретация суперсубъективности мира — солипсизм. Весьма маргинальная ниша.
После смерти единственного человека животный мир эволюционирует и возникнет другое разумное существо, которое так же будет видеть и изучать сипульки. Не говоря о жителях иных миров.
З.Ы. Боюсь, что статья не сблизила математиков и обывателей.aristarh1970
06.06.2017 17:54-1Естественно, не сблизила. Что будет, если биологию станет полуляризировать человек, честно признающий что он «не очень хорошо владеет языком биологии»?
Вот тут то же самое.
maxstroy
06.06.2017 18:59Боюсь, что другое разумное существо поймет, что все живые существа — это один единый организм, включающий в себя и неживое. И не станет делить мир на части, а будет наслаждаться единством. Мы не знаем, до чего еще дойдет эволюция, но вероятность того, что она придет к идее сипульки настолько мала, что равна вероятности того, что в нашей галактике есть человек, похожий на меня.
aristarh1970
06.06.2017 17:49Это не пихология, а философия.
Ваше утверждение откуда-то из области между Поппером и Гегелем…
Хотя, ПМСМ, если продолжите в том же направлении, то психологи вами заинтересуются.
aristarh1970
05.06.2017 22:27Все ж таки, если «от абстрактного — к конкретному», то это «сверху вниз».
michael_vostrikov
05.06.2017 12:53-2Как мы знаем, что состав множества может быть задан двумя способами:
- Непосредственным перечислением объектов, выбранных из какого-то множества.
- Правилами идентификации объектов, выбранных из какого-то множества.
Вы не замечаете здесь рекурсию?
Во втором способе описания модели объектов должны обладать одним общим атрибутом
"Обладание общим атрибутом" это только один из возможных вариантов задания "правила идентификации".
Тот и только тот объект из находящихся в комнате, который имеет желтый стикер, входит в состав множества А.
Тот и только тот объект, который является тарелкой или маркером, входит в состав множества А. Следовательно, первый способ это тоже высказывание в предикатах.
Автор этой затеи не заметил, что в результате логического вывода из этих двух высказываний мы получаем две тавтологии
Автор этой статьи не заметил, что признак вхождения в одно множество можно сделать признаком вхождения в другое множество, и почему-то решил, что это высказывание относится только к одному множеству, хотя причин для такого вывода в том обсуждении нет.
было предложено само вхождение во множество при помощи перечисления тоже сделать атрибутом: «входит в состав множества А»
Было предложено "вхождение во множество А" сделать атрибутом для определения что объект "входит в состав множества B". См. определения множеств натуральных и целых чисел.
maxstroy
05.06.2017 13:31+1Как мы знаем, что состав множества может быть задан двумя способами:
Непосредственным перечислением объектов, выбранных из какого-то множества.
Правилами идентификации объектов, выбранных из какого-то множества.
Вы не замечаете здесь рекурсию?
Нет, потому что объекты для множества африканских слонов выбираются из множества слонов. То есть, дано: множество слонов, мы выбираем из этого множества подмножество при помощи перечисления объектов.michael_vostrikov
05.06.2017 14:19-1Вот именно поэтому признак "входит в состав множества А" не является тавтологией при задании правила, определяющего множество.
maxstroy
05.06.2017 13:42+1Мне уже немного затратно перечислять логические ошибки, которые вы допускаете в своих рассуждениях. Я еще раз рекомендую обратиться к математику, если вам интересна эта тема.
michael_vostrikov
05.06.2017 14:18-1Вы не привели ни одного доказательства ошибки. Есть только неправильные понимания вами приведенных высказываний, что вы считаете ошибкой. Мне постоянно приходится пояснять, где именно вы поняли не так, что и приводит к длинным диалогам. При этом вы часто меняете тему и уходите от ответа. Как и сейчас, рекомендуя обратиться неизвестно к кому. Я не интересуюсь математикой, я указываю на логические ошибки в ваших рассуждениях. Математик не даст мне ответов, почему вы сказали так, а не иначе.
maxstroy
05.06.2017 14:41Вы постоянно дрейфуете в своих тезисах, не замечая этого. От этого много суеты, но мало толку.
michael_vostrikov
05.06.2017 14:42То есть, в ИС хранятся модели не всех элементов множества, а лишь тех, которые на данный момент зарегистрированы.
Вот тут мы подошли к интересному вопросу. Как в вашем подходе смоделировать регистрацию нового объекта? То есть введение нового объекта в рассмотрение и идентификацию его как элемента некоторого множества?
maxstroy
05.06.2017 14:57+1Как в вашем подходе смоделировать регистрацию нового объекта?
Кейсов моделирования столько, сколько хватит воображения. Рассмотрим один из них.
Объект учета регистрируется в ИС. Его тип на момент регистрации может быть известен с какой-то точностью. Самые общие типы — это объект, или множество. Объект учета должен быть отнесен либо туда, либо туда. Возможно, тип объекта учета известен чуть точнее, например, это — операция, или даже: это операция из тех, что происходят в отделе кадров. Мы регистрируем эту операцию. Затем по ходу ее выполнения\планирования\выяснения деталей мы уточняем мы выясняем все новые и новые подробности, касающиеся этой операции, появляются новые атрибуты и их значения (чего сделать нельзя, используй мы стандартные способы моделирования предметных областей). В какой-то момент мы узнаем про операцию столько, что мы можем переклассифицировать операцию как «операция по составлению трудового контракта». Допустим, что этого нам достаточно для анализа или синтеза. На этом моделирование не заканчивается. О дальнейшей судьбе модели можно писать долго, но это уже не тема сегодняшней беседы.michael_vostrikov
05.06.2017 16:23-1Ага, то есть типы позволяют моделировать предметную область. В прошлых статьях вы уверяли, что это не так, и поэтому языки программирования (и в частности ООП) не годятся для моделирования.
maxstroy
05.06.2017 16:31+1Типы объектов — это часть нашего представления о предметной области, и они требуют моделирования. Требования к моделированию типов я сформулировал в статье. Но не все, конечно. Конечно, в ООП нет возможности моделировать типы объектов.
При этом надо различать тип объектов, и тип данных, который связан с этим типом объектов. Типы данных в ИС можно попытаться связать с типами объектов, но в ООП сделать это можно только в исключительных случаях, да и то — если модель не потребует расширения. В противном случае придется переписывать структуру классов.
Поэтому я утверждаю, что ООП не создано ни для моделирования типов объектов, ни для хотя бы сопоставления типов объектов типам данных.
Сопоставить типы данных и типы объектов можно в OWL.michael_vostrikov
05.06.2017 17:23-1Вот как раз "переписывать" и надо в исключительных случаях. Когда модель неправильная. В остальных случаях при расширении предметной области расширяется и соответствующая ей модель в информационной системе. У вас снова неправильные утверждения, на основе которых вы делаете неправильные выводы.
maxstroy
05.06.2017 17:32То, что модель классов в ООП рпи расширении может потребовать перестройку модели классов — теоретически доказуемо. Хотя бы потому что атрибуты в ООП не отделены от классов. В OWL атрибуты от классов отделены.
michael_vostrikov
05.06.2017 18:13-1Добавление атрибута в описание типа нельзя назвать "перестройка модели классов". Появилось новое свойство в предметной области — добавили свойство в описание типа в программе. Изменения в программе отражают изменения в предметной области, значит модель правильная.
maxstroy
05.06.2017 18:23Отделение атрибута от класса означает, что атрибуты, методы и классы существуют отдельно друг от друга, а не вместе, как в ООП,
michael_vostrikov
05.06.2017 23:10-1Не знаю, что вы подразумеваете под словами «существовать вместе» и «существовать отдельно». В любой системе моделирования у вас будет место, где будут перечислены атрибуты некоторого типа, их имеющего. Описание понятий «атрибут», «метод» и «класс» (тип) и их взаимосвязей это модель модели, и для описания самой предметной области она не нужна. В языках программирования эта модель находится в компиляторах.
И неважно, как они существуют. Важно, что с помощью них можно задавать типы. Нигде в определении типа не сказано, что что-то где-то должно существовать отдельно. Следовательно, ООП позволяет моделировать предметную область.maxstroy
06.06.2017 07:40В любой системе моделирования у вас будет место, где будут перечислены атрибуты некоторого типа, их имеющего.
Вы мыслите шаблоном: тип должен иметь атрибуты. Нет, не верно. Если сделать так, то модели станут нерасширяемые. Для этого надо отделить атрибуты от типов. Атрибуты не принадлежат типам.
В этом (и не только) сила OWL
michael_vostrikov
06.06.2017 11:22
Тип, имеющий атрибуты, должен иметь атрибуты. Тип, не имеющий атрибутов, не имеет атрибутов. Я не зря там приписку после запятой написал. Рекомендую вам задуматься над своими шаблонами.типа, их имеющего
Вы мыслите шаблоном: тип должен иметь атрибуты
И все равно, наличие у типа атрибутов не запрещает нам добавлять в него новые атрибуты (расширять).
Атрибуты не принадлежат типам.
Они им и в ООП не принадлежат. Понятие «атрибут» образуется на уровне компилятора, и там оно отделено от понятия «тип», и все вместе они отделены от описания самого типа в исходном коде. В описании типа атрибуты только перечислены. Так же как они будут перечислены в вашем OWL.
И все равно, способ описания модели модели чего-то никак не влияет не ее способность моделировать это что-то.maxstroy
06.06.2017 11:34Я не понимаю ваши тезисы. Я смотрю описание классов в ООП и вижу, что в них определены атрибуты и методы. Я не вижу определение в ООП атрибутов без классов, не вижу определения методов вне классов. Как в ООП можно создать атрибут, или метод без создания класса? Это уже не ООП, это — функциональное программирование, в котором эта проблема решена, и метод отделен от класса.
michael_vostrikov
06.06.2017 11:39-1Зачем его создавать в ООП? Создание атрибута и описание его отношения с типом это модель модели. Для моделирования предметной области нужно описание типов. Если в предметной области понятия «атрибут» нет, то и в описании типов ООП его быть не должно.
maxstroy
06.06.2017 11:58Я не понимаю вас. Извините. Напишите свое видение в статье и мы ее обсудим. Если ООП декларирует описание типов и атрибутов, а вы настаиваете, что оно этого не делает, то напишите свою статью про свое видение и мы ее обсудим.
michael_vostrikov
06.06.2017 12:14Это не потянет на статью. Потому что мало и потому что все программисты это и так знают. Вот пример, подумайте на досуге.
Допустим в предметной области есть только 3 понятия «слон», «загон», «зоопарк». В ООП языке будет 3 типа «Elephant», «Paddock», «Zoo». Всё. В предметной области понятия «атрибут» нет, значит и в коде программы, моделирующем эту предметную область, типа «Attirbute» или переменной с названием «attribute» или отдельного списка всех возможных атрибутов «attributeList» не будет.maxstroy
06.06.2017 12:19Я понятия не имею, что есть в коде, но в нашем сознании есть атрибут высота. Этот атрибут должен моделироваться, если мы моделируем предметную область. И мы его моделируем. Если ООП не позволяет моделировать атрибут «высота», то мне жаль.
ACPrikh
06.06.2017 12:54Объект в ООП не имеет отношения к объектам реальности. В самом начале декларировалось именно соответствие, а по факту — нет. Из-за этого и мисандестуд.
В реальности есть высота и у слона, и у загона, и у, скажем, самого высокого здания зоопарка. Но у объектов в ООП «Elephant», «Paddock», «Zoo», пока не ввели нет высоты.maxstroy
06.06.2017 13:00Объект в ООП не имеет отношения к объектам реальности. В самом начале декларировалось именно соответствие, а по факту — нет. Из-за этого и мисандестуд.
Одна из тех мыслей, что я активно пытаюсь донести, — это то, что ООП не создано для моделирования реальности. Точнее, его пытаются натянуть на эту задачу, но получается плохо.
michael_vostrikov
06.06.2017 13:15Не вводите человека в заблуждение. «В реальности» то есть в предметной области может не быть высоты. Ну вот не волнует нас рост слона, мы его не знаем и указать не можем. И не будем. И в ООП его не будет. Когда мы построим крытый загон и начнем учитывать рост слона, перед постройкой мы измерим рост всех слонов, в предметной области у слона появится новая характеристика, а у нас новое знание. Новая характеристика появится в коде в описании типа «Elephant», новые знания о росте в базе данных слонов. Изменения в предметной области отражаются соответствующими изменениями в коде. Модель правильная.
maxstroy
06.06.2017 13:36так все-таки в ООП моделируются атрибуты и типы, или нет?
michael_vostrikov
06.06.2017 14:07В ООП можно описать тип и работать с объектами этого типа. Эти типы и объекты (заложенные в ИС «компьютер») можно использовать как соответствующие типам и объектам предметной области (используемым в ИС «мышление человека»). См. значения слова «модель», про «замещает объект-оригинал». Как описываются типы с атрибутами я уже показал. «У слона есть вес и рост» — «Elephant { weight; height; }».
Отдельно хочу обратить внимание, что мы не никогда рассматриваем признаки как «просто какая-то высота», мы всегда подразумеваем «высота (чего)».maxstroy
06.06.2017 14:17Отдельно хочу обратить внимание, что мы не никогда рассматриваем признаки как «просто какая-то высота», мы всегда подразумеваем «высота (чего)»
Вот я про это и говорю, что как только высота чего, то модель перестает удовлетворять требованиям расширяемости. В OWL атрибут не бывает чего-то. Есть область значений и область определений атрибута. Область определения — это те объекты, которые подвергаются классификации при помощи значений атрибута. Область значений — множество, элементами которого могут быть значения. атрибута. Но сам атрибут существует отдельно от «чего-то». И это принципиальное от отличие ООП, в котором из-за этого нельзя построить расширяемые модели. И именно поэтому в OWL отказались от этого интуитивного, но неверного решения — говорить атрибут чего-то.michael_vostrikov
06.06.2017 14:36Есть область значений
Вот именно поэтому «цвет» пикселя черно-белого монитора и «цвет» лепестка растения это разные атрибуты. И область значений зависит только от объекта, так как определяется его характеристиками. Потому что даже у двух черно-белых мониторов будет свой набор оттенков. Поэтому отдельного атрибута «цвет» нет, есть «цвет чего-то».
И это принципиальное от отличие ООП, в котором из-за этого нельзя построить расширяемые модели.
Да что мешает-то в тип «Слон» добавить новый атрибут «длина хобота»? Elephant { weight; height; trunkLength; } Просто взял и расширил.
maxstroy
06.06.2017 14:44Вот именно поэтому «цвет» пикселя черно-белого монитора и «цвет» лепестка растения это разные атрибуты.
В ООП — верно, но в OWL — это будет один атрибут. Или разный, если нам зачем-то это понадобится. Но, если разный, мы уже не сможем сравнить цвет пикселя и цвет лепестка. Или нам придется лезть в код и моделировать это вручную, а мы этого не хотим. Прелесть онтологии в том, что не надо кодить, надо моделировать. И, если кто-то замоделирует цвета разными атрибутами, то он сам дурак, — теперь это разные атрибуты и сравнивать их значения без создания костылей из кода уже нельзя.michael_vostrikov
06.06.2017 15:31Если у вас это будет один атрибут, то черно-белый монитор сможет иметь розовый цвет. Это значит, что модель у вас никуда не годится. Если вам так надо, дело ваше, только не надо говорить, что это правильно.
И да, сравнивать значения так нельзя. Значения сравниваются с учетом единиц измерения, которые и задают диапазон возможных значений. И это не костыли, это физические свойства окружающего мира. Нельзя сравнивать мощность в ваттах с мощностью в джоулях, или ньютоны с метрами. Надо сначала сделать преобразование (если оно возможно). Вот и у цвета пикселя свой диапазон. И перед сравнением с цветом лепестка нужно будет перевести его в RGB или в общую для них третью единицу.michael_vostrikov
06.06.2017 15:35А, еще одна проблема. Если в предметной области название «Цвет» для монитора поменяется на «Оттенок», то в вашей модели «Цвет» лепестка тоже станет называться «Оттенок».
maxstroy
06.06.2017 15:51Так вы должны следить за тем, что пишете. Если атрибут меняет название, то это — другой атрибут. Мы не вправе переименовывать атрибуты только потому что у монитора нет цвета, а есть оттенок
michael_vostrikov
06.06.2017 16:37Вот я про это и говорю. В предметной области просто поменялось название. Пусть даже не "Оттенок", а "Уровень белого", так будет более выражено. Все единицы измерения и характеристики у всех существующих объектов остались те же. А у вас в модели надо отвязать атрибут "Цвет", создать новый, привязать его, скопировать значения. Изменения в модели не соответствуют изменениям в предметной области. Значит модель неправильная.
maxstroy
06.06.2017 16:47Если у вас был атрибут цвет и значения этого атрибута. Потом пришел парень и сказал, что название для этого атрибута было неверным, надо переименовать этот атрибут. Вы переименовываете. Никаких проблем. Если же парень сказал, что раньше мы использовали одно название для обозначения цвета монитора и цвета цветка, а теперь он просит для монитора заменить название на новое, то это значит, что он просит создать новый атрибут, а значения старого по определенным правилам перенести в значения нового атрибута.
Это делается путем сохранения старого атрибута — ведь мы не имеем права просто удалить данные, внесенные другими пользователями. Если сдвинуть временную шкалу в прошлое, мы по-прежнему будем видеть цвета на мониторах. Однако, если мы говорим о будущем, то, после переноса данных на основе правил, которые мы сделаем, не прибегая к кодированию, у нас у монитора появится новый атрибут «Оттенок» и его значения. При этом мы сохраним обе точки зрения, которая была до ввода нового атрибута и после. Более того, на основе обратного правила, мы можем узнать, как выглядело бы описание монитора в старых терминах и сможем вернуться к ним, если новые не приживутся.
maxstroy
06.06.2017 15:49То, что черно-белый монитор не может засветиться желтым, не относится к атрибуту. Это свойство объекта — монитора. Сегодня он не может светиться желтым, завтра — сможет. Атрибут с этим поведением конкретного монитора никак не связан. Это и есть часть расширяемости модели. Если завтра окажется, что там в мониторе был желтый, в нашей модели ничего не поменяется, а в вашей модели придется переписывать код. Мы, конечно, в качестве правил логического вывода можем сказать, что, если у монитора появился желтый пиксель, нельзя называть этот монитор чб, он должен быть переклассифицирован в цветной, что мы и сделаем, если на то будет указание. И никаких правок кода!
michael_vostrikov
06.06.2017 16:32В программировании модель это код. Вы в принципе не можете поменять модель, не изменяя код. Для этого надо кодом описать модель модели, чтобы это все было можно сделать во время работы программы. Только это уже не будет модель предметной области, модель предметной области надо будет создавать вручную после запуска программы. Так же как вы делаете в редакторе OWL. Модель в оперативной памяти редактора — это аналог написанного кода. Добавление свойства в редакторе — это аналог добавления свойства в коде. Если вы требуете не менять код при добавлении атрибута, значит в OWL вы не должны добавлять его через редактор.
То, что черно-белый монитор не может засветиться желтым, не относится к атрибуту.
Черно-белый монитор так называется из-за свойств пикселей. Значит атрибут "цвет" относится к пикселю, а не к монитору. Кстати, если монитор у вас имеет атрибут "цвет", который означает "цвет пикселя", то вы не сможете добавить атрибут "цвет", который обозначает "цвет корпуса". Снова появляется связь "цвет (чего)".
Это и есть часть расширяемости модели.
Это не часть расширяемости, это заранее заложенный запас. Модель у вас не расширяется. В ней сразу заложено, что можно создать черно-белый монитор с желтым цветом. Только предметной области это не соответствует. А если завтра окажется, что он железо притягивать начнет? А у вас там только цвет задан.
maxstroy
06.06.2017 16:51Вы в принципе не можете поменять модель, не изменяя код.
Нет, не верно. Это одна из прелестей OWL, в котором и модели объектов и модели правил записываются одинаково. Вы же не меняете код, когда создаете модель нового объекта, правда вы меняете код, когда создаете модель нового класса, или новый метод.
Мы создаем новые классы и новые методы, не прибегая к кодированию так же, как вы создаете модели объектовmichael_vostrikov
06.06.2017 17:39Нет, не верно
Я говорил про ООП, а не про принципиальную невозможность. Еще раз, в OWL модель в оперативной памяти, там вы можете ее менять, не меняя код самого редактора, в коде редактора этой модели вообще нет. Но добавляя новое свойство вы ее меняете, меняете значения в оперативной памяти. В ООП модель в коде, чтобы ее поменять, естественно надо менять код, менять символы в файлах. В обоих случаях чтобы изменить модель надо менять там, где она хранится.
И неважно, отдельно у нас хранятся свойства или накопированы в каждый тип. Важно то, что это в обоих случаях моделирует саму предметную область. Если термины "тип" и "атрибут" в предметной области не существуют, то описывать их и их взаимосвязь в модели не надо.
maxstroy
06.06.2017 19:16Опять не понимаю. Я говорю о том, что в OWL атрибут отделен от типа. Вы говорите, что в ООП атрибут привязан к типу. В этом разница. И она позволяет мне делать то, что в ООП я делать не могу. А что там хранится в компе, — я понятия не имею. Я работаю с представлением, которое мне предоставляет интерфейс. То, что там байты, нолики и электроны, меня не трогает.
michael_vostrikov
06.06.2017 20:17Что конкретно вы не можете сделать ООП? Добавить атрибуты можно, удалить можно. В OWL меняется интерфейс (списки, стрелочки, или что там у вас), так как модель задается списками и стрелочками, в ООП меняется код, потому что модель задается кодом. Но это тоже модель.
VolCh
07.06.2017 09:36Кодирование на ассемблере, на ООП языке, на ФП языке, на каком-то DSL или метаDSL или тасканием квадратиков мышкой — это не принципиально. Модель или может быть реализована в рамках архитектуры современных компьютеров или нет (граничные случаи, связанные с физическими ограничениями не рассматриваем).
На ООП-языках можно представить любую модель, которую можно реализовать на популярных архитектурах. В каких-то случаях модель будет лаконичной, в каких-то понятия и связи предметной области надо будет выражать через конструкции языка громоздко, реализовывая самостоятельно то, что в языке и(или) ООП в целом не реализовано, а в каких-то обходя средствами языка ограничения этого же языка. Грубо, те же паттерны — это стандартные способы реализации того, что в языке не предусмотрено или даже запрещено.
В ООП мы вполне можем создать типы и атрибуты в ваших терминах, со связью 0..N:0..N. И типы, и атрибуты будут классами и(или) объектами в терминах ООП, связи между ними будут храниться в коллекциях объектов третьего типа и т. п., и вообще вся модель будет загружаться из БД или Интернета, но её термины, её метамодель будет написана на ООП-языке. А может на ФП. А может на ассемблере. А может на ООП без явного создания средств метамоделирования, простым или не очень кодом.
maxstroy
06.06.2017 16:53Я думаю, что достаточно рассказал про OWL. Если есть желание, могу отослать к методичке, которую мы написали для обучения моделированию в OWL, или к материалам, которые выложены в общем доступе.
michael_vostrikov
06.06.2017 13:08Если в предметной области у слона есть высота, то в коде будет «Elephant { height }». Моделируется? Моделируется.
И не надо путать моделирование как задание соответствия (mapping) объекта в одной ИС объекту в другой ИС, и моделирование как описание структуры в понятиях более высокого уровня абстракции.
VolCh
07.06.2017 09:10Я понятия не имею, что есть в коде, но в нашем сознании есть атрибут высота. Этот атрибут должен моделироваться, если мы моделируем предметную область.
Не должен, если в моделируемом контексте предметной области его наличие и(или) значение игнорируется. Кстати, это одна из самых частых ошибок в моделировании: есть что-то в сознании — переносим в модель, не задумываясь а нужно ли оно там, будет ли использоваться.
maxstroy
07.06.2017 09:27Хорошо, нам надо переносить, потому что мы моделирует типы и атрибуты. Кстати, в книжке, ссылку на которую мне дал Катричек Игорь: Языки моделирования" (1979 год, перевод 1985 год), есть все, что я рассказал. Так что я оказался не уникален. Все уже давно описано, но позабыто.
michael_vostrikov
05.06.2017 17:24Типы объектов — это часть нашего представления о предметной области, и они требуют моделирования.
Зачем это? Нам не надо моделировать наше представление о предметной области, нам надо моделировать саму предметную область.
Давно уже хочу сказать, но как-то повода не было. Вы ошибочно разделяете понятия "информационная система" и "наше представление". Мозг человека это тоже информационная система. Есть внешние объекты и их модель в некоторой информационной системе. Всё. Мозг человека умеет производить анализ данных и выделять типы объектов. Компьютер так не умеет, и типы ему надо задавать. В результате и там и там получается модель предметной области.
maxstroy
05.06.2017 17:36Есть внешние объекты и их модель в некоторой информационной системе
Нет внешних объектов, есть модель пространства и времени в нашем сознании. (это, если допустить существование пространства и времени). Поэтому все, что мы делаем, мы делаем на одном поле — в нашем сознании. Там появляются модели пространственно-временных объектов, там же — их модели (модели моделей). Поэтому нет объектов, есть только модели.
Зачем моделировать типы? Понятия не имею, но, если понадобится это сделать, я сформулировал требования к моделлеру.michael_vostrikov
05.06.2017 18:52Мы строим модель окружающего мира на основе входной информации. Входная информация появляется не сама по себе, есть причины ее возникновения. Внешние по отношению к информационной системе причины. Можете не называть их объектами, сути это не меняет. В информационной системе "наше представление" мы выделяем типы (и другие сущности), на основе чего строим модель предметной области. Если эти типы (и другие сущности) заложить в информационную систему "компьютер", в ней тоже будет модель предметной области.
Зачем моделировать типы? Понятия не имею
Типы это средство моделирования нами предметной области. Я имел в виду, что модель средства моделирования (следующий уровень абстракции) делать не надо. А вы, видимо, под выражением "моделировать типы" имеете в виду их задание в другой информационной системе. Задавать типы в ООП можно.
michael_vostrikov
05.06.2017 18:54Мы строим модель окружающего мира на основе входной информации. Входная информация появляется не сама по себе, есть причины ее возникновения. Внешние по отношению к информационной системе причины. Можете не называть их объектами, сути это не меняет. В информационной системе "наше представление" мы выделяем типы (и другие сущности), на основе чего строим модель предметной области. Если эти типы (и другие сущности) заложить в информационную систему "компьютер", в ней тоже будет модель предметной области.
Зачем моделировать типы? Понятия не имею
Типы это средство моделирования нами предметной области. Я имел в виду, что модель средства моделирования (следующий уровень абстракции) делать не надо. А вы, видимо, под выражением "моделировать типы" имеете в виду их задание в другой информационной системе. Задавать типы в ООП можно.
michael_vostrikov
05.06.2017 18:52Мы строим модель окружающего мира на основе входной информации. Входная информация появляется не сама по себе, есть причины ее возникновения. Внешние по отношению к информационной системе причины. Можете не называть их объектами, сути это не меняет. В информационной системе "наше представление" мы выделяем типы (и другие сущности), на основе чего строим модель предметной области. Если эти типы (и другие сущности) заложить в информационную систему "компьютер", в ней тоже будет модель предметной области.
Зачем моделировать типы? Понятия не имею
Типы это средство моделирования нами предметной области. Я имел в виду, что модель средства моделирования (следующий уровень абстракции) делать не надо. А вы, видимо, под выражением "моделировать типы" имеете в виду их задание в другой информационной системе. Задавать типы в ООП можно.
michael_vostrikov
05.06.2017 18:54Мы строим модель окружающего мира на основе входной информации. Входная информация появляется не сама по себе, есть причины ее возникновения. Внешние по отношению к информационной системе причины. Можете не называть их объектами, сути это не меняет. В информационной системе "наше представление" мы выделяем типы (и другие сущности), на основе чего строим модель предметной области. Если эти типы (и другие сущности) заложить в информационную систему "компьютер", в ней тоже будет модель предметной области.
Зачем моделировать типы? Понятия не имею
Типы это средство моделирования нами предметной области. Я имел в виду, что модель средства моделирования (следующий уровень абстракции) делать не надо. А вы, видимо, под выражением "моделировать типы" имеете в виду их задание в другой информационной системе. Задавать типы в ООП можно.
michael_vostrikov
05.06.2017 18:55Мы строим модель окружающего мира на основе входной информации. Входная информация появляется не сама по себе, есть причины ее возникновения. Внешние по отношению к информационной системе причины. Можете не называть их объектами, сути это не меняет. В информационной системе "наше представление" мы выделяем типы (и другие сущности), на основе чего строим модель предметной области. Если эти типы (и другие сущности) заложить в информационную систему "компьютер", в ней тоже будет модель предметной области.
Зачем моделировать типы? Понятия не имею
Типы это средство моделирования нами предметной области. Я имел в виду, что модель средства моделирования (следующий уровень абстракции) делать не надо. А вы, видимо, под выражением "моделировать типы" имеете в виду их задание в другой информационной системе. Задавать типы в ООП можно.
NaHCO3
05.06.2017 15:50> Например, математическое множество не существует во времени, как и операции над ним. Это значит, что нельзя сказать, что состав множества меняется во времени.
Воспользуйтесь категорией множеств и задайте шкалу над ней.maxstroy
05.06.2017 15:53+1Мы можем строить любые конструкции: множества множеств, например. Но это не отменяет того, что состав множества постоянен. Непостоянно только наше знание о его составе.
NaHCO3
05.06.2017 18:31А что вам мешает представить время как категорию, где одни немутабельные множества перетекают в другие немутабельные множества?
maxstroy
05.06.2017 19:19К сожалению, я не понял тезиса. Что такое категория времени, в которой множества «перетекают». Если время как параметр, то каждое множество — это множество, существующее с и по. Тогда куча песка описывается множеством множеств.
NaHCO3
05.06.2017 22:05Возьмём категорию, где объектами выступают множества, а морфизмами — функции с соответствующими областями определения/значений. Возмём малую категорию предпорядка. Построим категорию функторов из последней категорию в первую. Построенная категория хорошо отображает понятия времени. К тому же множества перетекают вместе со своими морфизмами — т.е. отношениями между ними.
И никакого множества множеств и прочих парадоксовmaxstroy
05.06.2017 22:19Я уважаю знания и людей, которые ими владеют. Сам я имею среднее образование в области математики, а хорошее — в области физики. Поэтому мне трудно понимать математиков. Поэтому я пишу статьи, чтобы таким как я было понятно, о чем говорят математики. Есть ли возможность сказать то же, но более простым языком? Или дать ссылку на достаточно понятный и простой учебник по теории категорий, до которой у меня руки так и не дошли пока?
NaHCO3
06.06.2017 09:42Я и сам не математик. Просто однажды я задумался о том, что мне придётся объяснять ребёнку, что такое число, и с ужасом понял, что сам не знаю. Стал потихоньку в вебе искать математические книжки. Оказалось, что теория категорий в современной математике — это универсальный язык, как теория множеств в старой.
К счастью, на хабре запостили очень простой и понятный учебник для начинающих: https://github.com/George66/Textbook
P.S. Множества с непрерывностью не работают, с непрерывностью работает топология — так что вам надо в том направлении копать, чтобы подобрать подходящие абстракции.maxstroy
06.06.2017 10:01Я искренне признателен за внимание к теме, но тут я могу сказать лишь одно, — все построения (в том числе теория категорий) основаны на теории множеств. Если мы не согласны с этим, то надо спросить у математика. Не знаю, поможет ли он нам, потому что он очень занят, но я попробую к нему обратиться с этим вопросом.
Множества с непрерывностью не работают, с непрерывностью работает топология
Этот тезис я, увы, понять не могу. Про непрерывность можно говорить на множестве, где введено понятие расстояния. И это делается на первом курсе МФТИ при изучении метрических пространств. Я не вижу проблем с понятием непрерывности.aristarh1970
06.06.2017 18:01Нет.
Теория категорий НЕ сводитсдя к теории множеств.
ТК была изначально разработана как альтернатива теории множеств в качестве основания метематики, но не содержащая парадоксов.
Поэтому ТК предлагает другой «язык математики», алтернативный «языку» теории множеств.
Одно из напревлений исследований ТК — построение и исследование категории, обладающей свойствами категории множеств (топосы).maxstroy
06.06.2017 18:05Здорово! Тогда как будет трактоваться тип и атрибут в этой парадигме?
aristarh1970
06.06.2017 18:20В какой «парадигме»?
ЕМНИП, в тех разделах ТК и ТМ, что мне известны понятия «атрибут» нет.
Это понятие возникает в информационном моделировании при выделении некоего домена и соотнесения ему имени.
За более детальным определением мозете обратится (например) к книшшке Плоткина (название что-то вроде «домены, множества, категории»), там это хорошо разобрано с чисто математической т.з.).maxstroy
06.06.2017 18:29Мы моделируем предметные области. В них есть объекты определенных типов, типы и атрибуты. Нам надо моделировать и то и другое. Поэтому я задаюсь вопросом, как в одной из парадигм представить, что такое атрибут и что такое тип, чтобы можно было его моделировать. То, что я нашел, я представил в терминах теории множеств. Этого достаточно, чтобы строить модели как атрибутов, так и типов. В теории категорий как будут выглядеть модели типов и модели атрибутов? Я не говорю, что они там есть, но они должны моделироваться в терминах ТК. Вот об этом вопрос
aristarh1970
06.06.2017 19:03Нет. Теории множеств недостаточно для моделирования атрибутив, объектов и типов.
В теории программировании это поняли еще в шестидесятые годы, когда родился лозунг «типы это не множества» и началась разработка «теории абстрактных типов данных».
Методы и способы, которыми вы определяете и выделяете объекты, типы и атрибуты в предметной области составляют существенную часть парадигмы моделирования.
Меняете способ выделения объектов или типов, или атрибутов (или чего еще там у вас будет) — и получаете другую парадигму.
Теории множеств недостаточно для информационного моделирования, поскольку для получения сколь-нибудь нетривиальной модели нужно иметь инварианты, операции, предикаты. Для этого нужно иметь предикаты. Для них нужно имерь возможность определять отношения и по крайней мере два типа/домена. А для этого нужно… И так далее.
Т.е. теория множеств требует расширений для возможности построения ваших моделей. Расширить ее можно разными способамим, но все эти способы должны удовлетворять определнному набору условий/признаков (определяемых математически), что б давать в результате формальную модель, допускающую непротиворечивые интерпретации.
То, КАК МОЖНО раширить теорию множеств для построения информационных моделей уже хорошо изучено и описано.
Пока же, извините, ваши построения читаются как откровения человека, освоившего вводные главы в популярной книжке.
maxstroy
06.06.2017 19:21Вы так и не ответили на вопрос: как в парадигме, которая известна вам, строится модель типов и атрибутов?
aristarh1970
06.06.2017 19:27Я и не собирался отчечать на этот вопрос. Я сказал, что у вас неверные представления о роли и месте теории категорий в математике.
maxstroy
06.06.2017 19:36Хорошо, я почитаю. Но смысл статьи был в том, что я дал определения для типа и атрибута в рамках теории множеств таким способом, что я теперь могу их моделировать, выбирать способы их моделирования осознанно. Так что, если теория категорий не позволит мне это сделать, то мы говорим вне темы поста.
VolCh
07.06.2017 09:44Мы моделируем предметные области. В них есть объекты определенных типов, типы и атрибуты
Не "в них есть", а "мы выделяем в них". Объективно в предметных областях как правило нет понятий объектов, типов и атрибутов. Их вводят при построении модели предметной области. Или не вводят, вводя, например, понятия класса, инстанса класса, свойств и методов. Или таблиц, их строк и столбцов. Вводим подобные абстракции мы, аналитики или исполняющие их роль на проекте, во время анализа предметной области, во время построения её модели.
maxstroy
07.06.2017 09:47Говоря слово, вы употребляете термин и у него есть значение, которое относится к объектам одного типа (группы), но не класса. Поэтому знание того, что такое тип, понятие и атрибут — обязательны.
michael_vostrikov
05.06.2017 22:23Состав множества всех слонов мира постоянно изменяется.
maxstroy
05.06.2017 22:31Нет, не меняется. Если множество имеет переменный состав, его нельзя ни сравнивать, ни производить операции над ним ни… и тд. Состав может меняться, но уже не множества. https://www.facebook.com/permalink.php?story_fbid=1382834025162408&id=100003074717050
michael_vostrikov
05.06.2017 22:38То есть множества всех слонов мира не существует? Как тогда определить тип «африканский слон»?
Да и вообще, как тогда определять множество, состоящее из реальных объектов? Они же не существуют вечно. Получается, множества для моделирования реальных объектов не подходят.maxstroy
06.06.2017 07:50Как тогда определить тип «африканский слон»?
Да и вообще, как тогда определять множество, состоящее из реальных объектов? Они же не существуют вечно.Посмотрите, как моделируют множества в 4D парадигме. Я растолковал эту парадигму в начале статьи. Много писал об этом ранее. Время — это еще одно измерение, мы живем в 4-х мерном мире. В нем нет изменений, изменения у нас в сознании. Уберите эту мысль и научитесь моделировать реальные множества. У нас есть специалист по этой теме: habrahabr.ru/users/vvagr/ Виктор Агроскин
michael_vostrikov
06.06.2017 11:34Зачем мне читать теорию? У вас ошибка в логических рассуждениях. Множество определено правилом «все слоны мира». Родился новый слон, множество изменилось. Если множество у вас не меняется, значит с помощью множества вы не можете работать с реальными слонами.
Либо покажите, как применить вашу теорию к этому примеру. В начале статьи вы предлагаете заменять объекты какими-то их частями, то есть меняете правило. Но задача стоит работать с множеством объектов, а не других частей.maxstroy
06.06.2017 11:39Вы опять сидите в рамках 3D. Слон — это не просто пространство, это еще и дата начала существования слона и дата окончания — смерти. Рождение нового слона — не пополняет множество слонов, оно пополняет наше знание о множестве слонов, потому что будущее закрыто. Я писал об этом в статье. Множество слонов не меняется, меняется наше знание о нем. Можно сказать и так: дай мне множество слонов, существующих сейчас. Понятно, что множество слонов, существующих сейчас отличается от завтра. Но это будут разные множества.
michael_vostrikov
06.06.2017 11:51«Знание о множестве» это и есть «множество». Потому что иначе нужно предполагать существование множества вне нашего мышления, как реальный объект. А вы ниже утверждали, что реальных объектов не существует, есть только модели в нашем мышлении.
Изменение только «знания о составе множества» подразумевает, что родившийся (после задания этого множества) слон входил в состав множества еще до своего рождения. Это в принципе неправильно, так как предполагает, что будущее (относительно момента задания множества) предопределено, и противоречит вашим другим тезисам, где вы говорили, что будущее вероятностно и имеет много вариантов развития.maxstroy
06.06.2017 11:54Как сказал бы математик — я не понимаю, о чем вы говорите. Я предупредил, что знание о множествах контринтуитивно и обросло мифами, порой религиозными.
VolCh
07.06.2017 10:41«Знание о множестве» это и есть «множество». Потому что иначе нужно предполагать существование множества вне нашего мышления, как реальный объект.
Нам необязательно знать точный состав множества, чтобы им оперировать, достаточно ссылки на правило задания множества или ссылки на перечисление, чтобы описать все необходимые для модели операции над этим множеством. Уточнение состава множества будет происходить непосредственно в момент когда нужно получить результат, зависящий от состава множества.
И, да, слон, родившийся после задания множества правилом "все слоны мира", входит в состав этого множества. На момент задания этого правила мы имеем в виду и таких, ещё не родившихся слонов. Если у нас, например, определена операция "пометить всех живых слонов", то уточнение состава множества "все слоны" и отсеивание из них неживых будет происходить в момент исполнения операции, которая может быть исполнена в момент времени, сколь угодно удаленный в будущее от момента задания множеством правила и операции.
michael_vostrikov
07.06.2017 11:22Нам необязательно знать точный состав множества, чтобы им оперировать
Правильно, оперировать мы будем множеством, а не объектами, входящими в его состав. Мы поэтому его и задаем, чтобы работать с ним как с единым целым, а не с отдельными объектами. Постоянно описание множества (правило), но не его состав.
VolCh
07.06.2017 09:55Формально множество, определенное правилом "все слоны мира" включает, и слонов ещё не родившихся, и слонов уже погибших. На практике чаще используется множество "все известные нам живые слоны мира на данный момент времени", реже — на какой-то момент в прошлом, ещё реже — прогнозы о составе множества (как правило количественные метрики) на какой-то момент времени в будущем. Либо, как вариант, множества типа "все известные нам слоны мира на момент запуска отчёта в будущем".
michael_vostrikov
07.06.2017 11:06Формально наверно да, но это не столь важно. Я о том, что можно придумать правило, зависящее от времени, а раз множество задается правилом, то его состав меняется. Либо это не множество, а что-то другое, значит теория множеств здесь не подходит. Можно как в ФП считать, что это просто разные множества, но это будет неправильное моделирование, так как мы в нашем мышлении считаем, что это один и тот же объект.
maxstroy
07.06.2017 11:15Мышление человека способно ухватить либо пространственные аспекты мира, либо времЕнные. Но нет слов, чтобы передать одновременно и пространственные и временные аспекты. Поэтому у вас множество меняется, хотя оно не меняется. Вы просто движетесь на транспорте вдоль оси времени. А математике нет дела до вашего движения и ваших представлений. Мы сразу строим 4D модель, в которых движение вдоль оси времени — это не более чем трехмерный срез.
michael_vostrikov
07.06.2017 11:31В таком случае множество слонов сегодня и множество слонов завтра это разные множества, и мы не можем с ними работать как с одним объектом. Мы в принципе не сможем работать с ними в реальности, так как ни одно действие не выполняется мгновенно.
Есть загон, в нем на данный момент 3 слона. Сколько элементов во множестве "множество слонов в этом загоне" в вашей 4D модели?
maxstroy
07.06.2017 12:15Множество слонов в загоне может быть лишь в определенный момент времени. данный момент времени мы рассматриваем множество слонов, состоящее из трех элементов. В другое время — это будет уже другое множество. Но в 4D модели множество содержит не слонов, как я писал ранее, а их темпоральные части. И там объектов может быть сколь угодно. Чтобы понять, какие слоны были на заданный момент времени, мы строим подмножество этого множества из тех темпоральных частей, которые актуальны на данное время.
VolCh
06.06.2017 08:17У множества может меняться как состав (в разные моменты времени к множеству могут относится разные объекты, правило задания множества может быть простой функцией от времени), так и правило его задания (правило задания множества может быть функцией высшего порядка от времени, возвращающей разные правила в разные моменты времени).
maxstroy
06.06.2017 08:22Я задал этот вопрос математику. Его ответ меня не порадовал, но был таков: это не множество.
VolCh
06.06.2017 08:26Как мы знаем, что состав множества может быть задан двумя способами:
Непосредственным перечислением объектов, выбранных из какого-то множества.
Правилами идентификации объектов, выбранных из какого-то множества.Как же так? Почему правило идентификации не может быть функцией от времени?
maxstroy
06.06.2017 10:53потому что в теории множеств время — это одна из размерностей множества, в котором определяются подпространства, которые мы называем объектами. Нам надо ввести ось, координаты для этой оси, надо ввести правила, каждое из которых приписано к значению координаты на этой оси, каждое из которых породит свое множество. Это один способ. Второй способ — правило единое, но оно касается темпоральных частей объектов, а не объектов. И в том и в другом случае множества неизменны. Только в первом случае — к нас множество множеств, а во втором — множество темпоральных частей
Azoh
06.06.2017 11:22Потому что получившийся "объект" ведет себя не как множество. На нем не задано отношение принадлежности. Но мы его можем мыслить как функцию, которая результатом будет иметь множество.
maxstroy
06.06.2017 11:44У множества нет поведения. вести себя может только объект.
Что значит: на множестве задать отношение принадлежности? Это значит, сказать, какой объект относится к множеству? Я рассказал как это сделать: надо отнести к множеству не объекты, а их темпоральные части.
aristarh1970
05.06.2017 22:11Все это, конечно, интересно и заслуживает всяческого уважения, но…
Но, похоже, уважаемый автор не понимает (или понимает, но не хочет никому говорить?), что теория множеств не универсальна. Даже, напротив.
В том смысле, что она изначально создавалась как иструмент для исследования достаточно специального класса задач, интересных «фундаментальным математикам».
А именно задач, связанных с понятиями конечности/бесконечности/отображения/количества/меры.
Все. Для моделеривания объектов реального мира, их структуры/поведения/взаимодействия/использования/т.п. — это теория изначально не предназначалась. От слова «совсем».maxstroy
05.06.2017 22:24Очень интересное замечание! Я как раз обратного мнения, Я считаю, что математики всю свою силу направляли на попытку создать язык для описания предметных областей. А то, что они строили обобщения, — это признак их незаурядного ума. Но обобщения при их применении к конкретным задачам напрямую применимы к практическим задачам. Как говорит мой знакомый математик, мне все равно, что моделировать.
aristarh1970
05.06.2017 22:56Метематика оперирует абстракциями. В т.ч. и строит на их основе абстракции более выского уровня. Или менее.
Вы, естественно, в полном праве иметь свою точку зрения. Она интересна, но… Но, право слово, стоит хотя бы попытаться «взойти на плечи гигантов».
Мне, к примеру, очень помогли книшшки Гильтерта по матлогике.maxstroy
06.06.2017 07:58Метематика оперирует абстракциями.
Если вы заявляете это, то должны легко дать определение понятию абстракция. Дайте, пожалуйстаaristarh1970
06.06.2017 18:06(Со вздохом) Вы ошибаетесь, полагая что я вам что-то должен.
Писать определение абстракции мне, честно говоря, лениво. Если вы и его не знаете, то… бяда.maxstroy
06.06.2017 18:31Я знаю — это модель. Вы сказали, что математика оперирует абстракциями, то есть моделями. Моделями чего? чего угодно, в том числе моделями типов и атрибутов. Вот и вопрос: как выглядит модель атрибута с точки зрения математики?
aristarh1970
06.06.2017 19:20Модель предметной области представляется в виде формальной системы в некоем алфавите.
Формальная система есть неоднородная совокупность набора первичных термов («слов»), набора правил композиции термов, набора правил вывода и набора предикатов (который можно раделить на отношения и операции).
Наборы в простейшем случае можно полагать не более, чем счетными множествами.
Эта часть определяет «синтаксическую» компоненту семиотической системы.
Для задания семантической компоненты семиотической системы нужно определить «область интерпретации» и «правила интепретации»…
Синтаксически атрибуты суть разбиения на ис-ходном множетве термов. Синтаксически типы определяются как совокупность подмножествс термов и выделенного набора предикатов.
Для атрибутов и типов правила интерпретации должны обладать определенным исвойствами.
Слушайте, это все по многу раз описывалось к учебниках по представлению знаний и моделированию, неуж-то нужно перепечатывать азы?!..
maxstroy
06.06.2017 19:24Нет, я выдвинул два простых определения типа и атрибута с точки зрения теории множеств. Они читаются за один раз и понятны, что бы вы ни говорили. Попробуйте также просто сформулировать определения этих терминов в модели, о которой вы говорите. Если это трудно, как, например, сформулировать, что такое число 0, то так и скажите, это сложно и дайте ссылку на литературу. Я ее почитаю. Но с точки зрения теории множеств, объясните, чем не устраивает вас мое определение?
aristarh1970
06.06.2017 19:44(Со вздохом) В рамках теории множеств эти понятия не имеют адекватного непротиворечивого определения.
Вам это тут уже говорено не один раз.
Число нуль (хотя это и не относится к обсуждаемому) определяется как класс множеств, изоморфных пустому множеству. Это в рамках теории множеств.
В общей алгебре нуль опредлеяется по-другому, но есть доказательство эвивалентности этих определений.
Книжка, которую надо б почтать перед началом разработки информационных моделей:
«Universal Algebra, Algebraic Logic, and Databases» by Plotkin B.
Вроде бы, издавалссь на русском.
maxstroy
06.06.2017 20:19Спасибо большое! Хотя я не отвергаю своего мнения. Мои определения были выстраданы годами и проверены вдоль и поперек. Пользоваться ими я могу в рамках решаемых задач. Это главное. Более нигде и никогда я не встречал определения типа и атрибута достаточного для моделирования. Хотя в OWL само то, что атрибут определяется через область значений и область определений, наводит на мысль о функции.
aristarh1970
06.06.2017 21:22Увы, «выстраданность» иммет значение в области веры и убеждений.
В инженерном деле, науке вообще и математике в частности имеют значение совсем другие интеллектуальные категории…
Разумеется, при всем том вы можете оставаться при своем мнении, и точно так же раумеется, что это мнение без доказательства обратного может быть неверным.
Естественно, что в OWL атрибут определяется именно так, потому как OWL и разрабатывался с оглядкой на математические основы представления знаний.
maxstroy
07.06.2017 06:59Неожиданно пришло подтверждение моей догадке относительно того, что такое атрибут. Игорь Катричек прислал скрин из книги Е.Киндлера «Языки моделирования» (1979 год, перевод 1985 год), где атрибут определяют похожим образом.
Только в этой книге значения атрибута не образуют множества В моем определении разделение множества на подмножества при помощи значений атрибута более общее, нежели просто значение функции. Я всегда был недоволен делением атрибутов на качественные и количественные, потому что при таком делении не делалось обобщение, — не было общего определения, которое было бы удовлетворительным и для того и для другого случая. Мне удалось их обобщить. И, самое веселое, что при этом атрибут стал рядом с типом, отличаясь от него всего одним словом: тип выделяет объекты в группу, а атрибут разделяет по группам. Согласитесь, что такое понимание более глубокое и простое.
flancer
Я несколько не в теме — а что значит "OWL"?
maxstroy
Краткое введение можно почитать на нашем сайте: http://trinidata.ru/files/SemanticIntro.pdf
flancer
Просканировав наискось 165 стр. краткого введения, пришел к выводу, что OWL — это Web Ontology Language.
maxstroy
Сорри, я думал под вопросом, что значит OWL, имелось ввиду его краткое описание.