Рекомендую ряд полезных утверждений: множество рациональных чисел счётно, множество пар рациональных чисел счётно, между любыми двумя числами есть рациональное число, тем самым разбиение любой фигуры на бесконечное множество квадратиков тоже содержит не более счётного числа элементов.
Две этих разных мощности довольно часто встречаются, поэтому у них есть свои названия.
Есть, но вы одно из них не знаете :-(
Множество с такой же мощностью, как у множества бесконечных двоичных строк, называется несчётным.
Рекомендую почитать про en.wikipedia.org/wiki/Throughput_accounting — книги Голдратта на русском легко находятся. Вы узнаете, как называется модное сочетание unit-экономика на скучном языке обычных бухгалтеров, когда расчёты unit костов в принципе неприменимы, и что делать в этих случаях (очень похоже на то, что вы и делаете :-).
Связь между классами — это и есть класс связей между их членами, поэтому ничего отдельного в ней нет. Надо всего лишь записать ряд свойств для класса связей «Автомобили-колёса», который прекрасно нарисован на третей диаграмме.
Эти свойства в том, что одна роль ограничена «Класс ТМ автомобилей», вторая — «Класс ТМ колёс». Именно в этом смысле (и ни в каком ином) класс отношений является отношением между классами концов этих отношений.
Ну и через обычное утверждение о кардинальностях записываем что есть по 4 члена на каждый автомобиль и по одному на каждое колесо.
На третьей диаграмме не отображено то, что написано текстом: «для каждого автомобиля найдется 4 связи с колесами в классе семантических связей под названием «Автомобиль имеет колесо», для каждого колеса существует только одна такая связь в этом классе. „
А причина этого проста. И на диаграмме, и в текстовом формализме логических моделей это записывается именно как “семантическая связь между классом ТМ автомобилей и классом ТМ колес». Точно с теми же кардинальностями, как на UML и прочих диаграммах.
А фразы "В такой постановке задачи – нет. Есть класс связей между автомобилями и колесами, но нет связи между классом ТМ автомобилей и классом ТМ колес. " — не соответствуют действительности. Ибо это единственный способ разумно записать то самое правило «для каждого автомобиля найдется 4 связи с колесами».
Кажется, принципиальной новацией по сравнению с философскими и онтологическими основами RDF является только ввод обязательного «субъекта» события, который превращает тройку в четвёрку? Да и то обязательность его относительна, ибо есть «абсолютный» субъект.
Тут вопрос в том, для чего пользователь онтологии её пользует. Я, опять таки, работаю с относительно узким применением — для определения некоего нейтрального формата обмена данными. Да ещё и в относительно узкой области — инженерных данных. И там, похоже, подход «сохранить чистоту» таки проиграл. Прагматические критерии для выбора онтологического подхода сохраняются — shared conceptualization is the king. А вот сохранять строгость концептуализации не удаётся. Но реально пока никто не понимает, насколько IT отрасль продвинется хотя бы от использования shared conceptualization. Поэтому никто не будет воевать за чистоту логического подхода по причине каких-то будущих проблем.
Для геометрических характеристик, таких как диаметры, длины, ширины, эксцентриситеты и координаты вообще — модели задаются через отношения со спец-объектами — числами.
Для сущностей типа 4-х болтовое соединение или 10-этажный — через кардинальности отношений.
Но если есть стандартный перечень размеров резьб, например — то только полным перечнем, даже если известна формула или шаг Х, с которым они идут от значения А до значения Б.
Ну я, как вы понимаете, не работаю с «согласованной онтологией», но и «живое» построение онтологии справочных данных, о котором я упоминал, сильно ограничивает возможности верификации. Правила сочетаемости разных классов при построении классификации конкретного объекта для верификации — описываются как паттерны (data shapes теперь вроде бы их надо называть), с практической точки зрения разумные ограничения и сочетания для конкретной предметной области проблемы не составляют.
Что касается автоматического выявления классов, то я сталкивался только с выявлением классов из инженерного текста на естественном языке, и в общем-то пришёл к выводу о наличии двух широких семейств правил — выявление таксономий из структур существительное+определения и выявление классов свойств. Противоречий между ними вроде бы не обнаружил.
А вот выявление функциональной природы каких-то классов кроме как вручную — не знаю как делать.
В каком смысле? Что такое " тип-класс «колесо» "? Кто его ввёл и как определил? Если как «артефакт, отличающийся тем, что он устанавливается на оси, изготовлен специально для обеспечения перемещения методом качения тех предметов, к которым он присоединён, а также тем, что его диаметр больше ширины» — то да, подкласс.
Практически необходимые операции трудностей не вызывают. Например, берётся экстенсионально или функционально определённый класс (Колесо) и пересекается с атрибутно-определённым (Диаметр 70 см).
Проблемы возникают из-за комбинаторного взрыва — нет языка для параметрического определения классов (Диаметр X см.). Но эта проблема вроде бы из другой оперы. Или это та же проблема?
Про индивиды — всё примерно так. Каждый индивид выделяется и классифицируется в зависимости от viewpoint (можете называть это «метод учёта).
Но классы, которые и используются для того, чтобы эти множественные классификации проводить — они как раз есть, и выражают „чистые“ понятия — физические, функциональные, красные, колесо, и т.д.
Да, про типы — это важно. В рамках моего подхода различение искусственно. Типы — удобное название для стандартной верхушки системы классов, не более того. Если есть механизм эффективного согласования мнений и интересов сообщества пользователей — систему типов можно расширять теми типами, которые все считают необходимыми. Если механизма поиска консенсуса нет — число типов остаётся малым, никакой беды.
В системе типов ISO 15926 есть как типы, определяемые экстентом, так и типы, определяемые интентом. И даже типы, определяемые атрибутами есть (правда, на уровне классов классов, то есть тип определён как класс классов, определяемых через наличие атрибутов).
Я не прочитал вашу дискуссию до конца, она многократно разветвилась и, кажется, несколько раз зациклилась :-) Поэтому отвечу тут.
Кроме классов, заданных перечислением и классов, заданных атрибутом, возникает ещё нужда в классах, заданных применением, интентом. Например, это классы функциональных объектов. Колесо — пример такого класса. Шарикоподшипник, надетый на палку в самодельном самокате — классифицируется классом Колесо.
Но проблемы в этом я не вижу. Нет единственной правильной классификации, нет единой таксономии классов. Единственная задача. которую надо решить — это уникальная идентификация классов. Нужны URI.
И, разумеется, нужны правила задания определений. Перечислением, описанием, операциями над множествами.
Если договорённости об идентификации и об определениях достигнуты — можно разрешить создание классов всем желающим.
Это я излагаю подход ISO 15926, разумеется. В его рамках модель мира может быть создана и опубликована по примерно таким правилам.
А всё-таки — чем крокодилы хуже? Точное решение найдено, по нему можно считать. При вычислениях на современной технике длина формул в этих пределах вроде бы не влияет ни на точность, ни на скорость. Какие ещё факторы?
Ну так этот подкласс темпоральных частей на данный момент и является тем индивидом, который должен учитываться в системе. Потому что значение атрибута Вес может быть только у индивида, у класса полагается интервал значений.
Вообще же всегда можно заменить объекты классами по одному объекту, только это замутнит модель данных до неприличия. А цель — прозрачная модель данных.
На самом деле в обоих случаях есть и класс, и индивид (объект хранения).
Во-первых, необходим класс БОЛТ М10, в обоих случаях один и тот же. Это стандартный класс, класс всех болтов данного стандарта в мире, имеет все стандартные атрибуты и не имеет никакого отношения к нашему складу. Лучше бы вообще брать его ID из национальной библиотеки справочных данных.
Во-вторых, есть объект хранения, индивид.
По второму варианту тут всё очевидно, индивиды индивидуализированы метками, классифицированы классом БОЛТ М10.
По первому варианту надо повозиться, если есть желание достичь строгости. Надо написать логическое утверждение о том, что темпоральные части нашего хранимого индивида состоят из объектов, классифицированных классом БОЛТ М10. У этих темпоральных частей (индивидов!) есть атрибут ВЕС.
Но в обоих случаях у склада связь ХРАНИТ с индивидом, несколькими или одним.
Никогда не делаются утверждения «склад хранит класс» или «машина состоит из класса». Всякий класс — вечен и неизменен, поэтому нет никакой разумной и удобной для имплементации возможности считать хранимым объектом какой-бы то ни было класс. Всё это верно в рамках той парадигмы моделирования, которой я занимаюсь, разумеется.
Я давно прочитал, не хотел высказываться. Но Вы, говорят, прямо интересовались моим мнением. Поэтому скажу так:
Мне неизвестна формальная логическая система, в которой было бы верно данное Ваше утверждение:
«Можно сказать, что машина состоит из класса колес, как двигатель состоит из класса болтов, как табуретка состоит из класса молекул. При этом мы не можем сказать, как именно машина состоит из колес, потому что в такой риторике нет координат, которые описывали бы местоположение колес в машине. В таком случае мы обычно говорим — машина состоит из пяти колес.»
Возможно, такую систему можно разработать, не знаю.
Кстати, ещё одно название для получающихся моделей данных — безатрибутные. Я тут про это лекцию читал с простыми примерами для студентов — www.youtube.com/watch?v=Ioi68tNLmYw
При любой стороне квадрата.
Есть, но вы одно из них не знаете :-(
Континуум оно называется.
Эти свойства в том, что одна роль ограничена «Класс ТМ автомобилей», вторая — «Класс ТМ колёс». Именно в этом смысле (и ни в каком ином) класс отношений является отношением между классами концов этих отношений.
Ну и через обычное утверждение о кардинальностях записываем что есть по 4 члена на каждый автомобиль и по одному на каждое колесо.
На третьей диаграмме не отображено то, что написано текстом: «для каждого автомобиля найдется 4 связи с колесами в классе семантических связей под названием «Автомобиль имеет колесо», для каждого колеса существует только одна такая связь в этом классе. „
А причина этого проста. И на диаграмме, и в текстовом формализме логических моделей это записывается именно как “семантическая связь между классом ТМ автомобилей и классом ТМ колес». Точно с теми же кардинальностями, как на UML и прочих диаграммах.
А фразы "В такой постановке задачи – нет. Есть класс связей между автомобилями и колесами, но нет связи между классом ТМ автомобилей и классом ТМ колес. " — не соответствуют действительности. Ибо это единственный способ разумно записать то самое правило «для каждого автомобиля найдется 4 связи с колесами».
Для геометрических характеристик, таких как диаметры, длины, ширины, эксцентриситеты и координаты вообще — модели задаются через отношения со спец-объектами — числами.
Для сущностей типа 4-х болтовое соединение или 10-этажный — через кардинальности отношений.
Но если есть стандартный перечень размеров резьб, например — то только полным перечнем, даже если известна формула или шаг Х, с которым они идут от значения А до значения Б.
Что касается автоматического выявления классов, то я сталкивался только с выявлением классов из инженерного текста на естественном языке, и в общем-то пришёл к выводу о наличии двух широких семейств правил — выявление таксономий из структур существительное+определения и выявление классов свойств. Противоречий между ними вроде бы не обнаружил.
А вот выявление функциональной природы каких-то классов кроме как вручную — не знаю как делать.
Проблемы возникают из-за комбинаторного взрыва — нет языка для параметрического определения классов (Диаметр X см.). Но эта проблема вроде бы из другой оперы. Или это та же проблема?
Про индивиды — всё примерно так. Каждый индивид выделяется и классифицируется в зависимости от viewpoint (можете называть это «метод учёта).
Но классы, которые и используются для того, чтобы эти множественные классификации проводить — они как раз есть, и выражают „чистые“ понятия — физические, функциональные, красные, колесо, и т.д.
В системе типов ISO 15926 есть как типы, определяемые экстентом, так и типы, определяемые интентом. И даже типы, определяемые атрибутами есть (правда, на уровне классов классов, то есть тип определён как класс классов, определяемых через наличие атрибутов).
Кроме классов, заданных перечислением и классов, заданных атрибутом, возникает ещё нужда в классах, заданных применением, интентом. Например, это классы функциональных объектов. Колесо — пример такого класса. Шарикоподшипник, надетый на палку в самодельном самокате — классифицируется классом Колесо.
Но проблемы в этом я не вижу. Нет единственной правильной классификации, нет единой таксономии классов. Единственная задача. которую надо решить — это уникальная идентификация классов. Нужны URI.
И, разумеется, нужны правила задания определений. Перечислением, описанием, операциями над множествами.
Если договорённости об идентификации и об определениях достигнуты — можно разрешить создание классов всем желающим.
Это я излагаю подход ISO 15926, разумеется. В его рамках модель мира может быть создана и опубликована по примерно таким правилам.
Вообще же всегда можно заменить объекты классами по одному объекту, только это замутнит модель данных до неприличия. А цель — прозрачная модель данных.
На самом деле в обоих случаях есть и класс, и индивид (объект хранения).
Во-первых, необходим класс БОЛТ М10, в обоих случаях один и тот же. Это стандартный класс, класс всех болтов данного стандарта в мире, имеет все стандартные атрибуты и не имеет никакого отношения к нашему складу. Лучше бы вообще брать его ID из национальной библиотеки справочных данных.
Во-вторых, есть объект хранения, индивид.
По второму варианту тут всё очевидно, индивиды индивидуализированы метками, классифицированы классом БОЛТ М10.
По первому варианту надо повозиться, если есть желание достичь строгости. Надо написать логическое утверждение о том, что темпоральные части нашего хранимого индивида состоят из объектов, классифицированных классом БОЛТ М10. У этих темпоральных частей (индивидов!) есть атрибут ВЕС.
Но в обоих случаях у склада связь ХРАНИТ с индивидом, несколькими или одним.
Никогда не делаются утверждения «склад хранит класс» или «машина состоит из класса». Всякий класс — вечен и неизменен, поэтому нет никакой разумной и удобной для имплементации возможности считать хранимым объектом какой-бы то ни было класс. Всё это верно в рамках той парадигмы моделирования, которой я занимаюсь, разумеется.
Мне неизвестна формальная логическая система, в которой было бы верно данное Ваше утверждение:
«Можно сказать, что машина состоит из класса колес, как двигатель состоит из класса болтов, как табуретка состоит из класса молекул. При этом мы не можем сказать, как именно машина состоит из колес, потому что в такой риторике нет координат, которые описывали бы местоположение колес в машине. В таком случае мы обычно говорим — машина состоит из пяти колес.»
Возможно, такую систему можно разработать, не знаю.