概念：セット、タイプ、属性

数学者は怠けすぎて、平均的な人の言語で実数を説明することができません。 一般の人が数学者によって書かれたアイコンを読むことは困難です。なぜなら、それらの意味は彼にとって明らかではないからです。 その結果、理論と実践の間にはギャップがあります。 理論的には、数学者はオブジェクトの種類と属性が何であるかを完全によく知っていますが、実際には、それが何であるかを理解している実践者はほとんどいません。 多くの直感的な概念がありますが、それらはそれぞれ知識というより宗教的な教義のようなものです。 この記事では、複雑なアイコンのない単純な言語で集合論の基礎を説明することで、数学者と申請者のギャップを埋めようとしました。 たとえば、属性の定義に精通していますか？ 正式な定義を見つけることができなかったため、私は自分で苦しみました。 そして、その後、イゴール・カトリチェクは、属性を定義するE. Kindlerの本「Modeling Languages」（1979年、1985年翻訳）へのリンクを送ってきました。


この記事では、簡単に想像できるように、独自のより一般的な属性の定義を示します。

前回の記事「 構造モデリング」。 モデラーの要件私は、私たちが全体として考えるいくつかのオブジェクトが私たちの意識の中に存在するが、私たちによって明確に理解されていないことを言った。 数学者はこれに気づき、これに多数の概念を導入することでそれを明確にした。 また、 多数の概念とオブジェクトの概念は、他の概念からは還元できない公理であることを思い出しました。 さらに、オブジェクトの概念は私たちに馴染みがあり、それらを扱うのに十分な経験がありますが、数学の基礎を研究するときに研究所で多くを知るようになり、それらの概念はそれほど明白ではありません。 もっと明確に表現する方法を学ぶ機会を探している人のために、デザインの表現において、良いイメージを見つけることができる場所について話しました。 この記事では、セットに関する話を続け、セット理論の観点からどのタイプと属性かを説明します 。 そして最も重要なこと-私たちが構築しているモデルにこれらの概念がどのように反映されているかを説明します。

数学と物理学のセット

私たちは世界を空間または時間として認識していますが、同時に両方を想像することはできません。 これは、使用する言語と構築するモデルに制限を課します。

たとえば、数学的セットとその操作は時間内に存在しません。 これは、セットの構成が時間とともに変化するとは言えないことを意味します。

私にはこれは直感に反し、自明ではない要件のように思えますが、それなしではセットの操作を実行して比較することはできません。 これは、砂の山に多くの砂の粒を記述したい場合、これを行うには2つの方法があることを意味します：砂の粒の新しい組成ごとに、新しいセットを導入するか、調査した山の砂の粒の多くの一時的な部分を考慮する。 砂粒の一時的な部分は一時的なものとして理解され、私は属性を持つ砂粒の一部です：始まりと終わり、ヒープ内のこの砂粒の存在をシミュレートします。 この一時的な部分のセットは、4Dパラダイムで実行される4D表現とも呼ばれます。 特定の瞬間の砂粒の組成は、このセットから時間スライスによって取得できます。特定の時間に「関連する」砂粒の時間部分、つまり、選択された時間よりも早くヒープに現れ、ヒープから離れた部分のみを選択します。 。

これは、実際の「物理」セットの構成をシミュレートします。 しかし、現在の記事では、そのような表現はかなり複雑になります。私は、時間内に「フリーズした」、つまり「時間外」に存在する単純なセットの通常の表現に戻ります。

セットの構成の決定

多数は全体として非常に多く、構図は多数である。 セットの構成を決定する方法を検討してください。 知っているように、セットの構成は2つの方法で定義できます。

1. あるセットから選択されたオブジェクトの直接列挙。
2. あるセットから選択されたオブジェクトを識別するためのルール。

たとえば、他のオブジェクトの中で部屋に2つのオブジェクトがあると仮定します：白いプレートと緑のマーカー。

1. これら2つの要素で構成されるセットAは、リストで指定できます。白いプレートはセットAの一部であり、緑のマーカーはセットAの一部です。部屋の他のセットはセットAの一部ではありません。
2. それ以外の方法で行うことができます。 プレートとマーカーに黄色のステッカーを貼り付けて、部屋に他のステッカーがないことを確認できます。 それから、黄色のステッカーがあるこの部屋のオブジェクトのみがセットAの一部であると言えます。

構成を決定する最初の方法は、リストすることです
2番目の方法は、識別条件を設定することです。

前回の記事の議論で、セットの構成を決定するこれら2つの方法の違いを誰もが明確に理解しているわけではないことに気付きました。 したがって、それらについて詳しく説明します。

