マルチパラダイムプログラミング言語を設計します。パート3-知識表現言語の概要

ドメインモデルを記述するための宣言的な論理スタイルをサポートするマルチパラダイムプログラミング言語の作成についての話を続けます。過去の出版物はこことここにあります。次に、ドメインモデル記述言語の主な機能と要件について説明します。しかし、最初に、知識を表現するための最も人気のある言語の簡単な概要を作りましょう。これは長い歴史を持つかなり広範な分野であり、論理プログラミング、リレーショナル計算、セマンティックWebテクノロジー、フレーム言語など、多くの分野が含まれています。Prolog、SQL、RDF、SPARQL、OWL、Floraなどの言語を比較し、設計されたマルチパラダイムプログラミング言語で役立つ機能を強調したいと思います。

プロローグ

ロジックプログラミングとProlog言語から始めましょう。主題分野に関する知識は、一連の事実と規則としてその中に提示されます。事実は即時の知識を説明します。前の投稿の例の顧客（ID、名前、電子メールアドレス）と請求書（アカウントID、顧客、日付、支払額、支払額）に関する事実は次のようになります。

client(1, "John", "john@somewhere.net").
bill(1, 1,"2020-01", 100, 50).

ルールは、他のルールや事実から推測できる抽象的な知識を記述します。ルールは頭と体で構成されています。ルールの先頭で、その名前と引数のリストを指定する必要があります。ルールの本体は、論理演算AND（コンマで指定）およびOR（セミコロンで指定）によって接続された述語のリストです。述語は、ファクト、ルール、または比較演算、算術演算などの組み込み述語にすることができます。ルールヘッドの引数と本体の述語の引数との関係は、ブール変数を使用して設定されます。同じ変数が2つの異なる引数の位置にある場合、これは、これらの引数が同一であることを意味します。ルール本体の論理式がtrueの場合、ルールはtrueと見なされます。ドメインモデルは、一連の参照ルールとして定義できます。

unpaidBill(BillId, ClientId, Date, AmoutToPay, AmountPaid) :- bill(BillId, ClientId, Date, AmoutToPay, AmountPaid), AmoutToPay < AmountPaid.
debtor(ClientId, Name, Email) :- client(ClientId, Name, Email), unpaidBill(BillId, ClientId, _, _, _).

2つのルールを設定しました。最初に、未払いの請求額より少ない請求書はすべて未払いの請求書であると主張します。第二に、債務者は少なくとも1つの未払いの請求書を持っているクライアントです。



Prologの構文は非常に単純です。プログラムの主な要素はルールであり、ルールの主な要素は述語、論理演算、および変数です。ルールでは、変数に注意が向けられます。変数はモデル化された世界のオブジェクトの役割を果たし、述語はそれらのプロパティとそれらの間の関係を記述します。債務者ルールの定義では、ClientId、Name、およびEmailオブジェクトがクライアントとunpaidBillの関係によって関連付けられている場合、それらも債務者の関係によって関連付けられると述べています。 Prologは、問題が一連のルール、ステートメント、または論理ステートメントとして定式化される場合に役立ちます。たとえば、自然言語の文法、コンパイラ、エキスパートシステムで作業する場合、コンピュータ、コンピュータネットワーク、インフラストラクチャオブジェクトなどの複雑なシステムを分析する場合です。繁雑、複雑なルールシステムは、明示的に説明し、Prologランタイムに任せて自動的に処理するのが最適です。



プロローグは一次ロジックに基づいています（高次ロジックのいくつかの要素が含まれています）。推論は、SLD解決（選択的線形確定句解決）と呼ばれる手順を使用して実行されます。単純化すると、そのアルゴリズムはすべての可能なソリューションのツリートラバーサルです。推論手順は、ルール本体の最初の述語のすべての解を見つけます。ナレッジベースの現在の述語が事実のみで表されている場合、解決策は、変数の値への現在のバインドに対応するものです。ルールによる場合は、ネストされた述語の再帰的なチェックが必要です。解決策が見つからない場合、現在の検索ブランチは失敗します。次に、見つかった部分的なソリューションごとに新しいブランチが作成されます。各ブランチで、推論手順は見つかった値を変数にバインドします、現在の述語に含まれ、述語の残りのリストの解決策を再帰的に検索します。述語リストの最後に達すると、作業は終了します。ルールを再帰的に定義する場合、ソリューションの検索は無限のループに入る可能性があります。検索手順の結果は、ブール変数への値のすべての可能なバインディングのリストです。