最初の方法は、一連のステートメントに基づいています。

プレートはセットAの一部です。
マーカーはセットAの一部です
セットAには誰もいません。

2番目の方法は、述語で言うことです。

黄色のステッカーが付いている部屋の唯一のオブジェクトはAの一部です。

構成を記述するための最初の方法では、任意のオブジェクトモデルが参加できます。 2番目の記述方法では、オブジェクトモデルには1つの共通属性が必要です。この属性の値によって、オブジェクトがセットに含まれるかどうかが決まります。 つまり、オブジェクトモデルに共通の属性がない場合、識別条件を構築することはできません。

この記事の議論では、列挙の助けを借りてセットへのエントリ自体も属性にすることを提案しました：「それはセットAの一部です」。 したがって、セットAにあるオブジェクトには、この属性の値「yes」があります。 次に、この属性に基づいて、同じセットAの構成で選択のサインを作成することが提案されました。値「yes」を持つオブジェクトはセットAの一部です。このアイデアの著者は、これら2つのステートメントの論理的結論の結果として、 2つのトートロジーを取得します。

セットAには、セットAの一部であるオブジェクトのみが含まれ 、

オブジェクトは、セットAの一部である場合にのみ、セットAの一部です。

これらの明白なステートメントには、特定のオブジェクトやAに関する情報は含まれていません。プレートを取得した場合、このステートメントに基づいて、セットAに属するかどうかを判断することはできません。

したがって、列挙とルールは、セットの構成を記述する2つの根本的に異なる方法であり、数学では、セットの構成を決定する2つの基本的かつ完全に異なる方法として示されます。

ところで、機能とは何かを決定することについては、かつて長い議論がありました。 この紛争は、どの識別ルールが正しいとみなされ、どの識別ルールが正しくないと判断できなかったために生じました。 その結果、すべてのルールが正しいと見なされるというディリクレの考えが採用されました。 そのため、すべてのルールの分類をすことはしませんが、このコンテキストでは必要な少数のルールのみを検討します。

教科書では、識別規則はしばしば選択規則と呼ばれます。 「選択ルール」という用語は、ある種の選択操作を伴うため誤解を招きます。 これは、セットを補充できるというヒントです。 しかし、これはそうではありません。 多くは固定構成です。 したがって、選択についてではなく、識別について話すことをお勧めします。 要素を多数に選択するのではなく、それらを多数の要素として識別します。

サブセットの構成を決定する

多くのアフリカゾウの組成をどのように決定するか見てみましょう。 これを行うには4つの異なる方法を数えました。

1. リストすることでそれらを定義できます。
2. 象にステッカーを貼り付けることができ、接着されたステッカーを持つ象はアフリカ人と見なされます。 これは、属性を介したセットの構成の定義です。 属性は、ステッカーの有無と見なされます。
3. 象のセットとアフリカに住む動物のセットの2つのセットの交差点から構成を決定できます。
4. 「アフリカゾウ」などのコンセプトを紹介できます。

作業でOWLを使用すると、サブセットを定義するための上記の3つのメソッドを実装できます。

1. サブセットに含まれるオブジェクトを明示的に列挙し、
2. 属性の値を所有するという事実からこの特定の範囲に入るまで、さまざまな操作で、属性の条件を通じて識別ルールを定義する
3. 他のセットの操作を定義します。たとえば、セットAの構成には、セットBの一部であり、セットCには含まれないオブジェクトのみが含まれます。

オブジェクトのタイプを使用して4番目の識別方法を実装できるかどうかを理解するために、より詳細に検討します。

型を使用したサブセットのモデリング

「アフリカゾウ」のタイプを決定するには、次のものが必要です。

1. サブタイプのオブジェクトを選択するオブジェクトのグループ。 この場合、このグループには名前があります-これは象のグループです。
2. タイプオブジェクトがグループの他のオブジェクトと異なるユニークなプロパティ：アフリカに住んでいます。
3. このタイプのオブジェクトの一意の名前

そうでなければ、アフリカに住んでいる動物をグループとして連れて行くことができます。 そして、アフリカゾウを他のアフリカの動物と区別するユニークな特性は、これらの動物がゾウであることです。

合計、タイプの定義を提供するには、以下が必要です。

1. 過剰なオブジェクトを指定します。
2. グループオブジェクトから特定のタイプのオブジェクトの特徴的な機能（差分プロパティ）を示します。
3. このタイプのオブジェクトの名前を指定します

さらに、次を指定できます。

• このタイプのオブジェクトが需要になった理由（このタイプのオブジェクトの異なる機能特性
• このタイプのオブジェクトを導入する利点
• 学歴
• 等

同じタイプのオブジェクトは、いくつかの一意のプロパティがスーパーセットの他のオブジェクトと異なります。 この一意のプロパティは、属性の条件によってモデル化できます。 ただし、すべての属性のすべての値が一致している必要はなく、同じタイプのすべてのオブジェクトの属性の構成が同じである必要もありません。

タイプが何であるかを知ると、サブセットを選択する4番目の方法は2番目と同じであると考えるかもしれません。 ただし、タイプを決定するには、少なくとも特殊な名前を追加で指定し、オプションとして、タイプの他の属性を指定する必要があります。たとえば、このタイプのオブジェクトを区別する理由、用語の履歴などを指定します。 2番目の方法を使用すると、これは不可能です。 したがって、4番目の方法は2番目の方法とは異なり、私が知っているモデリング標準にはまだ実装されていません。

コンセプトタイプ

したがって、集合論の観点から：

タイプは、サブセットとオーバーセットを区別し、このサブセットのオブジェクトに新しい名前を割り当てる方法です

オーバーセットがない場合、タイプは公理的、既約と見なされます。 前述のように、オブジェクトの概念とセットの概念は、オブジェクトのオーバーセットを指定できないため、既約の概念です。

オブジェクトのタイプと多くのオブジェクトの違い

この記事の議論から、オブジェクトのタイプと多くのオブジェクトが関連する概念または同じものであると信じる人々がいることに気付きました。 なぜそうではないのか説明しようと思います。 タイプは、オブジェクトを識別するためのルールであり、これらのオブジェクトの名前でもあります。 つまり、このタイプは、セットからのサブセットの特殊化（または分離）の両方を行い、特殊化されたオブジェクトに新しい名前を付けます。

各タイプはセットの構成を決定しますが、すべてのセットがその構成を決定するタイプに対応するわけではありません。例えば、その要素をリストすることで構成が指定されているセットについて話すとき、または要素に名前がないセットについて話すときです。

セットを設定するルールがセット自体ではないことは明らかです。

上記のことから、「オブジェクトのタイプ」の概念が「多くのオブジェクト」の概念とどのように異なるかは明らかです。

同じタイプのオブジェクトのモデリング

多くの場合、IPでは、同じタイプのオブジェクトは、同じ属性セットを含むモデルを使用してモデル化されます。 同じタイプのオブジェクトは異なる属性セットを持つことができるため、この制限は冗長であることがわかります。 この制限は、実装の技術的特徴によって引き起こされますが、サブジェクト領域の要件によるものではありません。

IPでは、同じタイプのオブジェクトのリストが補充されます。 これは、モデル化するセットの変数構成を示唆しています。 しかし、これはそうではありません。 IPに登録されているオブジェクトのリストは、セットの完全なリストではありません。 つまり、ISには、セットのすべての要素のモデルではなく、現在登録されているモデルのみが格納されます。 したがって、リクエストを行うときの意味は次のとおりです。IPに現在登録されているこのタイプのすべてのオブジェクトを教えてください。

オブジェクトのライフサイクル

オブジェクトは特定のタイプのオブジェクトに起因する可能性があるという事実に加えて、忘れてはならない2つのポイントがあります。

1. 分類（オブジェクトを特定のクラスまたはオブジェクトのタイプに割り当てる）は常に主観的です。 異なる視点からの同じオブジェクトは異なって見えるかもしれません。 拡張ドメインモデルを構築する場合、その使用にはさまざまな利害関係者の存在が関係するため、コンテキストとさまざまな視点をモデル化する可​​能性があるはずです。 さらに、異なる観点から、同じオブジェクトを異なるタイプに帰属させることができます。
2. オブジェクトのライフサイクルを考慮することには、オブジェクトの変化を考慮するだけでなく、オブジェクトの認識と変化のプロセスも合成と分析のプロセスと共に進行しているため、このオブジェクトに対する認識の変化も考慮する必要があります。

オブジェクト化とオブジェクト化解除のプロセスは次のようになります。

オブジェクト化

型の考えを持ち、私たちは私たちの周りの世界でこれらの型のオブジェクトを見つけようとします。 原則として、見つかったオブジェクトは最も広いタイプに属します。 たとえば、企業について話している場合、最初のステップで、見つかったオブジェクトは操作、機能、およびオブジェクトに関連付けることができます。 または、植物について話している場合、最初にそれらを木、草、低木に分けます。 次に、さまざまな仮説をテストすることにより、オブジェクトのタイプを絞り込みます。 改良のプロセスでは、この知識を実際に効果的に使用できるように、オブジェクトについて十分に説明する型を見つけようとします（このオブジェクトの原因となるより狭い型を見つけようとしています）。 改良の過程で、オブジェクトのモデルは新しい詳細で生い茂ります。 並行して、実際にこのオブジェクトに関する知識を使用します。 この知識の適用が成功した場合、オブジェクトは正しく受信され、正しく分類されたと見なされます（オブジェクトのタイプが正しく選択されます）。