上記の債務者ルールの例では、解決ルールは最初にクライアント述語の1つのソリューションを見つけ、それをブール値に関連付けます：ClientId = 1、Name = "John"、Email = "john@somewhere.net"。次に、この変数値のバリアントに対して、次の述語unpaidBillに対してソリューションが実行されます。これを行うには、ClientId = 1の場合、最初に述語請求書の解決策を見つける必要があります。結果は、変数BillId = 1、Date = "2020-01"、AmoutToPay = 100、AmountPaid = 50のバインディングになります。最後に、AmoutToPay <AmountPaidがチェックされます。組み込みの比較述語で。

セマンティックネットワーク

セマンティックネットワークは、知識を表す最も一般的な方法の1つです。セマンティックWebは、有向グラフ形式のサブジェクトエリアの情報モデルです。グラフの頂点はドメインの概念に対応し、円弧はそれらの間の関係を定義します。







たとえば、上の図のグラフによると、「クジラ」の概念は、「哺乳類」の概念と「is」（「is」）の関係に関連付けられ、「水」の概念に「住んでいる」と関連付けられています。したがって、サブジェクト領域の構造（含まれる概念とそれらが互いにどのように関連しているか）を正式に設定できます。そして、そのようなグラフを使用して、質問に対する答えを見つけ、そこから新しい知識を引き出すことができます。たとえば、関係「is」がクラスとサブクラスの関係を示し、サブクラス「Whale」がそのクラス「Mammal」のすべてのプロパティを継承する必要があると判断した場合、Whaleが「Spine」を持っているという知識を推測できます。

RDF

セマンティックWebは、マシン処理に適した形式で情報の表示を標準化することにより、World WideWebのリソースに基づいてグローバルセマンティックネットワークを構築する試みです。このために、情報はHTMLタグの特別な属性の形式でHTMLページに追加で埋め込まれます。これにより、コンテンツの意味をオントロジーの形式（一連の事実、抽象的な概念、およびそれらの間の関係）で記述することができます。



WEBリソースのセマンティックモデルを記述するための標準的なアプローチは、RDF（リソース記述フレームワークまたはリソース記述フレームワーク）です。それによると、すべてのステートメントは、トリプレット「サブジェクト-述語-オブジェクト」の形式である必要があります。たとえば、「クジラ」の概念に関する知識は次のように表されます。「クジラ」は主題であり、「住んでいる」-述語、「水」-オブジェクトです。このようなステートメントのセット全体は、有向グラフを使用して記述できます。サブジェクトとオブジェクトはその頂点であり、述語はアークであり、述語アークはオブジェクトからサブジェクトに向けられます。たとえば、動物の例のオントロジーは次のように説明できます。

@prefix : <...some URL...>
@prefix rdf: <http://www.w3.org/1999/02/rdf-schema#>
@prefix rdfs: <http://www.w3.org/2000/01/22-rdf-syntax-ns#>
:Whale rdf:type :Mammal;
:livesIn :Water.
:Fish rdf:type :Animal;
:livesIn :Water.

この表記はタートルと呼ばれ、人間が読めるように意図されています。ただし、XML、JSON形式、またはHTMLドキュメントのタグと属性を使用して同じことを記述できます。Turtle表記では、述語とオブジェクトを主題ごとにグループ化して読みやすくすることができますが、セマンティックレベルでは、各トリプレットは独立しています。



RDFは、データモデルが複雑で、多数のオブジェクトタイプとそれらの間の関係が含まれている場合に役立ちます。たとえば、Wikipediaは、RDF形式の記事のコンテンツへのアクセスを提供します。記事に記載されている事実は構造化されており、他の記事からの事実を含め、それらの特性と関係が説明されています。

RDFS

RDFモデルはグラフです。デフォルトでは、追加のセマンティクスは含まれていません。誰もがグラフ内のリンクを適切と思われるように解釈できます。RDFスキーマ（RDF上にオントロジーを構築するためのクラスとプロパティのセット）を使用して、いくつかの標準リンクを追加できます。RDFSを使用すると、特定のクラスへのリソースの帰属、クラス間の階層、プロパティの階層など、概念間の標準的な関係を記述し、サブジェクトとオブジェクトの可能なタイプを制限できます。



たとえば、ステートメント

:Mammal rdfs:subClassOf :Animal.

「Mammal」が「Animal」という概念のサブクラスであり、そのすべてのプロパティを継承することを指定します。したがって、「クジラ」の概念は、「動物」のクラスにも起因する可能性があります。しかし、このためには、「哺乳類」と「動物」の概念がクラスであることを指摘する必要があります。

:Animal rdf:type rdfs:Class.
:Mammal rdf:type rdfs:Class.

また、述語は、そのサブジェクトとオブジェクトの可能な値に制約を設定できます。



ステートメント

:livesIn rdfs:range :Environment.

「livesin」関係のオブジェクトは、常にクラス「Environment」に属するリソースである必要があることを示します。したがって、「水」の概念は「環境」の概念のサブクラスであるというステートメントを追加する必要があります。

:Water rdf:type :Environment.
:Environment rdf:type rdfs:Class

RDFSを使用すると、データスキーマを記述して、クラス、プロパティを列挙し、それらの階層と値の制限を設定できます。そしてRDFは、このスキーマを具体的な事実で満たし、それらの間の関係を定義することです。これで、このグラフについて質問できます。これは、SQLに似た特別なクエリ言語SPARQLで実行できます。

SELECT ?creature
WHERE {
?creature rdf:type :Animal;
:livesIn :Water.
} 

このクエリは、「Whale」と「Fish」の2つの値を返します。



アカウントと顧客に関する以前の出版物の例は、おおよそ次のように実装できます。RDFを使用すると、データスキーマを記述し、値を入力できます。

:Client1 :name "John";
    :email "john@somewhere.net".
:Client2 :name "Mary";
    :email "mary@somewhere.net".
:Bill_1 :client :Client1;
    :date "2020-01";
    :amountToPay 100;
    :amountPaid 50.
:Bill_2 :client :Client2;
    :date "2020-01";
    :amountToPay 80;
    :amountPaid 80.

しかし、このシリーズの最初の記事の「債務者」や「未払いの請求書」などの抽象的な概念には、算術演算と比較が含まれています。それらは、概念のセマンティックネットワークの静的構造に適合しません。これらの概念は、SPARQLクエリを使用して表現できます。

SELECT ?clientName ?clientEmail ?billDate ?amountToPay ?amountPaid 
WHERE {
?client :name ?clientName;
          :email ?clientEmail.
?bill :client ?client;
       :date ?billDate;
       :amountToPay ?amountToPay;
       :amountPaid ?amountPaid.
FILTER(?amountToPay > ?amountPaid).
}

WHERE句は、トリプルパターンとフィルター条件のリストです。ブール変数は、名前が「？」で始まるトリプレットに置き換えることができます。クエリエグゼキュータのタスクは、すべてのトリプレットパターンがグラフに含まれ、フィルタリング条件が満たされる変数のすべての可能な値を見つけることです。



ルールを使用して他のルールを作成できるPrologとは異なり、RDFではクエリはSemanticWebの一部ではありません。リクエストを別のリクエストのデータソースとして参照することはできません。確かに、SPARQLにはクエリ結果をグラフとして表す機能があります。したがって、クエリ結果を元のグラフと組み合わせて、組み合わせたグラフで新しいクエリを実行することができます。しかし、そのような決定は明らかにRDFのイデオロギーを超えます。

OWL

セマンティックWebテクノロジーの重要なコンポーネントはOWL（Web Ontology Language）です。これはオントロジーを記述するための言語です。RDFSの語彙では、概念間の最も基本的な関係、つまりクラスと関係の階層のみを表現できます。OWLは、はるかに豊富な語彙を提供します。たとえば、2つのクラス（または2つのエンティティ）が同等（または異なる）であることを指定できます。このタスクは、オントロジーを組み合わせるときによく発生します。



交差、結合、または他のクラスの追加に基づいて、複合クラスを作成できます。

• 交差する場合、複合クラスのすべてのインスタンスは、すべてのソースクラスにも適用される必要があります。たとえば、「Marine Mammal」は、「Mammal」と「SeaDweller」の両方である必要があります。
• . , , «» «», «» «». «».
• , . , «» «».
• . , .
• — , .

概念をリンクできるような式は、コンストラクターと呼ばれます。

OWLでは、多くの重要な関係プロパティを設定することもできます。