非オブジェクト化

しかし、すべてが変化します。私たちを取り巻く世界についての考え方が変わり、新しい知識が現れます。その結果、オブジェクトのモデルは実用性の要件を満たさなくなります。 そして、オブジェクトのあまりにも狭い専門化が敵になります。 オブジェクトは再分類され（アプリケーションは要件になっています）、エーテルまたは発熱体が破壊されたため、完全に破壊されることもあります。 そして、サイクルが再び始まります。オブジェクトの選択、オブジェクトに関する知識の洗練など。

ケーススタディ：

オブジェクト化：

クライアントが申し込みに来てみましょう。 アプリケーションが実行されない限り、ある程度の確率でのみそのタイプを知ることができます。 したがって、最も幅の広いタイプのアプリケーションが最初に登録されます。 その後、詳細が明確になり、その実行の過程で、アプリケーションモデルは新しい属性で大きくなりすぎます。 しばらくすると、このアプリケーションがどのタイプのアプリケーションに属しているかが明らかになり、最終的な分類が行われます。

非オブジェクト化：

インターネット上で情報を見つけるための典型的なシナリオがあるとします。 必要な情報を見つける必要があるときはいつでも、そのような検索エンジン、つまり必要な情報を検索するプログラムを使用してください。 検索操作を実行するたびに、このプログラムを繰り返し使用してみましょう。 このプログラムの運用中にはこのような操作が多くあり、それらはすべて「情報検索」タイプの操作として分類されました。 しばらくして、検索エンジンがスパイ機能を実行し、この情報に関心のあるユーザーにユーザーデータを「流出」させることが判明しました。 そして、この検索エンジンが使用したこれらの操作は、情報検索操作から関係者へのデータ転送操作に再分類されることがわかりました。 しかし、このプログラムについて何か他のことを学び、その後、それが参加した他の操作を確認する必要があることが判明する可能性があります。

型モデラーの要件

モデリングタイプ用に設計されたモデラーの要件を策定します。

1. 属性の構成が一致しない同じタイプのオブジェクトをシミュレートできる必要があります
2. オブジェクトを1つのタイプに区別するルールをモデル化できる必要があります
3. 他のタイプ属性をモデル化する必要性：特定のタイプのオブジェクトの名前、この名前の履歴など。
4. 同じオブジェクトで異なる視点をシミュレートできる必要があります
5. オブジェクトのライフサイクルをシミュレートできる必要があります。
6. 時間の経過に伴うオブジェクトの理解の変化をモデル化できる必要があります。

データベース構造に頼らずにIT業界でこれらの要件を実装する方法は？ データ構造に頼らずに、さまざまな視点を考慮し、新しいタイプのオブジェクトを追加し、オブジェクトのタイプを改良し、必要に応じてオブジェクトを再分類する方法は？

OWLを使用したオブジェクトモデリング

OWLには1つの制限があります：オブジェクトのセットとタイプは同じです。 このため、オブジェクトタイプをモデリングするための機能が制限されています。 ただし、次の機能があるため、この機能は他のモデリング方法が提供する機能よりもはるかに幅広いものです。

• OWLにオブジェクトの新しいセットを追加することは、新しいオブジェクトを追加することと同じです。
• オブジェクトのタイプがわかっている場合、事前にわかっている特定の属性を使用してオブジェクトのモデルを作成する必要があります。 この場合、作成後に属性を追加または削除できます。 例：アプリケーションモデルの作成では、属性値（アプリケーション番号、申請日、申請者、宛先）を指定する必要がある場合があります。 OWLのこれらの属性はオブジェクト型とは別に存在することを覚えておく必要があります。 また、1つの属性を異なるセットのオブジェクトのモデリングに使用できます。 これは、属性が1つのタイプのオブジェクトのフレームワーク内にのみ存在する一般的なプログラミング言語との根本的な違いです。 別のタイプの別の属性は、同じと呼ばれますが、別の属性になります。
• あなたは反対を要求することができます：オブジェクトモデルの属性に基づいてモデル化されたオブジェクトのサブセットを定義し、オーバーセットに属します。 これを行うには、特定のオーバーセットに属するオブジェクトのモデルにそのような属性が含まれ、その値が特定のルールを満たす場合、オブジェクトが特定のサブセットに自動的に割り当てられるというルールで記述されます。 したがって、ルールの助けを借りて、いわゆるアヒルの分類が実装されます。 たとえば、アプリケーションモデルに「電話番号」属性の値があり、「接続」が「実行された仕事の種類」属性の値である場合、アプリケーションは電話番号を接続するためのアプリケーションとして自動的に分類されます。