• 過渡性。関係P（x、y）とP（y、z）が成り立つ場合、関係P（x、z）も満たされます。このような関係の例としては、「多い」-「少ない」、「親」-「子」などがあります。
• 対称。関係P（x、y）が満たされると、関係P（y、x）も満たされます。たとえば、相対的な関係。
• 機能依存。関係P（x、y）とP（x、z）が成り立つ場合、yとzの値は同一でなければなりません。例は父の関係です-人は2人の異なる父を持つことはできません。
• 関係の逆転。関係P1（x、y）が満たされる場合、もう1つの関係P2（y、x）が満たされる必要があることを指定できます。このような関係の例は、親子関係です。
• 関係チェーン。AがBのプロパティに関連付けられ、BがCに関連付けられている場合、A（またはC）は特定のクラスに属するように設定できます。たとえば、AにBの父親がいて、父親Bに父親Cがいる場合、AはCの孫です。

関係の引数の値に制限を設定することもできます。たとえば、引数が常に特定のクラスに属している必要があること、クラスに特定のタイプの関係が少なくとも1つある必要があること、またはこのタイプの関係の数を制限することを指定します。または、特定の関係によって特定の値に関連付けられているすべてのインスタンスが特定のクラスに属するように指定できます。



OWLは現在、オントロジーを構築するための事実上の標準ツールです。この言語は、RDFSよりも大規模で複雑なオントロジーの構築に適しています。 OWL構文を使用すると、概念のさまざまなプロパティとそれらの間の関係を表現できます。ただし、いくつかの追加の制限も導入されます。たとえば、同じ概念をクラスとしても別のクラスのインスタンスとしても同時に宣言することはできません。 OWLオントロジーはより厳密で、より標準化されているため、より読みやすくなっています。 RDFSがRDFグラフの上にあるいくつかの追加クラスである場合、OWLには異なる数学的基礎（記述ロジック）があります。したがって、OWLオントロジーから新しい情報を抽出し、それらの一貫性をチェックして質問に答えることができる正式な推論手順が利用可能になります。



記述ロジックは、1次ロジックの一部です。 1つの場所の述語（たとえば、概念がクラスに属する）、2つの場所の述語（概念にはプロパティとその値があります）、および上記のクラスコンストラクターと関係プロパティのみが許可されます。記述論理における一次論理の他のすべての表現は削除されました。たとえば、「未払いの請求書」の概念が「請求書」クラスに属し、「請求書」の概念に「支払われる金額」および「支払われる金額」のプロパティがあるというステートメントは受け入れられます。ただし、「未払いの請求書」プロパティ「支払われる金額」の概念は、プロパティ「支払われる金額」よりも大きくする必要があることを表明することはできません。これには、これらのプロパティを比較するための述語を含むルールが必要です。残念ながら、OWLコンストラクターはこれを許可しません。

したがって、記述的論理の表現力は、一次論理の表現力よりも低い。しかし一方で、記述ロジックの推論アルゴリズムははるかに高速です。さらに、それは決定可能性の特性を持っています-解決策は有限の時間で保証されていることがわかります。実際には、そのような語彙は複雑でボリュームのあるオントロジーを構築するのに十分であると考えられており、OWLは表現力と推論効率の間の良い妥協点です。



また、SWRL（Semantic Web Rule Language）も言及する価値があります。これは、OWLでクラスとプロパティを作成する機能と、限定バージョンのDatalog言語でルールを作成する機能を組み合わせたものです。これらのルールのスタイルは、Prologの場合と同じです。SWRLは、比較、数学、文字列、日付、およびリスト操作のための組み込み述語をサポートします。これは、1つの簡単な表現を使用して「未払いの請求書」の概念を実装するために私たちが欠けていたものです。

フローラ-2

セマンティックネットワークの代わりに、フレームなどのテクノロジーを検討してください。フレームは、複雑なオブジェクト、抽象的なイメージ、何かのモデルを記述する構造です。これは、名前、一連のプロパティ（特性）、およびそれらの値で構成されます。プロパティ値は別のフレームにすることができます。また、プロパティにはデフォルト値を設定できます。その値を計算するための関数をプロパティにアタッチできます。フレームには、フレームの作成、削除、プロパティの値の変更などのイベントのハンドラーを含むサービスプロシージャを含めることもできます。フレームの重要なプロパティは、継承する機能です。子フレームには、親フレームのすべてのプロパティが含まれます。



リンクされたフレームのシステムは、RDFグラフと非常によく似たセマンティックネットワークを形成します。しかし、オントロジーを作成するタスクでは、フレームは現在事実上の標準であるOWLに取って代わられました。 OWLはより表現力があり、より高度な理論的基礎、つまり正式な記述ロジックを備えています。概念のプロパティが互いに独立して記述されるRDFおよびOWLとは異なり、フレームモデルでは、概念とそのプロパティは単一の全体、つまりフレームと見なされます。 RDFモデルとOWLモデルで、グラフの頂点に概念の名前が含まれ、エッジにプロパティが含まれている場合、フレームモデルでは、グラフの頂点にすべてのプロパティを持つ概念が含まれ、エッジには、プロパティ間の接続または概念間の継承関係が含まれます。



この場合、フレームモデルはオブジェクト指向のプログラミングモデルに非常に近いものです。それらはほぼ同じですが、スコープが異なります。フレームは、概念とオブジェクト間の関係のネットワークをモデル化することを目的とし、OOPは、オブジェクトの動作、オブジェクトの相互作用をモデル化することを目的としています。したがって、OOPは、あるコンポーネントの実装の詳細を他のコンポーネントから隠し、クラスのメソッドとフィールドへのアクセスを制限するための追加のメカニズムを提供します。



最新のフレーミング言語（KL-ONE、PowerLoom、Flora-2など）は、オブジェクトモデルの複合データタイプを1次ロジックと組み合わせます。これらの言語では、オブジェクトの構造を記述するだけでなく、ルールでこれらのオブジェクトを操作したり、特定のクラスに属するオブジェクトの条件を記述したルールを作成したりすることもできます。クラスの継承と構成のメカニズムは論理的な解釈を受け取り、推論手順で使用できるようになります。これらの言語はOWLよりも表現力があり、2つの場所の述語に限定されません。



例として、Flora-2言語で債務者を使用して例を実装してみましょう..。この言語には、フレームと1次ロジックを組み合わせたFロジックフレームロジック、他のステートメントの構造やメタプログラミングに関するステートメントを形成するためのツールを提供する高次ロジックHiLog、論理形式で許可するトランザクションロジック変更ロジックの3つのコンポーネントが含まれます。データの変更と計算の副作用について説明します。ここでは、Fロジックフレームロジックのみに関心があります。まず、これを使用して、クライアントと債務者の概念（クラス）を説明するフレームの構造を宣言します。

client[|name => \string,
email => \string
|].
bill[|client => client,
date => \string,
amountToPay => \number,
amountPaid => \number,
amountPaid -> 0
|].

これで、これらの概念のインスタンス（オブジェクト）を宣言できます。

client1 : client[name -> 'John', email -> 'john@somewhere.net'].
client2 : client[name -> 'Mary', email -> 'mary@somewhere.net'].
bill1 : bill[client -> client1,
date -> '2020-01',
amountToPay -> 100
].
bill2 : bill[client -> client2,
date -> '2020-01',
amountToPay -> 80,
amountPaid -> 80
].

'->'記号は、属性とオブジェクトの特定の値およびクラス宣言のデフォルト値との関連付けを意味します。この例では、billクラスのamountPaidフィールドのデフォルト値はゼロです。'：'記号は、クラスのエンティティを作成することを意味します。client1とclient2は、クライアントクラスのエンティティです。



これで、「未払いの請求書」と「債務者」という概念が「アカウント」と「クライアント」という概念のサブクラスであると宣言できます。

unpaidBill :: bill.
debtor :: client.

記号「::」は、クラス間の継承関係を宣言します。クラスの構造、メソッド、およびすべてのフィールドのデフォルト値が継承されます。unpaidBillクラスとdebtorクラスに属することを指定するルールを宣言することは残っています。

?x : unpaidBill :- ?x : bill[amountToPay -> ?a, amountPaid -> ?b], ?a > ?b.
?x : debtor :- ?x : client, ?_ : unpaidBill[client -> ?x]. 

最初のステートメントは、変数?がbillエンティティであり、そのamountToPayフィールドがamountPaidより大きい場合、その変数はunpaidBillエンティティであると述べています。2番目?に、unpaidBillクラスに属するもの（クライアントクラスに属し、クライアントフィールドの値が変数に等しいunpaidBillクラスのエンティティが少なくとも1つある場合）?。unpaidBillクラスのこのエンティティは、匿名変数に関連付けられ?_、その値はそれ以上使用されません。



クエリを使用して債務者のリストを取得できます。

?- ?x:debtor.

債務者クラスに関連するすべての値を見つけるようにお願いします。結果は、変数のすべての可能な値のリストになります?x：

?x = client1

フレームロジックは、オブジェクト指向モデルの可視性とロジックプログラミングの力を組み合わせたものです。データベースの操作、複雑なシステムのモデリング、異種データの統合など、概念の構造に焦点を当てる必要がある場合に便利です。