セットをサブセットに分割する

多くのオブジェクトがあるとします。 そして、このセットを7つのサブセットに分割し、各サブセットに「赤のオブジェクト」、「黄色のオブジェクト」という独自の色を割り当てます。 などなど。

セットをサブセットに分割するには、さまざまな方法があります。

1. オブジェクトをリストすることでサブセット間でオブジェクトを分散させることにより、セットを互いに素なサブセットに分割できます。 7つのサブセットを作成し、各サブセットに属するオブジェクトをリストします。
2. サブセットごとに、独自のサブタイプを考え出すことができます。 次に、「赤オブジェクトのタイプ」、「黄色オブジェクトのタイプ」などの7つのサブタイプを導入することで、セット全体を7つのサブセットに分割できます。各オブジェクトは、たとえば、オブジェクト。
3. 属性とその値を使用してスーパーセットを分割できます。 たとえば、Color属性とその7つの値（Red、Yellowなど）を入力できます。 次に、色の名前がオブジェクトの形容詞になり、赤いオブジェクト、黄色のオブジェクトなどのように聞こえます。

OWLの最初のメソッドは、7つの異なるクラスを作成し、それらに属するオブジェクトを指定することにより実装されます。

2番目の方法は、3つの異なる方法で実装できます。

1. 1つのタイプで結合された個別のサブセットを作成しますが、前述したように、タイプ自体はモデル化されません。 この方法は、列挙分離方法と違いはありません。
2. リファレンスブック「カラーオブジェクトのタイプ」を使用します。その値は、「赤いオブジェクト」、「黄色のオブジェクト」などのタイプをモデル化するオブジェクトになります。
3. 「オブジェクトタイプ」という名前の属性を使用し、その値は「赤いオブジェクトのタイプ」、「黄色のオブジェクトのタイプ」などのテキスト形式になります。

IPでセットをサブセットに分割する3番目の方法は、2つの方法でモデル化されます。

1. 「Colors」ディレクトリを使用して、その値は、赤、黄などの属性の値をモデル化するオブジェクトになります。
2. 「Color」という名前の属性を使用します。値のテキスト形式は「red」、「yellow」などです。

型と属性を使用した分離は、2つのケースで同じ方法でモデル化されていますが、名前が異なることがわかります。 実際、OWLの属性値の所有は、そのようなトリプルによってモデル化されています。

＃オブジェクト＃属性＃値

クラスに属するのは次のとおりです。

＃rdfオブジェクト：タイプ＃クラス

つまり、クラスに属することは、標準-rdf：typeで定義されている特別なサービス属性を使用して単純に表現されていると言えます。

コンセプト属性

私たちは声明を述べます：

属性は、複数のオブジェクトをサブセットに分割する方法です。 さらに、各属性値は、その値を持つ属性を持つオブジェクトを持つ特定のサブセットに対応します。

属性を使用したサブセットのモデリング

上記のサブセットモデリング方法の3つの方法には、それぞれ、コンテキストと選択した実装方法に応じて利点と欠点があります。

サブセットが少ない場合は、リストされているサブセットへの分離方法と実装を選択できます。

サブセットが多数ある場合（制限内で、たとえば、各セットが同じ長さのオブジェクトのグループをグループ化する場合など、無限です）、正式に残ります。

1. タイプのモデリングの3番目の方法
2. 属性をモデル化する2番目の方法。

ただし、各タイプに名前を付ける必要があることを以前に書きました。 多数のサブセットが（無限に）ある場合、それぞれに名前を付けるのは非現実的です。 したがって、型を使用してこのような区分をモデル化しません。 そのような区分は、値の範囲が一般的なセットの1つになる属性の助けを借りてのみモデル化されます。実数のセット、時間スケールをシミュレートするセット、自然数のセット、有限長の線のセットなどです。 データ型を認識していますか？

関数についてだけでなく、多くのサブセットで関数がどのように導入されるかについて読むことができます。

属性を実装する3番目の方法は、それを使用して膨大な数のサブセットをシミュレートできるという点で優れています（文字列を記述するためのオプションがたくさんあります） ""赤） "同じセットの値ですか、違うのですか？

サブセットをより良くモデル化する方法について多くの文献が書かれていますが、ここでは繰り返しません。 属性はサブセットモデルであり、値はサブセットの指標であることを忘れないでください。