SQL

最後に、SQL構文の主な機能を見てみましょう。前回の出版物では、SQLには論理的な理論的基礎、つまりリレーショナル計算があると述べ、LINQでの債務者による例の実装を検討しました。セマンティクスの観点から、SQLはフレーミング言語とOOPモデルに近いです-リレーショナルデータモデルでは、主要な要素はテーブルであり、個別のプロパティのセットとしてではなく、全体として認識されます。



SQL構文は、このテーブルの向きに完全に適合します。リクエストはセクションに分割されます。テーブル、ビュー、ネストされたクエリで表されるモデルのエンティティは、FROMセクションに移動されました。それらの間のリンクは、JOIN操作を使用して指定されます。フィールドと他の条件の間の依存関係は、WHERE句とHAVING句にあります。述語引数をバインドするブール変数の代わりに、クエリで直接テーブルフィールドを操作します。この構文は、「線形」プロローグ構文よりも明確にドメインモデルの構造を記述します。

モデリング言語の構文スタイルの見方

未払いの請求書の例を使用して、ロジックプログラミング（Prolog）、フレームロジック（Flora-2）、セマンティックWebテクノロジー（RDFS、OWL、およびSWRL）、リレーショナル計算（SQL）などのアプローチを比較できます。それらの主な特徴を表にまとめました。





次に、半構造化データを処理するように設計されたモデリング言語の数学的基礎と構文スタイル、および汎用のオブジェクト指向の機能的なプログラミング言語と組み合わされる異種ソースからのデータ統合を見つける必要があります。



最も表現力豊かな言語はPrologとFlora-2です-それらは高次ロジックの要素を持つ完全な一次ロジックに基づいています。残りのアプローチはそのサブセットです。 RDFSを除いて、それは正式なロジックとはまったく関係がありません。この段階では、本格的な一次ロジックが好ましいオプションのように思われます。そもそも、これにこだわるつもりです。しかし、リレーショナル計算または推論データベースロジックの形式の限定されたオプションにも利点があります。大量のデータを処理するときに優れたパフォーマンスを提供します。将来的には個別に検討する必要があります。記述ロジックは制限が多すぎて、概念間の動的な関係を表現できないようです。



私の見解では、半構造化データを操作し、異種のデータソースを統合するには、関係と概念クラスに焦点を当てたルール指向のProlog（OWL）よりもフレームロジックの方が適しています。フレームモデルは、オブジェクトの構造を明示的に記述し、それらに注意を向けます。多くのプロパティを持つオブジェクトの場合、フレーム形式はルールやサブジェクトプロパティオブジェクトトリプレットよりもはるかに読みやすくなります。継承は、反復コードの量を劇的に減らすことができる非常に便利なメカニズムでもあります。リレーショナルモデルと比較すると、フレームロジックを使用すると、ツリーやグラフなどの複雑なデータ構造をより自然な方法で記述することができます。そして最も重要なことは、知識を記述するためのフレームモデルがOOPモデルに近接しているため、自然な方法でそれらを1つの言語に統合できます。



SQLからクエリ構造を借用したい。概念の定義は複雑な形をとることができ、その構成要素を強調して知覚を容易にするために、それをセクションに分割することは害にはなりません。また、ほとんどの開発者にとって、SQL構文はかなりなじみがあります。



そこで、モデリング言語の基礎としてフレームロジックを採用したいと思います。ただし、目標はデータ構造を記述し、異種のデータソースを統合することであるため、ルール指向の構文を破棄して、SQLから借用した構造化バージョンに置き換えようとします。ドメインモデルの主な要素は「コンセプト」（コンセプト）です。その定義には、ソースデータからエンティティを抽出するために必要なすべての情報を含めたいと思います。

• コンセプトの名前。
• その属性のセット。
• () , ;
• , ;
• , .

概念の定義はSQLクエリに似ています。そして、ドメインモデル全体が相互に関連する概念の形になります。



次の出版物で、モデリング言語の結果の構文を示す予定です。今すぐそれを知りたい人のために、英語の科学的なスタイルの全文がここにあります：



半構造化データ処理のためのハイブリッドオントロジー指向プログラミング



以前の出版物へのリンク：



マルチパラダイムプログラミング言語の設計。パート1-それは何のためですか？

マルチパラダイムプログラミング言語を設計します。パート2-PL / SQL、LINQ、GraphQLでのモデル構築の比較